Окей, встреча начинается.
UX-дизайнер и продакт-менеджер:
Вот что мы протестировали на нескольких клиентах. Так пользователи увидят некоторые важные метрики, а остальные подробности — в таблице справа. Это имеет смысл? Сколько времени это займет?
Разработчики:
Да, это имеет смысл. Насчет времени…
Команда разработки представляет что-то вроде этого:
Им нужно будет связать воедино несколько вещей. Таблицу нужно будет агрегировать по-новому, так что над этим нужно будет подумать. У них уже есть библиотеки для диаграмм и таблиц, но теперь сортируемая таблица и графики будут на одном экране.
Разработчики:
Вероятно, два или три спринта. У нас есть и другие задачи, поэтому всё может затянуться.
Они собираются разделиться. Если Билл, Дарья и Син сконцентрируются на разных частях проблемы, они смогут сделать все за четыре спринта. Они представляют себе примерно это:
Они могут работать приблизительно в структуре спринта, но их задачи не влезают в спринт, поэтому они не останавливаются на этом.
Дарья из команды разработки высказывается:
Знаете, я думаю, что можно будет взять небольшую часть проблемы и отправить её в продакшн. Сейчас мы делаем много предположений. Как насчет этого:
Мы можем создать одну метрику для мобильного устройства (маленького экрана). Получить всего одно число. Так мы закончим за пару дней. Возможно, мы недооцениваем задачу агрегации, а создание фильтрации И диаграммы будет довольно сложным. Мне так кажется.
В комнате несколько секунд перешептываются.
ПМ: Возможно? Но в таком виде это не так ценно для пользователя.
UX: Я работал над этим макетом и тестировал его. Нам действительно здесь нужны движения? Я думаю, здесь теряется общая картина. И это уродливо.
Билл: Это так банально. Это поможет нам? Я бы хотел начать работать над агрегацией и сделать её качественно.
Син: А что насчет фронт-енда? Мы закончим это, а потом нам придется вернуться и планировать все снова. И мне здесь особо нечем заняться. Что я буду делать?
Все (кроме Дарьи): Не думаю, что это хорошая идея, Дарья.
Они представляют себе такую картину:
Это как если бы кто-то проверял вас каждый час, когда вы движетесь к очевидной цели. Трата времени, верно?
И кроме продакт-менеджера все думают:
Уже понятно, что здесь происходит. Мы будем работать над маленькой задачей, а потом внезапно менеджер скажет нам выпускать ее в продакшн в очень плохом состоянии. MVP — отстой.
Инкрементальная работа кажется рискованной. Потому что все мы любим делать работу хорошо.
Поэтому несколько наблюдений:
- Люди любят видеть большую картину. Маленькие шаги по достижению цели кажутся нам бессмысленными. Мы нетерпеливы.
- Мы не любим делать работу плохо. Команды живут в постоянном напряжении того, что менеджеры заставят их выпустить недоработанную функцию и двигаться дальше.
- Мы не любим микроменеджмент. Если мы разбиваем вещи на маленькие проблемы, мы чувствуем, что нам не доверяют.
- Работа над маленькими задачами имеет очевидные недостатки: больше встреч, более частая интеграция, большее количество pull-запросов. Другими словами, идея Дарьи кажется более долгой.
- Преимущества работы над маленькими задачами не так очевидны. Мне кажется, что предложение Дарьи лучше, так как приведет к более осмысленным решениям. Конечный продукт будет лучше, вы минимизируете риск и узнаете больше. Но из-за когнитивных искажений инкрементальная работа кажется глупым решением.
- Инкрементальная работа требует связи небольших задач с общей целью. Можно просто создать макет и сказать,что мы делаем это, но представить себе постепенный процесс гораздо сложнее. С этим могут помочь инструменты вроде User Story Mapping Джеффа Паттона. Но все равно этот процесс сложен и требует умственных усилий. Более того, мы часто очень догматично относимся к нашим представлениям о ценности. Вариант Дарьи кажется бесполезным для пользователя, но он позволяет многому научиться и показать пользователю лучший результат.
Многие знакомые мне senior-разработчики ругают инкрементальную разработку. Я думал, что более опытные специалисты просто берут на себя большие задачи. Но многие из них все равно работают над маленькими задачами, просто игнорируя формальное разделение и оценку. Другими словами, они делают это автоматически.
Итог
Работайте над небольшими задачами, даже если это “не имеет смысла”. Вам придется принять это на веру, потому что затраты будут реальными, а вот польза — отдаленной и теоретической. Никакого короткого пути нет. Сделайте что-нибудь за этот спринт.