Постарался расставить проблемы, с которыми сталкиваемся, по степени их влияния на исход проекта. К некоторым болезням проектного менеджмента удалось найти лекарства, но некоторые по-прежнему дают большие риски, которые съедают бюджеты и ресурсы.
Хочу попросить не отсылать к известным методологиям PMI, PRINCE2 и т.д. Так как в них указаны диапазоны бюджетов, в которых применимость их будет давать эффект больший чем затраты на саму методологию — это от 50 000 $ USA. Интересуют решения для проектов бюджетами от 5 000 до 30 000 $ USA.
1. Неправильная оценка проекта. Почти все заказчики хотят fix-cost. И это правильно с их точки зрения, только имея понимание об этом, они принимают решение запускать или не запускать проект.
Как лечится: выделение консалтинга в отдельный проект. По результатам имеем концепт проекта, ТЗ, ИСР, бюджет, календарь.
2. Противодействие или отсутствие действий со стороны персонала заказчика на этапе внедрения. На проект деньги еще выделяют, а зарплатный фонд никто не увеличивает на работы во время переходного процесса, например когда на предприятии работают две системы учета, или на обучение.
Как лечится: обучение заказчика, создание у него центра компетенции.
3. Ошибки при проработке требований заказчика. Все требования вроде как и фиксируются, систематизируются, но требования исходят от разных отделов и людей. Люди меняются и к моменту, когда есть результат, на месте внедрения оказываются уже другие люди с другими взглядами. Никто не отслеживает кто и как меняется, и нет процедуры чтобы вызвать инициативные изменения требований со стороны Заказчика.
Как лечится: управление требованиями, утвержденная процедура изменения требований.
4. Учет изменений на проекте и документация особенностей. Реализация идет с согласованными отклонениями от постановки, и это нормально, но когда проект уже запущен и летит, никто не занимается документацией этих отклонений и «фич». В итоге, если приходит новый человек на проект или его в дальнейшем надо сопровождать, то чтобы ввести его в курс дела, ничего нет кроме как первоначального устаревшего ТЗ и спецификаций. Проект изменился, он уже другой. Денег на исправление нет никогда. Такой проект становится кошмаром для support.
Как лечится: фиксировать все изменения в концепте проекта, хотя это ресурсозатратно.
5. Недостаточная обеспеченность проекта ресурсами. Сюда можно включить все разнообразие:
a. Людей не выделяют в нужном количестве и нужной квалификации
b. Людей забирают в середине проекта на тушение пожаров
c. Людей забирают в середине проекта на support их прошлых проектов
d. Неадекватная замена исполнителей
e. Текучка на проекте – уходят те, кто «в теме», а набирают тех, кто найдут
Лекарства пока нет. Видимо такова специфика отрасли – «овертаймить» и проваливать сроки.
6. Замыкание многих процессов на самых компетентных и перегрузка их работой. Нет делегирования. Всегда на проекте те кто знает и делает и те кто делает только если скажут. Ответственные и компетентные люди не всегда используют делегирование или этому не способствует обстановка в команде.
Лекарства пока нет. Видимо такова специфика отрасти IT. Хорошие инженеры и программисты по своей природе интраверты. Все говорят о Agile team building как лекарстве, но пока не получилось. Так как этот процесс утянет и так ограниченные ресурсы и деньги, понадобится компетентный и недешевый HR. Если у кого есть идеи, посоветуйте.
7. Много средств требует поддержка инфраструктуры и управление ей. Сколько не пиши правила где девелопим, как деплоим где тестируем, как выливаем релизы — в PMI это называется «Концепция проекта», — все же постоянно нужно проверять, разъяснять наказывать, и в итоге ПМ берет на себя все больше и больше участков работы.
Как лечится. Выделение ресурса на процесс контроля и прямое отражение этой статьи в затратах.
8. Сложность постановки процесса разработки под конкретный проект. Тут как не унифицируй, но каждый проект уникален в плане какие сервера, где стоят какой к ним доступ. Как пример — есть заказчики, которые выделяют к себе только узкий VPN через которые должны все ходить.
Как лечится. Выделение ресурса на процесс планирование и прямое отражение этой статьи в затратах.
9. Отсутствие итерационности в проекте. Заказчику нужно показывать и давать оценивать промежуточные результаты, чтобы понимать, что мы не сбились с пути. А у заказчика не всегда есть время на оценку. А надо лететь дальше, так как заказчику нужны сроки, а не оправдания и не дай бог его потыкать носом в не отвеченные запросы.
Как лечится. Введение в проект роли «аккаунт менеджер» который постоянно на связи с заказчиком и выдергивает из него все необходимое.
10. Плохое использование прошедшего опыта разработок и отсутствие условий его накопления и использования в будущем. Когда проект «горит» никто не думает о формирований библиотек или модулей для использовании в будущем. В итоге постоянное изобретение велосипедов вместо производства.
Лекарства пока нет. Если есть опыт посоветуйте, как замотивировать ПМ и разработчиков на выполнение этого процесса?
Автор: andrewleshchynskyy
