Как правильно организовывать доски в Notion и не только?

Человек, который разбирается в процессном менеджменте, создает правильно организованную доску в Notion буквально за 20 минут. Потому что это очень простая задача — но только когда знаешь, как правильно ее выполнять. Такой же специалист, но без этого знания, не сделает правильную доску, даже если дать ему на это неделю, месяц или год. Почему?

Привет! Меня зовут Кирилл Мокевнин, я CEO и сооснователь онлайн-школы программирования Хекслет. В компании сейчас работает около 100 человек, и все они пользуются Notion, сейчас это около 50 досок. Мы используем Notion, чтобы все рабочие процессы были понятны и прозрачны для всех сотрудников. При этом нередко возникает путаница, для чего нужны доски в Notion и как организовать их правильно.

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

Чтобы научиться работать с досками правильно, нужно познакомиться с несколькими концепциями: рабочий процесс (workflow) и стратегия вытягивания. Они несложные, но они важны для формирования правильного мышления.

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

Слово процесс тут ключевое. Если посмотреть на любую компанию, то практически все, что происходит внутри нее — это какие-то процессы, по которым люди работают. Первый шаг к успеху состоит в том, чтобы замечать эти процессы и уметь рассматривать их изолированно.

Возьмем для примера процесс создания статей для блога. Очень упрощенно он выглядит так:

• Руководитель ставит задачу редактору на написание статьи
• Редактор пишет статью и сдает ее руководителю

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

Исходя из этих требований, мы можем добавить два столбца: «в работу» и «сделано»:

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

Пожалуй, главный вопрос — как понять, над чем уже ведется работа, а над чем еще нет? Проблема здесь в том, что задача ставится сразу «в работу», хотя работа над ней еще не началась. Логичным шагом было бы разделить эту колонку на две: «В работу» и «В работе».

Теперь мы точно знаем, над чем ведется работа, а над чем еще нет. Так нам гораздо легче оценивать общую картину и понимать текущую загрузку на команду.

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

1. Руководитель ставит задачу редактору на написание статьи
2. Редактор пишет статью
3. Редактор публикует статью

Этот процесс переложенный на доску выглядит уже так:

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

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

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

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

Возьмем процесс включения телевизора. У этого процесса есть два состояния: «включен» и «выключен». Когда мы нажимаем кнопку, то переходим из одного состояния в другое.

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

Такими же процессами с наборами состояний являются любые известные нам действия на сайтах. Регистрация — процесс с кучей состояний, включая «ожидание подтверждение емейла», «готов к работе» и т.п. Заказ товара — состояния «оплата», «отгрузка», «доставка».

Конкретные состояния в этих процессах не фиксированы. Все зависит от проекта, в котором они реализуются. То есть автомат — это отражение реального мира, а не наоборот.

Зачем все это знать? Такой взгляд на вещи позволяет увидеть суть бизнес-процессов. Любой бизнес-процесс моделируется с помощью конечного автомата. Когда мы его пытаемся осознать и описать, то мы на самом деле пытаемся выделить в нем состояния и описать переходы.

Посмотрите на этот список с новым взглядом:

1. Руководитель ставит задачу редактору на написание статьи
2. Редактор пишет статью
3. Редактор публикует статью

Здесь мы видим описание переходов между состояниями. Написание статьи переводит ее из состояния «в работу» в состояние «в работе», которое затем переходит в состояние «сделано». Публикация переводит статью из состояния «сделано» в «опубликовано».

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

Точно таким же способом создается и любая другая доска.

• Описываем процесс — как он работает в реальности
• Выделяем ключевые состояния, которые хотим отслеживать
• Переносим состояния на доску в виде колонок

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

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

В текущей структуре это неудобно — ведь редактор по задумке берет все, что видит в колонке «в работу», и начинает над этим работать. Проблему можно было бы решить каким-нибудь текстом — например, «черновик» в названии задачи или ее описании, но есть способ лучше.

Обычно создают колонку, которую принято называть бэклогом. Эта колонка используется для задач-идей — их хочется записать, но пока они не готовы к тому, чтобы их выполнять. В таком случае левая часть доски начинает выглядеть так:

Со временем в колонке «Опубликовано» начнут копиться выполненные задачи. Это нормально, но их нужно будет куда-то деть. Поэтому тут нужна еще одна колонка, которую обычно называют «Архив»:

Архив сразу лучше пометить скрытой колонкой, чтобы он не мешал общему отображению. Если задач в архиве много, то это еще и ускорит работу доски

Любой хорошо оформленный процесс в виде доски в минимальном виде выглядит как следующий набор колонок:

1. Бэклог
2. Готово к работе
3. В работе
4. Сделано
5. Архив

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

Любая, даже отлично спроектированная доска, не будет работать, если ей постоянно не заниматься. Недостаточно просто научить всех и сказать «пользуйтесь». Придется переодически напоминать и задавать вопросы.

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

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

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

У каждого поля есть тип. Например, для основных статусов, по которым делятся колонки, используется тип Status. Внутри этого типа каждое название будет добавляться в одну из трех групп: To-Do («Бэклог», «В работу»), In Progress («В работе», «Сделано») и Complete («Опубликовано», «Архив»).

Главная концепция работы с полями состоит в том, что все данные нужно добавлять в карточку именно как поля, а не просто как текст. Это важно для поиска, удобного вывода и фильтрации.

Например, мы можем вывести любые важные для нас поля в саму таблицу со списком карточек и отфильтровать их по какому-то признаку:

Особняком стоит поле «Исполнитель». Для контроля процесса нам обязательно знать, кто ей занимается, поэтому на любой доске у любой карточки заполняется поле «Исполнитель».

С этим полем связаны два интересных момента. Сколько может быть исполнителей и кто их проставляет?

Количество исполнителей

В идеальном случае исполнитель один. Бывает достаточно редко, когда за тикет отвечает сразу множество людей. Даже если так, всегда должен быть кто-то, кто чувствует за собой конечную ответственность. Иначе люди просто не будут реагировать на карточки, где кроме них исполнителями назначены еще 3, 4 и больше людей.

Кто ставит задачи

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

Первая — ставить исполнителем того, кого нам взбредет в голову. Эта стратегия обладает рядом недостатков. Можно легко перегрузить задачами конкретного сотрудника, он может быть занят, он может оказаться в отпуске, а еще это может мешать процессам, которые организованы внутри команды.

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

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

Такой подход делает работу крайне неудобной:

• Невозможно фильтровать данные
• Кто в лес, кто по дрова. Нет единой системы обозначений
  
• Если поменяется название чего-либо, придется проходиться по всем карточкам и менять
  

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

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

Добавим в наш процесс создания статьи такую вещь как создание обложки. Обложками занимается иллюстратор. В какое место поместить эту часть?

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

По идее, каждая часть работы состоит минимум из трех этапов «В работу», «В работе» и «Сделано». Здесь мы видим только две новых колонки. Это не случайно. Колонку «В работу» здесь заменяет «Сделано». Работает это так: когда редактор написал статью, он перемещает ее в колонку «Сделано». Дальше включается механизм вытягивания. Иллюстратор сам забирает задачу из этой колонки и помещает ее в колонку выполнения задачи.

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

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

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