OpenPMO — Открытый Проектный Офис

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

Почему-то считается, что менеджер проекта может и должен вести одновременно несколько проектов. Возможно, но при условии, что не одновременно! Работу целесообразно делать полностью на ней сосредоточившись, и, получив пусть промежуточный результат, переключаться на другую задачу, сделав небольшую паузу. Никакой менеджер не сможет одномоментно разговаривать по нескольким телефонам, сидеть на нескольких митингах, читать несколько документаций или отвечать сразу не несколько писем. Непрофессионально выглядят люди, сидящие на митинге, отвечающие на почту в ноутбуке и одновременно чего-то делающие в телефоне — кто захочет попасть на стол к хирургу, или к зубному врачу, который чаще смотрит в свой телефон, чем на пациента.  

На проектах самым ценным ресурсом оказывается время. Часто приходится наблюдать, как менеджеры пытаются найти лучшее локальное решение, тратя на поиски драгоценное время. А что если решение буде не самым лучшим, а просто подходящим? И что лучше — выполнить работы в срок или найти решение, которое не факт, что окажется лучшим — ведь по ходу проекта многое меняется, выявляются новые факты, появляются возможности. Ценой перфекционизма, поиска чего-то совершенного часто оказывается невыполненный в срок проект, обманутые ожидания, серьезные финансовые и имиджевые потери. В поиске совершенства, которому нет предела,  надо уметь вовремя останавливаться.

Крупные компании обрастают неэффективными процессами согласования и принятия решений, порождая культуру безответственности. Оценка затрат на митинги, конференс-звонки, переписку показывает, что эти непроизводительные потери оказываются соразмеримы со стоимостью короткого авант проекта. Почему тогда не принимать быстрых решений и не делать коротких тест-проектов на деньги бесплодных митингов и согласований? В небольших частных компаниях так и поступают — лучше попробовать и пожалеть, чем не пытаться и жалеть. В крупных же организациях политический риск слишком велик. 

Модный в последнее время термин DevOps помимо гибкой разработки ПО, автоматизации тестирования и внедрения при гибком управлении инфраструктурой скрывает за собой еще и такую немаловажную деталь, как культуру в компании. В отличие от технических и технологических новинок о корпоративной культуре не принято говорить на конференциях и форумах, написано не так много публикаций. Тем не менее именно культура взаимодействия проектной команды как внутри так и с заинтересованными лицами оказывается наиболее ключевым фактором влияния на успешность проекта. Надо также понимать, что даже при очень высокой культуре взаимодействия на DevOps-проектах нельзя исключать риски конфликта интересов заинтересованных сторон.