Зачем в AGILE нужны проектные менеджеры?
Проектные менеджеры воспринимаются сегодня как must have для команды разработки. Но давайте разберемся, так ли они необходимы в AGILE-командах и есть ли от них польза?
Ни у кого не возникнет вопроса, зачем в команде присутствуют сами разработчики 😁. Польза QA менее очевидна, многим девелоперам может казаться, что уж они то пишут код без багов (что, конечно, не так). Тем не менее бывают команды и без QA. Но зачем команде нужен PM? Может ли команда работать без него? Достаточно ли курсов, чтобы стать хорошим PM? Попробуем с этим разобраться.
* Disclaimer: далее мы будем рассуждать исходя из роли PM в AGILE проектах. В Waterfall проектах роль PM может отличаться. В рамках этого текста, мы не будем анализировать waterfall.
Когда я начинал карьеру проектного менеджера, мой приятель спросил меня, как отнеслась ко мне команда. Многие PM-новички сталкиваются с тем, что команда относится к ним как к пятому колесу — лишь бы оно не тормозило всю машину. Многие, особенно опытные разработчики могут не видеть пользы в этой роли: как человек, который не умеет программировать, возможно моложе меня, может управлять моей работой и говорить мне что делать?
В чем польза PM?
На самом деле, от команды разработки требуется не код! Сам по себе код не стоит ничего. От команды требуется решать конкретную проблему конкретного клиента. Но как узнать, что это за проблема, понять как ее решить, или можно ли решить ее в одиночку? Легко ли распределить работу (в том числе тупую и рутинную) и не поссориться, когда окажется, что софт не работает или делает не то, что хотел заказчик? А еще, неплохо было бы в отпуске слетать на Мальдивы с семьей, и чтобы клиент не звонил через каждые 10 минут.
В разработке ПО, как и в повседневной жизни, есть много невидимой глазу работы. Когда вы приходите домой с работы, оказывается, что дома ждет “вторая смена”. Нужно навести порядок, приготовить еду, убраться и т.д. — за комфорт дома приходится платить временем. Причем это время в данном примере имеет вполне понятную стоимость — вы можете нанять клининг для уборки и заказать еду в кафе. При этом, часто час рабочего времени, потраченного на приготовление пищи стоит намного больше, чем еда из кафе. В рабочих задачах все то же самое: для решения задачи всегда нужно проделать много “подкапотной” работы (часто невидимой). Если этого не сделать, время утекает сквозь пальцы:
- бесконечные созвоны;
- переделки уже сделанной работы, потому что клиент ее не принял;
- увольняются разработчики, нужно искать новых;
- клиент ругается и не хочет платить.
В общем, проект разваливается так, что и код писать некогда.
И вот тут может помочь PM, который экономит время команды на переговоры, берет на себя функцию проксирования интересов заказчика, интерпретирует требования в понятные для команды задачи, решает организационные и административные вопросы, помогает решать конфликты внутри команды и поддерживать ее здоровье. Разберем на запчасти его работу.
Команда мечты
Итак, в Agile основной профит приносит команда. Команда — не просто набор случайных людей примерно, соответствующих по квалификации решаемой задаче, а слаженный механизм или, если угодно, экосистема, единый организм. Да, необходимое условие работы команды — это наличие людей обладающих нужной квалификацией. Но достаточное условие команды, которое обеспечивает максимальный перфоманс — это самовоспроизведение. Это тема достойна отдельного текста. Тут важно отметить, что объединить людей, сплотить, мотивировать, поддержать, в конечном счете, сделать так, чтобы каждый чувствовал ответственность не только за себя, но и за всю команду — это большая и сложная работа.
Во-первых, скорость группы при решении любой задачи всегда определяется скоростью самого медленного ее участника. Способность команды поддержать, разгрузить, научить, подставить плечо, наконец тому кто устал (а устают все, не только junior developer) определяет среднюю производительность команды.
Во-вторых, распределяя работу внутри команды не директивно, а обсуждая ее внутри, мы как бы увеличиваем ценность такой команды. Когда каждый участник уверен, что его мнение важно, он проявляет инициативу: подсвечивает места в коде, которые можно улучшить, дает фидбек по неудобным процессам, берет на себя более сложные задачи и т.д. Для команды это означает меньшее количество багов, архитектурных ошибок, больше оптимальных нестандартных решений и т.п. Если же строить процесс наоборот — “назначать” задачи, то мы получим не участников команды, а исполнителей, а результат у такой группы будет ниже, чем у слаженной команды.
Наконец, команда, являющаяся системой, способна к саморегулированию. Если какие-то процессы из книг “по классике” не работают, команда сама в состоянии проанализировать, подкрутить или заменить то, что мешает. Так организм способен бороться с инфекциями. Иммунитетом в случае с командой как раз является слаженность — чем она выше, тем сильнее иммунитет и выше перфоманс.
Что нужно, чтобы построить такую команду? Опыт и эмоциональный интеллект. PMу нужно чувствовать атмосферу в команде, управлять настроением внутри, знать про каждого своего сокомандника, насколько он вымотан, встревожен, счастлив. Еще нужна внутренняя энергия, которую неизбежно придется отдавать команде для создания этой самой атмосферы. Этому нельзя научить. Можно читать бесконечное количество книг и статей, но это навык, который приходит только через время, опыт и рефлексию.
Экономия на коде
Как ни странно, проектный менеджер может существенно сократить количество работы в команде: избежать переделок по запросу клиента и оверхеда на то, что не пригодилось (или не просили делать). Речь про работу с ожиданиями клиента и описанием требований.
История про то, что клиент старается впихнуть как можно больше в скоуп работ является классикой и объясняется принципом максимизации полезности из микроэкономики. Если никак не работать с этим, обязательства, взятые на себя командой вынудят работать в пожарном режиме. Это неизбежно приведет к стрессу, усталости и конфликтам внутри.
Необходимо четко представлять, чего именно хочет заказчик и каковы его цели (иногда бывает так, что требования отдельных фичей не приближают, а отдаляют клиента от его целей, при этом клиенту это не очевидно), и что из этого команда в состоянии сделать без перенапряжения. Единственный способ выяснить это — словами через рот (ну или буквами через текст).
Важно найти правильные слова для клиента и для команды. Смещение фокуса от оптимального состояния загрузки команды как в сторону пожеланий клиента, так и в сторону команды бьет по репутации команды. Если запланировать мало работы, клиент останется разочарованным и будет искать других разработчиков, а репутация команды ухудшится. Если же взять на себя больше, чем нужно, придется работать в состоянии стресса, что-либо приведет к конфликтам и в долгосрочной перспективе (если так будет постоянно) к тому, что разработчики будут уходить, либо к факапу, если команда не выполнит обязательств, что также будет ударом по репутации. Так или иначе в долгосрочной перспективе это фейл.
Но точно определить скоуп это половина дела. Еще необходимо правильно описать требования, иначе ожидания от фичей не совпадут с действительностью. Тогда работу придется переделывать. Для точного описания необходимо в первую очередь действительно понимать как цели заказчика, так и конкретные задачи. В этом поможет навык коммуникации в широком смысле. Этому также нельзя научить, только бесконечно шлифовать его анализируя обратную связь со всех сторон.
Время — деньги
Ну и самое, пожалуй, очевидное, чем может помочь PM команде — сберечь время. Время на общение с заказчиком, время на планирование и приоритизацию, уточнение требований у клиента, время на выяснение отношений внутри, время на споры. Время на анализ проблем и подготовку решений.
PM не сможет полностью избавить команду от коммуникаций с клиентом (останутся вопросы по реализации, технические споры, уточнения неясных моментов), но сможет уменьшить непродуктивно потраченное время, где-то сократив созвон, уменьшив количество участников, переключив на себя внимание чересчур активного заказчика.
Одна из, пожалуй, самых важных частей работы PM это коммуникация в широком смысле слова. В контексте пользы для команды необходимо превосходно коммуницировать с заказчиком и разработчиками, находить общий язык, понятно объяснять, понимать цели, намерения и мотивацию людей, знать и учитывать личные проблемы. В противном случае результат будет противоположный.
PM может уменьшить тупняки за счет грамотного оркестрирования задач и процессов внутри, используя бережливое (Lean) производство в команде и расшивая узкие места (bottlenecks). Оптимальные процессы внутри проекта помогают меньше спотыкаться друг об друга и быстрее находить и решать проблемы. Тем самым команда дает высокую производительность при меньшем напряжении. А процессы нужно продумать, выстроить и отладить — это тоже работа.
Все это: коммуникации, оркестрирование, настройка процессов — это навыки, которые приходят только с опытом. Польза от теории без широкой практики тут минимальна.
Почему курсы не заменят реальный опыт
Все что мы обсудили выше, может развиваться как в сторону уменьшения оверхеда команды, так и в сторону его увеличения.
Представим себе ситуацию (надо сказать, довольно распространенную), когда новоиспеченный PM после курсов приходит в команду разработчиков. Команда набрана из людей, не работавших ранее друг с другом. PM начинает строить процессы по канону, команда сопротивляется. У PM недостаточно авторитета (команда чувствует, что нет опыта), аргументов, он не может предвидеть последствия тех или иных решений.
Начав настраивать процессы по SCRUM среди людей, которые не разделяют ценности и не видят пользы, в команде, которая не объединена общей целью — PM получит скорее эффект обратный.
Если команда разнородная как по скиллам так и по специализации, не видит пользы и не работала раньше с процессом “Покер планирования” или не понимает в чем ценность оценки задач в Story points, то результатом внедрения будет лютый оверхед по времени при полном отсутствии прогресса. Польза от такого процесса будет отрицательной. Хотя для зрелой и слаженной команды мы сможем с помощью этого повысить точность оценок задач и предсказуемость продуктивности в спринте.
Наконец при взаимодействии с заказчиком, единственное что сможет сделать такой PM пойти на поводу, выйдя далеко за рамки возможностей команды, что неизбежно приведет к факапу.
Без опыта новоиспеченный PM будет раскатывать теоретические знания на команду, совершенно не представляя какой результат должен получиться в итоге. Ему будет крайне сложно найти аргументы, переубедить коллег и прийти к какому-то общему решению в силу отсутствия понимания сути проблем. С людьми будет происходить неладное. Сроки будут гореть, заказчики — орать.
Ноу хау Mad Devs в части получения PM-ами драгоценного опыта — это внутренние проекты направленные на разгребание “организационного долга” компании. Mad Devs последний год активно перестраивает внутренние процессы. Мы запустили внутреннюю LMS систему, стали появляться различные комьюнити, цель которых обеспечить непрерывное развитие сотрудников. У нас есть внутренняя команда CTO которая обеспечивает высокий технический уровень проектов. Собственно, это отдельные некоммерческие проекты со своими Jira, задачами, OKR-ами и дедлайнами, в которых всегда участвует кто-то из “старших товарищей”, способных подсказать и направить. Если начинающему PM-у не хватает опыта, внутренние проекты Mad Devs — это отличный способ для старта, одновременно приносящий компании пользу и снижающий риск неудачи в коммерческом проекте.
Что в итоге?
Мы не говорим, что курсы это зло. Они дают представление о роли PM, знакомят с инструментарием, основами процессов и т.д. Но было бы странно рассчитывать, что они хоть как-то заменят опыт, который в работе PM все же является ключевым.
Итак, PM в команде занимает место нервной системы внутри организма. Он обеспечивает плавность движений, задействовав различные группы мышц в нужной последовательности, сигнализирует об усталости и болезнях, ищет оптимальные способы решения задачи и многое другое. Созвоны должны занимать ровно столько времени сколько необходимо, задачи должны быть понятными, а сроки реальными. Клиент должен писать команде о том, как круто они поработали (а не говорить, что все пропало). PM является таким же членом команды как и дизайнер или QA, он выполняет свои задачи для того, чтобы достичь общую цель — сделать счастливым клиента.
Тем же кто только присматривается к работе PM хочется сказать, что идеал всегда недостижим. Не стоит рубить с плеча, оказавшись в команде (она как-то работала и до вас). Стоить понять и прочувствовать, чем живет команда, какие у нее болевые точки и заняться их системным лечением. Постепенно команда почувствует пользу и примет вас к себе первым среди равных.
