Как объяснить сейлам, что обещание жестких сроков — это плохо
Недавно я имел очередной разговор с представителями коммерческого департамента на предмет выдачи клиентам обещаний по срокам реализации функционала. Так как регулярно приходится объяснять почему это крайне сомнительный путь, то решил написать небольшую статью с описанием логики и аргументации.
Некоторые вводные:
Я управляю разработкой в компании, которая разрабатывает собственный продукт, нацеленный на Enterprise рынок. Поэтому клиентов у нас не так много, каждый из них ценен и с каждым выстраивается более-менее индивидуальное общение.
Когда я говорю про «команду разработки», то имеется в виду весь коллектив, создающий продукт: продакт менеджеры, разработчики, аналитики, тестировщики, дизайнеры и т. д.
Стандартная ситуация — клиенту не хватает в продукте какого-нибудь функционала и это влияет на решение о покупке. Для сейла очень удобно, когда он приносит новое требование в разработку, та называет ему срок реализации доработки, он сообщает дату появления функционала клиенту, срок клиента устраивает, происходит сделка и все довольны. В идеальном мире, разработка еще и успевает выпустить продукт в срок и тогда все счастливы. А если не успевает, то виноват не сейл, он свою работу сделал — принес денег в компанию.
Я не имею ничего против того, чтобы сообщать срок клиенту, но есть проблема — если пообещал, то надо делать. В случае невыполнения обещаний деньги то мы получим, но отношения с клиентом будут подпорчены.
Аргументация сейлов всегда в таких случаях одинакова:
Вы оцените все правильно, заложите риски и все будет хорошо.
Я деньги в компанию принес, а вы не можете функционал реализовать.
Ниже я привожу логику, почему такой подход не работает и это путь в никуда:
Так не бывает, но предположим, что у вас чудесная команда разработки, которая умеет точно оценивать сроки, а потом их выполнять.
Пожеланий от клиентов у вас несколько, вы все их точно оценили, составили план и начали реализовывать. И в принципе все было бы хорошо, если бы не следующий пункт.
Внезапно что-то произошло, и к вам в скоуп залетает новая задача. Стандартные причины:
Появился новый крупный клиент, который готов купить за много денег ваш продукт, если вы сделаете какую-то другую незапланированную доработку.
Что-то прям сильно сломалось в полях и надо править тяжелый баг (ведь это тоже клиентский запрос).
Произошли какие-то глобальные изменения. Например, в 2022 году в России резко начал набирать популярность Linux и многим разработчикам пришлось экстренно делать его поддержку.
Можно предположить, что новых внезапных задач не появится, но такого в разработке ПО последние лет 10–15 не наблюдается. Я не видел, по крайней мере.
Дальше имеем варианты:
Ставим новый запрос в очередь после выполнения всех текущих планов. В реальности где-то через год. С большой вероятностью такое решение никого не устроит, и нужно все срочно, так как это либо много денег, либо критично, либо что-нибудь еще.
Пропускаем новый запрос вперед, двигая остальные задачи. Так как по ним срок уже коммуницировали клиентам, то бегаем по ним и сообщаем о сдвиге сроков, либо молчим в надежде на чудо, а потом надеваем водолазку для извинений и идем к клиенту.
После рассказа сейлам описанных выше 5 шагов, они соглашаются, что результат получается так себе, водолазку им надевать не хочется, и тут же предлагают простые и очевидные решения:
Если такое произойдет, то соберемся и обсудим что делать.
Давайте оставим буфер по ресурсам, если появятся новые задачи, то будем их делать за счет него.
Почему нельзя расширить команду разработки и успеть все?
Рассмотрим, почему не работает первый способ решения проблемы. Так как новые задачи прилетают постоянно, то будет бесконечный торг делаем/не делаем. Все под крики «это же деньги, давайте напряжемся». В результате все равно не успеем, зато все переругаются.
Теперь про второй, тут интереснее. Подумаем что будет, если оставить буфер по ресурсам. Если он маленький, скажем 10% ресурсов команды, то он быстро заполнится первой внезапно прилетевшей задачей и мы попадаем в ситуацию, когда нужно бесконечно все согласовывать и перепланировать. Если оставить гарантировано большой буфер, которого вроде должно хватить на все потенциально появляющиеся задачи, то он будет 70% ресурса команды. То есть на этапе первичного планирования у вас команда будет загружена на 30%. На это никто не согласится: «В смысле у на большая часть команды будет бездельничать или заниматься техническим долгом? Давайте ее займем чем‑нибудь полезным!»
Ну и фантастический третий пункт:) Нанять команду, научить ее работать, выстроить все процессы не просто. Но предположим, нам повезло — у нас бесконечный бюджет, лучшие рекрутеры и менеджеры, мы можем бесконечно расширяться. Мы создаем команду, которая успевает все. В итоге, она достаточно быстро успевает все сделать, дальше ей будет нечем заняться и мы начнем болезненный процесс сокращений и увольнений, а после этого окажемся в одном из пунктов выше.
Что же делать в такой ситуации? Ответ простой: принять что реальность устроена так, как она устроена, то есть задач всегда больше, чем можно сделать, всегда будут внезапные задачи, некоторым клиентам придется отказывать и т. п. А после стадии принятия, нужно научиться с этим осознано жить.
