Почему продуктовый подход к разработке лучше проектного

Разработка может опираться на разные подходы, и самым эффективным из них на сегодняшний момент принято считать продуктовый. О его особенностях и преимуществах перед “оппонентом” — проектным методом — расскажем в нашей статье.  

Если вы предприниматель, планируете запустить онлайн-бизнес и находитесь в поиске команды разработчиков, ответьте себе на вопрос: чего вы ждете от работы специалистов и какова должна быть степень их “погружения” в ваш проект. Нужен ответственный исполнитель? Или технологический драйвер, который будет планировать, создавать и развивать интернет-магазин вместе с вами?
В первом случае ищите IT-компанию с проектным подходом, во втором — с продуктовым. Оба варианта имеют право на существование, но разница между ними огромна. 

Чем продуктовый подход в разработке отличается от проектного 

Начнем с того, что и проектный и продуктовый подходы — это МЕТОДЫ работы над созданием и развитием e-Commerce проекта. У них разные инструменты, понимание “эффективности” и способы оценки результатов, но в первую очередь — цели и философия. 

Проектный подход 

Давайте разбираться на примере? У предпринимателя “N” появилась уникальная, как ему кажется, идея. Он решает запустить интернет-магазин, пишет техническое задание (возможно, при помощи профильных специалистов), передает его в IT-компанию с проектным подходом к разработке. 

Миссия организации в данном случае — действовать по ТЗ и реализовать поставленные задачи в рамках согласованных сроков и бюджета. Руководитель детально прописывает план, подбирает команду, а менеджер проекта следит за ходом выполнения работ, чтобы успешно сдать их ко дню “Х”. 

Сами сотрудники при этом одновременно трудятся на нескольких проектах, а в нужный момент подключаются к решению задач того или иного заказчика. Примерно через полгода (средняя продолжительность разработки при проектном подходе) интернет-магазин выходит в релиз. Кажется, все идеально, если бы не одно “но”. Клиент действительно получит проект, на 100% соответствующий ТЗ. Но будет ли он отвечать реалиям изменившегося рынка и покупательского поведения — большой вопрос. Как и то, насколько уникальной и жизнеспособной на практике окажется бизнес-идея самого “N”.

Продуктовый подход

Идея продуктового подхода — ориентация не на ТЗ, а на потребности собственника интернет-магазина и его будущих покупателей. 

Давайте вернемся к нашему предпринимателю и представим, что теперь он приходит в компанию с продуктовым подходом. Первым делом эксперты зададут ему 3 вопроса:

1. какие цели и задачи у бизнеса?
2. какие проблемы есть у потребителей и как их можно решить? 
3. на чем будет зарабатывать магазин? 

Далее специалисты будут двигаться по следующему плану: 

• проанализируют рынок, определят потребности целевой аудитории и предложения конкурентов,
• сформируют гипотезы, проведут эксперименты, чтобы отмести нерабочие схемы,
• проработают пользовательские сценарии на сайте,
• подготовят детальное ТЗ с функциональными и бизнес-требованиями,
• определят необходимый стек технологий,
• сформируют продуктовую команду,
• помогут найти оптимальные модели монетизации бизнеса,
• через 2-3 месяца запустят первую минимально жизнеспособную версию интернет-магазина или онлайн-гипермаркета (MVP),
• внесут изменения в e-Com-продукт согласно обратной связи от пользователей,
• будут постоянно улучшать функционал магазина, чтобы он оперативно адаптировался под меняющуюся бизнес-среду.  

Продуктовый подход означает, что команда, работающая над созданием интернет-магазина или маркетплейса, — это не просто исполнители. Это технологические партнеры, которые подключаются к проекту на стадии обсуждения идеи клиента. В дальнейшем они будут проверять её на практике, подбирать оптимальную экономическую модель, составлять дорожную карту развития IT-продукта. Разработчики будут сосредоточены исключительно на одном клиентском проекте и погрузятся в него “с головой”.

Интересно, что еще пару лет назад российское бизнес-сообщество было не готово к такому подходу. Владельцы e-Com-проектов просто приходили в IТ-компанию с определенным запросом, и разработчики его “отрабатывали”. Сегодня конкуренция в онлайн-среде усиливается, ожидания покупателей растут, а сами магазины усложняются. К предпринимателям приходит понимание: вместо того, чтобы каждый раз обращаться к разработчикам за решением того или иного вопроса, эффективнее полностью передать в их руки техническое управление сайтом электронной коммерции. В этом контексте продуктовое программирование становится неотъемлемой частью успешной стратегии развития бизнеса в сфере e-commerce.

Преимущества проектного подхода

У проектного подхода есть множество плюсов, которые отличают его от проектного метода. Перечислим основные.

Теперь рассмотрим их более подробно

1. Фокус на ценности продукта и потребностях бизнеса

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

2. Забота о пользователях 

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

3. Проверка бизнес-гипотезы 

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

Реальный опыт и отзывы покупателей подскажут, стоит ли развивать бизнес дальше. Может, нужно скорректировать стратегию или признать, что гипотеза оказалась ошибочной и работу стоит прекратить (да, так бывает, и это лучше, чем вкладывать средства в заранее обреченный проект). Стоимость MVP, к слову, составляет 10-30% от суммы полной разработки, поэтому даже при мрачном стечении обстоятельств бОльшую часть своих средств предприниматель сохранит. А еще сэкономит массу времени, нервов и ресурсов. 

4. Высокая скорость запуска e-Commerce-проекта 

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

5. Непрерывное улучшение 

Продуктовый подход предполагает постоянную проверку интернет-магазина “в бою”. Выпустили релиз, собрали обратную связь, исправили ошибки и пошли дальше — “конвейер обновлений”, как говорят в среде разработчиков.
Почти 20-летняя практика Simtech Development на глобальном e-Com-рынке говорит о том, что после запуска MVP проект активно меняется еще в течение года: обновляется контент, функционал, товарные линейки. В случае продуктового подхода команда нон-стоп изучает альтернативные решения, пользовательские сценарии, а поняв, как улучшить продукт, выпускает новый релиз. 

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

Вполне логично, что продуктовый подход в разработке влияет и на сам процесс создании IT-продуктов. Хотите, расскажем более подробно? Без специальных терминов и сленга здесь не обойтись, но не пугайтесь, мы все аккуратно разложим “по полочкам”.   

1. Инженерная культура и практики CI/CD

Инженерная культура в среде разработчиков — важное явление. Это система ценностей, знаний, навыков, этических убеждений технических специалистов. Их окружение и атмосфера, где они по-своему творят: решают сложные задачи, включают аналитическое и креативное мышление, обмениваются идеями, в том числе, как создать и улучшить качество IT-продукта клиента. 
CI (Continuous Integration, “непрерывная интеграция”) — это регулярное объединение кода разработчиков в общий репозиторий (виртуальное хранилище). Что здесь имеется в виду: с кодом ведь работает не один, а множество человек. Одни “дописывают”, другие “переписывают”, третьи корректируют и так далее. Чтобы произошло слияние всех изменений, код отправляют в репозиторий. Там он заново компилируется, собирается и в дальнейшем тестируется.
CD (Continuous Deployment, “непрерывное развертывание”) — практика автоматической доставки  e-Com-проекта в продакшн (на клиентские сервера). CD автоматизирует процесс развертывания и обновления интернет-магазина, а также позволяет быстро внедрять новый функционал, исправлять ошибки и вносить изменения на сайт клиента.
Подход CI/CD — это цикличный процесс, где один этап переходит в другой: кодируем, собираем, проверяем, выпускаем релиз, разворачиваем на серверах, анализируем поведение покупателей, делаем выводы и составляем план по улучшению онлайн-магазина. А далее все повторяется снова.

Подход CI/CD

Использование CI/CD даёт команде большое количество преимуществ. Разработчики могут быстро тестировать новые идеи и внедрять их на проект раньше конкурентов заказчика. При этом качество кода будет с каждым новым циклом улучшаться, а скорость обновлений увеличится. Появится также возможность быстро получать фидбэк от пользователей и отсортировывать невостребованный ими функционал от реально необходимого. 

2. Статический анализ кода и код-ревью

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

Статистический анализ кода

Что это такое? Это выявление недочетов, ошибок и потенциальных уязвимостей в исходном коде ещё до его запуска. Такую работу проводят с помощью специальных программ и инструментов (SonarQube, ESLint, Pylint, Checkstyle, FindBugs, Coverity), а разработчики тем временем видят на экранах предупреждения, что код, скорее всего, содержит ошибку. 

Предупреждение об ошибке в коде

Тем не менее, статический анализ показывает только распространенные ошибки в коде (стилистические, синтаксические, логические) и потому его используют как дополнение к код-ревью. 

Code Review 

Code Review — это процесс проверки кода разработчиком перед релизом. Он выполняется не “автором” кода, а другими членами команды, чтобы выявить ошибки и потенциальные проблемы. В ходе Code Review могут быть предложены правки и рекомендации для улучшения качества ПО. Помимо прочего, Code Review помогает повысить читаемость и качество кода и — как следствие — облегчить его поддержку в будущем, ведь он становится понятен не одному, а нескольким участникам команды. 

3. Автотестирование 

Чтобы обеспечить e-Com-проекту высокое качество и работоспособность, разработчики и QA-инженеры постоянно проверяют его функционал. Делать это вручную крайне трудозатратно и долго. Поэтому продуктовая команда пишет автотесты, которые будут выполняться с помощью специальных скриптов, сценариев или программных инструментов.
Автотесты запускаются множество раз и помогают удостовериться, что изменения в коде не привели к появлению новых ошибок и не повлияли на функциональность уже протестированных компонентов.

Прогон автотестов

Автотесты могут быть разными: 

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

Комбинация различных видов тестирования помогает разработчикам обеспечить клиенту высокое качество e-Com-проекта и его устойчивость к различным условиям эксплуатации.

4. Работа с итерациями и бэклогом 

Как работает продуктовая команда? Для начала формирует бэклог — общий список задач и функциональностей, которые должны быть реализованы в процессе создания интернет-магазина или маркетплейса. Конечно, их получается очень много. Но разработчики не стремятся реализовать их все сразу, наоборот — разбивают на этапы (спринты или итерации), каждый из которых будет иметь свои цели и задачи. 

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

Платформы для совместной работы команды над проектом

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

Задачи бэклога заводятся в таск-трекер (их много: Teamwork, Trello, ActiveCollab, Wrike, Jira и другие). Он позволяет прозрачно управлять проектом: определять приоритеты, назначать ответственных, отслеживать прогресс и добавлять комментарии. Jira предоставляет также возможность планировать итерации (спринты), а также отслеживать время и ресурсы, затраченные на выполнение работ. 

Список задач в Jira

Jira также хорошо интегрируется с другими инструментами разработки, такими, например, как Bitbucket (система контроля версий) или Confluence (система управления знаниями).
К слову, Confluence в IT-компаниях — одно из любимых приложений. Система позволяет консолидировать большие объемы информации в одном месте (это может быть база знаний по проекту, документация, отчетность). Пользователи могут создавать и редактировать страницы, использовать в работе тексты, таблицы, графики, изображения, куски кода и другие мультимедийные элементы. 

Страница в Confluence

5. Definition of Ready (DoR) и Definition of Done (DoD)

Термины Definition of Ready (DoR) и Definition of Done (DoD) в переводе c английского означают “определение готовности” и “определение завершенности”. Это своеобразные маркеры, указывающие на то, что задача может быть взята в спринт (DoR), а позже считаться выполненной (DoD).

Например, перед нами стоит задание «Создать страницу авторизации». Согласно DoR, задача должна содержать:

• Ясное описание: требования к функциональности, примеры пользовательского интерфейса.
• Критерий приемки (их может быть и несколько). В случае с нашей задачей он может звучать так: “пользователь может успешно войти в систему под своими учетными данными”.
• Необходимые ресурсы: разработчикам должны быть представлены дизайнерские макеты, доступ к базе данных и необходимые разрешения для создания страницы авторизации.
• Указание на зависимости и связи: если задача «Создать страницу авторизации» зависит от задачи «Настроить аутентификацию», то последняя должна быть выполнена раньше.

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

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

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

6. Работа по методологии Agile и Scrum

Agile — это целая философия управления проектами. Её ценности были сформулированы инициативной группой из 17 программистов (Agile Alliance) и отражены в манифесте 2001 года.

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

3 роли

Scrum-команду образуют:

1. владелец продукта,
2. команда разработчиков,
3. scrum-мастер.

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

Команда разработчиков (это не только разработчики, но и маркетологи, верстальщики и иные специалисты) реализовывает задачи, а также осуществляет поддержку и развитие проекта.  
Scrum-мастер играет роль наставника и “парламентера”. Его задача — быстро устранять возникающие препятствия и споры в Scrum-команде, обучать новичков основам Scrum-подхода, обеспечивать максимальную продуктивность команды. 

5 событий

Среди событий Scrum следующие: 

1. Формирование и обновление задач в бэклоге. 
2. Планирование спринта и объема работ, которые будут взяты на выполнение.
3. Стендапы — короткие ежедневные совещание, где команда подводит итоги выполненных работ за вчера, обменивается мнениями, уточняет неясные моменты, ставит планы на текущий день.
4. Обзор итогов спринта — мероприятие, на котором команда разработчиков изучает и демонстрирует результаты проведенной работы, а владелец продукта обновляет бэклог, что может стать отправной точкой для планирования следующего спринта.
5. Ретроспектива — мероприятие, предназначенное для обзора завершённых этапов. Команда записывает результаты, обсуждает, что получилось, а над чем нужно еще работать. 

Все перечисленные события должны пройти в течение одного спринта, при этом менять его продолжительность нельзя. 

3 артефакта

Артефакты — это работы, которые надо сделать, чтобы считать спринт завершенным. Среди них:

1. Обновление бэклога продукта. После каждого спринта владелец проекта актуализирует список задач проекта.
2. Реализация задач из бэклога спринта. К концу итерации вся работа, запланированная на спринт, должна быть сделана.
3. Инкремент — цель спринта. Она должна быть достигнута, а её готовность оценена по критериям, которые устанавливаются в начале спринта. 

6. DevSecOps

DevSecOps — это комбо из development, security и operations (разработка, безопасность и операции). Так называется подход в IT-разработке, подразумевающий интеграцию мер безопасности в каждый этап разработки ПО. 

Основная идея DevSecOps заключается в том, чтобы включить безопасность в культуру и рабочие процессы разработчиков. Вместо того чтобы рассматривать безопасность как отдельный этап или ответственность отдельных специалистов, она становится неотъемлемой частью работы всей команды.

Итоги

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

Компания Simtech Development ведет разработку интернет-магазинов и маркетплейсов на базе продуктового подхода. Это наиболее безопасный и эффективный способ инвестирования в онлайн-бизнес, где каждый шаг и действие основывается на предварительном тестировании и последующей адаптации сайта электронной коммерции к условиям открытого рынка. Если вы ищете IT-компанию, которая поможет:

• разработать интернет-магазин;
• создать маркетплейс;
• запустить MVP,

Мы подберем квалифицированную продуктовую команду, поможем создать e-Com-проект “с нуля” и обеспечим ему устойчивое развитие, чтобы вы могли масштабировать цифровые продажи и быть на шаг впереди конкурентов.