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

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

Что такое чек‑лист в том понимании, которое мы применяли в компании? Это набор действий, которые надо совершить после шага бизнес‑процесса.

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

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

Вообще зачем начали применять хоть какие‑то практики и методики? В принципе, как всегда — были две команды, которые работали над сложным проектом со сложным заказчиком, и качество работы в хаосе и давлении Заказчика очень страдало. Мы начали огрызаться друг на друга, кто‑то начал халтурить, было много встреч с «разбором полетов» по качеству работы и, проанализировав проблемы двух команд с непересекающимися сотрудниками, поняли, что проблема в личной ответственности каждого сотрудника в большом потоке задач.

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

Самый простой пример внутрикомандной проблемы, с которой мы столкнулись, был, когда аналитик написал постановку на разработку и готов отправить ее на рецензию архитектору. Для нас было важно, чтобы аналитик в хаосе постоянных дерганий не забыл проверить соответствие постановки требованиям ТЗ, в том числе техническим, а также прикрепил к задаче jira ссылку на постановку в confluence.

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

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

Чек‑лист для процесса разработки мы внесли в jira (поле Check‑лист), остальное уже менее формализованно — в Confluence (чек‑лист при отправке внешнего документа, чек‑лист для определения списка адресатов и т.д). Еще часть, касаемая руководителя проектов, была внесена как чек‑лист проверки закрытия контрольных точек в внутренней системе управления проектами компании.

Инструмент кажется очень простым, но я не видела, чтобы еще где‑то его использовали именно таким образом, как использовали его мы. Как именно он нам помог?

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

• Снял напряжение с участников команды. Каждый точно знал, что свой обязательный минимум он делал — все было в чек‑листе, а остальное мы обсуждали в рабочем порядке и это был образовательный момент, а не «разбор полетов», что кто‑то что‑то объективно понятное всем не сделал.

• Облегчил подключение новых участников. Нам не приходилось долго погружать новых членов команды (особенно разработчиков, которых подключали на парт‑тайм к проекту), так как все помимо собственно разработки, уже было зашито в процесс.

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

• Облегчил контроль и «разбор полетов». Как бы это плохо не звучало, но неквалифицированные сотрудники все равно существуют и нужно разбираться с проблемами и выстраивать разговор. При подготовке к встрече мы анализировали задачи сотрудника и соответствие его работы заполненным чек‑листам — получалась очень объективная картина работы сотрудника, которая видна не только нам, но и ему.

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

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

• Протест сотрудников. Чек‑лист уравнивает всех участников процесса и заставляет высококвалифицированных специалистов подтверждать, что они и так знают и делают. А тех специалистов, что привыкли делать «кое‑как», вынужденно показывать свое незнание.

• Чек‑листы могут отличаться для каждого проекта, либо их может не хватать, чтобы решить конкретные проблемы конкретного проекта. Если компания использует одни и те же чек‑листы во всех проектах, возможно их не будет хватать для части проблем одного конкретно взятого проблемного проекта. Их нужно адаптировать и применять только там, где есть проблема. Либо использовать как самый минимум в самых часто повторяющихся местах (закрытие актов, проведение оплат, взаимодействия по закрытию проекта и т. д.).

• Анализ полезности каждого чек‑листа спустя время. Это требует трудозатрат, выделенных сотрудников на анализ процессов, не «замыливания» новых проблем.

• Анализ в принципе нужности чек‑листов на данном этапе проекта. Все проекты проходят свой жизненный цикл, и то, что чек‑лист нужен был на этапе реализации, уже не нужен на этапе сопровождения. Нужно актуализировать jira, убирать чек‑листы или добавлять новые.

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

В статье я привожу пример именно разработки, но специфика предметной области разработок компании позволяла нам применять методику чек‑листов не только внутри, но и внедрять такую же практику у Заказчиков при оптимизации и автоматизации процессов. Такие проверки на шагах процесса хорошо «взлетают» в любой предметной области в связи с их понятностью и универсальностью.

Примеры, где еще могут применяться чек‑листы:

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

• Формирование документа. Проверка по чек‑листу на использование стилей / нумерации и прочего, что составляет хороший документ.

• Здоровье проекта. Проверка по критериям, где может скрываться проблема в вашем проекте.

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