Всем привет! Меня зовут Максим, и последние восемь лет я работаю в крупных компаниях бизнес-аналитиком и владельцем продукта.
Сегодня я хотел бы поделиться с вами своими мыслями о разработке продукта, организованной с использованием большого количества команд разработчиков.
Интересующихся и желающих поговорить на эту тему добро пожаловать под кат.
Начнем с крупных компаний.
Под крупными компаниями я подразумеваю компании с тысячами разработчиков, тестировщиков, аналитиков, devops-инженеров, владельцев продуктов и других менеджеров по персоналу.
Это десятки отделов, сотни команд, сложная иерархия, бесконечные зависимости и зоны ответственности.
Когда попадаешь в такую компанию, поначалу сложно ориентироваться.
Но время идет, и теперь вы вполне можете представить себе свой «остров».
Обычно это:
- Некоторая понятная система или компонент, участвующий в очень большом и сложном бизнес-процессе;
- Владелец продукта — человек, который несомненно знает, где развивать эту систему;
- Комплект документации разной степени актуальности;
- Набор тестов, автоматизированных и не очень.
Обычно к такому облику приходят отделы разработки компаний с успешными продуктами через 10-15 лет. Успешные продукты приносят деньги, деньги вкладываются в развитие.
Разработка растёт как на дрожжах, линейно масштабируется и доходит до того, что менеджеры проектов уже не могут держать в голове все зависимости, многие команды начинают тянуть «одеяло» на себя, а иногда и вредить продукту, а не развивать его.
В такой ситуации вполне нормально, что одна команда стремится к собственному успеху, уже не беспокоясь о том, что у коллег возникли какие-то проблемы, и их общая черта из-за этого не будет реализована.
Это нормально — разрабатывать тот функционал, о котором громче всего просят бесконечные заинтересованные стороны, а не тот, который нужен пользователям.
Разработка «на столе» — не редкость.
Процесс продолжается: требования получены, реализованы, протестированы и доставлены.
За ширмой суеты и шума легко спрятать главное: разработка продукта уже не так эффективна, как раньше.
Чтобы понять эту потерю эффективности, давайте обратимся к классике управления продуктом.
В настоящее время существует достаточно онлайн-школ или университетов, которые могут научить вас этой науке за определенные деньги.
Мой краткий список, если вы их не знали
- Продуктовый университет Аркадия Морейниса
- Звезда продукта Илья Красинский
- Менеджер по продукту из Skillbox
- Видение продукта
- Профессия продакт-менеджер от Нетологии
- Управление продуктами от Geek Brains
- Симулятор разработки продукта от Олега Якубенкова
Итак, по «классике», товар – это то, что покупают. Задачи продакт-менеджера — найти целевую аудиторию, определить ценностное послание, выбрать подходящие каналы продаж, сбалансировать экономику, найти точки роста и перебрать все подходящие гипотезы.
При необходимости измените идею, целевую аудиторию, каналы, послание, бизнес-модель, рынок.
Или вообще убить продукт, если ясно, что он не имеет обозримой перспективы.
Не похоже на историю выше, правда? Дело в том, что когда ты небольшой стартап, все процессы разработки продуктов достаточно прозрачны и понятны.
Обнаружить проблему и устранить ее очень легко.
Просто поймите идею продукта.
Легко разобраться и разработать необходимый функционал.
Пользователи – вот они, под рукой.
Прод — вот он, со всеми метриками.
Однако проходит время, продукт успешно завоевывает долю рынка, развивается в продуктовую линейку, нанимаются все новые и новые разработчики, и, прежде чем вы это заметите, ваша компания превращается в огромную мешанину структур, интересов и обязанностей.
- Пользователи продукта castdevil? Теперь ваши продакт-владельцы о них не помнят, они мечутся от одного стейкхолдера к другому, пытаясь понять, за какие требования ухватиться в первую очередь;
- Была ли ясная и прозрачная юнит-экономика? Теперь владельцы продукта даже не рассматривают PnL (Profit and Loss), загружая всю команду на пол-спринта историями о сомнительной пользе;
- Были ли там истории вакансий, карты путешествий клиентов и другие персонажи? Теперь в магазине пишут «Как владелец продукта я хочу, чтобы это было сделано, потому что это нужно отделу эксплуатации и обслуживания»;
- Было ли понимание ответственности за результат и сроки? Теперь каждая команда сама за себя, ваши функции будут доставлены в производство в одном или двух выпусках позже.
Что делать? Первое, что приходит в голову топ-менеджменту, — это то, что нам нужен волшебный механизм, который заставит всю эту сложную систему работать как швейцарские часы.
Есть спрос – есть предложение.
Я знаю несколько таких фреймворков, которые теоретически могут справиться с поставленной задачей.
Список
Являются ли они «серебряной пулей»? Я пережил несколько трансформаций бизнеса, в ходе которых был нанят «золотой тренер» и внедрены самые современные процессы управления и коммуникации.Тысячи людей в одночасье поменяли свои должности и перешли в новую структуру, новую команду, новые процессы, новые проекты.
И я могу сказать следующее:
- это дорого;
- это не быстро;
- это очень рискованно;
- Конечный успех во многом зависит от культуры компании.
Если люди понимают и верят, успех вероятен.
Я считаю, что есть и другие способы масштабирования разработки продукта.
К сожалению, у меня нет для вас пошаговых инструкций, но вот мои идеи, которые могут в этом помочь: Продукт .
Продукт должен обеспечивать ценность.
Рассмотрите зоопарк ваших систем и компонентов с точки зрения ценности.
Определите все потоки создания ценности для конечных клиентов, контрагентов или третьих лиц и разделите карту системы на такие потоки.
Каждый Владелец Продукта должен иметь под своим управлением полную цепочку систем создания ценности.
Дайте ему пару аналитиков, если объем ответственности слишком велик.
Метрики .
Чтобы управлять, сначала нужно научиться измерять.
Каждый владелец продукта должен выделить метрики своего продукта, на основе которых он будет этот продукт разрабатывать.
Пользователи .
Давайте отложим заинтересованные стороны в сторону.
Только пользователи могут дать истинное представление о ценности продукта.
Владелец продукта должен основывать свои гипотезы на результатах собеседований и анализе заявок.
Гипотезы .
Больше никаких слепых реализаций функциональности.
Каждый эпик или функция должны иметь ожидаемое влияние на показатели.
При реализации функций и их тестировании с помощью A/B-тестов владельцы продукта должны понимать, оказалась ли гипотеза успешной или нет. Координация .
Разумеется, работа многочисленных продуктов должна быть скоординирована в соответствии с выбранной вами структурой.
Однако такую координацию не следует превращать в совет менеджеров по продуктам с коллективной ответственностью.
Я считаю, что только поддерживая описанные выше условия, можно успешно масштабировать управление продуктом, и по большому счету не имеет значения, какой фреймворк вы выберете для этого масштабирования.
Далее в небольшой серии статей я разберу каждую идею более подробно:
- Продукт;
- Метрики;
- Пользователи;
- Гипотезы;
- Координация.
-
Дизайн Как Глобальный Язык Xxi Века
19 Oct, 24 -
Google Конвертер Зарплат
19 Oct, 24 -
Еще Один Джордж
19 Oct, 24 -
Продолжаем Решать «Простые» Задачи
19 Oct, 24
