Вход в систему

Регистрация

Подписка:

QR код подписки

 QR-Code rss feed

Использование материалов

Коллеги, перед использованием материалов данного сайта, пожалуйста, ознакомьтесь с
Правилами использования материалов сайта

Подписка на обновления

Коллеги, если вы желаете быть в курсе обновлений сайта, вы можете оформить бесплатную подписку. Это занимает 1 минуту. Далее, описаны способы подписки.

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

Версия для печатиВерсия для печатиОтправить другуОтправить другу

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

Вывод:

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

Подписаться по email:

 

Ваш email:

Delivered by FeedBurner

 

 Ваш email:

Посетите Каталог Maillist.ru.

 

Напишите нам:

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