Почему проекты умирают. Понимание продукта менеджером


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

Было вполне обыденным увидеть в кабинете начальника развешенные по стенам логические модели данных, схемы конструктивного деления, какие-то блок-схемы и все остальное.

Тогда мне это казалось чем-то естественным. Люди, управляя созданием чего-то, стараются понимать, как это что-то устроено и, соответственно, как этим можно управлять.

Позже, когда я познакомился с другими людьми, поездил по конторам, сменил работу, я с удивлением осознал, что стремление понимать продукт, созданием которого управляешь, не является естественным. Естественным является стремление к управлению - стать  менеджером, руководить, командовать остальными. Особо не задумываясь над тем, что делаешь.

Естественно, что рано или поздно это приводит к определенной жопе на проекте, которую менеджер почему-то не решает погружением себя в тему. Обычно ее пытаются рассосать сперва накачиванием в проект дополнительных ресурсов, продолжают накатыванием феерической отчетности, а затем завершают изучением и внедрением всякой херни типа “бережливое производство”, “GTD”, “теория ограничений” и прочих модных буквосочетаний, по факту являющихся документированием традиционной логики мышления человека.

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

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

К большому сожалению, большинство менеджеров на старте проекта и даже гораздо позже свой продукт представляют не на много в более структурированном виде, чем как на той картинке, которую я вставил в заголовок.

Я это к чему. Понять, что творится на проекте, можно по рабочему столу и стенам кабинета менеджера. Если там продукт, то всё будет хорошо. Если там демотиваторы про пиздец, то будет пиздец.

Всё очень просто.

Комментарии

Популярные сообщения из этого блога

Карта компетенции аналитика

Оценка эффективности работы руководителя проектов

Драйв