Как продуктовый подход помогает масштабировать ИТ-компанию.Часть II. Как строится производство, сфокусированное на продуктовую разработку.

Как продуктовый подход помогает масштабировать ИТ-компанию.Часть II. Как строится производство, сфокусированное на продуктовую разработку.

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

Дизайн

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

Как продуктовый подход помогает масштабировать ИТ-компанию.Часть II. Как строится производство, сфокусированное на продуктовую разработку.

Принципы

  • Центрирование на пользователе. Постановка пользователей в центр нашего анализа и решений
  • Основанность на данных. Использование объективных данных и комбинирование количественных и качественных методов

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

Backend / Архитектура

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

Как продуктовый подход помогает масштабировать ИТ-компанию.Часть II. Как строится производство, сфокусированное на продуктовую разработку.

Что нужно изучить для построения архитектуры

  • Функциональные требования
  1. Анализ требований: четкое понимание того, какие задачи должно решать приложение
  2. Пользовательские сценарии: определение действий пользователей и соответствующих функциональностей
  • Нефункциональные требования
  1. Производительность: скорость работы, время отклика системы
  2. Масштабируемость: возможность системы расти и справляться с увеличением нагрузки
  3. Безопасность: защита данных и предотвращение несанкционированного доступа
  4. Отказоустойчивость: способность системы продолжать работу при возникновении ошибок
  • Предметная область и бизнес-логика
  1. Понимание бизнеса: знания о сфере деятельности, для которой создается приложение
  2. Требования заинтересованных сторон: ожидания клиентов, пользователей и других участников
  • Требования масштабирования
  1. Предполагаемая нагрузка: количество пользователей, объём данных
  2. Планирование на будущее: возможность расширения функциональности
  • Технологический стек
  1. Языки программирования: выбор языка, наиболее подходящего для задачи
  2. Фреймворки и библиотеки: инструменты, ускоряющие разработку
  3. Технологический радар заказчика

Мобильная разработка

Как продуктовый подход помогает масштабировать ИТ-компанию.Часть II. Как строится производство, сфокусированное на продуктовую разработку.

Почему вам подойдет продуктовый подход при разработке мобильных приложений?

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

QA

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

Как продуктовый подход помогает масштабировать ИТ-компанию.Часть II. Как строится производство, сфокусированное на продуктовую разработку.

Принципы

  • QA специалист смотрит на проект широко и комплексно: с позиции пользовательского опыта и бизнес-ценности.
  • Тестовые сценарии строятся с учетом того, как пользователь будет работать с приложением.
  • В условиях сжатых сроков, обязательно проводится работа с рисками.
  • Гибкость. Тестирование подстраивается под текущие потребности продукта.
  • Ранее тестирование — проверка требований и макетов.
  • Глубокое техническое погружение в проект.
  • Активная коммуникация с разработчиками помогает спроектировать необходимые проверки.
  • Работа с пользователями — баги и отзывы помогают улучшать продукт и тест-кейсы.
  • Личные качества и софт-скилы играют важную роль: нужно балансировать, адаптироваться, коммуницировать, предлагать, аргументировать, уточнять и тд.
Как продуктовый подход помогает масштабировать ИТ-компанию.Часть II. Как строится производство, сфокусированное на продуктовую разработку.

Минусы продуктовой разработки

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

Discovery VS Delivery

Для успешной реализации продуктового подхода важно грамотно организовать процесс. В BSL используется система двух параллельных потоков: Discovery (изучение потребностей и проверка гипотез) и Delivery (создание и внедрение решений).

Как продуктовый подход помогает масштабировать ИТ-компанию.Часть II. Как строится производство, сфокусированное на продуктовую разработку.

Однако при таком подходе могут возникать следующие сложности:

  • Рассинхрон между потоками: DISCOVERY движется вперед, тогда как DELIVERY не успевает за ним.
  • Работа команды в изоляции, что приводит к избыточной проработке технических деталей. Это похоже на попытку построить мост там, где достаточно было просто переплыть реку на лодке.

В BSL применяется иерархическая матричная модель с акцентом на отраслевую экспертизу внутри команд. Это означает, что у нас сформирован ресурсный пул, включающий фронтенд, бэкенд и другие направления, которые объединяются с отраслевыми знаниями для формирования специализированной команды. Такая команда выделяется под клиента, чтобы оперативно и эффективно решать его задачи, опираясь на глубокую экспертизу.

11
Начать дискуссию