Читати 12 хв

Четыре столпа business agility (часть 2/2)

Ключевое дополнение к методу безболезненного старта в agile для не-IT команд - 123AGILE.

Помните 123AGILE?

Раньше мы вам рассказывали, что 123AGILE - самый простой и безболезненный способ старта agile. Он работает как для продуктовых креативных команд, так и для сервисных. Помните ли вы три рекомендуемые практики из 123AGILE?

Mobilize;
Visualize;
Ritualize.

Или другими словами: 1. Пространство; - 2. Доска; - 3. Ритуал. Это простые, понятные, мощные и хорошо запоминающиеся три практики простого входа в гибкие методы работы.

Это намного проще, чем Скрам, и поэтому проще для старта.

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

Такой стиль командной работы с его прозрачностью повышает вовлечённость сотрудников, помогает им и их менеджерам раньше выявлять узкие места и тем самым быстрее решать рабочие моменты. Сотрудники же, будучи вовлечены в обсуждение условий и процесса своей работы, имеют непосредственное влияние на него, что зачастую приводит к его серьёзным улучшениям. В свою очередь повышается мотивация персонала. А как нам известно - мотивированные работники оказывают лучший сервис. Это win-win. Всем хорошо: и сотрудникам, и их менеджерам, и их клиентам.

Так и вправду выглядят многие классные agile команды, с которыми нам доводилось работать. Но выглядеть agile и быть agile - это “две большие разницы”, как говорят в Одессе.

Но практика бесполезна, если она не базируется на особых принципах. Так чем же отличается случайная группа людей, спонтанно обсуждающая свою работу у доски, с командой, которая серьёзно практикует agile в своей предметной области?

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

Итак, встречайте, четыре столпа business agility.

Ключевые слова: ценность, ценность для клиента, поставка ценности, поток поставки ценности, длительность потока поставки ценности, кросс-функциональность, кросс-функциональные команды, инкремент.

Интересно? Далі буде!

Результат работы

Итак, давай по порядку.

Просим вас на минутку оторваться от чтения и подумать о том, какие ответы вы услышите, если зададите своим сотрудникам / подчинённым такой вопрос:

Друзья, что является результатом нашей работы?

Ответы, конечно, же могут быть разными, и их диапазон вас удивит:

завершённый проект;
готовый продукт;
оказанный сервис;
удовлетворённый клиент;
пустой список задач;
довольный начальник.

Но это не должно вас удивлять. А теперь такой вопрос:

За что платят (или готовы платить) нам наши клиенты?

Здесь, тоже, к своему удивлению, вы скорее всего услышите различные ответы:

за решённую проблему;
за отсутствие проблем;
за получение или сохранение своих денег;
сохранение или восстановление здоровья.

Не смотря на разницу в ответах разными коллегами на один и тот же вопрос (все люди разные), нас будет интересовать другое - разница в ответе одного человека на оба вопроса. Ведь согласитесь, что не стоит ожидать запредельного качества оказываемого сервиса, когда сотрудники считают, что "пустой список задач" или "довольный начальник" являются результатом их работы...

Business agility - про осознанность в работе. Про совмещение внутренних и внешних индикаторов успеха. Про принесение пользы, а не про просто делание работы лучше или быстрее.

Но давайте по порядку.

Чья польза - клиентов или пользователей?

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

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

Примеры? Пожалуйста: штраф за неверно припаркованный автомобиль, повестка в суд, расчёт налоговой ставки, использование корпоративного Microsoft Teams и Office 365 (вместо желаемого Zoom и Google Docs) или же необходимость использования любого другого продукта или сервиса, регламентируемого сверху.

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

В случае разработки системы видео регистрации автодорожных нарушений клиентом является, скажем, министерство внутренних дел, а если конкретно - его сотрудники и, скажем, министр МВС. Именно их потребность будет удовлетворена, когда мы, несчастные конечные пользователи с вами начнём получать конверты со штрафами! Будем ли мы довольны? Конечно нет. Но речь здесь, к несчастью, ни о нас. Речь о заказчике.

Слова “клиент” и “заказчик” здесь и далее мы будем использовать как синонимы. Но не путайте их с “пользователями”.

К слову, в английском есть забавные рифмующиеся термины: user (тот, кто пользуется - “пользователь”) и chooser (тот, кто выбирает и платит - “заказчик”). Чаще, на деле, встречается слово: customer, вместо chooser.

Первый столп - осознанный поток поставки ценности

Итак, давайте вернёмся к пользе, которую мы оказываем клиентам - мы будем называть её словом "ценность". Ведь у неё есть цена, и за неё должны быть готовы платить. (Термин "ценность", конечно же, применим и к неприбыльным бизнесам).

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

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

Пример: языковая школа. Что мы чаще всего можем увидеть на стенах её офиса? Расписание уроков, фотографии преподавателей, их график загруженности и прочую внутреннюю кухню. Эти аспекты сотрудники и менеджеры школы скорее всего и будут пытаться оптимизировать.

Но зачем клиент школы покупает её услуги? За что они на самом деле готовы платить? Как вариант: за возможность общения с иностранцами, шансы переезда за границу, повышение квалификации и т.д.

Внедрение business agility в языковой школе должно помочь сопоставить внешние цели клиентов (эффективно освоить иностранные языки) с её внутренним устройством и функционированием (помочь клиентам освоить языки более эффективно). Это существенно. Ведь, очень несложно оптимизировать программу и подходы к организации процесса обучения без какого-либо долгосрочного эффекта для клиентов.

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

Поток поставки ценности и организация работы

Другой бытовой пример: вы купили участок за городом без электричества. И вы, естественно, готовы заплатить, чтобы его получить. Вернее, если смотреть шире, вам не электричество нужно - вам нужна возможность пользования привычными приборами и устройства, или ещё шире - вам нужен тёплый дом!

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

бригада по установке столбов;
бригада по установке счётчиков;
бригада по подключению дома к сети.

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

*Прошу прощения за банальность примеров. Но как раз на таких простых и бытовых вещах очень легко показать то, на что у нас замылены глаза в наших организациях. Когда мы рассуждаем о сложных доменах, вроде процесса разработки ПО для искусственного интеллекта или расчёта и выдача кредита клиентам банка, мы считаем их "особенными" и поэтому неподдающимися оптимизации. Это уловка ума. По сути для процессного коуча или фаната business agility - электрификация загороднего участника по сути ничем не отличается от любой другой работы. Контексты разные, термины другие. Но суть работы та же. Так что продолжаем.

Поток поставки ценности и время цикла

Время с момента подачи клиентом заявки до получения им ценности - очень важная и полезнейшая характеристика. Ею можно замерять успехи от внедрения любого улучшения. Её мы будем называть временем цикла (так как с точки зрения бизнеса, а именно его мы и оптимизируем - поступление заказов и процесс их обработки цикличны во времени).

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

Почему это так? Это доказывается теорией бережливого производства (lean) и теория ограничений (TOC). Но для простоты: чем дольше время цикла, тем дольше оборачиваемость капитала, медленней cash flow, больше склады незаконченной продукции, а с ними и стоимость складирования и управления очередями, тем медленней обратная связь по качеству ваших изделий, продуктов или услуг... Короче говоря, этой единственной метрики достаточно, чтобы судить о том, движетесь ли вы в сторону business agility или от неё.

Что же влияет на время цикла? Много вещей. И непоследнюю очередь занимает анатомия той самой бригады на выезде. Или другими словами - состав команды. Да, состав команды может иметь очень существенное значение на время цикла.

Не зря современные организации строятся вокруг команд. Но я забегаю вперёд.

Второй столп - реальная и полная команда

Итак, мы подобрались с вами ко второму столпу (а столбы-то так ещё и не стоят...).

Представьте себя на месте счастливого обладателя участка... Ах нет, забудьте об этом. Лучше представьте себя на месте счастливого сотрудника бригады по установке столбов! Как бы вам было удобно, чтобы был организован процесс работы?

расчёт по факту проделанной работы (и лучше "постолбно", а не когда у хозяина появится "тёплый дом", потому что на это мы не влияем...);
чтобы место под установку столба было заранее подготовленно (и вам не приходилось делать "чужую работу", ещё одна бригада могла бы к примеру рыть ямы до вас);
чтобы была документация (и вам не приходилось обсуждать на месте детали и выяснять ньюансы);
чтобы была продумана логистика (и вам не нужно было трястить часами в кузове грузовика, перезжая между разными заказами, ведь это трата вашего времени!).

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

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

Но это встречается повсеместно:

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

"Нам так удобно" - очень страшное словосочетание. Если вы тот, кто двигает процессные улучшения в вашей организации, научитесь замечать, когда его произносят. Это звоночек субоптимизации.

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

Как это сделать? Оставайтесь с нами после рекламной паузы.

Фейковый аджайл

Представьте на минуту, что бригада по установке столбов ознакомилась со Скрам методом, обзавелась книгой Джеффа Сазерленда и теперь каждое утро перед выездом на участки проводит 15-минутный скрам-митинг у доски с заказами.

Скрам? С виду - да.

Тепло или холодно вам (в буквальном смысле), как клиенту в ожидании тёплого дома, от такой вот модной церемонии, которую осуществляет бригада? Ни то и ни другое! Бригада с таким же успехом могла играть в домино или, скажем, молиться богам цемента и глины.

Это явление в научных кругах называется 'скрамтурбация' - игра в скрам, которая никак не влияет на бизнес показатели.

Локальная оптимизация

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

Здесь стоит сделать ремарку: возможно, у бригад, которые проводят 15-минутку и даже быть может недельное планирование, появится некоторая прозрачность, прилив мотивации и энтузиазма, интерес к Скраму... Это всё классно, и не стоит не замечать такие неизмеримые улучшения. И порой, перед тем, как вы сможете начать говорить об оптимизации чего-то большего, нужно дать людям увидеть выгоды от применения подхода на чём-то, что им близко и понятно.

Но это всё из области психологии и коучинга изменений (а наша статья не об этом). К несчастью очень часто в течение организационных изменений подобные "низковесящие плоды" подменяют высшую цель. А нашей высшей целью должны быть системные улучшения, а они требуют системных и всегда болезненных изменений (ведь понижение организационной энтропии требует затрат энергии, а это неприятно, особенно в условиях отсутствия отопления в доме).

Реальная команда

А как бы Илон Маск оранизовал процесс электрификации участков киевской области?..

Когда вы слышите про "agile команды" или "работу в стиле agile" - всегда подразумевается командная работа вокруг клиентской проблемы. И не просто командная, а самая настоящая - *реальная командная работа".

Если обратится к анналам того, что же есть "реальная команда", то тут не обойтись без работа Ричарда Хакмана и его исследований, показывающих 6 условий эффективной командной работы, первым из которых по важности является:

Для того, чтобы получилась отличная команда первое и самое главное - вам нужно создать реальную команду (в оригинале "real team"): 1) ту, которая имеет чёткие границы, то есть её участники знают, кто в команде (а кто нет) и что им нужно работать вместе для успешной работы и 2) они стабильны в плане членства достаточно долго, чтобы сделать вместе что-то существенное.

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

Промежуточный итог

Подводя итог по двум столпам, которые мы рассмотрели, и которые, как вы понимаете связаны между собой:

Осознанный поток поставки ценности;
Полная и реальная команда.

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

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

Чего ещё не хватает? Или этого уже достаточно?

Вовлечённый бизнес представитель

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

Поэтому, по сути, у любой команды два набора заинтересованных лиц: с одной строны это клиенты (и поток поставки ценности ведёт к ним), но с другой стороны это менеджмент компании (бизнес стейкхолдеры). Если с первой группой мы уже разобрались и поставили её на первое место, то сейчас самое время поговорить о последних.

Scrum вводит роль, которая у всех на слуху - "Product Owner" или "Владелец продукта", суть которой дать возможность бизнес стороне компании вовлечься и реально управлять работой команды в потоке поставки ценности. Но не микроменеджить (мы яростно верим в том, что реальная полная команда способна управляться самостоятельно), а именно МАКРОменеджить. Что же такое макроменеджент? Это работа с целями, стратегией, важными инвестиционными решениями ("делаем то, не делаем это"). Это и есть тот самый обожествлённый Скрамом крутой Владелец Продукта - стратег и макроменеджер.

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

Что даёт наличие такой роли в процессе? Оно создаёт контекст, в котором бизнес представители и команда (команды) работают тесно вместе над теми задачами, которые перед ними стоят. Слеп тот руководитель, которые предполагает, что достаточно поставить перед командой чёткие требования и отойти не мешать. В лучшем случае - команда реализует эти требования, как они написаны или вернее, как они их поняли... Это не управление работой. Это уход от управления с возможностью постфактум свалить всю вину за ошибки на команду.

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

Промежуточный итог №2

Подводя итог по трём столпам, которые мы рассмотрели, и которые, как вы понимаете связаны между собой:

Осознанный поток поставки ценности;
Полная и реальная команда;
Вовлечённый представитель бизнеса.

Уже практически комплект. Но чего-то, кажется, не хватает...

Завершающий ингридиент

Чем сложнее решаемая задача, чем сложнее предметная область, тем хуже виден прогресс. И business agility - не про простую работу, не про укладку асфальта или работу колл-центра. Всю ту работу, которую можно со временем автоматизировать или заменить AI мы не рассматриваем.

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

Что же нужно нам, чтобы двигаться в тумане неопределённости по территории запутанности? Нам нужны опознавательные знаки. Какие-либо сигналы, ориентиры и как это не смешно - наши с вами глаза и желание видеть эти самые знаки, независимо от того, что эти знаки сообшают нам.

"Inspect and Adapt" - это мантра agile мира. "Посмотри на реальность и скорректируй свой курс". В основном мы с вами так и живём. Исходя из этого принципа водим машины, воспитываем детей, едем в отпуска. Только в работе мы часто забываем о важности этого навыка - навыка гибкости.

Видимый измеримый результат

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

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