Войти в систему
Войти с помощью соц. сетей:
Самое главное — разговор происходит, и это безопасный разговор.
Аарон Бьйорк
Не так давно Брайан Харри, корпоративный вице-президент Microsoft, увидел в своем блоге неожиданный комментарий. «Вполне очевидно, — писал читатель с ником Kasper, — что последние полгода вы применяли Agile-инструменты… Интересно, как долго вы будете уделять внимание этой области?»
Кого-то удивит тот факт, что Microsoft в принципе следует Agile. В 2016 году прибыль этой гигантской корпорации составила $850 млрд, а число сотрудников — 114 тысяч человек. Во всем мире к Microsoft относятся как к огромному линкору, сильному и мощному, но тяжелому в маневрировании и не всегда удобному для пользователей.
Именно этот образ пришел мне в голову, когда Аарон Бьйорк, менеджер группы проектов в подразделении разработки Microsoft, связался со мной и предложил поделиться историей об Agile-трансформации Microsoft с SD Learning Consortium.
Подразделение разработки включает в себя около четырех тысяч человек. Всего в нем сотни команд, каждая из которых состоит из 10–12 членов. Команды работают в трехнедельных спринтах. Бьйорк руководит группой Visual Studio Team Services. Эта группа включает в себя 40 команд и в общей сложности около 500 сотрудников. Сам Бьйорк отвечает за деятельность семи команд.
Подразделение разработки создает ряд продуктов и услуг, среди которых Visual Studio, Visual Studio Team Services, Team Foundation Server и TypeScript. Подразделение разработки стоит во главе движения за достижение компанией большей гибкости. Оно владеет концепцией «единой инженерной системы» (1ES) и продвигает его в компании. Другие группы Microsoft, например Windows, Office и Bing, отделены друг от друга, но все находятся на разных стадиях Agile-трансформации. Руководители ежемесячно оценивают, как крупные подразделения внедряют новые процессы.
Мы провели несколько рабочих выездов и обнаружили, что теперь Microsoft похожа не на гигантский линкор, а на флотилию скоростных катеров, которым удается синхронно маневрировать.
В июле 2011 года Брайан Харри объявил в блоге о корпоративной приверженности Agile. Эта публикация, по сути, представляла собой признание в любви, и многие читатели отнеслись к этому скептически. Разве гиганту типа Microsoft можно научиться гибкости?
Кен Швабер, один из создателей Scrum, выразил общую позицию, обратившись к Харри с вопросом: сможет ли такая крупная корпорация, как Microsoft, перестать относиться к людям как к «передаваемым, анализируемым и оптимизируемым ресурсам»? Надо заметить, что очень маленький процент американских компаний, перешедших на метод «бережливого производства», следует его ключевому принципу — «уважение, признание ценности и вовлечение сотрудников». Не обернется ли следование Agile, о котором объявила Microsoft, приверженностью лишь внешним формам Agile, а не ее ценностям? Не окажется ли это той же старой «предсказуемой моделью производства, обернутой в инструменты Scrum», которая не позволит создавать креативные, сложные, качественные продукты?
К счастью, по итогам наших рабочих визитов мы можем сообщить, что ценности Agile в подразделении разработки Microsoft живы и процветают. Последнее не только само использует Agile-практики, но и внедряет их во всей компании. Более того, каждый, с кем мы пообщались, придерживается их в своих мышлении, речи и образе действий. Уважение, признание ценности и вовлечение сотрудников в удовлетворение потребностей клиентов играют в Microsoft важную роль.
Принимавший нас Аарон Бьйорк любит играть в гольф. Довольно необычное хобби для разработчика ПО! В свободное время он также помогает родителям на их небольшой ферме. Он изучал финансы и информационные системы в Вашингтонском университете, однако не задержался в этой области, потому что, по его словам, обладал огромной энергией и креативностью. Перспектива заниматься финансами его совершенно не привлекала. В 2002 году он начал карьеру в Microsoft в качестве разработчика, а через семь лет был назначен руководителем проекта (на языке Scrum — «владелец продукта»). Почему он занялся новым направлением? Бьйорк сравнивает свой интерес с автомобилем. «Мне нравилось открывать капот и залезать руками в двигатель, — рассказывает он. — Но на самом деле я хотел решать, какой “автомобиль” мы хотим разработать, и вносить свой вклад в “мелкие детали” вроде цвета кожаной обивки». Бьйорк знает, что эти мелочи важны потребителям. Это его страсть.
«Моя задача, — объясняет он, — выслушивать потребителей и следить за тем, чтобы мы создавали востребованный ими продукт, который они будут покупать. Также моя обязанность — проводить различие между желаниями и потребностями и при необходимости извиняться за то, что мы не в состоянии сделать».
Трансформация Microsoft заняла изрядный период времени. Со своей предыдущей командой Аарон начал экспериментировать с Agile и Scrum в 2008 году. Примерно через год Scrum внедрили еще несколько команд, и в различных частях Microsoft возникли новые центры Agile. В 2010 году решение «стать гибкой» приняла группа Team Foundation Server. Все ее команды применяли практики и роли Scrum и работали трехнедельными спринтами в едином темпе. Благодаря этим успехам в июле 2011 года Брайан Харри публично объявил в своем блоге о приверженности Agile и Scrum в группе Visual Studio. Позже в том же году «стать гибким» решило все подразделение разработки.
В июле 2015 года, когда мы впервые посетили Microsoft, группа Visual Studio Team Services вошла в первую неделю 87-го спринта. В мае 2016 года мы попали на вторую неделю 101-го спринта. Трехнедельные спринты продолжаются в стабильном ритме, несмотря на праздники и преобразования в компании. (Правда, на время праздников спринт «облегчается».) Командам нравится этот ритм и упорядоченность, которую он дает.
Но путь Agile-трансформации вовсе не походит на прямой маршрут из точки А в точку Б. Внедрение практик Scrum — планирование спринтов, бэклоги, ежедневные стендапы, ретроспективы — лишь часть задачи. Самое главным — и сложным — оказалось изменение мышления всех участников.
Это бесконечный путь. «Трансформация, — говорит Бьйорк, — не похожа ни на сплошной кошмар, ни на историю триумфа. В ней есть взлеты и падения. Одни вещи мы делаем хорошо, другие плохо. Есть области, которые мы усовершенствовали».
«Изначально было очень тяжело. Прошло много времени, прежде чем мы cумели успешно завершить трехнедельный спринт, — продолжает Бьйорк. — В реальности мы работали не спринтами, а этапами. По его завершении команда заявляла о готовности новой функции и устраивала праздник. Затем я пробовал эту функцию, и она не работала. Команда сокрушалась: “Ой, мы не провели настройку и не апгрейдили продукт под нее”. Я уточнял: “Но вы же сказали, что все сделали!”. Команда отвечала: “Ну да, мы все сделали. Мы просто не провели настройку и апгрейд”. Лишь со временем люди поняли, что следует полностью выполнять работу в течение каждого спринта. На осознание этого ушел год».
«Например, давайте перестанем руководствоваться сроком. Давайте исходить из ценностей. Давайте поставлять продукт тогда, когда он готов. Мы научились не менять дату поставки из-за внешних событий. Если возникает проблема, команда по мере возможности ее решает — или просто не проводит развертывание этой функции. В любом случае решение команда принимает самостоятельно. Также она сама проводит нагрузочное тестирование и составляет документацию. Долгое время это казалось нам странным и неудобным, — продолжает Бьйорк. — Теперь этот метод стал частью нашего ДНК».
Ниже представлены ключевые аспекты, которые, по мнению Бьйорка, необходимы для внедрения Agile в глобальном масштабе.
Цель Microsoft — обеспечить согласованность наверху и автономность внизу. «Последняя очень нужна командам, — настаивает Бьйорк. — Именно она окрыляет их и наделяет желанием создавать большую ценность для клиентов. Но в то же время их работа должна быть согласована с руководством. Излишний контроль мало кому приятен, однако его недостаток ведет к хаосу. Представьте себе: каждый делает что хочет; нет никаких общих сценариев; клиенты разочарованы; работа теряет смысл. Менеджеры всегда стремятся найти баланс».
Руководство устанавливает правила. К ним относятся разъяснение ролей команд, ритма, терминология и допустимое количество ошибок и недочетов, то есть багов.
Команда автономна в вопросах планирования и выполнения своей работы и может применять разный подход в общих рамках. Она сама выбирает конкретные практики разработки — например, самостоятельно решает, применять ли парное программирование (для сравнения: в Menlo Innovations, о которой мы говорили в , программирование в парах обязательно).
«Роль руководства похожа на определение правил дорожного движения, — разъясняет Бьйорк. — Фактически трасса помогает вам ехать быстро и вы можете гнать по ней с бешеной скоростью. Но есть определенные правила. Вы должны включать поворотник, когда пересекаете полосу, и в определенные моменты сбавлять скорость. Ответственные лица могут сделать трассу гораздо безопаснее, установив дополнительных “лежачих полицейских” и светофоры через каждые полтора километра. Но тогда движение на трассе замедлится. В Microsoft мы применяем тот же подход. Мы определяем для команд минимальные правила дорожного движения. При этом мы должны быть уверены в том, что они помогают командам быстрее двигаться и достигать желаемой цели, а не замедляют темп».
Конечно, когда Бьйорк спрашивает команду разработчиков «Какие указания руководства затрудняют ваше движение?», на него обрушивается целый град жалоб. «Они предъявляют массу претензий! Они ждут этого момента! Они пользуются случаем высказать все, что я делаю не так. И мы обсуждаем все, что у них накипело. Самое главное — разговор происходит, и это разговор без отрицательных последствий для кого-либо».
Что происходит, когда команде не удается выполнить все необходимое за один спринт, притом что никакой менеджер не отслеживает ход выполнения задач? «Командам необходим график сгорания задач, — говорит Бьйорк. — Но знаете, что происходит, когда они отстают? Мы обсуждаем то, что нужно сделать, и все равно добиваемся результата, поскольку именно такое поведение предписывает наша корпоративная культура. Что я выиграю, если буду кричать на людей или следить за графиком сгорания задач? Я должен решить, что мне важнее — идеальный график сгорания или откровенный разговор? В конечном счете нужно выбирать второе».
В этом и заключается различие между мышлением и практиками. Важно, чтобы люди понимали, почему они следуют практикам и несут ответственность за созданную ими ценность. Если ежедневные стендапы не работают, не прячьте голову в песок — сделайте что-нибудь! Именно здесь возникает автономность. Как говорит Бьйорк: «Ты контролируешь ситуацию! Ты отвечаешь за все!».
В подразделении разработки Microsoft внутренние отношения регулируются самими командами настолько, насколько это возможно. Каждая знает, чем занимаются остальные. Они в одной упряжке и вместе трудятся над качеством продукта в целом. Если работа одной команды зависит от другой, она не будет ждать следующего совещания, чтобы заявить об этом, — программные менеджеры и менеджеры по разработке сами договариваются между собой.
Разумеется, неожиданности происходят и на совещаниях: «О, так вы уже начали работать над этим? Мы не знали! Надо обсудить нюансы». Задача менеджеров — убедиться в том, что команды встретились, пообщались и разобрались в ситуации.
Ожидается, что в план трех спринтов будут включены все взаимоотношения. Бьйорк работает с семью командами. То же самое происходит в других шести группах. Менеджеры действуют в одном пространстве. Общение происходит постоянно.
Каждые три месяца проходит стендап под названием «Встреча функциональных команд», во время которого каждая делится своими планами. Подопечным Бьйорка отводится 90 минут на выступления, то есть каждая команда должна уложиться в 10–15 минут. В этом мероприятии участвуют все «боевые единицы». Эта регулярная «церемония» предоставляет руководству подразделения разработки возможность вникнуть в текущую ситуацию и подстроиться под нее.
Непрерывная поставка требует большей гибкости разработки и архитектуры ПО. Когда подразделение разработки только начало использовать ПО как услугу (SaaS), сотрудники перевели его в общее вычислительное пространство под названием «облако» и скрестили пальцы. Это не сработало. Когда одна часть продукта дает сбои, за ней летит и весь продукт. Сотрудники подразделения понимали, что каждая часть сетевого ресурса при сбое не должна влиять на другие части и тем самым на весь продукт. Это привело к большим архитектурным изменениям в продукте.
Когда подразделение только приступило к работе, каждая команда работала в своей ветке кода в течение трехнедельного спринта. В конце спринта полученные результаты объединяли, и возникал хаос. Фактически команды создавали слишком большой интеграционный долг. Эта модель оказалась нежизнеспособной. Для завершения каждого спринта команды должны были осуществить фундаментальные изменения.
В целом все работали в одной и той же ветке. Это означает, что каждая команда проводила свои изменения в программе под названием Git. Но нельзя работать автономно в течение трех недель в надежде объединить результаты позже — необходимо ежедневное сотрудничество. Допустив нарушения в текущем варианте программы, команда должна моментально его исправлять. Чем дольше команде приходится ждать объединения кода, тем выше риск технической и интеграционной задолженности — и катастрофы.
Команды используют так называемые функциональные флажки. При новой разработке они первым делом изолируют код, который необходимо менять, и делают переключатель к нему. В базе данных он отмечается флажком, что означает изменение конфигурации. Команда пишет новый код за пределами версии, зафиксированной флажком. Предполагая, что работа завершена, она переключает код только для себя. Этот переключатель не глобальный. Он служит своего рода демонстрацией в системе и действует только «для своих». Если все идет хорошо, команда активирует его для конкретных пользователей, чтобы его протестировали и таким образом помогли выявить баги и проблемы. По окончательном завершении задания команда готовит анонс выпуска и объявляет о переходе на новую версию для всех пользователей. Затем она рефакторит прежний код, чтобы коллеги могли продолжать работать над ним, не мешая друг другу.
В конце каждого спринта команда рассылает электронные письма всем 500 сотрудникам группы Visual Studio Team Services и руководству. В них сообщается о том, что она выполнила за этот спринт и что планирует выполнить в течение следующего спринта. Члены команды записывают видео на три-пять минут, которое заменяет присутствие на демо.
«Раньше, — рассказывает Бьйорк, — написав код, команда устраивала вечеринку и отмечала успех — как потом выяснялось, преждевременный: в реальности они тонули в багах, которые после праздника приходилось искать и исправлять. Таким образом, до поставки ПО команду по-прежнему отделяли многие месяцы. Это был кошмар».
«Сегодня предельное количество багов установлено официально, — продолжает Бьйорк. — Это ограничение рассчитывается как количество разработчиков в команде, умноженное на четыре. То есть у 10 разработчиков ограничение составляет 40. Достигнув лимита, команда прекращает работать над новыми функциями и следующим спринтом и занимается устранением багов. Таким образом мы можем поставлять продукт бесперебойно».
При методе DevOps разработка и эксплуатация объединяются. Команды занимаются планированием, выполнением, поставкой и рабочими процессами для каждой новой функции.
«Если сервис перестает работать, — объясняет Бьйорк, — команда должна сделать остановку и решить проблему. Многие привыкли, что этим занимается отдельная служба поддержки. Но кому приятно тратить свое время на исправление чужих ошибок? Сквозная ответственность за качество улучшает результат. Команды управляют жизненным циклом каждой функции. Если сервис часто выходит из строя, значит, возникла проблема с качеством кода. Необходимость остановки мотивирует людей писать отличный код. Между тем винить в проблемах некого: команды сами являются владельцами созданных функций. Сотрудники поэтапно выполняют работу и решают проблемы по мере их появления».
«Постановка новых сроков кардинально изменила ситуацию. Теперь работу нужно выполнять за три недели, — продолжает Бьйорк. — Три недели — это нормально. Раньше у сотрудников было лишь две возможности. Тем, кто их упускал, приходилось ждать два года. Теперь все происходит иначе. Если инкремент недостаточного качества, то вы его не выпускаете. Команда разочаровывается и обсуждает проблемы на ретроспективе. Сделала ли она что-то неправильно? Или недостаточно оценила уровень сложности? Или что-то упустила? Лучше провести конструктивный разговор, чем устраивать тревогу, наказывать команду за то, что она не выполнила обещанное или, что еще хуже, выпустила некачественный продукт. Раньше на виновника багов указывали пальцем. Теперь команда сама обнаруживает их, исправляет и забывает о них. Срок корректировки багов сократился».
Два года назад группа рассматривала возможность ежедневной поставки кода, но оказалось, что пользователи в этом не нуждались. Однако команды не теряют времени даром и учатся работать над более мелкими блоками.
Команды постоянно отслеживают, как функции используются в данный момент. Результаты отражаются в бэклогах, которые называются сценариями. Каждый месяц программный менеджер готовит отчет, оценивая различные метрики и аспекты сервиса. Группа учится использовать данные отчета, но не ставит их во главу угла, а ориентируется на общую картину, задействуя мозги и интуицию сотрудников. Однако это не означает, что данные отходят на второй план — они зачастую являются предметом обсуждения.
Само определение «готовности» подразумевает корректные данные измерений. Команды отслеживают их как при тестировании, так и после релиза. Это один из критериев приемки при поставке кода.
Сразу после поставки команда интересуется использованием функциональности. Затягивает ли она посетителей в нашу воронку конверсии? Переходят ли они в разряд постоянных клиентов или остаются обычными пользователями? Полученные данные помогают компании в дальнейшем развитии.
Программные менеджеры изучают своих пользователей всевозможными способами. На самом высоком уровне, в исполнительном брифинг-центре в Microsoft, где разрабатывается стратегия, проводятся так называемые советы потребителей. Кроме того, менеджеры группы проектов постоянно общаются с последними в Twitter.
Однако они не торопятся слепо следовать просьбам клиентов. Они исповедуют принцип, который Бьйорк называет принципом печенья: «Если у вас есть тарелка с печеньем и вы предложите его людям, никто не откажется. Если вы спросите у клиента, хочет ли он новую функцию, он, разумеется, ответит утвердительно. С какой стати ему поступать иначе? Это дилемма для любого новатора. Вы можете изготовить огромное количество хороших продуктов. Но вам необходимо фильтровать пожелания клиентов, а не удовлетворять их без разбору. Наша задача — создавать то, в чем люди действительно нуждаются, и то, что компания может гарантированно продать».
Никто из руководства ни разу не предлагал Бьйорку отказаться от Agile-управления. Одна из причин — огромный успех, который сопутствует Agile-командам.
«Конечно, мы следим за их деятельностью и, если есть необходимость, перераспределяем нагрузку, — признается Бьйорк. — Если команда отстает, мы не разбиваем ее, чтобы устранить проблему, а просим самих членов команды принять решение. Мы стараемся сохранять состав команды в течение 12–18 месяцев. Наша цель — дать людям возможность преуспеть в совместной разработке ПО. Если менять состав команд или задачи каждые три спринта, им будет сложно добиться хороших результатов. Компания вкладывается в команду как минимум на девять месяцев или год».
Менеджеры позволяют сотрудникам периодически выбирать команду для работы. Примерно две трети предпочитают оставаться на нынешнем месте, поэтому новые команды возникают редко (скорее для работников важна сама возможность выбора). В результате компания делает серьезные инвестиции в постоянные команды, которые повышают и их благосостояние, и эффективность.
Команда владеет бэклогом своих задач. «Разумеется, — говорит Бьйорк, — мы часто обсуждаем приоритеты. Но менеджер не указывает команде, что следует делать. В свою очередь, команда тоже не диктует свои правила менеджеру. Они находятся в постоянном диалоге: “Эй, нужно ли нам делать это? Как ты думаешь, мы уже достаточно вложили сюда? Должны ли мы пересмотреть все здесь?”. Будучи программным менеджером, я точно так же общаюсь со своей командой. Такое общение требует огромного взаимного доверия. Как менеджер вы не можете заниматься всем и знать все. Происходит обмен мнениями».
В сфере разработки ПО жизненный цикл продукта сокращается. «В традиционном бухгалтерском учете, — говорит Бьйорк, — продукт является производственным активом. На практике же активом все чаще и чаще является команда, способная поставлять программные продукты. Раньше команда создавала ценность дольше, чем компания. Теперь приоритеты изменились».
«Microsoft обладает преимуществом. Она создала команды задолго до того, как приняла Agile, — продолжает он. — В ней уже действовала устойчивая командная культура. Организациям гораздо сложнее стать гибкими, если они никогда не создавали команд».
Microsoft инвестирует в своих сотрудников — в противоположность компаниям, которые считают своих работников «сменным ресурсом».
В процессе Agile-трансформации сотрудникам Microsoft приходилось многому учиться. «В самом начале, — рассказывает Бьйорк, — мы решили проводить трехнедельные спринты. Руководство одобрило идею Agile, но беспокоилось о том, будет ли все работать. В итоге было запланировано после пяти спринтов провести “стабилизирующий спринт”. Узнав об этом, некоторые махнули рукой: “Нет причин волноваться о багах, потому что у нас будет стабилизирующий спринт!”. В результате появилось так много багов, что командам пришлось помогать друг другу исправлять их».
«На самом деле, — продолжает Бьйорк, — мы призывали людей делать одно, но создали среду, которая побуждала некоторых делать противоположное. Их нельзя было винить в этом. После истории со “стабилизирующим спринтом” сотрудники просили нас: “Никогда так больше не делайте!”. Это было примером непреднамеренных последствий».
Главная цель — избежать нежелательной последовательности: писать код в течение первого спринта, тестировать — в течение второго, исправлять баги — в течение третьего. «Дорожные правила» предписывают: поставлять готовый продукт после каждого спринта.
Такова концепция автономности. Если команды не контролируют качество собственной работы, не стоит удивляться негативным последствиям — например, авралам по выходным. Команды сами планируют свой график и могут не подчиняться процессам, которые не в силах контролировать.
В самом начале компания проводила коучинг и базовое обучение Scrum. Но вскоре группа просто начала учиться самостоятельно. В процессе работы люди выявляли наиболее эффективные практики и применяли их чаще, отказываясь от неэффективных. В итоге некоторые сотрудники и менеджеры Microsoft фактически сами стали аgile- или scrum-коучами. Но в целом группа просто поставила перед собой цель и с энтузиазмом взялась за дело.
Позже выяснилось, что многие новички не проходили базового обучения, поэтому было решено проводить его. К этому моменту стало понятно, что стандартной образовательной программы нет и то, что работает в других компаниях, может не подойти культуре Microsoft.
Изначально высшее руководство Microsoft с опаской относилось к Аgile. Но вскоре его отношение изменилось. «Теперь топ-менеджмент признает Agile современным способом разработки ПО, — радуется Бьйорк. — На уровне команды внедрять его несложно. Вы берете десять человек, проводите обучение и приступаете к делу. Но как синхронизировать деятельность четырех тысяч сотрудников? Это вопрос».
Непростую задачу удалось реализовать при поддержке корпоративного вице-президента Брайана Харри. Преимущество Бьйорка заключалась в том, что до перехода на нынешнюю должность он трудился в подразделении разработки, в котором практики Scrum и Agile закрепились с давних времен. «Наши клиенты писали нам свои пользовательские истории еще до того, как мы узнали, что это такое, — говорит Бьйорк. — Мы уже семь лет как применяем Agile. Компания не осуществляла все перемены одномоментно. Дольше всего менялось физическое пространство. Если бы все команды сразу собрались вместе, объединили бы свои направления и попытались работать в трехнедельных спринтах, ничего бы не получилось. Agile нужно развивать. Вы не можете внедрить его за один день».
Одно дело — Agile-трансформация существующего бизнеса. И совсем другое — создание абсолютно нового бизнеса, который формирует абсолютно новые рынки. Мы вернемся к этому вопросу в .
На своих мастер-классах я часто спрашиваю у присутствующих: «Сколько уровней может иметь организация, оставаясь при этом гибкой?». Я слышу разные ответы: обычно от двух до семи. Конечно, это каверзный вопрос. Правильный ответ — сколько угодно. Все дело в мышлении.
Например, подразделение разработки Microsoft включает в себя гораздо большее количество уровней. Однако оно не является бюрократической пирамидой. Сотрудники общаются между собой по всем вопросам. Обсуждения имеют самую разную направленность. Правильное мышление создает особую атмосферу любознательности и делает людей мобильными.
К слову сказать, крошечная одноуровневая организация может запутаться в бюрократических хитросплетениях, несмотря на свою одноуровневость, если решения в ней основаны на власти, а не на компетенции и повсюду установлены ограничения.
Джулия Вулф, аналитик Национального бюро экономических исследований, пишет:
На протяжении десятилетий консультанты по вопросам управления и популярная деловая пресса призывали крупные фирмы упрощать свою иерархию. Упрощение обычно означает сокращение уровней и расширение сферы контроля менеджеров. Принято считать, что готовность отправить решения вниз ускоряет ответную реакцию потребителя и рынка, усиливает ответственность сотрудников и укрепляет их моральный дух. Действительно ли именно упрощение позволяет спустить решения вниз?
Вулф утверждает, что нет.
В своем исследовании она использовала масштабную панель данных о контактах, служебных обязанностях и формах вознаграждения. Выборка включала в себя более 300 крупных американских компаний примерно за 15 лет. Этот анализ ретроспективных данных дополнял исследовательские интервью с руководителями (то, что CEO говорят) и анализ данных по использованию ими рабочего времени (то, что CEO делают). Вулф приводит доказательства, что в компаниях, упростивших структуру, остается больше контроля наверху и решения также принимаются наверху. «Упрощение может дать абсолютно обратные эффекты, несмотря на обещания, — пишет она. — В целом упрощение наверху является комплексным феноменом, который в конечном счете больше похож на централизацию».
Как правило, говоря об упрощении иерархии, менеджеры продолжают мыслить иерархическими категориями. Им предстоит вырваться из пут прекоперниканского мышления — в противном случае не поможет никакое изменение количества уровней. Кроме того, необходимо признать значимость взаимодействия на основе компетенции (Закон сети) и внутреннего стремления радовать клиентов (Закон потребителя).
J. Wulf. The Flattened Firm // Harvard Business School. Working Paper 12–087. April 9, 2012, .
Войти с помощью соц. сетей: