За более чем десятилетнюю карьеру менеджера проектов в IT, я сотни раз сталкивался с вопросом о переносе сроков проекта. О переносе в сторону увеличения. Были десятки причин почему это происходило. Но, по-началу, каждый разговор с клиентом заканчивался одинаково — я соглашался на то, что нужно завершить очередной этап, или проект в изначально утвержденное время, уговаривал команду работать сверхурочно, но в итоге мы все равно не успевали, тот результат, который получался, был с кучей ошибок и не отвечал требуемому качеству.
В один прекрасный момент, я вдруг решил что получение статуса Project Management Professional решит все мои проблемы. Я потратил год на подготовку, прочитал пять раз PMBoK. Это самая ужасная книга из прочитанных мною. Я прочитал несколько книг с комментариями, включая Rita Mulcahy, которая в конце концов расставила все точки над i, я прорешал более тысячи тестовых экзаменационных вопросов. Я вызубрил все процессы и их последовательность. Я сдал экзамен.
Пришло осознание, что да, я — упертый, но как разговаривать с клиентами до сих пор непонятно.
Как ощущения помогают понять, что сейчас происходит
Со временем я стал замечать, что ситуации с переносом сроков повторяются и при разговоре с клиентами об этом, я ощущаю что-то в теле. Был какой-то дискомфорт. Становилось трудно дышать, немного крутило живот. Я не придавал этому значения. Позже, когда стал заниматься йогой и медитацией, инструктор мне объяснил, что тело так реагирует на эмоции. И если это фиксировать и осознавать, то с этим можно работать.
Вы спросите, как это все относится к переговорам о сроках? Относится прямым образом. Эмоции и ощущения в теле вызвали чувство неуверенности, мешали четко думать и принимать решения. Пару месяцев йоги и осознанной медитации помогли мне с этим справиться. На переговорах я стал лучше понимать, что со мной происходит в данный момент, и как на это реагировать. Это придало уверенности и договариваться стало чуточку легче.
Типовые сценарии разговора
Для себя я выделяю два основных сценария разговора.
Первый — мы переносим сроки проекта из-за того, что заказчик накидал новых «хотелок». Важно донести до него, что производительность команды не резиновая. Если мы что-то впихиваем, то что-то должны выпихнуть. Даже если он готов доплатить за срочность, и мы нагоним людей на проект, это не гарантирует результат. Скорее всего даже наоборот — все станет еще хуже.
Здесь я для себя вижу два пути развития: либо придерживаемся изначального плана, либо мы определяем что же из перечисленных запросов важнее, делаем только их и укладываемся в срок, а все остальные запросы уже идут на следующий этап или спринт. В этом разговоре очень важно звучать уверенно и твердо стоять на своем.
Второй сценарий — мы переносим сроки из-за внутренних причин: работали без вмешательства заказчика, но, тем не менее, не укладываемся в отведенное время.
Здесь опять же два пути развития: либо нагоняем людей, если есть такая возможность, либо передоговариваемся с заказчиком. И вот это, на мой взгляд, самый сложный разговор. Во-первых, очевидно, что проблема на нашей стороне, во-вторых, я прошу об уступке, в третьих — ничего не предлагаю взамен. Чуть позже я расскажу, как сейчас справляюсь с такой ситуацией.
Думаю, что многим знакомы подходы по работе с дедлайнами. Но перечислю еще раз:
- Fast Track или быстрый проход — сжимаем и накладываем некоторые фазы друг на друга. Сразу минус — может пострадать качество.
- Crashing — нагоняем еще людей в команду.
- Переоценка — проверяем оценки времени (повторить оценку — вдруг ошиблись в сторону раздувания сроков).
- Урезаем scope. Здесь важно управлять ожиданиями заинтересованных лиц для понимания, какой будет эффект будет у урезания работ.
- Урезаем качество сократив сроки и/или некоторые процедуры вроде тестирования. Рискованно, так как тестирование не видно спонсору/заказчику/пользователю, зато видно его отсутствие.
- Отказать в изменениях — если причина наших мучений — незапланированные изменения от заказчика.
- Переработки.
Одно время довольно часто использовал MS Project, даже прошел курсы и пересмотрел кучу видео-уроков. Видел как строился проектный офис путем «внедрения» MS Project. Сейчас перешел на Google Docs + внутренняя система трекинга задач. Такой подход предоставляет больше гибкости, но есть и свои минусы — трудно строить критический путь и не всегда удобно (в графическом виде) сравнивать базовый план с актуальным. Оптимизация — наше все! Crashing, fast track, overworking, урезание работ — применяю, когда горят сроки. В эти моменты обычно появляются конфликты ресурсов — люди заняты, кто-то в отпуске, заказчик хочет именно это и все. Приходится договариваться, пересматривать и еще раз договариваться.
Как уменьшить агрессию при отстаивании сроков
Клиенты по-разному воспринимают разговор о сроках, но в основном это негативные эмоции разной степени. Согласитесь, мало приятного в том, что вы не получите желаемого результата вовремя?
Общий подход к разговору, где я выделил для себя несколько шагов:
- Сообщить клиенту о проблеме как можно раньше.
Вот вам пример — вы договорились с друзьями посидеть в баре. Но в последний момент шеф попросил задержаться на работе по очень важному делу. Вы не можете отказать и остаетесь. Вы можете сразу же позвонить друзьям и предупредить, что задерживаетесь, либо сделать это через два часа, когда освободитесь. Полагаю, если выберете второй вариант, то со временем, вас перестанут приглашать. - Убираю неопределенность. Рассказываю, с какими проблемами мы столкнулись, и что предполагаем делать. Здесь стоит подробнее рассказать о дальнейших шагах.
- Сделать так, чтобы клиент сам согласился, а в идеале сам предложил перенести сроки. Лично у меня пока еще не всегда это получается, но я к этому стремлюсь, и считаю верхом мастерства переговоров.
Дзен-подход и постановка цели
Этот пункт пересекается с темой дзен-переговоров, которая мне близка. Основная идея заключается в том, что идя на любую встречу, четко для себя сформулируйте — «Что должен сделать, или как должен измениться в пространстве мой собеседник, для того, чтобы я получил отсроченный результат».
Такой подход отлично дополняет стратегия «заставить клиента сказать нет как можно быстрее». Чем быстрее оппонент поймет, что его требования будут ему чего-то стоить, тем быстрее он может сказать «нет».
Разговор, который получился
Я вел проект для одного из подразделений большой иностранной компании. За время работы у нас с куратором со стороны заказчика сложились неплохие отношения. По мелким вопросам нам удавалось договариваться. Но вот наступает очередной этап сдачи большого куска проекта, и я понимаю, что мы не укладываемся. Вот еще бы две недели….
Привожу буквально дословно фразу, которая сломила ситуацию в нашу сторону, когда казалось, что все варианты уже исчерпаны:
«Слушай Грег, если мы сейчас выкатим продукт в том состоянии, в котором он есть, нас по головке за это не погладят, прилетит по первое число. Но и тебе достанется — куда же ты смотрел все это время. Если ты поможешь отсрочить дедлайн, мы со спокойной головой доделаем то, что нужно и без ошибок».
Извлеченные уроки
Сейчас я понимаю, что к сложным разговорам, лучше назвать их переговорами, нужно готовиться. Как итог — отвечая на заголовок статьи, что имеем в сухом остатке:
- Собираю факты — кто и что сделал, почему были приняты решения, сообщения на почте и в скайпе, записи собраний.
- Предварительная договоренность с моими коллегами о возможности переключения их разработчиков на мой проект. Заметьте, только о возможности, не факт что это случится.
- Формирую дзен-цель для себя. Сюда же входят ожидаемые результаты:
- Наилучший результат для меня.
- Компромиссный результат.
- Минимально-приемлемый результат.
- Наилучшая альтернатива, имеющаяся у меня. Что я буду делать, если не удастся договориться?
- Цели оппонента(ов).
- Что необходимо сделать при подготовке, чтобы добиться желаемого результата.
- Готовлюсь к переговорам — медитация в течение 5 минут, либо просто наблюдение за секундной стрелкой, также в течение 5 минут. Это позволяет освободить голову от потока ненужных мыслей и немного успокоиться.
- Обязательно беру с собой стакан или пол-литровую бутылку негазированной воды. Вода поможет смочить горло, когда голос будет проседать. Хриплый, непривычный голос может звучать неуверенно, а мне этого не нужно.
Кейс из практики
Разрабатываем продукт, процесс немного подзатянулся из-за постоянных вливаний новых фич, все стороны это понимают, но заказчик — CEO, так как проект внутренний — тем не менее настаивает на том, чтобы были реализованы все фичи из бэклога и необходимо придерживаться сроков установленных изначально.
Участники ситуации:
- CEO нашей компании;
- я как менеджер проекта.
Формирую дзен-цель для себя:
- CEO согласится довести проект до минимально жизнеспособного состояния (MVP), то есть оставить только те фичи, которые имеют приоритет «High», в сроки указанные мной.
Наилучший для меня результат:
- CEO соглашается на урезание скоупа, оставляем только фичи с приоритетом «High», и перенос дедлайна на 4 недели.
Компромиссный результат:
- СЕО соглашается на урезание скоупа, оставляем только фичи с приоритетом «High», и подключением еще 2 разработчиков.
Вариант так себе, на то он и компромиссный — новым разработчикам может потребоваться время, чтобы войти в проект.
Минимально приемлемый результат:
- CEO соглашается только на перенос сроков.
Риск здесь в том, что такая ситуация уже была — сроки переносились, но и хотелки продолжали добавляться.
Наилучшая альтернатива:
- Договариваться с коллегами, чтобы разработчики из команд часть времени работали над моими задачами. Плюс, возможно, сократить время на тестирование — оставить только высокорисковые фичи.
Цель CEO:
- Выпустить новую разработку на рынок как можно быстрее, т. к. уже есть некая договоренность с клиентами.
Что необходимо сделать при подготовке, чтобы добиться желаемого результата:
- Здесь возвращаемся к извлеченным урокам — собираем факты — переписка, письма, записи митингов и т. д. Готовлюсь объяснять, почему мы находимся там, где мы находимся, кто стоит за этим, и какие решения были приняты, а так же предлагаю возможные варианты решений.
Приоритетом для CEO было время, поэтому результатом переговоров стал один из возможных компромиссных сценариев. Мы пересмотрели фичи еще раз, что-то было выкинуто, что-то добавлено, были добавлены разработчики и урезаны некоторые из задач по тестированию. Причем мне удалось убедить CEO, что часть рисков, связанных с этим, ляжет на пользователей. Да, мы можем себе такое позволить.
Послесловие
Подводя все вышесказанное — когда есть то, на что можно опираться, а это — сценарии переговоров, подготовка, факты, то и сами переговоры будут проходить проще. Для меня важным уроком стало именно то, что нужно готовиться. Небольшой лайфхак — сценарий разговора можно записать на листе бумаги и взять его с собой. Даже если разговор пойдет не по сценарию, то в любом случае какие-то небольшие, физические подсказки не будут давать сбиться с намеченного курса.