Введение в управление разработкой цифрового продукта

Занятие 2 ВВЕДЕНИЕ В УПРАВЛЕНИЕ РАЗРАБОТКОЙ ЦИФРОВОГО ПРОДУКТА 1. ЦИКЛ РАЗРАБОТКИ ПРОДУКТА Универсальная модель double diamond 1. На первом этапе: вы максимально расширяете собственный контекст, на иллюстрации есть стрелочка, для того, чтобы обучить свою нейросеточку всем кейсам и сочетаниям информации, которым только возможны. Вы проводите исследования, интервью, используете все возможные инструменты, чтобы получить как можно больше информации. 2. На втором этапе - этапе определения(DEFINE) : вы наоборот, сужаете свой разум, чтобы из возможных вариантов решения выбрать лучшее. 3. На третьем этапе: предлагаете как можно больше вариантов решения задачи. Вы делаете разные прототипы, пробуете сделать продукт разными способами. 4. На четвертом этапе: из всех вариантов решения выбираете лучшее, т.е. снова сужаете свой разум. Это похоже на два бриллианта: расширение-сужение-расширение-сужение. Поэтому модель называется double diamond. После первичной работы над продуктом или фичой, вы приступаете к развитию. Развитие тоже может проходить через double diamond-модель.Эта модель и является основной для разработки любого продукта. Double diamond-модель основана на двух режимах работы мозга: • Diffuse mode • Focused mode. В режиме Focused mode - фокус на главной задаче: не обращаете внимания на обстоятельства вокруг, все ресурсы тратятся на определение лучшего варианта решения. В режиме Diffuse mode - вы расслаблены: мысль движется по нейронам вашего мозга абсолютно свободно, перескакивая с одной темы на другую. В режиме Diffuse mode в вашу голову приходят светлые идеи, нестандартные решения, а в режиме Focused mode вы выбираете из этих решений лучшее. Discovery и delivery Процесс разработки любого продукта разделяется на discovery и delivery. В режиме discovery идет поиск информации, рассматривается максимальное число вариантов решения задачи или проблемы. В режиме delivery вы доставляете до пользователя то, что нашли в режиме discovery. Пример: представим, что надо сделать видеосвязь в приложении по изучению иностранного языка. В режиме discovery проводится интервью с пользователями, чтобы понять, что они ожидают от видеосвязи, какие у них стоят задачи, как можно им помочь. Вы ищете варианты реализации видеосвязи в вашем приложении, смотрите, как это реализовано у конкурентов, придумываете, как это может выглядеть в вашем приложении. Когда вы определились с решением, приступаете к delivery: рисованию конкретных макетов конкретного решения, разработке, тестированию. Делаете все, чтобы пользователь увидел ваше решение. Цикл разработки нового продукта 1 этап: исследование. Возникла мысль создать что-то новое. Собирается информация о рынке, пользователях, ищется проблема, которую надо решить (или подсматривается у конкурента): ресерчи, интервью, customer development, отчеты консалтинговых агентств или смотрят, какие решения вообще предлагаются на рынке. На этом этапе есть два элемента: - проблема или задача, которую хочет решить пользователь, - решение, которое предлагаете вы. 2 этап: выдвижение гипотез. Какой продукт делать, по какой цене можно продавать и по какой цене можно привлекать пользователей. Гипотезы проверяются на пользователях, запускается тестовое привлечение и продажи без продукта. Повторяют столько раз, чтобы достичь успеха. 3 этап: MVP. После проверки гипотезы решения, создается MVP. MVP - минимально жизнеспособный продукт, который решает проблему пользователя. Дизайнеры рисуют. Разработчики разрабатывают. Набирают команду продаж и поддержки. Стартует привлечение. Стартуют продажи. Продукт запускается. Развитие действующего продукта 1 этап: обозначаем какую задачу хотим решить - проблему в продукте или задача поднять метрику. Продакт-менеджер изучает проблему, аналитику, поведение пользователей (fullstory), проводит интервью с теми пользователями, кто успешен в рамках задачи и наоборот, отвалился. Проводится ресерч по конкурентам и штурм поиска решения с командой. 2 этап: выдвигаются варианты решения, варианты приоритезируются. Те варианты, которые решено проверить, проектируются (сначала прототип). Прототип показывают пользователям, которые дают обратную связь. Прототип дорабатывают и снова показывают пользователям. Так происходит несколько раз. Работают только с прототипами или макетами. Этап завершается, когда обратная связь от пользователей перестает давать полезные сведения. 3 этап: проектирование эксперимента ( а/б-тест, сплит-тест). Рассчитывают, сколько пользователей должно увидеть тот или иной вариант фичи. В первом варианте оставляем все без изменений, во втором варианте показываем обновления, которые сделали. Дорабатывают прототип до полноценного продукта (финальный дизайн, разработка).Запускают сплит-тест. Половина пользователей теперь видят старый продукт, а половина новый. После тестового периода проводят подсчеты результатов теста. Если тест решил проблему или улучшил метрику, фича раскатывается на всех пользователей. 2. КОМАНДА РАЗРАБОТКИ, РОЛИ В КОМАНДЕ, ЗОНЫ ОТВЕТСТВЕННОСТИ Команда разработки 1. Продакт-менеджер - цели и решения; 2. Прожект-менеджер - процессы; 3. Ресерчеры - информация; 4. Дизайнеры - UX и макеты; 5. Аналитики - данные и цифры; 6. Разработчики - код и сам продукт ; 7. Тестировщики - чтобы всё работало ; 8. Маркетологи - рассказать о том, что это за продукт и зачем пользователю его покупать . Команды могут отличаться по составу. Это зависит от специфики продукта и компании. Любой участник не обязателен. Путь задачи в работе 1. Продакт-менеджер ставит цель; 2. Ресерчер или продакт ресерчит и проводит интервью; 3. Продакт и дизайнер проектируют решение; 4. Продакт+дизайнер+ресерчер тестируют решение; 5. Дизайнер делает итоговое решение; 6. Продакт или аналитик описывает задачу; 7. Разработчик пишет код; 8. Тестировщики тестируют + финально тестирует продакт; 9. Фича катится в А/В тест; 10. Все ждут,пока количество пользователей будет достаточным; 11. Аналитик обсчитывает результаты теста, делает вывод; 12. Продакт принимает решение, раскатывать ли эту фичу на всех пользователей или нет; 13. Маркетолог рассказывает о фиче всем, если было принято положительное решение; 14. Прожект или продакт делает так, чтобы процесс нигде не поломался. Задачи и зона ответственности продакт-менеджера 1. Определяет цель работы команды; 2. Исследует потребности пользователя, задачи бизнеса и аналитику; 3. Ставит задачи другим участникам команды; 4. Совместно с дизайнером принимает решение, как будет работать продукт и как будет выглядеть; 5. Обсуждает с разработкой варианты реализации; 6. Проверяет реализацию; 7. Принимает решение о сплит-тесте; 8. Принимает решение о раскатке фичи; 9. Управляет динамикой команды и несет ответственность за результат; 10. Знает, как монетизировать фичу и уверен, что она прибыльна. Задачи и зона ответственности проджект-менеджер 1. Принимает решение, по какому фреймворку работать на проекте; 2. Контролирует ресурсы и время согласно плану; 3. Контролирует динамику команды; 4. Пишет на скорость; 5. Контролирует рабочие процессы и коммуникацию; 6. Разрешает сложности по пути; 7. Делает так, чтобы заданная задача не застряла по пути от первого участника до реализации; 8. Делает так, чтобы заданная задача реализовалась. Задачи и зона ответственности ресерча 1. Изучает рынок; 2. Изучает конкурентов; 3. Визуализирует данные; 4. Проводит интервью, кастдевы, user research; 5. Проводит опросы, UX-тесты; 6. Рекрутирует респондентов; 7. Собирает полученную информацию в удобный вид. Задачи и зона ответственности дизайнера 1. Совместно с ресерчером или продактом изучает пользователяи сценарий пользователя; 2. Изучает сценарии использования продукта; 3. Решает задачу пользователя в продукте; 4. Рисует прототипы и проверяет их на пользователях; 5. Рисует макеты для реализации; 6. Определяет UX; 7. Определяет интерфейсы; 8. Определяет внешний вид продукта; 9. Следит за тем, чтобы в реальности все выглядело как на макетах. Задачи и зона ответственности аналитика 1. Постоянно мониторит данные и ищет выбросы; 2. Готовит данные для гипотез; 3. Проводит глубокую аналитику точки приложения усилий продакта; 4. Проектирует сплит-тесты; 5. Обсчитывает сплит-тесты; 6. Обеспечивает сквозную аналитику по продукту и аналитическую инфраструктуру. Задачи и зона ответственности разработчика 1. Определяет пути реализации фичи; 2. Оценивает трудозатраты задач; 3. Вписывает фичу в текущий продукт и текущую архитектуру; 4. Кодит; 5. Интегрирует фичу с другими; 6. Предлагает альтернативные решения; 7. Исправляет код, свой и других; 8. Делает так, чтобы все работало, поддерживает продукт и чинит баги. Задачи и зона ответственности тестировщика 1. Хорошо вникает в то, какой результат нужен по задаче; 2. Анализирует постановку задачи и продумывает сценарий тестирования; 3. Сразу после реализации прогоняет фичу через автотестирование и ручное тестирование по кейсу; 4. Пишет автотесты; 5. Контролирует разработчика, чтобы он исправил баги; 6. Держит в голове сотни странных кейсов, где все должно работать; 7. Понимает, как фича вписывается во всю логику работы продукта; 8. Может посоветовать решение. Задачи и зона ответственности маркетолога 1. Участвует в исследованиях пользователя, рынка, конкурентов; 2. Приносит потребности рынка; 3. Хорошо знает продукт, гипотезу и фичу; 4. Налаживает коммуникацию между продуктом, продажами, маркетингом; 5. Описывает фичу для всех материалов; 6. Знает, как привлечь пользователей на фичу; 7. Обеспечивает PR-поддержку; 8. Обеспечивает информирование пользователей и команды; 9. Знает, как монетизировать фичу; 10. Знает, как фича впишется в образ продукта у пользователей. 3. ЧЕМ ОТЛИЧАЮТСЯ ПРОДАКТ-МЕНЕДЖЕРЫ, ПРОДЖЕКТ-МЕНЕДЖЕРЫ И PRODUCT OWNERS Зоны компетентности • Функции продакт-менеджера находятся на стыке бизнеса, рынка и разработки. Он должен понимать как продукт зарабатывает, как позиционируется себя на рынке, из чего состоит и как технически реализован. • Проджект-менеджера интересует только продукт, который он разрабатывает, • Продакт отвечает на вопросы: “что делать” и “зачем делать”. Проджект на вопросы :“как можно сделать” и какие ресурсы нужны”. Специфика Продакт: Проджект: 1. 2. 3. 4. 5. 6. Эмпатия к пользователям Понимание рынка, маркетинга Направлен вовне команды Отвечает за результат продукта Должен уметь проводить эксперименты, понимать аналитику, знать способы монетизации, общаться со стейкхолдерами. Ответственность за продукт (долгая, пока не умрет продукт) 1. 2. 3. 4. 5. 6. Эмпатия к команде Понимание разработки Направлен внутрь команды Отвечает за результат команды Должен отлично разбираться в управлении проектами, фреймворках разработки, способах мотивации, инструментах управления командой. Ответственность за проект (закончился и ладно) на одном человеке. Иногда продакт = продакт + проджект Это работает, когда: 1. Небольшая команда; 2. Несложный проект; 3. Проще сконцентрировать всю ответственность Продакт должен быть крутым проджектом, даже если сейчас не занимается проджект-менеджментом. Product-owner Есть 2 категории специалистов, которые называются продакт-овнер, “владелец продукта”: 1. Head of Product, крутой продакт, который отвечает за весь продукт. 2. Почти проджект-менеджер в методологии Scrum, который отвечает за бэклог, т.е. список всех задач, которые уйдут в разработку, следит за порядком. Если поделить цикл разработки продукта на discovery Продуктовые исследования и delivery Поставка продукта, то продакт-менеджер ближе к discovery, сама команда разработки полностью delivery,а продакт-овнер находится на пересечении. 4. КАК РАБОТАЕТ РАЗРАБОТКА? Основные этапы разработки: 1. Постановка задачи. 2. Оценка задачи. 3. Разработка. 4. Тестирование и деплой. Постановка задачи осуществляется, когда: 1. Есть дизайн; 2. Понятен сценарий; 3. Гипотеза проверена “руками”; 4. Задача ставится в инструмент управления разработкой (Джира, Трелло...). Как продакту влиять на задачу на этом этапе: - ставить задачу чётче и подробнее, описывать результат, а не решение. Оценка задачи: Разработка смотрит задачу, определяет, сколько ресурсов потребуется: 1. Задача оценивается на основе опыта. 2. В часах, в Story Points или в неделях. 3. Чем точнее оценка, тем лучше можем планировать ресурсы. 4. Чем “неизвестнее” задача, тем больше погрешность. 5. Свои инструменты измерения — это ок. Курицы, ослы, лошади и слоны. Как продакту влиять на оценку: - задавать вопрос: а почему? - спросить второе мнение или командное мнение. Разработка - самый объемный этап. Разработчики кодят и создают продукт. 1. Часто задачи сложнее, чем кажутся. 2. Нужно учесть много взаимосвязей. 3. Иногда требуется привлечение архитектора. Как продакту влиять: ● обращаться с вопросами только к тимлиду; ● следить за ходом задачи в Jira ; ● приходить на дейлики(ежедневные встречи команды разработки),где можно узнать о ходе работ; ● продакт может взять на себя взаимодействие с внешним миром; ● задавать вопросы: что я могу сделать? что сейчас мешает? Тестирование и деплой Тестировщики проверяют, как реализация совпадает с заданием. Хорошие тестировщики тестят не только фичу, но и всё вокруг, включая голову. Автотесты — хорошо, но это только часть тестирования. Ручное тестирование необходимо. Деплой - разворачивание, публикация продукта там, где им может пользоваться конечный пользователь. Деплои происходят: 1. Раз в период. 2. Continuous delivery - выкатывание новой версии продукта сразу, как только она готова. Как продакту влиять: - пройдите руками основные сценарии; - контролируйте, чтобы не уходило слишком много времени на тестирование. 5. WATERFALL И AGILE Методологии разработки - Waterfall и Agile. • Waterfall - это поэтапное исполнение плана, который разработан в самом начале. • Agile - это работа короткими циклами, после каждой итерации готов результат. Отличия Waterfall и Agile Waterfall 1.Результат в конце 2.Задание и ресурсы неизменны 3.Команда работает поэтапно 4.“Добавить фичу” очень сложно 5.Понятно, что произойдет Когда продукту подходит Waterfall 1. Когда требования понятны сразу. 2. Когда есть заказчик, который платит за результат, который согласован. 3. Когда есть возможность добавить ресурсы: разработка, время, деньги. Пример: заказная разработка, госуслуги, атомные электростанции, аэропорты. Agile 1.MVP-MVP2..- важен итог каждого этапа 2.Все меняется каждую итерацию 3.Команда работает циклами 4.“Добавить фичу” просто 5.Результат непредсказуем Когда продукту подходит Agile 1. Когда требования меняются. 2. Когда есть потребитель,чьи требования непонятны. 3. Когда ресурсы фиксированы. Пример: практически вся коммерция. 6. ДРУГИЕ ФРЕЙМВОРКИ РАЗРАБОТКИ SCRUM • Scrum - это практическое применение принципов Agile к разработке. В Scrum есть много специфических ритуалов и ролей. • Сначала продакт-овнер производит груминг бэклога,т.е. разбирает бэклог и формирует задачи для команды разработки. Далее передает эти задачи в планирование спринта. Вся команда собирается, планирует задачи и оценивает необходимые затраты на разработку, включается в работу. В процессе работы команды каждый день встречаются на скрам-митинге(дейлике). В конце итерации представляют все, что у них получилось заказчику (демо) и проводят ретроспективу, т.е. выясняют, что можно было сделать по другому в процессе этой итерации. Во всем этом им помогает скрам-мастер. • Scrum требует тщательного внедрения, но подходит большинству команд. Kanban • Kanban-доска - инструмент визуализации. Может быть виртуальной (Trello) или реальной. Доска поделена на колонки. На листочках пишут этапы разработки и задачи. Листочки прикрепляют к доске в первую колонку (бэклог). Постепенно, когда задачи берутся в работу, листочки перемещаются по колонкам слева направо. У каждой колонки свой статус. Любая задача в Kanban проходит путь по доске: от первой колонки до последней. • Kanban подходит для самоорганизованных команд с сильным менеджером. Инкрементная и итеративная модели • В инкрементной модели вы представляете себе образ или результат продукта, который у вас получится. Но к работе приступаете по частям. Сначала делаете небольшую часть продукта, но по этой части нельзя сказать каким будет продукт и ей невозможно воспользоваться. Дальше делаете другие части продукта и соединяете их как пазл. Только в конце появится полноценный продукт. Это довольно близко к методологии Waterfall. • Итеративная модель очень похожа на Agile, или такую модель еще называют методом прогрессивного JPEG. В этой модели результат получают в самом начале. Результат будет некачественным, не очень понятный, но в целом есть представление о результате разработки продукта уже после первой итерации. После второй итерации этот образ уточняется, после третьей становится еще более точным. И так до момента, пока не получите полноценный продукт. 7. RUN, CHANGE, DISRUPT Виды деятельности: run, change, disrupt. • Run (текущая деятельность) - процессное управление текущей деятельностью. • Change (изменения) - проектное управление при внедрении новых продуктов и технологий. • Disrupt (инновации) - стартапы,новые бизнес-модели. Run (текущая деятельность) 1. Операционная работа, которая обеспечивает непрерывную работу компании. 2. В работе продакт-менеджера: текущие звонки, дейли-митинги, то, что приходится делать каждый день и что не приносит новых результатов. 3. Понятно, что делать. Как оптимизировать такую деятельность: • выделять конкретные слоты времени, лучше вечером; • делегировать по-максимуму; • автоматизировать. Change (изменения) 1. Изменения и проекты, которые меняют компанию. 2. Все эксперименты и ресерчи. 3. Все принятые решения об изменениях. 4. Обучение (если привязано к практике). 5. Непонятно, что конкретно делать, приходится думать. Как повысить процент такой деятельности: • выделяйте самые продуктивные часы; • бронируйте время; • замеряйте, сколько времени потратили на change. Disrupt (инновации) 1. Cоздание кардинально новых бизнес-моделей. 2. Прорывные идеи, которые способны «перевернуть» бизнес. 3. Кардинально изменение воронки и конверсий. 4. Полная неопределенность и творчество. Как повысить вероятность такой деятельности: • оставляйте время на “подумать”; • практикуйте “вид с вертолета”; • стратегические сессии. Пример разных видов деятельности: • разработка приложения банка. Операционная работа по организации — run. • Сделать функции — change. • Сделать мессенджер — disrupt. Чем меньше run и чем больше change (а тем более disrupt), тем больше пользы вы приносите бизнесу и миру. 8. GROWTH-HACKING Growth-hacking - это: 1. Методология быстрого масштабирования и роста компании без масштабирования затрат. 2. Подход, обеспечивающий рост через нестандартные подходы и практики. 3. Культура команды, основанная на экспериментах с целью роста компании. Growth-hacking находится на стыке трех компетенций: - креативность и маркетинг; - данные и эксперименты; - автоматизация и разработка. Примеры Growth-hacking Skyeng В самом начале главное окно выглядело по-другому. Оно состояло из огромной рабочей поверхности и маленького окна, где ученик видел учителя. Считалось, что вид учителя не важен, ведь самое главное происходит там, где ученик делает упражнения. Но провели исследование и выяснили, что это не так. Те студенты, которые видели учителя, обладали особой связью с ним. У таких студентов были лучше результаты. Решили провести эксперимент: окно общения с учителем увеличили в несколько раз (стало занимать 1⁄2 экрана).Метрики выросли в разы: получили большой прирост в интенсивности обучения, в продолжительности обучения, в выручке с каждого пользователя. Это оказалось удачной попыткой Growth-hacking. Clubhouse Главным инструментом Growth-hacking в Clubhouse стали инвайты. Это создание искусственного повышенного спроса на продукт и доступ к нему только по инвайтам, которые ограничены. Через какое-то время количество пользователей стало стремительно расти. Компания и продукт получили огромный рост за несколько недель. Это удивительно хорошо работающая механика. Growth-hacking-инструменты 1. Определение точки приложения усилий: взлом привлечения, взлом конверсии, взлом монетизации, взлом вовлечения. 2. Чем больше экспериментов, тем лучше: действовать HADI-циклами. HADI-цикл делит работу на этапы: гипотеза - действие - данные - выводы - гипотеза - ... Чем больше таких циклов провести, тем больше получится информации, и тем больше вероятность найти ту метрику, на которую может повлиять Growth-hacking. Подходы работы Growth-hacking Работа по пиратским метрикам - AARRR • Acquisition - привлечение пользователей • Activation - вовлечение пользователей в продукт • Retention - возвращаемость пользователей • Referral - то, как часто пользователи приглашают друг друга • Revenue - уровень монетизации, который исходит от каждого конкретного пользователя Если работаете по пиратским метрикам, то все гипотезы и все действия должны фокусироваться на этих метриках. Отдельно рассмотрим реферальность. Реферальная система - это система, в которой пользователь может пригласить друзей тоже использовать этот продукт и получает за это бонус. Это очень эффективная схема. AHA-moment • Это техника определения того момента в продукте, когда пользователь понимает ценность продукта (момент восторга). Этот момент хорошо использовать, чтобы предложить пользователю покупку или подписку. • Growth-hacking требует глубокого понимания продукта и маркетинга. Следует изучать примеры постоянно и применять их в продукте. 9. ПРИМЕРЫ SKYENG И КОНТУР Skyeng Это большая компания, которая занимается образованием детей и взрослых. Компанию оценивают в 130 млн.$, выручка 1-3 млрд. В Skyeng работают 7000 сотрудников, без учета учителей (по состоянию на 2020 г). В Skyeng: ● 30-40 продуктовых команд; ● есть ресерчеры, мало разработки; ● нет проджектов; ● гипотезы и эксперименты тщательно обсчитываются; ● главная цель продуктовых команд — деньги; ● у команд свой бюджет и ROI, каждый продакт — немного предприниматель, ответственный за прибыль команды. СКБ Контур Ещё более крупная компания. Стоимость компании оценивается в $657 млн.$.,18 млрд. выручки за 2020г. СКБ Контур создает сервисы для бизнеса. В компании работает 10 000 сотрудников (по состоянию на 2021 г). В СКБ Контур: ● нет продактов. Официально. Более 50 команд. ● много времени уделяется UX и ресерчам, много разработчиков; ● продакт=прожекты; ● гипотезы и эксперименты должны быть полезны пользователю; ● главная цель — счастье пользователей. А о деньгах пусть думает отдел продаж. В зависимости от типа бизнеса, компании и рынка, продукт имеет разные цели, разные команды и процесс. Нельзя приложить успешный процесс одной компании на другую и получить такой же результат. Нет универсальных рецептов или фреймворков. ДОПОЛНИТЕЛЬНО: Главный навык продакта — приоритизация. Фич, гипотез, задач. Проблемы: 1. Нельзя сравнивать несравнимое 2. Готовые схемы не подходят 3. Все очень важное План КОНСПЕКТА: 1. Бэклог, формулировка задач в бэклоге, груминг бэклога 2. Способы наполнения бэклога 3. Практика: составим бэклог на примере продукта. 4. Приоритизация: Impact/Effort, ICE, RICE, ROI 5. Приоритизация: MosCow, KANO, Buy the Feature, Иэна Маккалистера 6. Собственная модель приоритизации с развесовкой приоритетов 7. Практика: отскорить бэклог Бэклог Задачи в бэклоге могут быть ● Фичи, функции, новые сценарии пользователей ● Инфраструктурные и другие сервисные ● Эксперименты и проверка гипотез, сплит-тесты ● Исправление багов ● Рефакторинг Груминг бэклога 1. Актуализация 2. Дополнение недостающими элементами 3. Удаление ненужных 4. Добавление нужных 5. Приоритизация Результат — готовый список задач для разработки и не только Какие части есть в классической задаче в бэклоге ● User story (я, как бухгалтер, хочу скачать календарь сдачи отчетности в пдф, чтобы распечатать и повесить на стену) ● Метрика, которую мы двигаем ● Требования к функциональности ● Макеты/дизайн ● Оценка трудозатрат ● Приоритет ● ID, теги, тип задачи Наполнение бэклога Откуда берутся задачи? ● Руководство и стекхолдеры ● Команда ● Интервью, кастдевы ● Рынок и конкуренты ● Запросы клиентов ● Обращения в техподдержку ● Отдел продаж ● Аналитика и точки роста в продукте Приоритизация: Impact/Effort, ICE, RICE, ROI Impact/Effort ● Оцениваем Impact/Effort ● Сначала High Impact/Low Effort ● Потом Low Impact/Low Effort и High Impact/High Effort. ● Не делаем Low Impact/ High Effort Пример. 1. Фича 1, импакт высокий, эффорт высокий 2. Фича 2, импакт высокий, эффорт низкий 3. Фича 3, импакт низкий, эффорт низкий ● когда все понятно, есть North Star метрика и понятно, как все фичи на неё влияют ● когда задачи однотипны, команда сосредоточена на одной цели, нет раздербанивания фокуса ● когда у команда нет техдолга, а продукт прост и понятен ТО ЕСТЬ НИКОГДА ICE (Не забудьте, в ease обратная шкала) ● Когда KPI команды понятен и един ● Когда команда хорошо навострила чуйку RICE ROI • Фича Х.Ожидаемая выручка от фичи 10 000 000 • Ожидаемые затраты 4 000 000 • Профит 6 000 000 • ROI = 6 000 000 / 4 000 000 *100% = 150% • Когда цель команды — только деньги. • Когда умеем привязывать фичи к деньгам (знаем юнит-экономику и умеем прогнозировать LTV) • Когда затраты на разработку очень хорошо прогнозируемы MosCow • Звучит классно • Но как понять, что must, а что could? • «Делайте хорошо, плохо не делайте» KANO • Удовлетворенность клиентов функциями нашего продукта зависит от уровня предоставляемой функциональности (насколько и насколько хорошо они реализованы); • Вы можете определить, как клиенты относятся к какой-либо функции через анкету. • Первый вопрос спрашивает наших клиентов, как они себя чувствуют, если у них есть эта функция; • Второй — как они себя чувствуют, если у них нет этой функции. • Одномерные функции (performance): чем больше мы предоставляем этих функций, тем более удовлетворены клиенты • Обязательный функции (must be): ожидаются клиентами, если продукт их не имеет, он будет неполным или плохим • Привлекающие функции (attractive): неожиданные функции, которые вызывают очень положительную реакцию • Неважные функции (indiffirent): функции, пристутствие которые не имеет никакого значения. Обязательные > Одномерные > Привлекательные > Неважные Сложно и субъективно Buy the Feature Делим ресурс команды на у.е. Например, всего 920 часов (исключить дейлики и прочее). Это будет 1000 долларов, каждый доллар весит 0,92 часа. Примерно оцениваем все фичи в долларах. • Фича 1 — 120 долларов. • Фича 2 — 85 долларов. • Фича 3 — 40. И так далее. • Скорее всего, суммарно фич сильно больше, чем «бюджет команды». • Оценивающим выдаем бюджет — 1000 долларов и список фич с описанием каждой. • Получится типа «меню».- новый лендинг 180$ • исправление проблемы 130$ • опечатку поправить 35$ • новая большая фича 740$ • новая небольшая фича 340$ • Для стейкхолдеров: запереть в комнате, выдать меню фич и доллары, пущай договариваются, что купят. • Для клиентов: дать клиенту доллары и посмотреть, как распределит. • Когда совсем непонятно и надо быстро отприоритизировать. • Когда клиенты однородные. • Когда руководство не может договориться. Подход Иэна Маккалистера • Разбиваем относительные приоритеты и ресурсы: 10% на баги, 40% на инфраструктуру, 30% на рост, 20% на удобство юзеров (например) • Внутри блока разные приоритизации на ваш выбор • Аналогично, если на 3 команды продактов — одна команда разработки • Работает хорошо как подход, когда разнонаправленные задачи или метрики Список литературы • https://www.career.pm/briefings/kano-model 1 2 • https://dou.ua/lenta/articles/prioritization-approach/ 3 • https://upravlenie-proektami.ru/metod-moscow-dlya-prioritizacii-zadach-v-bekloge 4 • https://productstar.ru/backlog-svetlana-ayupova 5 • https://www.intercom.com/resources/books/intercom-product-management