Хотя я официально не числюсь на позиции менеджера, мне периодически приходится привлекать коллег-разработчиков на проекты, которые я веду или фичи, которые находятся в периметре моей ответственности, например алгоритмы для паблишеров, Header Bidding, фильтрация трафика и с некоторого времени алгоритмы ставок для YouTube'а.
При этом если человеку попробовать сумбурно накидать идей off top of my head, то запросто можно получить кота в мешке и впоследствии дружно плясать с бубном, объясняя менеджерам, как работает продукт. Чтобы этого избежать, готовим ТЗ. Сейчас расскажу, как.
1️⃣Даем контекст. Почему возникла потребность в фиче, какие боли мы решаем. Упоминаем контекст, и что идет не так на данный момент. Например, хотим повысить долю in-view для формата shorts'ов и infeed для видео рекламы на YouTube. Делаем это, поскольку досмотры на этих форматах не оптимизируешь (они максимум 2%), а дать возможность заводить РК под эти форматы нужно. Для этого хотим по умному рулить ставкой, чтобы выдать высокий view-through rate и при этом не срезать трафик показов и открученный таргет по бюджету.
2️⃣Определяем клиентов, которые будут пользоваться фичей. Кто они и где обитают. Например бренды-рекламодатели, которые хотят повысить brand-awareness и заводят РК через Google DV360 под трафик ютуба.
3️⃣Описываем сценарии использования(user flow). Здесь всегда хочется впихнуть невпихуемое, но вместо этого определяем базовые сценарии - без которых продукт попросту не имеет смысла. Желаемые вещи - их хорошо бы иметь, но можно допилить после релиза. Например клиент заводит РК в интерфейсе DSP и ставит галку напротив поля autobidding. На нашей стороне мы эту настройку читаем по API DSP и запускаем алгоритм на данного клиента.
4️⃣Фиксируем основной стек. Фреймворки, тулзы, языки программирования, OLAP vs OLTP базы etc. Здесь все достаточно понятно, используем тот стек, который наша команда умеет поддерживать и знает практики.
5️⃣Описываем зависимости. Вероятнее всего ваш продукт будет крутиться не в вакууме, и нужно будет тянуть часть данных из корпоративной базы, метрики из DSP, залогировать дополнительный ивент в очереди. Для всего этого прикладываем нужные API и схемы к ТЗ.
6️⃣Делаем макеты. Не чураемся использовать Jupyter Notebook и расписать, как алгоритм будет работать на примере семплированных или синтетических данных. Прикладываем нужные графики в ТЗ.
7️⃣Поясняем Definition of Done. Какие критерии сделанной работы? Мы запускаем джобу на Airflow? Или мы релизим сборку в Container Registry? Как мы будем рулить релизом и запуском РК клиентов?
8️⃣Делаем чек-лист для приема работы. На каких сценариях, РК, бюджетах мы прогоним продукт перед тем, как сказать, что он работает хорошо. Какие бизнес метрики будем мониторить, например VTR, budget spent, показы, CPM, CPV.
Объединяя вместе все вышеперечисленные разделы, у нас получится мощное ТЗ, от которого менеджеры будут в восторге, а от исполнителей вам будет респект и уважение.
Хотя я официально не числюсь на позиции менеджера, мне периодически приходится привлекать коллег-разработчиков на проекты, которые я веду или фичи, которые находятся в периметре моей ответственности, например алгоритмы для паблишеров, Header Bidding, фильтрация трафика и с некоторого времени алгоритмы ставок для YouTube'а.
При этом если человеку попробовать сумбурно накидать идей off top of my head, то запросто можно получить кота в мешке и впоследствии дружно плясать с бубном, объясняя менеджерам, как работает продукт. Чтобы этого избежать, готовим ТЗ. Сейчас расскажу, как.
1️⃣Даем контекст. Почему возникла потребность в фиче, какие боли мы решаем. Упоминаем контекст, и что идет не так на данный момент. Например, хотим повысить долю in-view для формата shorts'ов и infeed для видео рекламы на YouTube. Делаем это, поскольку досмотры на этих форматах не оптимизируешь (они максимум 2%), а дать возможность заводить РК под эти форматы нужно. Для этого хотим по умному рулить ставкой, чтобы выдать высокий view-through rate и при этом не срезать трафик показов и открученный таргет по бюджету.
2️⃣Определяем клиентов, которые будут пользоваться фичей. Кто они и где обитают. Например бренды-рекламодатели, которые хотят повысить brand-awareness и заводят РК через Google DV360 под трафик ютуба.
3️⃣Описываем сценарии использования(user flow). Здесь всегда хочется впихнуть невпихуемое, но вместо этого определяем базовые сценарии - без которых продукт попросту не имеет смысла. Желаемые вещи - их хорошо бы иметь, но можно допилить после релиза. Например клиент заводит РК в интерфейсе DSP и ставит галку напротив поля autobidding. На нашей стороне мы эту настройку читаем по API DSP и запускаем алгоритм на данного клиента.
4️⃣Фиксируем основной стек. Фреймворки, тулзы, языки программирования, OLAP vs OLTP базы etc. Здесь все достаточно понятно, используем тот стек, который наша команда умеет поддерживать и знает практики.
5️⃣Описываем зависимости. Вероятнее всего ваш продукт будет крутиться не в вакууме, и нужно будет тянуть часть данных из корпоративной базы, метрики из DSP, залогировать дополнительный ивент в очереди. Для всего этого прикладываем нужные API и схемы к ТЗ.
6️⃣Делаем макеты. Не чураемся использовать Jupyter Notebook и расписать, как алгоритм будет работать на примере семплированных или синтетических данных. Прикладываем нужные графики в ТЗ.
7️⃣Поясняем Definition of Done. Какие критерии сделанной работы? Мы запускаем джобу на Airflow? Или мы релизим сборку в Container Registry? Как мы будем рулить релизом и запуском РК клиентов?
8️⃣Делаем чек-лист для приема работы. На каких сценариях, РК, бюджетах мы прогоним продукт перед тем, как сказать, что он работает хорошо. Какие бизнес метрики будем мониторить, например VTR, budget spent, показы, CPM, CPV.
Объединяя вместе все вышеперечисленные разделы, у нас получится мощное ТЗ, от которого менеджеры будут в восторге, а от исполнителей вам будет респект и уважение.
