October 8

Как объяснить заказчику, почему сроки переносятся?  

Проблема со сроками – одна из самых неприятных в работе проджект-менеджера. Каждый проджект хотя бы раз (ах если б только раз🥲) сталкивался с этим.

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

Своим опытом с нами поделился Влад – основатель IT-компании HardDays и преподаватель нашего курса по проджект-менеджменту. Дальше от его лица.

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

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

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

Обычно, когда мы даем оценку – она делится на 3 уровня, от меньшего к большему:

  1. Оценка задачи
  2. Оценка блока задач
  3. Оценка всего проекта

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

Соберем главные рекомендации, которые помогут не допустить “просрочку” или минимизировать потери, когда огонь дедлайнов уже не потушить 👇🏼

1. Проекты лучше разбивать на небольшие блоки задач

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

  • Сроки горят на блоке в 2 часа – не такая уж беда
  • Сроки горят на блоке в неделю – Хьюстон, у нас проблемы
  • Сроки горят на блоке в целый проект – Пакуй вещи, кота и бери билет в один конец на Марс, мы горим

2. Сообщайте о проблемах заранее

Когда появляется туманная вероятность задержать сроки, полезно поступить как этот котик:

Ключевое, что важно понимать – к клиенту надо приходить тогда, когда появляется ТЕОРЕТИЧЕСКАЯ возможность не вписаться в сроки. Вы честно говорите о проблемах, а заказчик в курсе и видит, что процесс налажен и работа идет. Многие проджекты создают проблемы “теплой ванны”. Клиента держат долго в теплой ванне, рассказывая, мол, все хорошо, прекрасная маркиза, нет ни проблем, ни просрочек. А потом всё вываливают разом и пытаются реанимировать и клиента, и отношения с ним.

3. Держите клиента в контексте процесса

Дано: у вас есть проект, срок выполнения – 3 месяца. Вы с командой усердно работали, но где-то налажали и решили, что делиться этой инфой с клиентом необязательно, лучше молча исправить. Исправить не получилось, несмотря на то, что вы очень старались. Сроки упущены.

Результат: вы идете к клиенту и слезно вымаливаете еще один месяц, потому что бла-бла-бла.

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

Если вы когда-то имели дело со строительными бригадами, которые вечно переносят срок сдачи ремонта, точно сможете представить такую ситуацию. Приходит прораб в конце месяца и говорит, мол, не успели отделку сделать, еще один месяц нужен. Что вы подумаете? Правильно – что они всей бригадой целый месяц вместо работы в шахматы играли. В этом плане IT не сильно отличается от строительства.

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

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

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

 4. Ищите решения, которые сгладят последствия

Глобально, когда речь заходит о сроках, клиенты боятся двух моментов:

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

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

Клиент: Сколько вам нужно времени?

Мы: 3 месяца.

Клиент: Супер, у нас через 3 месяца выйдет реклама в крупном паблике. Закупили заранее, потому что так дешевле, и то сумма немаленькая, имейте в виду.

Мы: 👌

Проходит 2 месяца

Мы: Ребят, у нас не получается успеть через месяц.

Капец, что делать?

И таких моментов может быть много. Поэтому желательно еще на старте проекта (в идеале – до подписания контракта) понять, чем чревата для клиента пролонгация сроков? Что будет, если вы не успеете? Есть базовый сценарий, но есть и риски, которые надо учитывать. Если опоздаете на неделю-две, это нормально или вас за такое на кол посадят?

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

Как мы поступили в этой ситуации?

  1. Обнаружили проблему, сразу пришли с ней к клиенту.
  2. Сообщили: “Да, в срок не успеваем, но к 15 октября можем предложить полностью работающее вот это и это.”
  3. Рабочий функционал клиент сможет отправить в релиз и на рекламу, а мы сосредоточимся на том, чтоб допилить то, что вовремя не успели.
  4. Решение годное, рекламные деньги целы, клиент доволен.

5. Сначала предлагаем решения, потом извиняемся

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

«Извините, я обоср*лся».

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

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

Провальная стратегия: ныть, прокрастинировать и сесть за проект за неделю до сдачи, а потом извиниться перед заказчиком.

Рабочая стратегия: из позиции переговорщика “продать” свою идею и решение заказчику. Да, проблема есть, но вы предлагаете это и то, потому что вот так и вот так – это лучшие варианты в текущей ситуации, о которой заказчик был предупрежден.

6. Считайте экономику

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

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

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