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

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

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

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

Давайте посмотрим, из чего состоит каждая story

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

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

• Авторизация пользователя
  
• Анкета пользователя
  
• Экран общения с нейрособутыльником
  
• Экран «Каталог нейрособутыльников»
  
• Экран профиля и настроек
  
• Попап оплаты
  
• Подключение аналитики

Осталось расписать каждую стори (в указанном выше формате) и отдать в разработку. Я же говорил, что будет легко.
Хитрые лайфхаки
Есть ряд методик, которые ежедневно помогают мне в работе над продуктом. Вот те из них, которые касаются написания техзаданий.
Лайфхак №1: Детализировать итеративно
Сейчас я вообще не пишу ТЗ – они сами, фоново, появляются в процессе работы.
Когда появляется новая задача – я сразу прикидываю: а какие подзадачи нужны, чтобы это сделать? И тут же фиксирую каждую подзадачу в формате story (только название, детали будут потом).
Таким образом, у меня сразу готово обобщенное техзадание. Остается только детализировать story до той степени, когда можно будет отдать ТЗ в разработку.
Детализация тоже идет фоново: пока я ресерчу и продумываю детали – сразу делаю заметки внутри соответствующих сторей. Вместо дизайна вставляю прототипы из NinjaMock.
Такой подход заметно ускоряет работу. Плюс позволяет не упустить общую картину и не зарыться в детали раньше времени.
Лайфхак №2: Не работать с джиннами
Был такой старый фильм, где джинн исполнял желания самым хреновым способом.
Конечно, вменяемый разработчик не будет специально искать возможность навредить.
Но иногда людям безразлично, над чем они работают. Тогда они делают задачу «как написано», не особо вникая, зачем это нужно. Периодически это будет приводить к большим и малым фэйлам. Ну да, продакшн лег… но никто же не прописал в задаче, что нужно проверить – не сломает ли такая реализация все остальное.
Не скажу про аутсорс, но в продукте такой подход не приемлем. Хороший разработчик строит храм, а не просто кирпичи кладет. То есть он видит общую картину и вникает в происходящее. Такие ребята нередко предлагают альтернативные решения и сами предупреждают о подводных камнях.
Поэтому если вы хотите, чтобы ваши ТЗ делались наилучшим образом – то иногда нужно улучшать не ТЗ, а культуру разработки в команде. В целом, это задача PM, но продакт тоже может влиять на ситуацию. Особенно если команда ему доверяет (благодаря его продуманным и хорошо оформленным ТЗ, например).
Лайфхак №3: Отделить ТЗ от документации
Техзадание отвечает на вопрос «что нужно сделать?».
А документация – на вопрос «как это сделано / как это работает?».
ТЗ пишется до реализации задачи, а документация – после.
Если мне нужно переставить шкаф – я напишу задачу в духе «переставить отсюда -> сюда». Но не буду чертить архитектурный план дома, в котором стоит шкаф.
Иногда встречается мнение, что ТЗ нужно писать так, чтобы это была как бы заодно и документация. Это пагубная теория. Полноценной документации все равно не получится, потому что заранее неизвестно, как точно техзадание будет реализовано. Кроме того, разработчикам нужна свобода для маневра, которую документация не предусматривает. Ну и главное – такое ТЗ писать в разы дольше и получится оно громоздким.
Бывают разные продукты и разные стартапы. Кто-то может вообще обойтись без документации. Но если вам документация все же нужна – наймите джуна, который будет детально описывать функционал уже после его реализации. Для описания существующего функционала особых навыков не нужно, зато вы сэкономите время и нервы скилловых сотрудников – продактов и разработчиков.
Лайфхак №4: Научиться программировать
Чисто эмпирическое наблюдение: продакты, которые умеют программировать – лучше формулируют задачи. Причем не обязательно становиться синьор-бэкэндщиком, достаточно освоить любой язык программирования и понять суть алгоритмического мышления.
В свое время я безудержно кодил еще на хтоническом Спектруме, а в студенческие годы доводилось даже писать драйвера на Ассемблере. То есть с программированием я знаком не понаслышке – и это, безусловно, помогает находить общий язык с разработчиками.
Лайфхак №5: Думать много, писать мало
Наибольшие проблемы всегда возникают с задачами, которые до конца не понимает сам заказчик. Например, ему нужен новый отчет в админке, но как будет формироваться этот отчет – он не вполне представляет. Мол, тыжпрограммисты разберутся. Нет, это так не работает.
Единственный способ написать хорошую задачу, которую сделают правильно, – это вникнуть. В идеале, разобраться в задаче настолько, чтобы вы сами могли бы ее сделать… если бы умели программировать.
Но когда вы разобрались – не нужно вываливать всю найденную инфу в ТЗ. Как раз глубокое понимание задачи позволяет откинуть лишнее и написать только то, что имеет значение.
P.S. ТЗ – средство, а не цель. Поэтому иногда лучшее ТЗ – это его отсутствие. Как-нибудь расскажу, как я запустил пару продуктов вообще без ТЗ.
P.P.S. Если у вас есть собственный формат техзаданий или лайфхаки при их написании – пожалуйста, поделитесь в комментариях.
===========
Источник:
habr.com
===========
Похожие новости:

• [Дизайн, Дизайн игр, Управление продуктом] Геймификация в бизнесе. Мотивация со всех сторон
  
• [Разработка игр, Управление продуктом, Учебный процесс в IT] Дивный новый мир: вручение дипломов в Аллодах Онлайн
  
• [Agile, Управление персоналом, Управление продуктом, Управление проектами, Управление разработкой] Хочешь заработать миллион?
  
• [Управление продуктом, Управление проектами, Управление сообществом, Фриланс] Квалификация тоже продукт: рынок фриланса заточен под продажу услуг — заказчики ищут ещё и людей
  
• [Управление персоналом, Управление продуктом, Управление проектами] Project Management: Управление изменениями, часть 1
  
• [Agile, Управление продуктом, Управление проектами, Управление разработкой] Интеграция Youtrack со встроенным (embedded) Hub с Teamcity, Gitlab
  
• [IT-компании, Управление продуктом, Управление разработкой] Продуктовая трансформация в Delivery Club Tech
  
• [Agile, Управление продуктом, Управление проектами, Управление разработкой] YouTrack теперь с просмотром пул-реквестов в задачах
  
• [IT-компании, Лайфхаки для гиков, Разработка веб-сайтов, Разработка мобильных приложений, Управление продуктом] Наука о пользовательском опыте. Использование когнитивных искажений в разработке качественных продуктов
  
• [Профессиональная литература, Управление продуктом, Читальный зал] Digital Practitioner Body of Knowledge — обзор инструкции по цифровой трансформации для практиков

Теги для поиска: #_upravlenie_produktom (Управление продуктом), #_tehnicheskoe_zadanie (техническое задание), #_tehzadanie (техзадание), #_shablon_tz (шаблон тз), #_upravlenie_produktom (управление продуктом), #_razrabotka_produkta (разработка продукта), #_upravlenie_produktom (
Управление продуктом
)