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

product manager

Отправить сообщение
Да, почти никто не выживает. Причем это обычно статистику приводят за первый год, а там дальше еще хуже. Поэтому и уточнил:
… профессионализм в успешных IT-стартапах...


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

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

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

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

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

В любом случае, в продуктовой компании, где разработчики сидят в двух шагах от продакта — никакие ГОСТы не нужны. Более того, тот формат ТЗ, который я предлагаю в своей статье — можно назвать антиГОСТом, т.к. из него максимально вычищены все формальности, чтобы оставить только суть.
Ну к классическим user story мой формат относится довольно опосредованно :)
Потому и написал, что это вольная смесь. По сути от классики здесь только емкие формулировки о том, что нужно сделать.

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

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

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

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

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

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

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

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

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

Получается, срок спринта фиксирован, стоимость вообще не обсуждаем с командой разработки, а объем согласовываем с PM.
Ох, хотел бы похвастаться, но все реальные ТЗ под NDA, к сожалению.
А если весь текст размыть, то это ж голая табличка будет.

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

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

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

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

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

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

Вот как-то так, в моем представлении, PM влияет на команду и культуру разработки.
Думаю, у каждого продакта есть свои преимущества, смотря откуда он пришел:
  • бывшие дизайнеры лучше проектируют путь пользователя
  • бывшие разработчики лучше понимают ограничения и формулируют задачи
  • бывшие тестировщики хорошо видят негативные кейсы
  • и так далее

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

А с формальными методиками дела не имел. Насколько я понимаю, они нужны в областях вроде MedTech, где ошибки слишком дорого стоят.
Если говорить о небольших ТЗ, то их обычно берут целиком в спринт. Поэтому там нет смысла как-то приоритизировать задачи внутри.

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

Информация

В рейтинге
Не участвует
Откуда
Аргентина
Зарегистрирован
Активность