Как быстро выводить на рынок продукты и быть готовым к любым изменениям?

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

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

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

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

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

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

Обычно потребитель воспринимается как некий «черный ящик», мысли которого нужно непременно угадать заранее. Но потребитель — не «черный ящик», и иногда можно просто показать ему товар. И пусть он сам дальше подскажет, как нужно его улучшить.

Суть Agile: попробовали — ощутили — отрегулировали. И так, итерация за итерацией, мы проверяем гипотезы до тех пор, пока не приходим к лучшему решению.

25 октября состоялось первое заседание Бизнес-клуба Высшей школы бизнеса НГУЭУ, в рамках которого директор по развитию компании NPM group Сергей Чирва поделился опытом, как создавать реально работающие продукты быстро, качественно и с удовольствием, используя Agile–подход к управлению проектами, который решает проблемы традиционного проектного менеджмента. Выбор спикера был не случаен, поскольку компания NPM одна из первых применила Agile–подход в реальном секторе, хотя до этого его в основном применяли компании сферы ИТ. И это не случайно.

Интересно и то, откуда появился этот подход. Все началось в 2001 году, c осознанного кризиса в ИТ-отрасли, когда оказалось, что 80% написанных программ вообще никем не используются. И тогда те компании, которым было небезразлично, что происходит с их кодом, задались вопросом: а может быть, есть смысл делать не то, что мы придумали, а то, что действительно нужно людям? Потому что поменять процессы проще, чем поменять людей, особенно если эти люди — ваши потребители.

Одним из плюсов такого подхода является то, что изменения перестают быть для вас чем-то страшным. Даже если это изменения в ТЗ или желаниях заказчика. Да, заказчик не знает, чего он хочет. И мы не знаем. И это нормально. Вы просто знаете, что изменения в любом случае будут, и вы всегда к ним готовы. Это как подъем на вершину: вы знаете конечную точку, куда вам нужно попасть, и вы даже можете ее видеть. Но вы не знаете и не можете знать, что ждет вас на пути.

Да, это сложнее: вам нужен постоянный фокус на рынок, на продукт, на клиента. Но и путь до рынка в таком случае получается гораздо короче.

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

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

ТОЧКА ЗРЕНИЯ

Как уже было сказано, одной из первых компаний в России в производственном секторе, которая решила применять у себя Agile-подход, стала NPM (ранее — «Новосибпродмаш»). О том, зачем это понадобилось компании и какой опыт она извлекла из внедрения этой методологии, «КС» рассказал директор по Agile компании NPM СЕРГЕЙ ЧИРВА.

— Сергей, насколько результативно управление проектами с помощью Agile? Какие задачи эта технология решить может, а какие — нет?

— Важно понимать, что Agile — это не технология, это философия, она сама по себе не решает каких-либо задач, но дает основу, платформу для создания ценных для клиентов продуктов максимально быстро. В первую очередь она нужна там, где разрабатывается новый продукт. И это могут быть не только ИТ-продукты или какие-то материальные изделия. Результатом в Agile может быть любой процесс, если вы видите его как продукт. При формировании в компании продуктового мышления вы можете персонал подбирать по Agile, например. В целом методология позволяет создавать некое новое осмысление того, что люди важнее, чем процессы, а выдавать готовый продукт важнее, чем делать документацию. Сама философия Agile позволяет достичь высокой результативности. И ключевой момент здесь в максимальной скорости доставки ценности потребителю. Вы не занимаетесь бесконечными улучшениями, вы точечно здесь и сейчас даете самое важное, что нужно клиенту. С этой точки зрения ограничений по направлениям бизнеса нет. У нас в компании это работает и в маркетинге, и в рекрутинге — по всем направлениям.

— Как происходило внедрение Agile в вашей компании?

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

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

К этому нужно приспособиться. Примерно так обычно работают стартапы. Можно сказать, что при Agile в корпоративном формате работают много-много маленьких стартапов, которые разрабатывают свои продукты. Поэтому самая большая сложность — это поменять сознание.

— Где находятся «контрольные точки» в управлении проектами с помощью Agile? Как сделать так, чтобы это действительно работало?

— Если мы говорим о самом популярном «фреймворке» Agile — Scrum, контрольные точки находятся в конце каждой итерации (спринта).

Именно тогда вы смотрите на продукт, и если понимаете, что идете не туда, можете своевременно скорректировать направление развития. На каждой демонстрации результатов спринта (а это может быть одна, две или три недели в зависимости от длительности, которую вы выберете) команда заново «продает» свой продукт стейкхолдерам (инвестору, потенциальным потребителям и т. д.). Потенциально обновленный продукт можно внедрять по итогам каждого спринта, таким образом, поставка ценности потребителю идет непрерывно. Эффективность организации здесь оценивается намного быстрее, потому что если вы за три недели не сделали продукт, значит, что-то пошло не так: либо команде что-то мешает, либо внутри команды нет команды. Не нужно полгода ждать результата, вы буквально каждый спринт оцениваете его и видите все проблемы организации. Никаких специальных «контрольных точек» выстраивать не нужно, они формируются сами.

Основная обязанность руководителя здесь не контролировать, а создавать условия и устранять препятствия на пути эффективной работы команд.

— Что составляет основу успеха при внедрении Agile, на что нужно обратить особенное внимание?

— Если вернуться к метафоре с деревом, главное — не пытаться силой тянуть взращиваемое растение за ветки. Достаточно создавать для него комфортные условия и ждать, когда оно окрепнет и прорастет. Второе, но не менее важное — это сознание инвесторов и руководителей. Оно должно поменяться в первую очередь. В компании не может быть Agile, если в «голове» его нет.

— Какие примеры внедрения Agile можно считать успешными?

— Пример компании NPM считаю довольно успешным в производственной сфере, и мы планируем и дальше культивировать Agile. Буквально накануне я побывал в московской компании ArtStudio, они применяют гибкие методологии при создании своей продукции.

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