К основному контенту

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


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

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

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

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

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

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

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

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

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

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

Комментарии

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

Драйв

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

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

Проект - он как лестница. По нему надо карабкаться вверх, к результату. Не надо вокруг него прыгать. Это бессмысленно.

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

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

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

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

По сути эти категории образуют слоеный пирог, в основе которого лежат теоретические знания. На основе знаний аналитик пытается что-то сделать и приобретает опыт. Опыт оттачивает навыки, что является основой и движущей силой развития специалиста: нау…

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

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


Постановка задачи

Необходимо оценить эффективность работы руководителей проектов, выполняющихся по схеме time & material. Сразу оговорюсь, что на мой взгляд предлагаемая методика подходит и для схем fixed coast.

Цель оценки – понять, кто успешно ведет проект самостоятельно, а за кем надо попристальнее присматривать.

Критерии успешности хода проекта:
• Соблюдение бюджета
• Соблюдение плана выполнения проекта
• Отсутствие критических проблем, способных зааффектить бюджет и календарь
• Удовлетворенность Заказчика (субъективно, по отзывам)


В чем идея 

Идея основывается на еженедельной оценке хода проекта по трехбальной системе: красный (проект идет неуспешно), желтый (есть риск завалить проект в красную зону) и зеленый (проект идет успешно).

Успешность проекта оценивается по критериям, изложенны…