Как мы строим космолеты. Составляющие процесса Discovery, результаты и DOR по-нашему

Привет! С вами Таня Тихомирова, Lead Systems Analyst и SA Community Lead. Сегодня я хочу поговорить о составляющих Discovery-процесса и дать вам полноценный шаблон DOR, который можно использовать при разработке любой фичи или целой системы. Без боли и слез.

Сейчас же начать хочется с понимания, что же такое Discovery-процесс.

Частый вопрос, кстати. Я уже не удивляюсь, поэтому хочу начать с него. Это вся наша командная деятельность, связанная с разработкой нового продукта или новой фичи по запросу бизнеса, тестированием, отладкой и поставкой продукта в продуктив (delivery-процесс), то есть до клиента. При этом в основе процесса сейчас чаще используется Scrum или Kanban. Аня уже разбирала различные подходы к Discovery-процессу в своей статье. А в этой я хочу поговорить о самом процессе и подарить вам эффективный набор артефактов, который поможет спроектировать и реализовать любую фичу, модуль или систему.

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

Понять, что хочет бизнес, собрав достаточно информации для старта процесса разработки и спроектировать решение с учетом всех потребностей — основная задача discovery-процесса. По сути это исследование. Вся команда, начиная с владельца продукта (Product Owner или просто «PO») бросает все силы на то, чтобы понять, что требуется сделать на этот раз.

PO в сложных проектах, впрочем, как и во всех остальных, отвечает за сроки своей головой, в отличие от команды, которая варится в творческом процессе, часто эти самые сроки растягивая. Основная задача РО растягивания не допустить, в сроки уложиться, результат выдать согласно ожиданиям бизнеса. Получается, владелец продукта как бы промежуточное звено между бизнесом и командой, даже не совсем ее часть, и совсем не руководитель, но как-то очень близко к нему.

Потому что если сроки затягиваются, что обычно происходит? Да, досыпают побольше людей, и часто это идея принадлежит именно РО. Потому что, как всем известно, что если «одна женщина родит ребенка за девять месяцев, то девять женщин за месяц могут родить одного». Шутка. Тошнотворная фраза для толковых менеджеров, как и в жизни, совершенно нерабочая в нашем любимом «кровавом» enterprise. Но что еще можно придумать? Неужели больше нечего? А что если оптимизировать discovery-процесс?

Каждый раз, на очередном проекте, РО закатывает глаза: «Ой, ну мы все уже читали, знаем». Вы же, мои умницы, читали.

Почему бы не применить и не подстроить книжный процесс под себя?

Кстати, если вспомнить про Scrum-гайд, то в нем вообще нет DOR. То есть само понятие есть, а вот того, что в него входит — нет. Забавно, правда? И каждая команда сама через боль и страдания приходит к тому, что же должно в него входить.

Уверена, что просто читать недостаточно, каждый раз с новой командой заново переживать многомесячные мучения ради плюс-минус однотипного DOR — так себе затея. Конечно, надо учитывать, что команды уникальны, ритм разработки у всех свой, процесс исследований тоже. Он, ведь, из многих компонентов состоит, и разные специалисты с разным опытом работы и степенью начитанности подходят к нему по-разному. Но слепо следовать инструкции — самая распространенная ошибка, на мой взгляд.

Единственный вариант — адаптировать процесс под себя и уникальные особенности команды.

Конечно же, я пишу очевидные вещи. Уже пробовали и продолжают пробовать. Scrum-мастер для этого у нас появился — руководитель-слуга команды, который и все процессы настроит, и команду сделает успешной. А может команда сама стать эффективной, настроив свои процессы самостоятельно? «Конечно, нет,» — скажут скрам-мастера. «Конечно, да,» — говорим мы в нашей команде. На наше счастье нашей команде попался в свое время настоящий scrum-мастер будущего, на нашем «Диком Западе» эстимации проповедующий скрам-мастера как сервис — специалиста, который приходит на проект на месяца три, не больше, настраивает процесс производства, не discovery, и уходит. А команда самосовершенствуется дальше сама. Так и живем, спасибо, профессионалам своего дела!

Честно, теперь вообще не верим в управленцев, которые не понимают смысла происходящего и процессов, которыми пытаются управлять. Как и в мировой истории, в разработке самый страшный персонаж (простите, но обычно, это именно скрам-мастер) — тот, который приходит в любую команду и проект и сходу заявляет: «Я знаю, как надо! Верной дорогой все за мной!» Такие специалисты ничего кроме недоумения и руин из ненастроенных процессов и проекта в неопределенной стадии готовности после себя не оставляют, но верят в мощь и значимость «скрамного» дела, умудряясь жить в собственной параллельной с командой Вселенной месяцами. Потом внезапно исчезают, и хорошо, если с концами. От полного разочарования в нашем отечественном скраме спасает только скрам-мастер как сервис, мы проверили на себе. И вот почему.

Думаете, что поможет команде быстрее разобраться в сложных задачах: артефакты, достаточно подробно ее описывающие, или новый способ проведения ретроспективы по результатам спринта? Вопрос риторический, но мы свято верим в оптимизацию процесса сбора информации и разработки, а еще — в их запараллеливание, а не в процессы ради процессов.

Построение успешного процесса начинается с понимания того, что мы хотим получить — в Scrum это называется Definition of Ready (DOR). Какой результат процесс Discovery должен дать, чтобы мы посчитали его успешным? С этого вопроса мы начали строить свой «лунапарк».

Нашей команде нужно оптимизировать процесс так, чтобы каждый участник понимал, чем мы тут будем заниматься, какую проблему решать и какие ресурсы у нас для этого есть. И, как всегда, ладно, не «вчера», но как можно быстрее. Зима, ведь, близко.

В процессе работы мы определили идеальный для нашей команды набор артефактов, которыми пользуемся при работе над любой задачей. Опять же, набор зависит от команды и может различаться, но компоненты точно будут одни и те же. С ним у разработчиков почти не возникает вопросов, что нужно сделать, и при этом требования стейкхолдеров и РО учтены. У нас это три больших компонента:

1. Общие вводные артефакты

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

1.2. Job Story и сценарий по семи этапам действия – универсальный артефакт понимания происходящего, как для дизайнера, так и для всех остальных участников команды. Незаменимая «вещь», чтобы оторвать разработчиков от кода и поставить их на место будущего пользователя.

2. Артефакты процесса, который автоматизируем

2.1. Результаты исследований и UX-тестов, если проводились. Мы постоянно в команде обсуждаем, почему делать исследования «на каждый чих» — нелепо, к тому же дорого: исследования хороши, когда мало опыта, а опыт хорош тем, что можно сэкономить время на исследованиях. В итоге, главное, соблюсти баланс, не полагаясь только на исследования и не оторваться от жизни, слепо идя на поводу у опыта. Сложная задача, каждый раз приводящая к холивару, но обсуждать точно стоит — качественный продукт делать интереснее, а и то, и другое — однозначно одни из важнейших компонентов джентльменского набора, необходимого для создания качественного продукта.

2. 2. Макеты процесса от дизайнера, без комментариев, нужны всегда и включают в себя:

Чуть не забыла, что макеты должны быть качественными. И это, действительно, важно, а еще легко оценить: если разработчикам и QA на первой демонстрации не нужно объяснять их смысл, то это успех. Скорее всего, и пользователю объяснений не потребуется. Нужна инструкция? Нет, такой поход уже давно не работает: если нужна инструкция, чтобы разобраться в интерфейсе — это повод начать работу заново, а не создавать эти самые инструкции. Вот, кстати, почему с телефонами сейчас вместо толстенной книжки на нескольких языках поставляется крошечный листочек, свернутый в несколько раз с рекомендацией по утилизации, но без единого упоминания, как пользоваться интерфейсом. Именно ради этого огромные команды проектировщиков, разработчиков и инженеров годами работали над ним, чтобы ты, пользователь, разобрался без инструкции совсем.

2.3. Разметка событиями: каждая задача должна размечаться — если данные не нужны сейчас, то скорее всего понадобятся через полгода. А мы уже готовы.

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

2.5. И задача в Jira со ссылками на все эти артефакты

3. Архитектурные артефакты

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

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

В agile-манифесте действительно есть этот пункт: «Работающий продукт важнее исчерпывающей документации». Но разве он о том, что вообще ничего не надо описывать? Если вспомнить, что среди семнадцати человек, его подписавших, был автор UML и «Чистой архитектуры», давайте будем честны, этот пункт точно не об этом.

Мне везёт со сложными проектами и командами: никто не ищет оправданий, а просто делает свою работу лучше всех. Поэтому в текущей команде не было вопросов и сомнений, что архитектурная документация нужна наравне с макетами, ведь, именно она покажет нам, как должна быть реализована фича или вовремя выявит проблемы, и теперь у нас это:

3.1. Концептуальная схема архитектуры и схема архитектуры в нотации C4. Не обязательно выбирать C4, можно выбрать любую нотацию, какая вам больше нравится, если такая возможность в компании есть, или ту, что рекомендуется использовать вашим архитектурным сообществом. Главное, что мы для себя поняли, что использовать нотации важно и важно использовать их правильно, а не просто их элементы, как кажется красивее (к сожалению, частный подход), тогда и сама нотация «подскажет», чего не хватает.

3.2. Логическая или блок-схема, если нужно описать сложную или разветвленную логику (у нас это Activity-диаграмма)

3.3. Последовательность вызовов сервисов (Sequence-диаграмма) с бизнес-составляющими процесса: да, мы не просто пишем названия сервисов и рисуем стрелочки, мы делаем сиквенсы с бизнесовым контекстом, чтобы все специалисты могли ее прочитать и однозначно понимать происходящее.

Что важно: первый компонент собирается всей командой вместе, второй и третий всегда прорабатываются параллельно, а по готовности выносятся на командный PBR (и макеты, и все схемы!), где все участники могут высказать сомнения, уточнить детали и усовершенствовать видение, дополнив его своим. Иногда бывают споры и часа бывает мало. Но это здорово, потому что если прислушаться к этим спорам, то станет понятно, что все комментарии и замечания о том, как сделать лучше или проще, что по сути одно и то же. Так в нашем процессе мы сразу работаем и над оптимизацией будущего решения.

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

Наш Telegram-канал —Проектируем космолеты

#dyscoveryprocess , #softwaredevelopment , #uxui , #systemanalyst , #uxdesign , #uxисследования