Как построить дилерскую сеть с помощью кастомных IT-решений
Получить руководство
Simtech Development

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

Сфера IT — уникальная отрасль, где одну и ту же задачу можно решать по-разному. Даже такую сложную, как запуск интернет-магазина или маркетплейса.

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

Если вы предприниматель, планируете запустить онлайн-бизнес и находитесь в поиске команды разработчиков, ответьте себе на вопрос: чего вы ждете от работы специалистов и какова должна быть степень их “погружения” в ваш проект. Нужен ответственный исполнитель? Или технологический драйвер, который будет планировать, создавать и развивать интернет-магазин вместе с вами?
В первом случае ищите 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

Использование 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

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

Страница в Confluence

Страница в 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-манифеста

В 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 заключается в том, чтобы включить безопасность в культуру и рабочие процессы разработчиков. Вместо того чтобы рассматривать безопасность как отдельный этап или ответственность отдельных специалистов, она становится неотъемлемой частью работы всей команды.

Схема DevSecOps

Андрей Мягков, технический директор Simtech Development, резюмирует:

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

Итоги

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

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

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

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

Отправить заявку

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

Спасибо, мы получили ваш запрос и скоро ответим на него

Спасибо за обращение!
Мы свяжемся с вами в течение 1 часа в рабочее время