В далекой-далекой галактике трудится сферический product owner. Он бегло пишет заметки на салфетке и молча отдает ее разработчикам. А вскоре получает готовый продукт, который на 100% соответствует его ожиданиям. Даже если продукт этот – сложный кроссплатформенный сервис с блэкджеком и адаптивностью.

Возможно ли такое на практике?

«Нет, брат, нас не проведешь! Техзадание следует писать долго и дотошно», – скажут седовласые синьоры. «ТЗ – это серьезно!» – вторят им желторотые джуны. «От меня жена ушла из-за короткого ТЗ», – признается бывалый бизнес-аналитик.

Позвольте не согласиться.

Написание ТЗ не обязано быть трудоемким. Более того, хорошие техзадания писать легче, чем плохие. Если знать некоторые хитрости, конечно. Об этом сегодня и расскажу. Впрочем, вместо салфеток все же рекомендую использовать confluence.

А что не так-то?

Я уже более 11 лет пишу задачи для разработчиков. По ним сделаны приложения, игры, веб-сервисы, CRM-системы, обучающие платформы и иные прочие продукты. За это время я прошел путь от написания 200-страничных диздоков до лаконичных техзаданий в несколько сторей. И, конечно, набил все возможные шишки.

Год за годом в разных компаниях я наблюдал – как ставят задачи продакты, гейм-дизайнеры, маркетологи. И к каким последствиям приводят различные «особенности» оформления этих задач. Как на неделю смещают старт спринта, выясняя, что же именно хочет заказчик. Как в панике хотфиксят только что вылитый на прод функционал. Как быстро опускается оценка приложения из-за неучтенных кейсов. Как падают продажи и уходят лояльные пользователи. Как выгорают разработчики, которым приходится возиться с проблемными задачами.

У меня сложилось впечатление, что слишком многие из тех, кто ставит задачи на разработку – не умеют делать это хорошо. И сам вопрос качества ТЗ вне фокуса внимания: мол, написал задачу и норм, не разберутся, что ли? Тем более, всегда есть дела интереснее: обсуждение новых гипотез, митинги, кофе-брейки. В итоге страдают все – и заказчики, и разработчики, и бизнес.

Есть две крайности при написании ТЗ

Чем крупнее продукт, над которым вы работаете – тем выше цена ошибки и тем важнее качество ТЗ (спасибо, кэп!). Поэтому оба варианта не годятся, если вы делаете что-то серьезнее лендинга. В больших и конкурентных продуктах написание ТЗ должно быть быстрым, умным, рок-н-ролльным. Давайте посмотрим, как к этому прийти.

Требования к хорошему, душевному техзаданию

1. ТЗ должно радовать продакта
   А значит – писаться быстро, легко, с удовольствием. В идеале вообще не нужно специально писать ТЗ, оно должно само появляться в процессе работы (об этом еще расскажу ниже).
2. ТЗ должно радовать разработчиков
   А значит – быть максимально лаконичным, простым и однозначным. Причем, не усложнять ТЗ – важно, но еще важнее не усложнять продукт. Т.е. нужно избегать запутанной логики, хитрых условий, мудреных механик. Как правило, если продакт наворачивает сложную логику – он недостаточно компетентен или недостаточно старается, чтобы сделать проще.
3. ТЗ должно радовать PM-а
   А значит – легко разбиваться на небольшие, прогнозируемые, автономные задачи. Говоря «автономные», я имею в виду настолько охренительно независимые задачи, что их могут делать в разных спринтах незнакомые друг с другом разработчики.
4. ТЗ должно радовать QA
   А значит – учитывать все ключевые состояния и негативные кейсы, которые могут возникнуть. Какие user journey возможны и как поведет себя продукт в каждом из них. Миграции, настройки по умолчанию, состояния пустых экранов, вот это все.
5. ТЗ должно радовать тимлида
   А значит – не требовать каких-то особых ритуалов и разъяснений для передачи в разработку. Например, если продакт закончил ТЗ и его тут же, прямо в офисе, сбил автобус – это вообще не должно помешать сделать ТЗ в лучшем виде.

Сложно соответствовать всем этим требованиям? Вовсе нет.

Напротив, если о них помнить, то не получится написать откровенно плохое ТЗ. Потому что все эти требования сводятся только к одному – заботе о людях, которые с этим ТЗ взаимодействуют.

Мой формат ТЗ

Этот формат – достаточно вольная смесь user story + definition of done.

Он появился как результат многолетней эволюции: каждый раз, когда я видел систематическую проблему – менял формат своих ТЗ так, чтобы в дальнейшем эта проблема не возникала. В результате получился лаконичный и визуально чистый формат, который легко подхватывают даже джуны. Плюс он соответствует описанным выше требованиям.

Вот как выглядит типичная задача (story) в моем ТЗ:



И не важно, насколько большой и сложный продукт мы разрабатываем – любое ТЗ будет состоять из таких простых сторей (только вырастет их количество).


Важно: стори не должны описывать слишком крупный функционал (например, несколько экранов) или слишком мелкий (например, одну кнопку). Как правило, одна стори – это одна фича или механика продукта. Например, стори может полностью описывать регистрацию нового пользователя. Чтобы поставить задачу на верстку нового лендинга – мне, как правило, тоже хватает одной стори.

Если ТЗ большое и значимое, то перед списком сторей я вкратце пишу: зачем мы его делаем и каких результатов хотим достичь. Просто чтобы у разработчиков была общая картина.
В целом, получается примерно так:

Пример

Окей, чтобы понять, как это работает – давайте разобьем какой-нибудь продукт на такие story. Например, мы решили сделать приложение «нейрособутыльник». В нем нейросеть будет вести задушевные беседы с продактами, у которых не задался день (и нет друзей).

Для простоты считаем, что у нас уже есть натренированная нейросеть и нам нужно сделать ей интерфейс в виде приложения.

Вероятно, ТЗ будет состоять из таких сторей:

1. Авторизация пользователя
2. Анкета пользователя
3. Экран общения с нейрособутыльником
4. Экран «Каталог нейрособутыльников»
5. Экран профиля и настроек
6. Попап оплаты
7. Подключение аналитики

Осталось расписать каждую стори (в указанном выше формате) и отдать в разработку. Я же говорил, что будет легко.

---

Хитрые лайфхаки

Есть ряд методик, которые ежедневно помогают мне в работе над продуктом. Вот те из них, которые касаются написания техзаданий.

Лайфхак №1: Детализировать итеративно

Сейчас я вообще не пишу ТЗ – они сами, фоново, появляются в процессе работы. Когда появляется новая задача – я сразу прикидываю: а какие подзадачи нужны, чтобы это сделать? И тут же фиксирую каждую подзадачу в формате story (только название, детали будут потом).

Таким образом, у меня сразу готово обобщенное техзадание. Остается только детализировать story до той степени, когда можно будет отдать ТЗ в разработку.

Детализация тоже идет фоново: пока я ресерчу и продумываю детали – сразу делаю заметки внутри соответствующих сторей. Вместо дизайна вставляю прототипы из NinjaMock.

Такой подход заметно ускоряет работу. Плюс позволяет не упустить общую картину и не зарыться в детали раньше времени.

Лайфхак №2: Не работать с джиннами

Был такой старый фильм, где джинн исполнял желания самым хреновым способом.

Конечно, вменяемый разработчик не будет специально искать возможность навредить. Но иногда людям безразлично, над чем они работают. Тогда они делают задачу «как написано», не особо вникая, зачем это нужно. Периодически это будет приводить к большим и малым фэйлам. Ну да, продакшн лег… но никто же не прописал в задаче, что нужно проверить – не сломает ли такая реализация все остальное.

Не скажу про аутсорс, но в продукте такой подход не приемлем. Хороший разработчик строит храм, а не просто кирпичи кладет. То есть он видит общую картину и вникает в происходящее. Такие ребята нередко предлагают альтернативные решения и сами предупреждают о подводных камнях.

Поэтому если вы хотите, чтобы ваши ТЗ делались наилучшим образом – то иногда нужно улучшать не ТЗ, а культуру разработки в команде. В целом, это задача PM, но продакт тоже может влиять на ситуацию. Особенно если команда ему доверяет (благодаря его продуманным и хорошо оформленным ТЗ, например).

Лайфхак №3: Отделить ТЗ от документации

Техзадание отвечает на вопрос «что нужно сделать?». А документация – на вопрос «как это сделано / как это работает?». ТЗ пишется до реализации задачи, а документация – после.

Если мне нужно переставить шкаф – я напишу задачу в духе «переставить отсюда -> сюда». Но не буду чертить архитектурный план дома, в котором стоит шкаф.

Иногда встречается мнение, что ТЗ нужно писать так, чтобы это была как бы заодно и документация. Это пагубная теория. Полноценной документации все равно не получится, потому что заранее неизвестно, как точно техзадание будет реализовано. Кроме того, разработчикам нужна свобода для маневра, которую документация не предусматривает. Ну и главное – такое ТЗ писать в разы дольше и получится оно громоздким.

Бывают разные продукты и разные стартапы. Кто-то может вообще обойтись без документации. Но если вам документация все же нужна – наймите джуна, который будет детально описывать функционал уже после его реализации. Для описания существующего функционала особых навыков не нужно, зато вы сэкономите время и нервы скилловых сотрудников – продактов и разработчиков.

Лайфхак №4: Научиться программировать

Чисто эмпирическое наблюдение: продакты, которые умеют программировать – лучше формулируют задачи. Причем не обязательно становиться синьор-бэкэндщиком, достаточно освоить любой язык программирования и понять суть алгоритмического мышления.

В свое время я безудержно кодил еще на хтоническом Спектруме, а в студенческие годы доводилось даже писать драйвера на Ассемблере. То есть с программированием я знаком не понаслышке – и это, безусловно, помогает находить общий язык с разработчиками.

Лайфхак №5: Думать много, писать мало

Наибольшие проблемы всегда возникают с задачами, которые до конца не понимает сам заказчик. Например, ему нужен новый отчет в админке, но как будет формироваться этот отчет – он не вполне представляет. Мол, тыжпрограммисты разберутся. Нет, это так не работает.

Единственный способ написать хорошую задачу, которую сделают правильно, – это вникнуть. В идеале, разобраться в задаче настолько, чтобы вы сами могли бы ее сделать… если бы умели программировать.

Но когда вы разобрались – не нужно вываливать всю найденную инфу в ТЗ. Как раз глубокое понимание задачи позволяет откинуть лишнее и написать только то, что имеет значение.

---

P.S. ТЗ – средство, а не цель. Поэтому иногда лучшее ТЗ – это его отсутствие. Как-нибудь расскажу, как я запустил пару продуктов вообще без ТЗ.

P.P.S. Если у вас есть собственный формат техзаданий или лайфхаки при их написании – пожалуйста, поделитесь в комментариях.