А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

Ivan Zimin Head of pre-sales division в IT-Solutions 10.02.2016 18:26

Воу-воу-воу! Палехче!:))
Не было на месте пару дней, уже забросали какашками:)
Ну что ж, давайте буду отбиваться одним постом от всех.

General:
Мне кажется, что не все правильно поняли дилемму в сабже. Если её перефразировать, то я получаю следующий вопрос: Нужны ли глубокие знания и/или опыт в разработке для современного PM’а в SWD? Мой тезис для холивара — НЕТ.
Разъясняю:
Роль PM — это не про предметную область, это про процессы и людей, это про эстимейты и выполнение их, это про коммуникацию с Заказчиком и командой.
Глубоки знания или опыт в разработке — это круто, но они имеют несколько существенных минусов:
1) Как бы это было не обидно, но знания и скиллы устаревают со временем. А времени на поддержание их в актуальном состоянии не будет
2) ~~Применение этих знаний и скилов~~ неосознанная попытка оценить проект, проверить компетентность кодера/тестера/"коготоещё" основываясь на собственном опыте будет приводить как к ошибкам, так и к демотивации команды.
3) Попытка погрузится в subject domain будет нести ущерб процессам, коммуникациям и остальным обязанностям РМ’а
Другими словами, два РМ’а (один с опытом разработки, другой без) будут одинаково эффективно вести проект, т.к. знания не где будет применить. Для применения знаний есть команда со своим тимлидом.

Теперь попробую тезисно ответить на отдельные выпады (обобщённо):
1) Запуск миссии на Марс/Строительство моста/подготовка и полёт на Луну.
Тут многие забрасывали мне предложения поруководить проектами разными и всем я отвечал — Да. Я способен реализовать эти проекты при наличии адекватного спонсора и реальной связки бюджет-срок-объём.
На вопрос как оценивать бюджет-срок-объём: объём — с Заказчиком; срок -с командой; бюджет — согласно установленных правил и опираясь на предыдущие два пункта.
В подтверждение своих слов, я могу привести вам один пример из жизни, когда мы ввязались в проект по построению ВКС для досудебных следствий. Кроме прочего, в проекте присутствовал такой кусок, как Поставка вандалостойких Видеотерминалов с определёнными параметрами (если вкратце — моноблок; металический корпус; калёное стекло; согласованная связка ВКС и централизованное управление). Эти терминалы сейчас стоят в большинстве СИЗО Украины. Это было даже круче строительства моста или полёта на Луну, ведь мосты строили, а на Луну уже летали (если верить NASA:)), а такого опыта ни у кого в Украине не было. Более того, под этот кусок уже был понятен бюджет, больше которого нельзя выделить. Но мы справились, вложились в бюджет и сроки. Естественно архитектуру и дизайн рисовала команда с привлечением меня для декомпозиции, координации и планирования. После создания демообразца и утверждения его был запущен процесс очень схожий с Waterfall’ом, но модифицированный в виду жёстких сроков и низких требований к документации. Параллельно работало несколько команд (производители корпуса; закупка, сборка, инсталляторы). На выходе — у меня, в качестве кейса, есть успешный проект по HW Development’у и да, я не имел и не имею глубоких знаний в предметной области как металла, так и совместимости компьютерных комплектующих.
2) Теперь по поводу:

Ну и на кой ляд такой нужен? Что он будет заказчикам говорить? А разрабам? Заказчики закажут за 3 дня полет на Луну сделать, не понимая, он согласится. Что разрабам скажет? Рисуем и полетели?

Ну глобальный вопрос на кой ляд нужен РМ — это ближе к философии. Но тогда придётся задаться вопросом и об остальных не разработчиках: тестеры, бухгалтеры, уборщицы и т.д.
А в вопросе об испорченном телефоне — это не совсем так. Действительно грамотный РМ никогда не даст эстимейт, не согласовав его с командой! Ведь какой бы технически подкованный не был РМ, в любом случае делать команде. Есть тим-лид, есть команда, есть этап инициации проекта, на котором все потенциальные участники или, если проект большой, руководители структурных единиц собираются и грубо оценивают объём работы и затраты. После этого совещания начинается магия PM’а, который сводит это всё в сложные проектные документы и выдаёт своё решение на Заказчика.
Но есть ещё другое утверждение, это не совсем к РМ’у, это ближе к продажам — Нет ничего не возможного. И на Луну можно улететь за три дня (достаточно купить уже готовую к старту ракету, вопрос только в деньгах), и мост можно построить за три дня (по-крайней мере, инженерные войска готовы под этим подписаться).
3) @Viktor Chyzhdzenka, почему-то постоянно ссылался на то, что РМ’у без релевантного опыта (мы вроде как согласовали, что это опыт разработки) можно

Им с 3 короба наврешь и делай с ним, что хошь

Ну если опустить отсутствие ответа на мой вопрос Зачем это делал Виктор, а взять этот тезис за истину, которая широко распространена, отвечу — как команде с РМ’ом, так и РМ’у с командой надо дружить. Проверить враньё в эстимейтах или занятости очень просто (пообщаться с «обманщиком» и, потратив время, попытаться с ним декомпозировать его обещания до простых и доступных всем вещей, чтобы иметь возможность оценить реальность его эстимейтов. Или обратиться за помощью к тим-лиду/другому РМ с предположением, что сроки завышены, и просьбой подтвердить их...да множество способов). Так вот вопрос: как дальше работать команде с человеком, который намеренно филонит и завышает эстимейты?
Если честно, я всё-равно, никак не могу понять, как команда, работающая в проекте, может быть не заинтересована? Люди, которые приходят отсиживать свою ставку в офисе, кроме того, что отравляют коллектив (ведь соседям то виднее), так ещё и начинают деградировать (ведь вряд ли находясь в офисе и имитируя огромную загрузку, человек будет заниматься самообразованием)

4) Ну и вроде последний вопрос: Что должен делать PM на этапе Design (из SDLC).
Давайте согласуем, что дизайн это этап, который начинается после согласования и осознания требований Заказчика и заканчивается документом (иногда на бумажке :)) с описаниями как продукт будет выглядеть и как будет работать.
Так вот, на этом этапе, задача РМ запланировать и провести одно/ряд совещаний с требуемыми участниками последующих процессов для достижения результата (иногда на бумажке:)).

Вроде никого не упустил, если кому не ответил — напомните о своём вопросе, будем дискутировать дальше ;-)

З.ы. я понимаю, что в

99% наших контор — PM, это одновременно и тим-лид и архитектор и сеньор девелопер...

..я думаю, что цифра существенно завышена, такого быть не должно и эти «монстры» (я про PM’о-лидо-архитекторо-кодеров) будут отмирать и либо квалифицироваться во что-то одно, или будут востребованы только в «шарашко-лавках», менеджмент которых не может/понимает/хочет платить за экспертов.

З.ы.ы. я считаю, что каждый должен быть профессионалом в своём деле. А профессионал — это понятие широкое: и знание предметной области, и уважительной отношение к пересекающимся областям, и желание делится знаниями с «младшими», и совместное стремление в достижении целей компании/дирекции/команды, да и много ещё чего.

А ты понимаешь, что PM в SW-development’е и в строительстве — это один и тот же человек?

Схожі топіки

113 коментарів

Підписатись на коментарі