Изученный урок №105. Не бойтесь менять подходы для решения проблем

Ситуация:
Вы - руководитель проекта по разработке нового функционала для вашей корпоративной системы. Вы утвердили устав проекта, составили план график работ, реестр заинтересованных лиц, реестр рисков, прочие оперативные проектные документы и начали работы по созданию продукта. Непосредственно в выполнение работ проекта, помимо прочих сотрудников, был вовлечен финансовый директор компании (он же спонсор проекта), что являлось особенностью данного проекта. Финансовый директор, хотя и был вторым лицом в компании, не стал делегировать работы по написанию спецификации, описывающей требования к новому функционалу с точки зрения финансового подразделения, а взялся за ее написание сам. Другой особенностью проекта было то, что он должен был быть выполнен в весьма сжатые сроки, поэтому был принят итерационный подход и документ с требованиями формировался не сразу в окончательном варианте, а итерациями, параллельно разработке. Первое время дело двигалось споро, появлялись вопросы, проводились встречи для их решения, финансовый директор создавал новые версии спецификации, они обсуждались и утверждались, но примерно на 50% завершения спецификации дело застопорилось. Как вы ни старались сдвинуть дело с мертвой точки, "воз" оставался на месте. Финансовый директор не создавал новых версий спецификации и проект начал выбиваться из сроков. Тогда вы пошли на изменение подхода к написанию спецификации. Вы предложили финансовому директору делегировать само написание спецификации, а не принятие решений по продукту. Т.е. согласно предложенному подходу, вы обсуждали вопросы, касающиеся требований к продукту, создавали протокол и уже утвержденные решения, сотрудник финансового подразделения включал в спецификацию. Финансовый директор согласился с предложением.

Вывод:

Подобная ситуация встречается не столь редко, как может показаться, особенно в относительно небольших компаниях. В данном случае, вы поступили абсолютно верно. Финансовый директор, очевидно, опасался делегировать полномочия по определению возможностей нового функционала. Делегировав просто написание самой спецификации, и оставив за собой право определения требований, была решена проблема с написанием спецификации. Теперь новые версии создавались вовремя и проект двинулся дальше. В данном случае, важно быть сосредоточенным на проекте [1], чтобы правильно оценить влияние проводимых изменений. В этом случае вы можете выполнять даже серьезные изменения и это будет безопасно для проекта.