Описывая свои впечатления от книги Генри Минцберга “Структура в кулаке” я обещал еще раз вернуться к тому, почему же менеджеры, выходцы из механистических бюрократий, способны убить разработку в маленьких софтверных компаниях. Выполняю свое обещание. (Да, и маленькие -- это до 40-50 разработчиков).
Для начала нужно определить некоторые понятия. Минцберг делит персонал организаций на пять категорий:
- операторы или операционное ядро. Это те сотрудники, который выполняют основную работу организации: производят товары, оказывают услуги, несут службу и т.д. Например, рабочие на заводе, почтальоны в отделениях почты, кассиры-операторы в банковских расчетно-кассовых центрах, врачи и медсестры в поликлинниках -- это все операторы;
- стратегический апекс -- это самое высокое руководство организации. Например, совет директоров компании, директор завода со своими заместителями, главный врач больницы и т.д.;
- серединная линия -- это менеджеры всех уровней, расположенные между операционным ядром и стратегическим апексом, отвечающие за непосредственную деятельность организации. Например, на заводе -- это мастера смен, начальники производственных участков, начальники цехов и т.д. Однако, если на заводе есть еще и своя столовая, а так же подсобное хозяйство с небольшой свинофермой, то руководители столовой и свинофермы не входят в серединную линию, т.к. на них не лежит ответственность за выпуск продукции завода;
- техноструктура, состоящая из разного рода аналитиков. Техноструктура отвечает за формирование и контроль над процессом производства или оказания услуг. Например, мастера по ремонту и наладке оборудования являются частями техноструктуры. Нормировщики, методологи, инженеры по качеству, специалисты по технике безопасности и т.д. Техноструктура не производит продукцию, но определяет процесс его производства, либо в общих чертах, либо в мельчайших подробностях;
- вспомогательный персонал. Например, это сотрудники заводской столовой. Или юрисконсульты. Или библиотекари. Т.е. те, кто создают хорошие условия для сотрудников организации, но не занимаются производством продукции, а так же не определяют/регулируют/контролируют процессы производства.
Базисом любой организации является операционное ядро. Над которым размещается серединная линия, переходящая в стратегический апекс. А по бокам от стратегической линии -- техноструктура с одной стороны и вспомогательный персонал с другой.
Одной из пяти выделяемых Минцбергом организационных форм является механистическая бюрократия. Которая характеризуется тем, что многочисленные сотрудники операционного ядра выполняют относительно простые, хорошо формализуемые и подверженные узкой специализации операции.
Например, рабочие на конвейере сборочного цеха могут выполнять всего одну или две операции на протяжении всего рабочего дня. Каждый рабочий выполняет только свое действие, следующий рабочий -- свое и т.д. Каждый из них делает свою простую, узкоспециализированную операцию, но их последовательность и суммарный эффект рассчитан таким образом, чтобы на выходе получить сложный итоговый результат, например, автомобиль или компьютер.
Следовательно, эффективность труда в механистической бюрократии зависит от нескольких составляющих. Самыми важными в контексте этого разговора являются две из них:
- Насколько хорошо выстроен и отлажен процесс производства. Если не ошибаюсь, Генри Форд на своих заводах с секундомером замерял время выполнения каждой операции и оптимизировал операции так, чтобы свести это время к минимуму. Соответственно, роль техноструктуры и ее аналитиков в механистичеких бюрократиях чрезвычано важна: именно они отвечают за разделение процесса производства на элементарные операции, стандартизацию и формализацию каждой из операций, написание должностных инструкций для операторов, оформление требований к найму новых сотрудников, выработка процедур обучения персонала и т.д., и т.п.;
- Насколько хорошо конкретные операторы выполняют свою работу. Не филонит ли кто-нибудь из них, не гонит ли брак, не портит ли оборудование, не грубит ли клиентам и т.д. В механистической бюрократии вопросы контроля являются краеугольными, т.к. операторы выполняют однообразную, зачастую скучную, не приносящую никакого интереса и удовлетворения работу. А, поскольку нет заинтересованности в работе, то и качество ее выполнения обеспечивается лишь тотальным, неусыпным контролем и жесткими мерами.
По поводу второго пункта приведу цитату из “Структуры в кулаке”, из главы, посвященной особенностям функционирования механистических бюрократий:
Подмена целей средствами, низкий уровень обслуживания клиентов, различные проявления отчуждения рабочих -- все это ведет к ужесточению контроля над поведением, “завинчиванию гаек”. Негласным девизом механистической бюрократии можно считать слова “Сомневаешься -- контролируй”. Все проблемы должны решаться при помощи технократических тисков. Но поскольку именно это в первую очередь и порождает бюропатологии, в большинстве случаев проблемы только усиливаются, контроль ужесточается и т.д.
Так вот проблема с выходцами из банков в том, что банки -- это организации с механистической бюрократией.
А это означает, что из какой бы части организационной структуры банка не пришел менеджер, он не может не быть искалечен общими принципами функционирования подобных организаций: все работы по регламенту/процессам и с обязательным тотальным контролем на всех уровнях.
Даже не знаю, какой вариант хуже -- когда человек является выхлопом серединной линии, привык работать по готовым регламентам и заставлять других следовать этим регламентам. Или когда человек вышел из техноструктуры и привык формировать рабочие процессы для других сотрудников.
Ни то, ни другое не есть хорошо для маленькой софтверной компании. Особенно, если компания занимается разработкой и продвижением собственных продуктов.
Почему? По нескольким причинам.
Во-первых, программирование, как занятие, вообще не очень хорошо поддается стандартизации, формализации и разделению на узкоспециализированные задачи. В маленьких компаниях это особенно актуально. Даже если не брать крайние случаи, которые случаются в стартапах, когда один и тот же программист с утра пишет драйвер для железяки на C с вкраплениями ассемблера, а после обеда, уже на PHP, Web-морду для этой железяки, то все равно спектр лежащих на разработчиках задач очень большой. Особенно, если речь идет о ведущих разработчиках.
Соответственно, в маленьких компаниях техноструктуры либо нет, либо же она играет совершенно незначительную роль по сравнению с таковой в крупной механистической бюрократии. Нет жестких производственных процессов, нет отдельно стоящих аналитиков, придумывающих и насаждающих формальные процедуры. Нет мелочного тотального контроля. Нет отношения к операторам (т.е. к разработчикам, тестировщикам, техписателям и т.д.) как к незаинтересованным в результатах своего труда обезличенным штатным единицам, за которыми нужен глаз да глаз.
Во-вторых, вокруг и внутри маленькой компании все очень быстро меняется. Либо она сама переориентируется на новую нишу или продукт. Либо же ее вынуждают к этому крупные клиенты, имеющие возможность разговаривать с позиции силы и навязывать свои условия, например, по срокам или объемам функционала.
В таких условиях мобильность должна быть везде: нет времени разрабатывать новую стратегию, писать новые инструкции или полностью, в деталях, прорабатывать новую концепцию, затем спуская ее вниз на согласование/уточнение, и лишь затем запуская в реализацию. Да и, зачастую, необходимые для этого знания и умения есть только в самом низу, в операционном ядре, т.е. у разработчиков. И этим разработчикам нужно ставить задачу напрямую, без какой-то промежуточной иерархии менеджеров срединной линии, иначе можно и задачу исказить, и время потерять.
В общем, жестких процессов нет, каждый сотрудник не винтик, а очень важная часть организации, подгонять и ежечасно контролировать никого не нужно, актуальная и откровенная информация должна свободно распространяться в обе стороны...
Менеджеры оказываются в совершенно других условиях. Центры силы расположены не там -- в операционном ядре, а не в техноструктуре. Мнение какого-то одержимого гика-программиста для успешности проекта может значить больше, чем мнение нескольких степенных и солидных начальников отделов.
К таким условиям нужно либо приспособится самому, либо перекроить их под себя, перестроив организационную структуру компании и изменив принципы ее работы. Какой вариант поведения предпочтет в таких условиях среднестатический менеджер из банка? Оставляю этот вопрос в качестве упражнения читателю.
Как и поиск ответа на вопрос, сможет ли маленькая софтверная компания успешно работать дальше, если внедрить в ней жесткие процессы, относиться к сотрудникам, как к винтикам, нуждающимся в понуканиях и ежечасном контроле, скрывать информацию или крайне дозировано распространять ее, спуская по цепочке менеджеров серединной линии?
Думаю, что тогда читатели поймут, почему я считаю, что нельзя доверять управление маленькими софтверными компаниями выходцам из банков. ИМХО, Генри Минцберг в своей книги тридцать лет назад писал о том же самом. Поэтому напоследок приведу еще одну цитату оттуда про механистические бюрократии:
Механистические бюрократии отлично действуют в стабильном окружении потому, что они приспособлены для решения специфических, заранее определенных задач. Их сильная стороны -- эффективность, а не инновации. Если организация надевает работнику шоры на глаза, то стоит ли удивляться, что у них отсутствует периферийное зрение? Менеджерам здесь платят за то, что они повышают эффективность, добиваются снижения расходов, совершенствуют процедуры контроля и стандарты, а не за риск и творчество.
Комментариев нет:
Отправить комментарий