Обложка статьи «Продуктовая разработка. О чём не рассказывают на собеседованиях»

Продуктовая разработка. О чём не рассказывают на собеседованиях

Михаил Щекотов

Михаил Щекотов, архитектор CS-Cart

Вместо предисловия

Часто слышу от начинающих разработчиков про муки выбора компании-работодателя: продуктовая компания vs аутсорс-компания, занимающаяся заказной разработкой. Конечно, каждый случай уникален; всё зависит от того, чего вы ожидаете и хотите от своей работы, какими качествами и скиллами обладаете.

Для начала пару слов о том, что такое продуктовая разработка

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

Этапы разработки нового продукта:

идея → разработка → альфа/бета  → продукт

Этапы разработки в существующем продукте (на примере  CS-Cart):

бизнес-требование → прототип → демки/фидбек → фича

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

Если вы придёте на собеседование в продуктовую компанию или загуглите «преимущества работы в продуктовой компании», то, скорее всего, услышите / прочитаете это:

  • большой продукт, X лет на рынке;
  • никаких ТЗ от заказчика;
  • работаем по спринтам, никаких «срочно» и «сейчас»;
  • менеджеров нет, можно спокойно программировать.

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

Я не буду сравнивать особенности работы в разных типах компаний, поделюсь своим опытом работы в продуктовой компании.

Продуктовая разработка = развитие клиента (customer development), а не развитие продукта

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

В рамках этого подхода есть 4 важных этапа:

  • Поиск — Что за задача у клиента?
  • Подтверждение — Как мы можем решить эту задачу? Можем ли мы продать решение?
  • Создание — Можем ли мы продать решение многократно?
  • Рост — Как масштабировать бизнес?

Таким образом, продуктовая разработка находится где-то на стыке поиска, подтверждения и создания.

Продуктовая разработка = работа внутри команды

Всех сотрудников объединяет общая цель — совершенствование продукта, не получится работать изолированно. Если мы говорим не про стартап, то как правило, в продуктовых компаниях команда самоорганизована: обладает компетенциями, принимает решения, анализирует задачи и выдвигает гипотезы, разрабатывает и тестирует решения. В команде идёт непрерывный обмен знаниями и компетенциями, развитие и обучение каждого сотрудника.

Продуктовая разработка = аналитика и гипотезы

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

Мы много общаемся и в процессе диалогов пытаемся ответить на важные вопросы. Например:

  • Какова задача клиента?
  • Решена ли эта задача в других продуктах?
  • Как она решена у других?
  • Как ее можно решить у нас?

Продуктовая разработка = прототипы и фидбек

Чтобы понять насколько наши идеи жизнеспособны и будут ли они востребованы среди клиентов, нужно делать прототипы. Чтобы проверить гипотезу перед выкаткой фичи в продукт, мы используем MVP (minimum viable product) — «минимальный рабочий продукт». Он даёт пример решения задачи клиента, но не покрывает крайние случаи. Основная задача MVP — получение обратной связи для оценки и принятия решения. Нужно быть готовым к тому, что ряд прототипов по результатам собранного фидбека придётся выкинуть и полностью переработать. Это нормальный процесс.

Продуктовая разработка = обязательства

При этом обязательства возникают сразу по нескольким направлениям:

  • перед клиентами: мы доставим фичи;
  • перед разработчиками: мы не сломаем обратную совместимость.

Продуктовая разработка = стандарты индустрии

Фичи:

  • Как эта задача решена в других продуктах?
  • Работает ли это решение?

Разработка:

  • Какие стандарты кодирования мы можем использовать, чтобы сделать наш код понятным всему сообществу разработчиков?
  • Какие готовые популярные библиотеки мы можем использовать, чтобы не изобретать велосипеды?
  • Как рефакторить устаревающий код?

Тестирование:

  • Какие подходы к тестированию позволяют сократить количество ошибок?

Интерфейсы:

  • Какие подходы используются в создании интерфейсов?
  • Какие UI kit’ы решают эту задачу?

Инфраструктура:

  • Как сейчас выпускают и разворачивают проекты?
  • Как организовать мониторинг доступности и производительности?

Знать ответы на эти вопросы и следовать индустриальным стандартам — значит сохранять актуальность в комьюнити разработчиков.

Продуктовая разработка = ответственность

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

Рекомендации для начинающих программистов:

  1. Книга C. Макконнелл «Совершенный код». Талмуд в тысячу страниц. Несмотря на название, не весь про программирование. Содержит полезные советы по анализу требований и проектированию архитектуры.
  2. Н. Виноградова «Самые лучшие уроки рисования для смелых и любознательных». Когда я учился в универе, декан советовал нам смотреть мультики и больше рисовать, чтобы стать хорошими программистами. Мы тогда улыбались, но сейчас я разделяю эту мысль. Инструментов для проектирования систем много, но самый доступный — лист бумаги и карандаш.
  3. Изучить диаграммы последовательностей UML. При проектировании придется описывать процессы в системе. Диаграммы последовательностей UML — самый наглядный способ описания процессов.
  4. Продукт, который вы хотите пилить или уже пилите, нужно изучать постоянно. Сначала — для понимания, как он работает, чтобы разрабатывать хоть что-то. Потом — для понимания, что он предлагает клиентам. Далее — для понимания, что он может предложить клиентам. Без понимания того, что важно для клиента, а что нет, вы будете тратить время впустую на кажущиеся только вам важными улучшения.