Censor morum
Глубинная причина возникновения дурной бюрократии
Есть сотрудник, справляющийся с задачами лучше других. Он становится кандидатом на повышение, после чего вырастает до руководителя и получает новый спектр обязанностей, зачастую требующий больших компетенций.
Если новоиспечённый руководитель хорошо справляется с новым спектром обязанностей, он снова становится кандидатом на повышение и, через некоторое время переходит на следующую ступеньку с новым спектром обязанностей и новыми требованиями к компетенциям.
Это происходит ровно до того момента, пока сотрудник не окажется на позиции, спектр обязанностей которой ему будет не по зубам. Эта позиция называется «личный предел некомпетентности».
Разветвлённая бюрократическая структура стремится к состоянию, при котором все ключевые посты будут заняты сотрудниками, достигшими личного предела некомпетентности.
Основной признак истого бюрократа.
У такого сотрудника есть несколько характерных черт. Самая яркая — неукротимое желание доказать (в первую очередь, самому себе) собственную нужность. Для этого он генерирует и спускает вниз огромное количество детальных регламентов и инструкций, чтобы создать видимость работы и получить желаемое чувство удовлетворения.
Именно эта особенность бюрократических структур делает их громоздкими, медленными и уязвимыми.
Подробнее о дурной бюрократии читайте в книге «Законы Паркинсона».
Но есть и другая форма бюрократии.
Правила полезной бюрократии.
Базовое правило: Каждый участник процесса должен точно знать, зачем процесс существует и почему он проводится так, а не иначе.
Вторичное правило: Каждый участник процесса должен иметь право высказывать соображения, относительно возможной оптимизации или отказа от этого процесса (решение принимает владелец процесса).
Кейс
Вводная
В организации принят следующий порядок обработки запросов на изменение: регистрация, приоритезация, оценка аналитиком, согласование оценки, написание/корректировка требований, передача в работу, актуализация требований, сдача заказчику.
Один из ключевых сотрудников обнаруживает, что кусок функционала соседнего продукта работает не совсем так, как нужно. Он технический эксперт и противник всякой бюрократии, поэтому он идёт к коллеге-разработчику соседнего продукта и убеждает сделать правку, что тот и делает.
Цель достигнута? Да. Функционал работает так, как надо, правку провели очень быстро (там десяток строк кода, не больше). Всё было бы хорошо, если бы эти два специалиста существовали в вакууме, где кроме них и продукта никого нет.
Затраты — пять минут на разговор, двадцать минут на правку и заливку.
Последствия
Спустя восемь месяцев на данный кусок функционала прилетает дефект. Тестировщик анализирует код и отвечает, что это не дефект, всё работает корректно. Менеджер проекта читает документацию по функционалу и понимает, что алгоритм, на который прилетел дефект, не описан в документации. У него на проекте есть кусок кода, который делает непонятно, что.
Менеджер проекта звонит менеджеру продукта с просьбой предоставить актуальную пояснительную записку. Менеджер продукта отвечает, что подобного алгоритма в этом функционале быть не может – не было таких доработок. Никаких данных не зафиксировано, по крайней мере.
Менеджер продукта идёт в отдел разработки, эмпирически вычисляет программиста, который мог такое запилить и садится к нему на уши. Анализируются процедуры, ищется код, делаются попытки восстановить цепочку событий. Удаётся выяснить, что восемь месяцев назад была правка, но она была как бы сама по себе. К ней не привязан дефект, нет никакой резолюции. Код анализируется, делаются предположения, как он работает. Менеджер продукта правит требования и снабжает менеджера проекта актуальной документацией.
Потери на абсолютно бессмысленную работу — около 6 человекочасов всех участников.
Как надо
Было бы немножко сложнее. Нужно было создать дефект на требования. Кусок функционала сейчас работает согласно требованиям, но требования неполны, упустили важный алгоритм. Менеджер продукта видит дефект на требования, хватается за голову, правит документацию, создаёт задачу и кидает её разработчику в очередь. Разработчик, когда до задачи доходит очередь, вносит правку, ассоциируя набор изменений с задачей. Тестировщик получает задачу на проверку уже автоматически и проводит проверку. Доработка сдаётся инициатору. Требования полны, в системе существуют явные артефакты корректировки.
Затраты на «бюрократию». Две минуты на регистрацию дефекта, пять минут на разговор с менеджером продукта, пять минут на правку требований, пять минут на постановку задачи, двадцать минут на правку и заливку разработчиком, сорок минут на тест и сдачу. Чуть больше часа против шести с лишним часов потерь при коррекции «по-быстрому».
Грамотно организованная бюрократия экономит время, предотвращая потери в будущем.
