Как справляться с быстрыми изменениями спецификации проекта в сжатые сроки?[закрыто]

Question

Как вести себя с менеджером проекта, который устанавливает действительно жесткие сроки, но за день или около того до истечения крайнего срока вносит новые функции и изменения спецификаций для внедрения, а также еще один сжатый срок?

Хуже всего в этом то, что большая часть нового материала приводит к серьезному переписыванию существующего кода, поскольку ранее реализованные бизнес-правила больше не применимы или "набирают" странные побочные эффекты, которые необходимо рассматривать отдельно.

Кажется, что независимо от того, как сильно мы стараемся сделать систему расширяемой, всегда есть вещи, которые возникают буквально в последний момент и нуждаются в быстром внедрении и поддержке.

Как я мог справиться с такой ситуацией?Это действительно деморализует, и один коллега уже уволился из команды.

Answer 1

Это правда, что бы ты ни делал, ты человек и будешь совершать ошибки или что-то упускать.Тем не менее, регулярные изменения в ваших требованиях чаще всего являются результатом либо плохих требований, либо плохого процесса разработки, либо и того, и другого.

Какой-нибудь дизайн Заранее?

Разработчики, менеджеры проектов и т.д. Регулярно проводят бизнес-анализ в сжатые сроки.Большинство разработчиков просто хотят начать взламывать компьютер в первый день, и большинство руководителей любят позволять им это:"Вау, мы можем перейти от этапа инициации проекта к этапу строительства за 1 день, не затрачивая времени на весь этот нелепый бизнес-анализ!Это будет отлично смотреться для получения бонусов за завершение! " Но помните, что основная работа PM-менеджера - держать проект под контролем (вовремя и в рамках бюджета) ... не обязательно для того, чтобы радовать пользователей и уж точно не для того, чтобы радовать разработчиков.Это не значит, что они абсолютно бессердечны;хорошие руководители добьются своих целей, усиливая контроль за областью применения и развивая коммуникацию, и то, и другое полезно.

Но если потратить время на то, чтобы по-настоящему подумать о том, что необходимо, и проработать возможные сценарии, это может серьезно повлиять на проблемы, с которыми вы имеете дело.

• Если вы предприняли попытку провести тщательный бизнес-анализ, но все равно в итоге вносите изменения в последнюю минуту, то, возможно, ваша проблема - еще одна классическая проблема:отключенные пользователи.Эксперты по вашим предметам - ваше главное оружие в работе с этими угловыми случаями и их выявлении.Если у вас есть пользователи, которые не вовлечены в процесс анализа, наймите лучших экспертов по предмету.
• Также возможно, что пользователи отключены, потому что они слишком заняты своей обычной работой.В таком случае это проблема руководства, и им нужно дать инструкции о том, что участие в проекте является частью их работы;иногда это сложно, потому что часто то же самое руководство, которое сказало вам "сделать это вчера", - это та же самая группа болванов, которые ожидают, что проект произойдет волшебным образом, без сбоев и без каких-либо ресурсов (они распространены тем, что не понимают сложностей разработки программного обеспечения на заказ и предполагают, что это легко).Если руководство невежественно и не хочет меняться...что ж, вам придется либо работать сверхурочно и разбираться с описанными вами проблемами, либо найти новую работу.

Может ли Agile Помочь?

Конечно, было бы неплохо, если бы ваши пользователи рассказывали вам об этих угловых случаях раньше, а не позже, не так ли?Это связано с тем, что обсуждал Тоби Хеде в своем посте.Возможно, методология, позволяющая представить программное обеспечение пользователям как можно скорее, даже в неотшлифованном состоянии, может быстрее вызвать обратную связь.Это было одним из источников вдохновения для всех концепций agile.Создатели устали иметь дело с проблемами, которые вы описываете, и они также поняли, что если руководство и пользователи не собираются меняться, то, возможно, разработка сможет это сделать.Это все еще разработка, но особое внимание уделяется получению ранней обратной связи с помощью различных методов (привлечение экспертов в предметной области совместно с командой разработчиков, скорейшее попадание черновых прототипов в руки пользователей, парное программирование для использования опыта разработчиков и многое другое).Все это происходит потому, что мы понимаем, что мы люди и нам будет чего-то не хватать.

Наконец, вы упомянули, что пытаетесь сделать систему расширяемой, чтобы помочь с быстрыми изменениями, но как?Вы отделяете логику презентации от бизнес-логики?Инкапсулируете ли вы бизнес-логику в объекты, разделенные соответствующим образом, чтобы минимизировать зависимости и сцепление?Все эти вещи сложно выполнить, и на их планирование и построение может потребоваться время.

Кстати, ты не одинок.Многие (а может быть, и все) магазины сталкиваются с подобными проблемами.

Answer 2

Во-первых, не позволяйте им устанавливать крайний срок.

У вас есть 2 варианта

• Премьер-министр дает вам список функций, и вы сообщаете им, когда все будет готово.
• PM предоставит вам список функций и крайний срок.Затем вы сообщаете им, какие функции вы будете внедрять в данный момент времени.

Если PM является вашим менеджером или имеет полномочия устанавливать крайние сроки + количество функций, то я бы искал новую работу. careers.stackoverflow.com

Если PM не является вашим менеджером, вам нужно подключить своего менеджера к работе и попросить его предоставить PM свои варианты из приведенного выше списка.

Answer 3

С этим материалом действительно сложно иметь дело. Настоящая проблема здесь в том, что у вас нет процесса.

Ответ на самом деле зависит от политической ситуации в вашей организации и от того, насколько вы энергичны, чтобы стимулировать изменения.

В прошлом я пытался представить изменение процесса в нескольких организациях, и это всегда было проблемой. Это возможно, однако.

Я бы взглянул на некоторые методологии управления разработкой программного обеспечения. Я использую и рекомендую Scrum, например.

В ситуации с быстрыми изменениями работа с короткими итерациями, имеющими четко поставленные цели, может быть действительно полезной. Вам, вероятно, нужно отстаивать и управлять своим менеджером проектов, но это похоже на текущий " процесс " очевидно, не работает, поэтому продажа нового процесса на самом деле становится проще - у вас есть веское экономическое обоснование для улучшения.

Надежный процесс поможет вам «отодвинуться» на изменение требований. Быстрые реакционные изменения часто являются признаком более широких проблем в организационном направлении и стратегии, и в интересах всех решить эту проблему внутри организации.

Answer 4

Это одна из основных проблем, с которой вы столкнетесь как разработчик.

Одна хорошая техника, которую я использовал в прошлом, это задавать вопросы. Когда вы получите спецификации, найдите в них что-то, что нужно уточнить конечным пользователям. Это всегда замедляет ход событий и повышает вероятность возникновения у менеджеров рисков.

Убедитесь, что ваш менеджер проекта знает о рисках, связанных с внесением поздних изменений в проект.

Answer 5

Вы и ваша команда пытались обсудить это с самим менеджером? Это первое, что вы должны сделать.

У него может не быть большого опыта в процессе разработки, поэтому постоянные сжатые сроки и очень поздние серьезные изменения. Я видел такие случаи, люди, которые не могли развиваться, но думали, что могли бы работать лучше в PM.
Сидя и разговаривая с ним, может произойти две вещи, в зависимости от его личности / профессионализма. Он примет ваши очки и попытается изменить ситуацию на будущее, или он будет умным парнем и не сдастся, в этом случае стоит поднять ситуацию на более высокий уровень. Я не думаю, что есть какая-либо компания, которая с радостью примет потерявших разработчиков.

Кроме того, его менеджер может быть повсюду. И это проблема.

Если ничего не получается, как уже предлагалось, смена работы - это справедливо.