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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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