Услуги по 1С
Большое количество бюрократии замедляет разработку продуктов, делает ее дороже и неподатливей. Стандартный, плановый подход предполагает строгое следование этапам, — от разработки и дизайна до тестирования и вывода продукта на рынок. Процесс разработки неизменен в течение всего времени работы. Более того, плановый подход предполагает постоянное повышение затрат на каждом этапе создания продукта, в то время как ценность самого продукта равна нулю до выхода на рынок. К тому же, сложно предсказать, точно ли продукт принесет достаточно денег для того, чтобы окупить его разработку.
Такой подход разработки продуктов получил название «Стратегия большого взрыва» — обратной связи от заказчика нет до окончания проекта. Вот некоторые риски, которые можно встретить при таком подходе:
Agile, как способ минимизировать бюрократию
Для того, чтобы обойти ограничения и быстрее предоставить ценный и актуальный продукт покупателю, а также минимизировать бюрократию, в 1990-х начинаются первые попытки изменить работу постоянного следования планам и документациям.
В 2001 году был выпущен «Манифест гибкой разработки ПО», состоящий из 12 принципов. С этой даты и берет свое начало существование такой методологии (или даже философии) как Agile (дословно – «гибкий»). В её основе лежит метод итераций – повторений определенных элементов работы внутри коллектива. Коллектив оформляется в команду, состоящую из планировщиков, разработчиков, дизайнеров, тестировщиков. Все эти люди на протяжении всего проекта работают вместе, постоянно обсуждают полученный результат и каждый день задают себе два вопроса:
Еще одним преимуществом философии Agile является более грамотный риск-менеджмент, который возможен благодаря постоянному мониторингу состояния проекта, внесению изменений в процессе разработки и большому количеству обратной связи. В итоге, адаптивный гибкий подход позволяет работать слаженней и достигать нужного результата быстрее, дешевле и с меньшими рисками.
Традиционные модели разработки цифровых продуктов часто фокусируются на эффективности, а не на стоимости разработки. И иногда такой подход просто не оправдывает себя. Проект может выйти за установленные временные рамки, не уложиться в бюджет, и, что самое неприятное, выпущенный продукт может так долго находиться в разработке, что к моменту выхода будет уже не актуален. Как раз с таким набором проблем справляется подход к разработке продуктов под названием Scrum (дословно – «схватка») – наиболее популярная гибкая методология.
Все начинается с владельца продукта. Он определяет основных заинтересованных лиц (клиентов, заказчиков), работает с командой, в его задачи также входит определение приоритетов и создание бэклога продукта (списка задач, которые необходимо реализовать). Также в команде присутствует scrum-мастер. Он помогает команде вести работу над проектом, направляет ее, следит за правильным выполнением структуры работы и в целом, его работа похожа на кураторство.
Сама же работа строится по принципу спринтов и собраний на ходу. Первые представляют из себя этапы работы над проектом. Обычно устанавливается от 1 до 4 спринтов для одного проекта, каждый из которых длится ровно неделю. В течение 1 спринта команда проводит одну или несколько задач от этапа планирования до полного выполнения. Каждое утро все члены команды собираются и участвуют в ежедневной Scrum встрече, где они делятся успехами за прошлый день, дают обратную связь и обозначают свои планы и задачи на день. Благодаря ежедневному обсуждению, команда получает больше гибкости в решении различных задач, так как может корректировать свою работу в соответствии с работой своих коллег. В конце спринта команда презентует свои результаты за неделю владельцу продукта и/или клиенту, что позволяет получать обратную связь достаточно часто для корректировки курса разработки.
Scrum полагается на самоорганизованную, многопрофильную рабочую группу, в которой нет непосредственного лидера (не считая владельца продукта, но он не управляет действиями команды, а лишь дает задачи и проверяет промежуточные результаты). Благодаря тому, что вместо детального описания рабочего процесса команде предоставляется больше свободы действий, члены команды сами вольны выбирать способы решения задач и распределять свои обязанности в соответствии с возможностями. А многопрофильность команды означает то, что каждому из членов необходимо провести выбранную функцию от этапа генерации идей до конечного внедрения в продукт. Таким образом, главным предметом методологии Scrum являются бэклоги и сам продукт. Scrum довольно прост для внедрения и это позволяет применять его многим командам, которые уже перешли на Agile.
Но не обошлось и без минусов, даже скорее ошибок, которые могут быть допущены при работе в условиях Scrum:
Вдобавок, стоит учитывать, что Scrum был создан для разработки продуктов с высоким уровнем неопределенности. Он хорошо работает в случаях, когда нам нужны частые релизы для получения обратной связи от рынка. В ситуации, когда мы имеем детально прописанные требования, не оставляющие простора для творчества, или же когда обратная связь от заказчика/пользователей нам не нужна, Scrum лишь тратит время команды на встречи, не имеющие большой ценности для разработки продукта.
Сегодня, как никогда, важно быстро реагировать на все возможности, предоставляемые рынком. Команде необходимо анализировать рынок, новостное поле, генерировать идеи. Рутина и неэффективные процессы – главный враг продуктивной работе, именно поэтому философия Agile и ее методологическое ответвление Scrum – ключевые шаги на пути к слаженной и качественной деятельности.