О клиентоориентированности и дедлайнах

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

Одержимость клиентами может быть полезной вещью, но есть и другая, которой одержимы многие компании – сроки (дедлайны). “Будет сделано, когда я закончу” – это может быть хорошей стратегией если в компании над одним приложением работает один-два человека. Но когда в компании работает более сотни сотрудников, требуется понимание того, что происходит, представление о том, когда пользователи смогут использовать все ваши новые фишки.

Жестко установленные сроки – это плохо, и если у компании они есть, то можно пойти дальше и убрать пункт о клиентоориентированности из списка корпоративных ценностей. Верьте или нет, но пользователям все равно на заваленные спринты. Дедлайны нужны менеджменту, но никак не клиентам.

Почему заморозка требований на время спринта плохая практика

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

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

Речь идет о культуре разработки, которая предполагает замораживание целей на время спринта. Все собираются в самом начале спринта, дают оценки задачам (используя почему-то только числа из ряда Фибоначчи), а все что было решено на этой встрече должно быть сделано до завершения спринта – ничего нельзя изменять или переносить. Теория выглядит прекрасно, но эта тактика проигрышная. Давайте посмотрим почему.

Ситуация №1. Предположим, что разработчик преодолевает закон Паркинсона и заблаговременно закрывает свои задачи. В этом случае либо разработчик не сообщит об этом на следующем митинге, потому что это равносильно тому, что сказать “Мне нечего делать”, либо его менеджер назначает ему еще больше задач, непринужденно размораживая спринт, потому что не должно быть разработчика которому нечего делать.

Ситуация №2. Разработчик буду живым человеком, непринужденно отстает от графика. Например, проблемы с настройкой необходимого окружения заняли больше предполагаемого времени. И он уже не уверен, что успевает выполнить все до конца спринта. Об этом он сообщает на следующем митинге. И получает ответ от менеджера вида: “Я тебя понял. Но у нас есть обязательства, так что попытайся завершить все в срок”. В это самое время в голове менеджера всплывают картины объяснений задержки выпуска перед вышестоящим менеджментом, в которых он получает совет “Просто выполни все в срок”. Наш разработчик тем временем тратит пару ночей или выходных дней чтобы завершить все в срок. Менеджер “высоко оценивает” его старания на следующем митинге.

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

Рассматривать плачевный сценарий в котором не были соблюдены сроки и задача перешла в следующий спринт можно не рассматривать. В нем и так все понятно. Менеджеру предстоит оправдываться перед бизнесом и выслушивать нравоучительные советы.

Проблема этих ситуаций в том, что никто и ни в какой момент времени не задался вопросом “А что если мы переместим это на следующий спринт и не придется ни перед кем оправдываться? Как это скажется на пользователях?”.

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

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

Не нужно увлекаться процессами, упуская возможность достигнуть цели.

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

Дедлайн ужасен, потому что

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

Нужно ли работать без сроков?

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

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

Вместо заключения

В своем письме к акционерам в 2016 году Джефф Безос высказал очень хорошую мысль – “Сопротивляйтесь любым прокси между людьми внутри компании”.