Хабрахабр

[Перевод] Кого вы пытаетесь впечатлить своими дедлайнами?

Подсказка: явно не ваших пользователей.

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

Они работают в Oracle.

Но корпоративные ценности — они как абонемент в спортзал — недостаточно их просто иметь. Удовлетворенность клиентов является одной из корпоративных ценностей компании Oracle.

Дедлайны — это хорошо. Одержимость клиентами — полезная вещь, но есть ещё одна вещь, которой одержимы многие компании — это сроки. Но когда вы работаете в компании с более чем двумя сотнями сотрудников, вам требуется некоторое понимание того, что происходит; примерное представление о том, когда ваши пользователи смогут использовать ваши новые свистелки и перделки. «Будет готово, когда я закончу» может быть отличной (или даже рекомендованной) стратегией для двух человек работающих над одним приложением.

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

Дедлайны нужны в первую очередь не клиентам, а менеджменту.

Главная цель — это цель

Или почему заморозка требований на время спринта — ужасная практика

Сроки хороши, они создают ощущение срочности, обеспечивают предсказуемость ваших процессов, и потому следует их иметь. 

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

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

В таком случае либо разработчик не сообщает об этом на следующем утреннем стендапе, потому что ну эй, ну не может же он сказать что ему нечего делать. Ситуация А. Допустим разработчик одолевает закон Паркинсона и заблаговременно закрывает задачи. Либо его менеджер назначает ему больше задач, непринужденно разморозив спринт, потому что ну не может же у него быть разработчик, который занимается, ну, ничем.

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

Но мы взяли на себя обязательства, так что не можешь ли ты попытаться завершить все в срок?». О чем он и сообщает на следующем митинге, на что менеджер проекта отвечает: «Окей, я услышал тебя. В это же время в голове у менеджера прокручивается картина как ему приходиться объяснять задержку выпуска на еженедельном sync-up Вице-Президенту компании по Разработке, который в свою очередь дает ему нравоучительный совет “Просто сделай это”, так что с тем же успехом лучше просто напрячься и попытаться сделать.

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

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

И мы даже не будем обсуждать грустный сценарий, когда крайний срок не соблюден, задача переходит на следующий спринт, а менеджеру приходится оправдывать задержку на своем следующем еженедельном sync-up перед Вице-Президентом по Разработке и выслушивать нравоучительные советы.

Ни в какой из моментов времени никто не задался вопросом: «Слушай, а что случится если мы переместим это на следующий спринт и не будем ни перед кем за это оправдываться? Видите ли вы проблему? Как это повлияет на пользователей?»

И то, как следует с ними обходиться — тоже. Гораздо чаще, чем следовало бы, дедлайны оказываются самовнушением.

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

Допустим вы получили запрос от клиента –– починить потенциально тривиальный и низкоприоритетный баг. Есть и другая проблема с заморозкой спринтов. Но вы следуете ПроцессуTM, а значит задача добавляется в бэклог вашей команды и может быть о ней вспомнят спустя несколько месяцев. Разработчик справится с ним за день. Вы могли бы разобраться с этим за пару дней, и сообщить пользователю по электронной почте что его проблема решена. Но вы потеряли возможность порадовать пользователя! Такие моменты люди запоминают, и именно такие вещи заставляют их рекомендовать ваш продукт своим друзьям.

1

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

Почему дедлайны ужасны

  1. Они создают неверные ожидания, противоречащие тому, что записано в ваших корпоративных ценностях. Потому что ваши корпоративные ценности не являются вашими ценностями, ваши настоящие ценности –- это неписаные ожидания и предубеждения (как хорошие, так и плохие).
  2. Люди будут срезать углы, если вы поставите их в жесткие условия. Кто-то забьет на тест, кто-то не обновит документацию. Вы отгрузите релиз вовремя, но какой ценой?
  3. Никто не согласится тратить время на поиск новых решений, пока менеджеры молятся на завершенные в срок задачи. Все так и будут писать фронтенд на MVC фреймворках, пока кто-нибудь в Фейсбуке не просрет какой-нибудь дедлайн.

Так что, работать без дедлайнов?

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

Но замораживать спринты –– так себе решение.

Он посоветовал «сопротивляться прокси между людьми внутри компании». 1.На эту тему хорошо высказался Джефф Безос в письме к акционерам 2016 года.

2.Джоэл Спольски рассказывает о продвинутых методах оценивания сроков в своей статье «Evidence Based Scheduling» (перевод на Хабре).

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»