Менеджмент цифрового мира

Для уже существующего бизнеса вместо ценности для пользователей можно использовать продвижение по векторам Objectives and Key Results (OKR) для развития бизнеса. Например, если стоит задача захвата регионального рынка, то вы планируете разные рекламные и маркетинговые акции с целевыми аудиториями и ожидаемым эффектом, но при этом не надо забывать о насыщении рынка количеством товара, адекватным прогнозируемому росту спроса. И так далее.

Предварительный план релизов

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

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

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

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

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

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

Полная схема Scrum

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

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

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

Подготовка бэклога к спринту

Как написано выше, предварительный бэклог наполнен крупными задачами, для которых известен только принципиальный способ реализации. Они несут значительную долю неопределенности, которая недостаточна для уверенного планирования спринта. Поэтому до планирования задачи бэклога, которые с большой вероятностью будут включены в спринт, необходимо дополнительно детализировать. Возникает естественный вопрос: а насколько подробно необходимо прорабатывать задачи, кто именно их оценивает. На этот вопрос есть следующий функциональный ответ: содержание задачи должно быть проработано настолько, чтобы (а) Product Owner был уверен, что выполнение этих работ принесет стейкхолдерам желаемую ценность и (б) Команда могла оценить трудоемкость выполнения этих работ на планировании. Не меньше, но и не больше. Потому что именно на основании оценки задач и принимается решение, что помещается в спринт, а что – нет. Однако, использование только функционального ответа недостаточно, потому что разные люди будут по-разному давать ответ на этот вопрос. Поэтому хорошей практикой является разработать чек-лист Definition of Ready, формулирующий критерии готовности задачи к планированию.

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

Если такая подготовка задач к будущему планированию требуют заметных трудозатрат, то их надо планировать в предыдущим спринте, а если ограничивается обсуждениями, то отдельное время не выделяется, оно учитывается как общие накладные расходы. Процесс такой подготовки называется backlog grooming или backlog refinement. Груминг – первоначальное название, и оно соответствует сути, однако у него есть негативные сленговые коннотации, поэтому в официальных документах оно было заменено на refinement, подробности можно прочитать в этой статье.

Подготовка бэклога показана на моей рисовке схемы отдельным процессом, хотя часто ее помечают просто надписью на содержании спринта. Этот процесс требует организации. Простой способ – добавить к скрам-доске три колонки слева, в первую из которых Product Owner будет вывешивать задачи, ожидающие подготовки, во второй – те, которые готовятся на данный момент и в третьей – готовые к включению в будущий спринт. Но если процесс более сложен и требует внешних согласований, то такой способ может оказаться недостаточен. Тогда для подготовки бэклога можно организовать отдельный Kanban-процесс – об этом есть хороший доклад Алексея Пименова на SECR-2016 «Discovery Kanban для управления беклогом Scrum-команды».

Еще один вариант организации подготовки бэклога – уже упоминавшийся в главе «Завершение спринта в Scrum – демо и ретро» splitting sprint, разделение спринта на два со сдвигом.

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

Оценка работ

Об оценке трудоемкости следует сказать отдельно. Она может выполняться в физических единицах, например в человеко-часах, в том числе в разрезе конкретных специалистов. В этом случае понятно, как определять, сколько задач поместиться в спринт: у нас есть общий ресурс часов команды, с учетом текущих отпусков, есть нормированные накладные расходы и резерв на регулярные потоки работ, если команда их делает, и дальше мы просто учитываем загрузку специалистов. Такая оценка практикуется, при этом, однако, важно не стремиться к излишней точности оценки. Обычно это достигается применением карточек, где оценка дана в числах Фиббоначи (1, 2, 3, 5, 8, 13, 20, 40) или степенями двойки. Но практика показывает, что при относительно однородном потоке задач не менее точной, зато гораздо более быстрой является оценка не в часах, а условных единицах Story Point или в условных размерах: S, M, L, XL. При этом на нескольких спринтах эта оценка калибруется и емкость спринта или скорость команды определяется именно в таких единицах. Практика показывает, что члены команды могут давать оценку в размерах даже для задач, в которых они не являются специалистами-исполнителями, обучаясь на предыдущем опыте работы.

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

На планировании вполне вероятной является ситуация, когда оценка задачи получается слишком дорогой для ее ценности. Тогда следует такт обсуждения с Product Owner, который на планировании представляет интересы стейкхолдеров. Во-первых, бывает, что у стейкхолдеров есть на этот случае План-Б, и задачу просто не нужно делать. Во-вторых, возможно, команда может предложить какое-то более легкое решение для реализации, которое удовлетворит основные потребности – правило Парето говорит, что чаще всего это возможно. Это – конструктивное обсуждение.

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

Планирование – контракт на спринт

Вообще надо отметить, что планирование представляет собой заключение контракта на спринт между командой и стейкхолдерами, при этом интересы стейкхолдеров представляет Product Owner. Этот контракт может иметь разную жесткость. В свое время была популярной идея о том, что «настоящая команда» на планировании всегда дает обещание, commitment, которое потом выполняет почти любой ценой. Такой взгляд очень нравится стейкхолдерам и, на первый взгляд, отвечает их интересам. Однако, практика показывает, что это неверно. В долгую это ведет к выгоранию команды либо к сознательному завышению оценок, в котором еще и не сознаются, тратя выигранное время по своему усмотрению и превращая работу в agile- курорт. И этому есть системная причина – длинный хвост распределения в оценках IT-работы, о чем есть хороший доклад Андрея Бибичева «Пуассоново горение сроков».

Поэтому правильный подход – учитывать такую статистику на планировании и ранжировать задачи по желательности их исполнения. Для этого можно применять шкалу MoSCoW (Must – Should – Could – Would) или ее сокращенный вариант, и не ставить максимальное значение достаточному количеству задач. Кроме того, учитывая статистику, необходимо не заполнять весь бэклог крупными задачами, в нем должен быть достаточный буфер мелких задач. Конечно, планирование спринта обычно не является заключением какого-то принципиально нового контракта, речь обычно идет лишь о целях и объеме работ на спринт. Однако, в общем случае, стейкхолдерами проекта после любого спринта может быть принято решение о прекращении проекта.

Ценность и содержание работ

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

– Мы думали, что пользователи смогут, увидев названия документов в результате поиска по базе, выбрать наиболее подходящий, а выяснилось, что для очень много запросов выдает совершенно однотипные списки названий, начинающихся с «Письмо Минфина от DD.MM.YY разъяснением по практике применения…», и выбрать совершенно невозможно.

– Мы думали, что пользователь сформирует список из 10—20 любимых песен для запуска по циклу в фоне, а оказалось, что у многих есть несколько списков для разных настроений, и любимое произведение в одном состоянии превращается нестерпимым в другом.

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

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

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

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

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

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

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

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

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

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

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

Кеневин-фреймворк – можно ли найти компетентных сотрудников

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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