Аккредитованная IT-компания
В реестре рос. ПО №18127 от 29.06.2023
Москва
Есть простой способ проверить, понимает ли человек, что такое руководитель проекта. Спросите, чем PM отличается от координатора или диспетчера. Если в ответ — «ну, он следит, чтобы задачи делались вовремя», перед вами не руководитель проекта. Перед вами диспетчер, который называет себя красивым словом.
Пётр Федюшкин пятнадцать лет прошёл путь от руководителя проектов до партнёра в AGIMA и приехал на наш митап с докладом, который можно свести к одной неудобной мысли: большинство проблем на проекте — это не про сроки и не про технологии. Это про то, что люди вовремя не поговорили. Всё остальное — техничка.
Большинство проблем на проекте — это не про сроки и не про технологии. Это про то, что люди вовремя не поговорили.
Пётр выделяет несколько вещей, которые отличают руководителя проекта от любого другого члена команды. Он единственный, кто формирует ожидания сразу для двух сторон — производства и бизнес-заказчика. Он отвечает за коммуникацию и документы. Он пропускает через себя все риски, как через фильтр, понимает, как они влияют на проект, и озвучивает их. Он умеет быстро принимать сложные решения.
И — ключевое — единственная сторона, в чьих интересах он эти решения принимает, это сам проект. Не заказчик, не родная компания, не команда. Проект.
Метафора, которую Пётр использует, — хранитель кольца из «Властелина колец». Герои несли кольцо через всё, что им мешало, пока не довели до конца. PM так же несёт проект — не как сторонник одного из «приобретателей», а как хранитель чего-то отдельного, почти аморфного, но требующего защиты.
Звучит пафосно ровно до того момента, пока не начинается следующая часть.
Как только всё «розовое и понятное» зафиксировано, в игру вступает то, что разваливает проекты изнутри, — компромиссы. Они появляются буквально на первый-второй час после старта.
Пётр сравнивает это с машиной из автосалона. В салоне она блестела и стояла идеально. Выехала — не едет, лампочка не горит, что-то стучит. И выяснить это всё до старта было либо нельзя, либо нужно было проявить больше осмотрительности. Проект — та же машина: про него узнаёшь самое важное только после того, как тронулся.
Компромисс — это когда вы отказываетесь от трудоёмкого, но правильного варианта в пользу доступного. Один раз, другой, третий — и проект уже едет не туда. Задача руководителя проекта — либо бороться с этими компромиссами, либо хотя бы очень хорошо осознавать каждый из них. Потому что неозвученный компромисс не исчезает. Он просто ждёт.
Неозвученный компромисс не исчезает. Он просто ждёт.
Если в докладе и был один тезис, который Пётр повторял чаще остальных, то вот он: успех проекта на 90% определяется тем, как организованы коммуникации. Как общаются люди, где у них точки фиксации требований, как они реагируют на изменения, на каких уровнях ведётся диалог.
Из этого вырастает целый набор практик, которые Пётр считает обязательными ещё до старта работ:
Анализ достижимости целей. Кивнуть на всё, что хочет руководство, — это первейший компромисс. Нужно честно проверить, реализуемы ли цели вообще.
Оценка вовлечённости стейкхолдеров. Причём с обеих сторон. На стороне агентства — действительно ли у ответственного будет время подключаться на сложных местах, и бьются ли цели, под которые подписывается проект, с тем, как он будет реализовываться (а то иногда хочется просто получить предоплату). На стороне заказчика — есть ли вообще доступ к человеку, который придумал проект. Если идеолога не видно неделями, это огромный риск: ожидания невозможно зафиксировать и контролировать.
Регламент встреч. Одного чатика недостаточно. Нужно описать, кто с кем и как часто общается: руководитель проекта с тактическим уровнем — раз в неделю, директора-подписанты — раз в три месяца. Кстати, про подписантов: Пётр каждый раз удивляется, когда директор агентства и директор клиента вообще ни разу не виделись, а проект уже идёт. Со стороны сервиса это просто вопрос вежливости и протокола — обозначить, что «нам важно, куда мы движемся, и от вас это тоже хочется услышать».
Презентация промежуточных результатов. Недостаточно отправлять итоги на языке своей технической команды. Заказчик зачастую не готов признать, что не понимает технологию (иначе бы сам всё сделал). Поэтому результаты нужно разжёвывать, а формат этого разжёвывания — продумать заранее.
И отдельно — момент, который Пётр называет самым страшным для проговаривания: нужно на старте зафиксировать, что заказчик видит в вас эксперта. Что вся вкусовщина — «что-то не торкает» — остаётся за бортом с момента, когда ударили по рукам. Экспертные аргументированные комментарии — да. «Не цепляет» — нет.
Один из самых практичных тезисов. Если на стороне клиента сидит человек, для которого это первый в жизни запуск сайта или приложения, скорость проекта нужно закладывать в два-три раза медленнее. Иначе ваш драйв просто обнуляется об его неопытность.
И если вы это не озвучили — значит, приняли. Пётр формулирует жёстко: не озвучил компромисс — взял его на себя, и теперь он будет преследовать весь проект.
Здесь же — одна из лучших историй доклада. Часто ответственного на стороне заказчика назначают ситуативно: владелец компании решил, что нужно «что-то прорывное», прошёлся по офису и назначил первого, кто подвернулся у кулера. Человек не хотел этой работы, испытывает стресс, о котором никогда не расскажет из лояльности, — и вот вы уже работаете с огромным неозвученным компромиссом. Решение Петра простое: спросить про опыт прямо. И если опыта нет — спокойно сесть рядом и показывать, где какую кнопку нажимать. Не в выгоду своей компании, а в сторону проекта. «У тебя ученический автомобиль, мы научим, потом вместе получим награду».
Не озвучил компромисс — взял его на себя.
Отдельный блок — про то, что заказчик физически не может адекватно прочитать проектные документы, которые компания вылизывала годами. Контракт в AGIMA эволюционировал все двадцать лет существования компании. Ждать, что неподготовленный человек поймёт его так же, — наивно.
Поэтому документы должны быть отражением реальных договорённостей, а не ловушкой. И их нужно актуализировать — не каждую неделю подписывать допники, но раз в месяц-два фиксировать на бумаге то, что изменилось. Без этого статус проекта на верхнем уровне быстро расходится с реальностью.
История из практики: руководитель проекта на стороне заказчика всё время кивал «да-да-да», а сам уже искал работу и ходил по собеседованиям. Он был готов согласиться на что угодно, потому что мысленно уже ушёл. Все эти «да» потом обернулись компромиссами, за которые пришлось отвечать.
Бич руководителя проекта — попытка сделать всё самому. Объём работы огромный, людей много, документы, изменения, фиксация — а тут ещё и желание всё проконтролировать лично.
Пётр честно говорит: когда начинаешь делегировать, часть задач будет сделана хуже — на 50, на 70%. Но в сумме сделано будет больше. И по-другому, потому что это люди со своим взглядом. Неумение делегировать — это потолок в карьере. Переход от «руководителя проектов» к «человеку, который управляет руководителями проектов» занимает года три-пять, и это, по сути, разные профессии — как программировать и управлять программистами. Нигде этому быстро не научат, только на практике.
На собеседованиях в AGIMA есть вопрос: какая лучшая мотивация для команды, которая превзошла ваши ожидания? Кандидаты называют зарплату, отпуска, оплату больничных. И почти все забывают про простую благодарность.
Оказывается, многим руководителям тяжело сказать команде «спасибо», а многим сотрудникам — признать, что им это нужно. Пётр начал практиковать формулировку «мне нужен подтверждённый знак одобрения» — звучит нормально и ломает любые заборы. Вообще проговаривать вслух то, что тебя волнует, — это нормально: озвученное можно обрабатывать, невытащенное копится.
И отдельно — про пример. В мотивации команды важно быть примером, а не декларацией. Если остаёмся до конца ради срока — остаёмся все. Если лишаемся премии за провал — лишаемся все, а не считаем свои интересы выше остальных.
Финал доклада — про серию австралийских плакатов по технике безопасности. На одном парень говорит: «Я был новичком и боялся спросить». На другом девушка: «Я боялась показаться глупой, если переспрошу». На третьем: «Я думал, проскочит».
Пётр отправлял эти плакаты новым сотрудникам на онбординге с простым посылом: если ты не спросил и не уточнил — это твоя зона ответственности. Здесь нет статусов, нет «ты теперь супермен и должен решать всё сам». Есть возможность переспросить — переспроси.
Потому что иначе работает другая логика — «и так сойдёт». А результат у неё всегда один.
Если не спросил и не уточнил — это зона ответственности.
Для PM, которые читают это для себя: в зале был вопрос — если все эти навыки (коммуникация, документы, планирование, самодисциплина) хромают, с чего начинать? Ответ Петра: чаще всего хромает не навык, а то, что люди просто не договорились — внутри команды или с заказчиком. Прозрачно договориться с собой и сторонами — это и есть точка входа.
После доклада разговор вышел за пределы одного проекта. Если компромиссы, молчание и «и так сойдёт» ломают работу изнутри, то сжавшийся рынок делает эти ошибки слишком дорогими. Поэтому дальше на круглом столе обсуждали рынок, команды и влияние ИИ на агентства.
Материалы серии
01 - «И так сойдёт» не сойдёт: почему проекты разваливаются ещё до старта
02 - Рынок качнулся в обратную сторону: кого студии теперь оставляют, а с кем прощаются
Автор статьи
Теги
Понравился материал?
