Почему проекты умирают. Понимание продукта менеджером
Эту тему начну издалека. Свою успешную карьеру инженера-разработчика я начал в конструкторском бюро, занимавшимся проектированием всякого добра для ракетно-космической отрасли. У нас там как-то сложилось так, что весь руководящий инженерный состав, начиная с главного инженера и заканчивая руководителями проектов, начальниками отделов и секторов, мыслил о продукте, отталкиваясь от его структуры и понимания логики функционирования.
Было вполне обыденным увидеть в кабинете начальника развешенные по стенам логические модели данных, схемы конструктивного деления, какие-то блок-схемы и все остальное.
Тогда мне это казалось чем-то естественным. Люди, управляя созданием чего-то, стараются понимать, как это что-то устроено и, соответственно, как этим можно управлять.
Позже, когда я познакомился с другими людьми, поездил по конторам, сменил работу, я с удивлением осознал, что стремление понимать продукт, созданием которого управляешь, не является естественным. Естественным является стремление к управлению - стать менеджером, руководить, командовать остальными. Особо не задумываясь над тем, что делаешь.
Естественно, что рано или поздно это приводит к определенной жопе на проекте, которую менеджер почему-то не решает погружением себя в тему. Обычно ее пытаются рассосать сперва накачиванием в проект дополнительных ресурсов, продолжают накатыванием феерической отчетности, а затем завершают изучением и внедрением всякой херни типа “бережливое производство”, “GTD”, “теория ограничений” и прочих модных буквосочетаний, по факту являющихся документированием традиционной логики мышления человека.
Заканчивается эта эволюция менеджмента дизайном смешных картинок про жопы и вывешиванием на стены всяких слоганов про то, что все равно всем будет пиздец, потому что Заказчик всё передумает.
Но мало кто начинает с того, чтобы сходить к офис менеджеру, попросить повесить у себя на стенке доску под маркер и начать рисовать свой продукт. Начать его понимать. Начать понимать его жизненный цикл с разблядовкой на циклы компонентов и выявлением взаимосвязей между всем этим делом и контекстом продукта в среде Заказчика.
К большому сожалению, большинство менеджеров на старте проекта и даже гораздо позже свой продукт представляют не на много в более структурированном виде, чем как на той картинке, которую я вставил в заголовок.
Я это к чему. Понять, что творится на проекте, можно по рабочему столу и стенам кабинета менеджера. Если там продукт, то всё будет хорошо. Если там демотиваторы про пиздец, то будет пиздец.
Всё очень просто.