Освоение документирования процессов: полное руководство по созданию высокопроизводительной команды

Почему важна документация процесса

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

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

Итак, что делает лидера? По сути, лидер — это тот, кто в иерархии компании задает направление и организует усилия команды в рамках своих полномочий. Эффективный способ установить этот авторитет — документировать процессы в централизованном пространстве. Человек, который пишет правила, является ответственным.

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

Ценность документации процесса

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

1. Подготовка бизнес-требований.
2. Подготовка технических заданий и проектов.
3. Оценка требований.
4. Планирование релиза.
5. Выполнение.
6. Тестирование и стабилизация.
7. Выпуск доставки.

Как менеджеру, вам необходимо найти способы пройти этот процесс более гладко и эффективно.

• Были ли наши оценки точными?

• Есть ли проблемы с инфраструктурой?

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

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

Явный признак того, что в ваших процессах чего-то не хватает, можно увидеть в следующем примере:

• Dev: «Я закончил свою задачу вовремя и все зафиксировал. Не знаю, почему тестирование началось так поздно! Если бы мы обнаружили эту проблему раньше, у нас было бы достаточно времени, чтобы ее исправить! Вот почему релиз был отложен».

• QA: «Мы бы начали тестирование раньше, если бы знали, что задача выполнена. Во время обновления статуса команда разработчиков упомянула о проблемах с этой функцией и сказала, что им нужно дополнительное время, чтобы разобраться с этим. Поздно вечером в среду они закрыли подзадачу, не обновив статус основной задачи и не уведомив инженера по контролю качества. На нашей панели задач задача все еще была отмечена как «в разработке», поэтому мы понятия не имели, что должны были начать над ней работать».

Даже из этого диалога может возникнуть несколько вопросов:

1. Как команде разработчиков следует закрывать свои задачи?
2. Обязательно ли иметь и задачу, и подзадачу?
3. Как следует уведомлять команду QA о завершении задачи разработки?
4. Должно ли это уведомление быть ручным или его можно автоматизировать?
5. Как функционирует панель контроля качества и работают ли они с правильными рабочими элементами?
6. Нужны ли нам отдельные панели мониторинга для каждой подгруппы?
7. Почему команда разработчиков закончила свою задачу поздно вечером в среду? Возможно, стоит обсудить это на следующей личной встрече.

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

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

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

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

Охват документации можно разделить на два уровня:

1. Схема.
2. Инструкции по процессу.

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

Схематическое покрытие

Первым шагом в любом проекте должно быть схематическое покрытие - графическое представление вашего процесса. Это покрытие должно предоставить команде общее понимание установленного рабочего процесса и ответить на ключевые вопросы:

• Какие этапы включает в себя наш процесс?

• Где я нахожусь в этом процессе?

• Какова моя ответственность в этом процессе?

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

Базовый уровень схемы

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

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

Вот некоторые идеи для нынешних и новых членов команды:

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

Эта структура должна быть отображена как ключевая иллюстрация в публичном пространстве команды в системе wiki, такой как Confluence, Notion или SharePoint. Если в компании в настоящее время нет системы wiki, это прекрасная возможность создать ее, поскольку это необходимо для будущих улучшений.

• Одним из самых важных эффектов этого изображения является то, что оно вызывает у команды дополнительные вопросы:
• Но когда и кому необходимо обслуживать и переключать филиалы?
• Кто отвечает за управление накопившимся технологическим долгом?
• Вы пропустили задачи DevOps!
• Отдел продукта следует добавить на этап внедрения, поскольку мы помогаем с задачами 1, 2 и 3…
• Эта таблица слишком сложная. Я ничего в ней не понимаю!

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

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

Подробный схематический уровень

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

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

Что следует охватить на детальном уровне:

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

Команда должна иметь систему тикетов и отслеживания, например Jira или Microsoft Azure DevOps, содержащую рабочие элементы с определенными рабочими процессами. Документирование схематических правил для статусов и обязанностей на каждом этапе рабочего элемента имеет важное значение. Лучше иметь статьи для каждого типа рабочего элемента. Начните с самого распространенного, например, Задача или Ошибка продукта, и идите дальше. Даже если используются стандартные процессы, важно описать, что представляет собой каждый этап.

Инструкции по процессу

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

1. Уровень контрольного списка.
2. Уровень обучения.

Уровень контрольного списка

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

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

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

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

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

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

Контрольный список может дать несколько идей:

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

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

   1. Задача может оказаться слишком сложной.
   2. Задача может быть неясной.
   3. Задача могла быть начата не на том этапе.
   4. Ответственность может быть распределена некорректно, и задачу следует поручить кому-то другому.

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

Уровень обучения

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

Необходимость этого уровня лучше всего проиллюстрировать на примере:

Наш продукт может распространяться как SaaS или On-Prem программное обеспечение. Версия SaaS может быть развернута автоматически, но версия On-Prem требует ручной установки командой Delivery. В контрольном списке релиза есть задача, в которой указано: «Дистрибутив релиза продукта должен быть загружен в локальное хранилище команды Delivery».

Это управляемо, когда это делается раз в две недели, и все понятно. Но что делать, если менеджер по релизам уходит в запланированный отпуск или появляется новый менеджер по релизам? Какой дистрибутив использовать? Где находится локальное хранилище команды доставки? Есть ли там стандарт именования каталогов? Где я могу получить разрешение на загрузку в эту папку? Что делать, если я случайно загрузил не ту версию?

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

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

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

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

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

Методолог процесса

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

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

Обязанности методиста процесса:

1. Создание и поддержка шаблонов и структуры для каждого уровня документации процесса.
2. Выявление областей для улучшения проекта и создание резерва для усовершенствования процессов.
3. Определение задач для новых артефактов процессной документации.
4. Обеспечение качества, полноты и согласованности описаний процессов как на каждом уровне, так и по отношению к процессу в целом.
5. Поддержание документации процесса в актуальном состоянии по мере внесения усовершенствований.

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

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

Использование процессов в жизни команды

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

Первый шаг — обеспечить доступность процессов для всех. В системах управления задачами, таких как Jira или Azure DevOps, обычно есть страница описания проекта. Именно там вы можете разместить ссылку на документацию процесса. То же самое относится к корпоративным вики, таким как Confluence или Notion, которые хранят требования и другую документацию компании. Ваше пространство документации должно быть опубликовано на главных страницах этих систем. Также полезно уведомить команду по электронной почте или по каналам в корпоративных мессенджерах и упомянуть об этом на ежедневном собрании. Команда должна знать, что задокументированные процессы доступны для просмотра.

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

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

Все эти шаги необходимы для достижения нескольких основных целей:

1. Повышение прозрачности процессаКо всем относятся одинаково, существуют четкие правила, описывающие, как выполнять задачи.
2. Улучшить управляемость команды. Легче планировать свои обязанности и работу членов вашей команды, когда объем работ четко определен.
3. Снижение зависимости от ключевых сотрудников и менеджеров. Члены команды или даже вы можете покинуть компанию, не рискуя непрерывностью бизнеса. Если процессы работают гладко без вас, это признак хорошо спроектированных процессов, и это означает, что вы сделали свою работу правильно.

Дополнительным преимуществом документирования процессов является его полезность в разрешении рабочих конфликтов. Легче предоставлять обратную связь на основе письменных правил, а не личных впечатлений. То же самое относится к конфликтам между подразделениями. Если кто-то неправильно реализует процесс или если процесс упускает определенную ситуацию, это возможность для улучшения. Это здорово! Это означает, что есть новая идея о том, как сделать все лучше для всех.

Минусы надлежащего документирования процесса

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

1. Это отнимает много времени.

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

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

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

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

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

3. Менее мотивированные члены команды могут использовать отсутствие определенных описаний процессов как оправдание неудач.

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

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

• Это требует сильной мотивации со стороны методолога процесса.

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

Подводя итоги: ключевые шаги для эффективного документирования процесса

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

1. Определите методолога процесса. Это должен быть человек, который ревностно относится к улучшению процесса, активно занимается выявлением пробелов и увлечен совершенствованием рабочих процессов.
2. Решите, где хранить документацию по процессу. Она должна быть легкодоступной, в идеале с использованием существующих инструментов компании, чтобы избежать дополнительных расходов.
3. Опубликуйте базовую схему вашего процесса, чтобы наладить рабочий процесс документирования и собрать первоначальную информацию.
4. Публикуйте рабочие процессы для наиболее часто используемых рабочих элементов.
5. Составьте контрольные списки задач, необходимых для выпуска новой версии программного обеспечения, назначив ответственных за каждую задачу.
6. Публикуйте подробные инструкции для сложных задач.
7. Постоянно наблюдайте за своим процессом на протяжении итераций. Добавляйте новые принципиальные схемы, обновляйте контрольные списки и расширяйте библиотеку инструкций по мере необходимости.

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