Разработка ПО отличается от других видов производства возможностью дать команде высокую степень свободы. На ранних стадиях подход «атмосферы стартапа» себя оправдывает — замотивированная команда трудится над созданием первой версии продукта, первоочередная задача — побыстрее получить демо-версию продукта.
Проблемы вылезают значительно позже, когда ПО «выстреливает» и становится успешным. Компанию приходится масштабировать, привлекать новых сотрудников. Очень быстро начинаются проблемы вида:
— А почему ты не сделал %действие%?
— Не знал, что его нужно делать. / Не знал, что это — моя сфера ответственности.
Импульсивный руководитель может сказать: «Не хотите по-хорошему? Нате тогда вам регламент!» и зарегламентировать всё подряд. Плохой подход. Опыт показывает, что разработка ПО — сфера «постоянных изменений». Регламент необходим, но он не должен быть похож на проверку самолёта на готовность к вылету.
Зачем нужен регламент?
Плюсы:
Стандартные действия сотрудников в повторяющихся ситуациях.
Стандартные сроки для исполнения повторяющихся процедур.
Руководителю больше не нужно объяснять новым сотрудникам простые процедуры.
Сотрудники не конфликтуют между собой — каждый точно знает свою сферу ответственности.
В ходе разработки регламента можно избавиться от ненужных активностей.
Процесс контроля упрощается, деятельность компании становится более структурированной.
Минусы:
В условиях «постоянных изменений» нужно не лениться держать регламент актуальным.
Для «творческих» сотрудников составить регламент можно далеко не всегда.
Регламент необходим, когда:
В компании больше одного отдела.
Регулярно возникают повторяющиеся проблемные ситуации.
Типичные ошибки
Самых частых ошибок три:
 |
Отрыв от практики.
Типовой сценарий — руководство создало группу оптимизации бизнес-процессов, сотрудники группы начинают описывать всё подряд, не заботясь о сути задачи. Особенно опасна ситуация, когда за работу берутся специалисты, не понимающие всех тонкостей рабочего процесса. |
 |
Нет гибкости
Регламент не должен описывать каждую мелочь — в этом случае он становится нагромождением трудновоспринимаемой информации. Только ключевые шаги процесса, правильность выполнения которых критична для достижения результата. |
 |
Нет связи с системой мотивации
Мотивацию сотрудников необходимо завязать на исполнение регламента — иначе не будет подлинного стимула регламент исполнять. |
Алгоритм подготовки регламента.
| 01 | Определение предмета регламента. Осознаём, что именно мы регламентируем. Например: «Регламент работы аналитика: Правила проведения первичной оценки запроса». |
| 02 | Определение ответственного. Отвечет за составление регламента ключевой сотрудник, в компетенции которого находится осуществление данного процесса. Например: «Руководитель отдела анализа и проектирования». |
| 03 | Собрание. Критично, если описываем процесс, предполагающий участи сотрудников нескольких подразделений. Например: Руководитель отдела анализа и проектирования приглашает для беседы руководителя отдела внедрения, главу техподдержки и главу отдела прямых продаж, объясняет, почему процесс первичной оценки регламентируется. Формируется общая позиция о том, как должен проходить процесс, утрясаются ожидания. |
| 04 | Описание процесса. Ответственный сотрудник обсуждает процесс с коллегами и готовит описание ключевых шагов. Иногда на этом этапе выясняется, что есть несколько способов выполнить тот или иной шаг — это возможная точка оптимизации. Также может оказаться, что исходная цель поставлена некорректно, нужен не один, а целая группа регламентов. |
| 05 | Рецензия. Первые рецензенты итогового документа — специалисты, которым предстоит данный регламент соблюдать. Фиксируем замечания и предложения, обдумываем, вносим корректировки. Затем документ отправляется сотрудникам, которых собирали на третьем этапе для финальной рецензии. |
| 06 | Утверждение. Регламент визируется генеральным директором или директором по развитию, формируется приказ о вступлении в силу, текст размещается в основном хранилище регламентов. |
Компоненты регламента
Первая часть — краткая выжимка полезной информации, не более одной странички.
Название и назначение процесса.
Владелец, инициатор, участники, контролёр процесса.
Правила запуска процесса.
Входной артефакт(ы).
Основной сценарий.
Выходной артефакт(ы).
Правила завершения процесса.
Диаграмма процесса.
Вторая часть — более детальная информация:
Предпосылки внедрения процесса.
Описание альтернативных потоков.
Описание порядка разрешения спорных случаев.
Описание влияния процесса на мотивацию участников.
Описание порядка внесения изменений в данный регламент.
История изменений.
Пример регламента
Название и назначение процесса:
Первичная оценка ЗЗЛ. Нужна для того, чтобы максимально быстро выделить бизнес-проблему заказчика, сформировать вариант реализации, дать примерную оценку доработки в часах. Получив эту информацию, заказчик может составить представление о том, готов ли заказывать написание требований и реализацию доработки.
Владелец: Руководитель отдела анализа и проектирования.
Инициатор: Любой сотрудник отдела внедрения, отдела продаж, отдела поддержки.
Участники: Сотрудники отдела анализа и проектирования.
Контролёр: Глава департамента разработки.
Правила запуска процесса:
Инициатор вносит запрос в бэклог, запрос проходит приоритезацию (См. регламент работы с бэклогом) и получает место в общей очереди.
Владелец, получив от сотрудника отдела анализа и проектирования (далее «аналитик») информацию о том, что у него менее двух запросов в активной фазе (См. общие правила работы сотрудников отдела анализа и проектирования), на своё усмотрение выбирает запрос из первой пятёрки очереди и переводит его на этого аналитика.
Входной артефакт:
Правильным образом заполненный запрос в общем бэклоге (См. регламент работы с бэклогом) в состоянии «Первичная оценка».
Основной сценарий:
Аналитик уточняет у инициатора актуальность запроса.
Аналитик организует телекон с представителем заказчика для уточнения бизнес-проблемы.
Аналитик запрашивает у менеджера продукта, кто из разработчиков может проконсультировать по оценке.
Аналитик объясняет разработчику суть бизнес-проблемы, разработчик предлагает решение и оценку.
Аналитик применяет к оценке поправочные коэффициенты (См. формулы первичной оценки).
Аналитик вносит в запрос оценку, уточнённую бизнес-проблему и выработанный вариант реализации.
Аналитик формирует документ «Первичная оценка» (См. пример документа).
Аналитик отправляет документ «Первичная оценка» инициатору.
Аналитик переводит запрос в состояние «Согласование первичной оценки.
Выходной артефакт:
Запрос бэклоге имеет состояние «Согласование первичной оценки», заполнены поля бизнес-проблемы, варианта реализации и оценки в часах.
Документ «Первичная оценка», отправленный инициатору.
Правила завершения процесса:
Положительный сценарий: Инициатор подтверждает готовность заказчика к этапу точной оценки, аналитик переводит запрос в состояние «Очередь для точной оценки», инициализируется процесс точной оценки (См. регламент точной оценки)
Отрицательный сценарий: Инициатор сообщает об отказе заказчика от доработки, аналитик переводит запрос в состояние «Отменено».
Диаграмма:
Обратите внимание — инструкция получилась ёмкой и чрезвычайно краткой. Прочитав её, новичок получит ответы на большую часть вопросов. Некоторые проблемы могут возникнуть в альтернативном потоке, но для этого как раз необходима вторая часть регламента с подробностями. Пример второй части приводить не буду, я и так был сегодня добрым.
Управление изменениями
Выживают лишь команды, умеющие гибко реагировать на изменения, поэтому корректировка регламентов должна быть максимально простой. Однако есть подводный камень. Внезапно выясняется, что процесс был изменён, но часть участников об этом не знает.
Общие правила изменения регламентов:
Регламент обязателен для соблюдения.
Любой участник процесса может предложить пересмотреть регламент.
Регламент пересматривается в рамках отдельной встречи.
По итогам встречи изменения обязательно вносятся в текст регламента.
Изменения обязательно публикуются в виде приказа.
Необходимы два инструмента: хранилище регламентов и система информирования.
|
Хранилище регламентов Лучше всего подходит корпоративная вики. Создаём страницу с базовым регламентом, ссылаемся на дочерние регламенты. Очень важно организовать хранение и доступ так, чтобы у пользователи легко могли найти любой регламент. Вариант чуть хуже — набор документов в Google Docs. |
Система информирования Оптимально — корпоративный портал. Приказ в виде поста, пользователи могут нажать специальную кнопку/голосование, чтобы показать, что они с приказом ознакомились. Вариант чуть хуже — рассылка по email. Главное — организовать информирование так, чтобы об изменениях узнали все участники процесса. |
Резюме
Регламенты несут больше пользы, чем вреда и крайне важны для масштабирования компании.
Регламент нужен там, где есть повторяющиеся процессы.
Регламент должен быть связан с системой мотивации.
Регламент не должен быть оторван от практики.
Регламент пишет сотрудник, напрямую заинтересованный в точном исполнении процесса.
Регламент должен быть гибок, не нужно описывать каждую мелочь, только ключевые шаги.
Регламент должен состоять из двух частей — краткой и полной.
Все участники процесса должны быть уведомлены об изменениях в регламенте.
P. S. Вот хороший пост о регламентах из телеги:
