Текст книги "Менеджмент цифрового мира"

Место Agile-команд в компании

Сейчас мы поговорим о месте Agile-команд в большой компании. Вполне возможно, когда вся компания состоит из agile-команд. Но если речь идет о большой компании, которая сейчас работает, применяя другие управленческие подходы, то трансформацию стоит проводить постепенно. И, более того, далеко не всегда всю компанию стоит перестраивать. Есть смысл оценивать сравнительную эффективность разных методов, основываясь на характере деятельности и доступном персонале. А можно руководствоваться классическим «солнце всходит и заходит, ничего не надо трогать», в большинстве компаний можно найти хорошо работающие подразделения.

Хотя ранее я писал о Scrum, в этой речь пойдет об Agile-командах, применяющих различные методы. Они все достаточно похожи и имеют общие принципы работы, заложенные в Agile-манифесте – итерационную поставку ценности, сотрудничество с заказчиком и другими стейкхолдерами, самоорганизацию вместо прямого управления, доску или другие артефакты, обеспечивающие прозрачность работы для команды и стейкхолдеров и еще много общего. Все масштабируемые Agile-фреймворки рассматривают команды как единицу организации. В том числе и Kanban, который отличается тем, что целевой образ практики не зафиксирован в методе, а прорастает в ходе эволюционного развития. Кстати, Kanban умеет не только организовывать работу команды, но и оркестровать работу многих команд, которые применяют различные методы организации работ, включая классические. Впрочем, его я еще буду рассматривать в будущих статьях, как и другие фреймворки, а пока поговорим про место Agile-команды.

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

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

– Если в индустрии известны способы, которым можно достичь успеха в новом деле, но у вас нет компетентных в нем сотрудников – попробуйте их найти.

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

Отмечу, что бывает еще один случай, когда дело для компании новое и людей с доказанной компетентностью нет, однако есть признанный руководством лидер или команда, которым «любое дело по плечу», и работу доверяют им. На самом деле, это сводится к первому варианту: за людьми признана компетенция «успешно делать ранее неизвестную работу, разбираясь в ней в темпе проекта». Такие люди реально встречаются, хотя и редко. Если надо сделать что-то новое, и у вас нет компетентных сотрудников, и вы не можете их найти – используйте Agile. Или откажитесь от дела.

Если с компетентностью собственных сотрудников более-менее понятно, то со вторым способом могут быть проблемы. Компания решила начать новую деятельность или сделать проект – как узнать, есть ли в индустрии способы ее успешной организации? Помимо поиска информации об аналогичных проектов есть обобщенный способ получения ответа на этот вопрос – Кеневин-фреймворк (Cynefin framework) из теории сложности.

Он говорит о том, что устройство мира можно разделить на четыре области.

– Простая (simple), в которой есть понятные связи и законы.

– Сложная (complicated), в которой причины и следствия могут быть выявлены исследованием и поняты могучим разумом.

– Запутанная (complex), в которой объектов и связей настолько много, что хотя по-отдельности они понятны, поведение системы в целом пониманию не поддается.

– Хаотическая (chaos), в которой поведение системы не предсказуемо.

Отмечу, что извилистые границы областей на схеме – не вольность художника, а отражение замысла автора концепции, Дейва Сноудена, который таким образом подчеркивал нечеткость границ.

Одна из проблем, которую фиксирует эта схема – это ошибочное отнесение запутанной системы к сложной области. Люди видят устройство основных объектов и основные связи, и полагают, что они знают устройство системы и могут предсказать ее поведение. При этом они пренебрегают многочисленными дополнительными объектами и связями, полагая их неважными – и ошибаются в предсказании. Они делают исследования, узнают еще кусочек, и снова надеются, что теперь все знают, но опять ошибаются. Это – типичная ошибка эксперта, особенно начинающего, на котором еще сказывается эффект Даннинга – Крюгера. Аналогично, начинающий специалист, разобравшийся в правила простой области, может вообще не видеть ограниченность своих моделей, полагая применимыми их к любой ситуации. Для каждой области есть свой оптимальный образ действий.

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

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

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

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

Замечу, что этот список примерно соответствует трем классам проектов Дэвида Майстера: Мозги, Седина и Процедуры.

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

– Седина – в этих проектах результат не гарантирован, но может быть достигнут за счет опыта. Это сложная область.

– А Мозги – это принципиально новый проект, в котором опоры на опыт недостаточно для успеха. Здесь мы говорим о действиях в запутанной области.

Так же развитие науки и инженерии неуклонно превращает хаотические области в запутанные, проявляя в них отдельные фрагменты, затем – в сложные, понимая систему в целом, и затем из сложных делает простые, убирая всю сложность в базовые решения. Примером может служить самолетостроение, путь от первых экспериментов с самолетами, которые постепенно перевели область от хаотической к запутанной, к современному уверенному проектированию самолетов с заданными характеристиками, которое относится к сложной области. Впрочем, сложной оно является только при наличии компетенций, и то, что ведущие страны (Россия, Штаты, Европа) делают уверенно в своем военном и гражданском самолетостроении, для Китая и других развивающихся стран является в лучшем случае экспериментальной работой в запутанной области. При этом, как хорошо известно, распределение компетенций в военном и гражданском самолетостроении различно. Классификация по сложности зависит от компетентности специалистов: простое для одних является сложным для других и запутанным для третьих.

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

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

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

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

Современный мир характеризуется все большей динамикой развития, которая ведет к изменчивости внешнего окружения компании в VUCA-мире, и к обесценивают компетенций из-за быстрого развития технологий. В результате простые и сложные области превращаются запутанные, и область применения Agile-методов неуклонно увеличивается. При этом, из-за ошибок классификации, эффекта Даннинга– Крюгера и сильной недооценки динамики изменений, очень распространенной является ложная уверенность в том, что регулярный менеджмент может решить проблемы возросшей сложности, стоит лишь несколько напрячь мозг или позвать «настоящих специалистов». Это касается как топов и владельцев бизнеса, так и консультантов.

Основываясь на этом, можно сформулировать следующие условия, при которых стоит применять Agile-методы в операционной деятельности:

– Если область запутана и регулярные процессы все время дают сбои

– Если в области высокая динамика, и требуется частое изменение процессов

– Если в потоке запросов много особых клиентов, которых не хочется терять

– Если не ясны факторы успеха продуктов, надо пробовать и экспериментировать

– Если квалифицированный персонал – дефицитен, недоступен или дорог

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

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

– Сначала команду учим поставлять каждую итерацию что-нибудь.

– Потом учим делать нужное – поставлять ценность.

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

– Потом учим самоорганизации – умение оценивать свои процессы и улучшать их.

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

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

Создание команд и перестройка цепочек создания ценности в Agile-трансформации

Ранее я рассматривал вопрос о том, в каких областях разумно применять Agile-методы в зависимости от характера деятельности. Сейчас я буду говорить о том, как перестраивается производство компании при организации Agile-команд. Многие слышали и знают, что Agile-команда является кроссфункциональной, то есть в ней собираются специалисты, ранее работавшие в разных функциональных отделах. А значит и производственные процессы, характер цепочек создания ценности принципиально изменяются: работа, которая раньше передавалась из отдела в отдел, теперь собирается в команде. Именно с этого мы начнем рассмотрение.

Вообще такое преобразование кажется неверным с точки зрения регулярного менеджмента. Ведь, начиная от Адама Смита «все знают», что повышение производительности достигается за счет разделения труда. В книге «О богатстве народов» он приводит знаменитый пример с изготовлением булавок: разделение изготовление на 18 операций, каждую из которых делают отдельно, приводит к тому, что 10 рабочих изготавливают в день 48 тысяч булавок, в то время как при индивидуальном изготовлении рабочий их делал не более 20 в день: увеличение производительности труда в 240 раз. В эту сторону идет и конвейер Форда, который принципиально повысил скорость изготовления автомобилей – до одного в минуту.

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

Собственно, когда в IT возникла необходимость массовой разработки с появлением персоналок, вызывавшем взрывной рост потребности в программах автоматизации для множества конкретных фирм, то попробовали пойти по такому же пути. Конечно, в отличие от булавок или автомобилей программы – изделия индивидуальные, однако для этого были наработаны методики индивидуализированного производства, применявшиеся, например, в строительстве зданий или других аналогичных отраслях. Конструкторы-проектировщики разрабатывали технический проект, который потом отдавали в производство и получали готовое изделие с более-менее гарантированными стоимостью, сроками и качеством. Аналогичную конструкцию попробовали сделать в IT, и так появился Rational Unify Process (RUP). Не получилось. Для этого есть системные причины, подробнее я рассказывал о них в главе «Развитие и провал регулярного менеджмента в IT» и не буду повторяться.

А здесь хочу отметить, что автоматизация бизнеса имеет еще одну важную особенность: окружение, в котором работает система, динамично изменяется во времени. Конечно, при строительстве индивидуальных домов или ремонте квартир это тоже имеет место: у заказчика могут непрерывно возникать новые пожелания, но если они касаются уже построенного, то ему можно предложить голосовать деньгами. Однако, есть опасность что при бесконечных переделках дом никогда не будет закончен, такие примеры известны. В IT задача успеть за изменениями бизнеса при его автоматизации гораздо более актуальна, речь идет не о произвольных желаниях, а о следовании за изменениями процессов, которые компании продиктовал рынок.

Как и в случае строительства (или ремонта квартиры), выход в том, чтобы собрать всех необходимых специалистов в одну команду, чтобы они вместе преодолевали трудности. И лучше, если каждый из этих специалистов могу выполнять несколько функций, а не одну, чтобы они могли поддерживать и помогать друг другу во время работы. Так вместо функциональных отделов появляется кроссфункциональная команда. Это – первое из тех изменений, которые принес Scrum.

Кроссфункциональные команды вместо функциональных отделов изменяют и сам характер производства. Рассмотрим это подробнее. Для этого нам понадобиться обобщенная структура компании. Я буду работать на той схеме, которую Генри Минцберг дает в своей книге «Структура в кулаке» (Structure in Fives). Он выделяет пять частей организации:

– Стратегический апекс разрабатывает стратегию и осуществляет общее руководство

– Техноструктура разрабатывает и налаживает бизнес-процессы, именно там сидят те бизнес-технологи, о которых шла речь выше.

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

– Операционное ядро выполняет основной бизнес-процесс, разложенный на операции, обеспечивая цепочку создания ценности.

– Вспомогательный персонал представляет собой инфраструктуру, поддерживающую работу компании.

В целом это изображено на схеме. При этом условиями является грамотное построение процессов и обеспеченность компетентным персоналом.

В цифровом мире такая организация работы становится невозможной, это изображено на следующей схеме. Регулярная часть процессов переходит в IT-системы, а персонал занимается только особыми случаями. Ранее их рассматривали лишь опытные сотрудники, которые учились это делать, постепенно набирая опыт, а теперь они сразу должны работать исключительно с такими случаями. Техноструктура не успевает перенастраивать бизнес-процессы в темпе развития технологий и изменения условий работы компании в VUCA-мире. А менеджмент среднего звена при отсутствии стабильных процессов должен совмещать менеджерские и профессиональные предметные компетенции, реорганизуя производство «на лету». Конечно, такие люди есть, но они – дефицитны, и невозможно сделать такими всех менеджеров.

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

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

Как я отмечал раньше, типичной является ситуация, когда команды недостаточно обеспечены компетентным персоналом. В IT это случалось неоднократно в связи с бурным развитием технологий, и эти периоды, думаю, помнят не только не только IT-шники. Сначала, в 90-е, всем была нужна автоматизация процессов. Сначала интернет стал доступнее и всем компаниям потребовались сайты. Потом интернет стал быстрее, и множеству компаний потребовались не просто сайты, а интерактивные интернет-магазины. Потом волна, когда всем нужны мобильные приложения. И на этом процесс не закончится – уже сейчас идет волна чат-ботов, которые будут становиться все умнее, вплоть до полноценного искусственного интеллекта. Поэтому в IT наработаны схемы организации работы в условиях некомпетентных команд. При этом выделяются позиции технических наставников из числа людей, у которых получилось быстро освоить новые технологии, они обучают новичков и проводят аудит технических решений. Это изображено на следующей схеме. Наставники организуются в сообщества для обмена опытом. В ряде фреймворков масштабирования Agile на компанию, например, в Spotify, одним из элементов организации являются профессиональные гильдии, объединяющие людей одной специализации из разных команд для решения профессиональных задач.

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