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

Постановка цели – это второй шаг разработки программного продукта или системы. Цель продукта представляет долгосрочный ориентируемый результат. Цель продукта может быть как конечной (стратегической), так и переходной, при достижении которой ставится новая цель для достижения конечной цели.

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

Для выбора оптимальных целей и установления компромисса обычно пользуются формой матрицы зависимости требований (Requirements Dependency Matrix).

Самое важное в проектировании программных систем – постановка правильной цели. Точность постановки цели обуславливает не только эффективность реализации продукта, но и устранение множества внеплановых затрат на достижение желаемого результата: денежных, временных, человеческих и т.д.

В настоящем тексте мы рассмотрим, что такое цель программного продукта и метод ее постановки (разработки) через матрицу конфликтов требований.

Постановка цели – это второй шаг разработки программного продукта или системы.

Сам по себе продукт имеет заинтересованных в нем лиц (как минимум, пользователей и клиентов), для которых через его разработку создается ценность.

Цель продукта представляет долгосрочный ориентируемый результат.

В определении цели программного обеспечения важным является именно слово «ориентируемый». В данной характеристике состоит отличие от требований к продукту. То есть, если требования необходимо четко выполнять, но на пути достижения цели продукта возможны незначительные отклонения.

Цель продукта может быть как конечной (стратегической), так и переходной, при достижении которой ставится новая цель для достижения конечной цели.

Если подходить к описанию цели продукта с точки зрения планирования, то это некий образ будущего желаемого состояния продукта. Хорошее понимание того, что же является тем самым «желаемым состоянием» продукта помогает избежать лишних действий на пути его реализации. Таким образом, чем более четко вырабатывается цель продукта, тем ниже риски непредвиденных расходов в будущем.

Итак, перейдем к рассмотрению процесса постановки цели программного продукта. Для этого следует придерживаться следующих правил:

• Запрет на указание методов реализации цели. То есть нельзя путать цели и план их реализации.

• Тут же возникает требование о соблюдении достаточной точности формулировки цели. При уходе от расшифровки методов достижения цели возникает риск недостаточного погружения в особенности разрабатываемого продукта.

• Нужно вырабатывать компромисс между целями. Зачастую, при формулировании целей возникает противоречивость, т.е. конфликт целей. Это означает, что у каждой стороны (клиентов, разработчиков) имеются свои цели, которые часто противоречат друг другу.

• Разработка программного продукта должна учитывать два множества задач: цели продукта с точки зрения конечного клиента и цели проекта (стоимость, надежность, график и т.д.).

Таким образом, постановка цели включает не только выработку ее формулировки, но и процесс выработки компромисса во избежание конфликта целей.

Среди самых распространенных формулировок целей программного продукта выделяют:

• надежность;

• эффективность (производительность);

• универсальность;

• адаптивность;

• человеческий фактор (психологические факторы, документация);

• стоимость продукта;

• время на разработку продукта (график);

• безопасность;

• удобство сопровождения.

Взаимосвязь надежности с остальными целями продукта

Отдельно скажем про «надежность» (простыми словами — способность системы сохранять качество в процессе эксплуатации). В нашем случае надежность – это цель «царица». Как правило, с ней соотносят все остальные цели. Это связано с тем, что все дополнительные функции, рост производительности и т.д. автоматически требуют работы по повышению надежности. Этот же параметр сдерживает и само развитие.

Все подлежит доработке в процессе эксплуатации, однако надежность – самая сложная часть для устранения ошибок после запуска продукта.

Так же отметим, что сто процентной надежности разработчики пока что еще не научились добиваться.

• Что касается взаимосвязи производительности и надежности, то это сложная категория. С одной стороны, при росте производительности необходим больший объем памяти и времени на работу программы, что может являться следствием повышения надежности. С другой стороны, рост объема памяти и времени являются конфликтными категориями для надежности и обуславливают необходимость ее дополнительной проработки.

• Такая же история с адаптивностью. Адаптивность программного продукта – это добавление дополнительных функций для расширения охвата клиентов и облегчения использования продукта. Вместе с тем, в некоторых случаях она противоречит надежности, например, если не связана с улучшением системы защиты продукта. Данный конфликт решается путем выделения отдельных функций и соотнесения их с параметром надежности.

Компромиссы целей продукта и надежности

Как уже говорилось, при реализации целей конфликты неизбежны, выработка компромиссных решений является приоритетом еще на первоначальных этапах постановки цели. Для этого рассматривают «отношения» между выработанными целями, учитывая имеющиеся требования к разрабатываемому программному продукту.

Рассмотрим основные примеры таких связок с целью «надежность»:

• Универсальность и надежность

Универсальность программного продукта характеризуется объемом функционала, а также мощностью для пользователей, то есть представляет собой количественную характеристику.

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

В этом случае следует разобрать на функции разрабатываемый продукт и каждую функцию соотнести с показателем надежности. Таким образом, важно в процессе разработки программного продукта не ставить целью сто процентную универсальность продукта, а постараться идентифицировать функции продукта и для каждой из них выработать уровень универсальности.

• Учет психологических факторов и усложнение интерфейса, надежность

Психологическими факторами принято считать легкость работы с программным продуктом для клиента, а также предвидение возможных сценариев неверного применения клиентом разрабатываемого продукта. За счет этого повышается степень его интеллектуальности и надежности. Однако, тем самым и усложняется сам интерфейс, что приводит к сложностям в использовании продукта.

Избежать этого конфликта целей позволяет детальный учет психологических факторов для устранения действий пользователя непредвиденного характера.

• Стоимость и надежность

Стоимость программного продукта определяется не только затратами на разработку, но и количеством ошибок в продукте. Любой разработчик стремится в конкурентной борьбе снизить стоимость своего продукта, но в этом случае приходится поступаться некоторыми итерациями в разработке, что противоречит надежности. Компромисс здесь достигается поиском квалифицированных членов команды.

• График и надежность

Любой проект имеет срок сдачи. Если вы сдаете разработанный продукт, это означает, что вы провели достаточные тестирования и уверены в надежности. Однако, на этапе установления сроков сдачи часто отводится недостаточное количество времени для надлежащего проектирования. По этой причине сроки сдачи продукта сдвигаются. Таким образом, данный конфликт решается при отведении рационального времени для устранения ошибок и сдачи проекта.

Соотнесение основных целей

Теперь рассмотрим, какие же цели соотносятся с надежностью.

• Удобство сопровождения. Оно представляет собой временные затраты на исправление ошибок, что повышает надежность.

• Безопасность. Простыми словами– это бесперебойная работа продукта вне зависимости от действий клиента, т.е. гарантия сохранения уже имеющегося объема наработанной при использовании продукта информации. Ее повышение идет в тесной связке с надежностью.

• Документация. Это процесс публикации пояснений для пользователей. Чем чаще они осуществляются, тем выше надежность.

Для выбора оптимальных целей и установления компромисса обычно пользуются формой матрицы зависимости требований. Так как речь идет не о выработке требований, а о выработке целей, другими связанными с ней матрицами в этих целях не пользуются.

Матрица зависимости требований имеет следующий вид.

Начальным этапом составления матрицы является сбор требований (функций, которые необходимо учесть в продукте).

Далее конструируется сама матрица. В первую вертикаль и первую горизонталь матрицы выписываются требования, элемент матрицы с номером 11 не используется.

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

По итогам анализа матрицы вырабатываются краткосрочные и стратегические цели.

Итак, мы рассмотрели понятие цели продукта и процесс ее постановки. В заключении отметим, что при выработке цели продукта стоит помнить, что это основополагающий процесс продуктового менеджмента. От правильности постановки цели программного продукта в конечном счете зависит успешная реализация заказа клиента, конкурентоспособность и имидж компании–разработчика.

1. Поменять средний чек.

Лучше в большую сторону. Так и юнит–экономика оздоровится и гипотеза ценности вашего продукта протестируется.

2. Поменять аудиторию.

Может вы не тем продаете?

Может это нужно, но кому–то другому?

3. Увеличить трафик.

Acquisition — проблема множества бизнесов. Оно сука дорогое и хрен его просто так сделаешь. Поэтому если с трафиком жопа, может и не стоит суетить.

4. Увеличить APC.

Average Payment Count = синоним LTV. Важно, сколько раз вам заплатят повторно. А если повторно не платят, то может надо покрутить с бизнес–моделью что–то?

5. Перестать тратить деньги на маркетинг.

Вы знаете, что делает ваш маркетолог? Правильно, тратит бюджет. Ему в целом пофиг на ROMI, CAC, GM, ARPPU / ARPB. А если он захочет их показать красиво — покажет. Вы же в кабинеты не полезете. Вот и хватит на говно сливать кэш.

6. Обучиться маркетингу / Growth Hacking / Product Management

Сами поучитесь, поймете че и как.

7. Закрыть продукт.

Может и правда, не стоит оно того?

8. Продать продукт.

Любят люди покупать всякое. Денег свободных вокруг полно. Так чего бы нет?

9. Рассказать об истории продукта в социальных сетях.

Ну сторителлинг клево кстати продает. Если не впадлу личный бренд качать — качайте.

10. Пойти продавать ручками.

Это ваще самое лучшее, чтобы понять, кому и что продавать. Многие крупные ребята такое практикуют со своими топами. А про стартаперов я и не говорю. Если они конечно хотят продавать, а не инвестиции просто сливать.