Thread by @produnderhood

Сегодня поговорим одну из самых важных частей – подготовка материалов)

Написание PRD, обсуждения, подготовка аналитики, дизайн и все такое

https://twitter.com/produnderhood/status/1293921027802771457

Подготовка фичи проходит следующий цикл:
1. Описание идеи
2. Созвон, обсуждение и утверждение
3. Описание формального PRD и сверка с разработкой
4. Подготовка и утверждение дизайна
5. Дополнение PRD аналитикой
6. Отправка в реализацию

У нас в Notion есть 4 главных раздела для работы с фичами:
1. В целом карта приложения, чтобы ориентироваться (она у нас уже устарела, но надо будет обновить, если будут новые участники)
2. Таблица фич
3. Драфты фич
4. Сложные фичи связанные исключительно с аналитикой

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

Можно и сплошным текстом можно и табличками, как кому удобно.

Формат не важен, т.к. все это будет рассказываться во время созвона при обсуждении фичи.

Созвоны у нас проходят следующей командой:
1. Я (выступаю в роли продуктового менеджера и делюсь инженерным опытом)
2. Project Manager (который берет на себя часть функций продукт менеджера)
3. Один из кофаундеров, который отвечает за тех. направление

Иногда и СЕО приходит

После обсуждения и утверждения, начинается формальная часть, заполнение PRD.

Для фич мы используем таблицу в Notion, вот пример с одним из view (об этом я скажу чуть позже):

У нас следующие колонки:
1. Название фичи
2. Ее категория (приложение, сервер, админская панель, утилитарная фича)
3. Типы, может быть несколько (части приложения, удобно для объединения фич в одну группу, про это напишу позже)

4. Статус подготовки PRD и выполнения фичи
5. Ответственный за фичи (к кому обращаться)
6 и 7. Ответственный за аналитику и кто реализовал (второе полезно, когда есть вопросы по отслеживанию, с ведением 7 у нас пока сложности)

Теперь непосредственно создании фичи, мы используем темплейты в Notion, все это выглядит так:

Вот как выглядит экран после применения шаблона.

За основу мы взяли: atlassian.com/agile/product-…

И модернизировали под себя.

Проговорю про каждое поле отдельно:

Image: ссылка на Zeplin/Abstract, заполняются в будущем после того, как дизайнер подготовит их

Goals: кратко описывает, что хотим сделать

Key metrics: обычно для дизайнера, чтобы понять на чем делать акцент, но часто пропускается

Background and strategic fit: чтобы было понятно, почему мы делаем (например, подсмотрели у конкурента, юзеры попросили, должно повысить такую-то метрику и т.п.) полезно заполнять, в первую очередь, для самого продукта

Requirements: табличка с требованиями по фиче

У Requirements есть 4 основные колонки:

1. Что за компонент фичи
2. Его описание
3. Заметки (например, что длинна вода ограничена 120 символами или как ведет себя компонент)
4. Статус компонента (у нас 3 состояния: New, Implemented, Future)

Заметки никак не регламентируются, и у нас проблем с этим не было

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

Таблциа аналитики разделена на 2 (Events и Person Properties):

В первой:
1. Название эвента
2. Поля у эвента
3. Описание эвента (если нужно) и описание полей
4. Статус реализации

P.S. Showed/Closed эвенты работают из коробки на клиентах

Вторая таблица описывает пользовательские свойства

Если вы не знаете в чем их разница от событий, то можете почитать тут: help.amplitude.com/hc/en-us/artic…

Если у задачи есть связанные с ней задачи, то мы часто делаем кросс линкинг через указывание Related tasks

Одной из топовых фич таблиц в Notion являются Views: notion.so/Intro-to-datab…

Это когда вы выводите не всю таблицу, а только определенные отфильтрованные и отсортированные критерии

Когда каждый из нас работает над каким-то набором задач, то может указать соответствующую сортировку, создать свой View и быстро обращаться к текущем задачам

После написания, PRD:
1. Оно проходит проверку и утверждается
2. Отдается дизайнеру (если надо, проходит созвон)
3. Дизайнер предлагает варианты, они утверждаются и добавляются в PRD
4. В PRD добавляется аналитика

После этого фича подготовлена