Сегодня мы решили затронуть достаточно грустную, но весьма поучительную тему. Наверняка многие из Вас слышали, что успешных IT проектов не так уж много на фоне общей массы, а влияет на эту печальную статистику огромное количество факторов. Это вводная статья целого цикла публикаций о факторах успехов и неудач IT проектов, в которых мы соберем для Вас различную статистику, научные публикации и мнения специалистов из самых разных компаний. Мы начнем с анализа нескольких весьма дорогих кейсов из отрасли с 1992 по 2005 год и соберем для Вас факторы, которые повлекли за собой не самые удачные результаты.
Некоторые из этих факторов достаточно очевидны. Взять хотя бы “некорректную оценку необходимых для проекта ресурсов”, этот фактор кажется вполне логичным и не является чем-то новым. Разумеется, если Вы не выделили под проект достаточное количество специалистов, некорректно прикинули их компетенции, не выделили достаточного количества рабочих машин, вряд ли такой проект “взлетит”. Но кроме очевидных факторов, в IT проектах мы можем встретить и довольно много тех, что лежат отнюдь не на поверхности. К факторам такого вида можно отнести, например, “отсутствие постоянного анализа состояния проекта со стороны менеджера”. С одной стороны, казалось бы, толку от того, что менеджер смотрит за состоянием проекта, однако важным моментом в данном случае является то, что обзор состояния проекта необходимо делать с постоянными временными интервалами, чтобы лучше понимать “буксует” проект или нет. Потому что именно участившиеся буксировки на проекте сказываются на его результатах. Ниже приведен полный перечень факторов неудач проектов, собранных в рассматриваемых кейсах:
- Отсутствие проработанных превентивных действий — как следствие, команда не готова к трудностям на проекте, огромное количество времени уходит на поиск решения, прямые работы останавливаются.
- Нереалистичные или нечеткие цели проекта — из размытого понимания целей зачастую выходят размытые рамки проекта и размытые требования. Применяя определенные методики, команда может прийти к правильному решению и сформулировать цели в ходе проекта, но это удается далеко не всегда.
- Слабый/редкий/нечеткий репортинг статуса проекта командой — непонимание того, где мы сейчас находимся, почти наверняка приведет к тому, что команда будет все больше спотыкаться на следующих шагах.
- Неуправляемые риски — почти как в пункте 1, отсутствие хотя бы какого-то плана или перечня действий в ответ на риски, может стать существенной угрозой проекту.
- Плохая коммуникация между клиентами, разработчиками и пользователями — общение, общение и еще раз общение, только так можно достичь взаимопонимания на сложных проектах, четко сформулировать требования и реализовать их в соответствии с бизнес-потребностями.
- Использование “слишком” новых технологий разработки — мало того, что компетенций у команды может в какие-то моменты не хватать, если использовать слишком новые технологии, так они еще и далеко не всегда стабильно работают, а стабильный релиз может стать доступным для покупки/скачивания, когда команда уже погрязнет в проблемах.
- Невозможность справиться с комплексностью (в смысле большого количества зависимостей) проекта — большое количество взаимосвязей, как в коде программного продукта, так и в самом окружении проекта, могут попросту сломать команду после того, как они столкнуться с чередой смежных проблем и ошибок, возникающих в самых разных частях проекта.
- Слабые технические компетенции команды — ну что тут сказать, команда доставляет, прежде всего продукт, так что без необходимых скилов ну совсем никуда.
- Несогласованность стейкхолдеров со стороны клиента — попробуйте собрать перечень требований, если потребности стейкхолдеров постоянно конфликтуют, даже если сможете, сроки проекта почти наверняка поедут
- Недостаточность проверок/пересмотров — как следствие, накопление ошибок, которое тянется от самого сбора требований и до первого релиза продукта, концов потом не найдешь.
- Недостаточность поддержки топ-менеджмента — проект далеко не уедет, к сожалению, если в нем не будет предусмотрена возможность вызова в определенный момент “корпоративного пинка”, который позволит быстро согласовать документ, начать новую стадию, организовать необходимую встречу и так далее.
- Недостаточность инвестиций в обучение персонала — про этот аспект мы будем разговаривать отдельно, о нем нам расскажет один из ведущих специалистов партнерской компании, а точнее о том, как он боролся с последствиями возникновения этого фактора на своем проекте. Очень скоро, мы опубликуем статью “Пользователи. Когда планирование бессмысленно”, и Вы сами все узнаете.
