«Безнадежный» проект. 8 «уроков палкой»

Не бывает безнадежных проектов. Бывают плохие проектные менеджеры. К коим себя в случае этого проекта я могу отнести.

Излишняя самоуверенность бывает вредна, а для успеха проекта очень часто нужно заботиться «о политике», а не только о технике.

Статья написана сугубо по своим личным ошибкам, соответственно больше дискуссионная, чем информационная.

Урок 1. Ответственность за реализацию проекта лежит только на руководителе проекта со стороны заказчика Довольно не легко писать о неудачах. Тем более с посылом что «неудач по вине заказчика» или «неудач по вине исполнителя» не бывает.Ответственность за реализацию проекта лежит только на руководителе проекта со стороны заказчика.

В компании должен быть человек на которого все будут показывать пальцем при вопросе «кто у вас занимается вопросом внедрения.?». Руководитель проекта со стороны исполнителя, конечно, тоже должен присутствовать, но нужно осознавать, что у этого человека достаточно простые цели – подписать акты и получить деньги.

Если в большой компании вложили кучу денег в проект, то может повести и у этого человека будет ещё цель получить «рефернс» по проекту, который он мог бы показывать другим заказчикам. Если исполнитель не удовлетворят – нужно менять компанию исполнителя, если денег на проект недостаточно – нужно добиваться увеличения бюджета от спонсора проекта, или устанавливать ограничения проекта.

Это всё я пишу к тому что в моём случае я не пытаюсь написать «все мне мешали», а наоборот прекрасно осознаю что если бы принимал верные «политические» решения, то проект можно было бы спасти.

Урок 2. Никогда нельзя братья за руководство проектом, который находится «в финальной стадии» Началось всё достаточно банально – смена места работы. Небольшая торговая компания (5 крупных магазинов в Москве).

Best Epic Fail morons level 80


Область бизнеса, с которой давно знаком. Всё вроде бы хорошо, только вот одна вещь смущала на собеседовании – заниматься придётся проектом, который уже находится в финальной стадии.

Так вот, лучшее что можно сказать в этой ситуации – никогда нельзя браться за руководство проектом, который находится «в финальной стадии». Я, конечно, не был настолько наивен, чтобы этого совсем не понимать, но был слишком самоуверен, потому как с навыками разработчика пока не расстался, а тот объём работы, который предстояло выполнить, мне не показался таким уж большим; в крайнем случае, при желании, можно и своими силами справиться.

Логика тут простая: подключиться к разработке на 100% это равносильно 2-3 среднестатистическим разработчикам из франчайзи (думаю ни для кого не стало откровением, каков средний уровень разработчика во франчайзи, я этим не пытаюсь как либо «возвысить свои способности»). Теперь если меня совсем прижмёт, я могу работать до 16 часов в день, соответственно умножаем на 2. Получается уже неплохой объём ресурсов, вряд ли на данный проект выделяли намного больше.

С учетом того, что все эти ресурсы действуют предельно согласованно и не тратят время на взаимодействие друг с другом, не нуждаются в управлении, задачах, контроле, чётких ТЗ получается вполне эффективная команда. Но как показала практика завалить можно любой проект.

Абсолютно любой.

Урок 3. Завалить можно любой проект. Абсолютно любой Итак, при выходе на работу начались сюрпризы.

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

Плюс жуткая текучка кадров.

Как это влияет на проект? Да очень просто. Ни о какой «проектной команде» внутри уже не может быть и речи.

К ежедневной отчетности я отнёсся спокойно – привык уже. Только привык, конечно, отчитываться по результатам, а не по действиям.

Далее самое интересное – компания франчайзи (очень крупная и всем известная) собиралась внедрять типовую УТ 11 (тогда ещё были первые релизы – только вышла) без доработок. На складе, как-никак, но человек 20 там работает, пользователей человек 10-15.

Как не постеснялись это написать — не знаю. Кроме того, внедрять собирались не с начала года и без переноса данных – «скачком» как это любят называть.

Это уже конечно немного напугало.

Перспектива активного участия в разработке становилась почти неизбежной.

Наиболее подходящая Вам статья…

Понравилась статья? Поделиться с друзьями: