Гибкий процесс развития продуктов

Одно время стали довольно популярными обсуждения на тему: а как-бы нам использовать agile за границами ИТ. Несколько таких дискуссий вы, безусловно, найдете в группе FB GosAgile или в блоге Atlassian

Честно говоря, я не помню, чтоб в них было сказано что-то уж очень полезное. Возможно, я просто читал их недостаточно внимательно, а быть может авторы ограничивались слишком простой калькой с процессов разработки ПО. Ниже я опишу некую гипотезу о том, как мог бы выглядеть процесс new product development, адаптированный к современным реалиям посредством agile Lean и Kanban. В какой-то мере это будет продолжением статьи Чему ИТ может научить бизнес.

В принципе, попыток совместить гибкие методологии разработки программ с другими полезными подходами сделано довольно много(cм., например, картинку в начале этой заметки с версией Gartner комбинации Design Thinking, Lean Startup и Agile), но в большинстве из них смысловые вещи остаются где-то между строк.

Давайте начнем с традиционного процесса развития новых продуктов и услуг, именуемого обычно new product development. На рисунке ниже, который я люблю показывать в своих презентациях, изображен один из вариантов такого подхода от известного разработчика инструментов корпоративной архитектуры и управления портфелем проектов компании PlanView. Вполне себе такой «водопадный» или каскадный процесс, именуемый еще порой как stage-gate approach. Самая правильная идея в этой картинке это, некая воронка инноваций, по аналогии с воронкой продаж, иллюстрирующая тот факт, что до финиша дойдут далеко не все, а задача проектного офиса не столько в том, чтоб запустить побольше продуктов, а наоборот – отсеять лишние, сконцентрировав скудные ресурсы организации на реализации самых перспективных идей.

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

Вроде бы этапы остались те же самые, но подход поменяется довольно существенно. Вспомним про идею «вытягивания» задач. Здесь это  ключевой момент. На первом этапе, именуемом innovation frontend, менеджеры продуктов, руководители функциональных подразделений, простые граждане и другие сотрудники публикуют идеи новых продуктов и услуг, почерпнутые из разных источников, на неком общедоступном корпоративном ресурсе. Корпоративная вики, связка Jira+Confluence – вполне сгодятся. В Билайне такое пространство называлась «банк идей» Большая часть таких идей оставалась в этом банке навсегда и много лет никуда не двигалась. Делается этот этап с одной простой целью – очертить имеющиеся идеи, отделить их друг от друга, или же, наоборот, понять, что вот эта группа идей, на самом деле, об одном и том же. Специальная группа людей периодически и довольно неспешно занималась этой самой деятельностью.

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

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

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

Аналогичный подход применяется и на более поздних этапах, когда мы уже разработаем прототипы, проведем сплит-тестирование, осуществим серию разворотов (pivot) и будем более-менее представлять, что сейчас можно продвинуть на рынок. Маркетологи с продуктологами смотрят портфель, представляя степень готовности той или иной услуги, и видя результаты исследований и выбирают те, которые попадут в ближайшее окно маркетинговых коммуникаций, например, под новогодние праздники или 14-23 февраля/8 марта, сезон летних отпусков и т.д.

Один комментарий к “Гибкий процесс развития продуктов”

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *