Недавно я имел очередной разговор с представителями коммерческого департамента на предмет выдачи клиентам обещаний по срокам реализации функционала. Так как регулярно приходится объяснять почему это крайне сомнительный путь, то решил написать небольшую статью с описанием логики и аргументации.
Некоторые вводные:
Я управляю разработкой в компании, которая разрабатывает собственный продукт, нацеленный на Enterprise рынок. Поэтому клиентов у нас не так много, каждый из них ценен и с каждым выстраивается более-менее индивидуальное общение.
Когда я говорю про «команду разработки», то имеется в виду весь коллектив, создающий продукт: продакт менеджеры, разработчики, аналитики, тестировщики, дизайнеры и т. д.
Стандартная ситуация - клиенту не хватает в продукте какого-нибудь функционала и это влияет на решение о покупке. Для сейла очень удобно, когда он приносит новое требование в разработку, та называет ему срок реализации доработки, он сообщает дату появления функционала клиенту, срок клиента устраивает, происходит сделка и все довольны. В идеальном мире, разработка еще и успевает выпустить продукт в срок и тогда все счастливы. А если не успевает, то виноват не сейл, он свою работу сделал - принес денег в компанию.
Я не имею ничего против того, чтобы сообщать срок клиенту, но есть проблема - если пообещал, то надо делать. В случае невыполнения обещаний деньги то мы получим, но отношения с клиентом будут подпорчены.
Аргументация сейлов всегда в таких случаях одинакова:
Вы оцените все правильно, заложите риски и все будет хорошо.
Я деньги в компанию принес, а вы не можете функционал реализовать.
Ниже я привожу логику, почему такой подход не работает и это путь в никуда:
Так не бывает, но предположим, что у вас чудесная команда разработки, которая умеет точно оценивать сроки, а потом их выполнять.
Пожеланий от клиентов у вас несколько, вы все их точно оценили, составили план и начали реализовывать. И в принципе все было бы хорошо, если бы не следующий пункт.
-
Внезапно что-то произошло, и к вам в скоуп залетает новая задача. Стандартные причины:
Появился новый крупный клиент, который готов купить за много денег ваш продукт, если вы сделаете какую-то другую незапланированную доработку.
Что-то прям сильно сломалось в полях и надо править тяжелый баг (ведь это тоже клиентский запрос).
Произошли какие-то глобальные изменения. Например, в 2022 году в России резко начал набирать популярность Linux и многим разработчикам пришлось экстренно делать его поддержку.
Можно предположить, что новых внезапных задач не появится, но такого в разработке ПО последние лет 10-15 не наблюдается. Я не видел, по крайней мере.
-
Дальше имеем варианты:
Ставим новый запрос в очередь после выполнения всех текущих планов. В реальности где-то через год. С большой вероятностью такое решение никого не устроит, и нужно все срочно, так как это либо много денег, либо критично, либо что-нибудь еще.
Пропускаем новый запрос вперед, двигая остальные задачи. Так как по ним срок уже коммуницировали клиентам, то бегаем по ним и сообщаем о сдвиге сроков, либо молчим в надежде на чудо, а потом надеваем водолазку для извинений и идем к клиенту.
После рассказа сейлам описанных выше 5 шагов, они соглашаются, что результат получается так себе, водолазку им надевать не хочется, и тут же предлагают простые и очевидные решения:
Если такое произойдет, то соберемся и обсудим что делать.
Давайте оставим буфер по ресурсам, если появятся новые задачи, то будем их делать за счет него.
Почему нельзя расширить команду разработки и успеть все?
Рассмотрим, почему не работает первый способ решения проблемы. Так как новые задачи прилетают постоянно, то будет бесконечный торг делаем/не делаем. Все под крики «это же деньги, давайте напряжемся». В результате все равно не успеем, зато все переругаются.
Теперь про второй, тут интереснее. Подумаем что будет, если оставить буфер по ресурсам. Если он маленький, скажем 10% ресурсов команды, то он быстро заполнится первой внезапно прилетевшей задачей и мы попадаем в ситуацию, когда нужно бесконечно все согласовывать и перепланировать. Если оставить гарантировано большой буфер, которого вроде должно хватить на все потенциально появляющиеся задачи, то он будет 70% ресурса команды. То есть на этапе первичного планирования у вас команда будет загружена на 30%. На это никто не согласится: «В смысле у на большая часть команды будет бездельничать или заниматься техническим долгом? Давайте ее займем чем‑нибудь полезным!»
Ну и фантастический третий пункт:) Нанять команду, научить ее работать, выстроить все процессы не просто. Но предположим, нам повезло — у нас бесконечный бюджет, лучшие рекрутеры и менеджеры, мы можем бесконечно расширяться. Мы создаем команду, которая успевает все. В итоге, она достаточно быстро успевает все сделать, дальше ей будет нечем заняться и мы начнем болезненный процесс сокращений и увольнений, а после этого окажемся в одном из пунктов выше.
Что же делать в такой ситуации? Ответ простой: принять что реальность устроена так, как она устроена, то есть задач всегда больше, чем можно сделать, всегда будут внезапные задачи, некоторым клиентам придется отказывать и т. п. А после стадии принятия, нужно научиться с этим осознано жить.
Комментарии (24)
mixsture
26.12.2024 11:04На это никто не согласится: «В смысле у на большая часть команды будет бездельничать или заниматься техническим долгом? Давайте ее займем чем‑нибудь полезным!».
И они в чем-то правы, но это "что-нибудь полезное" не может иметь сроки (в обычном понимании как "надо уложиться до ...") и в любой момент может быть остановлено и заброшено условно на год.
Собственно, за основу я бы брал эмпирическое правило из тайм менеджмента: планируйте только 60% своего времени (а, 40, соответственно, на покрытие рисков). Но тайм менеджмент не оперирует существенным изменением функционала - он покрывает именно что внезапные операционные отклонения, поэтому либо функционал замораживается до конца, либо надо заложить еще сколько-то на расширение. Цифра, опять же, очень эмпирическая, но 30% считаю вполне обычной - так примерно и подходим к вашим 70% непланируемого времени.
И в этом нет ничего странного. Ровно такая же ситуация с планированием есть у одного из моих клиентов - они занимаются производством: какую-то часть смены они могут довольно точно планировать, а какая-то часть остается в режиме "может сделают, а может и нет". Относительно ИТ сферы у них, конечно, существенно меньший процент попадает на "может сделают, а может и нет" - но у ИТ своя специфика: уникальный каждый раз продукт, наличие R&D почти в каждом продукте - это высокорисковые операции.
PMLife Автор
26.12.2024 11:04И они в чем-то правы, но это "что-нибудь полезное" не может иметь сроки (в обычном понимании как "надо уложиться до ...") и в любой момент может быть остановлено и заброшено условно на год.
Получим кладбище недоделок, как часто и бывает.
sse
26.12.2024 11:04Возможно, то, что ваши сейлы обещают клиентам жесткие сроки -- единственное, что позволяет вам получать свою зарплату, а не идти пополнять дефицитный рынок ИТ-специалистов; подумайте об этом
PMLife Автор
26.12.2024 11:04Этот аргумент сейлы часто говорят :) С другой стороны, им есть что продавать, пока разработка может сделать и выпустить что-нибудь нужно клиенту, а это мы регулярно делаем.
sse
26.12.2024 11:04Ну, вы вроде сказали, что у вас продуктовый, а не заказной ИТ, значит, как минимум, разрабатывать под каждого не нужно, то есть и выпускать что-то нужное -- не надо, нужно находить клиентов на то, что было сделано, а не будет.
А если глазами сейлов посмотреть, вот что получилось: вам один раз сказали про жесткие сроки, вы попыхтели, уложились, второй раз сказали -- вы попыхтели и уложились, значит, так это работает с вами; значит, так это работает у вас в компании вообще, сейлы за такой уклад и премию могут получать свою, никакого резона отказываться от данной схемы у них нет
qelael
26.12.2024 11:04Посмотрите на ситуацию глазами заказчика и сэйлза. Заказчику не хватает фичи в софте. Фича нужна к какому-то сроку. Например, запланирована маркетинговая активность завязанная на этой фиче. Или регуляторка.
Заказчик идет к сэйлзу и говорит: "Вот тут допилите, мне надо". Заказчик ждет от вас четкий срок "КОГДА" т.к. от этого срока он будет планировать свою деятельность.
Что вы предлагаете сделать сэйлзу? Сказать заказчику "Да хрен знает когда сделаем, у нас тут распланировано все на три месяца вперед, мы вас поставим в очередь и может быть сделаем. А может быть не сделаем"?. Ну, в таком случае компания закроется очень быстро.Вендор должен либо идеально оценивать сроки и укладываться в них (что мало кому удается) либо держать команду "на подстраховке", которая может заниматься тех.долгом, ресерчами, оптимизациями и т.д., но в случае "Надо" - подключиться к кор. задачам. Как только команда "подстраховки" начинает бОльшую часть времени заниматься продуктовыми задачами вместо развития - набирается еще доп. команда.
А если кто-то считает, что тех.долг, рефакторинг и оптимизация не нужны и не приносят денег - огласите список. Общественность должна знать своих героев %)
PMLife Автор
26.12.2024 11:04Жесткие сроки могут быть, как верно замечено, та же регуляторка. И по приоритетам в таких случаях обычно вопросов не возникает. Просто такие жесткие дедлайны не должны занимать весь скоуп.
Идеально оцененные сроки и укладывание в них - это возможно, но это означает, что план работ зафиксирован и не может быть изменен. А это прям редкость, всегда что-нибудь прилетает.
qelael
26.12.2024 11:04Наоборот - жесткие дедлайны ДОЛЖНЫ занимать ВЕСЬ скоуп. Вы же не знаете какие из сроков для заказчика - "жесткие". Вам кажется, что фича мелкая и ничего особо не меняет. А у заказчика под фичу уже запланировано десять активностей и миллиардный бюджет.
Поэтому, наоборот - весь скоуп должен быть ЖЕСТКО прибит к срокам. И вендор должен обспечить необходимое количество разработчиков, чтобы выполнять взятые на себя обязательства. С позиции заказчика неприемлима ситуация, когда сэйлз в ответ на поставленное ТЗ (напомню, ТЗ вендор внутри уже оценил и знает примерные сроки) говорит "Хрен знает, ну вроде через месяц сделаем". В этом случае заказчик сразу начинает искать другого вендора.Иначе и в случае оплаты заказчик будет говорить "Ну, мы оплатим через месяц. А может не оплатим, хз". Так бизнес не ведут %).
Четкие договоренности - скоуп-срок-оплата - это крауегольный камень заказной разработки. Если вендор его не выдерживает - пора искать другого вендора.
P.S. Задача вендора и его менеджеров - рассчитывать различными методами потенциальную будущую нагрузку с учетом "влетов", появления новых клиентов и держать на готове необходимое количество сотрудников. Умение вести подобные расчеты, кстати, один из ключевых навыков ПМ, если я правильно помню %)
И оценкой менджмемента как раз будет являться то, насколько точно они предсказали нагрузку.
PMLife Автор
26.12.2024 11:04Вы же не знаете какие из сроков для заказчика - "жесткие". Вам кажется, что фича мелкая и ничего особо не меняет. А у заказчика под фичу уже запланировано десять активностей и миллиардный бюджет.
Если с клиентом выстроены хорошие коммуникации, то это не является тайной.
С позиции заказчика неприемлима ситуация, когда сэйлз в ответ на поставленное ТЗ (напомню, ТЗ вендор внутри уже оценил и знает примерные сроки) говорит "Хрен знает, ну вроде через месяц сделаем".
ТЗ - это про заказную разработку, а не про продуктовую как у нас.
Kanut
26.12.2024 11:04Просто такие жесткие дедлайны не должны занимать весь скоуп.
А какое это имеет отношение к продажникам? Если у вас такое происходит, то тут скорее проект-менеджмент виноват
Идеально оцененные сроки и укладывание в них - это возможно, но это означает, что план работ зафиксирован и не может быть изменен. А это прям редкость, всегда что-нибудь прилетает.
А зачем обязательно идеально оценённые сроки? В чём проблема иметь сроки просто с запасом?
Ну то есть оцениваете с запасом на случай этих самых форм-мажоров. Если они будут, то уложитесь в срок. Если их не будет, то будете готовы раньше. Сомневаюсь что ваши клиенты из-за этого растроятся. И у вас будет возможность сдвинуть вперёд другие проекты или даже просто заняться техдолгом.
allter
26.12.2024 11:04регуляторка. ... такие жесткие дедлайны не должны занимать весь скоуп.
А что делать, если вдруг набежало регуляторки?
По остальной статье - остался вопрос: "ОК, сроки не озвучиваем, а что делать?" :)
PMLife Автор
26.12.2024 11:04Работать с клиентом. "Управление ожиданиями", "работа с возражениями" и т.д.
woodiron
26.12.2024 11:04Вот так сдашь машину в ремонт, приходишь в назначенное время - а на подъёмнике висит другая машина, а твоя стоит в углу. И ты с пониманием говоришь себе - "сейлы виноваты, да и вообще делать работу в обещанные сроки западло, ведь у ремонтников есть другие важные дела, а мои дела подождут".
PMLife Автор
26.12.2024 11:04Если время назначено, значит срок обещали :) Я же и пишу, что обещал - надо выполнять, иначе клиент будет справедливо недоволен. А вот надо ли обещать, если понимаешь, что с большой вероятностью появится более выгодный заказ? Может надо как-то по другому начать общаться с клиентом, чем просто обещать то, что он хочет услышать?
vadimr
26.12.2024 11:04Вас же никто не заставляет обещать именно то, что он хочет услышать. Обещайте срок через 10 лет, если это является вашей пессимистичной оценкой. Но срок должен быть твёрдым.
Лично у меня в жизни было много случаев, когда договор не заключался по причине того, что заказчик хотел одно, а я мог предложить с нашей стороны другое (в смысле сроков и денег). Обычно в таких случаях заказчик заключал договор с менее ответственными людьми, которые брали на себя обязательства и их проваливали (а таких людей всегда много). Некоторых из них заказчики потом разоряли в судах. Но согласованных сроков я не срывал.
vadimr
Для справки, например, в гособоронзаказе за сорванные сроки применяется ответственность вплоть до уголовной. И как-то люди справляются.
Я много лет руководил разработкой ПО, и считаю, что этот человек абсолютно прав:
А что касается рассуждений о буфере, то они справедливы, если команда занимается только одним проектом. Это недопустимая роскошь. Конвейер не должен останавливаться. Сегодня прикрутил колесо к одной машине, завтра к другой, а не так, что сидишь и ждёшь, пока блондинка сядет за руль.
Конечно, это автоматически означает, что компания в любой момент должна иметь в разработке хотя бы десяток-другой различных по срокам проектов. Так что сейлсам можете сказать, что это их проблема – обеспечить разработчиков загрузкой вплоть до однородности выполняемой работы.
PMLife Автор
Это немного другая ситуация, в случае гособоронзаказа никто новые пожелания вперед текущих не будет двигать. Встанут в очередь "на после госзаказа". Работа на государство накладывает ряд ограничений.
Aggle
А если ещё один госзаказ?
PMLife Автор
Будет соревнование "жадность vs жажда свободы" ;) результат зависит от понимания рисков и желания их на себя брать.
Marabu88
Абсолютно согласен.
Если вы не понимаете, почему озвучивание сроков необходимо, и не можете выстроить процесс, обеспечивающий попадание в сроки хотя бы в 80% случаев, то вы не "управляете разработкой в компании". Вы просто тимлид.