Проекты Как Люди: Иногда Они Умирают. Уроки Одного Закрытого Проекта
На прошлой неделе, один наш хороший и уважаемый клиент принял решение закрыть большой и амбициозный проект, над которым мы совместно с ними работали вот уже полтора года. Причина - необходимость в изменении ключевых требований и принципиальной смене направления.
Если коротко и не вдаваясь в технические подробности, для одной из групп ключевых стейкхолдеров - инженеров - изменения, вносимые проектом, оказались слишком революционными и требующими ресурсов, которых инженеры оказались не готовы предоставить. Например, им пришлось бы переделывать ту часть софта, которая взаимодействовала с нашим проектом. Когда мы делали пилот, они понимали преимущества, которые получат и всячески поддерживали проект, но когда дело дошло до дела, то выяснилось, что ни людей, ни времени под это они выделить не могут. Ну и заодно выяснилось, что у них теперь появились альтернативные идеи, для реализации которых надо переделывать уже всю построенную архитектуру.
Хорошие новости заключаются в том, что к нам претензий никаких нет :-) It's not you, it's us - сказал их проджект менеджер и пообещал, что если этот проект когда-нибудь оживет в новой реинкарнации, они будут рады с нами продолжить работу.
Еще более лучшие новости заключаются в том, что мы приобрели очень много новых знаний, и чисто технических, и управленческих. На следующей неделе мы с тим лидом этого проекта делаем дебриф проекта для всех участников (это наша традиция, после каждого серьезного проекта делать дебриф и обуждать, что было так, что не так, и как в будущем избежать сделанных ошибок), но несколько вещей я могу выделить уже прямо сейчас. Это уроки лично для меня, как для человека, который этот проект анализировал, продавал, и вел.
Урок #1: В пилотной части проекта привлекать всех стейкхолдеров принимать равное участие
Что получилось у нас: одна группа стейкхолдеров - системные архитекторы - участвовали активно и реально пользовались нашей системой. А инженерам их проджект менеджер просто сделал презентацию проекта, получил восторженные отзывы, на чем участие инженеров закончилось. То есть на словах они понимали, что им тоже что-то придется менять, но реально они это не почуствовали. В итоге, инженеры поддерживали проект до тех пор, пока не дошла их очередь интегрироваться с нами. И тут выяснилось, что для них это все равно, что ремонтировать Боинг во время полета со всеми пассажирами на борту.
Урок #2: Принимать более активное участие в пилотной части проекта
Что получилось у нас: мы пилот сдали и стали тихо ждать фидбэка. В результате, после получения хорошего фидбэка после пилота мы решили, что все идет как надо, учли новые требования и хотелки, и побежали дальше. А надо было не отдавать это на откуп клиенту, а вместе с ним определить,
что именно мы проверяем в пилоте, кто и в каком объеме участвует, и сколько времени отводится на пилот. Тогда можно было настоять, чтобы инженеры реально сделали часть изменений уже в рамках пилота, и это дало бы им возможность прочуствовать не только плюшки, которые они получат, но и усилия, которые им надо будет потратить в рамках полноценного проекта.
Урок #3: Посвящать больше времени на оценку
Что получилось у нас: с оценкой на реализацию части требований мы пролетели. Оценка была занижена отчасти потому, что какие-то вещи оказались для нас новыми, и у нас не было опыта в их реализации, а отчасти потому, что не были учтены все технические риски (например, непредсказуемое поведение некоторых инструментов, которыми мы пользовались). По хорошему, надо было делать тесты и грубые прототипы еще на этапе оценки. Масшатаб проекта и бюджет вполне позволяли это сделать.
Урок #4: Документировать мотивацию принятия решений
Например, мы приняли решение пользоваться инструментом Х. В тот момент, когда мы принимали решение, явно была какая-то рациональ, которая стояла за этим решением. По прошествии нескольких месяцев эту рациональ никто не помнил. Мы спросили самих себя, почему мы, собственно, пользуемся инструментом Х. Может, сменить его на Y? Но все же понимали, что решение пользоваться Х не просто так было принято, и что если рубить с плеча, можно многое порушить и в итоге опять вернуться к Х. Тогда у меня взяло несколько хороших часов, чтобы прошерстить все емейлы и свои собственные записи, чтобы воссоздать мотивацию решения.
Такие дела. А, ну и еще одна хорошая новость заключается в том, что поскольку этот проект закрылся, то у нас освободились ресурсы для других проектов. Жизнь-то на месте не стоит :-)
Если коротко и не вдаваясь в технические подробности, для одной из групп ключевых стейкхолдеров - инженеров - изменения, вносимые проектом, оказались слишком революционными и требующими ресурсов, которых инженеры оказались не готовы предоставить. Например, им пришлось бы переделывать ту часть софта, которая взаимодействовала с нашим проектом. Когда мы делали пилот, они понимали преимущества, которые получат и всячески поддерживали проект, но когда дело дошло до дела, то выяснилось, что ни людей, ни времени под это они выделить не могут. Ну и заодно выяснилось, что у них теперь появились альтернативные идеи, для реализации которых надо переделывать уже всю построенную архитектуру.
Хорошие новости заключаются в том, что к нам претензий никаких нет :-) It's not you, it's us - сказал их проджект менеджер и пообещал, что если этот проект когда-нибудь оживет в новой реинкарнации, они будут рады с нами продолжить работу.
Еще более лучшие новости заключаются в том, что мы приобрели очень много новых знаний, и чисто технических, и управленческих. На следующей неделе мы с тим лидом этого проекта делаем дебриф проекта для всех участников (это наша традиция, после каждого серьезного проекта делать дебриф и обуждать, что было так, что не так, и как в будущем избежать сделанных ошибок), но несколько вещей я могу выделить уже прямо сейчас. Это уроки лично для меня, как для человека, который этот проект анализировал, продавал, и вел.
Урок #1: В пилотной части проекта привлекать всех стейкхолдеров принимать равное участие
Что получилось у нас: одна группа стейкхолдеров - системные архитекторы - участвовали активно и реально пользовались нашей системой. А инженерам их проджект менеджер просто сделал презентацию проекта, получил восторженные отзывы, на чем участие инженеров закончилось. То есть на словах они понимали, что им тоже что-то придется менять, но реально они это не почуствовали. В итоге, инженеры поддерживали проект до тех пор, пока не дошла их очередь интегрироваться с нами. И тут выяснилось, что для них это все равно, что ремонтировать Боинг во время полета со всеми пассажирами на борту.
Урок #2: Принимать более активное участие в пилотной части проекта
Что получилось у нас: мы пилот сдали и стали тихо ждать фидбэка. В результате, после получения хорошего фидбэка после пилота мы решили, что все идет как надо, учли новые требования и хотелки, и побежали дальше. А надо было не отдавать это на откуп клиенту, а вместе с ним определить,
что именно мы проверяем в пилоте, кто и в каком объеме участвует, и сколько времени отводится на пилот. Тогда можно было настоять, чтобы инженеры реально сделали часть изменений уже в рамках пилота, и это дало бы им возможность прочуствовать не только плюшки, которые они получат, но и усилия, которые им надо будет потратить в рамках полноценного проекта.
Урок #3: Посвящать больше времени на оценку
Что получилось у нас: с оценкой на реализацию части требований мы пролетели. Оценка была занижена отчасти потому, что какие-то вещи оказались для нас новыми, и у нас не было опыта в их реализации, а отчасти потому, что не были учтены все технические риски (например, непредсказуемое поведение некоторых инструментов, которыми мы пользовались). По хорошему, надо было делать тесты и грубые прототипы еще на этапе оценки. Масшатаб проекта и бюджет вполне позволяли это сделать.
Урок #4: Документировать мотивацию принятия решений
Например, мы приняли решение пользоваться инструментом Х. В тот момент, когда мы принимали решение, явно была какая-то рациональ, которая стояла за этим решением. По прошествии нескольких месяцев эту рациональ никто не помнил. Мы спросили самих себя, почему мы, собственно, пользуемся инструментом Х. Может, сменить его на Y? Но все же понимали, что решение пользоваться Х не просто так было принято, и что если рубить с плеча, можно многое порушить и в итоге опять вернуться к Х. Тогда у меня взяло несколько хороших часов, чтобы прошерстить все емейлы и свои собственные записи, чтобы воссоздать мотивацию решения.
Такие дела. А, ну и еще одна хорошая новость заключается в том, что поскольку этот проект закрылся, то у нас освободились ресурсы для других проектов. Жизнь-то на месте не стоит :-)