Самые распространенные причины фейлов IT проектов

Непонимание цели проекта командой. Одни пишут код, другие его тестируют, что-то демонстрируется клиенту, в итоге продукт выходит в прод. А оказывается, что архитектор не понимал объема данных, которые будут обрабатываться системой, и в итоге через неделю эксплуатации всё встало. Все красивые качественно свёрстанные (и даже в срок) дизайны, вся бизнес логика - всё не работает без существенных архитектурных переделок. Epic Fail. А ваша команда понимает, зачем они делают этот продукт и какие ключевые показатели будут определять его успех?

Недостаток управления. Берем несколько самоходных Senior разработчиков и успех проекту обеспечен! Добавим им администратора проекта (если повезет - junior PM), чтобы помогал с отчетами (и только не мешал!) на пару часов в день, дадим ему лычку Руководитель Проекта X и готово. А потом почему-то всё разваливается: разработчики предпочитают холивары продуктивной работе, делают не то, что нужно клиенту, а как правильно, плюс совсем неожиданно выстреливают какие-то проблемы, клиент не понимает, когда он наконец-то получит результат, в чем причина очередной задержки и что такое рефакторинг. Кто виноват? Project Manager, конечно. Меняем, теперь уж точно заживем. Исторически роль PM недооценивается, на них почему-то стараются экономить, урезать их загрузку (что там делать-то), закрывать позиции новичками с низким рейтом и т. д. Недавно в рейт карте одного из Digital-агентств увидел ставку PM ниже ставки тестировщика. Не хотите пожаров - позаботьтесь о том, чтобы у вас был человек, который держит в голове целостно проект, на постоянной основе работает со стейкхолдерами, командой, занимается полноценным управлением рисками и всякой остальной "ерундой" из-за которой клиенты и члены команды разбегаются, наевшись "сложного" проекта. Только убедитесь, что руководитель вашего проекта знает что, зачем и как делать. А на вашем проекте достаточно квалификации и времени PM?

Недостаток планирования на старте. Мы всегда торопимся начать новый проект, поскорее дать клиенту оценку, подписать контракт и запустить проект, а потом уж "как-нибудь" сделаем. "Как-нибудь" и получается. На планировании экономить себе дороже. Это и испорченные отношения с клиентом, и выгоревшая команда, и работа с маленькой маржинальностью (спасибо, если не в убыток). Если верить PMBOK, процессы планирования - это основа проектного управления. И речь тут не только о план-графике проекта, но и о плане контроля качества, работы с рисками, коммуникаций со стейкхолдерами и др. Нельзя говорить об "управляемости", если у нас нет надежных планов, по которым мы можем отслеживать прогресс, если у нас не проанализированы риски проекта на старте и каждый день грозит принести новый сюрприз, если мы не понимаем, как мы будем контролировать качество. Шансы на успех такого проекта малы. Всегда должен быть честный, хорошо проработанный план, разработанный командой и согласованный со стейкхолдерами. А у вас такой есть, или проект по сути пущен на самотёк? Если вы тоже стартовали проект в спешке, т. к. "надо было вчера", убедитесь, что сейчас все необходимые аспекты проекта должным образом спланированы и согласованы.

Чрезмерный оптимизм. "Я видел библиотеку, её здесь используем и пол дела сделано", "в этом спринте получилось немного медленнее - обязательно наверстаем в следующем", "тут задача простая, давай заложим на нее пару недель и точно успеем". Да почему вы так думаете?! Необоснованный оптимизм - частая причина недостаточной проработки рисков, ошибок в эстимейте, сокрытия от Заказчика реального положения дел и т. д.. Ничего из этого к успеху ваш проект не приближает. Не надо бояться быть параноиками и уточнять у коллег "почему ты так думаешь?". Лучше честно прописать риски, заложить прозрачные резервы на те или иные задачи, согласовать с Заказчиком как позитивный, так и негативный сценарий, вовремя признать отставание от плана, в конце концов, и начать что-то предпринимать. А насколько реалистичен ваш план проекта и ваши договоренности с Заказчиком?

Отдельные специалисты, а не команда. И вроде опытные ребята в проекте, и специалисты они хорошие, но почему-то "не едет". Каждый сфокусирован на своих задачах в рамках своей зоны ответственности и только. В итоге и требования формально есть, и код написан, и даже протестирован как-то, а продукта нет. И всё это с просто невозможными задержками (когда 5ти минутный вопрос коллеги может подвиснуть где-то в JIRA на несколько дней), склоками (я это не должен делать) и т. д. Никто не старается заглянуть за свои рамки, поучаствовать в обсуждении требований, помочь коллеге с дебагом дефекта, или рассказать как реализована бизнес-логика "на пальцах". Без команды успех проекта маловероятен. Вот почему важно уделять достаточно времени на подбор команды, чтобы специалисты были "срабатываемы" и всячески помогать им в этом процессе в ходе выполнения проекта. А вы можете назвать людей, которые занимаются вашим проектом громким словом Команда? Руководитель проекта понимает насколько это важно и умеет помогать людям становиться командой?