slava's words

Свежие заметки

Продуктовые подходы

время чтения ~19 мин.

Продуктовые подходы

JTBD - Jobs To Be Done

Note

Главное в Jobs To Be Done—знать и эффективнее выполнять задачи клиентов.

Методология JTBD называет задачи людей термином «работа», а продукты, которые люди покупают и действия, которые совершают для того, чтобы эффективнее выполнять задачи, называет термином «решение».

Работа = выполнить цель/задачу, то есть перейти

  • из точки А, в которой человек находится в контексте, обладает конкретными знаниями, испытывает эмоциональное состояние и с которым случилось триггерное событие. В точке А задача ещё не выполнена, но человек представляет себя в точке Б, в которой задача выполнена
  • в точку Б, в которой задача выполнена, результат получен, человек испытывает позитивные эмоции

Работы описываются по следующей формуле:

  • когда
    • я в контексте
    • у меня есть прошлый опыт и/или знания
    • у меня есть психологические особенности
    • испытываю негативные эмоции
    • случился триггер
  • хочу получить ожидаемый результат
    • с какими критериями ожидаемого результата
  • чтобы получить ожидаемый результат выше уровнем
    • и чувствовать себя по-другому после того, как я получу ожидаемый результат

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

Людям не нужны наши продукты, но мы про это постоянно забываем

  • Клиенту Т-Банка не нужен счёт и приложение Т-Банка.
  • Клиенту Airbnb не нужен сайт, приложения и апартаменты Airbnb.
  • Клиенту Яндекс Музыки не нужна функциональность «Моя волна».

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

Чинить боли клиентов—далеко не единственный способ создавать ценность

Проблема—ВСЕГДА следствие того, что на работу было нанято конкретное решение, и это решение облажалось, то есть выполнило работу ниже ожиданий.

Если вы выводите продукт на рынок со стратегией «мы чиним боли клиентов», это означает, что вы опираетесь на следующее знание:

  • на рынке есть достаточно большой сегмент людей, объёдинённый конкретной работой или работами
  • этот сегмент для выполнения своих работ нанимает конкретное решение
  • это решение не оптимально или вообще не выполняет эти работы
  • ваше решение выполняет работы этого сегмента людей ЛУЧШЕ, то есть без проблем относительно текущего решения

Сегментация по работам—главная сегментация для продукта

Чато встречаются ситуации, когда до использования JTBD команда использовала сегментацию, которая даёт ощущение ясности, например, типичная сегментация клиентов риэлторов или девелоперов—сегментация по доходу и возрасту + квартиры эконом-, комфорт-, бизнес- или премиум-классов.

Такая сегментация даёт ложное ощущение ясности, но не позволяет принимать эффективные решения, потому что не содержит в себе причинно-следственных связей, или эти связи слабые. С такой сегментацией у вас 20-летний парень может купить квартиру эконом-класса и квартиру бизнес-класса. 35-летная состоятельная предпринимательница может купить пять квартир эконом-класса. Команды, которые используют такие сегментации, не понимают ПОЧЕМУ это происходит и ограничены в своих решениях.

Можно сегментировать людей по парам работа+решение, и это самая удобная сегментация для принятия продуктовых решений

Шаблоны

Как мы анализируем исследование для поиска продукта 

Наша задача—увидеть типичные низкоуровневые работы, которые выполняют люди в сегменте, увидеть с какими сложностями сталкиваются, какие решения выполняют сами. 

Из исследования мы хотим получить: 

  • список низкоуровневых работ для сегмента:
    • когда триггер+контекст
    • хочу ожидаемый результат
    • чтобы желаемое эмоциональное преображение
    • субъективная средняя оценка важности работы
  • список низкоуровневых работ, которые возникали у клиентов внутри главной работы сегмента
  • какие решения использовал клиент, сколько они столили, средняя удовлетворённость соотношением цена/качество, к каким решениям клиенты привыкли
  • с какими проблемами сталкиваются люди в сегменте, насколько силён вес этих проблем суммируем скоры всех проблем по формуле скора проблемы = средняя эмоция*средняя частотность
  • примерное соотношение количества людей в сегментах. Если есть возможность * посчитать примерное количество людей в абсолютах—do it!

Сравнение JTBD с другими фреймворками

JTBD VS User Story:

  • JTBD фокусируется на глубинных потребностях и мотивах пользователей, пытаясь понять, ради чего они «нанимают» продукт.
  • В отличие от JTBD, User Stories фокусируются на конкретных функциональных требованиях и желаемых результатов использования продукта. Например:
    User Story может описать, как пользователь хочет видеть определенный функционал: «Как покупатель, я хочу видеть ассортимент часов, чтобы выбрать водонепроницаемую модель».

JTBD VS Agile:

  • JTBD сосредотачивается на стимулах, потребностях совершения того или иного действия(работы)
  • Agile - просто удобный фреймворк итеративной разработки продукта и постоянной адаптации Пример: команда разработчиков выпускает новую версию приложения каждые две недели, улучшая его на основе отзывов пользователей.

JTBD VS Lean Startup:

  • JTBD определяет, что важно для потребителя, анализируя его поведение
  • Lean Startup же фокусируется на быстром выходе на рынок с минимально жизнеспособным продуктом и его последующим совершенствованием Пример: стартап может запустить базовую версию приложения и постепенно добавлять новые функции, опираясь на обратную связь.

JTBD VS Design Thinking:

  • JTBD про глубину
  • Design Thinking про эмпатию и творчество для решения проблем пользователей Пример: дизайнеры могут разработать новый интерфейс кофе-машины, который делает процесс приготовления кофе ещё более простым и удобным.

Фреймворки для валидации гипотез

Rapid Iterative Testing Evaluation (RITE)

RITE - это как быстрое приготовление блюда с постоянным дегустированием и корректировкой вкуса. Ты начинаешь с базового рецепта (твоего продукта), пробуешь (тестируешь) и быстро вносишь изменения (итерации), основываясь на отзывах (обратной связи). 
Вот как это работает: 

  1. Тестирование: Сначала ты проводишь тестирование своего продукта с реальными пользователями. Например, ты создал прототип приложения и хочешь узнать, понятен ли интерфейс. 

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

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

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

Суть RITE в том, чтобы быстро адаптироваться и улучшать продукт, опираясь на реальные отзывы пользователей. Это как игра в “горячо-холодно”, где ты быстро находишь правильный путь, слушая подсказки. Так ты экономишь время и ресурсы, делая продукт, который действительно нравится пользователям.

Tip

Use it, when you have a prototype, want quick feedback, and have the ability to keep tweaking the design.

Riskiest Assumption Test (RAT)

Рискованные предположения—это позитивные предположения, из которых мы исходим, мечтая, что в будущем наш продукт станет успешным.

Riskiest Assumption Test—это инструмент выделения и проверки этих рискованных предположений. Он состоит из всего трёх шагов: 

  1. Выписать все рискованные предположения для будущего продукта и бизнеса, которые мы видим на текущий момент
  2. Отранжировать от наиболее рискованных до наименее рискованных 
  3. Пойти проверять топ рискованных предположений

После того, как проверено рискованное предположение, и, если нам повезло, оно подтвердилось, мы проходим по этому упражнению заново. Проверка одного рискованного предположения может дать вводные о новых рискованных предположениях и/или поменять веса рисков.

Типичные рисковые гипотезы 184. Рискованные предположения про рынок, тренды и регуляцию - Рыночные тренды восходящие - Рынок достаточно большой для планируемого ROI на нашем горизонте планирования возврата инвестиций - Нет законов и регуляторов, которые не позволят сделать планируемый продукт 185. Рискованные предположения про клиентские сегменты - Есть достаточно большой платёжеспособный сегмент - У этого сегмента есть важная (=тратят $, время, нервы) для них Job Story 186. Рискованные предположения про продукт - У нас есть доступ к людям и знаниям, которые помогут создать такой продукт - Наша гипотеза продукта решает Job Story выбранного сегмента 187. Рискованные предположения про юнит-экономику - В выбранной бизнес-модели у нас сойдётся пессимистичная юнит-экономика 188. При масштабировании привлечения, ROI будет сохраняться

5 Почему

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

  1. Первое “Почему?”: 
    Почему приложение перестало работать? 
    Ответ: Потому что сервер упал.

  2. Второе “Почему?”:
    Почему сервер упал? 
    Ответ: Потому что он перегружен из-за большого количества пользователей.

  3. Третье “Почему?”: Почему сервер не справился с большим количеством пользователей? Ответ: Потому что он не был настроен на такое количество запросов.

  4. Четвертое “Почему?”:
    Почему сервер не был настроен на большое количество запросов? Ответ: Потому что при планировании не учли возможный рост числа пользователей.

  5. Пятое “Почему?”:
    Почему при планировании не учли рост числа пользователей? Ответ: Потому что команда разработчиков не провела анализ потенциального рынка

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

Conjoint Analysis - Совместный анализ

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

Conjoint анализ - это как создание коктейля, где ты выясняешь, какие ингредиенты (или характеристики продукта) и в каком количестве нужны твоим клиентам. Ты предлагаешь людям разные варианты смартфонов с разными сочетаниями характеристик и спрашиваешь их мнение. 

Вот примеры вариантов: 

  1. Смартфон с отличной камерой, большой батареей, но высокой ценой. 
  2. Смартфон со средней камерой, средней батареей, но низкой ценой. 
  3. Смартфон с хорошей камерой, небольшой батареей и средней ценой.

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

У СА есть также и ограничения в использовании,  о которых важно помнить. Главное то, что его невозможно использовать, если характеристики товара/услуги взаимосвязаны между собой и их нельзя рассматривать по отдельности.

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

Количество характеристик не должно превышать 7-8, большее их количество излишне для восприятия респондента. Каждая характеристика может иметь собственные уровни. Например, уровни для типа экрана телевизора могут быть плазма, жидкокристаллический экран, электронно-лучевая трубка. Обычно используется 2-5 уровней.

Респондентам показывают набор товаров (или продуктов и пр.), содержащих комбинации характеристик товара (а также уровней), всех или наиболее существенных. Предлагается сделать выбор, например, отдать предпочтение, назначить ранги или рейтинги представленным вариантам продуктов. Мера сходства/различия представленных вариантов такова, чтобы потребитель мог легко сравнить их и отдать предпочтение тому или иному варианту. Каждый вариант составлен из уникального (неповторяющегося ранее) набора характеристик.

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

Жизненный цикл продукта

The four stages of the product life cycle are:

  1. Product Concept.
  2. Minimum Viable Product (MVP).
  3. Minimum Marketable Product (MMP).
  4. Minimum Lovable Product (MLP).
  5. Growth Product. The growth stage is when the product gains traction in the market, and sales and profits begin to increase. At this stage, the team focuses on scaling the product, increasing market penetration, and establishing brand identity.
  6. Maturity Product. The maturity stage is when the product reaches its peak popularity and sales. At this stage, the team focuses on maintaining the current market share and optimizing profits.
  7. Decline Product. The decline stage is when the product begins to slow down in terms of sales and profits. At this stage, the team focuses on maintaining the market share and reducing costs.

During the introduction stage, the product is introduced to the market and the company begins to build awareness of the product. 

During the growth stage, the product gains traction and starts to become more popular. 

During the maturity stage, the product is established in the market, has achieved its maximum potential, and is beginning to decline. Finally, in the decline stage, sales of the product start to decrease and the product eventually disappears from the market. 

Product managers must be aware of the product life cycle in order to develop successful Product Strategy. By understanding the product life cycle, product managers can plan their marketing activities to ensure the product is successful at each stage of the cycle. 

They must also consider the competitive landscape and changing Customer Needs to ensure they are staying ahead of the Competition.

1. Introduction Stage 

The introduction stage is the initial phase of the product lifecycle. During this stage, the product is launched into the market, and customer awareness and demand begin to grow. Key considerations for product managers during this stage include:

  • Market Research. Conduct thorough market research to understand customer needs, preferences, and potential demand for the product.
  • Product Positioning. Determine the unique value proposition of the product and position it effectively in the market to differentiate it from competitors.
  • Product Marketing and Promotion. Develop marketing strategies to create awareness and generate interest in the product among the Target Audience.
  • Pricing Strategies. Set an appropriate pricing strategy that balances value for customers and profitability for the business.
2. Growth Stage 

In the growth stage, the product experiences rapid market acceptance and increasing sales. The key considerations for product managers during this stage include:

  • Market Expansion. Identify opportunities to expand the product’s market reach and target new customer segments.
  • Product Differentiation. Continuously enhance the product’s features and functionalities to differentiate it from competitors and maintain its growth momentum.
  • Distribution Channels. Explore and establish effective distribution channels to ensure wider availability and accessibility of the product.
  • Customer Support. Invest in customer support services to address customer inquiries, provide assistance, and build customer loyalty.
3. Maturity Stage 

During the maturity stage, the product reaches its peak level of market penetration, and sales growth stabilizes. Key considerations for product managers during this stage include:

  • Market Saturation. Recognize that the market is saturated, and competition is intense. Focus on retaining existing customers and increasing customer loyalty.
  • Product Optimization. Continuously optimize the product’s performance, quality, and features to maintain its competitiveness and meet evolving customer needs.
  • Price Adjustments. Monitor pricing strategies and consider adjustments to maintain profitability and respond to market dynamics.
  • Diversification and Extensions. Explore opportunities for product line extensions or diversification to capitalize on the brand’s reputation and customer loyalty.
4. Decline Stage 

In the decline stage, the product experiences a decline in market demand and sales. The key considerations for product managers during this stage include:

  • Product Evaluation. Evaluate the product’s performance and market demand objectively to determine if it is still viable.
  • Exit Strategies. Identify appropriate exit strategies, such as discontinuation or phasing out the product, while minimizing financial losses.
  • Customer Transition. Plan for a smooth transition for existing customers, ensuring they are well-informed and provided with alternative solutions.
  • Lessons Learned. Reflect on the product’s lifecycle and gather insights to inform future product development and management decisions.

15 способов создать MVP

  1. MVP волшебник страны Оз. При разработке продукта это означает, что вы создаете версию продукта, которая выглядит так, как будто она работает полностью самостоятельно, но на самом деле за кулисами находятся люди, заставляющие ее работать.
  2. MVP клиентообразующий. В отличие от просто MVP, который проверяет основную идею продукта на жизнеспособность и функциональность, клиентообразующий MVP фокусируется на том, чтобы заинтересовать первых пользователей и получить обратную связь, которая поможет дальнейшему улучшению продукта.
  3. MVP Консьерж. MVP Консьерж — это способ тестирования нового продукта или услуги, при котором многое делается вручную, будто у вас есть личный консьерж, который помогает вам. Вместо того чтобы сразу строить полностью автоматизированную систему, вы делаете много работы за кулисами, чтобы понять, что на самом деле нужно вашим пользователям.
  4. MVP Чужой продукт. MVP “Чужой продукт” — это когда компания использует уже существующие продукты или инструменты, чтобы проверить свою идею, прежде чем вкладывать деньги в создание собственного продукта.
  5. MVP Одновариативного использования. MVP Одновариативного использования, или MVP с одним вариантом использования, это когда продукт создается с одной основной функцией или для решения одной конкретной задачи. Это создание инструмента, который делает только одно, но делает это хорошо.
  6. MVP одного клиента. MVP одного клиента — это когда компания или разработчики создают первую версию своего продукта специально для нужд или задач одного конкретного клиента. Это не просто базовая версия продукта для всех, а сфокусированная разработка, которая решает конкретные проблемы одного пользователя или компании.
  7. MVP Piecemeal. Вместо того чтобы разрабатывать каждый элемент продукта с нуля, команды комбинируют доступные компоненты, чтобы быстро создать работоспособную версию продукта. Сюда же входят Nocode, lowcode инструменты разработки
  8. MVP демо видео. MVP демо видео – это когда для проверки идеи продукта используется видеоролик, показывающий, как этот продукт будет работать, вместо создания самого продукта.
  9. MVP fake door. MVP “Fake Door” — это метод тестирования интереса к потенциальному продукту или функции, при котором компания создает иллюзию наличия этого продукта или функции, хотя на самом деле она еще не разработана. Это как когда в магазине висит реклама товара, которого на самом деле нет в наличии, чтобы посмотреть, сколько людей спросят о нем.
  10. MVP предзаказ. MVP предзаказ – это метод, при котором компании предлагают своим потенциальным клиентам возможность заранее заказать продукт, который еще не был полностью разработан или выпущен. Это помогает понять, насколько востребованным будет продукт, прежде чем он будет полностью готов, и помогает собрать финансирование для его разработки.
  11. MVP маркетинговая кампания. MVP маркетинговая кампания - это подход, при котором компания запускает простую и основную рекламную кампанию для проверки интереса к новому продукту или услуге. Вместо того чтобы вкладываться в большую и дорогостоящую кампанию, они начинают с чего-то маленького и простого, чтобы увидеть, как реагируют потенциальные клиенты.
  12. MVP email кампания. MVP email кампания — это когда компания запускает очень простую и базовую рассылку по электронной почте, чтобы проверить интерес к новому продукту или услуге.
  13. MVP лендинг. MVP лендинг – это создание простой веб-страницы (лендинга), целью которой является проверка интереса к новому продукту или услуге. Это как если бы компания поставила небольшой рекламный щит, чтобы увидеть, сколько людей остановятся и поинтересуются.
  14. MVP небольшая ниша. MVP для небольшой ниши — это когда разработка продукта или услуги нацелена на очень специфическую и ограниченную аудиторию. Это подход, при котором компания не пытается сразу угодить всем, а сосредотачивается на удовлетворении потребностей конкретной группы людей.
  15. MVP внутренний тест. MVP внутренний тест – это когда компания создает простую версию своего продукта и тестирует ее внутри организации, прежде чем показывать ее внешним пользователям или клиентам. Это репетиция перед большим выступлением, чтобы убедиться, что все работает как надо.

Growth Loop продукта

Growth loops answer a couple different questions:

  • What: How is the loop triggered? You want an action, or set of actions, that connects input and output.

  • Who: Who are the people involved in the loop? You want to identify where free users, paying users, suppliers, and others fit in.

  • Why: What is the deep need, problem, or motivation that drives the person to trigger the growth loop? If it’s not fundamental, the loop will patter over time.

Famous Growth loops

Матрица RACI

RACI Matrix Template

Матрица RACI – это схема эффективного распределения полномочий и ответственности в бизнес-процессах. Эта методика помогает избежать такой проблемы, как «размытие ответственности»: ситуации, когда становится непонятно, какой член команды за что отвечает – кто принимает решения, кто выполняет работу, а кто несет ответственность.

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

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

A – обозначает «Accountable», это тот, кто несет ответственность за всю задачу и результаты работы исполнителя. Участник с такой ролью следит за тем, чтобы задача была завершена в срок, но не обязательно решает ее сам. A-участники достаточно часто назначают задачи сотрудникам, исполняющим R-роль. Важный нюанс: у одной задачи должен был только один ответственный, чтобы все члены команды понимали, к кому обращаться за информацией или с какими-либо вопросами, однако при этом сам ответственный может являться одновременно и исполнителем.

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

I – первая буква английской фразы «Inform after doing», которая означает «оповещает после исполнения». Буквой I в таблице матрицы ответственности RACI обозначают участника проекта, который обязан быть в курсе принимаемых решений и хода выполнения задачи. I-участники по большей части не вовлечены в другие аспекты достижения результата, однако, поскольку результат влияет на их дальнейшую деятельность, им важно следить, за тем, что происходит.

Встречаются вариации матрицы RACI, включающие дополнительные буквы и роли:

  • RACI-VS – V, от «Verifier», означает «верификатор», то есть тот, кто проверяет результат работы на соответствие заблаговременно согласованным критериям, а S («Signatory» – «подписывающий»), обозначает лицо, отвечающее за сдачу работы заказчику.
  • RASCI – в этой аббревиатуре добавлена буква S (от «Support» – «поддержка»), она обозначает участника, который помогает ответственному лицу выполнять его работу.
  • RACIQ – здесь Q – первая буква слова «Quality», что в переводе с английского значит «качество», и, как не трудно догадаться, роль этого участника – проверка качества результата работы.
Health check матрицы
  • В RACI матрицу включают не фичи продукта, а этапы проекта, хотя их еще называют таски/задачи. Это может быть задача по разработке, проектированию, подготовке отчетности по завершению проекта, но не задача «передвинуть кнопочку.
  • Матрица лучше работает, когда рассматривают от 10 до 25 этапов проекта. 
  • Этап проекта должен выражаться через конкретный глагол, вроде «провести ревью», «опубликовать отчет», «оценить сроки», «составить расписание», «собрать данные», «утвердить концепцию».
  • В матрице лучше использовать роли, а не имена. Если завтра Васю сбивает автобус, пусть это цинично, но его роль будет исполнять другой человек.
  • Разрабатывать RACI матрицу лучше группой от 4 до 10 человек. Из одной головы можно неверно оценить ситуацию, а слишком большое количество человек — просто долго и сложно для обсуждения. Но перед утверждением RACI матрицы, каждый, кто будет в ней участвовать, должен увидеть свою роль и согласиться с ней. 
  • Лучше устанавливать A и R на минимальный соответствующий уровень.
  • Назначать на A — Accountable, т.е. наделять ответственностью можно только человека с полномочиями.
  • Сведите к минимум позиции I и С.
  • Если вы составили матрицу, то оповестите всех участников проекта о матрице, об их роли в проекте и уточните, уточните, согласны ли они с этой ролью. Если нет, матрицу придется дорабатывать.
  • RACI матрицу иногда приходится обновлять по ходу проекта, т.к. она может устареть.
  • проверка Вертикально(по ролям):
    • Слишком много R
    • нет пустых мест
    • слишком много a
    • нет R или A
    • Двойные позиции A/R, A/I
  • проверка Горизонтально(по этапам):
    • нет R
    • слишком много R
    • нет А
    • больше, чем одна A
    • Все ячейки заполнены на каждом этапе
    • нет C либо I
    • слишком много С, либо I
    • МНого двойных позиций

Пример правильной матрицы RACI

Навигация

Обратные ссылки

Вид графа