Представьте, что вы строите дом. Вы наняли команду строителей, нарисовали им примерную схему будущего дома, выделили бюджет. Что может пойти не так? Всё, если нет чёткого плана и слаженной работы команды. При таком подходе вы никогда не получите готовый дом и будете терять деньги.

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

Главные этапы разработки ПО

SDLC — это пошаговый процесс создания программного обеспечения, начиная от идеи и заканчивая поддержкой. Обычно в нём шесть основных этапов:

1. Анализ и составление требований к продукту.
2. Проектирование и дизайн.
3. Разработка.
4. Тестирование.
5. Релиз или развёртывание.
6. Поддержка продукта.

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

Бизнес-аналитика и предпроектная подготовка: как понять, что ПО будет приносить прибыль

Аналитика бизнес-ниши и технических требований будущего проекта — критически важный этап разработки IT-продукта. Исследования показывают, что около 70% неудач связаны с недостаточным или некорректным определением требований на начальной стадии.

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

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

1. Подписываем NDA и изучаем имеющуюся документацию — архитектуру приложения или требования к будущему продукту, отчёты и аналитику.
2. Проводим интервью с клиентами или вашей командой и глубже понимаем цели и задачи проекта, чтобы спроектировать нужное аудитории приложение.
3. Проводим брейншторм для генерации идей — от технологий для разработки до выстраивания Customer Journey Map (CJM) клиента в приложении.
4. Исследуем рыночные тренды и аудиторию бизнеса — разбираемся в самых приоритетных тенденциях сферы и главных «болях» пользователей, которые приложение должно закрыть.
5. Определяем состав MVP продукта или новых функциональностей для уже имеющегося решения. Приоритезируем функциональности, а не пытаемся разработать самые популярные решения — это залог работающего на ваш бизнес ПО.

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

Параллельно с этим провели аудит UX/UX-дизайна и выделили бутылочные горлышки в CJM, которые мешают пользователям дойти до целевого действия: проверили 23 пользовательских сценария. Сопоставили прогнозируемый путь пользователя с реальным и перешли к проектированию и этапу разработки IT-продукта с полным пониманием системы.

Проектирование и дизайн: как сделать интерфейс, который помогает пользователям

Дизайнеры разрабатывают пользовательские сценарии и интерфейсы будущего ПО. Затем они создают прототип приложения, который позволяет оценить, насколько решение удобно пользователям.

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

Пример, как это работает. Для провайдера ТВ-каналов «Триколор» спроектировали UX и создали обновлённый UI на основе исследования отзывов пользователей, приложений конкурентов и воркшопа по разработке CJM. Затем провели опрос для 12 жителей Москвы и Краснодара, чтобы проверить, насколько удобнее стало пользоваться подпиской и управлять каналами.

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

Разработка: как уложиться в сроки и потом не переписывать код

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

Пример, как это работает. Мы разработали сразу шесть приложений для трёх брендов сети аптек «Ригла»: Живики, Риглы и Будь Здоров. Так как у компании были ограниченные сроки, мы предложили им использовать кроссплатформенный фреймворк Flutter — это оптимизировало расходы на этап разработки ПО на 40%. Мы написали основу кода один раз для якорного бренда Риглы, а затем переиспользовали 80–95% написанного кода и автоматически делали сборки приложений для дочерних брендов. После этого адаптировали функциональности и UX под особенности каждого бренда.

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

3.1. Проведение код-ревью и снижение технического долга

Важная составляющая часть процесса разработки — проведение код-ревью. Это процесс, когда разработчики проверяют работу друг друга, что помогает улучшить качество кода и в дальнейшем легко масштабировать приложение. Для внесения изменений разработчики отправляют pull requests. Например, мы проводили код-ревью работы другого подрядчика для корпоративного приложения крупного ритейлера. На этом этапе наши эксперты составили рекомендации, которые помогут более тщательно контролировать изменения в коде: предлагать по одному изменению за раз, более подробно разбивать на задачи, привлекать к ревью больше экспертов, ввести практику комментирования по современным стандартам.

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

• Инвентаризация. Проводите анализ кодовой базы, чтобы определить участки с высоким уровнем технического долга. Для этого разработчики используют статические анализаторы кода (например, SonarQube, FindBugs), а также проводят ревью кода с акцентом на потенциальные проблемы.
• Оценка риска. Не весь технический долг одинаково опасен. Разработчики оценивают каждый участок по следующим критериям: насколько велика вероятность возникновения ошибок или проблем из-за этого участка кода? Насколько серьёзны будут последствия возникновения этих ошибок — потеряются ли данные, снизится ли производительности? Сколько времени и ресурсов потребуется для исправления?
• Интеграция в спринты. Выделите определённое время в каждом спринте для работы над техническим долгом. Это поможет избежать накопления новых долгов и постепенно снижать существующие. Не нужно выделять весь спринт, достаточно 20–30%.

Иногда принятие технического долга является оправданным решением. Ключ — в осознанном принятии этого решения, его документировании и последующем планировании его устранения.

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

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

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

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

Тестирование: как снизить количество ошибок перед релизом ПО

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

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

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

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

Релиз и поддержка: как добиться стабильной работы ПО

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

Пример, как это работает. Поддержка может осуществляться как in-house специалистами, так и внешней командой, которая писала код. В первом случае, мы в Surf всегда предоставляем детальную документацию всех аспектов проекта, чтобы обеспечить бесшовную передачу новой команде, а во втором — предлагаем услугу SLA-поддержки по сопровождению приложения после запуска. Вы получаете:

• Ежемесячные отчёты по количеству возникших ошибок в разных модулях и функциональностях.
• Анализ ключевых показателей работы приложения и оперативную реакцию на изменения в них.
• Рекомендации по оптимизации интерфейсов и проведению рефакторинга.

Чек-лист: как оптимизировать этапы разработки ПО

Эффективное управление сроками каждого из этапов разработки софта помогает уложиться в бюджет и добиться более высокого качества конечного продукта. Мы собрали проверенные технологии и процессы для оптимизации процесса разработки ПО.

Используйте предпроектное исследование, чтобы понять, насколько востребовано ваше ПО. Для этого изучайте конкурентов, тренды в вашей сфере, проводите исследования CJM пользователей и внедряйте опросы.

Изучайте тренды в UX/UI-дизайне. Проектируйте ПО так, чтобы оно было максимально удобно пользователю. Будьте готовы анализировать работу интерфейса и логику вашего продукта, чтобы замечать сложности и быстро исправлять ошибки.

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

Автоматизируйте тестирование. Использование инструментов для автоматизации тестирования в два раза снижает время, которое требуется для покрытия приложения тестами на должном уровне. Это позволяет команде сосредоточиться на решении наиболее сложных задач.
Обеспечивайте поддержку. После релиза важно отслеживать работу ПО, в том числе основные метрики. Для этого настраивайте процессы и работу вашей команды для выявления ошибок и трудностей пользователей и постоянно улучшайте работу продукта.

Сотрудничайте с опытной командой. Выбор в пользу команды со специалистами, которые имеют опыт разработки схожих проектов в релевантной бизнес-нише, позволяет добиться более эффективного Time to Market проекта при высоком качестве. Такие специалисты обладают глубокими знаниями и навыками, что позволяет им быстрее решать задачи, избегать распространённых ошибок и эффективно применять лучшие практики. Опыт способствует более точному планированию, быстрому выявлению и устранению проблем, а также повышает качество кода, что сокращает время на разработку ПО и его тестирование.

Наша команда с 2011 года успешно разрабатывает мобильные приложения под ключ, специализируясь на фудтехе, финтехе и ecommerce. Среди наших клиентов: KFC, Burger King, Росбанк и LOVE REPUBLIC. По версии Рейтинга Рунета 2024 мы на первом месте среди мобильных разработчиков для крупного бизнеса.

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