Ну я стараюсь разработчиков лишний раз не дергать — т.к. они погружены в текущий спринт, пока я готовлю ТЗ в следующий.
А чтобы хорошо проработать задачу, я чаще хожу «в поля»: интервью с пользователями, копание в аналитике, опрос стейкхолдеров, ресерч по конкурентам и т.п.
Наверное, за консультацией к разработчикам обращаюсь всего в двух случаях:
Когда не знаю, можно ли в принципе реализовать какой-то функционал в разумные сроки
Когда есть несколько вариантов технической реализации, которые влияют на продуктовую логику — и нужно выбрать как будет проще сделать
Возможно меня поправят ребята из аутсорса, но, насколько я понимаю: ТЗ по ГОСТу нужно скорее юристам, чем разработчикам. Причем только в том случае, когда заказчик и исполнитель работают в разных компаниях.
Меня конечно шокирует, насколько можно усложнить написание ТЗ благодаря ГОСТу. Но, возможно, это оправдано, когда речь идет об автоматизации процессов на крупном государственном производстве и за нестыковку в ТЗ можно присесть по какой-нибудь веселой статье.
В любом случае, в продуктовой компании, где разработчики сидят в двух шагах от продакта — никакие ГОСТы не нужны. Более того, тот формат ТЗ, который я предлагаю в своей статье — можно назвать антиГОСТом, т.к. из него максимально вычищены все формальности, чтобы оставить только суть.
Ну к классическим user story мой формат относится довольно опосредованно :)
Потому и написал, что это вольная смесь. По сути от классики здесь только емкие формулировки о том, что нужно сделать.
Понятно, пример про дверь выбран упрощенный — но чаще всего настоящие стори у меня не намного сложнее. А все детали вроде толщины стен зафиксированы на уровне гайдлайнов. Ну и я бы не пропагандировал такой формат, если бы он приводил к неправильной реализации. В том-то и кайф, что такое простое описание дает высокую точность реализации.
Впрочем, бывают стори, где действительно нужно указать на нюансы, в таком случае само название стори остается таким же простым, но вот в столбце Result может быть довольно подробный список.
И еще, что хочу подчеркнуть по поводу такого формата: не важно, что было на месте этой двери раньше — хоть избушка на курьих ножках. Если в definition of done написано, что теперь там должна быть дверь — то задача будет выполнена только тогда, когда там будет именно дверь и именно такая как в дизайне. А если мне нужно что-то оставить от избушки — то я просто добавлю пункт про миграцию в описание.
Ну и это мы сейчас говорим об описании задачи. А что реально нужно заказчикам — это нужно выяснить до того как отдавать задачу в разработку, конечно. Т.е. я предполагаю, что продакт уже провел хороший кастдев. Тогда он не просто делает то, о чем просит пользователь, а то, что реально закроет проблему наилучшим образом.
Да, тоже соглашусь.
Джиннами становятся не от хорошей жизни.
Если продакт хочет, чтобы его задачи делались хорошо — нужно и самому позаботиться о разработчике, который будет их делать. Как минимум нормально эти задачи оформить.
И еще, думаю, если идти работать в продуктовую компанию — важно выбирать ее не только по условиям труда, но и чтобы сам продукт нравился. Чтобы он реально людям помогал, чтобы не стыдно было сказать «это я сделал», а в идеале — и самому хотелось им пользоваться.
При таких условиях, полагаю, безразличного отношения не будет :)
В основном я работал с GameDev и EdTech проектами. Безусловно, тут меньше порог входа, чем в FinTech и MedTech.
Но с точки зрения постановки задач — не думаю, что возникла бы проблема. И вот почему:
1. В продуктовой компании разработчики вольно-невольно начинают разбираться в предметной области. Поэтому вы общаетесь в одном контексте.
2. ТЗ ж не энциклопедия, поэтому я бы внутри ТЗ не объяснял, что значит параметр Х. Максимум можно оставить ссылку на тематическую статью (для самых любопытных). А так я бы просто написал формулу как посчитать Х и показал в дизайне куда этот Х выводить.
Если разработчику нужно понимать ряд терминов, чтобы работать — лучше вынести эти термины в отдельную базу знаний, а не прописывать в каждом ТЗ.
Ну PM это широкая профессия, намного шире чем тот же product, как мне кажется.
Но если говорить о роли PM в продуктовой компании — то у нас это не просто человек, который компонует и ведет спринты. Это еще и некий лидер мнений, который формирует атмосферу в команде, разруливает сложные ситуации, задает вектор развития и планку качества.
Например, во время ретроспективы PM может сказать: «Вот это мы сделали круто, а здесь давайте в следующий раз сделаем иначе». Или так: «Вот Иван — красавчик, увидел потенциальную проблему и предупредил о ней. А Петр зря не уточнил по поводу этой задачи, придется ее теперь переделывать».
Вот как-то так, в моем представлении, PM влияет на команду и культуру разработки.
Думаю, у каждого продакта есть свои преимущества, смотря откуда он пришел:
бывшие дизайнеры лучше проектируют путь пользователя
бывшие разработчики лучше понимают ограничения и формулируют задачи
бывшие тестировщики хорошо видят негативные кейсы
и так далее
Да, благодаря техническому бэкграунду, я иногда могу быть полезным даже на техническом митинге. Но, честно говоря, в этом редко есть необходимость и они бы и без меня замечательно справились. А вот базовые знания программирования «пригождаются» каждый день. Впрочем, согласен, что каждому продакту полезно хотя бы раз в жизни самостоятельно накодить и запустить хотя бы небольшой продукт.
А с формальными методиками дела не имел. Насколько я понимаю, они нужны в областях вроде MedTech, где ошибки слишком дорого стоят.
Если говорить о небольших ТЗ, то их обычно берут целиком в спринт. Поэтому там нет смысла как-то приоритизировать задачи внутри.
Но иногда получаются прям объемные техзадания. Например, если делаю глобальное ревью устоявшегося продукта и выписываю все необходимые доработки. Тогда да, ставлю значок (!) возле ключевых сторей — чтобы PM понимал: что брать сразу, а что можно отложить до следующего спринта.
Как-то так это выглядит:
А чтобы хорошо проработать задачу, я чаще хожу «в поля»: интервью с пользователями, копание в аналитике, опрос стейкхолдеров, ресерч по конкурентам и т.п.
Наверное, за консультацией к разработчикам обращаюсь всего в двух случаях:
Меня конечно шокирует, насколько можно усложнить написание ТЗ благодаря ГОСТу. Но, возможно, это оправдано, когда речь идет об автоматизации процессов на крупном государственном производстве и за нестыковку в ТЗ можно присесть по какой-нибудь веселой статье.
В любом случае, в продуктовой компании, где разработчики сидят в двух шагах от продакта — никакие ГОСТы не нужны. Более того, тот формат ТЗ, который я предлагаю в своей статье — можно назвать антиГОСТом, т.к. из него максимально вычищены все формальности, чтобы оставить только суть.
Потому и написал, что это вольная смесь. По сути от классики здесь только емкие формулировки о том, что нужно сделать.
Понятно, пример про дверь выбран упрощенный — но чаще всего настоящие стори у меня не намного сложнее. А все детали вроде толщины стен зафиксированы на уровне гайдлайнов. Ну и я бы не пропагандировал такой формат, если бы он приводил к неправильной реализации. В том-то и кайф, что такое простое описание дает высокую точность реализации.
Впрочем, бывают стори, где действительно нужно указать на нюансы, в таком случае само название стори остается таким же простым, но вот в столбце Result может быть довольно подробный список.
И еще, что хочу подчеркнуть по поводу такого формата: не важно, что было на месте этой двери раньше — хоть избушка на курьих ножках. Если в definition of done написано, что теперь там должна быть дверь — то задача будет выполнена только тогда, когда там будет именно дверь и именно такая как в дизайне. А если мне нужно что-то оставить от избушки — то я просто добавлю пункт про миграцию в описание.
Ну и это мы сейчас говорим об описании задачи. А что реально нужно заказчикам — это нужно выяснить до того как отдавать задачу в разработку, конечно. Т.е. я предполагаю, что продакт уже провел хороший кастдев. Тогда он не просто делает то, о чем просит пользователь, а то, что реально закроет проблему наилучшим образом.
Джиннами становятся не от хорошей жизни.
Если продакт хочет, чтобы его задачи делались хорошо — нужно и самому позаботиться о разработчике, который будет их делать. Как минимум нормально эти задачи оформить.
И еще, думаю, если идти работать в продуктовую компанию — важно выбирать ее не только по условиям труда, но и чтобы сам продукт нравился. Чтобы он реально людям помогал, чтобы не стыдно было сказать «это я сделал», а в идеале — и самому хотелось им пользоваться.
При таких условиях, полагаю, безразличного отношения не будет :)
Но, честно скажу, за всю свою карьеру в IT — ни разу живьем их не видел :)
В большинстве продуктовых компаний, полагаю, это проще организовано.
У нас это происходит так:
Получается, срок спринта фиксирован, стоимость вообще не обсуждаем с командой разработки, а объем согласовываем с PM.
А если весь текст размыть, то это ж голая табличка будет.
Но, если хотите, можете скинуть какую-то задачу, а я распишу ее в своем формате — чтобы был наглядный пример.
В основном я работал с GameDev и EdTech проектами. Безусловно, тут меньше порог входа, чем в FinTech и MedTech.
Но с точки зрения постановки задач — не думаю, что возникла бы проблема. И вот почему:
1. В продуктовой компании разработчики вольно-невольно начинают разбираться в предметной области. Поэтому вы общаетесь в одном контексте.
2. ТЗ ж не энциклопедия, поэтому я бы внутри ТЗ не объяснял, что значит параметр Х. Максимум можно оставить ссылку на тематическую статью (для самых любопытных). А так я бы просто написал формулу как посчитать Х и показал в дизайне куда этот Х выводить.
Если разработчику нужно понимать ряд терминов, чтобы работать — лучше вынести эти термины в отдельную базу знаний, а не прописывать в каждом ТЗ.
Но если говорить о роли PM в продуктовой компании — то у нас это не просто человек, который компонует и ведет спринты. Это еще и некий лидер мнений, который формирует атмосферу в команде, разруливает сложные ситуации, задает вектор развития и планку качества.
Например, во время ретроспективы PM может сказать: «Вот это мы сделали круто, а здесь давайте в следующий раз сделаем иначе». Или так: «Вот Иван — красавчик, увидел потенциальную проблему и предупредил о ней. А Петр зря не уточнил по поводу этой задачи, придется ее теперь переделывать».
Вот как-то так, в моем представлении, PM влияет на команду и культуру разработки.
Да, благодаря техническому бэкграунду, я иногда могу быть полезным даже на техническом митинге. Но, честно говоря, в этом редко есть необходимость и они бы и без меня замечательно справились. А вот базовые знания программирования «пригождаются» каждый день. Впрочем, согласен, что каждому продакту полезно хотя бы раз в жизни самостоятельно накодить и запустить хотя бы небольшой продукт.
А с формальными методиками дела не имел. Насколько я понимаю, они нужны в областях вроде MedTech, где ошибки слишком дорого стоят.
Но иногда получаются прям объемные техзадания. Например, если делаю глобальное ревью устоявшегося продукта и выписываю все необходимые доработки. Тогда да, ставлю значок (!) возле ключевых сторей — чтобы PM понимал: что брать сразу, а что можно отложить до следующего спринта.
Как-то так это выглядит: