Знайте свой продукт: практическое руководство по функциональному разложению
24 июня 2025 г.Управление - это чрезмерный термин, который может означать почти все. Есть множество профессий, как -то связанные с руководством. Но общей целью этого процесса является определение объекта управления и установить цели, которых должен достичь объект.
В случае управления продуктом ваш продукт или часть этого продукта является объектом. Погружаясь в новый проект или во время мозгового штурма о том, как повысить текущие, очень важно иметь четкое понимание того, чем вы управляете: плюсы и минусы текущего продукта, общий набор функций и ограничения продукта.
Создание нового продукта довольно весело. У вас хорошая идея и четкое видение. Вы можете использовать совершенно новые технологии и современные стандарты. Согласно текущей практике, более вероятно, что новый продукт будет содержать только «обязательные» функции, чтобы доказать гипотезу. Команда вовлечена, и если вы создадите достаточный процесс разработки, вы успешно принесете что -то новое на рынок. Но после выпуска продукт начнет развиваться. Вы можете обнаружить, что гипотеза поворота может быть неверной, и необходимо изменить позиционирование продукта. Или гипотеза в порядке, но вы также должны разработать дополнительные функции, чтобы конкурировать или обеспечить дополнительную ценность. После нескольких лет разработки совершенно новый продукт может быть не так простым для понимания, как версия Mint 1.0.0.
Богатая функциональность требует систематического подхода, чтобы держать изменения в страхе. Если бы вы были в начале процесса разработки и отвечали за этот продукт во время его изменений, это может быть не такая большая вещь. Но что, если вы являетесь новым менеджером по продуктам и у вас есть задача достичь новых высот для старого программного обеспечения или даже перезапустить продукт? Правильные решения могут быть достигнуты только с глубоким пониманием вашего объекта.
Если вы хотите что -то управлять, вы должны понимать, чем вы управляете и чем состоит ваш объект.
Эта статья охватывает часть работы по управлению продуктом и раскрывает метод работы с зрелым продуктом. Это отлично работает для того, кто только начинает новую работу с новым продуктом или кем -то, кто хотел бы упростить текущий продукт. Шаг за шагом помогает понять, что вам удается принимать собственные решения на основе данных.
Что мы здесь делаем и почему?
Давайте представим зрелый продукт B2B с несколькими сотнями функций. Каждый Agile Sprint, команда разработчиков устраняет старые проблемы и создает совершенно новые функции. Изменения должны иметь цель, связанную с деньгами.
Новые функции должны увеличивать счета клиентов.
Завершение технических долговых задач повысит стабильность или безопасность продукта, что помогает поддерживать продукт в долгосрочной перспективе.
Мы должны исправить ошибки, просто потому, что это демонстрирует общее качество продукта.
Некоторые части продукта могут поддерживаться разными командами с различными процессами разработки в соответствии с платформой или традициями. Это большой объем входных данных, с которыми мы должны иметь дело.
Вышеупомянутые ошибки продукта могут привести к интересной информации. Некоторые ошибки могут быть частью процесса стабилизации для новых функций. Они не важны в этой теме, но все же необходимо проанализировать их, если их много во время спринта, чтобы выявить некоторую дисфункцию между продуктом и разработкой. Но также, возможно, у вас могут быть старые производственные ошибки, которые у вас были из -за ухоженных древних особенностей. Эти ошибки могут появиться во времени и потреблять много денег, потому что, например, много лет назад эта функция была создана быстро и без надлежащей инженерии.
Должна ли ваша команда исправить эти ошибки, если эта функция была так плохо создана? Эта функция часто используется? Может, вам следует вернуть это? С какими еще функциями будет конкурировать эта функция? Ресурсы всегда ограничены, и очень важно иметь четкую картину вашего продукта и стоимость каждой части программного обеспечения. Чтобы ответить на все эти вопросы, у вас должно быть целое разложение продукта, которое поможет определить приоритеты компонентов продукта в соответствии с их влиянием на стоимость продукта и продемонстрировать реальную стоимость каждого решения продукта.
Форма и инструменты не имеют значения, но любой тип электронной таблицы - лучший и самый простой вариант. После предоставления этого разложения вы должны иметь понимание основных функций продукта и кучу дополнительных функциональных блоков, которые обеспечивают прямую или косвенную ценность (лучший способ выразить ценность - деньги). Как мы можем начать строить это разложение?
Как достичь разложения продукта?
Сложная задача для нового менеджера зрелого продукта или кого -то, отвечающего за продукт, где разложение не было необходимым раньше, - это найти, как начать. Первое, что нужно сделать, это собрать все входные данные. Цель состоит в том, чтобы составить список функций, которые можно позже подключаться к группам функциональности. Это будет документ реестра функций. Баланс необходим - результат должен быть подробным, но поддерживаемым. Тем не менее, это нормально иметь несколько сотен функций для взрослого продукта. Система фильтров и групп помогает ориентироваться. Самый простой способ работы с данными - это использование листов. Кроме того, необходимо выбрать инструмент, который может использоваться любым членом команды.
В зависимости от текущего состояния компании, продукта или проекта можно собрать эти пять источников для реестра функций. Из -за десятков причин некоторые из них могут быть доступны, а некоторые могут не быть. Но лучше получить все возможные источники и объединить данные:
Пользовательская документация
Если какие -либо другие источники недоступны, это отличный способ выделить основную функциональность продукта. Как обычно, документация по продукту состоит из наиболее используемых и необходимых функций. Если есть какие -либо дополнительные варианты, они могут быть задокументированы в некоторых приложениях или в боковых разделах. Первоначальная структура документации по продукту - отличный способ начать. Вы можете начать с раздела «Начало работы» и добавить в реестр некоторые основные функции, такие как «аутентификация», «Аутентификация 2FA», «восстановление пароля», вы называете его.
Спецификации продукта
Если продукт хорошо поддерживается, это самый подробный и полезный источник данных. Технические характеристики уже могут быть разделены логическими или архитектурными модулями, которые помогают выявить структуру продукта на основе истории эволюции программного обеспечения. Лучше погрузиться в спецификации после понимания некоторого уровня продукта, но позже абсолютно необходимо собирать все доступные статьи и схемы для создания системы управления. С другой стороны, этот уровень содержит так много деталей, что важно иметь некоторый фильтр, чтобы избежать переоценки.
Пользовательские истории или элементы отставания в системе отслеживания
Иногда они могут отражать спецификации продукта, но вполне возможно, что на некоторых этапах эволюции продукта время на рынке было более важным, чем документация, и эти артефакты являются единственным способом найти некоторые подробности о части функциональности. Они являются отличными кандидатами, чтобы добавить к столу после адаптации названий предметов для стиля реестра.
Ошибки продукта или задачи продукта
Самый низкий уровень артефактов, которым требуется много времени для анализа и поиска полезной информации. Но если продукт не такой большой, или если нет других источников, необходимо погрузиться в эти небольшие объекты.
Сам продукт
Великий источник информации, который мог бы рассказать историю сами по себе. Единственная проблема не состоит в том, чтобы пропустить какую -то дополнительную функцию, скрытую в редко используемой функции. Каждая форма может быть функцией. Например, мы могли бы открыть диалог создания пользователя. Это новая функция для нашего реестра: «Создание пользователей». Но, как обычно, создание означает будущее обслуживание и все операции CRUD, поэтому мы могли бы добавить такие функции, как «редактирование пользователя», «удаление пользователя» и «Список представления пользователей». Сложный лист в порядке. Лучше работать со всеми доступными данными.
Как построить управляемую панель мониторинга на основе сложной таблицы?
Во время пользовательской истории и анализа бэклиных предметов продукта необходимо получить понимание структуры продукта. Некоторые вещи хорошо развиты и развиваются после выпуска. Некоторые артефакты выглядят так, как будто они редко используются. Основная цель этого этапа - найти ядро продукта. Любые другие функции могут быть модулями продукта.
Там нет полезных секретов; Это обычная и творческая задача. Тем не менее, необходимо следовать здравому смыслу определять местонахождение основных функций и дополнительных доменов. Результаты работы повлияют на стратегию всей команды, поэтому лучше не спешить.
В зависимости от размера продукта, можно установить не более десяти доменов, включая основной продукт. Некоторые домены могут быть настолько очевидны, что они могут состоять только из одной функции продукта, и это здорово. Некоторые функции могут выглядеть многодоменными, и было бы трудно принять решение о них. Например, мы можем установить домен «интеграции», который содержит все разъемы для стороннего программного обеспечения. Но представьте, что одна из этих интеграций необходима для бизнес -процесса другого домена. Здесь есть несколько вариантов:
Переосмыслить подход разложения. Может быть, эта ситуация происходит из -за неправильной идеи, что сама интеграция является чем -то разделяемой. Интеграции, сделанные для достижения некоторого бизнеса и бизнес -области, лучше, чем архитектурные.
Сделайте исключение для этой интеграции, если этот случай полностью отличается от других. Это нормально, но показывает некоторую бессмысленность в этой идее и может привести к другим особым случаям, которые затрудняют поддержание и понимание системы.
Установите зависимость домена для создания цепочки доменов, которые необходимо поддерживать в продукте для этой функции. Плохое решение, но все же возможно.
После нескольких итераций все проблемы должны быть решены, и будет достигнут конечный реестр функций продукта с доменной разложением.
Что делать дальше?
Весь процесс функционального разложения решает задачу внедрения сложности продукта и понимания объема. Но главное понимание главного листа будет впереди.
- Какова стоимость каждой функции в год?
Состоит ли эта стоимость из зарплаты, или у нас есть некоторые сторонние зависимости?
Можем ли мы перейти на открытый исходный код, чтобы уменьшить количество запатентованных сторонних зависимостей? Насколько популярны и важны эти функции?
- Какие функции генерируют максимальную стоимость (деньги), а какие нет?
Можно ли удалить непопулярные функции из продукта?
Можем ли мы улучшить ценность существующих функций и сделать их популярными?
Ответ на все эти вопросы и дополнительный анализ помогает нам переключиться на управление на основе данных, которое может значительно улучшить качество продукции и позицию рынка. Понимание стоимости каждой функции в прошлом помогает предсказать и правило будущие оценки. Вся эта информация является отличной базой для обнаружения истинной рыночной стоимости продукта.
Слепые руководство приводит к ошибкам, которые могут даже разрушить бизнес, поэтому как можно быстрее, необходимо раскрыть детали вашего объекта и знать, чем вы управляете.
Оригинал