Как стать автором
Обновить

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

Время на прочтение9 мин
Количество просмотров24K
Всего голосов 23: ↑21 и ↓2+31
Комментарии29

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Публикации

Истории