Comments 26
Для справки, например, в гособоронзаказе за сорванные сроки применяется ответственность вплоть до уголовной. И как-то люди справляются.
Я много лет руководил разработкой ПО, и считаю, что этот человек абсолютно прав:
Вы оцените все правильно, заложите риски и все будет хорошо.
А что касается рассуждений о буфере, то они справедливы, если команда занимается только одним проектом. Это недопустимая роскошь. Конвейер не должен останавливаться. Сегодня прикрутил колесо к одной машине, завтра к другой, а не так, что сидишь и ждёшь, пока блондинка сядет за руль.
Конечно, это автоматически означает, что компания в любой момент должна иметь в разработке хотя бы десяток-другой различных по срокам проектов. Так что сейлсам можете сказать, что это их проблема – обеспечить разработчиков загрузкой вплоть до однородности выполняемой работы.
Для справки, например, в гособоронзаказе за сорванные сроки применяется ответственность вплоть до уголовной. И как-то люди справляются.
Это немного другая ситуация, в случае гособоронзаказа никто новые пожелания вперед текущих не будет двигать. Встанут в очередь "на после госзаказа". Работа на государство накладывает ряд ограничений.
Абсолютно согласен.
Если вы не понимаете, почему озвучивание сроков необходимо, и не можете выстроить процесс, обеспечивающий попадание в сроки хотя бы в 80% случаев, то вы не "управляете разработкой в компании". Вы просто тимлид.
Обычно для выполнения сроков по оборон заказу, режут сильно функционал и качество (что в текущей полит. ситуации лично меня устраивает). Я сам какое-то время был невыездным, угораздило на практику попасть в интересное место, плюс знакомый на одном из оборонных предложений работает уже несколько лет. Он много "приколов" рассказывал. И про систему контроля версий в виде ДВД дисков и про устаревшее ПО, и т.д.
Кстати сейчас многое в оборонке касаемо IT отдают на оутсорс, но только не критичную часть и очень хитро под видом обычных заказов.
В гос. секторе с этим дела обстоят куда лучше и там качество продуктов повыше будет. Притом что при срыве дедлайна тендера так же ответственность вплоть до уголовной, но обычно сроки ставят просто с большим запасом.
На это никто не согласится: «В смысле у на большая часть команды будет бездельничать или заниматься техническим долгом? Давайте ее займем чем‑нибудь полезным!».
И они в чем-то правы, но это "что-нибудь полезное" не может иметь сроки (в обычном понимании как "надо уложиться до ...") и в любой момент может быть остановлено и заброшено условно на год.
Собственно, за основу я бы брал эмпирическое правило из тайм менеджмента: планируйте только 60% своего времени (а, 40, соответственно, на покрытие рисков). Но тайм менеджмент не оперирует существенным изменением функционала - он покрывает именно что внезапные операционные отклонения, поэтому либо функционал замораживается до конца, либо надо заложить еще сколько-то на расширение. Цифра, опять же, очень эмпирическая, но 30% считаю вполне обычной - так примерно и подходим к вашим 70% непланируемого времени.
И в этом нет ничего странного. Ровно такая же ситуация с планированием есть у одного из моих клиентов - они занимаются производством: какую-то часть смены они могут довольно точно планировать, а какая-то часть остается в режиме "может сделают, а может и нет". Относительно ИТ сферы у них, конечно, существенно меньший процент попадает на "может сделают, а может и нет" - но у ИТ своя специфика: уникальный каждый раз продукт, наличие R&D почти в каждом продукте - это высокорисковые операции.
Возможно, то, что ваши сейлы обещают клиентам жесткие сроки -- единственное, что позволяет вам получать свою зарплату, а не идти пополнять дефицитный рынок ИТ-специалистов; подумайте об этом
Этот аргумент сейлы часто говорят :) С другой стороны, им есть что продавать, пока разработка может сделать и выпустить что-нибудь нужно клиенту, а это мы регулярно делаем.
Ну, вы вроде сказали, что у вас продуктовый, а не заказной ИТ, значит, как минимум, разрабатывать под каждого не нужно, то есть и выпускать что-то нужное -- не надо, нужно находить клиентов на то, что было сделано, а не будет.
А если глазами сейлов посмотреть, вот что получилось: вам один раз сказали про жесткие сроки, вы попыхтели, уложились, второй раз сказали -- вы попыхтели и уложились, значит, так это работает с вами; значит, так это работает у вас в компании вообще, сейлы за такой уклад и премию могут получать свою, никакого резона отказываться от данной схемы у них нет
Посмотрите на ситуацию глазами заказчика и сэйлза. Заказчику не хватает фичи в софте. Фича нужна к какому-то сроку. Например, запланирована маркетинговая активность завязанная на этой фиче. Или регуляторка.
Заказчик идет к сэйлзу и говорит: "Вот тут допилите, мне надо". Заказчик ждет от вас четкий срок "КОГДА" т.к. от этого срока он будет планировать свою деятельность.
Что вы предлагаете сделать сэйлзу? Сказать заказчику "Да хрен знает когда сделаем, у нас тут распланировано все на три месяца вперед, мы вас поставим в очередь и может быть сделаем. А может быть не сделаем"?. Ну, в таком случае компания закроется очень быстро.
Вендор должен либо идеально оценивать сроки и укладываться в них (что мало кому удается) либо держать команду "на подстраховке", которая может заниматься тех.долгом, ресерчами, оптимизациями и т.д., но в случае "Надо" - подключиться к кор. задачам. Как только команда "подстраховки" начинает бОльшую часть времени заниматься продуктовыми задачами вместо развития - набирается еще доп. команда.
А если кто-то считает, что тех.долг, рефакторинг и оптимизация не нужны и не приносят денег - огласите список. Общественность должна знать своих героев %)
Жесткие сроки могут быть, как верно замечено, та же регуляторка. И по приоритетам в таких случаях обычно вопросов не возникает. Просто такие жесткие дедлайны не должны занимать весь скоуп.
Идеально оцененные сроки и укладывание в них - это возможно, но это означает, что план работ зафиксирован и не может быть изменен. А это прям редкость, всегда что-нибудь прилетает.
Наоборот - жесткие дедлайны ДОЛЖНЫ занимать ВЕСЬ скоуп. Вы же не знаете какие из сроков для заказчика - "жесткие". Вам кажется, что фича мелкая и ничего особо не меняет. А у заказчика под фичу уже запланировано десять активностей и миллиардный бюджет.
Поэтому, наоборот - весь скоуп должен быть ЖЕСТКО прибит к срокам. И вендор должен обспечить необходимое количество разработчиков, чтобы выполнять взятые на себя обязательства. С позиции заказчика неприемлима ситуация, когда сэйлз в ответ на поставленное ТЗ (напомню, ТЗ вендор внутри уже оценил и знает примерные сроки) говорит "Хрен знает, ну вроде через месяц сделаем". В этом случае заказчик сразу начинает искать другого вендора.
Иначе и в случае оплаты заказчик будет говорить "Ну, мы оплатим через месяц. А может не оплатим, хз". Так бизнес не ведут %).
Четкие договоренности - скоуп-срок-оплата - это крауегольный камень заказной разработки. Если вендор его не выдерживает - пора искать другого вендора.
P.S. Задача вендора и его менеджеров - рассчитывать различными методами потенциальную будущую нагрузку с учетом "влетов", появления новых клиентов и держать на готове необходимое количество сотрудников. Умение вести подобные расчеты, кстати, один из ключевых навыков ПМ, если я правильно помню %)
И оценкой менджмемента как раз будет являться то, насколько точно они предсказали нагрузку.
Вы же не знаете какие из сроков для заказчика - "жесткие". Вам кажется, что фича мелкая и ничего особо не меняет. А у заказчика под фичу уже запланировано десять активностей и миллиардный бюджет.
Если с клиентом выстроены хорошие коммуникации, то это не является тайной.
С позиции заказчика неприемлима ситуация, когда сэйлз в ответ на поставленное ТЗ (напомню, ТЗ вендор внутри уже оценил и знает примерные сроки) говорит "Хрен знает, ну вроде через месяц сделаем".
ТЗ - это про заказную разработку, а не про продуктовую как у нас.
Просто такие жесткие дедлайны не должны занимать весь скоуп.
А какое это имеет отношение к продажникам? Если у вас такое происходит, то тут скорее проект-менеджмент виноват
Идеально оцененные сроки и укладывание в них - это возможно, но это означает, что план работ зафиксирован и не может быть изменен. А это прям редкость, всегда что-нибудь прилетает.
А зачем обязательно идеально оценённые сроки? В чём проблема иметь сроки просто с запасом?
Ну то есть оцениваете с запасом на случай этих самых форм-мажоров. Если они будут, то уложитесь в срок. Если их не будет, то будете готовы раньше. Сомневаюсь что ваши клиенты из-за этого растроятся. И у вас будет возможность сдвинуть вперёд другие проекты или даже просто заняться техдолгом.
регуляторка. ... такие жесткие дедлайны не должны занимать весь скоуп.
А что делать, если вдруг набежало регуляторки?
По остальной статье - остался вопрос: "ОК, сроки не озвучиваем, а что делать?" :)
Вот так сдашь машину в ремонт, приходишь в назначенное время - а на подъёмнике висит другая машина, а твоя стоит в углу. И ты с пониманием говоришь себе - "сейлы виноваты, да и вообще делать работу в обещанные сроки западло, ведь у ремонтников есть другие важные дела, а мои дела подождут".
Если время назначено, значит срок обещали :) Я же и пишу, что обещал - надо выполнять, иначе клиент будет справедливо недоволен. А вот надо ли обещать, если понимаешь, что с большой вероятностью появится более выгодный заказ? Может надо как-то по другому начать общаться с клиентом, чем просто обещать то, что он хочет услышать?
Вас же никто не заставляет обещать именно то, что он хочет услышать. Обещайте срок через 10 лет, если это является вашей пессимистичной оценкой. Но срок должен быть твёрдым.
Лично у меня в жизни было много случаев, когда договор не заключался по причине того, что заказчик хотел одно, а я мог предложить с нашей стороны другое (в смысле сроков и денег). Обычно в таких случаях заказчик заключал договор с менее ответственными людьми, которые брали на себя обязательства и их проваливали (а таких людей всегда много). Некоторых из них заказчики потом разоряли в судах. Но согласованных сроков я не срывал.
Прикиньте, но с автосервисами это сплошь и рядом 😁
Если сейлы говорят клиентам неадекватные сроки, то пусть потом сами подключаются в разработку, чтобы в эти сроки уложиться.
Есть единственный работающий способ объяснить что-либо сейлам - заложить им это в компенсацию. Сорвали срок - не получили бонус.
Моментально научатся ставить корректные сроки
Сроки сейлы у нас не ставят, они хотят получить их с разработки и сообщить клиентам.
А если разработка говорит ",хз, мошт месяц, мошт три..." ? Или "сделаем за неделю" - а делают за месяц, т.к. у них перекос в ресурсах?
При таком отношении к клиенту этот клиент очень быстро отвалится. И сейл не получит свой бонус. Поэтому как раз сейл заинтересован выдать и согласовать с заказчиком реалистичный срок, чтобы заработать денег себе и компании.
Как объяснить сейлам, что обещание жестких сроков — это плохо