10 шишек на одном проекте. Опыт PM’а

Как говорится, не ошибается только тот, кто ничего не делает. РМ’ы, увы, ошибаются и делают это с размахом ;)

В этой статье хотел бы рассказать об одном проекте, на котором я набил большое количество шишек. После множества Root Cause Analysis’ов, опыта работы в нескольких компаниях, было время и разобраться, проверить извлеченные уроки на практике и оценить ситуацию со стороны.

Все имена и названия — вымышленные. Любое совпадение случайно.

О проекте

Обратился к нам старый клиент. Назовем его Епифан. Деталей на тот момент было мало, но до этого у нас с ним были очень хорошие отношения и несколько успешно выполненных проектов по fixed price, которыми я честно горжусь до сих пор.

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

Старт

Стало известно, что это стартап, цель которого — решить проблему бюрократии в медицинской сфере и существенно ускорить процесс сбора информации. Интересно? Еще бы! Технологично, сложно, стильно, модно, молодежно.

Также стало известно, что система уже «кое-как» сделана другими подрядчиками, назовем их команду FIM. Этим «кое-как» клиент Епифан сильно недоволен. Со слов Епифана стало также известно, планируется весь проект передать на разработку нам и полностью прекратить сотрудничество с FIM, как только мы, новая команда (назовемся WOW), будем готовы вести проект самостоятельно. Нам предстояла передача знаний, и первым условным заданием на старте было покопаться в коде, посмотреть, что же там коллеги из FIM сделали, как обстоят дела в архитектуре.

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

Шишка 1. РМ должен выяснить до мельчайших деталей, почему клиент решил сменить провайдера

Это инструмент РМ’а в будущей работе. Зная детали и учитывая их, можно не допускать тех же ошибок, из-за которых клиент решился на смену команды. Мы четко знали, что будем пилить проект самостоятельно, как только будем готовы. На том этапе у меня не возник вопрос, а как определить готовность, и одинакова ли она у нас с клиентом?

Шишка 2. РМ’у необходимо заранее выяснить ожидания клиента от команды и него самого

Казалось бы, простая вещь. А теперь представьте, что вы с клиентом работаете не первый раз, вы уже не один пуд соли съели и через многое прошли. Разве надо садиться, тратить время и деньги клиента и говорить об очевидных, на первый взгляд, вещах? Да, надо! Обязательно. Даже если вы понимаете ожидания клиента от вашей работы, не будет лишним проговорить их вслух и убедиться, что вы «на одной странице».

Тем не менее мы стартовали, не договорившись об ожиданиях, не зная, как понять, готовы или нет, и кто это должен отследить.

Передача знаний

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

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

Каково же было наше разочарование, когда мы узнали, что ребята из FIM не очень-то хотят эту передачу делать и всеми возможными способами пытаются замедлить процесс. Они ссылались на то, что нет времени, так как у них много задач для разработки, есть сроки и обязательства перед клиентом. Мы в какой-то момент стали заложниками ситуации: с одной стороны, нам нужно как можно быстрее закончить передачу знаний и подхватить проект; с другой стороны, команда FIM пилит клиенту фичи, которые он же от них и требует. В итоге команда FIM уполномочила Solution Architect’а передавать нам знания о проекте по 2-3 часа в день.

Шишка 3. Приоритеты и цели должны быть синхронизированы и понятны для всех участников проекта

Так как нам выделили только одного специалиста, а не всю команду, то время на передачу знаний выросло почти в два раза. Мы бросились переделывать план. Вместо этого нужно было расставить приоритеты, цели и ретранслировать их всем. В итоге в глазах клиента все выглядело как плохо спланированная нами работа, а не фактический «лебедь, рак и щука», где команды тянут проект в разные стороны, а воз и ныне там. Отсюда следующий урок.

Шишка 4. Ориентироваться нужно на то, что лучше для проекта и клиента, а не на то, что лучше вам

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

Процессы

Как я упоминал ранее, у нас с клиентом были достаточно крепкие отношения и успешные проекты по модели fixed price. Наш новый проект четко ложился в продуктовую разработку и подразумевал другую модель работы — dedicated team. К моменту инициации этого проекта я уже вел чуть больше года другой проект продуктовой разработки в модели dedicated team, четко понимал необходимую разницу в построении процессов в команде. Таким образом, я принялся выстраивать процессы работы, необходимые именно нашему проекту, как я себе это видел.

Через несколько итераций на меня обрушилась буря негодования со стороны Епифана, который не понимал, что происходит. Посыпались вопросы: «А где же демки работающего продукта после каждого спринта, как было ранее? А что это за задача „investigate фичи“? А? Что за юнит-тесты? А почему тестировщик столько времени тратит на какие-то документы тест-стратегии и тест-кейсов? Почему он не может просто проверить, что все работает? Почему я должен платить за то, что ваш разработчик устанавливает себе локальную среду разработки?» и другие вопросы в том духе.

Сказать, что я был удивлен — не сказать ничего. Я тут же принялся объяснять клиенту, почему так и никак по-другому, зачем это надо и что это нам даст. Откровенно говоря, начал отвечать на вопросы клиента «реактивно».

Шишка 5. То, что очевидно вам, не очевидно другим

Я слишком поздно понял, что клиент, который работал с нами по модели fixed price, привык просто получать результат и знать, сколько он за это платит. Он никогда не заглядывал «под капот». Ему было все равно, что и как мы делаем, на что тратим усилия, сколько человек в этом задействованы, какой их уровень, с какими трудностями мы сталкиваемся, какие митинги проводим, если мы все делаем в срок и в рамках бюджета. Тут фокус сместился, клиент начал платить за специалистов и, знакомясь с новой моделью сотрудничества, хотел убедиться, что каждая минута была потрачена эффективно.

В свою очередь, для меня казалось очевидным, что надо продумать тест-стратегию, что и как мы будем тестировать, что одна из первых задач разработчика на проекте — поднятие локальной среды, настройка проекта. О каких демо может идти речь, если мы по большей части занимаемся передачей знаний и изучением системы? Это было очевидно мне, но не клиенту.

Таким образом, клиент начал достаточно активно заглядывать внутрь и вносить свою лепту в работу. Сперва последовали рекомендации, которые тут же перетекали в настоятельные рекомендации, а затем — в ценные указания. Фактически Епифан начал диктовать нам, что и как делать, сколько времени тратить на задачу. Я, как РМ, начал адаптировать клиентские указания под наши реалии. Так продолжалось достаточно долго, мы уже хорошо продвинулись в плане передачи знаний, начали заниматься разработкой. Примерно раз в неделю или две команда собиралась и обсуждала, почему не смогла сделать то, что просил клиент. Отсюда следующая шишка.

Шишка 6. Процессы должен устанавливать тот, кто несет ответственность за результат

Вы только представьте себе: клиент говорит, что нам надо делать, затем говорит, кто это будет делать, сколько времени можно на это потратить, в какой срок. В результате наша команда разочаровывает клиента, так как не выполнила его указаний. То есть рулит он, мы, как можем, подстраиваемся и потом получаем выговор. Со стороны может показаться, что это очевидная проблема, но мне на тот момент просто хотелось сделать все максимально хорошо и поставить проект на рельсы. Клиентские указания тогда казались мне необходимым условием, чтобы это случилось. Почему я это делал? Потому что «к-клиентоориентированность».

Клиентоориентированность

Мы всей командой WOW старались помочь клиенту. Были дедлайны, коммитменты, отношения с заказчиком, и это выходило на первый план. Клиенту надо успеть пятилетку за три года, погнали!

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

В итоге получилась такая картина. Опытная команда слушает указания клиента, отвечает ему, что так не пойдет, и клиент ловко бросает мне вызов на предмет способностей — моих и команды. Я беру дело в свои руки и говорю клиенту, что мы что-то придумаем. Про себя думаю о клиентоориентированности. Так продолжается несколько месяцев: мы на каждую прихоть клиента выдумываем план реализации, имея при этом весь карт-бланш со стороны компании. Дополнительные ресурсы, инструменты, овертаймы, что угодно, лишь бы достичь целей и выгрести из ямы.

Шишка 7. Не делать клиенту медвежью услугу, а вступать в сложный диалог на предмет принятых решений

Это сложно описать, но представьте ситуацию, что клиент приходит к вам и говорит, что все на грани срыва. Единственное, что может спасти ситуацию, — это если мы успеем сделать большой и сложный функционал на вчера. Другими словами, если 9 женщин родят одного ребенка за месяц. Я, сам того не понимая, делал клиенту именно «медвежью услугу», когда зарывался в поисках решения подобных задач. Тогда я считал, что клиент просит, значит мы должны помочь.

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

Доверие и подчинение

Как-то раз я получил от Епифана весьма странное письмо. На тот момент мы проработали над этим проектом несколько месяцев, уже закончилась передача знаний. Мы пилили клиентские пожелания параллельно с командой FIM, при этом плохо попадая в дедлайны, выставленные клиентом. Дело как-то шло, мы горели, страдали, но не сдавались.

В письме был очень простой запрос от клиента: не мог бы я предоставить ему доказательства, что все часы, отработанные командой за все время на проекте, были где-то подтверждены им лично или коллегами с его стороны. У нас были выстроены процессы еженедельных и ежемесячных репортов, где все было достаточно прозрачно расписано: кто чем занимался, сколько времени потратил на ту или иную задачу. Клиент, имея на руках все отчеты за все время работы, запросил новый с доказательствами, где и кто подтверждал чуть ли не каждый час работы команды. Обычно на проектах такого масштаба этого никто не делает. Такой запрос звучал для меня как «А можно наконец-то проектного менеджера добавить в команду?».

Затем последовали длительные сборы отчетности, кошмарные переговоры со всеми и вся и вопросы от клиента вроде «А кто этот час аппрувил?». Было много неясностей, и я нашел огрехи в своих же отчетах, но в то же время было ясно одно: доверие клиента утеряно.

Шишка 8. Как только клиента начинают заботить мелкие задачи или отчеты, значит что-то не так с доверием

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

Шишка 9. Не допускайте двойного подчинения

В моем случае вышло так, что основная коммуникация по проекту велась с двумя стейкхолдерами из команды клиента. Назовем их Покахонтас и Мариванна. Чуть выше них по иерархии стоял Епифан, который принимал ключевые решения, как, например, о переходе от одних провайдеров к другим. С его слов, решения, которые приняты Покахонтас и Мариванной, являются истиной для нашей команды, на которую он тут же готов подписаться, и он полностью полагается на них. И это работало, мы доверяли их решениям.

Пока внезапно решения Покахонтас и Мариванны не стали конфликтовать друг с другом. Мариванна поручила очень важную задачу, мы делаем. Покахонтас говорит давайте-ка сделаем вот эту задачу очень срочно. Сделали. Через неделю приходит Мариванна и говорит, что вы не сделали ту задачу, которая была самой срочной. В глазах Епифана мы просто провалили дедлайн. Я считаю, что если бы я сразу определил такой риск, то смог бы договориться с клиентом об одном человеке, который бы и принимал решения, а не МариХонтас, из-за которого пришлось набить очередную шишку. Или вообще сделать stakeholder matrix и engagement strategies. Тогда точно таких бы проблем не возникло.

Выводы

В итоге клиент Епифан решил остаться с FIM. Могу с уверенностью сказать, что я, как РМ, очень сильно завалил проект, несмотря на все усилия. Но этот опыт помог проанализировать мои же ошибки, сделать выводы и стать сильнее!

Один из главных выводов, к которому я пришел, — каждому РМу необходимо развивать коммуникативные навыки. Слушать и слышать своих ключевых стейкхолдеров. Важно правильно коммуницировать и собирать информацию, но еще важнее делать это вовремя.

Этот проект позволил мне взглянуть по-другому на свою работу. Как одно из следствий — получил PMP сертификацию (об этом можно почитать статью Как я готовился и сдал PMP Exam с результатом «Above Target» по PMBoK‎ 6th Edition), разобрался в эффекте Даннинга-Крюгера. Могу точно сказать, что бесконечно благодарен этому опыту.

Закончить статью хотелось бы советом моего тогдашнего руководителя, который впоследствии оказался для меня 10-й шишкой: РМ’у необходимо развивать умение смотреть на проект сверху, чтобы видеть весь огород, а не только свою грядку.

Keep managing and let’s rock!

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU