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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Фичи:

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

Разработка:

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

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

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

Интерфейсы:

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

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

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

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

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

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

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

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