скачать книгу бесплатно
Отмечу, что извилистые границы областей на схеме – не вольность художника, а отражение замысла автора концепции, Дейва Сноудена (https://en.wikipedia.org/wiki/Dave_Snowden), который таким образом подчеркивал нечеткость границ.
Одна из проблем, которую фиксирует эта схема – это ошибочное отнесение запутанной системы к сложной области. Люди видят устройство основных объектов и основные связи, и полагают, что они знают устройство системы и могут предсказать ее поведение. При этом они пренебрегают многочисленными дополнительными объектами и связями, полагая их неважными – и ошибаются в предсказании. Они делают исследования, узнают еще кусочек, и снова надеются, что теперь все знают, но опять ошибаются. Это – типичная ошибка эксперта, особенно начинающего, на котором еще сказывается эффект Даннинга – Крюгера (https://ru.wikipedia.org/wiki/%D0%AD%D1%84%D1%84%D0%B5%D0%BA%D1%82_%D0%94%D0%B0%D0%BD%D0%BD%D0%B8%D0%BD%D0%B3%D0%B0_%E2%80%94_%D0%9A%D1%80%D1%8E%D0%B3%D0%B5%D1%80%D0%B0). Аналогично, начинающий специалист, разобравшийся в правила простой области, может вообще не видеть ограниченность своих моделей, полагая применимыми их к любой ситуации. Для каждой области есть свой оптимальный образ действий.
– В простой надо написать регламенты и правила и действовать по ним. И эти регламенты не надо создавать с нуля, они обычно уже имеются в культуре человечества, надо лишь найти нужные и адаптировать к вашей ситуации.
– В сложной – найти высококвалифицированных специалистов, которые поймут область и выработают правильный способ действий. И, опять-таки, исследования уже, вероятно, проведены до вас, и стоит найти результаты и опираться на них, и привлекать тех, кто имел с этой областью дело.
– В запутанной надо постоянно проверять гипотезы и накапливать работающие приемы, которые дальше можно повторять, однако следует быть постоянно готовыми к тому, что известное действие даст неожиданный результат.
– В хаотической можно только экспериментировать, и если получилось удачно – то замечательно. «Попробуй – и получится, а если не получится – попробуешь опять», как поется в известной песенке.
Замечу, что этот список примерно соответствует трем классам проектов Дэвида Майстера (https://en.wikipedia.org/wiki/David_Maister): Мозги, Седина и Процедуры.
– Процедуры – то, что компании знакомо, является рутиной и может выполняться с гарантированным результатом. Это соответствует простой области.
– Седина – в этих проектах результат не гарантирован, но может быть достигнут за счет опыта. Это сложная область.
– А Мозги – это принципиально новый проект, в котором опоры на опыт недостаточно для успеха. Здесь мы говорим о действиях в запутанной области.
Так же развитие науки и инженерии неуклонно превращает хаотические области в запутанные, проявляя в них отдельные фрагменты, затем – в сложные, понимая систему в целом, и затем из сложных делает простые, убирая всю сложность в базовые решения. Примером может служить самолетостроение, путь от первых экспериментов с самолетами, которые постепенно перевели область от хаотической к запутанной, к современному уверенному проектированию самолетов с заданными характеристиками, которое относится к сложной области. Впрочем, сложной оно является только при наличии компетенций, и то, что ведущие страны (Россия, Штаты, Европа) делают уверенно в своем военном и гражданском самолетостроении, для Китая и других развивающихся стран является в лучшем случае экспериментальной работой в запутанной области. При этом, как хорошо известно, распределение компетенций в военном и гражданском самолетостроении различно. Классификация по сложности зависит от компетентности специалистов: простое для одних является сложным для других и запутанным для третьих.
Далеко не всегда путь в сложную область является путем уверенного численного моделирования. Это может достигаться за счет активного открытого сотрудничества и накопления практик. Здесь интересен пример дельтапланов: в отличие от самолетов, их нельзя рассчитать на текущем уровне развития моделей, потому что ткань, из которой делают крыло полупроницаема для воздуха, а если сделать ее непроницаемой, то дельтаплан становится неустойчив при резких порывах ветра. Тем не менее, за счет активного обмена опытом дельтапланеристов, накапливающего и распространяющего хорошие решения, дельтапланы сейчас строятся уверенно.
Области использования Agile.
Теперь попробуем указать на конкретные области применения Agile-методов. Как легко увидеть из описания способов работы в разных областях, область регулярного менеджмента – простая и сложная области. Специальные люди – бизнес-технологи делают и совершенствуют регламенты и процедуры, а все остальные по ним действуют. Разница лишь в том, что для простой области процедуры известны, а в сложной надо вести исследования. А область Agile-методов – запутанная и хаотическая области, где надо двигаться с постоянными экспериментами и коррекцией курса.
Всякая социальная система обычно является запутанной. И одна из задач регулярного менеджмента состоит в том, чтобы превратить систему с участием людей в сложную или даже простую. На языке менеджмента это называется «исключить влияние человеческого фактора на результаты работы», и достигается с помощью процедур и регламентов. Это достаточно успешно можно сделать, когда сотрудники компании преимущественно выполняют физический труд, который хорошо поддается нормированию, а продуктом компании является физическое изделие, пусть даже очень сложное, но типовое, например, автомобиль.
Однако, если компания оказывает услуги, то окружением, в котором она работает, является социальная система. Конечно, ее тоже можно нормировать, как, например, поступает ряд туристических компаний, продающих только стандартные туры, но при этом вы ограничиваете свой рынок. Кроме того, часть услуг требуют не физического, а умственного труда, например, медицина или образование. В этих случаях регулярный менеджмент организует работу через нормирование компетенций сотрудников и их проверку через тесты, экзамены и сертификацию. Однако, это возможно лишь в стабильных областях – при динамичном развитии учебные курсы и сертификационные программы не успевают за изменениями, и результаты хорошо знакомы каждому по массовой медицине и массовому образованию.
Современный мир характеризуется все большей динамикой развития, которая ведет к изменчивости внешнего окружения компании в VUCA-мире, и к обесценивают компетенций из-за быстрого развития технологий. В результате простые и сложные области превращаются запутанные, и область применения Agile-методов неуклонно увеличивается. При этом, из-за ошибок классификации, эффекта Даннинга- Крюгера и сильной недооценки динамики изменений, очень распространенной является ложная уверенность в том, что регулярный менеджмент может решить проблемы возросшей сложности, стоит лишь несколько напрячь мозг или позвать «настоящих специалистов». Это касается как топов и владельцев бизнеса, так и консультантов.
Основываясь на этом, можно сформулировать следующие условия, при которых стоит применять Agile-методы в операционной деятельности:
– Если область запутана и регулярные процессы все время дают сбои
– Если в области высокая динамика, и требуется частое изменение процессов
– Если в потоке запросов много особых клиентов, которых не хочется терять
– Если не ясны факторы успеха продуктов, надо пробовать и экспериментировать
– Если квалифицированный персонал – дефицитен, недоступен или дорог
Кроме того, Agile-методы стоит применять в процессах поиска мест потенциальных улучшений и при ведении проектов изменений компании – они работают с организацией как с социальной структурой, и потому относятся к работе в запутанной области. Правда, Agile-коучи, проводя трансформацию не часто начинают с того, что вешают доску для самого процесса трансформации и организуют спринты. Причина обычно не в том, что они не используют Agile-методы для организации своей работы, а в том, что в нее часто вовлечены руководители компании, которые привыкли работать более традиционным образом. Они готовы попробовать трансформировать отдельное подразделение в пилотном режиме, но не готовы сами изменить способы своей работы, во всяком случае сразу. Поэтому Agile-коучи применяют Agile для проекта трансформации, но не афишируют это.
Изменения идут итеративно, при этом есть гейты на которых фиксируется, что в процессе изменений не просто поменяли работу, а что эти изменения начали приносить эффект, то есть была создана ценность изменений. Например, Асхат Уразбаев в одном из выступлений так описывал этапы изменений работы команды.
– Сначала команду учим поставлять каждую итерацию что-нибудь.
– Потом учим делать нужное – поставлять ценность.
– Потому учим быть предсказуемыми – поставлять запланированное на итерацию количество ценности.
– Потом учим самоорганизации – умение оценивать свои процессы и улучшать их.
С каждым этапом связаны определенные поведенческие маркеры – изменения работы членов команды и команды в целом, и каждый из них означает определенное изменение культуры команды. И каждый такт – определенный шаг от привычных ранее методов работы к новым. Поэтому Agile-коуч должен не только хорошо знать Agile-методы и практики, но и иметь навыки изменения поведения и культуры групп людей. Почему-то об этом часто забывают руководители, заказывающие трансформацию. Особенно забавно, что эти люди часто знают о собственных проблемах в изменении поведения, например, никак не могут начать заниматься спортом или ходить на фитнесс, но почему-то уверены, что Agile-коуч сможет в заданное время гарантированно изменить привычки их сотрудников…
Не всегда компетенции по Agile и психологии сочетаются в одном человеке. И тут я хочу привести пример трансформации компании InfoWatch (http://0x1.tv/20131025-22), когда кроме Agile-коуча привлекли профессионального психолога. Он использовал групповой вариант методики «Психология позитивных изменений» – метода, с помощью которого в индивидуальном варианте людей отучают пить и курить и проводят другие изменения поведения. Там разработана система оценки – принял человек новые правила, или еще требуется закрепление. Agile-коуч вел команды по известному ему пути, а психолог оценивал: готова команда к следующему шагу, или нужно закрепление. В результате изменения прошли очень гладко, качественно, и, на удивление, не занял много времени.
Создание команд и перестройка цепочек создания ценности в Agile-трансформации
Ранее я рассматривал вопрос о том, в каких областях разумно применять Agile-методы в зависимости от характера деятельности. Сейчас я буду говорить о том, как перестраивается производство компании при организации Agile-команд. Многие слышали и знают, что Agile-команда является кроссфункциональной, то есть в ней собираются специалисты, ранее работавшие в разных функциональных отделах. А значит и производственные процессы, характер цепочек создания ценности принципиально изменяются: работа, которая раньше передавалась из отдела в отдел, теперь собирается в команде. Именно с этого мы начнем рассмотрение.
Зачем нужна кроссфункциональная команда вместо функциональных отделов?
Вообще такое преобразование кажется неверным с точки зрения регулярного менеджмента. Ведь, начиная от Адама Смита «все знают», что повышение производительности достигается за счет разделения труда. В книге «О богатстве народов (https://www.gumer.info/bibliotek_Buks/Econom/smit/01.php)» он приводит знаменитый пример с изготовлением булавок: разделение изготовление на 18 операций, каждую из которых делают отдельно, приводит к тому, что 10 рабочих изготавливают в день 48 тысяч булавок, в то время как при индивидуальном изготовлении рабочий их делал не более 20 в день: увеличение производительности труда в 240 раз. В эту сторону идет и конвейер Форда, который принципиально повысил скорость изготовления автомобилей – до одного в минуту.
Однако, в этих случаях речь идет о стабильном производстве физического труда. Каждую операцию можно хорошо спроектировать и нормировать время и качество его выполнения: Форд проектировал свой конвейер с учетом физических возможностей человека, чтобы рабочим не нужно было делать шагов, они до всего могли дотянуться руками. Таким образом, организация производства с разделением труда требует специальных людей – бизнес-технологов, которые разложат труд на операции, нормируют их результат, придумают приемы для выполнения и разработают программы для обучения тех, кто будет их выполнять.
Собственно, когда в IT возникла необходимость массовой разработки с появлением персоналок, вызывавшем взрывной рост потребности в программах автоматизации для множества конкретных фирм, то попробовали пойти по такому же пути. Конечно, в отличие от булавок или автомобилей программы – изделия индивидуальные, однако для этого были наработаны методики индивидуализированного производства, применявшиеся, например, в строительстве зданий или других аналогичных отраслях. Конструкторы-проектировщики разрабатывали технический проект, который потом отдавали в производство и получали готовое изделие с более-менее гарантированными стоимостью, сроками и качеством. Аналогичную конструкцию попробовали сделать в IT, и так появился Rational Unify Process (https://en.wikipedia.org/wiki/Rational_Unified_Process) (RUP). Не получилось. Для этого есть системные причины, подробнее я рассказывал о них в главе «Развитие и провал регулярного менеджмента в IT» и не буду повторяться.
А здесь хочу отметить, что автоматизация бизнеса имеет еще одну важную особенность: окружение, в котором работает система, динамично изменяется во времени. Конечно, при строительстве индивидуальных домов или ремонте квартир это тоже имеет место: у заказчика могут непрерывно возникать новые пожелания, но если они касаются уже построенного, то ему можно предложить голосовать деньгами. Однако, есть опасность что при бесконечных переделках дом никогда не будет закончен, такие примеры известны. В IT задача успеть за изменениями бизнеса при его автоматизации гораздо более актуальна, речь идет не о произвольных желаниях, а о следовании за изменениями процессов, которые компании продиктовал рынок.
Как и в случае строительства (или ремонта квартиры), выход в том, чтобы собрать всех необходимых специалистов в одну команду, чтобы они вместе преодолевали трудности. И лучше, если каждый из этих специалистов могу выполнять несколько функций, а не одну, чтобы они могли поддерживать и помогать друг другу во время работы. Так вместо функциональных отделов появляется кроссфункциональная команда. Это – первое из тех изменений, которые принес Scrum.
Цепочки создания ценности.
Кроссфункциональные команды вместо функциональных отделов изменяют и сам характер производства. Рассмотрим это подробнее. Для этого нам понадобиться обобщенная структура компании. Я буду работать на той схеме, которую Генри Минцберг (https://en.wikipedia.org/wiki/Henry_Mintzberg) дает в своей книге «Структура в кулаке» (Structure in Fives). Он выделяет пять частей организации:
– Стратегический апекс разрабатывает стратегию и осуществляет общее руководство
– Техноструктура разрабатывает и налаживает бизнес-процессы, именно там сидят те бизнес-технологи, о которых шла речь выше.
– Срединная линия менеджмента организует работу подчиненных в соответствии с регламентами и процедурами, а также разбирает особые случаи и сбои, вызывающие отклонение от процесса.
– Операционное ядро выполняет основной бизнес-процесс, разложенный на операции, обеспечивая цепочку создания ценности.
– Вспомогательный персонал представляет собой инфраструктуру, поддерживающую работу компании.
В целом это изображено на схеме. При этом условиями является грамотное построение процессов и обеспеченность компетентным персоналом.
Цифровой мир ломает традиционную структуру
В цифровом мире такая организация работы становится невозможной, это изображено на следующей схеме. Регулярная часть процессов переходит в IT-системы, а персонал занимается только особыми случаями. Ранее их рассматривали лишь опытные сотрудники, которые учились это делать, постепенно набирая опыт, а теперь они сразу должны работать исключительно с такими случаями. Техноструктура не успевает перенастраивать бизнес-процессы в темпе развития технологий и изменения условий работы компании в VUCA-мире. А менеджмент среднего звена при отсутствии стабильных процессов должен совмещать менеджерские и профессиональные предметные компетенции, реорганизуя производство «на лету». Конечно, такие люди есть, но они – дефицитны, и невозможно сделать такими всех менеджеров.
Решение – кросс-функциональные команды
Организация кросс-функциональных команда позволяет решить эти проблемы, как показано на очередной схеме. В команду собираются все специалисты, которые необходимы для выпуска конечного продукта, и она работает, короткими итерациями, непрерывно корректируя свой путь, проверяя гипотезы о продукте на соответствие рынку. Позиция менеджера среднего звена разделяется на две: ответственного за конечный продукт с компетенциями предметной области и ответственного за самоорганизацию команды, обладающими компетенциями по работе с людьми.
Что же происходит с техноструктурой? А ее роль изменяется принципиально: вместо организации бизнес-процессов и регламентов они занимаются организацией качественной коммуникации и обучают людей это делать, фасилитируют совещания и обсуждения, и так же прорабатывают средства, обеспечивающие прозрачность происходящего в командах для руководства и синхронизацию движения в целом. Таким образом, работа с процессами уходит из техноструктуры в команды, которые сами организуют свою работу, а вот работа с персоналом, коммуникациями и культурой из обеспечивающей задачи для инфраструктуры превращается в основную задачу техноструктуры.
Как я отмечал раньше, типичной является ситуация, когда команды недостаточно обеспечены компетентным персоналом. В IT это случалось неоднократно в связи с бурным развитием технологий, и эти периоды, думаю, помнят не только не только IT-шники. Сначала, в 90-е, всем была нужна автоматизация процессов. Сначала интернет стал доступнее и всем компаниям потребовались сайты. Потом интернет стал быстрее, и множеству компаний потребовались не просто сайты, а интерактивные интернет-магазины. Потом волна, когда всем нужны мобильные приложения. И на этом процесс не закончится – уже сейчас идет волна чат-ботов, которые будут становиться все умнее, вплоть до полноценного искусственного интеллекта. Поэтому в IT наработаны схемы организации работы в условиях некомпетентных команд. При этом выделяются позиции технических наставников из числа людей, у которых получилось быстро освоить новые технологии, они обучают новичков и проводят аудит технических решений. Это изображено на следующей схеме. Наставники организуются в сообщества для обмена опытом. В ряде фреймворков масштабирования Agile на компанию, например, в Spotify, одним из элементов организации являются профессиональные гильдии, объединяющие людей одной специализации из разных команд для решения профессиональных задач.
Отметим, что так работают многие компании даже в области относительно устоявшихся технологий, нанимая студентов и обучая их в процессе работы. При этом сотрудники быстро растут, способные остаются в компании, если она расширяется, но большинство через небольшое время уходит в другие компании уже сложившимися специалистами, а компания нанимает новых студентов – это заложено в бизнес-модель. А вот для более традиционных компаний, ранее ориентированных на долгую работу сотрудников, такой быстрый рост и связанный с этим уход сотрудников может стать неприятным сюрпризом.
Гибридная схема частичной перестройки.
Как мы видим, основное изменение состоит в том, что длинная цепочка создания ценности заменяется короткой, инкапсулированной в одной команде. Естественно, это не всегда возможно, и, более того, далеко не всегда целесообразно. Возьмем, например, компанию по производству окон. Значительная часть производственного процесса, которая обеспечивает выполнение уже полученного заказа, хорошо организуется методами регулярного менеджмента, и для нее в кардинальной перестройке нет смысла. А вот взаимодействие с клиентами, поиск и предложение новых продуктов как раз могут быть интересным участком перестройки. Такая частичная перестройка изображена на следующей схеме.
Отметим, что на стыке между Agile-командами и регулярным производством возникает культурный разрыв из-за существенно отличающихся способов организации. И в таком гибридном случае необходимо правильным образом обеспечить, чтобы разница культур не приводила к негативу и враждебным взаимоотношениям, ведущим к потерям для компании. Для этого надо понимать ценности, культуру и образ мышления людей в каждом из участков компании, и организовывать коммуникации с учетом этих различий, снимая понятийные барьеры коммуникации. В частности, надо объяснять производству, что изменения в продуктах компании и заказах клиентам связаны не с неорганизованностью менеджеров по продажам и отдела маркетинга, которые «не могут заранее выяснить, чего на самом деле хочет клиент», а с объективной динамикой внешнего мира. И, наоборот, объясняя продавцам и маркетингу, что производству свойственна определенная жесткость и инерционность, и оно не может перестроиться мгновенно не потому, что там «все ленивы, консервативны и не хотят шевелиться». И не только объяснять все это, а практически работать над решением конфликтов и поиском решений в межкультурной коммуникации.
А еще надо обеспечивать прозрачность и управляемость бизнеса, который разворачивается в такой неоднородной структуре. И тут на помощь приходит Kanban, который не только организует работу отдельных команд, но и позволяет оркестровать работу компании. Но об этом мы поговорим в следующей статье.
Проектируем Agile-трансформацию компании
Опираясь на написанное выше, что Agile-трансформация – это не просто организация команд, и изменение их способов работы, это еще и перестройка цепочек создания ценности. А значит существующие цепочки должны быть проанализированы, и должно быть понятно, какой из вариантов перестройки мы выбираем. Иллюстрацией служит следующая схема.
На что опираться в таком решении? Как раз на анализ ситуации компании и ее окружение на рынке и сложность деятельности. При этом надо помнить, что мы работаем с запутанной (по Кеневин, смотри предыдущую главу) социальной системой, поэтому тот образ перестройки компании, который мы получим в результате анализа является не более, чем гипотезой, подлежащей экспериментальной проверке. Гарантированного результата тут получить невозможно. Именно поэтому Kanban вообще предлагает начать стартовать с существующей организации компании, сделать прозрачным поток создания ценности и запустить эволюционный процесс перестройки. Правда, есть опасность, что этот эволюционный процесс увязнет в привычной рутине, и поэтому данный путь сложнее, чем революционная реорганизация.
В любом случае, бывают ситуации, когда переход к кросс-функциональным командам для определенных участков компании является достаточно очевидным решением, исходя из анализа деятельности или просто с учетом сопротивления преобразованиям. В этом случае надо организовать будущие команды. При этом опыт IT однозначно говорит, что их недостаточно организовать логически, просто собрав людей и объявив, что они теперь будут работать одной командой, как иногда делают при организации проектных групп. Надо провести физическую реорганизацию, объединив людей одной команды в единое физическое пространство. Разумеется, сейчас есть техники работы распределенных команд, но, во-первых, они сложнее, а, во-вторых, сохранение привычного окружения надежно останавливает любые новшества. Фраза Питера Друкера, «культура ест стратегию на завтрак» к этой ситуации тоже вполне применима. Должен ли сотрудник работать только в одной команде? Ответ из опыта IT – это крайне желательно. У любой команды должно быть ядро сотрудников, у которых команда является единственным местом работы. Может быть некоторое количество специалистов, занятых частично, и участвующих в 1—2 командах. Но не больше, во всяком случае, сотрудник, разрывающийся между 5—10 проектами – пример вопиющей неэффективности, потому что, как правило, он не помнит ни об одном. Разумеется, бывают исключения, и я сам знаю таких людей, но это – крайне редкие случаи, а обычно такие ситуации возникают потому, что руководители не знают, кем бы сейчас заткнуть дыру в деятельности, и нагружают сотрудников, которые в результате ни с чем не справляются, выгорают и уходят. И в большинстве случаев это все равно иллюзия решения проблемы.
Инфраструктура компании.
Разумеется, есть ситуации, когда команде иногда нужна консультация высококвалифицированного специалиста. Но это не означает, что он должен быть постоянным членом команды. Тут мы подходим к интересному вопросу – кого именно из числа специалистов, необходимых для создания продукта компании следует включать в кросс-функциональную команду, и не окажется ли она при этом слишком большой? Ответ на это в различении основной структуры компании и ее инфраструктуры – вспомогательного персонала на схеме Минцберга, о котором мы почти не говорили. Инфраструктура представляет собой подразделения, которые обеспечивают работу основных подразделений и не являются для них ограничением.
Если юридический департамент согласует любой договор в заданные сроки, например, за один день, а бухгалтерия столь же оперативно готова оформить документы и провести платежи, то это – инфраструктура, и их представителей не надо включать в каждую команду, хотя для них вполне может быть выделен курирующий сотрудник. А вот если команда постоянно прорабатывает новые формы договоров или финансовые схемы оплаты, то среди ее членов юрист и бухгалтер соответственно, иначе в процессе работы могут случиться неприятности.
Заметим, что для того, чтобы обеспечить гарантированный отклик на запросы команд в краткие сроки, инфраструктура должна иметь избыточную мощность, то есть дополнительное количество сотрудников. Потому что запросы имеют обыкновение приходить крайне неравномерно. Одной из типичных ошибок классического менеджмента является сокращение мощности инфраструктуры, основываясь на средней, а не пиковой загрузки сотрудников. В результате в периоды пиковых загрузок встают основные бизнес-процессы. Как легко догадаться, происходит это наиболее ответственные периоды пиковых продаж с соответствующими потерями для компании. Печальные истории подобных сокращений юридического отдела, бухгалтерии или службы ремонта оборудования известны и некоторые даже попали в книги и учебники, но люди предпочитают учиться на своих ошибках, повторяя чужие.
Меняем способ организации команды.
Как легко заметить, выше в статье шла речь о кросс-функциональной команде и не было опоры та то, что команда применяет для организации своей работы один из Agile-методов, а не управляется руководителем традиционным образом. И действительно, просто преобразование к таким командам без отказа от обычного способа управления способно дать существенный эффект, и рассматривается в регулярном менеджменте. Там это называют «переходом к проектным группам» или, в более сложном варианте, «переходом к матричной структуре» в зависимости от того, какая именно деятельность и модели управления рассматриваются.
Однако, принципиальным вопросом для успеха таких преобразования является наличие хороших руководителей. Если у вас в компании их достаточно, или вы умеете их привлекать, то в сохранении традиционного стиля управления нет проблем. Однако, обычно именно руководители группы являются дефицитной позицией. Особенно когда работа группы предполагает вовлечение всех ее участников и достижение синергии коллективного взаимодействия – а именно это нужно при работе с новыми продуктами в режиме неопределенности VUCA-мира или при недостатке компетенций. Для этого руководитель должен работать через делегирование, в коучинговом или менторском режиме, а в стиле раздачи поручений. Конечно, книги по менеджменту и лидерству полны призывов именно к такому способу управления, но какой процент таких руководителей вы видели на практике? Очень мало.
Agile-методы, особенно Scrum, решают эту проблему не за счет личных качеств руководителя, а за счет организации процесса. Кроме того, Scrum делит обязанности традиционного руководителя на три части: ответственный Product Owner за продукт, ответственность Scrum Master за самоорганизацию команды, и ответственность команды в целом. Разделение ответственности, передача ее части команде используется и в других Agile-методах. И потому требования к каждой позиции снижаются, подобрать подходящих людей становится легче. А прозрачность работы команды в Agile-методах позволяет наблюдать за происходящим и корректировать при необходимости, помогая команде преодолевать проблемы.
Отметим, что развитие IT показало, что при сохранении принципиального разделения ответственности за продукт и за организацию, детальное разделение ответственности в разных компаниях отличается очень сильно. Недавно Егор Толстой и Стас Цыганов организовали в IT-сообществе сбор полного MindMap управленческой ответственности команды, результаты опубликованы на GitHub (https://github.com/tlbootcamp/tlroadmap) и доступны. В статье – картинка, а по ссылке можно скачать себе полный mindmap и внести свой вклад в обсуждение. И хотя эта работа сделана на материале IT-отрасли, в ней много общезначимых пунктов и вы можете подумать о применении его в рамках своей отрасли, выполнив адаптацию сами или организовав аналогичное обсуждение в профессиональном сообществе. А потом – подумать о том, как ответственность разделяется в вашей компании: что находится внутри команды и как именно распределено, что передано руководителю следующего уровня, за что отвечает инфраструктура и техноструктура, увидеть упущенные или провисающие фокусы ответственности.
Так же я хочу поговорить о вариантах перехода от традиционной иерархии к организации с разделением ответственности. Пусть у нас есть отдел продаж, и мы хотим в нем перейти на Scrum с тем, чтобы получить эффекты от командной работы и убрать потери от индивидуализма продавцов. Может показаться, что это совершенно бесперспективная задача, чистое теоретический кейс, потому что «всем известно», что продавцы – яркие индивидуалисты, у них к тому же обычно стоит индивидуальный KPI по продажам – какая тут командная работа и сотрудничество? Между тем, эти кейсы – вполне реальны, более двух лет назад я слышал на IT-Spring от Марины Симоновой (Marina Alex (https://www.facebook.com/marina.a.alex)) кейс реорганизации отдела продаж, в котором для пилота выбрали самую отстающую команду. Трансформация была успешной, подробности можно посмотреть в выступлении (https://youtu.be/Hsxiuu1kMz4). Кстати, Марина развивает применение Agile в продажах, сейчас у нее разработан собственный SWAY-фреймворк для Agile в продажах http://agileinsales.org/ (http://agileinsales.org/) (здесь по-русски (https://uba.school/blog/sistema-sway)), признанный на международном уровне. При этом стиль работы подразделений реально изменяется, появляется сотрудничество и взаимопомощь, которая и обеспечивает эффект от преобразования. Правда, необходимо не только изменить процессы управления и работать с культурой и ценностями сотрудников, но и изменить систему мотивации, уходя от индивидуальных KPI.
Так вот, при agile-трансформации большого департамента продаж, состоящего из нескольких отделов, есть два существенно различных варианта, изображенных на схеме. Если у вас в компании стратегией продаж занимается руководитель департамента, который при этом обычно является директором по продажам или занимает аналогичную должность, а руководители отделов лишь организуют работы сотрудников, то директор по продажам становится Product Owner для всех команд, а руководители отделов – скрам-мастерами. А если отделы продаж работали достаточно автономно, например, по сегментам рынка или разным продуктам, и ответственность за выбор направлений по каждому направлению была на руководителях отделов, то именно они могут стать Product Owner, образуя управляющую продажами команду в стиле Scrum of Scrum, а скрам-мастеров при этом надо выбирать внутри команд. Тщательная работа с культурой сотрудников будет нужна в любом случае, впрочем об этом я уже говорил.
Kanban и Lean – эволюция вместо революции
Распространено мнение, что Kanban является сильно упрощенным вариантом «Scrum без спринтов» для ситуации, когда команда должна просто обрабатывать поток задач. Это неверно. Kanban, в отличие от Scrum, вообще не дает какого-либо фиксированного способа организации процесса. Он запускается на основе существующего процесса и набора ролей, визуализирует поток создания ценности, а затем начинает эволюционные изменения для наращивания потока и исключения лишней работы.
Kanban может быть запущен как для одной команды, организуя его работу, с постепенным расширением области применения на смежные команды, так и для компании в целом, соорганизуя и оркеструя работы многих команд. Его естественным развитием является Lean, ориентированный на оптимизацию цепочек создания ценности. Отмечу, что речь тут идет об IT-вариантах Kanban (https://en.wikipedia.org/wiki/Kanban_(development)) и Lean (https://en.wikipedia.org/wiki/Lean_software_development), а не об их производственных вариантах, разработанных в Toyota. Kanban, насколько я представляю его историю, является оригинальной конструкцией, собранной на основе разных источников. Хотя он и получил свое название от использования Kanban-доски, которая является первым шагом метода и применяется для визуализации потока работ. А Lean является переосмыслением и адаптацией исходного производственного варианта для систем умственного труда, описанным Мэри и Томом Поппендик в книге «Бережливая разработка программного обеспечения» (Lean Software Development). Применяются те же механизмы оптимизации потока создания ценности, однако типы лишней работы для задач умственного труда, принципиально отличаются от типов для физического производства. Чтобы убедиться в этом достаточно сравнить лекции специалистов по производственному Lean и Lean в IT. Сейчас можно говорить о том, что объединение Lean и Kanban в IT, по моей оценке, является наиболее интенсивно развивающимся из Agile-методов, и имеет наибольший потенциал применения во всех отраслях, в связи с приходом цифрового мира, вызвавшего интенсивный переходом от физического труда к умственному.
Начну я свой рассказ с того, что порекомендую замечательный доклад про Kanban Алексея Пименова на AgileDays-2019 «Скрытая механика работы Kanban Method (https://youtu.be/DCSPRM4msu4)» (мой конспект в отчете с конференции (http://mtsepkov.org/AgileDays-2019)). Алексей является ведущим специалистом по Kanban на всем постсоветском пространстве, включая, естественно, Россию и имеет высокие уровни сертификации от Kanban University (https://www.kanban.university/) и хорошо представляет себе современное развитие метода. Отмечу, что сертификация продвинутых уровней предполагает не просто прохождение курсов и тренингов с проверкой теоретических знаний, а личный опыт практической работы, который проверяется на сертификационном собеседовании – помимо теории ты рассказываешь экспертам-практикам о своих кейсах. Поэтому такой сертификат служит реальным свидетельством квалификации.
Дэвид Андресон. Kanban – альтернативный путь в Agile.
Как и большинство Agile-методов, Kanban имеет автора, его придумал Дэвид Андресон и его книга «Kanban – альтернативный путь в Agile» является правильным источником для знакомства с методом, подобно книге книга Джефа Сазерленда «Scrum – революционный метод управления проектами» для знакомства со Scrum. Книги-первоисточники хороши тем, что обычно позволяют проникнуть в замысел автора, показывают логику формирования метода, а не готовый результат. А это очень важно для понимания метода.
Надо заметить, что название «альтернативный путь в Agile» есть только в русском переводе, и, говорят, появилось по настоянию издательства для лучших продаж книги. Оригинал называется «Kanban. Successful Evolutionary Change for Your Technology Business». И в сообществе периодически возникает дискуссия о том, является ли Kanban Agile-методом. С моей точки зрения, безусловно, является. Во-первых, исторически: Андерсон его именно так и позиционировал в своих ранних работах и выступлениях на Agile-конференциях, например, «Agile Management for Software Engineering: Applying the Theory of Constraints for Business Results» (2003). Кстати, она явно показывает один из основных источников – теорию ограничений. Во-вторых, по содержанию: если посмотреть на набор практик, описанный в книге Андерсона, то в целом он хорошо соответствует набору практик Scrum, а также принципам Agile. Что не удивительно, потому что они в целом отражают эффективные методы для IT-разработки. А, в третьих, на уровне культуры: хотя Kanban стартует от существующего процесса и не предъявляет требования какой-либо особой Agile-культуры, прозрачность потока создания ценности, ориентация на его улучшения и сотрудничество со смежниками неизбежно ведет к изменению культуры как раз в том направлении, в котором это сформулировано в Agile-манифесте.
Отмечу, что книгу Андерсона можно читать на двух уровнях. Первый уровень, находящийся на поверхности, показывает набор различных практик, которые постепенно появлялись в методе. А второй уровень показывает логику, в которой эти практики появлялись. В книге Андерсона два уровня: первый показывает набор практик, а второй – эволюционную логику их появления.
Второй уровень значительно важнее первого, потому что именно он показывает логику разворачивания эволюционного процесса улучшений, который и составляет суть Kanban. В книге Андерсон показывает тут путь, который прошли его команды. Следуя духу Kanban, ваши команды пройдут свой путь в той же логике, но стартовав от других начальных условий, и прийдя, естественно, к другому набору используемых практик, потому что этот набор будет зависеть от специфики и условий вашего проекта. И, вероятно, это будут вовсе не простой набор практик, скорее всего, схема процесса будет сложнее, чем фреймворк Scrum, зато она будет отражать вашу специфику. Во всяком случае, то, что получилось у Андерсона и описано в книге – сложнее, поэтому ее и не рисуют.
Доска и проектирование Kanban-системы
Итак, каким образом работает Kanban? Как уже говорили, все начинается с анализа и визуализации на доске существующего потока работ. Об использовании досок в Agile я писал в главе «Доска – визуализация текущего состояния работы», где как раз достаточно подробно раскрывал их работу на примере Kanban. Я не буду повторяться, однако помещу тут картинку из той статьи с описанием основных элементов и приемов, просто чтобы напомнить. Основным результатом визуализации является эмпатия к доске: сотрудники, глядя на доску, понимают текущую ситуацию с работой, и доверяют этому представлению. Отмечу, что такая визуализация иногда сама по себе дает очень большой эффект, проявляя большое количество скрытых проблем: проявляет скрытую работу, выявляя очереди и зависимость команды от смежников, разбираясь с обязательными и не обязательными этапами, а также их последовательным и параллельным выполнением.
Проектирование доски является частью проектирования Kanban-системы в целом. Он выполняется с помощью STATIK – Systems Thinking Approach to Introducing Kanban, описанном в в книге Майка Барроуза (Mike Burrows) «Kanban from the inside». Описывать его я не буду, потому что краткое описание будет достаточно бесполезно. Желающие могут прочесть книгу, или найти и почитать статьи или сходить на первый тренинг «Kanban System Design». Впрочем, если вы любопытны и решите найти статьи с кратким описанием – найдите несколько и сравните.
От функций к сервисам.
Самым главным результатом проектирования является вовсе не прояснение потока работ. Главный результат – это ответ на вопрос для кого работает ваше подразделение в компании и какой сервис оно предоставляет тем, для кого работает. Вообще основная идея Kanban – это представить компанию в сервисной структуре. Перейти от представления компании как потока задач, которые выполняются потому что «так надо» и передаются на следующий этап работ соседнему отделу, к представлению компании как предоставляющий сервис конечному клиенту. Это делают подразделения, которые непосредственно с клиентом взаимодействуют, и для этого другие подразделения предоставляют сервис им самим. Основная идея Kanban – это представить компанию в сервисной структуре. Представление через сервисы означает, что у отдела появляется SLA, Service Level Agreement, описывающий условия для обслуживания им внешних и внутренних клиентов, и такие же SLA появляются у его поставщиков и смежных отделов, которых он привлекает для выполнения своих обязательств. Такой характер взаимоотношений принципиально отличается от привычной работы по обработке задач.
Самое существенное изменение касается отношения к простоям. Задача сервиса не в том, чтобы все сотрудники были максимально загружены, задача в том, чтобы все внешние запросы обрабатывались в соответствии с соглашением. Типичный пример, который, я думаю, всем будет понятен – кассы в супермаркете. Нет задачи, чтобы кассир все время выбивал чеки, есть задача, чтобы очередь была маленькой: увидев хвост, покупатели просто пойдут в соседний магазин. Для оказания сервиса требуемого уровня в условиях неоднородного потока запросов нужны избыточные мощности. А когда покупателей мало, кассира можно занять чем-нибудь полезным, но при этом основная его задача – сервис на кассе.
Отметим, что переход к сервисной модели предполагает разделение задач по классам обслуживания. В общем-то, это хорошо известно: всегда есть срочные задачи и поручения от руководства, или важные сделки с VIP-клиентами, которые следует обслуживать в приоритетном порядке. И их тоже следует проявить в ходе анализа потоков работ и сформулировать отдельные SLA. Важно, что сервисная модель предполагает: обслуживание приоритетных задач не должно задерживать обслуживание обычных, поскольку о наличии таких задач заранее известно, и их наличие необходимо было учесть при проектировании сервиса.
С каждым классом обслуживания связан не только SLA, но и правила обработки в команде. По характеру обработки выделяются четыре типа задач: обычные, составляющие основной поток, срочные задачи с отдельными правилами, задачи с фиксированной датой завершения, и необязательные задачи-улучшения, включаемые в работу, когда основной входной поток по каким-то причинам временно уменьшает мощность. Часто именно их и называют классами обслуживания, но это не совсем верно, класс обслуживания прежде всего зависит от назначения задачи для клиента и связанного с этим SLA, а не от внутренних правил обработки, хотя одно с другим безусловно связано.
WIP-лимиты и вытягивание – ограничиваем незавершенную работу.
Основными характеристиками сервиса является мощность потока задач, которые он обрабатывает и скорость прохождения отдельных задач через сервис. Как учит теория ограничений Голдратта (https://en.wikipedia.org/wiki/Theory_of_constraints), для высокой скорости прохождения задач необходимо ограничить количество незавершенной работы. Для этого в Kanban есть механизм WIP-лимитов, которые ограничивают незавершенную работу. При этом используется разные виды лимитов: на человека, на задачу в целом, на классы обслуживания, на этапы работ. Отметим, что в случае обычного производства ограничением является какие-то конкретные этапы обработки. А в IT из-за высокой неопределенности, связанной с исполнением задачи и длинного хвоста распределения вероятности выполнения, мы, как правило, не можем уверенно выделить этапы, являющиеся ограничениями. Поэтому WIP-лимиты устанавливаются для всех этапов.
WIP-лимит служит ограничением не только числа задач, находящихся в работе на конкретной фазе, но и для тех, которые уже готовы для передачи на следующий этап. В этом и состоит суть вытягивания: задача закреплена за фазой исполнения до тех пор, пока на следующей фазе не освободиться для нее место. Таким образом, возможна ситуация, когда завершив очередную задачу сотрудник не может взять следующую, потому что сработало ограничение лимита. И в этот момент возникает вопрос: а что ему делать? Ответы могут быть разными: «отдохнуть и выспаться», «помочь другим», «посмотреть, что можно сделать в других этапах», «почитать книгу». Важно не брать задачу сверх лимита, увеличивая этим незавершенную работу и нарушая, таким образом, производительность Kanban-системы. Теория ограничений говорит: простои сотрудников не ведут к деградации сервиса. Отметим, что переход к вытягиванию и WIP-лимитам поощряет или даже вводит культуру помощи. Сотрудники учатся видеть потенциально узкие места, в которых скапливаются готовые задачи, которые невозможно продвинуться, потому что на следующих этапах образовалось бутылочное горлышко, и помогать в его разгребании. На статусе у доски разбор идет не по сотрудникам, а по задачам справа налево, и следует обращать особое внимание на те зоны, в которых бутылочное горлышко может возникнуть. А еще такой разбор привносит культуру завершения: начиная с задач, которые продвинулись дальше и уже получили больше незавершенной работы, мы даем им больше внимания, фокусируясь на завершении начатого. И, наконец, формируется культура управления через структурирование работы, а не людей, при этом предполагается, что люди сами соорганизуются вокруг работы, которую им необходимо выполнить. Во время перехода к Kanban это делает коуч, а постепенно навык получает вся команда. И таким образом культура сотрудничества, фокуса на завершении задач (ориентированность на клиента) и другие ценности Kanban прорастают в команде. Так же ценностях и культуре Kanban есть перевод хорошей статьи Майкла Барроуза (https://habr.com/ru/company/scrumtrek/blog/292914/).
Переход к вытягивающей системе выполняется не сразу. WIP-лимиты вводят постепенно, анализируя изменения, к которым их изменение привело для обработки потока задач. И не существует никакой формулы, которая бы позволила вычислить «правильные лимиты» в зависимости от команды: многое зависит именно от конкретного потока задач, а он индивидуален.
Один из простейших лимитов – число незавершенных задач, которые могут быть в ответственности у одного человека. Этот лимит не связан с этапами работ, а призван ограничить незавершенные работы, возникающие из-за внешних согласований. Сотрудник взял задачу в работу, что-то сделал, у него возник какой-то вопрос, он написал письмо – и взял следующую задачу. Когда он так поступил пять раз, то смысл от небольшой начатой работы окончательно потерян. При этом психологически взять следующую ожидающую задачу – гораздо проще, чем разбираться с возникшим затруднением.
Если такие ситуации регулярно возникают и являются типичными, то команда превращается в «отдел ждунов», и это сигнал ситуации, когда никакие внутренние реорганизации не смогут принципиально изменить ситуации. Стоит задуматься о перестройке работы, например, исключении лишних согласований со смежниками или руководством. Сила Kanban-системы в том, что она позволяет увидеть такие ситуации и оценить потери от лишних согласований, а также реальные риски их отсутствия: сколь часто возникают ситуации, когда на согласовании задача была изменена. Алексей Пименов в упомянутом выше докладе рассказывал, что у него было много кейсов, когда согласование занимает 30—50% от времени реализации, и отделу принимать решения без согласования получалось ускорить процесс в полтора раза.
Отдельно стоит сказать про буферную зону входных задач. Для начала можно его не ограничивать, наблюдая за пополнением. И начать регулярно проводить процедуру оценки актуальности задач в буфере: очень часто срочные задачи перестают быть срочными, а не выполненные становятся не актуальными, и нет никакого смысла сохранять их в буфере. И уже после этого вводить ограничения.
Начинать здесь стоит со срочных задач, и не только в буфере, а в целом на обработке, потому что практика показывает, что большое количество срочных задач, которых никто не учитывает, является основной причиной нарушения регулярной работы. Может показаться, что ограничение на срочные задачи – не реалистичное, потому что они часто выполняются по прямому поручениями руководства. Однако, если контролировать их и объяснять, что реально такое количество задач срочно выполнено точно не будет, и надо поставить реальные приоритеты, то получается конструктивный диалог. Практика показывает, что достаточно часто срочность оказывается ситуативной и теряет актуальность, а руководство забывает ее отменить. При этом выполнение в «пожарном режиме» того, что оказалось не нужным является очень сильным демотиватором. Отметим, что выполнение задач, которая стала не актуальной – один из примеров лишней работы, muda в lean.
Отдельно стоит сказать про вытягивание, то есть запуск в работу задач, имеющих фиксированную дату завершения, например, связанных с подготовкой к каким-либо праздникам или датам изменениям нормативных документов. Эмпирическое правило, о котором говорит Андерсон в своей книге, состоит в том, что их следует запускать в работу как можно позже, однако с учетом разумной оценки времени выполнения и определенного резерва времени. Потому что опыт говорит, что чем ближе к дате – тем выше определенность, касающаяся содержания задачи, включая работу смежников. Впрочем, на практике применить это правило довольно сложно, что знают все, кто готовился к экзаменам. Подготовка заранее не имеет особого смысла – ты забудешь выученное. Но вот оценить адекватно время подготовки сложно, в результате последняя ночь перед экзаменом часто проходит вовсе не так, как хотелось бы. Зато это будет одна ночь, а не нервная неделя – время аврала сокращается.
Метрики и индикаторы.
