Казалось бы, идея регламентации деятельности компании является очень логичной и должна повысить эффективность работы компании. Но почему-то на практике это мало кому удается сделать.
Мне известно очень большое количество попыток регламентировать деятельности компании, которые, по сути, ничем хорошим не закончились.
Почему же большинству компаний не удается создать эффективную машину по зарабатыванию денег за счет регламентации всех бизнес-процессов и проектов?
Безусловно, в каждом конкретном случае на разработку регламентов могут негативно влиять сразу несколько факторов. Тем не менее, на мой взгляд, есть одна причина, которая с вероятностью близкой к 100% хоронит идею регламентации.
Итак, одна из основных проблем, из-за которой регламенты в компании не работают, заключается в самой организации деятельности по их разработке.
Самый распространенный подход к разработке регламентов заключается в том, чтобы поручить данную работу одному (или нескольким, в зависимости от объема) человеку. Причем нередко этим занимается внешний специалист (например, консультант или группа консультантов).
Как делать бизнес-регламенты правильно
В подавляющем большинстве случаев это приводит к возникновению огромного количества всевозможных регламентов (положений, инструкций и т.д.), которые на практике не используются.
Кстати, раньше все эти регламенты разрабатывались вручную, что, конечно же, занимало много времени, особенно если нужно было вносить какие-то изменения. Сейчас есть много специализированных компьютерных программ, с помощью которых можно разрабатывать регламенты.
При этом регламенты могут формироваться и в текстовом и в графическом виде. В общем, сейчас очень много различных «рисовалок», используя которые можно разрабатывать талмуды за сравнительно небольшое время. «Рисовалок» много, а толку мало.
Благодаря этим программам, разработка регламентов из сложной содержательной задачи превратилась в чисто техническую. Во многих компаниях считают, что им достаточно приобрести одну из таких программ, нанять сотрудника (или пригласить консультанта), который нарисует им все необходимые регламенты.
Кстати, в большинстве компаний так серьезно относятся к выбору названия должности такого сотрудника, как будто от этого что-то зависит.
Как их только не называют. Специалист по разработке регламентов, специалист по бизнес-инжинирингу, бизнес-аналитик и т.д.
Иногда создают целые отделы или группы. Например, отдел/группа корпоративной регламентации или отдел/группа бизнес-инжиниринга или бизнес-аналитиков.
На мой взгляд, подобная централизация, а затем и локализация функции регламентации и приводит к тому, что компания не получает желаемого результата и созданный для разработки регламентов отдел (группа или сотрудник) расформировывается.
Если в компании, скажем так, не очень следят за затратами и не думают о повышении эффективности работы, то такой отдел/группа может просуществовать не один год. Этот отдел и дальше будет продолжать поддерживать в «актуальном» состоянии все раннее разработанные регламенты, а также заниматься созданием новых, но все это не будет иметь никакого отношения к реальной практической деятельности предприятия.
5 причин внедрить регламенты в бизнес сегодня
Этот отдел будет, как говорится, вариться в собственном соку. Если в один день уволить всех сотрудников данного отдела, то этого никто и не заметит. Может быть кроме тех, с кем сотрудники этого отдела чаи гоняли на работе.
Противоположностью такого централизованного и локального подхода к разработке регламентов является децентрализованный подход, когда разработкой регламентов занимаются все подразделения. То есть каждое подразделение полностью автономно разрабатывает для себя регламенты.
Основные проблемы такой децентрализованной стратегии разработки регламентов заключаются в том, что нельзя будет нормально прописать взаимодействие подразделений при выполнении различных функций, а также в том, что каждое подразделение может использовать свои форматы описания регламентов.
Таким образом, действительно эффективным подходом к разработке регламентов является смешанный вариант.
Безусловно, должна быть какая-то координация и контроль разработки регламентов. Кроме того, нужно разработать и утвердить единые стандарты описания регламентируемых объектов компании.
Возникает вопрос: кто же должен заниматься разработкой единых стандартов, координацией и контролем разработки регламентов?
Если компания небольшая, то данные функции может выполнять сам директор (возможно, привлекая внешних консультантов). Если компания уже не маленькая, но еще не такая крупная чтобы позволить себе иметь в штате отдел (или дирекцию) развития, то опять-таки эти функции может выполнять директор компании, но в этом случае с большой вероятностью ему потребуется помощь со стороны внешних экспертов (возможно даже на постоянной основе).
Если же в компании уже есть отдел развития, то данными функциями может заниматься он при контроле со стороны директора.
Почему предлагаются именно такие варианты распределения рассматриваемого здесь функционала? Да потому, что разработка регламентов – это деятельность, связанная с развитием компании, конкретно с развитием системы управления.
А значит, для эффективной реализации такой деятельности нужно использовать технологию проектного управления. В данном случае речь идет именно о проектах развития.
То есть разработка и внедрение регламентов должна быть проектной деятельностью, которую курирует или сам директор или отдел развития (при контроле со стороны директора).
ЭТО МОЖЕТ БЫТЬ ИНТЕРЕСНО
Ближайший семинар по оргпроектированию состоится 20-21 июня 2023 г.
Таким образом, регламент должна создавать проектная группа, состав которой у каждого проекта может быть свой. При этом обязательно в состав группы должен входить сотрудник отдела развития.
Если у компании нет отдела развития, то в состав некоторых проектных групп может включаться внешний специалист (консультант). В таком случае контролировать работу проектных групп будет сам директор (возможно с помощью консультанта).
Примечание: более подробно тема данной статьи рассматривается на семинаре-практикуме «Организационное проектирование. Реструктуризация предприятия и бизнес-процессов», который проводит автор данной статьи — Александр Карпов.
Источник: rik-company.ru
Почему команда работает плохо? Очень много о регламентах и процессах
Я Артём Салеев, руководитель backend-направления в компании Amiga. Мы занимаемся заказной разработкой мобильных приложений на Flutter, созданием веб-сайтов и корпоративных порталов.
Большинство советов, которые мы рассмотрим дальше, справедливы для заказной веб-разработки или проектной деятельности. Но если вы работаете в продукте, тоже сможете почерпнуть полезные рекомендации и применить на практике.
Эта статья вышла на основе моего выступления на конференции Merge 2022.
Все плохо, что делать?
Ситуация: задача не выполнена вовремя, потратили на нее больше часов, чем планировалось, а по итогу появляется куча багов. Знакомо? А когда мы получаем такой результат, к кому все идут в первую очередь? Конечно, к разработчикам.
Но почему команда косячит и что-то идет не так? Мы задались этим вопросом и ретроспективно посмотрели на последний год. Основные причины можно разбить на 3 категории: проблемы с документацией, регламенты процессов, регламенты разработки. Поехали разбираться.
Проектная документация
Чтобы избежать ошибок выше, у вас должна быть собрана вся информацию по проекту в одном месте. Мы храним данные в Confluence.
Я разделил блоки документации на 3 отдельные области в зависимости от ролей и их зоны ответственности (у вас разбивка может отличаться): общая информация, менеджерские документы, документы разработчика.
Общая информация
- Требования, ТЗ и спецификации. Зафиксированные требования — важнейшая часть любого проекта. Все, в том числе и клиент, должны понимать, какой продукт по итогу получится. К тому же, это гарант безопасности команды и компании с юридической точки зрения.
- Материалы от клиента. Мы скидываем сюда все входящие материалы, которые прилетают со стороны заказчика — брифы, референсы, макеты и так далее. Всегда понятно, где искать потерявшуюся ссылку месячной давности, не в общем чате же.
- Список команды. Здесь хранятся следующие данные — ФИО, контакты, за что отвечает на проекте. Такой перечень поможет команде понять, кто и чем занимается, к кому обращаться в случае проблемы, как найти человека.
- Онбординг. Краткая «экскурсия» по проекту, которая поможет быстрее подключить новых сотрудников. Это дополнительный пункт — зависит от частоты сменяемости участников проекта. Всегда нужно смотреть целесообразность онбординга, не во всех проектах понадобится.
Ответственность менеджера
В нашей команде за наполнение этого блока документации отвечает менеджер проекта, у кого-то может быть по-другому. Какое наполнение входит в зону его ответственности?
- Документация проекта: акты, счета, договора с подрядчиками и т.п.
- Гант и сроки. Менеджер фиксирует, на каком этапе проекта команда находится, кто и что делает в ближайшее время, какие результаты. Необходимо постоянно поддерживать этот документ в актуальном состоянии. Мы также используем его на еженедельных встречах с клиентом, чтобы показывать сроки, результаты работы и подсвечивать какие-то контрольные точки.
- Спринты. Если работаете по Scrum, можете фиксировать пулы задач спринтов и отслеживать их.
- Бэклог. Используем это как копилку для желаний клиента. Периодически возвращаемся и мониторим, что можем реализовать.
- Ретро. Итожим с командой результаты, обсуждаем цели, задачи и что нужно исправить/улучшить. После встречи менеджер составляет отчет, который мы анализируем на следующем ретро (сверяемся, удалось ли нам исправить ошибки).
- Репорты. PM описывает договоренности на встречах с клиентом в репорт встречи, чтобы в процессе работы посмотреть, когда и о чем договорились.
Ответственность тимлида
То, что влияет на процессы разработки, фиксирует тимлид и ведет следующую документацию:
- Архитектура проекта. Включает в себя описание серверного окружения, архитектурные решения, используемые сервисы и механизмы взаимодействия между ними;
- Принципы и регламенты разработки. Раздел содержит в себе стандарты разработки и правила написания кода, которым необходимо придерживаться на проекте (PSR, SOLID и т.п). По большей части они общие, но бывают и исключения;
- Доступы. Важно контролировать уровни доступов всех участников проекта, особенно когда команда быстро растет;
- Тест-планы и баг-репорты. Раздел посвящен тестированию проекта и всему, что с ним связано. Хранение такой информации позволяет анализировать накопленные данные и делать последующие выводы;
- Технический долг — тут можно фиксировать костыли временные решения и компромиссы, которые нужно исправить в перспективе, чтобы проект не скатился, куда не нужно.
Регламент процессов
Как я писал ранее, мы занимаемся заказной разработкой, и большая часть нашей работы сводится к выполнению различных задач. Поэтому рассмотрим, пожалуй, наиболее важный для нас — это регламент постановки задач. Мы на своем опыте пришли к следующим правилам:
- Четко формулировать задачи и составлять понятные требования. Делать это так, чтобы исполнитель, зайдя в задачу, понимал, что от него хотят. Справедливости ради — бьемся с этой проблемой по сей день. Постановка задачи в духе «cделать фильтр — вот макет» не прокатит.
- Оценивать трудозатраты. Думаю, что большинство читающих — умнички, и оценивают задачи прежде, чем брать их в работу. Это неотъемлемая часть контроля процесса и сроков, только так, и никак иначе 🙂
- Делать декомпозицию на задачи по 6 часов. Выработали для себя это правило, потому что набили много шишек. Задачи гораздо проще контролировать, и при таком подходе можно своевременно реагировать на возникающие проблемы.
- Ставить ответственных и сроки на любом этапе задачи, иначе вы рискуете потерять ее из виду или бесконечно переносить.
- Фиксировать любую другую информацию, которая поможет упростить процесс разработки/менеджмента.
Не менее важная часть задач — отчетность. Она необходима, чтобы на любом этапе задачи участники понимали, какая работа уже проделана, а что осталось реализовать. Также это способствует снижению количества узких горлышек в команде, когда при смене исполнителя или менеджера весь процесс встает. Что включает в себя такая отчетность:
- Трекинг времени — сколько потратил на выполнение задачи. Так мы можем смотреть аналитику, прогнозировать и корректировать последующие оценки.
- Комментарии по итогу выполненных работ: что сделано, что осталось.
- Инструкции при необходимости (как запустить выгрузку, где лежит скрипт и т.д).
- Если задача не завершена или нужно больше времени — описание проблемы. В идеале получать от исполнителей сразу возможные варианты решения этой проблемы.
Регламенты разработки
Этот раздел напрямую влияет на качество проекта в техническом плане и кодовой базы.
Первое, с чего необходимо начать, это организация тестовых зон. Можно описать, какие площадки вы создаете, где вы их создаете. Следующее, это Readme проекта — информация, которая поможет понять, как развернуть проект у себя, где взять актуальный бэкап базы и т.д. Так при подключении новых разработчиков не будет необходимости проходить эти круги ада с каждым.
Code Style. Написание кода должно быть в едином стандарте, для этого придумали соответствующие правила, которые необходимо соблюдать.
Работа с Git. Изначально мы полагались на классическое Git Flow, но этого оказалось недостаточно. Поэтому выделили ряд необходимых правил:
- Например, мы именуем коммиты по следующему правилу: task_XXX, где XXX — номер задачи из трекера. Это позволяет связать историю коммитов с задачей и в последующем легко и быстро отслеживать нужные правки.
- Хуки, линтеры и пайплайны — вещи, с помощью которых можно упростить или автоматизировать процесс Code Review, Deploy и сократить трудозатраты.
- Прочая автоматизация — нет предела совершенству. На прошлом шаге можно не останавливаться, под свои нужды допиливать и автоматизировать процессы.
Итог
Проанализировав опыт сотрудников, мы выделили 3 основные причины, почему команда работает не так эффективно, как хотелось бы: отсутствие или неполная информация по проекту, нет четко регламентированных процессов взаимодействия в команде, а также процессов разработки, которые нуждались в оптимизации и доработке.
Кто разрабатывает регламенты бизнес процессов
Проект Описание Статус Отзыв Заявка
Разработка регламентов
Перед сотрудниками консалтинговой компании GANTBPM, которая решает задачи проектного менеджмента в различных отраслях народного хозяйства, была поставлена задача по созданию единой системы управления объектами недвижимости, формированию единой концепции, созданию дорожной карты реализации, разработке нормативно-регламентирующей документации по эксплуатации субъектов недвижимого имущества.
Многолетний положительный опыт работы нашей фирмы в данной сфере деятельности привлекает к ней не только российских заказчиков, но и зарубежных партнеров. разработка регламентов
Разработка регламентов
Разработка стандартов управления крупными объектами недвижимости распределенными по многим регионам России. Основной задачей, поставленной перед специалистами консалтинговой компании GANTBPM, была разработка принципов администрирования субъектов деятельности Заказчика. Единая система менеджмента объектов хозяйственной должна была сформировать общее представление о том, как должен быть организован в целом facility management.
После проведения тщательного анализа мы сформировали принципы координации работ при управлении, которая включала в себя фасилити и административный менеджмент.
Несмотря на то, что фасилити менеджмент является достаточно новым для России направлением, специалисты нашей организации имеют хороший опыт в организации системы эффективного управления логистическим комплексом. Разработка регламентов по направлению Facility Management способствует грамотному построению и функционированию инженерной и социальной инфраструктур зданий.
После подготовки единой концепции контроля за техническим состоянием зданий и сооружений был подготовлен комплект нормативно-регламентирующей документации в области регулирования деятельности субъектов недвижимости, стандарты по пожарной и экологической безопасности. Следующими документами, которые нам предстоит разработать, являются принципы организации повышения энергоэффективности логистических комплексов холдинга.
В целом работы по созданию руководства по эксплуатации административно-складских комплексов содержали:
- Подготовка заявления руководства холдинга
- Постановка целей и задач единой системы разработка регламентов
- Разработка дорожной карты реализации программы
- Формирование принципов управления
- Проработка принципов «одного окна»
- Разработка комплекта нормативной и регламентирующей документации
- Создание собственного центр сертификации
- Формирование методов планирования
- Разработка эффективной системы ТОиР
- Подготовка к внедрению методологии кодирования KKS
- Формирование показателей для ежеквартальной отчетности
