Миф о «прозрачной задаче»
Представьте ситуацию. Вам понадобился отчёт по продажам. Вы открываете мессенджер и пишете аналитику: «Нужен отчёт по продажам за май, сделай красиво».
Аналитик выгружает данные, строит сводную таблицу, делает красивые графики и отправляет вам. Но тут вы понимаете, что нужны были продажи с учётом возвратов, неплохо было бы оценить месяц с учётом вклада каждого менеджера и ещё круто было бы увидеть по каким источникам приходили лиды.
В итоге решение такой простой, казалось бы, задачи затягивается из-за переделок и недопонимания.
Знакомо? Это классика. У заказчика и аналитика разное понимание слов «май», «продажи» и даже слова «красиво».
Техническое задание (ТЗ) — это не бюрократическая прихоть и не недоверие к сотрудникам.
ТЗ — это инструмент управления, который экономит ваши ресурсы, фиксирует ответственность и исключает «испорченный телефон».
ТЗ — это стандарт управления
Некоторые руководители сомневаются в необходимости требовать письменное ТЗ, так как считают это пустой тратой времени: всё же и так понятно!
Или боятся: «А вдруг аналитик обидится? Решит, что я проверяю каждый его шаг?»
Перестаньте. Вы не надзиратель, вы — управленец.
А любой управленец должен понимать три вещи:
А любой управленец должен понимать три вещи:
- что делаем
- зачем делаем
- когда ждать результат
Без письменного ТЗ вы не знаете ни первого, ни второго, ни третьего.
Требовать ТЗ — это «я хочу, чтобы у нас обоих были одинаковые ожидания от работы».
Три управленческие выгоды от ТЗ
Золотое правило менеджмента:
«Нет ТЗ — нет задачи». Есть ТЗ — есть ясные сроки, понятный результат и спокойный сон у всех участников.
4 сценария боли менеджера
Сценарий 1. «Я же просил по-другому»
Вы дали задачу устно. Аналитик сделал. Оказалось не то. Вы тратите полчаса на выяснение, кто что сказал. Доказательств нет. Виноваты оба.
ТЗ решает: Всё записано. Если аналитик понял не так — его задача была уточнить. Если вы утвердили неверную формулу — ваша ответственность.
Сценарий 2. «Почему это заняло так много времени?»
Аналитик говорит: «Я делал три дня». Вы: «Я думал, это на три часа». Без ТЗ вы не можете оценить сложность.
ТЗ решает: Вы видите список пунктов. Сравниваете с результатом. Либо пункты сделаны, либо нет.
Сценарий 3. «Директор спрашивает, почему отчёт вчера не сдали»
Вы приходите к аналитику: «Где отчёт?» — «Вы не уточнили, по какому региону». Вы идёте к директору с пустыми руками.
ТЗ решает: Вы показываете ТЗ директору: «Задача сделана в полном объёме. Чтобы добавить регион, нужно расширить ТЗ — это ещё 4 часа».
Сценарий 4. «Текучесть кадров разрушает аналитику»
Ключевой аналитик уволился. Его задачи, отчёты, договорённости — в его голове. Новый сотрудник начинает всё с нуля.
ТЗ решает: Архив ТЗ — это база знаний. Новый аналитик погружается в проект за дни, а не за месяцы.
Минимальные требования к ТЗ. 5 пунктов
Многие руководители боятся ТЗ, потому что в их голове он ассоциируется с 50-страничными документами, техническим жаргоном и неделями согласований.
Это не так.
В аналитике хорошее ТЗ — это один экран. Оно пишется за 15 минут, а читается за 2 минуты. Потому что оно состоит не из «всего подряд», а всего из 5 ключевых пунктов. Всё остальное — лишнее. Если ТЗ не влезает на один лист А4 — вы не ставите задачу, вы пишете диссертацию. Вернитесь к пяти пунктам.
Вот эти 5 пунктов.
1. Бизнес-цель (а не просто «что сделать»)
Вместо: «Посчитать конверсию».
Напишите: «Цель: понять, какой канал привлечения даёт самую качественную аудиторию. Решение: сравнить конверсию в покупку по каналам за март. Если канал даёт конверсию ниже 2% — мы отключаем его бюджет».
Зачем? Чтобы аналитик пришёл с таблицей, которая отвечает на бизнес-вопрос.
2. Входные данные и их статус
«Используем таблицу orders в схеме sales. Данные обновляются ежедневно в 6 утра. Задержки данных не допускаются».
Зачем? Если исходные данные врут, аналитик не виноват. Но вы должны знать, кому предъявлять (админам БД, инженерам).
3. Формулы — без вариантов
Плохо: «Конверсия — это отношение заказов к визитам».
Хорошо: Конверсия = (Количество уникальных пользователей со статусом заказа 'done' / Количество уникальных пользователей с событием 'page_view') * 100.
Зачем? Получить ключевую метрику, которая нужна именно вам. Аналитик не должен решать, исключать ли возвраты. Это решаете вы.
4. Критерии приёмки — то, за что вы платите
- Отчёт сформирован в Yandex DataLens за < 10 секунд.
- Есть фильтры по датам и по регионам.
- Все формулы проверены на корректность работы.
Зачем? Вы не принимаете работу, пока условия не выполнены. Просто и неэмоционально.
5. Дата дедлайна и формат сдачи
Дедлайн: 20 мая, 12:00.
Формат: Ссылка на дашборд в Yandex DataLens, доступ у Ивана Иванова.
Зачем? Чтобы не было «я думал, до пятницы, а заказчик хотел в четверг».
Как внедрить культуру ТЗ в команде
Самое сложное — ввести процесс, когда его не было. Команда скажет: «Мы раньше работали нормально!». Вот план для руководителя.
Шаг 1. Начните с себя
Каждую задачу, которую вы даёте, пишите в одном и том же формате (например, в Jira или Битрикс24). Первые 2-3 шаблона сделайте сами. Покажите пример.
Шаг 2. Установите правило «ТЗ перед любыми работами»
Никакой код, никакие запросы не пишутся, пока ТЗ не завизировано (подпись в чате, статус «утверждено» в таск-трекере).
Шаг 3. Сделайте ТЗ коротким
Скажите команде: «ТЗ — это не роман. Один экран, список пунктов, пример расчёта».
Шаг 4. Снимайте ответственность за переделки
Если ТЗ утверждено, а потом заказчик меняет требования — переделка оплачивается как новая задача. Это мотивирует заказчиков думать заранее.
Шаг 5. Хвалите за хорошие ТЗ
Когда аналитик прислал чёткое ТЗ на согласование, и вы не нашли ошибок — скажите вслух: «Отличная работа, это то, что нужно». Позитивное подкрепление работает лучше наказаний.
Реальный кейс: как ТЗ спасло миллион
Приведу реальный случай из практики консалтинга.
Компания — интернет-магазин. Маркетолог даёт задание аналитику: «Посчитай ROMI за прошлую неделю». Аналитик считает — ROMI = 4,5 (отлично).
Маркетолог докладывает CEO. CEO выделяет дополнительный миллион на рекламу. Через две недели продажи не выросли. Разбор полётов.
Выясняется: аналитик считал ROMI по оплаченным заказам. Но доставка у магазина — 5 дней. На прошлой неделе оплатили, а на этой — массово вернули. Аналитик об этом не знал (и не должен был знать — ему не поставили задачу).
Что сделали после: Внедрили обязательный пункт в ТЗ — «Статусы заказов, которые считаются успешными (оплачен, отправлен, доставлен, закрыт)». И отдельный пункт — «Учитывать ли возвраты вендором?».
Цена отсутствия ТЗ — миллион рублей. Цена ТЗ — 15 минут времени менеджера.
Заключение: ТЗ — это не контроль ради контроля, это уважение к ресурсам
Если вы вынесли из этой статьи только одну мысль, пусть она будет такой:
Без ТЗ вы управляете надеждами. С ТЗ вы управляете фактами.
Ваши аналитики не против ТЗ. Они против бесконечных переделок, невнятных требований и того, что их называют «виноватыми» за то, о чём их не просили.
Как руководитель, вы имеете право требовать ТЗ. Но вы также обязаны его читать и утверждать. Это ваша часть сделки.
Ваш следующий шаг сегодня:
- Создайте в корпоративной вики или таск-трекере раздел «Шаблон ТЗ для аналитики» (можно скопировать из раздела 3 этой статьи).
- На ближайшей планерке скажите: «С понедельника любая задача аналитику без ТЗ не запускается в работу».
- Первую неделю сами помогайте команде заполнять ТЗ (да, это время, но оно окупится за месяц).
Сэкономьте месяц рабочего времени своих сотрудников и миллионы бюджета — потратьте 15 минут на ТЗ перед каждой задачей.
ГОТОВЫЙ ШАБЛОН ТЗ
Не нужно заполнять таблицы вручную. Возьмите готовый шаблон по ссылке и сделайте копию.
Ссылка на шаблон:
Инструкция:
- Перейдите по ссылке
- Нажмите «Файл» → «Сделать копию»
- Сохраните в свой Google Диск и заполните поля под свою задачу
Что важно заполнить обязательно:
- бизнес-цель (зачем нужен отчёт)
- формулы метрик (как именно считать)
- фильтры (что исключаем)
- дату дедлайна
- подписи заказчика и аналитика
Перед отправкой аналитику проверьте себя:
- цель понятна и измерима
- формулы однозначны
- исключения прописаны
- дедлайн реалистичный
Если в вашей компании принят другой формат (Word, Excel, Notion, Jira) — скопируйте структуру шаблона туда. Важны не поля, а логика: цель, формулы, фильтры, критерии приёмки.