Продуктовая разработка. О чём не рассказывают на собеседованиях
Рассказ опытного разработчика, который может помочь по-другому взглянуть на работу в софтверной компании.
16К открытий17К показов
Михаил Щекотов
архитектор CS-Cart
Вместо предисловия
Часто слышу от начинающих разработчиков про муки выбора компании-работодателя: продуктовая компания vs аутсорс-компания, занимающаяся заказной разработкой. Конечно, каждый случай уникален; всё зависит от того, чего вы ожидаете и хотите от своей работы, какими качествами и скиллами обладаете.
Для начала пару слов о том, что такое продуктовая разработка
Продуктовая разработка — разработка продукта, ориентированного на определенную целевую аудиторию. Продуктом может быть всё, что можно продать: сайт, приложение, услуга.
Этапы разработки нового продукта:
идея → разработка → альфа/бета → продукт
Этапы разработки в существующем продукте (на примере CS-Cart):
бизнес-требование → прототип → демки/фидбек → фича
Что рассказывают на собеседованиях в продуктовых компаниях
Если вы придёте на собеседование в продуктовую компанию или загуглите «преимущества работы в продуктовой компании», то, скорее всего, услышите / прочитаете это:
- большой продукт, X лет на рынке;
- никаких ТЗ от заказчика;
- работаем по спринтам, никаких «срочно» и «сейчас»;
- менеджеров нет, можно спокойно программировать.
Из всего этого может сложиться ощущение, что продуктовая разработка — это только кодинг и внедрение. Но это не так.
Я не буду сравнивать особенности работы в разных типах компаний, поделюсь своим опытом работы в продуктовой компании.
Продуктовая разработка = развитие клиента (customer development), а не развитие продукта
Этот подход к построению бизнеса был разработан американским предпринимателем и учёным Стивом Бланком на основе его опыта с десятками стартапов и компаний. Суть подхода: важнейший актив компании — это клиенты, а не продукт; продукт должен решать проблемы покупателей и заключать в себе ценность.
В рамках этого подхода есть 4 важных этапа:
- Поиск — Что за задача у клиента?
- Подтверждение — Как мы можем решить эту задачу? Можем ли мы продать решение?
- Создание — Можем ли мы продать решение многократно?
- Рост — Как масштабировать бизнес?
Таким образом, продуктовая разработка находится где-то на стыке поиска, подтверждения и создания.
Продуктовая разработка = работа внутри команды
Всех сотрудников объединяет общая цель — совершенствование продукта, не получится работать изолированно. Если мы говорим не про стартап, то как правило, в продуктовых компаниях команда самоорганизована: обладает компетенциями, принимает решения, анализирует задачи и выдвигает гипотезы, разрабатывает и тестирует решения. В команде идёт непрерывный обмен знаниями и компетенциями, развитие и обучение каждого сотрудника.
Продуктовая разработка = аналитика и гипотезы
Данный пункт вытекает из 2-х предыдущих. Чтобы повысить ценность продукта, команде нужно активизировать весь ресурс сотрудников для выявления проблем, потребностей клиентов и генерации идей.
Мы много общаемся и в процессе диалогов пытаемся ответить на важные вопросы. Например:
- Какова задача клиента?
- Решена ли эта задача в других продуктах?
- Как она решена у других?
- Как ее можно решить у нас?
Продуктовая разработка = прототипы и фидбек
Чтобы понять насколько наши идеи жизнеспособны и будут ли они востребованы среди клиентов, нужно делать прототипы. Чтобы проверить гипотезу перед выкаткой фичи в продукт, мы используем MVP (minimum viable product) — «минимальный рабочий продукт». Он даёт пример решения задачи клиента, но не покрывает крайние случаи. Основная задача MVP — получение обратной связи для оценки и принятия решения. Нужно быть готовым к тому, что ряд прототипов по результатам собранного фидбека придётся выкинуть и полностью переработать. Это нормальный процесс.
Продуктовая разработка = обязательства
При этом обязательства возникают сразу по нескольким направлениям:
- перед клиентами: мы доставим фичи;
- перед разработчиками: мы не сломаем обратную совместимость.
Продуктовая разработка = стандарты индустрии
Фичи:
- Как эта задача решена в других продуктах?
- Работает ли это решение?
Разработка:
- Какие стандарты кодирования мы можем использовать, чтобы сделать наш код понятным всему сообществу разработчиков?
- Какие готовые популярные библиотеки мы можем использовать, чтобы не изобретать велосипеды?
- Как рефакторить устаревающий код?
Тестирование:
- Какие подходы к тестированию позволяют сократить количество ошибок?
Интерфейсы:
- Какие подходы используются в создании интерфейсов?
- Какие UI kit’ы решают эту задачу?
Инфраструктура:
- Как сейчас выпускают и разворачивают проекты?
- Как организовать мониторинг доступности и производительности?
Знать ответы на эти вопросы и следовать индустриальным стандартам — значит сохранять актуальность в комьюнити разработчиков.
Продуктовая разработка = ответственность
Разработчик возлагает на себя ответственность за успех или провал продукта. Продуктом уже пользуются, поэтому появление багов в нём гораздо критичнее, чем косяки в коде проекта, ещё не выпущенного в продакшн.
Рекомендации для начинающих программистов:
- Книга C. Макконнелл «Совершенный код». Талмуд в тысячу страниц. Несмотря на название, не весь про программирование. Содержит полезные советы по анализу требований и проектированию архитектуры.
- Н. Виноградова «Самые лучшие уроки рисования для смелых и любознательных». Когда я учился в универе, декан советовал нам смотреть мультики и больше рисовать, чтобы стать хорошими программистами. Мы тогда улыбались, но сейчас я разделяю эту мысль. Инструментов для проектирования систем много, но самый доступный — лист бумаги и карандаш.
- Изучить диаграммы последовательностей UML. При проектировании придется описывать процессы в системе. Диаграммы последовательностей UML — самый наглядный способ описания процессов.
- Продукт, который вы хотите пилить или уже пилите, нужно изучать постоянно. Сначала — для понимания, как он работает, чтобы разрабатывать хоть что-то. Потом — для понимания, что он предлагает клиентам. Далее — для понимания, что он может предложить клиентам. Без понимания того, что важно для клиента, а что нет, вы будете тратить время впустую на кажущиеся только вам важными улучшения.
16К открытий17К показов