ОК. Давайте начнем это совещание.

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

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

Таблица

Команда разработчиков:

Да. Это имеет смысл. Что касается сроков…

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

Таблица с точки зркния разработчиков

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

Команда разработчиков:

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

Им нужно разделять и властвовать. Если Билл, Дарья и Синь смогут сосредоточиться на разных частях проблемы, им нужно будет объединить все это в четыре спринта («может занять больше времени» … эта фраза работает как заклинание). По их мнению, все выглядит так:

Как выглядит спринт

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

«Прочее» (Other stuff на рисунке) — это уже совсем другая история.

Дарья — участник команды разработчиков программного обеспечения, говорит:

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

Разбить задачу на мелкие составляющие

Что нужно, чтобы сделать одну фичу на мобильном устройстве (маленький экран)? Всего один. Это мы сможем сделать все целиком за пару дней. Мы можем сильно упростить агрегирование, решить проблему с фильтрацией и составить таблицу. Сделать все сразу будет непросто. Я не знаю… это инстинктивная идея.

На десять секунд в комнате воцарилась тишина. А потом:

Продакт-менеджер: Ну… Возможно? Но это не принесет пользы пользователю. Мы это знаем

UX: Я много работал над этим макетом. Я протестировал его. Неужели нам действительно это нужно? Похоже, мы теряем общее видение. И это УЖАСНО.

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

Синь: Как насчет фронтенд разработки? Мы закончим эту фичу, а потом нам нужно будет вернуться и спланировать все заново. Плюс … если честно, мне здесь было бы нечего делать. Чем бы я занимался?

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

По их мнению, вот, что произойдет. И это не очень:

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

И в глубине сознания каждого (кроме продакт-менеджера) живет следующая мысль:

О, ты ЗНАЕШЬ, что произойдет. Мы будем работать небольшими итерациями, и внезапно продакт-менеджер набросится на нас и просто скажет выпустить этот супердерьмовый продукт. Минимально жизнеспособные продукты — это ОТСТОЙ!

Работа постепенно становится рискованной. А нам нравится делать качественную работу.

Итак…

Некоторые наблюдения:

  • Людям нравится видеть общую картину. Кажется, расточительным делать небольшие итерации, когда вы знаете свой пункт назначения — особенно итерации, которые могут быть переписаны. Мы нетерпеливые существа.
  • Мы ненавидим делать дерьмовую работу! Команды живут в постоянном страхе, что кто-то закричит «выпускайте как есть» и попросит вас двигаться дальше.
  • Мы все ненавидим, когда контролируют каждый наш шаг. Разбивка вещей на небольшие итерации может вызвать ощущение, что нам не доверяют.
  • Издержки, связанные с небольшой работой, очень очевидны (больше встреч, больше остановок, больше интеграций и т. д.). Другими словами, предложение Дарьи КАЖЕТСЯ ЗАМЕДЛИТ работу. Это будет ОЩУЩАТЬСЯ, как пустая трата времени.
  • Преимущества работы малыми частями не сразу очевидны. Предложение Дарьи — лучший вариант ИМХО, при условии, что за ним постепенно следуют более совершенные решения. Вы получите лучший конечный продукт, минимизируете риск и раньше научитесь. Но эти выгоды возникают, когда мы открываем для себя что-то новое! Поэтому мы не можем «знать» эти вещи на стадии планирования. Множество когнитивных предубеждений заставляет поэтапную работу небольшими частями (вариант Дарьи) казаться глупой.
  • Работа малыми частями, требует связать небольшую работу с общей картиной. Трудность в том, что нам нужно обрабатывать вещи с разными разрешениями. Легко показать макет и сказать «мы создаем это». Гораздо сложнее визуализировать постепенный прогресс. Инструменты, такие User Story Mapping от Jeff Patton помогают. Но это все еще сложно, и требует тренировки ума. Еще одна проблема… мы часто очень догматичны в отношении ценности. Вариант Дарьи — «дерьмовый» (не ценный для пользователя), но мы бы узнали много, и мы могли бы показать это клиенту.

Ремарка…

У меня были опытные друзья-разработчики, которые зареклись от поэтапной разработки. Мне пришло в голову, что более опытные люди могут погружаться на более длительное время, прежде чем вынырнуть на воздух… по крайней мере с технологической точки зрения (еще много нужно узнать о поведении пользователя). Тем не менее, большинство из них работает малыми частями. Это скорее привычка. Другими словами, они делают это автоматически. Они не думают, что делают… но они это делают.

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

Вывод

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

Идите и сделайте ЧТО-НИБУДЬ за один спринт!