- PVSM.RU - https://www.pvsm.ru -
В далекой-далекой галактике трудится сферический product owner. Он бегло пишет заметки на салфетке и молча отдает ее разработчикам. А вскоре получает готовый продукт, который на 100% соответствует его ожиданиям. Даже если продукт этот – сложный кроссплатформенный сервис с блэкджеком и адаптивностью.
Возможно ли такое на практике?
«Нет, брат, нас не проведешь! Техзадание следует писать долго и дотошно», – скажут седовласые синьоры. «ТЗ – это серьезно!» – вторят им желторотые джуны. «От меня жена ушла из-за короткого ТЗ», – признается бывалый бизнес-аналитик.
Позвольте не согласиться.
Написание ТЗ не обязано быть трудоемким.
Более того, хорошие техзадания писать легче, чем плохие.
Если знать некоторые хитрости, конечно. Об этом сегодня и расскажу.
Впрочем, вместо салфеток все же рекомендую использовать confluence.
Я уже более 11 лет пишу задачи для разработчиков. По ним сделаны приложения, игры, веб-сервисы, CRM-системы, обучающие платформы и иные прочие продукты. За это время я прошел путь от написания 200-страничных диздоков до лаконичных техзаданий в несколько сторей. И, конечно, набил все возможные шишки.
Год за годом в разных компаниях я наблюдал – как ставят задачи продакты, гейм-дизайнеры, маркетологи. И к каким последствиям приводят различные «особенности» оформления этих задач. Как на неделю смещают старт спринта, выясняя, что же именно хочет заказчик. Как в панике хотфиксят только что вылитый на прод функционал. Как быстро опускается оценка приложения из-за неучтенных кейсов. Как падают продажи и уходят лояльные пользователи. Как выгорают разработчики, которым приходится возиться с проблемными задачами.
У меня сложилось впечатление, что слишком многие из тех, кто ставит задачи на разработку – не умеют делать это хорошо. И сам вопрос качества ТЗ вне фокуса внимания: мол, написал задачу и норм, не разберутся, что ли? Тем более, всегда есть дела интереснее: обсуждение новых гипотез, митинги, кофе-брейки. В итоге страдают все – и заказчики, и разработчики, и бизнес.
В этой статье я говорю о продуктовой разработке, где задача ТЗ – эффективно донести разработчикам, что нужно сделать. То есть мы не говорим об аутсорсе, где бизнес-аналитик пишет ТЗ так, чтобы защититься от судебных исков заказчика.
Для меня такой подход выглядит дико. Как выбрать хороший виски, прочитав десятки обзоров и опросив кавистов… Чтобы разбавить его колой и залпом выпить, не почувствовав ни запаха, ни вкуса. Не надо так!
Но вариант, когда задача продумана, но плохо описана – это еще полбеды. Потому что хороший разработчик задаст вопросы, получит ответы и продолжит работу. А бывает и так, что задача плохо описана, потому что заказчик сам не разобрался в вопросе. Как правило, это выясняется в момент, когда уже идет декомпозиция и тот самый разработчик начинает задавать вопросы. Это всё, сушите весла.
Излишняя детализация превращает ТЗ в непрактичный, нечитабельный документ.
Вот несколько причин, почему не нужно писать такое ТЗ:
Приведу пример. Как-то я пришел в команду, где было принято рисовать все ключевые разрешения для адаптивного дизайна, а потом еще и прописывать их в ТЗ. Вместо этого я предложил разово договориться о правилах, по которым у нас работает адаптивность и… довериться верстальщику. Теперь мы показывали в ТЗ только основное разрешение, а остальное оставляли на усмотрение верстальщика. В результате:
Чем крупнее продукт, над которым вы работаете – тем выше цена ошибки и тем важнее качество ТЗ (спасибо, кэп!). Поэтому оба варианта не годятся, если вы делаете что-то серьезнее лендинга. В больших и конкурентных продуктах написание ТЗ должно быть быстрым, умным, рок-н-ролльным. Давайте посмотрим, как к этому прийти.
Сложно соответствовать всем этим требованиям? Вовсе нет.
Напротив, если о них помнить, то не получится написать откровенно плохое ТЗ.
Потому что все эти требования сводятся только к одному – заботе о людях, которые с этим ТЗ взаимодействуют.
Этот формат – достаточно вольная смесь user story + definition of done.
Он появился как результат многолетней эволюции: каждый раз, когда я видел систематическую проблему – менял формат своих ТЗ так, чтобы в дальнейшем эта проблема не возникала.
В результате получился лаконичный и визуально чистый формат, который легко подхватывают даже джуны. Плюс он соответствует описанным выше требованиям.
Вот как выглядит типичная задача (story) в моем ТЗ:
И не важно, насколько большой и сложный продукт мы разрабатываем – любое ТЗ будет состоять из таких простых сторей (только вырастет их количество).
Важно: стори не должны описывать слишком крупный функционал (например, несколько экранов) или слишком мелкий (например, одну кнопку). Как правило, одна стори – это одна фича или механика продукта. Например, стори может полностью описывать регистрацию нового пользователя. Чтобы поставить задачу на верстку нового лендинга – мне, как правило, тоже хватает одной стори.
Если ТЗ большое и значимое, то перед списком сторей я вкратце пишу: зачем мы его делаем и каких результатов хотим достичь. Просто чтобы у разработчиков была общая картина.
В целом, получается примерно так:
Окей, чтобы понять, как это работает – давайте разобьем какой-нибудь продукт на такие story.
Например, мы решили сделать приложение «нейрособутыльник». В нем нейросеть будет вести задушевные беседы с продактами, у которых не задался день (и нет друзей).
Для простоты считаем, что у нас уже есть натренированная нейросеть и нам нужно сделать ей интерфейс в виде приложения.
Вероятно, ТЗ будет состоять из таких сторей:
Осталось расписать каждую стори (в указанном выше формате) и отдать в разработку. Я же говорил, что будет легко.
Есть ряд методик, которые ежедневно помогают мне в работе над продуктом. Вот те из них, которые касаются написания техзаданий.
Лайфхак №1: Детализировать итеративно
Сейчас я вообще не пишу ТЗ – они сами, фоново, появляются в процессе работы.
Когда появляется новая задача – я сразу прикидываю: а какие подзадачи нужны, чтобы это сделать? И тут же фиксирую каждую подзадачу в формате story (только название, детали будут потом).
Таким образом, у меня сразу готово обобщенное техзадание. Остается только детализировать story до той степени, когда можно будет отдать ТЗ в разработку.
Детализация тоже идет фоново: пока я ресерчу и продумываю детали – сразу делаю заметки внутри соответствующих сторей. Вместо дизайна вставляю прототипы из NinjaMock.
Такой подход заметно ускоряет работу. Плюс позволяет не упустить общую картину и не зарыться в детали раньше времени.
Лайфхак №2: Не работать с джиннами
Был такой старый фильм [2], где джинн исполнял желания самым хреновым способом.
Конечно, вменяемый разработчик не будет специально искать возможность навредить.
Но иногда людям безразлично, над чем они работают. Тогда они делают задачу «как написано», не особо вникая, зачем это нужно. Периодически это будет приводить к большим и малым фэйлам. Ну да, продакшн лег… но никто же не прописал в задаче, что нужно проверить – не сломает ли такая реализация все остальное.
Не скажу про аутсорс, но в продукте такой подход не приемлем. Хороший разработчик строит храм, а не просто кирпичи кладет. То есть он видит общую картину и вникает в происходящее. Такие ребята нередко предлагают альтернативные решения и сами предупреждают о подводных камнях.
Поэтому если вы хотите, чтобы ваши ТЗ делались наилучшим образом – то иногда нужно улучшать не ТЗ, а культуру разработки в команде. В целом, это задача PM, но продакт тоже может влиять на ситуацию. Особенно если команда ему доверяет (благодаря его продуманным и хорошо оформленным ТЗ, например).
Лайфхак №3: Отделить ТЗ от документации
Техзадание отвечает на вопрос «что нужно сделать?».
А документация – на вопрос «как это сделано / как это работает?».
ТЗ пишется до реализации задачи, а документация – после.
Если мне нужно переставить шкаф – я напишу задачу в духе «переставить отсюда -> сюда». Но не буду чертить архитектурный план дома, в котором стоит шкаф.
Иногда встречается мнение, что ТЗ нужно писать так, чтобы это была как бы заодно и документация. Это пагубная теория. Полноценной документации все равно не получится, потому что заранее неизвестно, как точно техзадание будет реализовано. Кроме того, разработчикам нужна свобода для маневра, которую документация не предусматривает. Ну и главное – такое ТЗ писать в разы дольше и получится оно громоздким.
Бывают разные продукты и разные стартапы. Кто-то может вообще обойтись без документации. Но если вам документация все же нужна – наймите джуна, который будет детально описывать функционал уже после его реализации. Для описания существующего функционала особых навыков не нужно, зато вы сэкономите время и нервы скилловых сотрудников – продактов и разработчиков.
Лайфхак №4: Научиться программировать
Чисто эмпирическое наблюдение: продакты, которые умеют программировать – лучше формулируют задачи. Причем не обязательно становиться синьор-бэкэндщиком, достаточно освоить любой язык программирования и понять суть алгоритмического
В свое время я безудержно кодил еще на хтоническом Спектруме [4], а в студенческие годы доводилось даже писать драйвера на Ассемблере. То есть с программированием я знаком не понаслышке – и это, безусловно, помогает находить общий язык с разработчиками.
Лайфхак №5: Думать много, писать мало
Наибольшие проблемы всегда возникают с задачами, которые до конца не понимает сам заказчик. Например, ему нужен новый отчет в админке, но как будет формироваться этот отчет – он не вполне представляет. Мол, тыжпрограммисты разберутся. Нет, это так не работает.
Единственный способ написать хорошую задачу, которую сделают правильно, – это вникнуть. В идеале, разобраться в задаче настолько, чтобы вы сами могли бы ее сделать… если бы умели программировать.
Но когда вы разобрались – не нужно вываливать всю найденную инфу в ТЗ. Как раз глубокое понимание задачи позволяет откинуть лишнее и написать только то, что имеет значение.
P.P.S. Если у вас есть собственный формат техзаданий или лайфхаки при их написании – пожалуйста, поделитесь в комментариях.
Автор: Ventarron
Источник [5]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/tehnicheskoe-zadanie/355642
Ссылки в тексте:
[1] Image: https://habr.com/ru/post/513784/
[2] старый фильм: https://ru.wikipedia.org/wiki/%D0%98%D1%81%D0%BF%D0%BE%D0%BB%D0%BD%D0%B8%D1%82%D0%B5%D0%BB%D1%8C_%D0%B6%D0%B5%D0%BB%D0%B0%D0%BD%D0%B8%D0%B9
[3] мышления: http://www.braintools.ru
[4] Спектруме: https://lurkmore.to/%D0%A1%D0%BF%D0%B5%D0%BA%D1%82%D1%80%D1%83%D0%BC
[5] Источник: https://habr.com/ru/post/513784/?utm_source=habrahabr&utm_medium=rss&utm_campaign=513784
Нажмите здесь для печати.