Снова стал свидетелем того, как руководитель, прочитав какую-то книгу про одну из методологий управления проектами, уже утром начал натягивать ее на свой проект. Да, именно натягивать, иначе и не скажешь.
И вот с невероятной скоростью появляются документы: “Risk management list”, “Анализ отклонений” и прочие планы, ровно в том составе, как это было прочитано. Команде объявляется о начале новой жизни, вводится новая терминология, каждое слово которой наполнено важностью и обязательным соответствием тому, что написано в книге. Создается куча регламентов и диаграмм Ганта. Что в результате? Проект просрочен неприемлемо, команда в растерянности и пытается завершить его хотя бы в каком-то виде, документы не актуализируются. Приняв методологию за догмат, руководитель бросил все усилия именно на нее, забыв о реальном контексте, в котором разрабатывается проект. Он забыл о проекте, о его цели.
Меня часто спрашивают о том, по какой методологии мы работаем. Ни по какой и по всем одновременно! Мне известны методологии Agile, известны рекомендации PMBoK, но я не вижу необходимости, а иногда и возможности, строго следовать всему тому, что в них излагается. Любую методологию мы используем исключительно как справочник, как некий свод рекомендаций, которые могут применены. Но применены лишь тогда, когда они уместны в данном контексте. Безусловное следование положениям методологии – это типизация, но команды и проекты, к которым они применяются, типизированы быть не могут. Каждая команда – уникальна, ее окружение – уникально, ее проекты – уникальны. Зачем натягивать типовую методологию на нетиповой проект?
Менеджер проекта – не тот, кто применяет методологии, это тот, кто ведет команду к требуемому результату. Он не должен брать методологию, он должен найти свою, применимую в конкретном контексте. И он должен быть готов к внезапному изменению контекста, следовательно, изменению своих подходов. Наши проекты переживали разные этапы своего развития. Было и срочное вытаскивание из кризиса, было и изменение архитектуры, иногда мы в спокойном режиме разрабатываем новую функциональность делаем рефакторинг. Если бы мы на всех этапах применяли одни и те же подходы к управлению, то мы бы захлебнулись.
Недавно мои ребята эмоционально обсуждали какую-то проблему. Как оказалось, один из разработчиков заявил о необходимости проведения рефакторинга, который отодвинул бы срок релиза на 2 месяца. Я решил уточнить причины необходимости проводить рефакторинг именно сейчас, когда ключевой клиент (крупная и очень известная компания) ждет от нас срочное обновление. Он мне сказал, что в коде много копипасты. На мое возражение о том, что сейчас это не является критической проблемой, он ответил: “Копипаста – главный грех в разработке”. Видели бы вы мои глаза в этот момент. Кто сказал, что это грех? И почему грех должен быть причиной, по которой мы можем подвести того, для кого мы вообще работаем – нашего клиента??? Программирование ради программирования – это не то, что нужно заказчику. Программирование – инструмент достижения результата.
Догматы в разработке не менее опасны, чем догматы в управлении проектами. И, поверьте, нарушить догму человека, который к ним склонен - очень трудное дело. Но это и есть работа менеджера проектов.
Догмы являются следствием недостаточности критического мышления. Это вопрос бессознательного каждого человека, результат его развития. Школа, семья, двор, институт, друзья, книги – все это в комплексе определяет склонность человека к принятию догматов. И вот он читает книгу в красивой обложке с надписью “Бестселлер” и изначально ставит под сомнение исключительно свои знания, не подвергая сомнению знания, изложенные в книге. А сомневаться нужно как в своих, так и в чужих знаниях. Личный опыт тем и отличается от догм, что он является результатом ошибок и рефлексии.
Таким образом, руководитель должен делать то, что принесет пользу проекту, будет неизменно приближать его к достижению цели. Соответствие подходов управления неким “правильным” методологиям является бесполезным, а иногда и откровенно вредным. Если руководитель своей целью видит “правильный менеджмент”, то проект, с высокой вероятностью, ждут серьезные трудности из тех, которые можно было бы избежать.