Я работал руководителем ИТ-проектов с 2006 года, а сейчас являюсь руководителем стартап-проекта «Динабот». За это время я видел много успехов, но еще больше видел неудач. Эти неудачи, на мой взгляд, часто связаны не столько с применяемыми технологиями, сколько с узостью картины мира руководителей. И я хотел бы чтобы больше руководителей проектов умели возвышаться над технологиями и, таким образом, принимать более правильные решения.

Сегодня мы пьяны Agile! Кто не пьян, опьянеет завтра или послезавтра. И это здорово!

Вот фото с моего последнего проекта, который управлялся согласно Agile-принципам:


Agile так сказочно звучит, что некоторым страшно его использовать! Походу оказывается, что использовать Agile не так легко, как написано. Но, все равно, мы будем его использовать, так как никуда не деться от тренда. Заказчики ведь тоже пьянеют и заставляют нас ИТ-ков использовать Agile. Будем использовать несмотря на провалы, пеняя, что мы что-то неверно делаем, корректировать наши технологии, менять людей. К сожалению, часто слепо использовать…

Мы приходим к Заказчику и говорим ему: вот так мы будем планировать проект, вот так будем управлять изменениями, вот так будем управлять рисками, вот так будем проводить совещания, вот так будем эскалировать проблемы и принимать решения, вот такие сроки будут у нас на согласование, вот такая периодичность будет статусных совещаний и т.д. И приносим ему это в виде объемного документа этак страниц на 30-50 регламентирующего текста. Заказчик смотрит на это «широко закрытыми глазами» и говорит: «Круто!». То, что не соотносится с практикой, принятой у Заказчика, он предложит исправить, но в остальном документ будет принят.

А дальше началась жизнь и процессы прошли своим путем, принятия решений своим путем, а документ остался на полке. Иногда РП достает его чтобы показать, что Заказчик не соблюдает установленные сроки, либо нарушает другие договоренности. Но это делается, когда на проекте нарастает напряжение и сторонам нужно защищаться. Есть ситуации, когда РП пытается актуализировать процессы, но часто на него смотрят «косо» как на бюрократа, который вместо результата занимается «бумажками».

В итоге такой документ выполняет функцию защиты РП-ника или Подрядчика, либо маркетинговую функцию для Подрядчика: «Круто! Вы работаете по проектной технологии!». А хотелось бы, чтобы документ работал.