Работа с ожиданиями клиента в условиях неопределенности. Советы проектным менеджерам

Всем привет! Я — Дарья Козленко, Project Manager в NIX и спикерка NIXMultiConf.

Моя команда занимается IT-продуктом в аккаунте на 150 человек. Аккаунт — это большой и долгосрочный проект, в рамках которого несколько команд работают над одним или несколькими продуктами. Конкретно наш проект насчитывает порядка 30 человек со стороны NIX. Помимо нас, над ним трудятся еще четыре группы специалистов из Индии, Японии, Китая и США. У всех общий релиз и бэклог задач. Чтобы не накосячить, важно регулярно пребывать в плотной кооперации с распределенными командами клиента.

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

Статья будет полезна проектным менеджерам, бизнес-аналитикам, техлидам и другим специалистам, которые в той или иной мере примеряют на себя роль РМ’а.

Иллюстрация Алины Самолюк

Почему мы работали в условиях неопределенности

На момент старта проекта у нас была частично собранная команда из Front-, Back- и Client-разработчиков, бизнес-аналитиков и тестировщиков и примерное понимание, сколько еще специалистов может потребоваться. Не было ни четкого скоупа задач, ни его релевантной оценки, ни релиз-планирования. Вдобавок к этому ключевые на проекте люди (Product Owner, технический менеджер проекта и супервизор направления) получили промоушен и перешли на другие проекты в рамках организации. Усугублял ситуацию нереалистичный дедлайн, который заказчик установил без нашего участия.

«‎‎Надо было стопнуть проект!» — скажут самые правильные :) Но для нас стакан наполовину полон. С этим аккаунтом мы работаем давно. У нас уже налажена работа с клиентом, есть доверие и уважение к специалистам за результаты нашей работы. Посему становится в позу и создавать негативный прецедент с последующим разрывом сотрудничества мы сочли нецелесообразным. Тем более верили, что в краткосрочной перспективе мы разрулим ситуацию.

Начали мы с того, что не стали подписываться под установленными клиентом сроками. Бросили все силы на T-Shirt сайзинг задач и получили новую дату, которая отличалась (всего ничего!) на пять месяцев от дедлайна клиента. Параллельно вся команда впахивала и грумила скоуп, чтобы как можно раньше получить подтверждение нашим предположениям по оценке релиза и быть уверенными, что дополнительные пять месяцев работы нас точно спасут. Также мы активно согласовывали дизайн, с пристрастием исследовали требования, чтобы выявить блокеры и зависимости на другие команды. Тем самым старались минимизировать риски на ранних этапах. Это все мы делали вместе с разработкой, чтобы иметь возможность вести предметный разговор с клиентом.

Как мы действовали

Первоочередно мы рассказали клиенту о рисках непопадания в установленные им сроки и возможности появления зависимостей, о которых мы не знаем на данном этапе. Таким образом, мы со старта начали готовить клиента к изменениям. Затем привлекли нового Product Owner к регулярному «причесыванию» требований. Нашим фокусом было как можно скорее закончить формирование и оценку скоупа. Новый PO стал частью процесса, и наши действия были для него логичными. Мы все так же занимались спайками и фиксировали наши находки в артефактах на Confluence — внутренней системе для работы с общей базой знаний. А также привлекали к обсуждению другие команды, на которые у нас были зависимости.

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

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

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

Какие выводы сделали после отработки текущего кейса

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

Синхронизируйте стейкхолдеров на стороне клиента между собой. Перепроговаривайте договоренности. Когда «умных дядек», принимающих решения, много, они могут не общаться друг с другом. Ваша задача — ввести всех заинтересованных в курс дела. Если вы думаете, что на стороне клиента все участники команды — бравые ребята, которые синкаются между собой каждый день — вы глубоко заблуждаетесь. Каждый живет в своем контексте, и у них нет времени на «лишние» трудозатраты. Ребята на стороне клиента, конечно, бравые, но только они зачастую не общаются между собой.

Фиксируйте письменно любые договоренности и подкрепляйте их артефактами. Цифры могут быть лучшим языком, который понимает клиент. А каждый созвон должен заканчиваться call summary — короткой заметкой с описанием, что вы обсудили, что нового выяснили, к чему пришли и кто ответственен за внедрение следующих шагов. Если этого не делать, каждый услышит то, что хотел услышать, а запомнит — еще меньше. Поэтому ваша задача как проектного менеджера — минимизировать риски подобных потерь. Не поленитесь и зафиксируйте все, о чем говорилось. Еще лучше — записывать созвоны с разрешения всех участников разговора. Таким образом у вас всегда будет возможность прослушать запись снова, если вы что-то упустили или забыли. Я практикую запись call summary по ходу собрания, но это не всегда легко. На сложных собраниях, требующих глубокой концентрации внимания, все же лучше не мультитаскать.

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

Старайтесь погружаться настолько, насколько это возможно. Не списывайте себя со счетов, думая, что вы ничего не можете привнести в кругу технически подкованных разработчиков. Задавайте вопросы и не бойтесь показаться глупым. Порой именно РМ поднимает такие нюансы, о которых никто в команде не подумал ранее. И все потому, что ракурс проблемы, который видите вы — иной и отличается того, как его видит команда разработки.

Учитывайте зависимости на другие команды в своем расписании. Крайне важно совместить релизы всех команд, от которых вы чего-то ждете, и согласовать ваши задачи с их внутренними правилами и процессами. Не бойтесь обсуждать проблему в лоб, как бы неудобно это не казалось. На одном из общих собраний с командой, на которую у нас были зависимости, мы узнали, что они особо не планировали включать нужный нам функционал в свой релиз. Прямо спросив, что конкретно они смогут покрыть, мы обнаружили, что это далеко не 100% скоупа, который мы ожидали. Также ребята дали нам понять, что девелопмент билд, который мы рассчитывали получить к определенному сроку, нам точно не видать.

Закладывайте риски. Никто не вырабатывает 100% своих трудовых возможностей.

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

Используйте дашборды. Будьте ленивыми — не делайте ничего руками. За вас давно все придумал Atlassian. Главное в этом деле — понять, что вы хотите мониторить и какие метрики дадут вам ответы на интересующие вас вопросы. Как по мне, лучше настроить больше дашбордов, чем меньше. По ходу их использования вы сами поймете, какие дашборды вам не нужны.

Введите регулярные собрания по грумингу — «причесыванию» требований. Грумить задачи на ближайший спринт недостаточно. Займитесь всем скоупом релиза. И чем раньше вы это сделаете, тем лучше для вас. Все скрытые сюрпризы вы найдете раньше, чем могли бы, прокрастинируя и откладывая работу с бэклогом в долгий ящик.

Планируйте все к релизу, а не на ближайший спринт. Этот пункт как следствие вышеуказанного совета. Вы должны видеть картину целиком, а не только ее часть. Без полного представления происходящего вам будет трудно объективно оценить, насколько ваша команда сможет покрыть «хотелки» клиента, что важнее и к какому сроку. В Jira есть интересный гаджет — Version Report with release date. Попробуйте его. Я уверена, вы будете удивлены, увидев даты релиза по пессимистичному сценарию.

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

Думайте о зависимостях и советуйтесь с архитекторами не только своей, но и других команд. Специалисты из других команд могут подсветить то, что упускает ваша команда, и сэкономить много времени всему проекту. Ну, или добавить, как повезет :)

Ведите метрики по проекту. Вы должны знать производительность своей команды. С каждым спринтом отслеживайте отклонения факта от плана. Если вдруг обнаружите, что отстаете, вы должны понимать, какой кусок работы вам придется компенсировать, как быстро и за чей счет это можно покрыть. Трекинг-велосити доступен по закрытию каждого спринта в Jira из Sprint Reports. Также советую попробовать Rich Filter по статусам и Sprint Health гаджет.

Отслеживайте изменения скоупа. Лучше автоматизировано, конечно. Обложитесь Jira-нотификациями и дашбордами себе в помощь. Если не получается настроить процесс самостоятельно, можете привлечь самого клиента или более опытных коллег. Получается занимательно, мы проверяли :)

Будьте прозрачны во всех вопросах — везде и всегда. Регулярно держите клиента в курсе вашего прогресса. Словами через рот и текстом через почту/мессенджеры.

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

Мне очень интересно, чем закончится наше путешествие в текущем релизе, но это уже будет совсем другая история.

👍НравитсяПонравилось10
В избранноеВ избранном11
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Спасибо, было интересно и познавательно почитать. Некоторые рекомендации попробуем применить на нашем проекте.

Це не Agile, це створення нового легасі.

Грумінг — це слово поза вживанням останні 5 років. Авторка не в темі.

Всегда говорите клиенту правду и ничего, кроме правды.

Так и запишем: всегда говорите клиенту ничего

и подкрепляйте артефактами.

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