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

В компании Wild Apricot, где я работаю, мы используем чеклисты как один из инструментов для контроля качества релизов достаточно широко. У нас это список действий, которые надо обязательно выполнить что бы фича ушла в релиз. У нас есть чеклисты разработчика, тестировщика (о!.. сколько у тестировщиков тест-листов...), и даже чеклист аналитика и дизайнера. Сравнительно недавно я занимался его переработкой и хотел бы поделится уроками, которые при этом получил.

Аналитиком у нас называется человек, который разбирается в чем состоит проблема пользователя, составляет список требований и сопровождает разработку.
Работает в тесном контакте с группой разработки (включающей дизайнера), которая, в свою очередь, на основе требований предлагает как именно решить задачу. Т.е. готовит и описывает конкретные изменения в продукте.

Больной

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

1. Аккумулирует знания о процессе анализа/дизайна. Это, конечно, и список ошибок, но во многом это еще те практики и приемы которые мы попробовали или придумали сами, и считаем правильным применять в дальнейшем
2. Помогает ответить на вопрос что делать дальше по фиче, примерно оценить общий прогресс, оставшееся время работы. Т.е. это один из основных рабочих документов при работе по фиче.
3. Крайне полезен для адаптации новых сотрудников. Т.е. во многом чеклист — это достаточно подробное и прикладное описание рабочего процесса как аналитика, так и дизайнера.

История болезни

Первая версия чеклиста решала все вышеописанные задачи, и решала их хорошо около года. А потом возникла идея (ну хорошо, шеф поставил задачу), — что надо бы его сократить, т.к. за год он разросся до неприличных размеров и стал практически неудобоварим в использовании. Если перечислять проблемы по пунктам, то он был:

• тупо длинный
• половина пунктов была применима к одним фичам, а вторая половина — к другим. По-хорошему, только один этап (про написание спецификации) использовался всегда и везде.
  Это на самом деле бОльшая проблема, чем может показаться, т.к. чеклист из рабочего инструмента плавно превращался в формальность, т.е. исчезала его ценность.
• страдал кучей описательных текстов, например почему какой-то пункт важен или как лучше оформить тот или иной документ

Первой логичной операцией была попытка сократить объем путем вычеркиванием лирики. Это был фейл, т.к. симптомы ушли, а сама болезнь осталась.



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

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

Поиск проблемы/решения всегда выглядит примерно так:



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

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

Поэтому сложный и длинный (даже творческий) процесс надо

• разбить на этапы и
• для каждого этапа использовать чеклист для проверки “на вшивость”.

Лечение

Решение проблемы уже придумал умный доктор Atul Gawande в своей книге Checklist Manifesto. В ней описано два вида чеклистов (в моем очень вольном изложении):

• чеклист действия (Измерить пульс и температуру, дать таблетку, поставить клизму), т.е. инструкция что делать. Используется прямо в процессе работы.
• и проверочный чеклист, который выполняется после завершения очередного этапа работы (проверить что отвезли больного в палату, все инструменты на месте и т.п.).

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

• Проверочный чеклист фичи
• Описательный how-to с лучшими практиками работ.

Чеклист

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

Чисто с точки зрения удобства использования этот чеклист один на фичу, т.е. включает в себя все этапы жизненного цикла фичи. Тем не менее он достаточно короткий (ну насколько это возможно ), т.е. включает в себя только hi-level вещи:

• выложил ли описание фичи на wiki,
• согласовал ли решение с заказчиком,
• проверил ли интеграцию с другими контурами: например с API или c мобильным приложением.

Фактически мы каждый раз делаем копию чеклиста для конкретной фичи и в ней “физически” ставятся галочки напротив каждого пункта.

• Текущая копия нашего чеклиста

How-to

В этих документах (по одному на каждый этап + несколько специальных) упрятано то “неформализуемое” знание о процессе работы, которые мы накопили. Здесь мы раскрываем что и как делаем, подробнее описываем важность тех или иных пунктов, что учесть при создании новых артефактов.Именно этот документ является, по сути, человекочитаемым описанием того, чем мы занимаемся, поэтому он исключительно полезен при адаптации сотрудников.

Однако опытный аналитик открывает how-to сравнительно редко — подразумевается что он и так все знает. Тем не менее документ всегда должен быть под рукой, что бы освежить, например, зачем и как делается приемка фичи перед слиянием ветвей разработки. Или для того что бы внести дополнения в описание того или иного процесса когда появляются свежие мысли.

• Пример how-to для этапа начального анализа

Профилактика

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

Надо всегда четко понимать для кого и с какой целью делается инструмент.

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

С другой стороны how-to больше полезен для новичков. Однако, когда мы вносим изменения в чеклист, каждый член команды становится по своему новичком и именно из how-to он может понять что стоит за новым пунктом, почему он был введен, какие проблемы призван решить. Это очень важно пока ты сам не “попробуешь” новую активность “руками”.

Чеклист, как и любой рабочий инструмент, должен быть живым.

Пусть я повторюсь в “дцатый” раз — если ты веришь в ценность инструмента и он доказал свою полезность (как нам) — то используй его в работе всегда и без исключений. Если ты не используешь чеклист — то он тебе не нужен. А если он тебе не нужен — зачем его делать? Ведь создание хорошего рабочего чеклиста это хороший кусок работы сам по себе.

Второй момент — важно не только использовать чеклист, но и постоянно обновлять его если что-то поменялось. Встретил новую проблему — не поленись, подумай может стоит ее внести в how-to? А может сразу в чеклист? Ну и не забудь уведомить команду об изменении.

Ну и третье: если несмотря на настойчивые напоминания чеклистом не пользуются — то это хороший повод побеседовать с людьми или (что, надеюсь, более вероятно) повнимательнее посмотреть на чеклист. А действительно ли это удобный рабочий инструмент?

Выписка

• Чеклисты бывают двух видов: чеклист действия (что делать дальше?) и проверочный чеклист (что не забыть проверить?)
• Для сложного творческого процесса применим только проверочный чекист и он реально полезен
• Если вам нужно детальное описание процесса, лучших практик — выносите в отдельный документ (how-to).
• При разработке чеклиста всегда помните о пользователях и целях документа
• Постоянно используйте и обновляйте чеклист, иначе зачем вообще с ним связываться?