Comments 13
Я бы еще сказал что на таком уровне становится необходим кросс-тренинг. Невозможно жить устойчиво в ситуации, когда PM/деливери тянет одеяло в одну сторону, а техлид/тимлид в другую. Заставляйте менеджерскую и техническую сторону читать не только свои книжки, но и книжки друг друга. Лид должен понимать ограничения внешней среды, которые персонифицируются в проекте его ПМ-ом. Проджект должен понимать технические и организационные ограничения, которые персонифицирует тимлид. Плюс должна быть открытая и честная обстановка на проекте. Если менеджмент хочет отманипулировать лидом, не раскрывая причин желаемых изменений, или наоборот — лид хочет манипулировать менеджером скрывая проблемы в команде или в процессе — это ни к чему хорошему не приводит.
В операционной есть хирург, и есть анастезиолог-реаниматолог. Они отвечают за разные части процесса, но жизненно (для пациента!) важно, чтобы они имели одно и то же базовое видение того, чем они заняты — и понимали проблемы и сложности друг-друга.
В ведении проекта — ровно то же самое: обеспечивайте общее базовое образование и понимание проектной деятельности, убирайте стимулы и KPI которые стимулируют перепихивание ответственности, заставляйте лидов участвовать (хотя бы слушать) решение бизнесовых вопросов, а менеджеров разработки — аналогично в технических. Это не быстрый процесс, но постепенно ситуация должна улучшаться...
Надо начинать с четкого разделения обязаностей, ответственности и полномочий. Хотя бы простая RACI матрица, которая со всеми сторонами согласованна.
Это может как помочь, так и навредить. RACI-матрица является хорошим инструментом анализа или проектирования коммуникаций — но она точно не является инструментом разрешения конфликтов. Потому что в жизни полномочия сторон не лимитируются буквами в матрице. Есть ресурсные взаимосвязи, есть внешние ограничения которые персонифицируются человеком на конкретной должности… Понятно, что если все хватаются за любой рычаг и крутят любую ручку — это плохо, и оно так не заработает. Но с другой стороны, от чрезмерного разграничения полномочий и закрепления ответственности — лучше не становится. Ну да, у любой стороны после этого четкого закрепления появляются железные аргументы почему они делают так, а не иначе. Но проект от этого железного стояния никуда двигается (или двигается на горизонтальных связях которые игнорирует матрица RACI).
Сори, но не согласен. Любые правила, в том числе и кто за что отвечает - должны быть зафиксированны. Отсутствие таких фиксаций и ведет к конфликтам, так как каждый решает, что это его право/привелегия/обязаность/долг принять решение.
На примере, который описан в статье: проджект говорит, что надо катить продукт на прод, а тимлид, что надо рефакторить. Из-за того, что непонятно, кто решает, едет ли релиз и возникает конфликт. А было бы зафиксированно, что (условно) ПМ принимает решение о выкатке релиза на продакшен, то вся ответственность на нём. Он должен выслушать аргументы тимлида на счет рефакторинга, взвесить риски и принять решение - катим или нет. Упадет прод - виноват и отвечать будет ПМ.
Это довольно типичный для экс-СССР взгляд на проблему, где назначением ответственного история как-бы заканчивается. Как говорил Лазарь Моисеевич — у любой аварии есть фамилия, имя и должность.
Теперь давайте посмотрим на вопрос шире. Допустим, вы дали клеточке с надписью PM право решать, выкатывать релиз или нет. Как вы собираетесь искать людей в эту клеточку, чтобы они принимали безошибочные решения? Трагедия управленческой традиции экс-СССР заключается в безоговорочной уверенности что назначенные решать люди — обладают сакральным знанием и сверхспособностями только потому что их назначили ответственными. В то время, как в реальности этого не наблюдается.
Следующий момент — допустим, выкатили релиз в прод под ответственность PM, а он упал. Можете сколько угодно делать ответственным PM, но он сам релиз не поднимет и не откатит — это должна делать команда. И тогда в чем скакральный смысл делать PM ответственным за выкат релиза — если реальную ответственность (в смысле устранять последствия, а не получить выговор на бумажке или снятие с должности) несет не он ?
Я настаиваю, что в случае конфликта катить на прод или рефакторить — спасает только кросс-тренинг и наличие общей целевой установки: предприятие должно жить и кормить сотрудников. Тогда есть какие-то шансы что вопрос будет решен в интересах дела (и придется принимать дополнительные обязательсва как менеджменту так и команде). Любые "жесткие" закрепления ответственности тут скорее выльются в прикрытие задниц и проигрышу всех разом из-за неудачного завершения проекта.
Все еще зависит от стилей управления одного и второго + взаимодействия с заказчиком. Регламенты, которые четко разделяют роли должны быть, но, кмк, на каждом из проектов и ПМ и ТЛ должны в тч проявлять гибкость, но только, если эта гибкость будет согласована между ними.
Вы слишком утрируете кейс.
Если ПМу сказал Тимлид, что надо рефакторить, а то упадем. Но ПМ его не послушал и все упало - ПМ дурак, ему говорили, не слушал. Если не научится на этой ошибке - гнать такого ПМа в шею.
А может ПМ принял решение катится, так как сроки дико поджимали и был риск потерять ключевого клиента и риск вылететь всей компании в трубу. И после выкатки было все ок, так как тимлид перфекционист (и ПМ это понимал) и просто хотел сделать 25-й рефакторинг и так нормального кода (тут уже гнать такого лида :)
Принимать решение о выкатке, естественно, надо компетентному человеку. Конечно, тот кто принимает решение должен обладать многими скилами, как с технической стороны, так и процессной и бизнесовой.
В реальной ситуации, без ответственного человека, всё это работает в утопическом Скраме самоорганизованной команды. А реальности (я такое видел), когда ПМ и Маркетинг говорили, что надо катить скорее, QA лид просил провести очередной регресс, тимлид хотел переписать очередную библиотеку, дизайнер изменить фронт на более классный, в результате ничего никуда не ехало и клиент рвал и метал, так как не понятно было, кто за что отвечает и все давили своим авторитетом и что записано у них в должностной инструкции.
Проблема заключается в том, что в вашей технологии управления — кого выгнать, а кого нет — это пост-знание. Оно появляется тогда, когда событие уже случилось (или наоборот, не случилось). Допустим в конкретном случае решили что лид перестраховался и его выгнали. Как вы собираетесь искать нового человека под должность лида, и как вы собираетесь гарантировать что он будет принимать правильные решения? "Перебдеть в обратную сторону" очень легко. Забиваем на рефактор, удовлетворяем желания PM. Потом код начинает разваливаться — техдолг и все такое. Снова уволим лида? Но код-то от этого лучше не станет!
Я не понимаю, почему в советских управленческих кейсах мораль истории заканчивается на том, что кого-то уволили (в зависимости от эпохи, вариант — расстреляли). Ну хорошо, для уволенного она закончилась — но для предприятия-то нет! Теперь надо откуда-то брать ресурсы и людей, чтобы исправлять проблемы...
В этом смысле я не идеализирую западную методологию с ее культом команды и постоянными совещаниями. Но она четко понимает, что нельзя замыкать решения на одном человеке просто потому что его потом можно уволить: человек уйдет, проблемы останутся. Там делается упор на методологию, которая позволит НЕ совершать ошибок и использовать для принятия решения экспертизу всей команды.
вы опять очень близко примеряете выдуманный кейс к реальности.
И ПМ, который не слушает советов и в одиночку решает катиться на прод, и тимлид, который делает 25-й рефакторинг, до своих должностей просто не дойдут в нормальных адекватных компаниях.
Такие проблемы не появляются из ничего, всегда есть более мелкие предпосылки, которые отсеивают некомпетентных людей.
Это был бы хороший ответ, если бы как во времена СССР примерно большинство начинали с должности рабочего, и постепенно двигались наверх. По факту, на рынке ИТ уже который год дефицит высококвалифицированных кадров. Предложите методику, как с рынка нанимать PM и Lead которые бы занимали позиции "под личную ответственность" и принимали бы правильные решения ?
ой, дублированный комент отправил
Мне кажется в статье сразу чуток неверно выставлены акценты. Начнем с ответственности. ПМ отвечает за проект в целом. За все. Бюджет, риски, сроки, качество ... за любой фейл ПМ может получить втык. И поэтому, так как отвечает за все - он главный.
Тимлид - один из многих. Ну реально. В проекте может быть архитектор, куча аналитиков, тестировшики со своим лидом, девопс, заказчик, еще 5 людей, которые мнение имеют и хрен их объедешь (безопасность, юристы, другие подразделения), спонсоры. ПМ общается со всем этим кагалом или иногда делегирует кому то.
Тимлид отвечает за "производство" на своем участке. В проекте может быть еще 5 тимлидов, к примеру. Или 10, из них три - это внешние конторы за реальные бабки. Никаким проектом он не управляет :). Исключение - мини-проекты на одну команду.
Это важно, потому на одной доске они могут стоять только в чем-то маленьком и малоинтересном :)
Чтобы понять, откуда могут быть конфликты, надо понять что кому надо. Тут все в реале просто. Тимдид возглавляет команду, которая дает оценки и закрывает тикеты, делая изменения в коде. Для ПМа причина конфликта может быть либо в срыве сроков, либо в плохом качестве решения (большое число багов, переоткрывающиеся баги, ...). Тут человечество вроде как нашло способ. Делаем root cause анализ и после локализации исправляем. Иногда вплоть до выбрасывания кого-то за борт. Насколько ПМ может выполнить и/или делегировать эту задачу зависит от его квалификации.
В обратную сторону ... а с чего. ПМ не репортит лиду от слова совсем. Сорян, не по чину и позиции :)
Теперь по примерам.
Первый. Если у вас в последнюю неделю выяснилось, что есть куча рефакторинга, вопрос один - у почему до того это не озвучено? Это чисто для понимания, что кризис начался намного раньше. За неделю ясен пень можно сделать немного. Поэтому либо закругляемся, и молимся чтобы прокатило, либо просим сдвинуть сроки. Чего тут еще? Потом можно полученный пендаль поделить на всех
Второе. Главнее ПМ. Точка. Но лид может иметь вес в организации, поэтому это проблема ПМ в данном случае. Как в паре режиссер-главный актер. Отношения строим сразу и до конца проекта. Можно и иногда нужно для начала конкретно посраться. Если лид не "звезда" - смотри первое предложение.
Третье. Они планируют разные работы. Если потом оценки тимлида сильно отличаются от реальности - разбираемся. Возможно неверно оценен весь прлект, кртвая архитектура или слабый агалитик. Надо искать причину. А конфликта тут в целом нет вообще. Либо ПМ слабо понимает, что такое планирование проекта.
Четвертое. Риски все на ПМ. Но по каждому риску он обращается к экспертам. ПМ не эксперт и не его задача спорить с экспертами. Сорян, тут не конфликта. ПМ не должен на себя брать функции эксперта. Это не его зона ответственности
Пятое. Вообще нет причин для конфликта. Спокойно учимся, набираемся опыта и всего, чего можна унести. В конце либо надо свинтить, если проект мертвый. Потому что если ПМ делает мертвый проект - он идиот :) Если не мертвый - ну так берем и делаем
P.S. В целом ощущение, что автор имеет опыт работы в мини проектах. И только :(
Заклятые друзья: почему проджект-менеджер и тимлид всё время ругаются