Изящная отмена проекта

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

Проект был недавно отменен после шести итераций из-за изменения ожиданий продаж и бизнес-приоритетов. У нас есть еще около 8-10 итераций, чтобы закончить проект.

Я знаю, что для морального духа и мотивации не стоит выбрасывать шесть недель работы, так как же можно изящно закрыть проект?

Сосредоточьтесь на том, чтобы помочь им получить назначение на следующую задачу. Остаться незамеченным без покрытия еще хуже, чем выбросить 6 недель работы.

Ответы (3)

Используйте это как возможность учиться. У меня за плечами как минимум четыре однозначно провальных проекта, и каждый из них научил меня чему-то важному.

Как объясняется в этом фантастическом ответе ,

Суждение исходит не от успехов, а от неудач. Большинство компаний хотят нанимать людей, чьи неудачи были оплачены предыдущими компаниями, поэтому они требуют N+ years of experience, это подразумевает, что они уже сделали все основные ошибки начального уровня , и кто-то другой должен был за них заплатить.

Это суждение приходит только с опытом.

Эдисон изобрел лампочку, пережив неудачу, а не какой-то грубый опыт...

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

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

Настройте постмортем/ретроспективу проекта. Изучите, как все прошло, что было сделано правильно, а что можно было бы сделать лучше. Узнайте, как подать заявку... ох, невозможно адекватно осветить в ответе такую ​​тему, не зная специфики вашего проекта.

В качестве отправной точки см. статью Стива Павлины «Проведение анализа проекта »:

Лучшее время для проведения вскрытия — около двух недель после выпуска продукта (или для некоторых продуктов после отмены проекта). Это позволяет вам восстановить свою объективность, не забывая о деталях. Ваши воспоминания все еще будут свежи, и у вас будет хорошая перспектива, чтобы увидеть проект в целом, а не слишком сильно сосредотачиваться на самой последней работе...

Еще одна полезная ссылка — эссе Скотта Беркуна «Как учиться на своих ошибках »:

Контрольный список обучения на ошибках

  • Принятие ответственности делает обучение возможным.
  • Не приравнивайте совершение ошибок к тому, чтобы быть ошибкой.
  • Вы не можете изменить ошибки, но вы можете выбрать, как реагировать на них.
  • Рост начинается, когда вы видите возможности для улучшения.
  • Постарайтесь понять, почему это произошло и каковы были факторы.
  • Какая информация могла бы избежать ошибки?
  • Какие маленькие ошибки последовательно привели к большей ошибке?
  • Есть ли альтернативы, которые вы должны были рассмотреть, но не сделали?
  • Какие изменения необходимы, чтобы избежать повторения этой ошибки? Какие изменения кажутся вам трудными?
  • Как, по вашему мнению, должно/изменилось бы ваше поведение, если бы вы снова оказались в подобной ситуации?
  • Работайте над тем, чтобы понять ошибку, пока не сможете высмеять ее (или не захотите убивать тех, кто высмеивает).
  • Не переусердствуйте: следующая ситуация не будет такой же, как предыдущая.
+1. Цитируя/перефразируя многих писателей (совершенно неясно, кто сказал это первым): «Хорошее суждение — результат опыта, однако опыт обычно приобретается в результате неправильного суждения». Учиться на неудачах — это именно то, что имеется в виду, говоря о том, чтобы снова встать на лошадь после того, как вы упали. (... если вы на самом деле не пытаетесь обкатать настоящую лошадь, то речь идет об обучении лошади, а не себя. По-тай-то, по-та-то.)
Я думаю, мы можем обсудить, следует ли считать это «неудачей» или нет, потому что неудача подразумевает (для некоторых?), что кто-то сделал ошибку, а здесь это не обязательно так. Бизнес-приоритеты могут измениться в зависимости от новой информации, поэтому возможно, что действительное решение на прошлой неделе («продолжить проект») станет недействительным на этой неделе («наши конкуренты запустили X, остановите наш проект»). Конечно, разработчики не должны покидать проект с мыслью, что они как-то потерпели неудачу.
@JanFabry хорошая заметка, я изменил формулировку, чтобы учесть это. Отмененный проект не обязательно означает провал
@BrianS - Я держу целое состояние печенья с предсказанием на моем столе. Однако он формулирует это немного более содержательно:Good judgement comes from experience. Experience comes from bad judgement.

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

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

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

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

Лучше всего об этом сказал Бард: «Если это было сделано, когда сделано, то было бы хорошо. Это было сделано быстро».

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

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