Чтобы выполнить пункт 1, у топ-менеджеров должны быть полномочия. Они их реализуют путём выпуска обязательных к выполнению распоряжений. Распоряжением (явным или неявным, это можно обсуждать) могут быть выпущены (не «утверждены», а «выпущены"/released/"приняты"/delivered):
- регламенты и изменения к ним
- чеклисты: и содержание, и указание, как они реализованы — например, в каком софте
- планы учебных мероприятий (надо ведь сотрудникам разъяснить, что изменилось в их методах работы, а также первый раз провести заполнение чеклистов с ними вместе, чтобы потом они делали это сами. Если что пойдёт не так, немедленно поменять регламент и чеклист. Если сотрудник заартачится — проявить лидерство, а если упрётся — уволить без сожаления).
А потом распоряжения сотрудникам надо будет выполнять, а топ-менеджер будет отслеживать (или организовывать отслеживание) их выполнение.
И вот тут проблема: надо вернуть полномочия по принятию решений как менеджерам (включая топ-менеджеров), так и инженерам. В текущей организации есть сдвиг полномочий на ступеньку вверх, это приводит к появлению дополнительного срока на «утверждение». В управлении это ведёт к диким задержкам. Как надо? Смотрим труды John Doyle (
John Doyle: синтез уровня системы и бешеные зомби: ailev — LiveJournal) по «синтезу уровня системы»: контроллер/управляющий какого-то уровня посылает сигнал прямо на своё исполнительное устройство, хотя и участвует в сложной сети обратных связей (например, посылает копию управляющего сигнала, точнее, делает её доступной для вышестоящего уровня управления).
Вот как это выглядит на предприятии сейчас (случай гипотетический! Но в каждой шутке есть доля шутки):
- топ-менеджер пишет докладную записку с ПРЕДЛОЖЕНИЯМИ о подготовке приказа (слово «предложения» тут капслоком, ибо это верный лексический признак того, что разработчик не принимает решение, а бесправный аналитик — то есть ни разу не топ-менеджер).
- какая-нибудь кадровая служба или канцелярия (они-то тут причём?) переводит докладную записку в формат готового к подписанию приказа, который УТВЕРЖДАЕТ регламент, чеклисты, даёт указание айтишникам и обязывает дальше следовать регламенту как корпоративному стандарту.
То есть вместо управления/организовывания топ-менеджер делает «предложения по управлению», а потом генеральный директор осуществляет управляющий акт. Разработчик только ПРЕДЛАГАЕТ (как аналитик, пишет «аналитический отчёт» и прилагает отдельно «рекомендации», а кто-то уровнем выше УТВЕРЖДАЕТ «рекомендации»). Это долго и неверно (ибо тот, кто утверждает, плохо владеет ситуацией — он может ориентироваться только на металл в голосе предлагающего и непротивление окружающих предложениям, когда «принимает решение об утверждении». «Принятие решения об утверждении» — это не принятие собственно организационного решения! Это совсем другое!
Налицо каскадирование: каждый уровень служебной иерархии занимается спихиванием исполнения вниз, а ответственности вверх. Так что работа двух смежных уровней (один предлагает, другой утверждает) это хороший случай, чаще один разрабтывает (сотрудник топ-менеджера), а другой (топ-менеджер) просто передаёт вверх на утверждение генеральному. Ну, и если уровней десять, то каскад на десять уровней. Не спрашивайте, что там думает архитектор предприятия про такую модульность — архитектора предприятия там нет. А генеральный конструктор? У него разузловка/предложение модульной структуры изделия делается примерно так же — не инженерно, а начальственно, «предложением-утверждением».
Против этого работает инженерная парадигма, в которой инженер-проектировщик выпускает проектную документацию (в случае организатора это как раз регламенты и чеклисты по изменению состояния какого-то предмета регламента), а инженер-технолог потом реализует этот проект на заводе.
Но постойте, а как действуют инженеры? Вы удивитесь, они сегодня копируют менеджеров: они тоже стали аналитиками, которые не выпускают инженерные рабочие продукты, а только ПРЕДЛАГАЮТ, а какие-то их начальники их УТВЕРЖДАЮТ. Та же самая сдвижка «шкуры инженера на кону» на уровень вверх. Инженер-разработчик не говорит, «согласно моим расчётам в ракете будет 3 ступени, а варианты с двумя и четырьмя ступенями не прошли» — и дальше все остальные инженеры ориентируются на него. Нет, он делает «предложение», а потом кто-то «утверждает» это предложение. Один генеральный конструктор пожаловался, что он у себя на почте вечером находит примерно двести предложений, требующих утверждения.
А как там с коллизиями? В нашем курсе системной инженерии говорится: «В DevOps тоже рассматривают версионирование (для описаний) и управление конфигурацией (для целевой системы), на этом основана практика непрерывной интеграции (continuous integration, в любой момент времени есть готовый целостный вариант системы). Часть этой практики — магистральная разработка/trunk-based development. Управление изменениями в виде независимого принятия решений какой-нибудь „комиссией по изменениям“ экспериментально было показано, что не работает (см. подробности в книге „Accelerate“). Это очень контринтуитивно, но команда сама принимает решение, что ей добавлять в общий продукт. Нет долгоживущей версии baseline и трудной процедуры внесения в неё изменений. Более того, одновременно в работе (например, при A|B-тестировании) могут находиться несколько версий системы, все они „главные“, и все они „экспериментальные“. В любой момент жизни системы она рассматривается не как окончательная конфигурация на базе окончательной версии описаний системы, полученных из разработки, но как „текущая“, которая будет меняться много раз в день. Поиск конфигурационных коллизий — тут». Ещё фрагмент из этого же курса: «каждая команда выдаёт поток небольших инкрементальных изменений в общую «магистраль» (trunk) сборки, и это происходит ежедневно (иногда ежечасно), но не еженедельно и уж тем более не ежемесячно. Это практика магистральной разработки (trunk-based development) вместо практики «долгоживущих ветвей для изменений» (long-lived feature brunches) и последующих больших шагов по интеграции. Сегодня это уже практика не только программной инженерии, но и «железной» инженерии: в самолётостроении конструкторы результаты своей работы выкладывают в общую PLM-систему немедленно, каждый день, а не по мере окончательной готовности каких-то крупных частей. Ещё лет десять назад в моде была поговорка, что «дураку половину работы не показывают», сегодня на эту поговорку сразу возражают:
- Смотрят не дураки, поэтому с такими заявлениями нужно быть осторожней.
- Значит взял слишком большую работу, надо было поделить её на части, которые можно показывать.
- Если не показываешь, то ошибки (начиная с того, что вообще ненужную работу делаешь, не тем занялся) выявятся позже, а это недопустимо.
- Покажи ещё и тесты для своей работы.
Каждая интеграция маленького инкремента не занимает много времени, а если выявляются «большие проблемы» (например, необходимость доработки интерфейсов), то они выявляются рано. То, что это небольшие законченные части, помогает как с обеспечением «потока» (flow) работ в части менеджмента (отсутствуют «заторы» в местах ограничения/constraints потока — small batch size практика), так и помогает быстро находить ошибки, уменьшать число переделок/reworks в части прикладной инженерной работы".
Итого: каждый сам принимает свои решения и немедленно отдаёт результаты этих решений для всей команды, а не «предлагает на утверждение» и не «утверждает решения других». Тут и «шкура на кону», и субсидиарность, и continuous delivery и даже в какой-то мере you build it, you run it! Много самых разных идей, которые все про одно и то же: давайте люди будут принимать решения и воплощать их, а не «утверждать». «Утверждение» — это только замедление дела, прощё каждому принимать свои решения и дальше быстро обнаруживать конфигурационные коллизии и устранять их, сотрудничая с другими инженерами и менеджерами.
Вернуть инженерию и менеджмент на предприятия вместо аналитики и начальничества! Это резко ускоряет работы:
- меньше время на выпуск каждого решения («выпуск» вместо «предложения — утверждения»), меньше времени на лишнюю «координацию», больше на саму работу
- ранняя обратная связь, то есть раннее устранение конфигурационных коллизий, ошибки не успевают закрепиться
- устраняет длинные цепочки «один предлагает, другой утверждает, третий вносит изменения в софт». Кто предлагает, тот и вносит своей властью решения как изменения в софте! Отредактировать в универсальном моделере строчку чеклиста — это не так трудно, и много быстрее, чем вовлекать в это дело множество людей и устранять ошибки недопонимания.
И ещё замечание сюда же: власть никогда не дают, её берут!