Опасности при измерении продуктивности

Тема личной эффективности витает в воздухе, в книгах и на бизнес-конференциях не первый год. Взбудораженные очередными гениальными техниками тысячи менеджеров по всему миру пробуют на практике применить все то, без чего, как им кажется, невозможен современный бизнес. Под катом прекрасный рассказ Сэма МакКафи ^[1].

«Как вы рекомендуете измерять индивидуальную продуктивность моих инженеров?». Был уже поздний вечер, мне предстояло час провести за рулём, и не оставалось уже сил отвечать на вопросы. Но этот молодой менеджер, задавший вопрос, чья презентация шла после моей, зацепил меня. Он словно прочитал мои мысли, вытащил на свет самую большую досаду по поводу управления и передал мне её в форме вопроса. Меня наполнила энергия, и я спросил: «Прежде всего, зачем вам вообще это делать?». Молодой человек ответил: «Ну, меня только что повысили, чтобы я управлял командой инженеров, которые раньше были моими коллегами. Хочу быть уверенным, что я делаю для них хорошую работу. Хочу иметь возможность измерять их, чтобы было от чего отталкиваться при дальнейшей оценке их продуктивности. Хочу быть уверенным, что все работают добросовестно…». Звучит совершенно резонно, верно? Тем хуже, поскольку это совершенно, абсолютно неверно. «Ну», — ответил я, вешая сумку на плечо, — «почему бы вам не пройтись со мной до парковки и описать, что вы сейчас делаете? А я дам честный отзыв». В конце концов я описал ему три конкретные методики, которые он мог сразу применять в своей команде. Но чтобы они имели какой-то смысл, нам сначала пришлось быстро рассмотреть ключевые трудности, с которыми сталкиваются компании подобно его.

Сегодня все мы — софтверные компании

Марк Адрисен (Marc Andreessen) как-то сострил, что «программное обеспечение пожирает мир». Он намекал на растущую зависимость от технологий практически всех индустрий, а не только софверных компаний.

Расцвет SaaS, облачных технологий, больших данных, ИИ и машинного обучения, а также разнообразие мобильных устройств с лёгким доступом к высокоскоростному интернету представляет одновременно опасность и возможность для традиционных компаний, особенно тех, что были основаны до интернет-революции последних десятилетий. Эти компании сегодня сталкиваются с выбором, «действовать как софтверные компании» или быть сокрушёнными конкурентами.

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

Я регулярно сталкиваюсь с тремя основными препятствиями к внедрению инноваций и обретению гибкости подобными компаниями:

1. Организационные структуры мешают сотрудничеству.
2. Устаревшие теории управления, глубоко укоренившиеся в культуре компании.
3. Правовая или нормативная жёсткость, препятствующая рискованным решениям.
С третьей проблемой нужно разбираться на исполнительном уровне. Но любой менеджер, возглавляющий проект по разработке продукта, может серьёзно повлиять и на первые две.

Традиционная теория управления сломана

Два авторитетных мыслителя начала двадцатого века Фредерик Уинслоу Тейлор и Генри Гантт оказали глубокое и продолжительное влияние на традиции в сфере управления. Они были в рядах тех, кто сформировал интеллектуальную основу для теории управления в эпоху американского промышленного производства. К сожалению, их продолжающееся влияние на методики управления в информационную эру уже не приносит никакой пользы.

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

Во многом благодаря влиянию Тейлора работники сосредоточены на своей загруженности (utilization) как метрике эффективности. Это имело смысл в мире немеханизированного обслуживающего труда. Но сегодня мы живём в совсем других реалиях.

Примерно в тот же период Гантт разработал знаменитую диаграмму Гантта ^[2] для управления проектами. Вы все наверняка сталкивались с этой диаграммой. Это фреймворк для визуализации всех ресурсов и задач, необходимых для завершения проекта.

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

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

Деминг и новая наука управления

Одним из ранних критиков измерения индивидуальной продуктивности был Уильям Деминг. В своих статьях и выступлениях в начале 1950-х он выделил и описал опасности излишней сосредоточенности на «индивидуальном».

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

Деминг часто критиковал практику годовых бонусов за индивидуальную продуктивность, как один из аспектов чрезмерного внимания к «индивидуальному». В интервью Industry Week в 1994-м он поделился своими мыслями о причастности к сложной системе:

«Велики, почти огромны шансы, что всё происходит так потому, что является следствием системы, в которой он работает, а не следствием его собственных усилий. Иными словами, продуктивность не может быть измерена. Вы измеряете только комбинированный эффект о системы и его усилий. И разделить их вы не можете.».

При сотрудничестве Деминга с японскими учёными и инженерами в ходе послевоенного восстановления, линейным рабочим в цехах позволили улучшать результаты своей работы как команды, что стало одним из ключевых компонентов такого явления, как производство «точно в срок» (Just-in-Time).

Хорошо известная производственная система Toyota — насчитывающая среди своих потомков методологии Agile and Lean Startup — является одним из очевидных результатов широкого сотрудничества японской промышленности с Демингом. Это инновационная новая философия, которая в конце концов в 1980-х проникла в США благодаря обмену между американскими автопроизводителями и руководителями из Токио, и наконец была популяризирована под названием Lean. Учитывая, что Деминг был столь влиятельной фигурой не только в создании производства «точно в срок» в Японии и Lean-производства в США, но и в создании методологий Lean Startup и Agile Software Development, возможно, нам стоит прислушаться к его предупреждениям относительного того, почему нам не следует измерять индивидуальную продуктивность.

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

По его тону и взгляду я понимал, что им движут только лучшие побуждения. Он хотел всё делать правильно в своей новой должности. Более того, он явно уважал инженеров, которые перед ним отчитывались (он только что был одним из них), и искренне хотел помочь и направить каждого члена команды, который изо всех сил старался идти в ногу с остальными.

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

Работа в сфере знаний требует новых подходов

Несмотря на впечатляющий успех по всему миру производственной системы Toyota и Lean-производства, внедрение Lean-методик в сферу знаний в больших организациях продвигается медленно. Я сильно подозреваю, что как минимум одной причиной является всё ещё очень сильное влияние Тейлора и Гантта при обучении управленцев.

Раньше руководство старалось оценивать работников, разрабатывавших продукт, по качеству, скорости, стоимости и прибыли. В современном мире значение имеют только изобретательность, умение сотрудничать и решать проблемы. Все обслуживающие, административные и сдельные работы из 20 века — даже на уровне «белых воротничков» — автоматизируются гораздо быстрее, чем вам, вероятно, кажется.

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

Во-первых, компании медленно переходят из состояния, когда большинство сотрудников имеют операционное или проектное мышление ^[3], к мышлению ^[3], ориентированному на клиентов или продукт. Во-вторых, задачи, не относящиеся напрямую к основному процессу создания продуктов и обслуживания клиентов отдаются на аутсорсинг в специализированные фирмы, либо целиком автоматизируются.

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

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

Это более-менее то, что я сказал тому молодому менеджеру, пока складывал в машину пиджак и сумку.

«Смотри, ты хочешь, чтобы все в команде эффективно работали вместе, правильно? Тогда ты должен разработать стимулирующую и оценивающую структуру вокруг команды, а не отдельных сотрудников».

Я сказал ему сделать следующее:
1. Измерять продуктивность работ, а не активность людей. Организовать работы в виде очереди (план, список задач, что угодно), в зависимости от важности для бизнеса. Единственная метрика, имеющая значение, это скорость доставки работы клиентам.
2. Собирать людей в пары или группы для выполнения одного вида работ за раз. Позволить им сосредоточиться на совместном создании, тестировании, поставке этой работы, прежде чем давать им новую работу из очереди. Более того, позволить им самим выбирать себе пару или группу (возможно, на первых порах понадобятся небольшие корректировки).
3. Вдохновить команду на самостоятельно улучшение процесса. Регулярно собирать всех и анализировать, что работает, а что нет. Позволить команде озвучивать проблемы и предлагать идеи, которые, как им кажется, помогут в решении.

Ваша задача — помочь выбрать приоритеты на основе потребностей бизнеса, убрать препятствия, замедляющие команды, и отчитываться о прогрессе бизнесу. Это уже довольно много. Добавьте к этому помощь в построении карьеры и наставничество, и вы уже станете руководителем получше многих.

По пути домой я думал: «Какой хороший вопрос. Нужно как-нибудь превратить эту беседу в публикацию для блога».

Автор: Parallels

Источник ^[4]