Попса

популярный светский альманах

Тег: процесс

Пять правил реформ — уроки Столыпина

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

 
 

Система

№ 1. Проводить преобразования системно

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

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

Системность преобразований нельзя путать с «пилотированием». В ряде случаев имеет смысл обкатать нововведение на фокусной группе и оценить его эффективность.

 
 

Пирамида

№ 2. Начинать с «низовых» потребностей

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

Например, если мы говорим о компании-разработчике ПО, начинать надо с базовых процессов. Система постановки задач, багтрекер, система связи, сборка продукта в одно действие, учёт плановых и фактических затрат, техническая документация, рецензирование кода. Основные вещи. Только тогда, когда они заработают без сбоев, можно думать о более «высокоуровневых» преобразованиях.

 
 

Стратегия

№ 3. Соблюдать стратегические интересы

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

Например, внедрение очереди запросов — не слишком популярное решение. Заказчики обязательно будут ругаться и давить, потому что надонадонадо срочносрочносрочносрочно. Однако если не организовать очередь, бардак не прекратится никогда.

Что сделать? Небольшую доработку, которая принесёт условные 60 000 руб. через месяц или отрефакторить алгоритм работы с кэшем, что ускорит работу продукта на 15-20 %, но не принесёт прямой прибыли? Если наша цель — качественный продукт, то безусловно, второе. Но лучше бы планировать работы так, чтобы подобных альтернатив не возникало.

 
 

Супермен

№ 4. Проводить селекцию кадров

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

Нанимаем медленно, увольняем быстро; всегда даём второй шанс, никогда не даём третий; ставим на ключевые посты «умных лентяев».

 
 

Механизм

№ 5. Добиваться исполнения регламентов

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

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

О псевдобюрократии

Бюрократ за столом
 

Глубинная причина возникновения дурной бюрократии

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

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

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

Разветвлённая бюрократическая структура стремится к состоянию, при котором все ключевые посты будут заняты сотрудниками, достигшими личного предела некомпетентности.

 
 

Основной признак истого бюрократа.

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

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

Подробнее о дурной бюрократии читайте в книге «Законы Паркинсона».

Но есть и другая форма бюрократии.

 
 

Правила полезной бюрократии.

Базовое правило: Каждый участник процесса должен точно знать, зачем процесс существует и почему он проводится так, а не иначе.

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

 
 
 

Кейс.

 

Вводная

В организации принят следующий порядок обработки запросов на изменение: регистрация, приоритезация, оценка аналитиком, согласование оценки, написание/корректировка требований, передача в работу, актуализация требований, сдача заказчику.

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

Цель достигнута? Да. Функционал работает так, как надо, правку провели очень быстро (там десяток строк кода, не больше). Всё было бы хорошо, если бы эти два специалиста существовали в вакууме, где кроме них и продукта никого нет.

Затраты — пять минут на разговор, двадцать минут на правку и заливку.

 
 

Последствия.

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

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

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

Потери на абсолютно бессмысленную работу — около 6 человекочасов всех участников.

 
 

Как надо.

Было бы немножко сложнее. Нужно было создать дефект на требования. Кусок функционала сейчас работает согласно требованиям, но требования неполны, упустили важный алгоритм. Менеджер продукта видит дефект на требования, хватается за голову, правит документацию, создаёт задачу и кидает её разработчику в очередь. Разработчик, когда до задачи доходит очередь, вносит правку, ассоциируя набор изменений с задачей. Тестировщик получает задачу на проверку уже автоматически и проводит проверку. Доработка сдаётся инициатору. Требования полны, в системе существуют явные артефакты корректировки.

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

 
 
Грамотно организованная бюрократия экономит время, предотвращая потери в будущем.