Что такое цель программы

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

А пока хочу остановится на предубеждениях которые нам закладывают с детства и которые влияют на то, как мы ставим цели:

• Жизнь это последовательность событий
• Для достижения результата нужно идти к цели шаг за шагом
• Цель это точка маршрута к которой мы идем

Что такое цель?

Цель это некоторое состояние в будущем, к которому мы хотим прийти. Состояние звучит слишком абстрактно? Можно сказать что это набор точек на графике времени.

Движение человека или корпорации по графику времени это постоянное изменение состояния этого человека или компании. Поскольку осознать что такое состояние мы не можем (это бесконечный набор точек), мы выбираем набор точек на плоскости по которым оцениваем это состояние. Эти точки в зависимости от принятой методологии могут называть kpi, могут называть vital signs, еtc. А цели обычно — изменение этих показателей, или появление/открытие новых.

Что такое цель и инструменты?

Объясню на простом примере: вы поставили себе личную цель стать более здоровым. Во-первых для этого вам надо определить что значит «здоровый» для вас, если собрать несколько человек в одной комнате и попросить описать этот термин — каждый даст разное определение.

Предположим для вас здоровый человек это человек который может пробежать 10км за час или менее, не курит и не пьет (мы понимаем что здоровье это очень большая плоскость, но выделили такие точки). Затем стоит выделить текущее состояние: например вы употребляете один алкогольный напиток в день, курите, и можете пробежать 3 км за 22 минуты с одышкой. Это начальное состояние. От начального состояния до конечного есть некий временной отрезок за который вы хотите/планируете его преодолеть.

Есть множество способов соединить эти точки. Я бы сказал бесконечное множество промежуточных точек и путей. Напоминает систему уравнений с несколькими неизвестными.

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

Если есть бесконечное количество точек, то как выбрать нужные?

Ценности могут в этом помочь ограничив пространствоь точек. Помогают ли цели в будущем расти нашим ценностям?

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

От Этого Исполнятся Все Твои Цели! Как Ставить Цели Правильно и Достигать Их Быстро!

Любая методология целеполагания

— Специализирована (не универсальна, не подходит всем и всегда)

— В первую очередь инструмент структурирования коммуникации внутри рабочей группы

Подход к выбору конкретных инструментов должен отвечать на вопрос:

— Помогает ли нам этот инструмент (субъективно) взаимодействовать эффективнее

— Помогли ли поставленные нам цели к развитию наших ценностей (как внутри так и снаружи)

Какие бывают инструменты?

Ваш бизнес-тренер вероятно говорил о том что цели должны быть SMART. Возможно вы слышали о PACT, но есть еще примерно примерно десяток акронимов, большая часть из которых существует только для того чтобы сокращение было красивым.

1. Есть инструменты для определения целей — это SMART, PACT етц, они подсказывают нам как определить цели, и что вообще являются целью. Несколько разных людей будут определять что такое цель по-разному, поэтому нужно общее определение для того чтобы работать в группе.

• Методы приоритезации целей позволяют ранжировать цели в соответствии с приоритетами. Например если за определение цели принят KPI, например увеличить прибыльность продукта при том же количестве и качестве трафика на 10%, то мы будем приоритезировать этот KPI относительно других KPIs. Применять методы приоритезации можно как для стратегических инициатив так и для рядовых задач внутри продукта.

• Фреймворки работы с целями, такие как OKR сочетают в себе как определение цели так и подходы к их постановке, контролю их выполнения и пересмотру.

В этой статье и приложениях к ней мы обсуждаем пункты 1 и 2 и немного коснемся OKR в контексте определения целей.

Процесс постановки целей

Мой личный подход к постановке персональных целей такой:

1. Выписать все что приходит в голову в spreadsheet

2. Отранжировать то что записано по принципу: «что я считаю приоритетным»

3. По каждой цели пройти квадратом Декарта:

4. К каждой цели задать вопрос какой из наших ценностей (одной или нескольким) соответствует эта цель. Как она поможет развивать и растить эту ценность/-и (и записываем это в отдельную колонку)

5. Добавить колонки интерес, риск, усилия и проставить для каждой цели значения в эти колонки от 1 к 10 (где 10 это наибольшее) и затем посчитать в отдельную колонку эти значения по формуле: интерес/риск/усилия*100 — наибольшее значение более приоритетное (я движим интересом, это моя базовая мотивация, поэтому я сделал для себя такой фреймворк приоритезации личных целей)

6. Проранжировать список на основе инсайтов полученных в пунктах 3 и 4 и 5.

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

Как бы эта цепочка выглядела для постановки целей в продуктовой компании?

1. Предварительно мы выбираем что такое цель и что мы будем считать нашей целью. А также о методе по которой будем оценивать важность
2. Коллектив собирается чтобы обсудить цели и выписывает их в удобном виде — от стикеров до электронной таблицы.
3. Каждую из целей мы проверяем на соответствие определению цели из пункта № 1
4. К каждой цели задать вопрос какой из наших ценностей (одной или нескольким) соответствует эта цель. Как она поможет развивать и растить эту ценность/-и (и записываем это в отдельную колонку). Я называю этот этап ценностным фильтром.
5. Применяем к целям фреймворк приоритезации.
6. На основе фреймворка приоритезации ранжируем цели.

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

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

— Все распространенные подходы к постановке целей в статье: “Больше чем SMART: 11 подходов к постановке целей”

Возьмем за основу RAVE (Risks, Assumptions, Values, Effects) и MosCow method из двух статей выше. Да, да, вы все правильно поняли, у нас будет Rave in MoSСoW.

Каждая цель несет в себе риски. Какие у нас есть риски?

В целом любую задачу можно оценить исходя из двух рисков: что нам грозит если мы ее сделаем и что нам грозит если мы ее не сделаем.

Цель это предположение, гипотеза.

Вместо «мы хотим увеличить прибыль направления Х на 30%”, “если мы увеличим прибыль направления Х на 30% то станем устойчивее.» (если устойчивость это ценность.)

Цель должна соответствовать определенной ценности

Как отразится выполнение этой цели на компании, ее ценностях и других целях.

Квадрат декарта помогает нам в оценке Риска и Эффекта

(Must-Have, Should-Have, Could-Have, and Won’t-Have)

Почему для примера я взял MoSCoW? По моему опыту работы числовые методы очень переоценены:

• Values vs Effort это всегда overestimated values vs underestimated effort.
• WSJF не учитывает неопределенность и поэтому без ручного вмешательства там делаются только задачи с определенной сложностью и возвратом (а все long-shot RnD и задачи с неясным outcome либо требуемыми ресурсами получают неверный/странные приоритет)
• RICE требует в рамках целеполагания оценить достаточно сложные параметры, что возможно только при старте работы над целью (и соответственно требует времени на оценку даже тех идей которые не пойдут в работу), либо оценить эти параметры узкой группой лиц очень грубо и спустить сверху (считай — ткнуть в потолок).

Главный недостаток MoSCoW это игнорирование ограниченного capacity — даже инфографика выше показывает effort, но сам метод не подразумевает оценку effort.

Как с этим быть?

Чаще всего оценка effort обманчива и вызывает конфликты. (Наши боссы думают что это реально сделать в квартал, хахаха). К тому же это хороший способ обмануть приоритеты «от бизнеса» на приоритеты «от ресурсов» — вместо задач которые приносят ценность будут делаться задачи которые мы можем сделать быстро. Я бы здесь исходил из того, что были бы цели, а ресурсы найдутся. При этом следует максимально строго ограничивать количество must have целей.

И как быть с разными взглядами на приоритеты у стейкхолдеров (например каждый стейкхолдер считает свою цель must-have)?

Есть несколько разных способов решить эти противоречия:

У каждого из стейкхолдеров есть определенный набор жетонов — привязанный к его вкладу и роли, и он может потратить их на голосование. Предположим 3 жетона за must have, 2 за should have, 1 за could have и 2 за won’t have.

• Голосование

В отличии от покупки у каждого из участников есть равное количество голосов — по одному на каждую цель.

В моем эксперименте MoSCoW давал ту же точность, что и его числовые аналоги (RISE, WSJF, Value vs Effort) на одном списке целей. Вы можете провести свой эксперимент: а именно взять два-три метода и применить их к вашему списку целей и посмотреть на получившийся результат. Поскольку это эксперимент после беглой оценки вы можете потратить дополнительное время и ресурсы на оценку получившихся приоритетов (например, более детально рассчитать коэффициенты, если вы выбрали RICE).

Как будет выглядеть вся цепочка.

Набор ценностей: Безопасность, Устойчивость, Эффективность, Ответственность.

Набор целей:

• Увеличить прибыль направления X на 30% (если мы увеличим прибыль направления X на 30% то станем устойчивее)
• Запустить продукт N (если мы запустим продукт N то диверсифицируем бизнес и станем устойчивее)
• Добавить функционал Y в продукт Z (если мы добавим функционал Y в продукт Z то мы сможем оказывать поддержку клиентам эффективнее)
• Добавить функционал Е в продукт Z (то это увеличит нашу безопасность)

Квадрат декарта: Если мы увеличим прибыль направления X на 30% то станем устойчивее

Что будет если мы это сделаем?

• Свободные средства которые мы можем использовать/инвестировать по своему усмотрению Возможность уйти в минус в следующем квартале
• Возможность инвестировать в финансово-емкие новые направления

Что будет если мы этого не сделаем?

• Свободный ресурс разработки
• Мы сможем сделать другую эпик цель

Чего не будет если мы это сделаем?

• Скорее всего мы не сможем запустить продукт N так как он пересекается по ресурсам с этой целью

Чего не будет если мы это не сделаем?

• Свободных денег

Источник: vc.ru

3.2.3. Цели программного обеспечения

Второй этап разработки ПО – постановка целей. Цели – это конкрет­ные ориентиры для программного продукта. Процесс их постановки – прежде всего процесс принятия компромиссных решений. Например, не столь уж невероятно встретить документ, в котором требования формули­руются в следующей форме:

Обеспечить максимальную надежность, эффективность, адаптируе­мость, общность и безопасность системы, минимизируя стои­мость и время разработки, требуемую память и время реакции терми­нала.

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

При постановке целей распространены следующие ошибки:

1. Цели не формулируются явно.

2. Составляется беглый набросок списка целей, причем жизненно важные цели в него не включаются.

3. Цели формулируются, но таким образом, что они конфликтуют друг с другом. В результате каждый программист, работающий над проек­том, разрешает эти конфликты сам, причем все разрешают их по-своему, что в конечном итоге дает совершенно непредсказуемый результат.

4. Необходимость конкретных целей признается, но цели формули­руются только для продукта, а не для проекта. При разработке ПО необхо­димы два набора целей: цели продукта, т.е. определение целей оконча­тельного результата с точки зрения пользователя, и цели проекта, такие как график, стоимость, степень тестированности и т.д.

Цели продукта

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

1. Резюме. Вначале нужно коротко сформулировать общее назначе­ние разрабатываемого продукта.

2. Определение пользователя. Если разрабатывается большая сис­тема с разными группами пользователей, должны быть определены роли различных пользователей.

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

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

5. Эффективность. Сюда относятся все цели, касающиеся эффек­тивности или производительности, такие как временные характеристики, пропускная способность, использование ресурсов, а также необходимые средства измерения производительности и средства настройки.

6. Совместимость. Если конкретный программный продукт должен быть совместим с другими, эти цели указываются здесь. Следует указать также относящиеся к делу международные и государственные стандарты и внутренние стандарты компании.

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

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

9. Обслуживание. Здесь намечаются стоимость и время исправления ошибок, а также необходимые для достижения намеченных параметров программные средства, например диагностические программы.

10. Установка. Сюда относятся методы и средства настройки сис­темы на конкретные условия эксплуатации.

11. Надежность. Рассматриваются последствия отказов системы и методы их преодоления.

Цели лабораторной работы по изучению ЦК приведены в подразд. 3.2.

Источник: studfile.net