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



В далекой-далекой галактике трудится сферический 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
  • Номер (№)
    Нужен, чтобы быстро ссылаться на story в любых коммуникациях и внутри ТЗ.
  • Название (Story)
    Вкратце объясняет цель / суть / содержание задачи. Помогает легко ориентироваться в ТЗ. Даже далекий от разработки стейкхолдер может бегло просмотреть названия сторей, чтобы понять, о чем техзадание. Тут можно писать неформально, так даже веселее.
  • Definition of done
    Состоит из двух частей: условие (preconditions / actions) и результат (result). Условие описывает – что сделал пользователь или какое событие произошло. Результат – к чему должно привести выполнение условия согласно нашей задумке.

    Это достаточно гибкий и максимально однозначный способ описать необходимую логику работы продукта. И это практически готовый кейс для тестировщиков. Иногда, если функционал достаточно простой – я вообще убираю условие и оставляю только результат.
  • Design
    Я никогда не описываю дизайн текстом. В ТЗ должна быть только логика работы продукта, а визуальную часть разработчики без проблем посмотрят в Figma (ну или что вы используете для хранения дизайн-макетов). Поэтому достаточно ссылки на дизайн и скриншота для наглядности.

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

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



Пример


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

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

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

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

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



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


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

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


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

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

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

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

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


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

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

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

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

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


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

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

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

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

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


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

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

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


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

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

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



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

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

Подробнее
Реклама

Комментарии 29

    +1
    Годно, очень годно :)
    Пользуюсь похожим шаблоном, когда пишу спецификации.
    А как вы передаете информацию о приоритетах — например, если есть какие-нибудь must и nice to have? Или в данном случае ТЗ — это исключительно must?

    Отдельный респект за Лайфхак №4. Многие пытаются прийти на роль ПО или БА именно в ИТ без понимания того, как работает эта сфера. Считаю, что хотя бы базовое представление нужно иметь для комфортного общения с разработчиками.
      0
      Если говорить о небольших ТЗ, то их обычно берут целиком в спринт. Поэтому там нет смысла как-то приоритизировать задачи внутри.

      Но иногда получаются прям объемные техзадания. Например, если делаю глобальное ревью устоявшегося продукта и выписываю все необходимые доработки. Тогда да, ставлю значок (!) возле ключевых сторей — чтобы PM понимал: что брать сразу, а что можно отложить до следующего спринта.
      Как-то так это выглядит:
    • НЛО прилетело и опубликовало эту надпись здесь
        +1
        Думаю, у каждого продакта есть свои преимущества, смотря откуда он пришел:
        • бывшие дизайнеры лучше проектируют путь пользователя
        • бывшие разработчики лучше понимают ограничения и формулируют задачи
        • бывшие тестировщики хорошо видят негативные кейсы
        • и так далее

        Да, благодаря техническому бэкграунду, я иногда могу быть полезным даже на техническом митинге. Но, честно говоря, в этом редко есть необходимость и они бы и без меня замечательно справились. А вот базовые знания программирования «пригождаются» каждый день. Впрочем, согласен, что каждому продакту полезно хотя бы раз в жизни самостоятельно накодить и запустить хотя бы небольшой продукт.

        А с формальными методиками дела не имел. Насколько я понимаю, они нужны в областях вроде MedTech, где ошибки слишком дорого стоят.
        +1

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

          0

          Поздозреваю, что автор имеет в виду вовлекать команду в финалочку ТЗ, чтобы не сразу "я сделаль", а сначала шли предложения и обсуждения как это сделать лучше.

            0

            Так это к аналитику или владельцу продукта тогда. Это один из признаков наличия у них минимального (я подчеркиваю это) опыта — понятная разработчику постановка задачи (из этого вытекает необходимость привлечения разработчика для ревью).
            PM в данном случае только процесс коммуникации может наладить, если у аналитика или владельца продукта не хватает опята для этого.

            +1
            Ну PM это широкая профессия, намного шире чем тот же product, как мне кажется.

            Но если говорить о роли PM в продуктовой компании — то у нас это не просто человек, который компонует и ведет спринты. Это еще и некий лидер мнений, который формирует атмосферу в команде, разруливает сложные ситуации, задает вектор развития и планку качества.

            Например, во время ретроспективы PM может сказать: «Вот это мы сделали круто, а здесь давайте в следующий раз сделаем иначе». Или так: «Вот Иван — красавчик, увидел потенциальную проблему и предупредил о ней. А Петр зря не уточнил по поводу этой задачи, придется ее теперь переделывать».

            Вот как-то так, в моем представлении, PM влияет на команду и культуру разработки.
            +2
            Хорошая статья! Спасибо!

            Сейчас я трачу время своих тимлидов на финальную проработку таска вместе со мной, в основном это сводится к 2 ключевым вопросам:
            — Сможет ли сам тимлид выполнить задачу качественно, опираясь только на предоставленные данные?
            — Сможет ли тимлид оказать помощь члену своей команды при разработке?

            Пока во многих моих задачах это напоминает крайность «и так сойдет», но помогает прощупать подводные камни реализации и в следующей схожей задаче заставляет меня продумать чуть глубже.
              +1

              Как же вы точно некоторых людей назвали «джиннами» :) Это самая лучшая метафора для обозначения явления, которую я где-либо видел.


              Доводилось ли вам применять ваш подход в проектах связанных с сложной предметной областью? Типа биржевых торгов, медицины, САПР и т.д. User story для интернет магазина это хорошо, разработчик и так знает что такое интернет магазин. А вот написать «юзер должен уметь ставить M-ELO ордера» это считай ничего не написать, если разработчик не трейдер и не квант. А расписывать, что есть M-ELO не так то просто и много букв.

                0
                Справедливый вопрос, спасибо!

                В основном я работал с GameDev и EdTech проектами. Безусловно, тут меньше порог входа, чем в FinTech и MedTech.

                Но с точки зрения постановки задач — не думаю, что возникла бы проблема. И вот почему:
                1. В продуктовой компании разработчики вольно-невольно начинают разбираться в предметной области. Поэтому вы общаетесь в одном контексте.
                2. ТЗ ж не энциклопедия, поэтому я бы внутри ТЗ не объяснял, что значит параметр Х. Максимум можно оставить ссылку на тематическую статью (для самых любопытных). А так я бы просто написал формулу как посчитать Х и показал в дизайне куда этот Х выводить.

                Если разработчику нужно понимать ряд терминов, чтобы работать — лучше вынести эти термины в отдельную базу знаний, а не прописывать в каждом ТЗ.
                +1
                Автор, за статью большое спасибо :) Обсудили среди команды, будем «покурить» что можно изменить в своем процессе.
                Подскажите, а можно посмотреть на боевые обезличенные ТЗ, чтобы уж совсем проникнуться?
                  0
                  Ох, хотел бы похвастаться, но все реальные ТЗ под NDA, к сожалению.
                  А если весь текст размыть, то это ж голая табличка будет.

                  Но, если хотите, можете скинуть какую-то задачу, а я распишу ее в своем формате — чтобы был наглядный пример.
                  0
                  Как фиксируется Scope и стоимость?
                    0
                    Думаю, история про фиксацию сроков-объема-стоимости — больше про аутсорс.

                    В большинстве продуктовых компаний, полагаю, это проще организовано.
                    У нас это происходит так:

                    1. Я перед спринтом говорю PM-у — давай возьмем в спринт вот эти крупные ТЗ и вот эту дюжину мелких задач.
                    2. PM компонует спринт, берет мои задачи + теходолг + баги.
                    3. Разработчики эстимируют все задачи будущего спринта.
                    4. В итоге, если получился перегруз — садимся вместе с PM и думаем что выкинуть.

                    Получается, срок спринта фиксирован, стоимость вообще не обсуждаем с командой разработки, а объем согласовываем с PM.
                      0
                      У вас получилось не ТЗ, а беклог.
                      Для внутренней разработки или T&M такой подход отлично работает.
                      Для Fix Price контрактов Flex Scope сложно применять. С фикс прайс важно описать Scope иерархически и обязательно включить Assumption, Constrains, Dependencies, Risks и Out of scope
                        0
                        Это продуктовая команда, scope — это беклог спринта в соответствии с ресурсами команды по FF, а стоимость — зп разработчиков и задача project manager как раз задать 100% нагрузку на команду.
                    +1
                    Кто-то может вообще обойтись без документации. Но если вам документация все же нужна – наймите джуна, который будет детально описывать функционал уже после его реализации.

                    Вообще-то под это дело даже отдельная профессия есть, технический писатель и даже со своим профстандартом :)
                      0
                      Да, слышал про таких ребят.
                      Но, честно скажу, за всю свою карьеру в IT — ни разу живьем их не видел :)
                        0
                        Ну в больших фирмах они обычно есть, в средних-маленьких их обычно нет. Так что живьём я их действительно видел :)
                      +1
                      Полностью согласен со вторым лайфхаком. Но также `джиннами` становятся, после того как неграмотный пм делает из разраба отладчик, подсовывая откровенный бред — ожидая что он то всё поправит или даже полностью переделает попутно объясняя как всё работает (ну а кто нанимался доучивать начальство?). Так что если кому-то кругом например часто встречаются `джинны` следует подумать и о себе.
                        0
                        Да, тоже соглашусь.
                        Джиннами становятся не от хорошей жизни.

                        Если продакт хочет, чтобы его задачи делались хорошо — нужно и самому позаботиться о разработчике, который будет их делать. Как минимум нормально эти задачи оформить.

                        И еще, думаю, если идти работать в продуктовую компанию — важно выбирать ее не только по условиям труда, но и чтобы сам продукт нравился. Чтобы он реально людям помогал, чтобы не стыдно было сказать «это я сделал», а в идеале — и самому хотелось им пользоваться.

                        При таких условиях, полагаю, безразличного отношения не будет :)
                        0
                        Какое-то у вас странное понимание user story. Story должна давать какую-то предысторию, понимание, зачем это вообще понадобилось (оно же story, не?), а не вот это вот «Дверь мне запили». Хорошо, если просто есть пустой проём от строителей и купленная дверь. Да и ту можно повесить на левую сторону и на правую. А если это 16-й этаж и наружная стена в 60см? А так и бывает. Делаешь дверь, потом оказывается, что людям было душно. Задаёшь вопрос «а почему не бризер или хотя бы окно?» и в ответ получаешь: «ну у нас же везде в старом офисе двери были, всё хорошо работало».
                          0
                          Ну к классическим user story мой формат относится довольно опосредованно :)
                          Потому и написал, что это вольная смесь. По сути от классики здесь только емкие формулировки о том, что нужно сделать.

                          Понятно, пример про дверь выбран упрощенный — но чаще всего настоящие стори у меня не намного сложнее. А все детали вроде толщины стен зафиксированы на уровне гайдлайнов. Ну и я бы не пропагандировал такой формат, если бы он приводил к неправильной реализации. В том-то и кайф, что такое простое описание дает высокую точность реализации.

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

                          И еще, что хочу подчеркнуть по поводу такого формата: не важно, что было на месте этой двери раньше — хоть избушка на курьих ножках. Если в definition of done написано, что теперь там должна быть дверь — то задача будет выполнена только тогда, когда там будет именно дверь и именно такая как в дизайне. А если мне нужно что-то оставить от избушки — то я просто добавлю пункт про миграцию в описание.

                          Ну и это мы сейчас говорим об описании задачи. А что реально нужно заказчикам — это нужно выяснить до того как отдавать задачу в разработку, конечно. Т.е. я предполагаю, что продакт уже провел хороший кастдев. Тогда он не просто делает то, о чем просит пользователь, а то, что реально закроет проблему наилучшим образом.
                            0
                            Если я правильно поняла, то собственно сам процесс (история как таковая), тут стоит над user story, а в user story, которые отдаются разработчикам, отражен конкретный шаг: 1) поступил документ — выполни проверку, 2) выполнил проверку — выбрал маршрут движения, 3) выбрал маршрут — отдал документ дальше.
                            А что касаемо предыстории — тут, пожалуй, мы все вольно или нет приходим к привлечению разработчиков к этапу аналитики, когда показываешь проработанный процесс, приходишь с ними к общему пониманию того, что должно быть сделано, дробишь на шаги (user story) таким образом, чтобы именно им было удобно, и уже потом отдаешь в работу. По крайней мере у нас в команде происходит нечто подобное, поэтому в какой-то степени начали подсаживаться на DDD.
                              0
                              Ну я стараюсь разработчиков лишний раз не дергать — т.к. они погружены в текущий спринт, пока я готовлю ТЗ в следующий.

                              А чтобы хорошо проработать задачу, я чаще хожу «в поля»: интервью с пользователями, копание в аналитике, опрос стейкхолдеров, ресерч по конкурентам и т.п.

                              Наверное, за консультацией к разработчикам обращаюсь всего в двух случаях:

                              • Когда не знаю, можно ли в принципе реализовать какой-то функционал в разумные сроки
                              • Когда есть несколько вариантов технической реализации, которые влияют на продуктовую логику — и нужно выбрать как будет проще сделать
                          0
                          ТЗ по ГОСТу имеет смысл?
                            0
                            Возможно меня поправят ребята из аутсорса, но, насколько я понимаю: ТЗ по ГОСТу нужно скорее юристам, чем разработчикам. Причем только в том случае, когда заказчик и исполнитель работают в разных компаниях.

                            Меня конечно шокирует, насколько можно усложнить написание ТЗ благодаря ГОСТу. Но, возможно, это оправдано, когда речь идет об автоматизации процессов на крупном государственном производстве и за нестыковку в ТЗ можно присесть по какой-нибудь веселой статье.

                            В любом случае, в продуктовой компании, где разработчики сидят в двух шагах от продакта — никакие ГОСТы не нужны. Более того, тот формат ТЗ, который я предлагаю в своей статье — можно назвать антиГОСТом, т.к. из него максимально вычищены все формальности, чтобы оставить только суть.
                            +1
                            Использую uml usecase diagram для наглядности всех сценариев. Дальше также итеративно их прорабатываю и отдаю в разработку. Пример:
                            image

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

                            Самое читаемое