Комментарии 29
Пользуюсь похожим шаблоном, когда пишу спецификации.
А как вы передаете информацию о приоритетах — например, если есть какие-нибудь must и nice to have? Или в данном случае ТЗ — это исключительно must?
Отдельный респект за Лайфхак №4. Многие пытаются прийти на роль ПО или БА именно в ИТ без понимания того, как работает эта сфера. Считаю, что хотя бы базовое представление нужно иметь для комфортного общения с разработчиками.
Но иногда получаются прям объемные техзадания. Например, если делаю глобальное ревью устоявшегося продукта и выписываю все необходимые доработки. Тогда да, ставлю значок (!) возле ключевых сторей — чтобы PM понимал: что брать сразу, а что можно отложить до следующего спринта.
Как-то так это выглядит:
- бывшие дизайнеры лучше проектируют путь пользователя
- бывшие разработчики лучше понимают ограничения и формулируют задачи
- бывшие тестировщики хорошо видят негативные кейсы
- и так далее
Да, благодаря техническому бэкграунду, я иногда могу быть полезным даже на техническом митинге. Но, честно говоря, в этом редко есть необходимость и они бы и без меня замечательно справились. А вот базовые знания программирования «пригождаются» каждый день. Впрочем, согласен, что каждому продакту полезно хотя бы раз в жизни самостоятельно накодить и запустить хотя бы небольшой продукт.
А с формальными методиками дела не имел. Насколько я понимаю, они нужны в областях вроде MedTech, где ошибки слишком дорого стоят.
Мне, как PM'у, не очень понятен момент, где я должен влиять на культуру разработки. Может, я другой смысл вкладываю в эти слова, поэтому прошу пояснить.
Поздозреваю, что автор имеет в виду вовлекать команду в финалочку ТЗ, чтобы не сразу "я сделаль", а сначала шли предложения и обсуждения как это сделать лучше.
Так это к аналитику или владельцу продукта тогда. Это один из признаков наличия у них минимального (я подчеркиваю это) опыта — понятная разработчику постановка задачи (из этого вытекает необходимость привлечения разработчика для ревью).
PM в данном случае только процесс коммуникации может наладить, если у аналитика или владельца продукта не хватает опята для этого.
Но если говорить о роли PM в продуктовой компании — то у нас это не просто человек, который компонует и ведет спринты. Это еще и некий лидер мнений, который формирует атмосферу в команде, разруливает сложные ситуации, задает вектор развития и планку качества.
Например, во время ретроспективы PM может сказать: «Вот это мы сделали круто, а здесь давайте в следующий раз сделаем иначе». Или так: «Вот Иван — красавчик, увидел потенциальную проблему и предупредил о ней. А Петр зря не уточнил по поводу этой задачи, придется ее теперь переделывать».
Вот как-то так, в моем представлении, PM влияет на команду и культуру разработки.
Сейчас я трачу время своих тимлидов на финальную проработку таска вместе со мной, в основном это сводится к 2 ключевым вопросам:
— Сможет ли сам тимлид выполнить задачу качественно, опираясь только на предоставленные данные?
— Сможет ли тимлид оказать помощь члену своей команды при разработке?
Пока во многих моих задачах это напоминает крайность «и так сойдет», но помогает прощупать подводные камни реализации и в следующей схожей задаче заставляет меня продумать чуть глубже.
Как же вы точно некоторых людей назвали «джиннами» :) Это самая лучшая метафора для обозначения явления, которую я где-либо видел.
Доводилось ли вам применять ваш подход в проектах связанных с сложной предметной областью? Типа биржевых торгов, медицины, САПР и т.д. User story для интернет магазина это хорошо, разработчик и так знает что такое интернет магазин. А вот написать «юзер должен уметь ставить M-ELO ордера» это считай ничего не написать, если разработчик не трейдер и не квант. А расписывать, что есть M-ELO не так то просто и много букв.
В основном я работал с GameDev и EdTech проектами. Безусловно, тут меньше порог входа, чем в FinTech и MedTech.
Но с точки зрения постановки задач — не думаю, что возникла бы проблема. И вот почему:
1. В продуктовой компании разработчики вольно-невольно начинают разбираться в предметной области. Поэтому вы общаетесь в одном контексте.
2. ТЗ ж не энциклопедия, поэтому я бы внутри ТЗ не объяснял, что значит параметр Х. Максимум можно оставить ссылку на тематическую статью (для самых любопытных). А так я бы просто написал формулу как посчитать Х и показал в дизайне куда этот Х выводить.
Если разработчику нужно понимать ряд терминов, чтобы работать — лучше вынести эти термины в отдельную базу знаний, а не прописывать в каждом ТЗ.
Подскажите, а можно посмотреть на боевые обезличенные ТЗ, чтобы уж совсем проникнуться?
В большинстве продуктовых компаний, полагаю, это проще организовано.
У нас это происходит так:
- Я перед спринтом говорю PM-у — давай возьмем в спринт вот эти крупные ТЗ и вот эту дюжину мелких задач.
- PM компонует спринт, берет мои задачи + теходолг + баги.
- Разработчики эстимируют все задачи будущего спринта.
- В итоге, если получился перегруз — садимся вместе с PM и думаем что выкинуть.
Получается, срок спринта фиксирован, стоимость вообще не обсуждаем с командой разработки, а объем согласовываем с PM.
Для внутренней разработки или T&M такой подход отлично работает.
Для Fix Price контрактов Flex Scope сложно применять. С фикс прайс важно описать Scope иерархически и обязательно включить Assumption, Constrains, Dependencies, Risks и Out of scope
Кто-то может вообще обойтись без документации. Но если вам документация все же нужна – наймите джуна, который будет детально описывать функционал уже после его реализации.
Вообще-то под это дело даже отдельная профессия есть, технический писатель и даже со своим профстандартом :)
Джиннами становятся не от хорошей жизни.
Если продакт хочет, чтобы его задачи делались хорошо — нужно и самому позаботиться о разработчике, который будет их делать. Как минимум нормально эти задачи оформить.
И еще, думаю, если идти работать в продуктовую компанию — важно выбирать ее не только по условиям труда, но и чтобы сам продукт нравился. Чтобы он реально людям помогал, чтобы не стыдно было сказать «это я сделал», а в идеале — и самому хотелось им пользоваться.
При таких условиях, полагаю, безразличного отношения не будет :)
Потому и написал, что это вольная смесь. По сути от классики здесь только емкие формулировки о том, что нужно сделать.
Понятно, пример про дверь выбран упрощенный — но чаще всего настоящие стори у меня не намного сложнее. А все детали вроде толщины стен зафиксированы на уровне гайдлайнов. Ну и я бы не пропагандировал такой формат, если бы он приводил к неправильной реализации. В том-то и кайф, что такое простое описание дает высокую точность реализации.
Впрочем, бывают стори, где действительно нужно указать на нюансы, в таком случае само название стори остается таким же простым, но вот в столбце Result может быть довольно подробный список.
И еще, что хочу подчеркнуть по поводу такого формата: не важно, что было на месте этой двери раньше — хоть избушка на курьих ножках. Если в definition of done написано, что теперь там должна быть дверь — то задача будет выполнена только тогда, когда там будет именно дверь и именно такая как в дизайне. А если мне нужно что-то оставить от избушки — то я просто добавлю пункт про миграцию в описание.
Ну и это мы сейчас говорим об описании задачи. А что реально нужно заказчикам — это нужно выяснить до того как отдавать задачу в разработку, конечно. Т.е. я предполагаю, что продакт уже провел хороший кастдев. Тогда он не просто делает то, о чем просит пользователь, а то, что реально закроет проблему наилучшим образом.
А что касаемо предыстории — тут, пожалуй, мы все вольно или нет приходим к привлечению разработчиков к этапу аналитики, когда показываешь проработанный процесс, приходишь с ними к общему пониманию того, что должно быть сделано, дробишь на шаги (user story) таким образом, чтобы именно им было удобно, и уже потом отдаешь в работу. По крайней мере у нас в команде происходит нечто подобное, поэтому в какой-то степени начали подсаживаться на DDD.
А чтобы хорошо проработать задачу, я чаще хожу «в поля»: интервью с пользователями, копание в аналитике, опрос стейкхолдеров, ресерч по конкурентам и т.п.
Наверное, за консультацией к разработчикам обращаюсь всего в двух случаях:
- Когда не знаю, можно ли в принципе реализовать какой-то функционал в разумные сроки
- Когда есть несколько вариантов технической реализации, которые влияют на продуктовую логику — и нужно выбрать как будет проще сделать
Меня конечно шокирует, насколько можно усложнить написание ТЗ благодаря ГОСТу. Но, возможно, это оправдано, когда речь идет об автоматизации процессов на крупном государственном производстве и за нестыковку в ТЗ можно присесть по какой-нибудь веселой статье.
В любом случае, в продуктовой компании, где разработчики сидят в двух шагах от продакта — никакие ГОСТы не нужны. Более того, тот формат ТЗ, который я предлагаю в своей статье — можно назвать антиГОСТом, т.к. из него максимально вычищены все формальности, чтобы оставить только суть.
Ты можешь писать безупречные ТЗ, но какой в этом толк, если разработчик твой плачет?