Постарался расставить проблемы, с которыми сталкиваемся, по степени их влияния на исход проекта. К некоторым болезням проектного менеджмента удалось найти лекарства, но некоторые по-прежнему дают большие риски, которые съедают бюджеты и ресурсы.

Андрей Лещинский, E-xecutive


Хочу попросить не отсылать к известным методологиям PMI, PRINCE2 и так далее. Так как в них указаны диапазоны бюджетов, в которых применимость их будет давать эффект больший чем затраты на саму методологию – это от тыс. Интересуют решения для проектов бюджетами от тыс. до тыс.

1. Неправильная оценка проекта. Почти все заказчики хотят fix-cost. И это правильно с их точки зрения, только имея понимание об этом, они принимают решение запускать или не запускать проект.

Как лечится: выделение консалтинга в отдельный проект. По результатам имеем концепт проекта, ТЗ, ИСР, бюджет, календарь.

2. Противодействие или отсутствие действий со стороны персонала заказчика на этапе внедрения. На проект деньги еще выделяют, а зарплатный фонд никто не увеличивает на работы во время переходного процесса, например когда на предприятии работают две системы учета, или на обучение.

Как лечится: обучение заказчика, создание у него центра компетенции.

3. Ошибки при проработке требований заказчика. Все требования вроде как и фиксируются, систематизируются, но требования исходят от разных отделов и людей. Люди меняются и к моменту, когда есть результат, на месте внедрения оказываются уже другие люди с другими взглядами. Никто не отслеживает кто и как меняется, и нет процедуры чтобы вызвать инициативные изменения требований со стороны Заказчика.

Как лечится: управление требованиями, утвержденная процедура изменения требований.

4. Учет изменений на проекте и документация особенностей. Реализация идет с согласованными отклонениями от постановки, и это нормально, но когда проект уже запущен и летит, никто не занимается документацией этих отклонений и «фич». В итоге, если приходит новый человек на проект или его в дальнейшем надо сопровождать, то чтобы ввести его в курс дела, ничего нет кроме как первоначального устаревшего ТЗ и спецификаций. Проект изменился, он уже другой. Денег на исправление нет никогда. Такой проект становится кошмаром для support.

Как лечится: фиксировать все изменения в концепте проекта, хотя это ресурсозатратно.

5. Недостаточная обеспеченность проекта ресурсами. Сюда можно включить все разнообразие:

  1. Людей не выделяют в нужном количестве и нужной квалификации
  2. Людей забирают в середине проекта на тушение пожаров
  3. Людей забирают в середине проекта на support их прошлых проектов
  4. Неадекватная замена исполнителей
  5. Текучка на проекте – уходят те, кто «в теме», а набирают тех, кого найдут

Лекарства пока нет. Видимо такова специфика отрасли – «овертаймить» и проваливать сроки.

6. Замыкание многих процессов на самых компетентных и перегрузка их работой. Нет делегирования. Всегда на проекте те, кто знает и делает, и те, кто делает, только если скажут. Ответственные и компетентные люди не всегда используют делегирование или этому не способствует обстановка в команде.

Лекарства пока нет. Видимо такова специфика отрасли IT. Хорошие инженеры и программисты по своей природе интраверты. Все говорят о Agile team building как лекарстве, но пока не получилось. Так как этот процесс утянет и так ограниченные ресурсы и деньги, понадобится компетентный и недешевый HR. Если у кого есть идеи, посоветуйте.

7. Много средств требует поддержка инфраструктуры и управление ей. Сколько не пиши правила где девелопим, как деплоим, где тестируем, как выливаем релизы — в PMI это называется «Концепция проекта», — все же постоянно нужно проверять, разъяснять наказывать, и в итоге ПМ берет на себя все больше и больше участков работы.

Как лечится: Выделение ресурса на процесс контроля и прямое отражение этой статьи в затратах.

8. Сложность постановки процесса разработки под конкретный проект. Тут как не унифицируй, но каждый проект уникален в плане какие сервера, где стоят какой к ним доступ. Как пример — есть заказчики, которые выделяют к себе только узкий VPN через которые должны все ходить.

Как лечится: Выделение ресурса на процесс планирования и прямое отражение этой статьи в затратах.

9. Отсутствие итерационности в проекте. Заказчику нужно показывать и давать оценивать промежуточные результаты, чтобы понимать, что мы не сбились с пути. А у заказчика не всегда есть время на оценку. А надо лететь дальше, так как заказчику нужны сроки, а не оправдания и не дай бог его потыкать носом в не отвеченные запросы.

Как лечится: Введение в проект роли «аккаунт менеджер», который постоянно на связи с заказчиком и выдергивает из него все необходимое.

10. Плохое использование прошедшего опыта разработок и отсутствие условий его накопления и использования в будущем. Когда проект «горит», никто не думает о формировании библиотек или модулей для использовании в будущем. В итоге постоянное изобретение велосипедов вместо производства.

Лекарства пока нет: Если есть опыт посоветуйте, как мотивировать ПМ и разработчиков на выполнение этого процесса?

Серым фоном выделены проблемы, для которых автор не видит решений.

Серым фоном выделены проблемы, для которых автор не видит решений.