Ты можешь писать безупречные ТЗ, но какой в этом толк, если разработчик твой плачет?

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

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

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

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

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

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

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

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

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

1. И так сойдет!

Такое встречается даже среди матерых продактов. Они могут хорошенько вложиться в исследование рынка, кастдев, аналитику… а потом написать какую-то невнятную задачу.
Это приводит к затянутой декомпозиции, лишним рэопенам, доработкам после релиза и даже конфликтам в команде. К убыткам это приводит, короче.

Для меня такой подход выглядит дико. Как выбрать хороший виски, прочитав десятки обзоров и опросив кавистов… Чтобы разбавить его колой и залпом выпить, не почувствовав ни запаха, ни вкуса. Не надо так!

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

2. Я у мамы техписатель

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

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

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

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

• Дизайнеры минимум вдвое сократили время отрисовки новых экранов. Они стали счастливее, так как сократилась рутина.
• Техзадания стали писаться быстрее. Их стало легче читать и декомпозировать.
• Верстальщик почувствовал себя человеком, который участвует в процессе и влияет на результат, а не просто один в один копирует готовый дизайн.
• QA больше не нужно было сравнивать все разрешения с дизайном и ТЗ, поэтому время тестирования тоже сократилось.
• Качество адаптивности точно не ухудшилось (а местами и выросло), так как верстка стала более осознанной.

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

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

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.P.S. Если у вас есть собственный формат техзаданий или лайфхаки при их написании – пожалуйста, поделитесь в комментариях.

Автор: Ventarron

Источник