Профессионал управляет рисками, а не просто выполняет работу

Сильные специалисты и хороший продукт ещё не гарантируют клиенту результата.

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

Для меня это и есть профессиональное ведение проекта.

Клиент не должен становиться менеджером проекта, который он у нас купил.

Эта статья - продолжение серии “Мы так не будем”.

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

Теперь хочу зафиксировать следующий принцип.

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

Когда клиент становится менеджером собственного проекта

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

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

Но общий клиентский опыт всё равно оказывался плохим.

Проблема появлялась не обязательно внутри отдельной операции. Она появлялась между операциями.

Один специалист закончил свою часть, но следующий этап не был назначен. Договорённость осталась в переписке, но никто не проконтролировал её выполнение.

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

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

Пока не задал вопрос:

Что теперь должно произойти?

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

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

Но он не должен сам удерживать весь проект в движении.

Он не должен:

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

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

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

Хороший специалист и профессиональный сервис - не одно и то же

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

Но клиент покупает не только отдельную профессиональную операцию. Он покупает переход из одной точки в другую.

Именно здесь появляется разница между хорошим исполнителем и профессиональной системой.

Исполнитель спрашивает:

Я свою задачу выполнил?

Профессионал спрашивает:

Проект приблизился к согласованному результату?

Исполнитель отправил документ и считает работу завершённой.

Профессионал проверяет:

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

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

Исполнитель отвечает только за свой участок. Профессиональная команда удерживает связи между участками.

Потому что сложные проекты часто разваливаются не внутри отдельных задач. Они разваливаются на стыках.

Что такое профессиональное ведение проекта

Почти десять лет мы занимаемся внедрением IT-решений и автоматизацией процессов на базе Битрикс24 и своиз ИТ продуктов.

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

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

А проект - это не только список задач и сроки.

Это:

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

Поэтому профессиональное ведение проекта я понимаю прежде всего как управление рисками на пути к согласованному результату клиента.

Не как обещание, что проблем не будет. Проблемы в сложных проектах неизбежны.

Профессионализм проявляется в том, что происходит с риском до и после его реализации.

Профессионал не обязан заранее знать всё

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

Я не считаю такую уверенность признаком профессионализма. Часто это просто уверенная продажа неизвестности. Профессионал не обязан заранее знать всё.

Он обязан честно понимать границы своего знания.

Он должен видеть:

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

Сказать “я пока не знаю” иногда профессиональнее, чем назвать красивую цифру. Но одной честности недостаточно.

После слов “я не знаю” должна появиться управляемая конструкция:

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

Именно это превращает неопределённость из проблемы клиента в управляемую часть проекта.

Управлять риском - значит говорить до того, как стало поздно

Есть большая разница между сообщением о проблеме и управлением риском.

Сообщение о проблеме выглядит так:

Мы не успели.

Управление риском начинается раньше:

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

В первом случае клиент получает последствие. Во втором - возможность повлиять на результат.

Профессионал должен сообщать не только сам факт риска.

Клиенту нужно понимать:

• что именно может произойти;
• на что это повлияет;
• кто отвечает за действие;
• что требуется от подрядчика;
• что требуется от клиента;
• какие варианты ещё доступны;
• до какого момента решение имеет смысл.

Это не бюрократия. Это уважение к клиенту и его результату.

Истинное служение не означает угождение

Мне близка формулировка “служить клиенту”. Но она легко искажается.

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

Не значит брать на себя ответственность за всё, включая то, что контролирует только сам клиент. Не значит бесконечно расширять работу без изменения сроков и условий.

Иногда настоящее служение выглядит как отказ:

Так сделать можно, но мы не рекомендуем этот путь, потому что он создаёт такие последствия.

Иногда - как остановка:

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

Иногда - как неприятная правда:

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

Угождение защищает текущий комфорт клиента. Служение защищает его согласованный результат.

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

А потому что профессионал видит риск, который клиент может пока не видеть.

Служение клиенту требует границ ответственности

Управление проектом не означает, что подрядчик отвечает абсолютно за всё.

Есть решения, которые должен принять клиент. Есть данные, которые может предоставить только его команда.

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

Эту границу я подробнее разбирал в статье “Влияние не равно контролю”. Профессиональный подрядчик не обещает невозможного.

Он ясно разделяет ответственность.

Например:

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

Когда зоны ответственности не обозначены, обе стороны начинают жить в разных реальностях.

Подрядчик считает, что ждёт решение клиента. Клиент считает, что подрядчик продолжает работу. Сотрудники уверены, что вопрос закрыт. Руководитель уверен, что кто-то ещё занимается проблемой. Проект стоит.

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

Настоящая роль менеджера проекта

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

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

Он должен удерживать:

• конечный результат;
• текущий этап;
• принятые решения;
• открытые вопросы;
• зависимости;
• сроки;
• изменения;
• зоны ответственности;
• риски;
• следующий шаг.

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

Он не может гарантировать отсутствие сбоев. Но клиент не должен обнаруживать сбой последним.

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

Он не может устранить любую внешнюю зависимость. Но он должен сделать её видимой и управляемой.

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

Почему это особенно важно для “Дожми Продажи”

“Дожми Продажи” - сложный продукт. Для запуска недостаточно просто нажать кнопку и получить готовую управленческую систему.

Нужно подключить коммуникации. Проверить полноту данных.

Определить управленческий фокус. Превратить его в проверяемый критерий.

Понять, одинаково ли этот критерий трактуют собственник, руководители и сотрудники. Откалибровать оценку.

Разобрать спорные случаи. Принять решения по результатам.

Где-то могут возникнуть технические ограничения. Где-то окажется, что данных недостаточно.

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

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

Вот платформа. Дальше разбирайтесь.

Даже если платформа будет технически сильной, для меня этого недостаточно.

Я хочу перенести в “Дожми Продажи” накопленный опыт сложных IT-внедрений. Не только знание технологий. Прежде всего культуру профессионального ведения проектов.

Мы должны помогать клиенту пройти сложность продукта.

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

Наша задача - не подменить руководителя. Наша задача - сделать путь к его решению управляемым.

Каким должен быть наш сервис

Я хочу, чтобы клиент “Дожми Продажи” понимал:

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

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

Но мы можем построить систему, в которой ошибка не скрывается. Риск не замалчивается. Ответственность не растворяется. Контекст не пропадает между участниками. Проект не останавливается незаметно. А клиент не вынужден самостоятельно управлять подрядчиком, чтобы получить купленный результат.

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

Мы так не будем

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

Не будем оставлять договорённость без ответственного и следующего шага. Не будем прятать неприятную правду за удобными формулировками.

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

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

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

Для меня именно это и означает по-настоящему служить клиенту.

Частые вопросы

Что такое управление рисками проекта?

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

За что отвечает менеджер проекта?

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

Должен ли менеджер проекта отвечать за результат?

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

Должен ли клиент контролировать подрядчика?

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

Чем служение клиенту отличается от угождения?

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