Я старший разработчик в agile-проекте. В этом проекте я и два других разработчика должны перенести существующее программное обеспечение на другую целевую платформу. Я не программирую, я в основном отвечаю за задачи управления проектами, написание/сбор пользовательских историй, ведение журнала невыполненных работ, организацию демонстраций спринтов, планирование спринтов, ретроспективы, отчеты руководству.
Проект был недавно отменен после шести итераций из-за изменения ожиданий продаж и бизнес-приоритетов. У нас есть еще около 8-10 итераций, чтобы закончить проект.
Я знаю, что для морального духа и мотивации не стоит выбрасывать шесть недель работы, так как же можно изящно закрыть проект?
Используйте это как возможность учиться. У меня за плечами как минимум четыре однозначно провальных проекта, и каждый из них научил меня чему-то важному.
Как объясняется в этом фантастическом ответе ,
Суждение исходит не от успехов, а от неудач. Большинство компаний хотят нанимать людей, чьи неудачи были оплачены предыдущими компаниями, поэтому они требуют
N+ years of experience
, это подразумевает, что они уже сделали все основные ошибки начального уровня , и кто-то другой должен был за них заплатить.Это суждение приходит только с опытом.
Эдисон изобрел лампочку, пережив неудачу, а не какой-то грубый опыт...
Даже самые опытные не достигают успеха без пропорционального количества неудач. Так зарабатывается здравый смысл...
Объясните вышеизложенное членам вашей команды, помогите им понять, как применить приобретенный опыт для улучшения в следующем проекте (проектах).
Настройте постмортем/ретроспективу проекта. Изучите, как все прошло, что было сделано правильно, а что можно было бы сделать лучше. Узнайте, как подать заявку... ох, невозможно адекватно осветить в ответе такую тему, не зная специфики вашего проекта.
В качестве отправной точки см. статью Стива Павлины «Проведение анализа проекта »:
Лучшее время для проведения вскрытия — около двух недель после выпуска продукта (или для некоторых продуктов после отмены проекта). Это позволяет вам восстановить свою объективность, не забывая о деталях. Ваши воспоминания все еще будут свежи, и у вас будет хорошая перспектива, чтобы увидеть проект в целом, а не слишком сильно сосредотачиваться на самой последней работе...
Еще одна полезная ссылка — эссе Скотта Беркуна «Как учиться на своих ошибках »:
Контрольный список обучения на ошибках
- Принятие ответственности делает обучение возможным.
- Не приравнивайте совершение ошибок к тому, чтобы быть ошибкой.
- Вы не можете изменить ошибки, но вы можете выбрать, как реагировать на них.
- Рост начинается, когда вы видите возможности для улучшения.
- Постарайтесь понять, почему это произошло и каковы были факторы.
- Какая информация могла бы избежать ошибки?
- Какие маленькие ошибки последовательно привели к большей ошибке?
- Есть ли альтернативы, которые вы должны были рассмотреть, но не сделали?
- Какие изменения необходимы, чтобы избежать повторения этой ошибки? Какие изменения кажутся вам трудными?
- Как, по вашему мнению, должно/изменилось бы ваше поведение, если бы вы снова оказались в подобной ситуации?
- Работайте над тем, чтобы понять ошибку, пока не сможете высмеять ее (или не захотите убивать тех, кто высмеивает).
- Не переусердствуйте: следующая ситуация не будет такой же, как предыдущая.
Good judgement comes from experience. Experience comes from bad judgement.
Я знаю, что это не лучший способ морального духа и мотивации выбросить шесть недель работы, так как же можно изящно закрыть проект?
Было бы гораздо хуже для морального духа и мотивации продолжать работу над бесполезным проектом, поэтому завершите его чисто и быстро.
Будьте честны с командой. Объясните, что они проделали большую работу, но реальность бизнеса изменилась. Люди ценят честность, и это реальный мир бизнеса, где случаются подобные вещи.
Шесть недель — это невозвратные затраты. Если за эти недели не было произведено чего-то ценного для какого-то другого проекта, работа все равно «выбрасывается». Посмотрите, есть ли что-нибудь, что можно спасти для других проектов. Если нет, проведите ретроспективу, чтобы посмотреть, чему вы научились, пообедайте в завершение проекта, отложите проект и приступайте к следующему заданию.
Вы бы спросили у людей, которые решили отменить проект, каковы шансы, что проект может быть возрожден. Если вероятность равна нулю и любая вложенная работа имеет нулевую ценность, вы немедленно отменяете ее. Если есть возможность, вы делаете минимальную работу, чтобы можно было оживить проект, скажем день-два. Делайте резервные копии всего, документируйте все, чтобы ничего не потерялось.
А затем вы говорите всем участникам, что очень сожалеете, что проект отменяется, даете всем возможность высказать, как они раздражены этим решением и насколько глупым является менеджмент, а затем переходите к следующей работе.
mhoran_psprep
IDRinkandIKnowThings