Comments 29
Годно, очень годно :)
Пользуюсь похожим шаблоном, когда пишу спецификации.
А как вы передаете информацию о приоритетах — например, если есть какие-нибудь must и nice to have? Или в данном случае ТЗ — это исключительно must?
Отдельный респект за Лайфхак №4. Многие пытаются прийти на роль ПО или БА именно в ИТ без понимания того, как работает эта сфера. Считаю, что хотя бы базовое представление нужно иметь для комфортного общения с разработчиками.
Пользуюсь похожим шаблоном, когда пишу спецификации.
А как вы передаете информацию о приоритетах — например, если есть какие-нибудь must и nice to have? Или в данном случае ТЗ — это исключительно must?
Отдельный респект за Лайфхак №4. Многие пытаются прийти на роль ПО или БА именно в ИТ без понимания того, как работает эта сфера. Считаю, что хотя бы базовое представление нужно иметь для комфортного общения с разработчиками.
Если говорить о небольших ТЗ, то их обычно берут целиком в спринт. Поэтому там нет смысла как-то приоритизировать задачи внутри.
Но иногда получаются прям объемные техзадания. Например, если делаю глобальное ревью устоявшегося продукта и выписываю все необходимые доработки. Тогда да, ставлю значок (!) возле ключевых сторей — чтобы PM понимал: что брать сразу, а что можно отложить до следующего спринта.
Как-то так это выглядит:
Но иногда получаются прям объемные техзадания. Например, если делаю глобальное ревью устоявшегося продукта и выписываю все необходимые доработки. Тогда да, ставлю значок (!) возле ключевых сторей — чтобы PM понимал: что брать сразу, а что можно отложить до следующего спринта.
Как-то так это выглядит:
UFO just landed and posted this here
Думаю, у каждого продакта есть свои преимущества, смотря откуда он пришел:
Да, благодаря техническому бэкграунду, я иногда могу быть полезным даже на техническом митинге. Но, честно говоря, в этом редко есть необходимость и они бы и без меня замечательно справились. А вот базовые знания программирования «пригождаются» каждый день. Впрочем, согласен, что каждому продакту полезно хотя бы раз в жизни самостоятельно накодить и запустить хотя бы небольшой продукт.
А с формальными методиками дела не имел. Насколько я понимаю, они нужны в областях вроде MedTech, где ошибки слишком дорого стоят.
- бывшие дизайнеры лучше проектируют путь пользователя
- бывшие разработчики лучше понимают ограничения и формулируют задачи
- бывшие тестировщики хорошо видят негативные кейсы
- и так далее
Да, благодаря техническому бэкграунду, я иногда могу быть полезным даже на техническом митинге. Но, честно говоря, в этом редко есть необходимость и они бы и без меня замечательно справились. А вот базовые знания программирования «пригождаются» каждый день. Впрочем, согласен, что каждому продакту полезно хотя бы раз в жизни самостоятельно накодить и запустить хотя бы небольшой продукт.
А с формальными методиками дела не имел. Насколько я понимаю, они нужны в областях вроде MedTech, где ошибки слишком дорого стоят.
Мне, как PM'у, не очень понятен момент, где я должен влиять на культуру разработки. Может, я другой смысл вкладываю в эти слова, поэтому прошу пояснить.
Поздозреваю, что автор имеет в виду вовлекать команду в финалочку ТЗ, чтобы не сразу "я сделаль", а сначала шли предложения и обсуждения как это сделать лучше.
Так это к аналитику или владельцу продукта тогда. Это один из признаков наличия у них минимального (я подчеркиваю это) опыта — понятная разработчику постановка задачи (из этого вытекает необходимость привлечения разработчика для ревью).
PM в данном случае только процесс коммуникации может наладить, если у аналитика или владельца продукта не хватает опята для этого.
Ну PM это широкая профессия, намного шире чем тот же product, как мне кажется.
Но если говорить о роли PM в продуктовой компании — то у нас это не просто человек, который компонует и ведет спринты. Это еще и некий лидер мнений, который формирует атмосферу в команде, разруливает сложные ситуации, задает вектор развития и планку качества.
Например, во время ретроспективы PM может сказать: «Вот это мы сделали круто, а здесь давайте в следующий раз сделаем иначе». Или так: «Вот Иван — красавчик, увидел потенциальную проблему и предупредил о ней. А Петр зря не уточнил по поводу этой задачи, придется ее теперь переделывать».
Вот как-то так, в моем представлении, PM влияет на команду и культуру разработки.
Но если говорить о роли PM в продуктовой компании — то у нас это не просто человек, который компонует и ведет спринты. Это еще и некий лидер мнений, который формирует атмосферу в команде, разруливает сложные ситуации, задает вектор развития и планку качества.
Например, во время ретроспективы PM может сказать: «Вот это мы сделали круто, а здесь давайте в следующий раз сделаем иначе». Или так: «Вот Иван — красавчик, увидел потенциальную проблему и предупредил о ней. А Петр зря не уточнил по поводу этой задачи, придется ее теперь переделывать».
Вот как-то так, в моем представлении, PM влияет на команду и культуру разработки.
Хорошая статья! Спасибо!
Сейчас я трачу время своих тимлидов на финальную проработку таска вместе со мной, в основном это сводится к 2 ключевым вопросам:
— Сможет ли сам тимлид выполнить задачу качественно, опираясь только на предоставленные данные?
— Сможет ли тимлид оказать помощь члену своей команды при разработке?
Пока во многих моих задачах это напоминает крайность «и так сойдет», но помогает прощупать подводные камни реализации и в следующей схожей задаче заставляет меня продумать чуть глубже.
Сейчас я трачу время своих тимлидов на финальную проработку таска вместе со мной, в основном это сводится к 2 ключевым вопросам:
— Сможет ли сам тимлид выполнить задачу качественно, опираясь только на предоставленные данные?
— Сможет ли тимлид оказать помощь члену своей команды при разработке?
Пока во многих моих задачах это напоминает крайность «и так сойдет», но помогает прощупать подводные камни реализации и в следующей схожей задаче заставляет меня продумать чуть глубже.
Как же вы точно некоторых людей назвали «джиннами» :) Это самая лучшая метафора для обозначения явления, которую я где-либо видел.
Доводилось ли вам применять ваш подход в проектах связанных с сложной предметной областью? Типа биржевых торгов, медицины, САПР и т.д. User story для интернет магазина это хорошо, разработчик и так знает что такое интернет магазин. А вот написать «юзер должен уметь ставить M-ELO ордера» это считай ничего не написать, если разработчик не трейдер и не квант. А расписывать, что есть M-ELO не так то просто и много букв.
Справедливый вопрос, спасибо!
В основном я работал с GameDev и EdTech проектами. Безусловно, тут меньше порог входа, чем в FinTech и MedTech.
Но с точки зрения постановки задач — не думаю, что возникла бы проблема. И вот почему:
1. В продуктовой компании разработчики вольно-невольно начинают разбираться в предметной области. Поэтому вы общаетесь в одном контексте.
2. ТЗ ж не энциклопедия, поэтому я бы внутри ТЗ не объяснял, что значит параметр Х. Максимум можно оставить ссылку на тематическую статью (для самых любопытных). А так я бы просто написал формулу как посчитать Х и показал в дизайне куда этот Х выводить.
Если разработчику нужно понимать ряд терминов, чтобы работать — лучше вынести эти термины в отдельную базу знаний, а не прописывать в каждом ТЗ.
В основном я работал с GameDev и EdTech проектами. Безусловно, тут меньше порог входа, чем в FinTech и MedTech.
Но с точки зрения постановки задач — не думаю, что возникла бы проблема. И вот почему:
1. В продуктовой компании разработчики вольно-невольно начинают разбираться в предметной области. Поэтому вы общаетесь в одном контексте.
2. ТЗ ж не энциклопедия, поэтому я бы внутри ТЗ не объяснял, что значит параметр Х. Максимум можно оставить ссылку на тематическую статью (для самых любопытных). А так я бы просто написал формулу как посчитать Х и показал в дизайне куда этот Х выводить.
Если разработчику нужно понимать ряд терминов, чтобы работать — лучше вынести эти термины в отдельную базу знаний, а не прописывать в каждом ТЗ.
Автор, за статью большое спасибо :) Обсудили среди команды, будем «покурить» что можно изменить в своем процессе.
Подскажите, а можно посмотреть на боевые обезличенные ТЗ, чтобы уж совсем проникнуться?
Подскажите, а можно посмотреть на боевые обезличенные ТЗ, чтобы уж совсем проникнуться?
Как фиксируется Scope и стоимость?
Думаю, история про фиксацию сроков-объема-стоимости — больше про аутсорс.
В большинстве продуктовых компаний, полагаю, это проще организовано.
У нас это происходит так:
Получается, срок спринта фиксирован, стоимость вообще не обсуждаем с командой разработки, а объем согласовываем с PM.
В большинстве продуктовых компаний, полагаю, это проще организовано.
У нас это происходит так:
- Я перед спринтом говорю PM-у — давай возьмем в спринт вот эти крупные ТЗ и вот эту дюжину мелких задач.
- PM компонует спринт, берет мои задачи + теходолг + баги.
- Разработчики эстимируют все задачи будущего спринта.
- В итоге, если получился перегруз — садимся вместе с PM и думаем что выкинуть.
Получается, срок спринта фиксирован, стоимость вообще не обсуждаем с командой разработки, а объем согласовываем с PM.
Кто-то может вообще обойтись без документации. Но если вам документация все же нужна – наймите джуна, который будет детально описывать функционал уже после его реализации.
Вообще-то под это дело даже отдельная профессия есть, технический писатель и даже со своим профстандартом :)
Полностью согласен со вторым лайфхаком. Но также `джиннами` становятся, после того как неграмотный пм делает из разраба отладчик, подсовывая откровенный бред — ожидая что он то всё поправит или даже полностью переделает попутно объясняя как всё работает (ну а кто нанимался доучивать начальство?). Так что если кому-то кругом например часто встречаются `джинны` следует подумать и о себе.
Да, тоже соглашусь.
Джиннами становятся не от хорошей жизни.
Если продакт хочет, чтобы его задачи делались хорошо — нужно и самому позаботиться о разработчике, который будет их делать. Как минимум нормально эти задачи оформить.
И еще, думаю, если идти работать в продуктовую компанию — важно выбирать ее не только по условиям труда, но и чтобы сам продукт нравился. Чтобы он реально людям помогал, чтобы не стыдно было сказать «это я сделал», а в идеале — и самому хотелось им пользоваться.
При таких условиях, полагаю, безразличного отношения не будет :)
Джиннами становятся не от хорошей жизни.
Если продакт хочет, чтобы его задачи делались хорошо — нужно и самому позаботиться о разработчике, который будет их делать. Как минимум нормально эти задачи оформить.
И еще, думаю, если идти работать в продуктовую компанию — важно выбирать ее не только по условиям труда, но и чтобы сам продукт нравился. Чтобы он реально людям помогал, чтобы не стыдно было сказать «это я сделал», а в идеале — и самому хотелось им пользоваться.
При таких условиях, полагаю, безразличного отношения не будет :)
Какое-то у вас странное понимание user story. Story должна давать какую-то предысторию, понимание, зачем это вообще понадобилось (оно же story, не?), а не вот это вот «Дверь мне запили». Хорошо, если просто есть пустой проём от строителей и купленная дверь. Да и ту можно повесить на левую сторону и на правую. А если это 16-й этаж и наружная стена в 60см? А так и бывает. Делаешь дверь, потом оказывается, что людям было душно. Задаёшь вопрос «а почему не бризер или хотя бы окно?» и в ответ получаешь: «ну у нас же везде в старом офисе двери были, всё хорошо работало».
Ну к классическим user story мой формат относится довольно опосредованно :)
Потому и написал, что это вольная смесь. По сути от классики здесь только емкие формулировки о том, что нужно сделать.
Понятно, пример про дверь выбран упрощенный — но чаще всего настоящие стори у меня не намного сложнее. А все детали вроде толщины стен зафиксированы на уровне гайдлайнов. Ну и я бы не пропагандировал такой формат, если бы он приводил к неправильной реализации. В том-то и кайф, что такое простое описание дает высокую точность реализации.
Впрочем, бывают стори, где действительно нужно указать на нюансы, в таком случае само название стори остается таким же простым, но вот в столбце Result может быть довольно подробный список.
И еще, что хочу подчеркнуть по поводу такого формата: не важно, что было на месте этой двери раньше — хоть избушка на курьих ножках. Если в definition of done написано, что теперь там должна быть дверь — то задача будет выполнена только тогда, когда там будет именно дверь и именно такая как в дизайне. А если мне нужно что-то оставить от избушки — то я просто добавлю пункт про миграцию в описание.
Ну и это мы сейчас говорим об описании задачи. А что реально нужно заказчикам — это нужно выяснить до того как отдавать задачу в разработку, конечно. Т.е. я предполагаю, что продакт уже провел хороший кастдев. Тогда он не просто делает то, о чем просит пользователь, а то, что реально закроет проблему наилучшим образом.
Потому и написал, что это вольная смесь. По сути от классики здесь только емкие формулировки о том, что нужно сделать.
Понятно, пример про дверь выбран упрощенный — но чаще всего настоящие стори у меня не намного сложнее. А все детали вроде толщины стен зафиксированы на уровне гайдлайнов. Ну и я бы не пропагандировал такой формат, если бы он приводил к неправильной реализации. В том-то и кайф, что такое простое описание дает высокую точность реализации.
Впрочем, бывают стори, где действительно нужно указать на нюансы, в таком случае само название стори остается таким же простым, но вот в столбце Result может быть довольно подробный список.
И еще, что хочу подчеркнуть по поводу такого формата: не важно, что было на месте этой двери раньше — хоть избушка на курьих ножках. Если в definition of done написано, что теперь там должна быть дверь — то задача будет выполнена только тогда, когда там будет именно дверь и именно такая как в дизайне. А если мне нужно что-то оставить от избушки — то я просто добавлю пункт про миграцию в описание.
Ну и это мы сейчас говорим об описании задачи. А что реально нужно заказчикам — это нужно выяснить до того как отдавать задачу в разработку, конечно. Т.е. я предполагаю, что продакт уже провел хороший кастдев. Тогда он не просто делает то, о чем просит пользователь, а то, что реально закроет проблему наилучшим образом.
Если я правильно поняла, то собственно сам процесс (история как таковая), тут стоит над user story, а в user story, которые отдаются разработчикам, отражен конкретный шаг: 1) поступил документ — выполни проверку, 2) выполнил проверку — выбрал маршрут движения, 3) выбрал маршрут — отдал документ дальше.
А что касаемо предыстории — тут, пожалуй, мы все вольно или нет приходим к привлечению разработчиков к этапу аналитики, когда показываешь проработанный процесс, приходишь с ними к общему пониманию того, что должно быть сделано, дробишь на шаги (user story) таким образом, чтобы именно им было удобно, и уже потом отдаешь в работу. По крайней мере у нас в команде происходит нечто подобное, поэтому в какой-то степени начали подсаживаться на DDD.
А что касаемо предыстории — тут, пожалуй, мы все вольно или нет приходим к привлечению разработчиков к этапу аналитики, когда показываешь проработанный процесс, приходишь с ними к общему пониманию того, что должно быть сделано, дробишь на шаги (user story) таким образом, чтобы именно им было удобно, и уже потом отдаешь в работу. По крайней мере у нас в команде происходит нечто подобное, поэтому в какой-то степени начали подсаживаться на DDD.
Ну я стараюсь разработчиков лишний раз не дергать — т.к. они погружены в текущий спринт, пока я готовлю ТЗ в следующий.
А чтобы хорошо проработать задачу, я чаще хожу «в поля»: интервью с пользователями, копание в аналитике, опрос стейкхолдеров, ресерч по конкурентам и т.п.
Наверное, за консультацией к разработчикам обращаюсь всего в двух случаях:
А чтобы хорошо проработать задачу, я чаще хожу «в поля»: интервью с пользователями, копание в аналитике, опрос стейкхолдеров, ресерч по конкурентам и т.п.
Наверное, за консультацией к разработчикам обращаюсь всего в двух случаях:
- Когда не знаю, можно ли в принципе реализовать какой-то функционал в разумные сроки
- Когда есть несколько вариантов технической реализации, которые влияют на продуктовую логику — и нужно выбрать как будет проще сделать
ТЗ по ГОСТу имеет смысл?
Возможно меня поправят ребята из аутсорса, но, насколько я понимаю: ТЗ по ГОСТу нужно скорее юристам, чем разработчикам. Причем только в том случае, когда заказчик и исполнитель работают в разных компаниях.
Меня конечно шокирует, насколько можно усложнить написание ТЗ благодаря ГОСТу. Но, возможно, это оправдано, когда речь идет об автоматизации процессов на крупном государственном производстве и за нестыковку в ТЗ можно присесть по какой-нибудь веселой статье.
В любом случае, в продуктовой компании, где разработчики сидят в двух шагах от продакта — никакие ГОСТы не нужны. Более того, тот формат ТЗ, который я предлагаю в своей статье — можно назвать антиГОСТом, т.к. из него максимально вычищены все формальности, чтобы оставить только суть.
Меня конечно шокирует, насколько можно усложнить написание ТЗ благодаря ГОСТу. Но, возможно, это оправдано, когда речь идет об автоматизации процессов на крупном государственном производстве и за нестыковку в ТЗ можно присесть по какой-нибудь веселой статье.
В любом случае, в продуктовой компании, где разработчики сидят в двух шагах от продакта — никакие ГОСТы не нужны. Более того, тот формат ТЗ, который я предлагаю в своей статье — можно назвать антиГОСТом, т.к. из него максимально вычищены все формальности, чтобы оставить только суть.
Использую uml usecase diagram для наглядности всех сценариев. Дальше также итеративно их прорабатываю и отдаю в разработку. Пример:
Sign up to leave a comment.
Ты можешь писать безупречные ТЗ, но какой в этом толк, если разработчик твой плачет?