Разработка может опираться на разные подходы, и самым эффективным из них на сегодняшний момент принято считать продуктовый. О его особенностях и преимуществах перед “оппонентом” — проектным методом — расскажем в нашей статье.
Если вы предприниматель, планируете запустить онлайн-бизнес и находитесь в поиске команды разработчиков, ответьте себе на вопрос: чего вы ждете от работы специалистов и какова должна быть степень их “погружения” в ваш проект. Нужен ответственный исполнитель? Или технологический драйвер, который будет планировать, создавать и развивать интернет-магазин вместе с вами?
В первом случае ищите IT-компанию с проектным подходом, во втором — с продуктовым. Оба варианта имеют право на существование, но разница между ними огромна.
Чем продуктовый подход отличается от проектного
Начнем с того, что и проектный и продуктовый подходы — это МЕТОДЫ работы над созданием и развитием e-Commerce проекта. У них разные инструменты, понимание “эффективности” и способы оценки результатов, но в первую очередь — цели и философия.
Проектный подход
Давайте разбираться на примере? У предпринимателя “N” появилась уникальная, как ему кажется, идея. Он решает запустить интернет-магазин, пишет техническое задание (возможно, при помощи профильных специалистов), передает его в IT-компанию с проектным подходом к разработке.
Миссия организации в данном случае — действовать по ТЗ и реализовать поставленные задачи в рамках согласованных сроков и бюджета. Руководитель детально прописывает план, подбирает команду, а менеджер проекта следит за ходом выполнения работ, чтобы успешно сдать их ко дню “Х”.
Сами сотрудники при этом одновременно трудятся на нескольких проектах, а в нужный момент подключаются к решению задач того или иного заказчика. Примерно через полгода (средняя продолжительность разработки при проектном подходе) интернет-магазин выходит в релиз. Кажется, все идеально, если бы не одно “но”. Клиент действительно получит проект, на 100% соответствующий ТЗ. Но будет ли он отвечать реалиям изменившегося рынка и покупательского поведения — большой вопрос. Как и то, насколько уникальной и жизнеспособной на практике окажется бизнес-идея самого “N”.
Продуктовый подход
Идея продуктового подхода — ориентация не на ТЗ, а на потребности собственника интернет-магазина и его будущих покупателей.
Давайте вернемся к нашему предпринимателю и представим, что теперь он приходит в компанию с продуктовым подходом. Первым делом эксперты зададут ему 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-команду образуют:
- владелец продукта,
- команда разработчиков,
- scrum-мастер.
Владелец продукта отвечает за формирование общего списка задач по проекту и определение их приоритетности.
Команда разработчиков (это не только разработчики, но и маркетологи, верстальщики и иные специалисты) реализовывает задачи, а также осуществляет поддержку и развитие проекта.
Scrum-мастер играет роль наставника и “парламентера”. Его задача — быстро устранять возникающие препятствия и споры в Scrum-команде, обучать новичков основам Scrum-подхода, обеспечивать максимальную продуктивность команды.
5 событий
Среди событий Scrum следующие:
- Формирование и обновление задач в бэклоге.
- Планирование спринта и объема работ, которые будут взяты на выполнение.
- Стендапы — короткие ежедневные совещание, где команда подводит итоги выполненных работ за вчера, обменивается мнениями, уточняет неясные моменты, ставит планы на текущий день.
- Обзор итогов спринта — мероприятие, на котором команда разработчиков изучает и демонстрирует результаты проведенной работы, а владелец продукта обновляет бэклог, что может стать отправной точкой для планирования следующего спринта.
- Ретроспектива — мероприятие, предназначенное для обзора завершённых этапов. Команда записывает результаты, обсуждает, что получилось, а над чем нужно еще работать.
Все перечисленные события должны пройти в течение одного спринта, при этом менять его продолжительность нельзя.
3 артефакта
Артефакты — это работы, которые надо сделать, чтобы считать спринт завершенным. Среди них:
- Обновление бэклога продукта. После каждого спринта владелец проекта актуализирует список задач проекта.
- Реализация задач из бэклога спринта. К концу итерации вся работа, запланированная на спринт, должна быть сделана.
- Инкремент — цель спринта. Она должна быть достигнута, а её готовность оценена по критериям, которые устанавливаются в начале спринта.
6. DevSecOps
DevSecOps — это комбо из development, security и operations (разработка, безопасность и операции). Так называется подход в IT-разработке, подразумевающий интеграцию мер безопасности в каждый этап разработки ПО.
Основная идея DevSecOps заключается в том, чтобы включить безопасность в культуру и рабочие процессы разработчиков. Вместо того чтобы рассматривать безопасность как отдельный этап или ответственность отдельных специалистов, она становится неотъемлемой частью работы всей команды.
Андрей Мягков, технический директор Simtech Development, резюмирует:
— Продуктовый подход — это про достижение больших целей маленькими шагами. Он позволяет заказчику и разработчикам концентрироваться на полезности любого действия: расставлять приоритеты, отказываться от ненужных задач или усложнений. Результат продуктового подхода — e-Com-продукт, который несет реальную ценность для клиента и его бизнеса с минимальными рисками и оправданными затратами.
Итоги
В мире IT-разработки существует 2 разных подхода к созданию интернет-магазина: проектный и продуктовый. Первый фокусируется на реализации поставленных клиентом задач в оговоренные сроки и в рамках утвержденной сметы. Второй ориентируется на бизнес-стратегию клиента, потребности аудитории и поддержку IT-продукта в течение всего жизненного цикла.
Компания Simtech Development ведет разработку интернет-магазинов и маркетплейсов на базе продуктового подхода. Это наиболее безопасный и эффективный способ инвестирования в онлайн-бизнес, где каждый шаг и действие основывается на предварительном тестировании и последующей адаптации сайта электронной коммерции к условиям открытого рынка. Если вы ищете IT-компанию, которая поможет:
- разработать интернет-магазин;
- создать маркетплейс;
- запустить MVP,
Мы подберем квалифицированную продуктовую команду, поможем создать e-Com-проект “с нуля” и обеспечим ему устойчивое развитие, чтобы вы могли масштабировать цифровые продажи и быть на шаг впереди конкурентов.
