Ситуация. Российский ритейлер запускает SaaS-платформу — продакт-менеджер презентует своё видение разработки и предлагает применять Agile, также как делают 90% ИТ-компаний и до 83% бизнесов из других отраслей, в том числе ВТБ, Сбер, Apple и Cisco. ИТ-директор не согласен — он считает, что модный Agile не подходит, у компании нет необходимости, культуры гибкости и времени переучивать сотрудников. Он предлагает скрещивать подходы, оставляя линейность процессов Waterfall.

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

Этот материал будет полезен для руководителей цифровых направлений и продакт-менеджеров, которые выбирают подход к созданию продукта для своей инхаус-команды. Для тех, кто может внести изменения, пока разработка не началась. В статье рассказываем, почему выбор модели для создания IT-продукта — стратегическое решение, почти «точка невозврата». Она поможет разобраться, как выбрать модель разработки ПО, чтобы сократить time-to-market, сохранить гибкость и соблюсти все требования к проекту.

Что такое методологии разработки

Методологии разработки программного обеспечения (ПО) — структурированные подходы, которые помогают организовать процесс создания приложений.

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

«На разных проектах подходят свои методологии: для небольших проектов до полугода — гибкий Agile, для срочных — RAD, для проектов с чётким ТЗ — Waterfall. Нет методологии „для всех“, и важно сразу определить, какая из них „для вас“. На выбор методологии влияют процессы внутри компании. Какой бы срочный ни был проект, не всем подойдет методология для быстрой разработки.

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

Юлия Давыдова, Главный руководитель проектов и процессов разработки в Surf

Зачем погружаться в методологии разработки перед началом проекта

Три основных повода освежить знания о методологии разработки ПО перед началом проекта:

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

2. Узнать, какие методологии точно не подойдут на вашем проекте. Например, если есть всего три месяца до запуска, скорее всего, команда не успеет создать и протестировать прототип. Зато может настроить процессы по Scrum или RAD.

3. Выбрать комфортный уровень вовлечённости. Важно понять, как вам будет удобно вести проект. Можно выбрать методологию, где владелец продукта подключается к процессам и даёт обратную связь каждые 2 недели. А можно такую, где нужно будет оценить только основные этапы: проект, дизайн, кликабельный прототип и готовый продукт.

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

На что обратить внимание при выборе методологии

Факторы, которые стоит учесть при выборе модели разработки ПО, можно разделить на очевидные и неочевидные.

Базовые факторы

Масштаб проекта. Разработка приложения соцсети как MAIN с обновлениями на основе фидбека от пользователей лучше строится с гибкими методологиями разработки, а разработка ДБО для крупного банка требует линейной методологии.

Тип проекта. Методологии для продуктового исследования, анализа конкурентов и аудита кода отличаются от тех, с которыми удобно проводить редизайн системы или разработку фронтенда и бэкенда с нуля.

Размер команды. Команды из 30+ сотрудников, где важно чёткое разделение ролей, лучше работают со структурированными методами. Маленькие команды, в которых люди давно работают совместно, предпочитают гибкие методологии.

Бюджет. Имеет значение тип контракта. Если вы ставите задачи последовательно и регулярно и фиксируете оплату за услуги разработчиков, подойдёт Waterfall. Если задачи меняются или появляются нерегулярно, лучше оплачивать работу по модели Time & Material и выбрать модели Scrum и Kanban.

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

Требования. Если требования к продукту меняются и его часто обновляют, нужна гибкость. Если важно следовать пошаговому плану, подойдёт линейный подход. В NASA при разработке ПО для космических аппаратов используют Waterfall, для других проектов — Agile или смешанный подход.

Неочевидные факторы

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

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

Долгосрочная стратегия. Компании, которые работают над продуктами с долгими циклами обновлений и на старте выбирают, например, Lean, через несколько лет сталкиваются с трудностями из-за масштабирования. Здесь важно продумать, что будет с продуктом дальше, и готовы ли вы пройти через полный редизайн системы через 3–5 лет.

Для чего нужны разные модели разработки ПО

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

Agile для гибкости и быстрого внесения изменений

Agile хорош там, где нужна адаптация к изменениям. Это методология разработки для продуктов, которые развиваются динамично, например, маркетплейсов. Agile применяют 9 из 10 разработчиков ПО, а также компании из других секторов.

Пример проекта — приложение магазина

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

Например, в приложении LOVE REPUBLIC наши разработчики внедряли и тестировали умный поиск и фильтры в каталоге.

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

Смесь Agile+Waterfall используется и как методология тестирования — её выбирают 46% российских компаний.

«Компания, которая занимается аутсорс-разработкой, не может следовать полностью гибким методологиям. Наши ключевые метрики — бюджеты, сроки, содержание. Не все типы договоров подходят для этого, и не все заказчики готовы работать полностью по „гибким правилам“, поэтому мы тоже используем гибрид.»

Юлия Давыдова, Главный руководитель проектов и процессов разработки в Surf

Scrum для комфорта сплоченных команд, готовых к адаптации

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

Пример проекта — веб-клиент для платёжной системы

Например, Scrum или похожий подвид Agile подойдёт, если нужно разработать веб-клиент для платёжной системы за 4 месяца, два из которых направлены на проектирования MVP, а ещё два — на доработку всей функциональности сервиса.

Однако в реальности возникают сложности с распределением ролей и выполнением спринтов в срок, если проект постоянно претерпевает изменения.

Waterfall для линейных проектов с чётким ТЗ

Ступенчатый или пошаговый метод разработки ПО — Waterfall (водопадная или каскадная модель). Используется там, и где процесс, и результат должны быть детально продуманы заранее. Например, при проектировании ПО для госучреждений.

Пример проекта — система учёта налогов по НК РФ

Представим проект по разработке системы учёта налогов. Каждая стадия должна быть завершена до начала следующей: от анализа требований до тестирования и внедрения. При этом всё должно быть подробно задокументировано согласно ГОСТ. Waterfall поможет соблюсти сроки и проконтролировать все этапы, но вносить изменения быстро не получится.

Попытки идти путём «среднего игрока рынка» и использовать только Waterfall не подходят стартапам, малым инновационным предприятиям и некоторым крупным компаниям вроде Google и Яндекс, которые запускают рискованные проекты. Структура блокирует вариативность в бизнесе.

Lean для уменьшения количества задач и оптимизации кода

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

Пример проекта — оцифровка документооборота за месяц

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

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

Prototype model для проверки гипотез и визуализации будущих результатов

Разработчики создают предварительную версию продукта для проверки гипотез. Они показывают прототип продакт-менеджеру, пользователям в рамках А/В-тестирования и другим командам, чтобы получить обратную связь.

Prototype model подходит, если проверяете жизнеспособность идеи до инвестирования ресурсов. А ещё она нужна на проектах с высоким уровнем неопределённости и 50+ функциональностями в бэклоге, потому что помогает визуализировать будущее решение и уточнить требования.

Пример проекта — создание супераппа

Прототипирование используют на проектах, где нужны кликабельные черновые дизайны, модели и внутренние кастомные сервисы. Например, при создании супераппов как AliPay, WeChat и Т-банк.

Но Prototype model — не лучший подход, если утверждение прототипа на каждом этапе жизненного цикла ПО задержит релиз. Когда глава IT-департамента не планирует подключаться к согласованию деталей и вникать в логику каждого экрана, прототипы только замедлят time-to-market.

Команда дизайнеров Surf создаёт кликабельные прототипы, чтобы утвердить дизайн-концепцию, но наши разработчики не используют эту методологию в разработке приложений, чтобы не задерживать релизы.

Rapid App Development для запуска продукта в кратчайшие сроки

Когда скорость выпуска продукта критична, обратите внимание на метод разработки RAD и его производные. Rapid Application Development — итеративный подход, включающий создание рабочих прототипов. В RAD важнее скорость, а не следование плану.

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

Как провести анализ потребностей бизнеса перед выбором модели

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

Провести SWOT-анализ

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

Сформулировать цели проекта

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

Пример № 1: проблема — бумажный документооборот в сети ресторанов затрудняет контроль над выполнением KPI и учет времени сотрудников. Цель бизнеса — в течение года разработать и внедрить ERP-систему как у KFC, которая позволит менеджерам экономить 10 рабочих часов в неделю за счёт автоматизации.

Пример № 2: проблема — чтобы наращивать клиентскую базу и повышать конкурентоспособность, компании из сферы фармритейла нужен новый способ онлайн-продаж. Цель — за пять месяцев разработать кроссплатформенные приложения для аптеки и запустить мобильный канал продаж.

Как наши команды разрабатывают приложения

Мы работаем в основном по стандарту PMI. Это гибрид Agile и Waterfall. Наша команда предпочитает гибкие методологии разработки, многие церемонии из Scrum и инструменты Kanban. Но мы не следуем им полностью. Можем что-то добавлять и убирать, чтобы подстроиться под условия проекта. Разберём пару примеров.

1. Создаём решения для интернет-магазинов по Scrum и Kanban

На сложных проектах для e-commerce есть две команды: discovery и delivery — аналитики и разработчики. Первая команда работает по Kanban: составляет беклог функциональностей, описывает требования, проводит оценку. В этом подходе нет спринтов. Вместо них — еженедельные дейли с обсуждением прогресса и задачи на Канбан-доске. Команда разработчиков работает по Scrum с двухнедельными спринтами и промежуточными релизами. Они составляют дорожную карту с учетом количества участников, отпусков и праздников, и на основе этого планируют спринты.

2. Разрабатываем приложения для банков по Waterfall

Используем водопадную модель на проектах со строгими бизнес-требованиями, если нужно гарантировать безопасность личных и финансовых данных и соблюдать ФЗ, например, во время разработки банковского ДБО или медтех-приложений. Сначала аналитики определяют ряд задач, потом анализируют требования и оценивают объём работ. Затем формируют документы и проектируют архитектуру системы, а дизайнеры создают визуальные макеты. Следующие этапы — разработка, тестирование и релиз. Работа идёт последовательно, а оплата рассчитывается по фиксированной стоимости услуг.

3. Подстраиваемся под процессы заказчика

Учитываем привычные методы коммуникации, используем клиентские инструменты для управления проектами (например, Jira и Trello) и подготавливаем документацию по утвержденным шаблонам. Чаще всего нам не предлагают изменить подход к разработке, а ждут нашу экспертизу и проверенные процессы.

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

Если хотите оптимизировать рабочие процессы, обновить текущую систему или создать ИТ-продукт с нуля — обратитесь к экспертам Surf. За 13 лет на рынке кастомной разработки мы узнали, как эффективно вести проекты, и можем помочь вашей команде, поделиться экспертизой или взять разработку приложений на себя.