Хотя я официально не числюсь на позиции менеджера, мне периодически приходится привлекать коллег-разработчиков на проекты, которые я веду или фичи, которые находятся в периметре моей ответственности, например алгоритмы для паблишеров, 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.
Объединяя вместе все вышеперечисленные разделы, у нас получится мощное ТЗ, от которого менеджеры будут в восторге, а от исполнителей вам будет респект и уважение.
While some crypto traders move toward screaming as a coping mechanism, many mental health experts have argued that “scream therapy” is pseudoscience. Scientific research or no, it obviously feels good. While the character limit is 255, try to fit into 200 characters. This way, users will be able to take in your text fast and efficiently. Reveal the essence of your channel and provide contact information. For example, you can add a bot name, link to your pricing plans, etc. Content is editable within two days of publishing Telegram desktop app: In the upper left corner, click the Menu icon (the one with three lines). Select “New Channel” from the drop-down menu. How to create a business channel on Telegram? (Tutorial)
from us
