Привет, Хабр! Меня зовут Владимир Казаков, я руковожу продуктом «Обучение» в МТС Линк. В его основе — решение для вебинаров, с которого мы начали 16 лет назад как самостоятельный продукт. Сейчас наша платформа для обучения решает более широкий круг задач, к ней добавились и новые продукты (Курсы, Формы). Растет ответственность, число вовлеченных команд, но кое-что остается неизменным — сложность с проставлением дедлайнов.

После очередного заруба и обсуждения, кто — продакты или разработчики — определяют сроки и несут ответственность за них, у меня родилось желание расписать все с максимально живыми примерами. Так и появилась эта «тру стори». Под катом — иллюстрация того, как важно взаимопонимание в команде на примере одной отдельно взятой семьи и стандартной бытовой задачи.

Дисклеймер: на самом деле некоторая часть диалога была выдумана для большей наглядности. Так что все совпадения случайны.

Действующие лица:
П — жена в роли Продакта.
Р — я в роли Разработчика.

День первый

11:00

П: Приоритетная таска! Нужно сделать замок в калитке, а то от старых хозяев навесной замок остался, неудобно ходить. Когда будет готово?

Р: Нужен ресерч, так что хз, но вроде недолго. Справлюсь за два часа.

Первоначальная оценка закоммичена в задачу «замок в калитке». Разработчик берет рулетку, линейку, листок в клеточку, идет измерять ширину профиля, толщину, расстояние до ригеля.

Р: Тут такое дело: профиль тонкий (5 см), нужно искать либы и компоненты, готовые для узкопрофильного замка. Могу ехать в магазин?

П: Ты че, куда? Потом сгоняешь. У нас еще задача «домашка сына» не в релизе. Помоги разблокировать.

Таким образом принято продуктовое решение снизить приоритет задачи «замок в калитке» для поддержки junior-разработчика с его эпиком по английскому языку.

Разработчик спустя какое-то время все-таки оказывается в магазине, достает фотку листочка в клеточку, приобретает нужные модули и платные компоненты (замок, ручки, прочие полезности).

День второй

11:00

Утренний стендап с кормлением детей прошел, пора браться за задачи по приоритетам.

П: Ну что, как там?
Продакт кивает на калитку. Разработчик тихо бурчит, что с таски холд не сняли, а уже спрашивают.

Р: Все ок, платные компоненты залиты на верстак, сейчас приступаю.

П: Когда будет готово?

Разработчик прикидывает в уме количество пропилов болгаркой и сверления дырок. В формате точного времени готовности дает технический коммит с учетом задействованных человекочасов.

Р: Часа два, к 13:00 выкачу на прод.

День второй

11:30

Р: Такая фигня: сверло есть только на 8, но надо на 10. Лучше на 12, но это тогда еще дрель покупать. Думаю, на 10 норм. Могу сгонять в магазин?

К счастью ехать всего 5 минут.

П: Погоди, давай тогда еще сделаем по пути задачу «подготовка к ужину». Пойдем, посмотрим, что надо купить там рядом.

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

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

12:50

До срока коммита осталось 10 минут. Чистого времени работы: полчаса, которые частично пересекаются с эпиком «Поездка в магазин».

Р: Привет, я вернулся. Вот продукты. Я пошел, доделаю.

П: Стоять! А как же таска «обед»? Без него увеличивается риск «профессиональное выгорание». Давай детей кормить, затем возьми задачи «уложить дочку» и «домашка с сыном». Калитку доделаешь после них.

Для выполнения менее приоритетных, но более срочных тасок принято продуктовое решение не снимать холд с таски «замок в калитке».

16:00

С точки зрения времени готовности срок коммита превышен в два раза. Разработчик сверлит «технологические отверстия», по пути решает нетривиальный блокер «ответная планка», возникшую из-за слишком большого расстояния между створками.

П: Ну что, как там?

Разработчик рассказывает о таске, которой не было при декомпозиции, ее причинах и возникших сложностях: поиске куска профиля, выпиливании болгаркой кромки, подгонки ее толщины, поиске варианта заглубления саморезов.

П: Ничего непонятно, но очень интересно, держи в курсе.

16:10

Р: Тут еще фигня. Замок на проде, все зашибись и работает, но при ресерче не учли ширину декоративных накладок на ручки и замочную скважину. Если их приделать, то теперь ответная планка мешает, и калитка не будет открываться и закрываться.

П: Ну, убери нафиг планку.

Разработчик объясняет, что без нее створка будет болтаться, и по-другому нельзя. Вот совсем никак.

П: Когда готово-то будет? Обещал еще два часа назад!

Р: Сейчас поресерчу, что можно сделать.

16:30

Р: Ну смотри. Могу ручку на веревочку привязать, тогда, когда надо открыть, ты ее берешь, вставляешь, потом вот так убираешь, а то…

П: Не, нафиг, тестирование не пройдено. UX плохой, переделывай.

Разработчик смотрит на свою болгарку, с которой все в этом мире становится гораздо проще.

Р: Согласен. Тогда могу эти накладки декоративные тоже пилой фигануть. В акцептанс-критериях нет ограничения по внешнему виду с торца двери, колхозный легаси потом замажем чем-нибудь. Техдолг небольшой. Могут быть слайды с прочностью конструкции, но по нагрузочному тестированию в акцептанс-критериях тоже нет ничего. Устроит?

П: Иди нафиг со своей болгаркой. Давай нормально.

Принято продуктовое решение о дополнении акцептанс-критериев внешним видом с торца, прохождении UX и нагрузочных тестов.

Р: Тогда нужны другие ручки. Более узкие, чем эти. Могу ехать в магазин?

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

П: Стоять! А как же сделать таску «шашлык на ужин»? Клиент в лице тещи уже едет, готово должно быть в 19:00, в магазин уже не успеешь.

Р: Ну, шашлык так шашлык — время есть еще.

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

22:00.

Разработчик успешно сдал таски «шашлык на ужин», «овощи и картошка в казане на гарнир», «покорми детей» и «уложи детей».

П: (с интонациями скрам-мастера на ретро) Ну вот, опять за спринт ничего не сделали. Даже таску с калиткой не зарелизили, хотя ты коммитился к 13:00 успеть!

Р: …

Замок не на проде, показать на демо нечего, спринт провален.

День третий

14:00

Р: Привет! Я заскочил в магазин — теперь есть новые ручки. Остается прикрутить.

П: А обещал еще неделю назад! Задачу поставили, обсудили, декомпозировали, а ты только теперь купил все, что нужно…

Р: …

Метрика time-to-market выросла в десять раз из-за последовательности продуктовых решений и нескольких технических просчетов, связанных с недостатком профильной экспертизы и специфичным легаси от прошлого владельца. При этом чистое время работы и сторипоинты не менялись на протяжении выполнения таски.

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

• Убрать задачу «обед» и работать с повышенным риском «профессиональное выгорание».

• Принять сопутствующие риски и доверить самостоятельное выполнение задач «укладывание» и «домашку» junior-разработчикам.

• Не совмещать подзадачу «купить замок» с задачей «закупка продуктов».

Тогда задача могла бы быть выполнена если не к 13:00, то к 14:00 шестого дня, что даже не привело бы к сдвигу важного эпика «шашлык на ужин», и спринт можно было бы считать успешным, оценку трудоемкости — приемлемо точной, а сдвиг сроков — не критичным.

 14:30

Р: Я закончил работу, готов браться за следующую важную задачу.

П: Отлично! У дивана как раз сломался подъемный механизм.

К счастью ресерч был проведен еще раньше, закупка была выполнена в рамках эпика «поездка в магазин» и нужные модули уже залиты в проект «запчасти» и лежат в соответствующем репозитории.

Да, планирование — это сложно

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

Есть ли готовые решения для таких дилемм? Навскидку я вижу только два варианта и они, блин, противоречат друг другу.

Спустить дедлайн сверху

Ключевая задача планирования — ответы на вопросы «когда будет готово?» и «что для этого нужно?». В моем примере выше задача «шашлык на ужин» должна быть сделана к определенному часу, не раньше и не позже. При этом есть альтернативные варианты — заказать пиццу — и эта задача уже будет не нужна.

Часто менеджер не может оценить, реализуема ли вообще задача к определенному сроку. Тогда ему вместе с разработчиком остается только управлять объемом фич или их качеством. Если мы хотим приготовить грибной суп на обед, то нужно сходить в лес и принести минимум десять подберезовиков. Принести нужно именно к обеду, а не вечером. И хорошо, если менеджер понимает, что на дворе февраль и грибы есть только в магазине…

Спросить трудоемкость у самих разработчиков

И поставить эту цифру в план с каким-то дополнительным таймингом. Но что есть у нас для оценки сроков? Тоже не очень много.

«Гибко-жесткое» планирование

Одна часть задач расписана по слотам (эпик «шашлык на ужин» привязан к ужину и его не подвинуть), а остальные раскиданы по принципу «когда руки дойдут». Этот подход можно было применить в моем примере выше. Задачи «обед», «укладывание детей» тоже жестко привязаны ко времени, а «замок в калитке» можно делать по мере появления свободных слотов.

Казалось бы, что может быть проще? Вот тебе люди, задачи и оценки — сиди и рисуй свои диаграммы Ганта. Но управлять этим — та еще морока. Небольшая накладка, которая сдвигает одну задачу на час, может перенести ее на неделю. Не успел отдать таску в тестирование — коллеги закрыли набор фичей в текущий релиз, а следующий планируется только через неделю. Знакомо?

Да, бывают ситуации, в которых все задачи легко прогнозировать. Но есть обратный случай, когда «хрен его знает, надо ресерчить». Как правило, срок исследования вообще не предсказуем, а после него останутся только минимальные усилия, чтобы результат оказался на проде. Часто такие исследования по сути являются перебором вариантов. Когда решение найдено — все становится очень простым. Я такие задачи сравниваю с поиском грибов в лесу: можно выйти на опушку и набрать полную корзинку за 5 минут, а можно весь день ходить и ничего не найти.

Расчет по «средним показателям»

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

Предположим, за прошлое лето я собрал 5 кг грибов за пять заходов в лес. В среднем это по 1 кг за раз. Но на самом деле я 3 раза я вернулся ни с чем, один раз принес 1 кг, и один раз — сразу 4кг. Прогнозировать в таких случаях исходя из средних — нельзя, о чем нам говорит теория статистики. Более живой пример — средний километраж поездок в вашей машине. Он совершенно точно не говорит о том, что завтра вы проедете именно 30 или 50 км, даже если средний показатель за прошлый месяц именно такой. Может вы вообще за руль не сядете.

Что имеем в сухом остатке? Нужно уметь договариваться!

Единственного и 100% рабочего способа оценки сроков сложных задач на самом деле не существует. Планирование возможно только при очень плотном взаимодействии продакта и разработчика. Работая как одна команда, они смогут слышать друг друга, видеть реальный результат и понимать, где можно подвинуть или упростить задачу, где забить и наплодить техдолг или упороться и работать по ночам. К сожалению я сейчас вижу только такой вариант. Нужно уметь договариваться — и это гарантирует успешное достижение целей проекта.