Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Подсказка: явно не ваших пользователей.
Поднимите руку те, чья компания провозгласила «Клиентоориентированность» как одну из своих корпоративных ценностей. Для тех из вас, кто читает этот текст на Хабре и не видит аудиторию: почти весь зал поднял руку, кроме пары человек сзади.
Они работают в Oracle.
Удовлетворенность клиентов является одной из корпоративных ценностей компании Oracle. Но корпоративные ценности — они как абонемент в спортзал — недостаточно их просто иметь.
Одержимость клиентами — полезная вещь, но есть ещё одна вещь, которой одержимы многие компании — это сроки. Дедлайны — это хорошо. «Будет готово, когда я закончу» может быть отличной (или даже рекомендованной) стратегией для двух человек работающих над одним приложением. Но когда вы работаете в компании с более чем двумя сотнями сотрудников, вам требуется некоторое понимание того, что происходит; примерное представление о том, когда ваши пользователи смогут использовать ваши новые свистелки и перделки.
Смею утверждать, что жестко установленные сроки — это плохие сроки, и если у вашей компании такие есть, возможно следует пойти еще дальше, и убрать пункт об «клиентоориентированности» из списка корпоративных ценностей. Потому что, хотите верьте, хотите нет, пользователям плевать на заваленные спринты.
Дедлайны нужны в первую очередь не клиентам, а менеджменту.
Сроки хороши, они создают ощущение срочности, обеспечивают предсказуемость ваших процессов, и потому следует их иметь.
Но есть хорошие и есть плохие сроки. И есть компании, в которых сроки высекаются на камне, а те кто заваливают дедлайны в одном шаге от увольнения. Вот тогда и начинаются проблемы.
Я говорю о культуре разработки, в которой принято замораживать цели на время спринта: когда все собираются в самом начале, дают оценки задачам, непременно с использованием только чисел Фибоначчи, и что бы не было решено на этих встречах, все это должно быть сделано до завершения спринта — ничего не изменяется и не переносится. В теории это звучит складно, но думаю что такая тактика проигрышная при любом раскладе:
Ситуация А. Допустим разработчик одолевает закон Паркинсона и заблаговременно закрывает задачи. В таком случае либо разработчик не сообщает об этом на следующем утреннем стендапе, потому что ну эй, ну не может же он сказать что ему нечего делать. Либо его менеджер назначает ему больше задач, непринужденно разморозив спринт, потому что ну не может же у него быть разработчик, который занимается, ну, ничем.
Ситуация B. Разработчик, будучи разработчиком, отстает от графика. Проблемы с настройкой окружения отняли больше времени, чем предполагалось, и он уже не уверен, что успеет все сделать до конца недели.
О чем он и сообщает на следующем митинге, на что менеджер проекта отвечает: «Окей, я услышал тебя. Но мы взяли на себя обязательства, так что не можешь ли ты попытаться завершить все в срок?». В это же время в голове у менеджера прокручивается картина как ему приходиться объяснять задержку выпуска на еженедельном sync-up Вице-Президенту компании по Разработке, который в свою очередь дает ему нравоучительный совет “Просто сделай это”, так что с тем же успехом лучше просто напрячься и попытаться сделать.
Так что разработчик, будучи разработчиком, уходит на пару ночей, или возможно выходных дней, и завершает работу в срок. А его менеджер высоко оценивает его усилия на следующем митинге. Делов-то.
Или все не так уж и гладко? Сроки были соблюдены, и работа была успешно сделана, но был создан неверный прецедент. Недавно нанятый вчерашний студент с выпученными глазами получил сигнал о том, что перерабатывать по выходным — это правильно.
И мы даже не будем обсуждать грустный сценарий, когда крайний срок не соблюден, задача переходит на следующий спринт, а менеджеру приходится оправдывать задержку на своем следующем еженедельном sync-up перед Вице-Президентом по Разработке и выслушивать нравоучительные советы.
Видите ли вы проблему? Ни в какой из моментов времени никто не задался вопросом: «Слушай, а что случится если мы переместим это на следующий спринт и не будем ни перед кем за это оправдываться? Как это повлияет на пользователей?».
Гораздо чаще, чем следовало бы, дедлайны оказываются самовнушением. И то, как следует с ними обходиться — тоже.
Идеальным решением было бы просто поговорить с заинтересованными сторонами — продуктовой командой или командой продаж, разузнав у них, может ли задержка привести к потере клиента. И если это так, то безусловно выделить дополнительные часы, и возможно поработать в выходные. В таком случае молодой студент получил бы сигнал о том, что компания действительно заботится о своих клиентах, а не о своих спринтах.
Есть и другая проблема с заморозкой спринтов. Допустим вы получили запрос от клиента –– починить потенциально тривиальный и низкоприоритетный баг. Разработчик справится с ним за день. Но вы следуете ПроцессуTM, а значит задача добавляется в бэклог вашей команды и может быть о ней вспомнят спустя несколько месяцев. Но вы потеряли возможность порадовать пользователя! Вы могли бы разобраться с этим за пару дней, и сообщить пользователю по электронной почте что его проблема решена. Такие моменты люди запоминают, и именно такие вещи заставляют их рекомендовать ваш продукт своим друзьям.
Не слишком увлекайтесь процессами — из-за них вы может упустить вашу цель.1
Я также считаю, что заморозка спринтов или любые другие ограничивающие практики являются признаком присущего внутри компании взаимного недоверия, как результат более фундаментальных проблем на уровне культуры общения, но об этом в следующий раз.
Конечно нет. Устанавливайте сроки, но делайте их гибкими. Насколько гибкими могут быть ваши сроки определяет ваша цель. Если несоблюдение указанного срока может привести к потере миллиона долларов, коэффициент вашей гибкости должен быть нулевым. Но если это очередная фича, всегда есть пространство для маневра. А еще можно поэкспериментировать с более сложными вероятностными способами оценки сроков, вместо игр в генерацию чисел Фибоначчи пальцем в небо.2
Но замораживать спринты –– так себе решение.
1. На эту тему хорошо высказался Джефф Безос в письме к акционерам 2016 года. Он посоветовал «сопротивляться прокси между людьми внутри компании».
2. Джоэл Спольски рассказывает о продвинутых методах оценивания сроков в своей статье «Evidence Based Scheduling» (перевод на Хабре).
Поднимите руку те, чья компания провозгласила «Клиентоориентированность» как одну из своих корпоративных ценностей. Для тех из вас, кто читает этот текст на Хабре и не видит аудиторию: почти весь зал поднял руку, кроме пары человек сзади.
Они работают в Oracle.
Удовлетворенность клиентов является одной из корпоративных ценностей компании Oracle. Но корпоративные ценности — они как абонемент в спортзал — недостаточно их просто иметь.
Одержимость клиентами — полезная вещь, но есть ещё одна вещь, которой одержимы многие компании — это сроки. Дедлайны — это хорошо. «Будет готово, когда я закончу» может быть отличной (или даже рекомендованной) стратегией для двух человек работающих над одним приложением. Но когда вы работаете в компании с более чем двумя сотнями сотрудников, вам требуется некоторое понимание того, что происходит; примерное представление о том, когда ваши пользователи смогут использовать ваши новые свистелки и перделки.
Смею утверждать, что жестко установленные сроки — это плохие сроки, и если у вашей компании такие есть, возможно следует пойти еще дальше, и убрать пункт об «клиентоориентированности» из списка корпоративных ценностей. Потому что, хотите верьте, хотите нет, пользователям плевать на заваленные спринты.
Дедлайны нужны в первую очередь не клиентам, а менеджменту.
Главная цель — это цель
Или почему заморозка требований на время спринта — ужасная практика
Сроки хороши, они создают ощущение срочности, обеспечивают предсказуемость ваших процессов, и потому следует их иметь.
Но есть хорошие и есть плохие сроки. И есть компании, в которых сроки высекаются на камне, а те кто заваливают дедлайны в одном шаге от увольнения. Вот тогда и начинаются проблемы.
Я говорю о культуре разработки, в которой принято замораживать цели на время спринта: когда все собираются в самом начале, дают оценки задачам, непременно с использованием только чисел Фибоначчи, и что бы не было решено на этих встречах, все это должно быть сделано до завершения спринта — ничего не изменяется и не переносится. В теории это звучит складно, но думаю что такая тактика проигрышная при любом раскладе:
Ситуация А. Допустим разработчик одолевает закон Паркинсона и заблаговременно закрывает задачи. В таком случае либо разработчик не сообщает об этом на следующем утреннем стендапе, потому что ну эй, ну не может же он сказать что ему нечего делать. Либо его менеджер назначает ему больше задач, непринужденно разморозив спринт, потому что ну не может же у него быть разработчик, который занимается, ну, ничем.
Ситуация B. Разработчик, будучи разработчиком, отстает от графика. Проблемы с настройкой окружения отняли больше времени, чем предполагалось, и он уже не уверен, что успеет все сделать до конца недели.
О чем он и сообщает на следующем митинге, на что менеджер проекта отвечает: «Окей, я услышал тебя. Но мы взяли на себя обязательства, так что не можешь ли ты попытаться завершить все в срок?». В это же время в голове у менеджера прокручивается картина как ему приходиться объяснять задержку выпуска на еженедельном sync-up Вице-Президенту компании по Разработке, который в свою очередь дает ему нравоучительный совет “Просто сделай это”, так что с тем же успехом лучше просто напрячься и попытаться сделать.
Так что разработчик, будучи разработчиком, уходит на пару ночей, или возможно выходных дней, и завершает работу в срок. А его менеджер высоко оценивает его усилия на следующем митинге. Делов-то.
Или все не так уж и гладко? Сроки были соблюдены, и работа была успешно сделана, но был создан неверный прецедент. Недавно нанятый вчерашний студент с выпученными глазами получил сигнал о том, что перерабатывать по выходным — это правильно.
И мы даже не будем обсуждать грустный сценарий, когда крайний срок не соблюден, задача переходит на следующий спринт, а менеджеру приходится оправдывать задержку на своем следующем еженедельном sync-up перед Вице-Президентом по Разработке и выслушивать нравоучительные советы.
Видите ли вы проблему? Ни в какой из моментов времени никто не задался вопросом: «Слушай, а что случится если мы переместим это на следующий спринт и не будем ни перед кем за это оправдываться? Как это повлияет на пользователей?».
Гораздо чаще, чем следовало бы, дедлайны оказываются самовнушением. И то, как следует с ними обходиться — тоже.
Идеальным решением было бы просто поговорить с заинтересованными сторонами — продуктовой командой или командой продаж, разузнав у них, может ли задержка привести к потере клиента. И если это так, то безусловно выделить дополнительные часы, и возможно поработать в выходные. В таком случае молодой студент получил бы сигнал о том, что компания действительно заботится о своих клиентах, а не о своих спринтах.
Есть и другая проблема с заморозкой спринтов. Допустим вы получили запрос от клиента –– починить потенциально тривиальный и низкоприоритетный баг. Разработчик справится с ним за день. Но вы следуете ПроцессуTM, а значит задача добавляется в бэклог вашей команды и может быть о ней вспомнят спустя несколько месяцев. Но вы потеряли возможность порадовать пользователя! Вы могли бы разобраться с этим за пару дней, и сообщить пользователю по электронной почте что его проблема решена. Такие моменты люди запоминают, и именно такие вещи заставляют их рекомендовать ваш продукт своим друзьям.
Не слишком увлекайтесь процессами — из-за них вы может упустить вашу цель.1
Я также считаю, что заморозка спринтов или любые другие ограничивающие практики являются признаком присущего внутри компании взаимного недоверия, как результат более фундаментальных проблем на уровне культуры общения, но об этом в следующий раз.
Почему дедлайны ужасны
- Они создают неверные ожидания, противоречащие тому, что записано в ваших корпоративных ценностях. Потому что ваши корпоративные ценности не являются вашими ценностями, ваши настоящие ценности –- это неписаные ожидания и предубеждения (как хорошие, так и плохие).
- Люди будут срезать углы, если вы поставите их в жесткие условия. Кто-то забьет на тест, кто-то не обновит документацию. Вы отгрузите релиз вовремя, но какой ценой?
- Никто не согласится тратить время на поиск новых решений, пока менеджеры молятся на завершенные в срок задачи. Все так и будут писать фронтенд на MVC фреймворках, пока кто-нибудь в Фейсбуке не просрет какой-нибудь дедлайн.
Так что, работать без дедлайнов?
Конечно нет. Устанавливайте сроки, но делайте их гибкими. Насколько гибкими могут быть ваши сроки определяет ваша цель. Если несоблюдение указанного срока может привести к потере миллиона долларов, коэффициент вашей гибкости должен быть нулевым. Но если это очередная фича, всегда есть пространство для маневра. А еще можно поэкспериментировать с более сложными вероятностными способами оценки сроков, вместо игр в генерацию чисел Фибоначчи пальцем в небо.2
Но замораживать спринты –– так себе решение.
1. На эту тему хорошо высказался Джефф Безос в письме к акционерам 2016 года. Он посоветовал «сопротивляться прокси между людьми внутри компании».
2. Джоэл Спольски рассказывает о продвинутых методах оценивания сроков в своей статье «Evidence Based Scheduling» (перевод на Хабре).
