Вероника Гатилова

Старший маркетолог ООО «Диалог Информационные Технологии»

Эдуард Мелкоступов

Специалист-консультант ООО «Диалог ИТ»

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

В чем риски стандартного подхода к разработке продуктов

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

Такой подход разработки продуктов получил название «Стратегия большого взрыва» — обратной связи от заказчика нет до окончания проекта. Вот некоторые риски, которые можно встретить при таком подходе:

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

 Agile, как способ минимизировать бюрократию

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

В 2001 году был выпущен «Манифест гибкой разработки ПО», состоящий из 12 принципов. С этой даты и берет свое начало существование такой методологии (или даже философии) как Agile (дословно – «гибкий»). В её основе лежит метод итераций – повторений определенных элементов работы внутри коллектива. Коллектив оформляется в команду, состоящую из планировщиков, разработчиков, дизайнеров, тестировщиков. Все эти люди на протяжении всего проекта работают вместе, постоянно обсуждают полученный результат и каждый день задают себе два вопроса:

  1.  Делаем ли мы то, что нужно заказчику?
  2.  Можем ли мы делать это еще лучше?
Основной особенностью Agile является то, что команда двигается небольшими шажками, постоянно получая обратную связь от других членов команды и от заказчика, изменяя траекторию создания продукта, и в конечном итоге приходит к результату, который может значительно отличаться от изначального, но который в полной мере удовлетворит клиента.

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

Agile – это философия, а что же такое Scrum?

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

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

Сама же работа строится по принципу спринтов и собраний на ходу. Первые представляют из себя этапы работы над проектом. Обычно устанавливается от 1 до 4 спринтов для одного проекта, каждый из которых длится ровно неделю. В течение 1 спринта команда проводит одну или несколько задач от этапа планирования до полного выполнения. Каждое утро все члены команды собираются и участвуют в ежедневной Scrum встрече, где они делятся успехами за прошлый день, дают обратную связь и обозначают свои планы и задачи на день. Благодаря ежедневному обсуждению, команда получает больше гибкости в решении различных задач, так как может корректировать свою работу в соответствии с работой своих коллег. В конце спринта команда презентует свои результаты за неделю владельцу продукта и/или клиенту, что позволяет получать обратную связь достаточно часто для корректировки курса разработки.

Scrum полагается на самоорганизованную, многопрофильную рабочую группу, в которой нет непосредственного лидера (не считая владельца продукта, но он не управляет действиями команды, а лишь дает задачи и проверяет промежуточные результаты). Благодаря тому, что вместо детального описания рабочего процесса команде предоставляется больше свободы действий, члены команды сами вольны выбирать способы решения задач и распределять свои обязанности в соответствии с возможностями. А многопрофильность команды означает то, что каждому из членов необходимо провести выбранную функцию от этапа генерации идей до конечного внедрения в продукт. Таким образом, главным предметом методологии Scrum являются бэклоги и сам продукт. Scrum довольно прост для внедрения и это позволяет применять его многим командам, которые уже перешли на Agile.

Секреты эффективного использования

Но не обошлось и без минусов, даже скорее ошибок, которые могут быть допущены при работе в условиях Scrum:

  1. Усложнение. Бывает так, что Scrum подход не будет самым простым и эффективным из доступных, и в таком случае его применение лишь замедлит разработку.
  2. Ежедневный scrum. Благодаря встречам каждый участник может понять, в какую сторону движется команда, какие задачи необходимо решить сегодня, и какие вопросы требуют ответа. Не будет встреч – эффективность метода очень сильно снизится.
  3. Ретроспектива. После каждого из спринтов команде необходимо собираться вместе и оценивать успехи за прошлую неделю. В scrum очень важна обратная связь и регулярный мониторинг успехов, именно это и дает методологии такую гибкость. Важно вовремя заметить возможные проблемы, требующие исправления, чтобы следующий спринт прошел гладко.

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

Когда и так все понятно, зачем усложнять?

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

© «УПРАВЛЯЕМ ПРЕДПРИЯТИЕМ»
Все права защищены. Все торговые марки являются собственностью их правообладателей.