? ДАП – Дерево анализа проекта (альфа-версия)

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

Задача ДАП – (1) максимально быстро (за 1-2 часа) узнать общую картину существующего проекта, (2) описать «виденье» идеи проекта.

За последние 5 лет, ДАП был обкатан на более сотни проектов и дошел до своей зрелости.

!Важно! ДАП почти на 100% относится именно к IT-продуктам / услугам.

Предназначено для

1. Тех кто устраивается на работу, чтобы понимать серьезность намерений фирмы / проекта, в который они идут
2. Веб-студий, когда они знакомятся с заказчиком
3. Продуктовых команд, которые брейнштормят новую потребность или пытаются осознать чем стал их проект
4. Стартапов, когда они брейнштормят идею проекта
5. В принципе хороший тренажер, позволяющий верхнеуровнево описать и оценить проект

Дисклеймер. ДАП корнями уходит в Бизнес-анализ и Бизнес-моделирование.

Дисклеймер 2. Это альфа-версия, многое еще может поменяться. Апдейты будут в канале @davidshekunts_blog

Почему «Дерево»

Потому что в рамках любой главы вы можете сделать ответвление.

Как это работает:

В главе Потребность ваш проект может решать несколько потребностей, которые слишком друг на друга не похожи: разные Проблемы, разные Решения, они имеют разную ЦА, и так далее.

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

Пример ДАП будет рано или поздно (обновления ждите на канале)

Словарь

Терминология, которая используется в ДАП:

1. Дерево – сочетание всей информации в каждом узле
2. Узел – глава с ответами
3. Проект – под «проектом» можно подразумывать и «фирму», и «продукт», и «линейку продуктов» тут все зависит от размера компании, которую вы анализируете

Правила использования ДАП

1. Идите сверху вниз, глава за главой, не перескакивайте.
2. Если вы расписываете свою идею, ответ: «Не знаю» – НЕ котируется, идите и узнавайте.
3. Если вы используете ДАП, интервьюируя чей-то существующий проект, ответ: «Не знаю» – котируется и вы можете пропустить Узел.

Предисловие

1. Для описания ДАП идеально подходит Notion
2. А для визуализации мой совет использовать Miro или LucidChart
3. Поскольку бизнес всегда крутиться вокруг «Потребностей» клиентов и способов их удовлетворения, для анализа и выявления потребностей подходят любые методологии. Самыми современные и удобными назову: JTBD, CustDev, RAT. Полезные ссылки для изучения приведу в конце статьи.

Поехали

В секциях «пример» я чаще всего буду упомнять ? IT-Качалка ? – сообщество и экосистема по проектированию IT-продуктов, но иногда будут другие примеры для большей наглядности.

А еще огромная просьба: если вам совсем непонятно, что здесь написано, напишите мне в ЛС, это позволит сделать этот документ реально значимым.

Корень. Резюме

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

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

Пример:

«? IT-Качалка ? уникальный проект, направленный на сбор и распространение информации о способах проектирования IT-продуктов, с кучей уникальных механик, основная задача которого – собрать вместе специалистов и тех, кто хочет ими стать для взаимопомощи.

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

Потребности

Ответ на вопрос клиента самому себе: «Что я хочу, в определенный момент времени и зачем мне это?».

Существует такая методология JTBD (попсовенькое объяснение) и по факту Потребность в ДАП это Job Story из JTBD.

Описывается в Потребность в формате:

Глагол + Существительное + Контекст + Для того чтобы

Пример

1. Увеличить свой навык проектирования (backend, frontend), не имея достаточного количества этих задач на текущей работе, чтобы вырасти из Middle в Senior разработчика / из Senior в Architect.
   
2. Обучиться инструментам бизнес-аналитики, не прерывая работу, чтобы вырасти из UI до UX специалиста / быстрее отгружать более качественный дизайн заказов.
   
3. Понять принципы проектирования от требований до выбора стэка, не имея возможности участвовать в процессе разработки, чтобы быстрее принимать решения и утверждать план реализации проекта.
   

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

1. Стать Senior разработчиком
   1. -> Получать больше денег
      1. -> Ощущение «Успешности»
         1. -> Перекрываение невроза, вызванного травмой детства
            1. -> …
   2. -> Знать больше
      1. -> Социальное одобрение
         1. -> Перекрываение невроза, вызванного травмой детства
            1. -> …

Короче, вы поняли.

Самый просто способ определить уровень детализации: вы можете сформулировать такое Решение, которое ЦА может понять в рамках предложения: «Наше Решение закрывает вот эту Потребность».

Плохой пример: «Наши курсы сообщества прокачки скиллов проектирования помогут вам получить социальное одобрение!» – мысли клиента: «Чего блять?»

Хороший пример: «Наши курсы сообщества прокачки скиллов проектирования помогут вам быстрее стать Senior разработчиком!» – мысли клиента: «Да, часть работы Senior разработчика – это проектирование, так что все звучит логично!» – подсознание клиента: «А став Senior меня все зауважают.» – глубинное подсознание клиента: «Папа наконец-то услышит обо мне и вернется после 25-ти летнего похода в магазин за сигаретами…»

Как найти ответ? Провести CustDev + JTBD Interview (+ RAT) /Продуктовую аналитику (если уже есть продукт) / Рыночную аналитику.

Правила

Правила очень совпадают с правилами Job Stories:

1. Контекстом не должно быть прилагательное, например, «дешево», «быстро», а тем более неопределенное «выгодно», «эффективно» и так далее.
   
2. В формулировки потребности не должно быть ее решения.
   
3. И т.д. (добавлю ссылки позже)

Полезная инфа

Потребности одной Ветки должны быть похожи друг на друга. Если потребности сильно отличаются, но существуют в рамках 1-го Проекта, выделите их в отдельную Ветку.

Достаточно часто ветвление на этом уровне приводит к появлению подразделений в фирме.

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

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

ЦА

Отвечаем на вопрос: «У кого есть данные Потребности?»

Каждый пункт ЦА это «сегмент».

Как найти ответ? Определяется также в процессе CustDev + JTBD Interview / RAT, продуктовую и рыночную аналитику.

Как описать сегмент?

Это может быть крайне проблематично, особенно для B2C-ного сегмента, большой совет:

Чем меньше кол-во атрибутов ЦА в меньшем количестве слов, тем лучше.

Пример, нашей чтобы стало понятно:

1. «Middle разработчики» – работающий человек + понятна должность + понятна ставка + понятны пути роста
2. «Работающие UI/UX дизайнеры» – тоже самое
3. «Топы стартапа на этапе масштабирования» – тоже самое + момент наибольшей потребности
4. «Бизнес-аналитики» – вообще, это просто их работа, поэтому для них это повышение квалификации

Короче, потребность описывается в рамках профессиональных скиллов, поэтому ее просто описать и выявить ЦА.

Все гораздо сложнее, при попытке описать ЦА «приложения для помощи в лечение больной спины». ЦА можно сфомулировать так:

1. Люди, у кого больная спина
2. Люди у кого близкие с больной спиной.

Это много слов и много вариантов (там есть и пересечения ЦА IT-качалки), но чтобы сформулировать более точную картинку, надо делать CustDev, я его не делал по идее с больной спиной (пока что), так что не буду давать никаких комментариев.

И при этом все становится гораздо легче, если вы делаете, B2B продукт для автоматизации мед осмотров водителей перед выездами:

1. Гуглите или спрашиваете у специалиста области у каких фирм существуют штаты с водителями и мед.проверками
2. ???
3. Profit. У вас есть excel таблица с названиями фирм и их контактами.

То есть, вы знаете не «описание» ЦА, а конкретные фирмы.

Правило 1. не делайте более 6-ти сегментов

Правило 2. Последним сегментом ставьте «?», потому что в будущем вы обязательно найдете как минимум 1 неизвестный сегмент.

Характеристики ЦА

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

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

Как найти ответ? Во время предыдущих этапов обязательно спрашивайте у людей их характеристики и потом выявляйте паттерны.

3 типа характеристик:

1. Обязательно – без этих характеристик нельзя считать их ЦА
2. Приоритетно – если есть большой шанс, что будут «фанатами» (А-сегментом) продукта
3. Опционально – скидываете сюда разного рода характеристики, которые вы проверите и переведете в «Обязательное», или «Приоритетно», или выкините.

Пример

1. Middle разработчики
   1. Обязательно
      1. Текущая потребность в росте до Senior
   1. Приоритетно
      1. Уже проявляют активность в сообществах (например, хакатонеры)
2. Middle UI/UX дизайнеры
   1. Обязательно
      1. Работа / желание работать над проектами, требующими проработки UX
   2. Приоритетно
      1. Уже проявляют активность в сообществах (например, хакатонеры)
      2. Проходили / проходят курсы по UX
3. Топы стартапов
   1. Обязательно
      1. Проблема / потребность в понимании процесса проектирования, поскольку сейчас этап, когда это больше всего влияет на проект
   2. Приоритетно
      1. Стартапы УТП которых основан на технологической инновации.
      2. В проекте используется необычный стэк.

Целевые сегменты

Как бы не хотелось, но должны конкретные сегменты, которые выделяются больше всего.

Чтобы оценить целевой сегмент опишите каждый из сегментов по 10 бальной шкале:

1. Боль
2. Платежеспособность – деньги в платном продукте и время в бесплатном
3. Размер

Потом перемножьте и получите целевой сегмент.

Пример:

1. Middle разработчики
   1. Боль – 6 (упомянание потребности в 90% случаев, но не критично)
   2. Платежеспособность – 6 (переодическое затопление, но возможность работать в фирме, где есть время на развитие)
   3. Размер – 6 (в разрезе IT-Middle специалистов)
2. Middle UI/UX дизайнеры
   1. Боль – 5 (рынок не так часто требует этого скилла)
   2. Платежеспособность – 6 (одинаковая загрузка с разрабами)
   3. Размер – 3 (меньше, чем разрабов)
3. Топы стартапов
   1. Боль – 7 (особенно при заказной разработке)
   2. Платежеспособность – 3 (у них никогда нет времени)
   3. Размер – 2 (их мало)

Итоги

1. Middle разработчики = 6 * 6 * 6 = 216
2. Middle UI/UX дизайнеры = 5 * 6 * 3 = 90
3. Топы стартапов = 7 * 3 * 2 = 42

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

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

Правило. Целевых сегментов должно быть не менее 1, но не более 2-х.

Поэтому пока мы не отработаем до конца, целевым сегментом ставим Middle Разработчиков.

Правило 2. Далее советую сделать разветвление и начать первую ветку с целевого сегмента.

Поэтому мы создаем Ветку «Middle разработчики» и продолжаем описывать ее.

Решение

Описание что могло бы решить Потребность.

Решение должно быть абстрактным, без частностей (а именно конкретных Продуктов, о которых ниже)

Например:

«Решением потребности в профессиональном росте могут быть: (1) дополнительное образование или (2) помощь в смене места работы на то, где более профессиональный коллектив»

Правило 1. определяйте множество Решений, даже, если ваши Продукты их не покрывают. Это даст идеи для роста и развития Проекта.

Правило 2. Решение должно четко описывать, как оно соотноситься с Потребностью и давать понимание полезности в 1-2-х предложениях.

Проблема

Почему у клиентов не решается Потребность или какие они затруднения испытывают при ее решение существующими Продуктами.

Пример:

1. Отсутствие задач на работе
2. Отсутствие материалов по тематике
3. Отсутствие понимания «с чего начать?»

Как найти ответ? Провести CustDev, JTBD Interview, RAT, Продуктовую аналитику (если уже есть продукт), Рыночную аналитику.

Продукты

Продукт – это услуга или товар (в IT чаще всего это можно назвать «инструментом»), за который вам платят клиенты.

Продукт – это всегда Решение Потребности.

Пример:

«Курс «Как создать IT-проект и не про?баться» является примером Решения потребности в проф. росте через обучение»

«Услуга ? IT-Ментор ? – пример Решения потребности в проф. росте через личные консультации»

Конкуренты

Это чужие продукты, у которых вы будете переменивать клиентов.

Если существует потребность, значит человек его уже как-то ее решает. Чтобы перейти к вам, он должен (1) перестать применять текущее решение, (2) начать пользоваться вашим.

3 вида конкурентов:

1. Прямая конкуренция — продукты выполняют одну и ту же работу одинаковым способом (McDonalds и BurgerKing).
   
2. Непрямая конкуренция — продукты выполняют одну и ту же работу разными способами. Например, Skype соперничает с полетами бизнес-классом, потому что у них одинаковая работа — провести деловую встречу.
   
3. Косвенная конкуренция — продукты выполняют разную работу с конфликтующим результатом. Например, Петя любит бургеры, но в то же время хочет быть спортивным. Бургер в BurgerKing и фитнес-браслет FitBit решают разные проблемы, но борются за одну целевую аудиторию.

Списзжено отседа

В нашем случае:

1. Прямая конкуренция (борьба за время)
   1. Курсы
   2. Хакатоны
2. Непрямая конкуренция (борьба за знания)
   1. Новая работа с командой профи и задачами проектирования
   2. Работа, в которой Senior про понимание утилитарного программирования
3. Косвенная конкуренция (борьба за удовольствие)
   1. Отдых и развлечения вне профессионального времени

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

Как найти ответ? Во время CustDev + JTBD Interview сосредоточиться на вопросе: «Как вы сейчас решаете потребность?» + пройтись по гуглу ключевыми запросами потребности, проблемы и решения.

Отличия вашего решения (УТП)

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

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

Как найти ответ? Во время CustDev + JTBD Interview сосредоточиться на вопросе: «Почему вы пользуетесь / выбрали именно наш продукт?»

Правило. Указывать не более 6-ти отличий.

Ключевой недостаток

В чем ваше решение проигрывает конкурентам по 2-м категориям:

1. Внешние (потребительские) недостатки – что может заставить человека передумать / уйти от вас.
   
2. Внутренние недостатки – в чем вы проигрываете конкурентам по внутреннему устройству вашего бизнеса.

Как найти ответ? Сравнить вашу и чужую бизнес-модель / ДАП.

Пример:

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

Экономика

Если утрировано, то тип монетизации и издержек.

Ооочень вариативная: у масштабных продуктовых решений это может быть Unit-экономика, у локальных активные продажи, у специализированных приход расход по стандартам Бизнес-плана.

Также монетизация может быть отложенной или косвенной.

Как найти ответ? Посмотреть на конкурентов, тестировать разные варианты.

Пример

В случае в IT-качалке монетизация – сбор коммьюнити (человеческого ресурса) + инструмент увеличения личного бренда участников.

Получается, что основной ресурс IT-качалки не измерим в деньгах, но, может быть монетизирован в будущем тем или иным образом.

Цифры и Метрики

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

Здесь важно выявить:

1. Ключевые метрики результата
2. Ключевые метрики, которые на этот результат напрямую воздействуют
3. Расходы

Вариантов тоже так много, что я даже вкратце не могу описать, эта тема на 10 книг.

Пример

В случае с качалкой

1. Ключевые метрики результата
   1. Кол-во месяцев пребывания в качалке
   2. Кол-во решений, предоставленных на Тренировках
   3. Дельта ежемесячного притока
2. Ключевые метрики воздействия на результат
   1. Кол-во созвонов 1 на 1 участников IT-качалки
   2. Кол-во написанных статей перемноженная на коэффициент реакции: (лайки + дислайки + комментарии) / кол-во просмотров
3. Расходы
   1. Время тренеров
   2. Стоимость рекламы

Каналы маркетинга

Через какие каналы происходит распространение информации о проекте.

Существуют 2 типа каналов

1. Пассивные – когда одно действие самостоятельное (сарафано) распространение информации (вирусная реклама, о которой пишут СМИ, полезная статья, которую публикуют у себя на страницах и подобное)
2. Активные – реклама, за которую вы платите и имеете с нее трафик.

Причины создания проекта

Описать «почему» решили вообще создавать проект.

Это очень интересный пункт, потому что он может сразу подсказать, насколько проект жизнеспособный.

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

Устройство компании (орг. структура)

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

Основные сущности Орг. структуры:

1. Проект – временно́е предприятие (процесс), направленное на создание уникального продукта, услуги или результата. У каждого Проекта обязательно есть Ответственный и Задача. Проект может использовать одну или несколько Команд, а может состоять только из одного Ответственного. Проект может быть частью другого Проекта или относиться к нескольким другим Проектам.
   
2. Софт – набор программ, ответственных за осуществление какого-то набора функционала.
   
3. Команда – набор людей, которые осуществляют конкретный набор функций, чаще всего, в рамках какого-то одного или нескольких Проектов. Один и тот же человек может участвовать в разных Командах.
   
4. Подразделение (Компонента) – полностью схоже с Проектом за исключением того, что не имеет временного ограничения и вместо Задачи есть функционал, который Подразделение предоставляет.

О способах формирования орг. структуры я напишу отдельную статью (или серию статей).

Полезные ссылки

…

Итого

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

Гораздо больше контента и развлечений в Telegram-канале