Как управлять клиентами? Советы от опытного менеджера проектов

Я менеджер проектов в NIX United. Моя команда работает над ИТ-продуктом, в котором задействовано более 150 человек. Над этим продуктом работают многочисленные команды, в том числе команда из 30 ИТ-специалистов из NIX United. Другие команды родом из Индии, Японии и Китая.

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

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

Эта статья будет полезна руководителям проектов, бизнес-аналитикам, техническим аналитикам и другим специалистам, выполняющим роль менеджера проектов.

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

На старте проекта у нас была частично сформированная команда Front, Back и Client-разработчиков, бизнес-аналитиков и QA, а также примерная оценка того, сколько еще специалистов может потребоваться.

Однако не было запланированного объема работ, точной оценки или стратегии выпуска. Кроме того, ключевые люди проекта (владелец продукта, технический менеджер проекта и супервайзер) были повышены в должности и переведены на другие проекты внутри компании. Что еще хуже, клиент установил нереальные сроки, не посоветовавшись с нами.

“” – скажут люди. Но для нас стакан всегда наполовину полон. Мы давно работаем с этим клиентом и установили доверительные и уважительные отношения.

Поэтому мы посчитали неразумным создание порочащего прецедента с последующим прекращением сотрудничества. Более того, мы верили, что в краткосрочной перспективе урегулируем ситуацию.

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

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

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

Как мы действовали в поисках решения

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

Таким образом, мы сразу начали подготовку клиента к возможным изменениям. Затем мы привлекли нового Product Owner для постоянного структурирования и учета требований. Нашей главной целью было как можно быстрее сформировать и оценить масштаб.

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

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

После того, как мы закончили подготовку, мы создали новую временную шкалу, которая включала все упомянутые риски. Клиент не был разочарован, когда получил новую временную шкалу, так как знал о каждом шаге. На самом деле, он предвидел это!

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

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

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

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

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

Выводы, которые мы сделали из этого случая?

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

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

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

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

Заинтересованные стороны на стороне клиента должны быть синхронизированы

Пересмотреть соглашения. Когда многие ключевые люди принимают решения, они могут не общаться друг с другом. Это ваша обязанность ввести всех в курс дела.

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

Погрузитесь в проект

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

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

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

Учитывайте зависимость вашего графика от других команд

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

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

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

Оценить риски

Трудно полностью реализовать свой потенциал на работе. Поэтому и оценка, и продолжительность задаются с определенной долей риска. Это создает буфер, который дает нам пространство для маневра.

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

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

Информационные панели могут быть очень полезными

Ничего не делай руками, ленись. Atlassian уже все продумала за вас. Самое главное — знать, что вы хотите отслеживать и какие показатели могут дать вам ответы.

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

Знакомство с груминг-встречами

Недостаточно подготовить задачи для следующего спринта. Завершите весь объем выпуска. И чем раньше вы начнете, тем лучше. Откладывая и откладывая невыполненные задачи, вы не обнаружите все скрытые сюрпризы раньше.

Планируйте выпуск, а не ближайший спринт

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

Если у вас нет четкого представления о том, что происходит, трудно указать сроки. Отчет о версии с датой выпуска — полезный инструмент в Jira, и вам стоит попробовать его. Я уверен, вы будете удивлены, увидев даты выпуска в более пессимистичном обзоре ситуации.

Не ставьте все на свою команду

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

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

Прислушивайтесь к мнению других команд

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

Следите за показателями проекта

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

Отчеты о спринтах в Jira позволяют отслеживать скорость в конце каждого спринта. Я также рекомендую использовать гаджет Sprint Health и расширенный фильтр по статусу.

Любые договоренности должны быть зафиксированы в письменной форме

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

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

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

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

Следите за модификациями прицела

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

Будьте открытыми и честными во всем, что вы делаете — везде и всегда.

Часто держите клиента в курсе вашего прогресса. Со словами, произнесенными вслух, и текстом, отправленным по электронной почте/сообщениям.

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

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