Джош Берсин – Непревзойденные. Семь принципов менеджмента, которые выведут компанию на запредельно высокий уровень (страница 4)
ТАБЛИЦА 1.1: ТИПИЧНЫЕ ВИДЫ КОМАНД
Источник
Акцент Unilever на гибкости команд стал ключевым фактором изменений в бизнесе компании, особенно при удовлетворении возросшего спроса на гигиенические товары в начале пандемии COVID-19. «Анализируя ситуацию в Китае в конце 2019 года, мы смогли перенаправить около 30 % нашего производства на выпуск средств для умывания и ухода за руками уже в марте 2020-го, всего за три недели», – сказал Йерун Вельс, исполнительный вице-президент Unilever по кадрам14.
Чтобы справиться с вызовами, сотрудники Unilever, которые ранее работали с клиентами вроде ресторанов и отелей, временно закрытых из-за пандемии, были переориентированы на рынки с устойчивым спросом. К концу апреля 2020 года более 9000 сотрудников сменили свои обязанности, сосредоточившись на обслуживании сегментов с высокими темпами роста.
«Переход от продаж продуктов питания к реализации средств гигиены в итоге показал нашу способность адаптироваться, – подчеркнул Вельс. – Благодаря командному подходу мы смогли оперативно перераспределять ресурсы между закрывающимися предприятиями и теми, где спрос резко вырос».
Основополагающими принципами успешных команд являются их инклюзивность и многофункциональный характер.
Каждая команда нуждается в лидере, дизайнерах, разработчиках, операторах и других специалистах. Хотя задачи этих групп различны, общая структура остается неизменной: лидер координирует процесс, а не управляет им, сотрудники распределяются по командам в зависимости от своих компетенций, имеют право самостоятельно принимать решения и действовать, а также ориентируются на четко сформулированные цели, определяющие дальнейшие шаги.
Такая структура логична в теории, но что происходит на практике? Работники нередко участвуют сразу в нескольких проектах. Лори Голер, глава HR-отдела в в крупной организации, отметила, что люди бывают часто задействованы в различных командах параллельно. По ее словам, «все действительно зависит от человека, и, конечно, они обсуждают это со своим менеджером»15. Культура компании позволяет командам формироваться быстро и легко.
Создание культуры, позволяющей сотрудникам свободно выбирать проекты, приносит впечатляющие результаты. Барри Мерфи, директор по обучению в Airbnb, уверен, что успешность организации зависит от грамотно выстроенной структуры: «Нужно создать систему, поддерживающую людей, а не ограничивающую их»16. А по мнению Дона Прайса, футуриста из Atlassian, цель заключается в том, чтобы «обеспечить условия, в которых сотрудники смогут ежедневно выполнять самую значимую работу в жизни»17.
ЗНАМЕНИТАЯ ИСТОРИЯ: СОКРАЩЕНИЕ ИЕРАРХИИ В IBM
В 1980-е IBM занимала лидирующие позиции в технологической отрасли. Компания производила чипы, системы, ПО для операционных систем, приложения и сетевые устройства. Фактически, IBM представляла собой целую IT-экосистему, предлагая клиентам все необходимое для функционирования центров обработки данных. Организация имела строгую иерархию, построенную вокруг продуктовых подразделений, и обладала разветвленной сетью продавцов и технических экспертов. В тот период IBM была основным поставщиком решений для большинства IT-компаний, что делало ее крайне иерархичной.
Конечно, всем известно, что случилось дальше. В 1970–1980-х годах компьютеры стали массовым товаром, и такие компании, как Intel, Microsoft, а затем Dell и Compaq, создали машины, которые оказались столь же мощными и функциональными, как и продукция IBM. Прибыли корпорации от продажи фирменных систем стремительно сократились, однако руководство продолжало игнорировать эти изменения.
Иерархия IBM стала препятствием для адаптации. Знаю по собственному опыту, ведь я начал работать там в отделе продаж в 1982 году. Спустя несколько лет занимался продажей компьютеров IBM Калифорнийскому университету в Беркли и часто бывал в отделе компьютерных наук, общаясь с создателями Unix, Sendmail и множества других технологий. Однако мои собеседники предпочитали закупать оборудование у таких компаний, как Sun, Apollo, Silicon Graphics и Digital Equipment.
Я был в ярости от того, что мой любимый работодатель IBM с таким трудом справлялся с изменениями. Эта компания была ориентирована на масштабируемость и эффективность, а не на скорость обучения. IBM обучалась слишком медленно. Несмотря на трудности 1980-х и начала 1990-х годов, она оставалась весьма компетентной. Более того, я убежден, что IBM фактически открыла секреты эффективной командной работы еще до появления гибкой методологии разработки ПО.
В 1970-х годах, как описывает Фред Брукс, руководитель IBM18, в книге «Мифический человеко-месяц» (1975), в IBM существовали крупные команды разработчиков, которые занимались созданием операционных систем, баз данных и сетевых платформ для мейнфреймов, использовавшихся банками, страховыми компаниями и другими крупными организациями. Многие из них трудились в лаборатории Санта-Тереза в Сан-Хосе, штат Калифорния, напоминавшей современный технологический кампус. Команды разработчиков тесно сотрудничали с командами инженеров по оборудованию, благодаря чему каждое новое поколение мейнфреймов или коммуникационного оборудования сопровождалось готовым программным обеспечением.
Однако команды по программному обеспечению были довольно большими, а продукты – монолитными. Новые версии продуктов выходили каждые 18–36 месяцев. Как подробно описано в книге, Брукс заметил, что по мере увеличения сложности проектов сроки их завершения растягивались. Тщательно изучив деятельность организации, он пришел к выводу, что добавление новых членов в команду не ускоряет процесс, а, наоборот, замедляет.
Концепция промышленного масштаба оказалась неэффективной. По словам Брукса, одним из самых больших препятствий, с которыми сталкивались команды, была необходимость людей общаться друг с другом. Если двум инженерам требовалось обсудить задачу, расширение штата лишь тормозило проект, вплоть до полной остановки.
Брукс считал, что оптимальная команда должна состоять из одного инженера, его напарника, специалиста по документации, администратора, тестировщика и разработчика инструментов, повышающих продуктивность сотрудников. Такая структура позволяет каждому члену команды работать по специализации и одновременно вносить вклад в общий успех.
Исследования Брукса, проведенные 45 лет назад, и внедрение его идей заложили основу современного подхода к командной работе. С тех пор технологическая отрасль продолжает совершенствовать наши представления об оптимальной структуре организации, особенно когда речь идет о скорости, а не о масштабе.
Инновация. Основы принципа Agile
Следующий значительный этап эволюции произошел в 2001 году, когда команда разработчиков под руководством Джона Керна, аэрокосмического инженера, объединилась для создания Манифеста гибкой разработки программного обеспечения, широко известного как Agile Manifesto19.
Гибкая методология стала настоящей инновацией в мире бизнеса. Первоначально зародившаяся в сфере разработки программного обеспечения, она представляет собой новый подход к работе, который может быть адаптирован практически в любой отрасли.
Команда Керна исходила из понимания, что сложные системы программного обеспечения невозможно предугадать заранее20.
Вместо традиционного каскадного метода, при котором разработка движется строго последовательно, гибкая методология делает упор на быстрое создание моделей программного обеспечения, их тестирование и получение обратной связи в ходе их развития.
Однако принципы Agile выходят далеко за пределы разработки ПО – это скорее набор культурных ценностей, нежели организационной модели.
Посещая команды, работающие по гибким принципам, вы услышите много разговоров о культуре. Ключевыми аспектами являются внимание к индивидуальным способностям, формирование небольших, четко определенных команд, достижение ежедневного прогресса и акцент на дизайне, сотрудничестве и обратной связи. Вся работа направлена на упрощение процессов, исключение ненужных функций и фокусировку на главных задачах.
Чтобы лучше понять, как работают гибкие принципы, я провел время с инженерными лидерами в Pivotal Labs (теперь – часть VMware), одной из первых компаний, предлагающих облачные хостинг-платформы и консалтинговые услуги. Этот опыт подтвердил мою уверенность в том, что команды разработчиков по всему миру обычно включают трех основных участников: бизнес-лидер (продуктовый менеджер или владелец бизнеса), инженер (разработчик ПО) и дизайнер (специалист по интерфейсам и пользовательскому опыту).
Как объяснил Джо Милителло, бывший главный специалист по кадрам в Pivotal: «Мы начинаем с проблемы клиента, быстро разрабатываем решение, создаем прототип и показываем его группе пользователей. Обычно мы обнаруживаем, что 80 % прототипов не подходят, но остальные 20 % работают хорошо, поэтому мы отбрасываем лишнее и сосредоточиваемся на том, что эффективно. После чего повторяем цикл»21.
ПРИНЦИПЫ ГИБКОГО МАНИФЕСТА
1. Удовлетворение клиента за счет быстрого и постоянного предоставления ценного программного обеспечения.
2. Готовность к изменениям требований, даже на поздних этапах разработки.