Зачем рисовать процессы или нужна ли стартапу документация?

Когда я только пришла работать в Nautal, мне казалось, что здесь все довольно просто – маркетплейс типа Airbnb, только для лодок. Ну что может быть сложного? В процессе онбординга мне объяснили общий процесс – клиент делает заявку, владелец яхты отправляет оффер, клиент платит, владелец подтверждает.

Правда, упомянули, что в некоторых случаях возможны нюансы. Нюансов оказалось много, а документации почти не было. Мы же стартап – ну какая документация? :) Официальная версия – «все очень быстро меняется, потратим время на документацию, и она устареет через неделю».

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

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

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

В какой-то момент я просто села и нарисовала схему о первом шаге воронки – что происходит с момента когда клиент делает заявку до момента, когда он получает оффер.

Для рисования схем использую Miro (бывший Realtimeboard). Удобно, что все – на одной бесконечной белой доске, плюс, можно зумиться. Зум оказался чудовищно удобной штукой. Я добавляю уменьшенные скрины емейлов прямо на схему процесса. Так они не захламляют схему, а если хочешь увидеть контент письма – призумься и увидишь.

Распечатала, раздала менеджерам, рассказала им как все работает. Наконец-то увидела у них в глазах понимание и искреннюю детскую радость. Вопросов стало на порядок меньше, а когда они возникают, я достаю бумажку и тыкаю в нее пальцем – очень быстро все становится ясно. Это успех, я считаю :)

Мне так понравился эффект! Плюс, словила кайф от самого процесса наведения порядка (это моя суперсила :)) что я раскопала все основные флоу и отрисовала схемы по каждому из них. Сейчас это выглядит так:

И это только основной процесс, без особых деталей.

Программисты тоже оценили. Когда я формулирую задачу, часто прикладываю к тикету в Jira схему нужного процесса с объяснениями, что надо поменять. Учитывая, что spanglish на котором мы общаемся всем не очень родной, картинки – здорово помогают понять задачу.

Складываю картинки в Confluence где у нас хранится вся документация. Если процесс меняется – добавляю новую схему с датой обновления, а старую сохраняю для истории, чтобы отвечать на вопросы «А когда мы поменяли эту штуку?». Программисты и менеджеры имеют доступ к хранилищу, так что могут в любой момент сами зайти туда и посмотреть.

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

Как конкретно изображать блоки особой роли не играет, жестких правил нет. Мне удобно письма обозначать желтыми прямоугольниками, события – красными и зелеными скругленными прямоугольниками, условия – ромбиками, действия – текстом, примечания – серым курсивным текстом с пунктирной линией, которая показывает к чему примечание относится. Плюс, красные комментарии, если нужно подчеркнуть проблему или важный момент.

Если диаграмма описывает процесс для разных ролей – клиентов и владельцев лодок одновременно, я использую «Плавательные дорожки» (Swim Lanes), чтобы было понятно, что к кому относится.

Для меня работает подход – делать отдельные схемы по логически законченным шагам процесса. Примерно ориентируюсь на 10-20 блоков в одной схеме. Больше – сложно для восприятия, меньше – не информативно. Плюс, стараюсь сделать так, чтобы было читаемо при печати на А4.

Располагаю схемы на доске в логическом порядке. Например, слева-направо:
1. Процесс от заявки до оффера,
2. Оплата,
3. Подтверждение,
4. Обработка второго платежа и т.д.

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

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

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

Плюс, приятный бонус – можно получить удовольствие от процесса, потому, что ну разве не приятно сделать что-то красивое, аккуратное и полезное :)