Действительно ли за один спринт нельзя ничего успеть?

Окей, встреча начинается.

UX-дизайнер и продакт-менеджер:

Вот что мы протестировали на нескольких клиентах. Так пользователи увидят некоторые важные метрики, а остальные подробности — в таблице справа. Это имеет смысл? Сколько времени это займет?  

Разработчики:

Да, это имеет смысл. Насчет времени…

Команда разработки представляет что-то вроде этого:

Им нужно будет связать воедино несколько вещей. Таблицу нужно будет агрегировать по-новому, так что над этим нужно будет подумать. У них уже есть библиотеки для диаграмм и таблиц, но теперь сортируемая таблица и графики будут на одном экране.

Разработчики:

Вероятно, два или три спринта. У нас есть и другие задачи, поэтому всё может затянуться.

Они собираются разделиться. Если Билл, Дарья и Син сконцентрируются на разных частях проблемы, они смогут сделать все за четыре спринта. Они представляют себе примерно это:

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

Дарья из команды разработки высказывается:

Знаете, я думаю, что можно будет взять небольшую часть проблемы и отправить её в продакшн. Сейчас мы делаем много предположений. Как насчет этого:

Мы можем создать одну метрику для мобильного устройства (маленького экрана). Получить всего одно число. Так мы закончим за пару дней. Возможно, мы недооцениваем задачу агрегации, а создание фильтрации И диаграммы будет довольно сложным. Мне так кажется.

В комнате несколько секунд перешептываются.

ПМ: Возможно? Но в таком виде это не так ценно для пользователя.

UX: Я работал над этим макетом и тестировал его. Нам действительно здесь нужны движения? Я думаю, здесь теряется общая картина. И это уродливо.

Билл: Это так банально. Это поможет нам? Я бы хотел начать работать над агрегацией и сделать её качественно.

Син: А что насчет фронт-енда? Мы закончим это, а потом нам придется вернуться и планировать все снова. И мне здесь особо нечем заняться. Что я буду делать?

Все (кроме Дарьи): Не думаю, что это хорошая идея, Дарья.

Они представляют себе такую картину:

Это как если бы кто-то проверял вас каждый час, когда вы движетесь к очевидной цели. Трата времени, верно?

И кроме продакт-менеджера все думают:

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

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

Поэтому несколько наблюдений:

• Люди любят видеть большую картину. Маленькие шаги по достижению цели кажутся нам бессмысленными. Мы нетерпеливы.
• Мы не любим делать работу плохо. Команды живут в постоянном напряжении того, что менеджеры заставят их выпустить недоработанную функцию и двигаться дальше.
• Мы не любим микроменеджмент. Если мы разбиваем вещи на маленькие проблемы, мы чувствуем, что нам не доверяют.
• Работа над маленькими задачами имеет очевидные недостатки: больше встреч, более частая интеграция, большее количество pull-запросов. Другими словами, идея Дарьи кажется более долгой.
• Преимущества работы над маленькими задачами не так очевидны. Мне кажется, что предложение Дарьи лучше, так как приведет к более осмысленным решениям. Конечный продукт будет лучше, вы минимизируете риск и узнаете больше. Но из-за когнитивных искажений инкрементальная работа кажется глупым решением.
• Инкрементальная работа требует связи небольших задач с общей целью. Можно просто создать макет и сказать,что мы делаем это, но представить себе постепенный процесс гораздо сложнее. С этим могут помочь инструменты вроде User Story Mapping Джеффа Паттона. Но все равно этот процесс сложен и требует умственных усилий. Более того, мы часто очень догматично относимся к нашим представлениям о ценности. Вариант Дарьи кажется бесполезным для пользователя, но он позволяет многому научиться и показать пользователю лучший результат.

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

Итог

Работайте над небольшими задачами, даже если это “не имеет смысла”. Вам придется принять это на веру, потому что затраты будут реальными, а вот польза — отдаленной и теоретической. Никакого короткого пути нет. Сделайте что-нибудь за этот спринт.