Что такое дизайн спринты?

Last modified date

Comments: 0

Есть два источника по которым я разбиралась, что такое дизайн спринт: Фреймворк разработанный в Стенфорде (курсы на курсере) и его адаптация под разработку стартапов в Google (гайды гугла и курс на udacity).

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

Для каких ситуаций подходит?
Решения непонятных, нетривиальных задач, когда нужно выйти за рамки, так как “застопорились”, непонятно как и что делать. Например, есть проблема: “Падает посещаемость и непонятно в чем причина и как исправить” или “Стопор в разработке стратегии продукта, не понятно куда идти, какую фичу, направление делать” или “Нет хороших интерфейсных решений, все тупят ничего нормального предложить не могут”.

Кто участвует?
В любом из типов дизайн спринтов (в зависимости от типа каких то людей больше, каких то меньше) должны участвовать: Представители бизнеса, продажники (те кого волнует коммерческая сторона и которые знают, что происходит на рынке), дизайнеры и аналитики (кто обладает навыками количественного и качественного анализа и знаниями в нужной области), технические специалисты (которые знают, что можно и что нельзя сделать).

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

Какие варианты дизайн спринтов бывают
(в английском под словом дизайн подразумевается не только рисование интерфейсов, а вообще создание чего либо):

  • Дизайн спринт по проблемным сценариям – нахождение и выделение проблем и потребностей пользователей в определенной области. В результате получаются знания рынка, бизнес задач, конкурентов, пользователей, свежий взгляд на текущий продукт, проблемы пользователей и их потребности. И, как результат набор стратегических фич согласованных и понятных всем участникам. Ну и эффект “владения идеей”, все этой стратегией болеют, так как сами придумывали и вырабатывали фичи и верят в них.
  • Мотивационный дизайн спринт – до того как реализовывать какое то сложно решение можно провести спринт по “имитации” продукта удовлетворяющего пользовательские потребности и проверить какое решение будет действительно полезно конечному пользователю. Не интерфейсная его часть, а именно концепт решения. Тупой пример из учебника: Мы поняли, что у пользователя очень шумная машина. И придумали, что его спасет супер громкая магнитола. Имитируем решение и получаем кучу инсайтов, что это не удобно и возможно идеи, что лучше сделать звукоизоляцию.
  • Юзабили спринт – генерация прототипа интерфейсов и подтверждение, что конкретное наше интерфейсное решение пользователям удобно, полезно и с помощью него они могут решить проблему.
  • Архитектурный дизайн спринт – для тех. команды для разработки сложных систем, когда в одного рискованно принимать какие то базовые решения. Тоже обязательно представитель от бизнеса, чтобы можно было задавать вопросы о том что и как работает в мире. Это уже для супер сложных систем в которых переделка стоит дорого.

Как проходит дизайн спринт?
За основу дизайн спринтов взята модель из design thinking (что то отдаленно напоминающее наш ТРИЗ – теория решения изобретательских задач).
Делится на несколько этапов (в разных источниках могут быть разные примеры, в некоторых источниках 6 этапов) В общих чертах этапы следующие:

  1. Изучить/понять, определить/обозначить
  2. Нагенерить разнообразных идей (брейнсторминг)
  3. Решить/ выбрать
  4. Запрототипировать, визуализировать
  5. Проверить, протестировать, провалидировать

1. Изучить

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

2. Нагенерить разнообразных идей (брейнсторминг)

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

3. Решить/ выбрать

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

4. Запрототипировать

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

5. Проверка

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

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

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

Что по времени?
В гугле предлагают под это использовать целую неделю, каждый день отводится под отдельный этап. Они используют этот подход в своем инкубаторе для создания стартапов. Берут группу ребят три месяца их обучают по направлениям, потом прогоняют через этот цикл собранную команду и получают какую то идею с прототипом, которую уже дальше команда пытается вытащить на рынок. Таким образом за очень короткий срок (всего неделя) неопытные разработчики получают какие то знания о технологиях, бизнесе и UX. А так же погружение в предметную область и знания о рынке и пользователях, которые потребуются для создания продукта.

Есть варианты когда весь спринт укладывается в один день.

Так как метод используется для решения именно нетривиальных или сложных задач и принятие сложных решений, то речь идет о задачах выработки стратегических фич, например. В обычном режиме принятие таких решений группой специалистов может занимать до полугода. В сравнении с этими масштабами – пять дней дизайн спринта выглядят отличной альтернативной. К тому же дальше, с результатами этого метода начинают работать по lean startup подходу, что позволяет минимизировать риски. Т.е. смысла “рассусоливать” и до последнего искать единое верное решение – нет, так как бизнес процессы использующих этот подход контор заточены под быструю просейку и опробацию идей на рынке.

То что гайдбук выпустил гугл и “распиарил” его, не значит, что подход плохой и не стоит его использовать. Только все нужно делать к месту и с умом.

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

2. Очень важен опыт и навыки ведущего.

2.1 Любые групповые активности чреваты возможными конфликтами и неэффективностями. Для этого важно, чтобы ведущий обладал знаниями и опытом управления групповыми динамиками. Пример: из за нераспределенных ролей в команде два человека (тех. лид и руководитель отдела продаж, например) начинают “спорить о скобочках” (о какой то тупой фигне) и в итоге, если у ведущего недостаточно опыта и знаний все совещание превращается в холливор и выяснение кто круче. Часть этих проблем решается гайдлайнами в методичке гугла, но это просто подсказка как проводить совещания, а опять же, не серебряная пуля.

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

3. Недостаточная подготовка. Нет правильного места и подручного материала, не собрана правильная группа специалистов, не было времени пригласить пользователей. Заранее не объяснен формат и правила. Ну и куча, куча нюансов, которые не описаны в гайдбуках, просто потому что для этого нужно чтобы гайдбук был толщиной в войну и мир и тогда его никто читать не будет.

4. Не была проведена подготовительная работа по сбору имеющейся информации о рынке, области, конкурентах, существующем продукте и т.д.

5. Культура и структура организации должна быть заточена под принятие решений командой и команда должна быть. Поэтому этот метод в первую очередь позиционируется для стартапов, которые еще не успели нарастить мощный бюрократический аппарат “принятия решений”. Если сейчас в какой нибудь большой корпорации со сложившейся историей 15ть человек проведут дизайн спринт и примут какие то даже хорошие решения, все это может запросто быть похоронено на местах. Так как генерация решений и их внедрение и реализация – не одно и то же.

Итого:
Дизайн спринт – это просто супер умное название для специфически структурированного формата группового брейнсторминга.
Чтобы эта штука заработала и были позитивные результаты ее должен проводить опытный ведущий (фасилитатор), который сможет организовать группу. Т.е. есть у ведущего должен быть минимально необходимый порог знаний и навыков о том как проводить групповые совещания вообще, чтобы успешно воспользоваться “методичкой”.
Это всего лишь один из методов проведения групповых совещений, самые лучше результаты он дает в комбинации с подходами: бизнес моделирования рынков, итерационной проверки идей, гибкой организации и т.д.
У Стэнфорда более сложный и общий вариант, для решения любых задач. У Гугла упрощенный вариант более заточенный под стартапы и вывод новых продуктов на рынок.

Чем отличается от обычного брейнсторминга и почему все так с ним бегают.
“Методичка гугла” – это очень хорошее практическое пособие по проведению групповых совещаний нацеленных именно на создание и опробирование решений в IT. До дизайн спринтов все эти теории были и практические упражнения, некоторые не новые, но гугл первый собрал их в таком доступном, понятном и готовом для применения виде с практическими указаниями и рекомендациями. А так же завязал и адаптировал под специфический процесс разработки продуктов в IT, что тоже не мало и не очень тривиально.

Источники и что почитать посмотреть на тему:
https://en.wikipedia.org/wiki/Design_sprint
http://blog.udacity.com/2015/07/introducing-googles-design-sprint-process-in-product-design-new-course.html
https://developers.google.com/design-sprint/
https://www.coursera.org/learn/uva-darden-running-design-sprints

crincum

Leave a Reply

Your email address will not be published. Required fields are marked *

Post comment