В чем проблема?

 

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

 

Комплексный подход к внедрению инноваций 

Эксперимент — основной метод разработки и внедрения инноваций. Есть два способа разработки и планирования инновационных решений.

Customer Development – подход к созданию продукта или бизнеса, основанный на плотном взаимодействии с клиентом. Важным элементом является формулировка MVP (Minimum Viable Product) – минимального жизнеспособного продукта, обладающего минимальными, но достаточными для удовлетворения первых пользователей функциями.   В основе лежит формулирование и управление гипотезами.

Гипотеза – предположение, которое основывается на том, что решение (продукт или сервис) принесет определенную ценность выделенному сегменту пользователей за счет удовлетворения потребности или решения какой-то проблемы. Гипотеза должна формироваться и проверяться на разных циклах Customer Development, но её конечная валидация происходит на этапе релиза MVP.   Ниже мы рассмотрим набор методов и инструментов, которые позволят значительно снизить порог входа в инновационную деятельность для среднего бизнеса. 

 

Robotic Process Automation как пример инновационной ИТ-технологии

 

Robotic Process Automation – форма технологии автоматизации бизнес-процессов. Эта технология получила широкое распространение не только зарубежом, но и в России. Порой компании начинают внедрение там, где не стоит этого делать. Известны случаи, когда бизнесы вместо того, чтобы подготовить почву для внедрения RPA-решений и осмысленно подойти к вопросу, поспешно приобретают лицензии на готовые решения, либо инициируют разработку RPA-решений.   Одной из ошибок является неверное понимание того, какое место занимают элементы RPA в бизнес-архитектуре и ИТ-инфраструктуре. Робот не является частью инфраструктуры, а находится на более верхнем уровне в архитектуре бизнеса, взаимодействуя с интерфейсами существующих ИТ-приложений. RPA-решения “насаживаются” на существующую инфраструктуру, для того, чтобы выполнять рутинные операции, которые ранее выполнял человек. Чтобы понять, как внедрить RPA-решение и какие процессы можно отдать на выполнение этой технологии, нужно применить большой набор методик и инструментов.

 

Компоненты успешной разработки и внедрения инновационных ИТ-продуктов

 

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

 

• Технология Форсайт: анализ рынков, отраслей и выявление трендов.

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

 

• Определение пользователей и требований. 

Вне зависимости от того, является ли заказчиком бизнес, или внешний пользователь, акцент должен делаться на изучении конечного потребителя. Необходимо понимать какие пользователи будут и могут быть задействованы при работе с новой системой. Для выявления роли пользователей и составлениях их портрета используется Impact Mapping и интервью.    Impact mapping – это методика планирования для команд, которые создают ИТ-решения и продукты. Она основана на дизайне взаимодействия с пользователем, планировании, ориентированном на результат, и составлении диаграмм связей. Визуализация, помогающая составить портрет потребителя.   Основным инструментом выявления требований являются интервью. На начальных этапах возможна комбинация тех методик, которые используются в бизнес-анализе и так называемых проблемных интервью, предлагаемые методикой Customer Development. Далее, после того как ИТ-решение будет сформулировано, проводят решенческие интервью, целью которых является проверка правильности потенциального решения.   В случае, если понадобится применение технологии RPA, и решение будет внедряться для рынка B2B, то дальше необходимо придерживаться следующей последовательности относительно получения первых бизнес-кейсов (case study). 

 

• Анализ бизнес-процессов. 

BPM (business process management) – концепция управления бизнес процессами занимает важное место в предлагаемом подходе. При создании ИТ-инноваций, тем более связанных с использованием RPA-решения, необходимо начать с описания основного и дополнительных процессов, в рамках которых работают все пользователи будущей системы.    Необходимо провести эти действия для пилотной имплементации решения, на основе которой будет описываться бизнес-кейс. Если имеется готовое описание бизнес-процессов, то на его основе можно произвести оценку для какой части бизнес-архитектуры целесообразно применение инструментов BPM, а для какой – RPA.    Далее, необходимо реализовать или обновить бизнес-архитектуру и выделить шаги для внедрения инновации. При этом надо фиксировать цели на каждом шаге процесса и метрики, которые будут отслеживаться. Один из инструментов, который может помочь в данном направлении – User Story Mapping – создание карты пользовательских историй, который строится на основе бизнес-сценария.   К robotic process automation прибегают именно на этой стадии, когда становится ясно, какие действия можно отдать на исполнение RPA-технологиям. В отличии от средств ИТ-автоматизации, RPA-решения способны адаптироваться к меняющейся среде, исключениям из правил и новым ситуациям. Эти самообучающиеся системы способны выявлять и интерпретировать действия в определенных процессах, оперировать данными, инициировать ответные действия, запускать команды и коммуникации с остальными системами в ИТ-инфраструктуре, и делать это автономно.   Инициативы, связанные с внедрением RPA-решений, просто не могут обойтись без управленческой концепции BPM. Особенно это важно для тех организаций, которые используют множество сложных систем, между которыми должен осуществляться бесперебойный обмен данными.

 

• Формулировка гипотезы и описание MVP. 

Сформулировать гипотезу означает описать сегмент пользователей, их проблему, что именно будет являться решением данной проблемы и показатели успешности MVP, т.е. метрики продукта. Для отслеживания метрик надо продумать и реализовать “линейку” – определить, как выбранные показатели будут отслеживаться, с помощью каких инструментов, кем и как часто. Результатом MVP являются знания и информация о том, подтвердилась ли основная гипотеза. Фокус нужно держать на целях, обозначенных на этапе анализа бизнес-процессов и метриках. Шаблон MVP позволяет наглядно представить всю эту информацию.  Как следует и не следует подходить к формированию MVP я описал в этой статье.

Бывает, что люди, близкие к теме разработки софта спрашивают: чем проектная работа отличается от создания MVP (Minimal Viable Product)? Понятно, что при этом у каждого спрашивающего свой контекст вопроса – соответственно, отвечать на него надо по-разному. Однако, если обобщить, то проект и разработка продукта сильно отличаются друг от друга. Вообще всем. Это не так-то легко объять, поэтому давайте попробуем разобраться в проблематике.

 

Проблематизация: проект или разработка продукта

Если смотреть поверхностно, то разработка софта – она и есть разработка софта, будь то проект или разработка продукта. Есть некие функциональные требования – не всегда формализованные. Есть нефункциональные требования – про которые частенько забывают вовсе. Есть разработчики, есть некий условный менеджер, и есть какая-то методология. Разработчики пилят код, менеджер разгребает препятствия у них на пути, решает вопросы с конечным клиентом / пользователем / заказчиком. В конце показывают какой-то результат. Иногда, как любят шутить в индустрии, результат даже соответствует требованиям.  Кстати, вопрос рассогласования требований конечного результата поднимал мой коллега в статье “Формулируем MVP в заказной разработке”

 

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

 

Это так называемые “проектный” и “продуктовый” подходы к разработке. У каждого подхода есть свои особенности, которые мы рассмотрим чуть дальше. Так вот, если копнуть ещё глубже в продуктовый подход, то внутри можно выделить ещё и разработку MVP. Создание MVP, будучи частью продуктовой разработки, в то же время имеет свои особенности и резко отличается от разработки уже полноценного продукта с целью его улучшения и расширения. Помимо MVP также можно выделить MMF (Minimum Marketable Feature). MMF не является объектом рассмотрения данной статьи, просто нужно отметить, что это разные вещи. Их, к сожалению, частенько путают, говоря, что всё это MVP.   И вот теперь, имея представление о существовании всех этих отличий – можно копнуть глубже в детали и рассмотреть, чем же именно отличаются подходы.

 

Проект vs продукт

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

1. Основной задачей проектного управления обычно является попадание в тройственное ограничение: Сроки, Стоимость, Функциональность. Из этого требования логически проистекает необходимость договариваться обо всём “на берегу”, фиксировать эти договорённости, и проводить зачастую очень утомительные циклы согласований для любых изменений. 
2. Этот подход требует специфического состава команды, процессов, коммуникаций.

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

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

Как говорится – сюрприз-сюрприз. Цели, поставленные перед системой, определяют всё наполнение системы: материал, из которого она создана, её структуру, процессы, внутренние и внешние связи.

Тройственное ограничение

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

 

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

Специфика проектной системы

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

 

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

 

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

 

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

Гибко откликаться на сигналы рынка

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

 

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

При этом сами итерации не могут быть длинными: результат нужен как можно раньше. Чем быстрее “вброшенная” идея будет реализована и выпущена на рынок – тем раньше будет понятно, стоит ли развивать её дальше, или нужно брать другую. Поэтому сами итерации обычно варьируются от одной недели до одного месяца, и чаще всего команды выбирают “золотую середину” в две недели.

 

При этом по завершении КАЖДОЙ итерации команда выдаёт рабочий результат. Нечто, что можно пощупать, дать пощупать клиентам, выложить в сеть, разрекламировать, увидеть плюсы и минусы, скорректировать дальнейшее развитие. Ну, по крайней мере, гибкие подходы декларируют, что результат будет готов после каждой итерации. Реальность, бывает, вносит свои коррективы.

 

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

 

Бюджеты при этом завязаны на стоимость команды разработки в единицу времени и срок реализации. Чем дольше команда работает – тем больше бюджета она “съедает”.

 

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

Специфика продуктовой системы

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

 

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

 

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

 

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

 

Неизбежно и роли внутри команды сглаживаются, перестают быть настолько ярко выделенными, как при проектном подходе. Разработчик может в один день и пописать серверный код, и код фронта, и поверстать, и потестировать. Дробить уже и так небольшие задачи на отдельные блоки и раздавать людям с разными компетенциями становится чересчур накладно. Поэтому резко возрастают требования не к специализации, а к кросс-функциональности членов команды, растёт ценность full-stack разработчиков.

 

При этом внедрение может вестись – и зачастую ведётся – параллельно с разработкой. Этим может заниматься либо эта же команда разработки, либо команда внедрения и поддержки, работающая в своём ритме.

 

Результирующая таблица сравнения

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

 

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