Нужны ли вам спринты фиксированной длины?
Если кратко, то:
1. Да, спринты фиксированной длины очень сильно помогают, когда команда только начинает, она еще не сработана, и вы не знаете реальной velovcity этой команды на этом проекте. Эта задает ритмичность и столь необходимые искусственные ограничения.
2. Спринты дают комфортное чувство дедлайна 😉 - можно сосредоточиться на понятном скоупе работ, и выбросить на две недели из головы часть мыслей о приоритезации и следующих задачах. “Комфортное” - потому что дедлайн для решений не каждый день, а раз в спринт.
3. Обратная сторона: это ведет к неизбежным подтасовкам: мы либо берем слишком маленькую цель (ведь задача спринта - сделать явный инкремент в продукте), либо придумываем цель под те таски, которые поместились в спринт после оценки команды.
4. Последний вариант, к сожалению, самый частый. У этого много причин:
* РО не успевает или не может придумать явную цель с понятным инкрементом
* продукт имеет большое количество пользователей (особенно это касается В2В энтерпрайз) и есть много мест, которые нужно пофиксить “на вчера”
* спринты сложены из багов или техдолга, а не исходят из цели.
5. Основная проблема со спринтами: мы опасаемся брать большие значимые цели, которые сделают многих счастливыми, потому что они ТОЧНО не помещаются в спринт. Что делать в таком случае:
* Для этого существуют эпики. Эпик может длиться более одного спринта (в отличие от истории).
* Эпики все равно нужно бить на части, и эти части должны быть более-менее независимыми друг от друга в части функционала (это сложная тема, которую в комментарии не раскрыть, но это возможно).
* Попробовать (это челлендж лично для меня, с учетом энтерпайз продукта, в который коммитят 20+ скрам-команд) добиться выпуска shippable инкремента КАЖДЫЙ СПРИНТ. Покрытого юнит и интеграционными тестами, с зелеными тест-планами, сданного по Definition of Done, принятых в вашей компании. По этому пункту я планирую написать больше в ближайшее время.
Красивый пост с картинками, который меня вдохновил (очень рекомендую): https://hackernoon.com/fixed-length-iterations-vs-continuous-flow-afd0d32ab50
P.S. Идея отказаться от спринтов ради более гармоничной работы вокруг целей разного объема (не подпиливать их под 14 дней) мне пока кажется нецелесообразным. Пока более разумной выглядит мысль брать задачи объемом меньше спринта, которые могут быть явно отданы в релиз, а оставшееся время просто начинать делать следующие задачи из топа бэклога. При этом успешность спринта оценивать только по основной цели, а не дополнительным задачам.
Если кратко, то:
1. Да, спринты фиксированной длины очень сильно помогают, когда команда только начинает, она еще не сработана, и вы не знаете реальной velovcity этой команды на этом проекте. Эта задает ритмичность и столь необходимые искусственные ограничения.
2. Спринты дают комфортное чувство дедлайна 😉 - можно сосредоточиться на понятном скоупе работ, и выбросить на две недели из головы часть мыслей о приоритезации и следующих задачах. “Комфортное” - потому что дедлайн для решений не каждый день, а раз в спринт.
3. Обратная сторона: это ведет к неизбежным подтасовкам: мы либо берем слишком маленькую цель (ведь задача спринта - сделать явный инкремент в продукте), либо придумываем цель под те таски, которые поместились в спринт после оценки команды.
4. Последний вариант, к сожалению, самый частый. У этого много причин:
* РО не успевает или не может придумать явную цель с понятным инкрементом
* продукт имеет большое количество пользователей (особенно это касается В2В энтерпрайз) и есть много мест, которые нужно пофиксить “на вчера”
* спринты сложены из багов или техдолга, а не исходят из цели.
5. Основная проблема со спринтами: мы опасаемся брать большие значимые цели, которые сделают многих счастливыми, потому что они ТОЧНО не помещаются в спринт. Что делать в таком случае:
* Для этого существуют эпики. Эпик может длиться более одного спринта (в отличие от истории).
* Эпики все равно нужно бить на части, и эти части должны быть более-менее независимыми друг от друга в части функционала (это сложная тема, которую в комментарии не раскрыть, но это возможно).
* Попробовать (это челлендж лично для меня, с учетом энтерпайз продукта, в который коммитят 20+ скрам-команд) добиться выпуска shippable инкремента КАЖДЫЙ СПРИНТ. Покрытого юнит и интеграционными тестами, с зелеными тест-планами, сданного по Definition of Done, принятых в вашей компании. По этому пункту я планирую написать больше в ближайшее время.
Красивый пост с картинками, который меня вдохновил (очень рекомендую): https://hackernoon.com/fixed-length-iterations-vs-continuous-flow-afd0d32ab50
P.S. Идея отказаться от спринтов ради более гармоничной работы вокруг целей разного объема (не подпиливать их под 14 дней) мне пока кажется нецелесообразным. Пока более разумной выглядит мысль брать задачи объемом меньше спринта, которые могут быть явно отданы в релиз, а оставшееся время просто начинать делать следующие задачи из топа бэклога. При этом успешность спринта оценивать только по основной цели, а не дополнительным задачам.
Hacker Noon
Fixed Length Iterations vs. Continuous Flow
Your team is mulling over two approaches to goal setting:
Если вы пропустили полезную ссылку в посте из последнего сообщения, - вот полезная мысль на тему “инкремент каждый спринт”:
ЦЕЛЬ СПРИНТА - это смысл в наборе задач, которые помещены в спринт. Цель оправдывает этот набор задач и делает его гармоничным. Благодаря цели, этот набор задач приведет к инкременту который заслуживает релиза как отдельный артефакт, при этом несет ясную ценность, выходящую за рамки просто написанного кода. Иными словами, именно цель спринта делает спринт и его результат большим, чем просто набор задач в спринте. … Без целей теряется смысл использования скрама.
Мысль кажется банальной только тем, кто не пробовал внедрять скрам и добиваться ритмичной прогнозируемой работы большого количества команд в течение продолжительного периода времени 😭🤦♂️
Оригинал:
https://dzone.com/articles/sprint-goals-in-practice
ЦЕЛЬ СПРИНТА - это смысл в наборе задач, которые помещены в спринт. Цель оправдывает этот набор задач и делает его гармоничным. Благодаря цели, этот набор задач приведет к инкременту который заслуживает релиза как отдельный артефакт, при этом несет ясную ценность, выходящую за рамки просто написанного кода. Иными словами, именно цель спринта делает спринт и его результат большим, чем просто набор задач в спринте. … Без целей теряется смысл использования скрама.
Мысль кажется банальной только тем, кто не пробовал внедрять скрам и добиваться ритмичной прогнозируемой работы большого количества команд в течение продолжительного периода времени 😭🤦♂️
Оригинал:
https://dzone.com/articles/sprint-goals-in-practice
DZone
Sprint Goals in Practice
"Onward! onward! must we travel? When will come the goal? Riddle I may not unravel, Cease to vex my soul."
Ной Вайс, бывший вице-президент по продукту Foursqare и нынешний продакт хэд в Slack, делится своим простым подходом к роадмаппингу и приоритезации бэклога.
Исходя их его опыта, для очень быстро растущих компаний (исповедующих lean startup подход), классические подходы, включая OKR, слишком тяжеловесны: оверхэды на метрики отнимают много времени, квартальный цикл коррекции слишком крупный для их темпов.
Вместо этого они делят фичи на три блока: #now, #next, #later
Далее:
1. Все равно стоит согласовать несколько ключевых целей на уровне компании/продукта.
2. Собрать фичи/идеи из всех мест, где они у вас накапливаются 😉
3. Разложить на категории:
a. #now - 1 месяц (1-2 спринта)
b. #next - 3 месяца (сразу после #now)
c. #later - когда-то)
4. Далее у автора идет мысль о том, как удобно управлять проектами в Асане, с чем я согласиться не могу в контексте софтверной разработки :), но для синхронизации на уровне верхнеуровневой истории, с привязкой тикетов и идей, при достаточной дисциплинированности, и только между РО/ВА, чтоб не загружать разработчиков сырыми идеями - может быть.
https://medium.com/@noah_weiss/now-next-later-roadmaps-without-the-drudgery-1cfe65656645
Больше о целях компании на примере OKR: https://news.1rj.ru/str/productdev/19
Исходя их его опыта, для очень быстро растущих компаний (исповедующих lean startup подход), классические подходы, включая OKR, слишком тяжеловесны: оверхэды на метрики отнимают много времени, квартальный цикл коррекции слишком крупный для их темпов.
Вместо этого они делят фичи на три блока: #now, #next, #later
Далее:
1. Все равно стоит согласовать несколько ключевых целей на уровне компании/продукта.
2. Собрать фичи/идеи из всех мест, где они у вас накапливаются 😉
3. Разложить на категории:
a. #now - 1 месяц (1-2 спринта)
b. #next - 3 месяца (сразу после #now)
c. #later - когда-то)
4. Далее у автора идет мысль о том, как удобно управлять проектами в Асане, с чем я согласиться не могу в контексте софтверной разработки :), но для синхронизации на уровне верхнеуровневой истории, с привязкой тикетов и идей, при достаточной дисциплинированности, и только между РО/ВА, чтоб не загружать разработчиков сырыми идеями - может быть.
https://medium.com/@noah_weiss/now-next-later-roadmaps-without-the-drudgery-1cfe65656645
Больше о целях компании на примере OKR: https://news.1rj.ru/str/productdev/19
Medium
#now, #next, #later: Roadmaps without the Drudgery
A deceptively simple process for prioritizing projects that won’t cause a revolt.
It’s a fine line between acknowledging there are issues but without taking too much of the blame.
Это должно быть мантрой каждого продакт овнера, мне кажется)
Сказано об Адаме Моссери, VP of Product Facebook, который отвечает в том числе за Newsfeed - сердце и основу интерфейса Facebook.
Отличная история об отличном парне, на родном языке:
https://digiday.com/media/hes-not-pr-guy-adam-mosseri-facebooks-head-news-feed-become-unlikely-good-guy-publishers/
Это должно быть мантрой каждого продакт овнера, мне кажется)
Сказано об Адаме Моссери, VP of Product Facebook, который отвечает в том числе за Newsfeed - сердце и основу интерфейса Facebook.
Отличная история об отличном парне, на родном языке:
https://digiday.com/media/hes-not-pr-guy-adam-mosseri-facebooks-head-news-feed-become-unlikely-good-guy-publishers/
Digiday
‘He’s not a PR guy’: Adam Mosseri, Facebook’s head of news feed, has become an unlikely good guy to publishers
Publishers that find themselves at the end of their rope with Facebook have found one person they don't hate: Adam Mosseri, its head of news feed.
Недавно я писал о простом способе определения приоритетов в роадмапе/бэклоге продукта - раскладывание по трем категориям #now, #next, #later (https://news.1rj.ru/str/productdev/34).
Еще один перпендикулярный (в буквальном смысле) взгляд - это категоризация по трем типам фич:
1. Влияющие на метрики. В здоровых организациях есть большие цели, и можно соотносить метрики с ними). Это то, что драйвит использование продукта, достижение финансовых целей, снижение оттока и т.д. На самом деле очень небольшое количество фич действительно серьезно влияют на метрики. Эти фичи нужно знать, понимать, сколько они требуют инвестиций и быть готовыми воплощать их, несмотря ни на что.
2. Основанные на фидбеке пользователей. Customer voice - наше все. У вас может быть 100500 тикетов или комментариев на аппсторе. Обещания самым крупных энтерпрайз-клиентам. Хотелки. Вещи, которые реально упрощают жизнь, но без которых тоже можно существовать. Не все эти фичи нужно всегда воплощать, но профессиональный РО всегда старается получать ПРЯМУЮ обратную связь от пользователей (избегайте агрегированных субъективных идей сейлз-менеджеров, саппорта, партнеров или CSM). Читайте тикеты, организовывайте конференц-звонки, слушайте клиентов/пользователей.
3. Основанные на вашем видении. Здесь могут быть вещи, которые приятно удивят ваших пользователей, например улучшения UX или скорости работы. Обычно для появления этих фич требуется несколько ингредиентов: внимательно слушать пользователей для выявления их настоящих проблем (но не их варианты решения проблем, которые могут быть не универсальными!), понимание возможностей технологии, продуманный UXи упаковка фичи, ее встраивание в существующий опыт/продукт.
Безусловно, некоторые фичи попадают в несколько категорий, но редко во все три.
Основная идея состоит в том, что:
1. Вы с командой четко отдаете себе отчет, к какой категории относится то, над чем вы работаете - какова цель (ответ на вопрос WHY)
2. Вы стараетесь включать в мажорные релизы понемногу из каждой категории - МЕТРИКИ: улучшения для бизнеса/стейкхолдеров; ФИДБЕК: демонстрируете, что слышите пользователей; ВИДЕНИЕ: удивляете и показываете, что продует/компания является экспертом и может производить инновации.
И наоборот, если ваш анализ покажет, что одна из категорий отсутствует в вашем роадмапе и планах на релизы - очевидно, у вас есть проблема, и ее нужно исправлять.
Еще один перпендикулярный (в буквальном смысле) взгляд - это категоризация по трем типам фич:
1. Влияющие на метрики. В здоровых организациях есть большие цели, и можно соотносить метрики с ними). Это то, что драйвит использование продукта, достижение финансовых целей, снижение оттока и т.д. На самом деле очень небольшое количество фич действительно серьезно влияют на метрики. Эти фичи нужно знать, понимать, сколько они требуют инвестиций и быть готовыми воплощать их, несмотря ни на что.
2. Основанные на фидбеке пользователей. Customer voice - наше все. У вас может быть 100500 тикетов или комментариев на аппсторе. Обещания самым крупных энтерпрайз-клиентам. Хотелки. Вещи, которые реально упрощают жизнь, но без которых тоже можно существовать. Не все эти фичи нужно всегда воплощать, но профессиональный РО всегда старается получать ПРЯМУЮ обратную связь от пользователей (избегайте агрегированных субъективных идей сейлз-менеджеров, саппорта, партнеров или CSM). Читайте тикеты, организовывайте конференц-звонки, слушайте клиентов/пользователей.
3. Основанные на вашем видении. Здесь могут быть вещи, которые приятно удивят ваших пользователей, например улучшения UX или скорости работы. Обычно для появления этих фич требуется несколько ингредиентов: внимательно слушать пользователей для выявления их настоящих проблем (но не их варианты решения проблем, которые могут быть не универсальными!), понимание возможностей технологии, продуманный UXи упаковка фичи, ее встраивание в существующий опыт/продукт.
Безусловно, некоторые фичи попадают в несколько категорий, но редко во все три.
Основная идея состоит в том, что:
1. Вы с командой четко отдаете себе отчет, к какой категории относится то, над чем вы работаете - какова цель (ответ на вопрос WHY)
2. Вы стараетесь включать в мажорные релизы понемногу из каждой категории - МЕТРИКИ: улучшения для бизнеса/стейкхолдеров; ФИДБЕК: демонстрируете, что слышите пользователей; ВИДЕНИЕ: удивляете и показываете, что продует/компания является экспертом и может производить инновации.
И наоборот, если ваш анализ покажет, что одна из категорий отсутствует в вашем роадмапе и планах на релизы - очевидно, у вас есть проблема, и ее нужно исправлять.
Telegram
Product Development and Management 🏋️♀️
Ной Вайс, бывший вице-президент по продукту Foursqare и нынешний продакт хэд в Slack, делится своим простым подходом к роадмаппингу и приоритезации бэклога.
Исходя их его опыта, для очень быстро растущих компаний (исповедующих lean startup подход), классические…
Исходя их его опыта, для очень быстро растущих компаний (исповедующих lean startup подход), классические…
Как расставляет квартальные приоритеты в разработке Pandora
Продолжаем нашу серию о том, как расставлять приоритеты в краткой и среднесрочной перспективе. Тема, вне всякого сомнения, сложная и этого заслуживает. При этом, естественно, самые рабочие варианты - самые простые.
Сегодня - о системе выбора приоритетов, которая работает даже для стартапов на ранней стадии, где вообще часто очень мало ориентиров и не на что опереться. Систему придумал и внедрил СТО Pandora (сервис стриминга музыки а-ля Spotify). Оригинал для любителей лонгридов: https://goo.gl/b9v9Ga
Вкратце, вот сама система:
1. В начале каждого квартала задайте себе вопрос: Что было бы крайне тупо в нашем положении не сделать в следующие 90 дней? (формулировка важна, она отсекает большую часть nice to have фич, хотя они все равно просочатся).
2. Вопрос себе могу задавать все сотрудники компании - все идеи приветствуются, у каждого может быть свой инсайт.
3. Опишите каждую идею в нескольких пунктах на одном слайде (не более слайда на идею). Каждый может описывать свои идеи.
4. Оцените приблизительно объем работы разработчиков для воплощения каждой из идей.
5. Пандора оценивает этот объем в долларах: $5 - это объем, который требует одного сферического разработчика в вакууме в течении месяца. Соответственно, три месяца одного человека = $15
6. Если у вас 10 разработчиков, у вас всего $150 долларов, которыми вы можете распоряжаться.
7. (Подсказка: вы можете оценивать в командо-спринтах, если ваш R&D крупный - например у нас сейчас 20+ серам-команд, и оценивать на уровне одного разработчика будет затратно. С другой стороны, если вы планируете на уровне команд, а не всей компании, размер в разработчиков-месяцах все еще подходит вам).
8. Итак, на каждом слайд с идеей у вас должна быть стоимость в долларах.
9. Выберите маленькую команду, которая будет заниматься планированием. Идеально, если это ключевые люди в компании (например, фаундеры, продакт-менеджеры, деливери, директора CSM и т.д.). Берите людей, которые точно заинтересованы в успехе компании/продукта, не просто классных сотрудников (они могут трудиться ради ЗП). Демократия здесь излишня.
10. К примеру, если у вас 5 людей в этом «комитете» ;), и объем доступных разработчиков $150 - выдайте каждому по 6 стикеров стоимостью $5 каждый.
11. Распечатайте слайды и повесьте их на стену. Кратко (минута максимум) презентуйте команде каждую из идей.
12. После этого каждый из «комитета» с помощью своих стикеров «покупает» те фичи, которые особенно ценны для бизнеса на их взгляд.
13. Как вы понимаете, это приводит к очень жесткой расстановке приоритетов.
14. После первого круга вы можете торговаться и договариваться между собой, перемещать стикеры, так чтоб в итоге у вас был полный список фич, которые вы можете и хотите купить в этом квартале.
15. Кроме пользы в приоритетах, этот метод обеспечивает buy-in, то есть каждый психологически включается в то, чтоб этих целей достичь.
16. Получив ограниченный, достижимый объем функциональнсти в разработку, можно переходить к детализации историй, критериев приемки, UX и прототипам и т.д., в обычном вашем режиме работы.
Через 90 дней повторить все с ноля, заново, не опираясь на идеи, ранее сгенерированные в предыдущем цикле.
Продолжаем нашу серию о том, как расставлять приоритеты в краткой и среднесрочной перспективе. Тема, вне всякого сомнения, сложная и этого заслуживает. При этом, естественно, самые рабочие варианты - самые простые.
Сегодня - о системе выбора приоритетов, которая работает даже для стартапов на ранней стадии, где вообще часто очень мало ориентиров и не на что опереться. Систему придумал и внедрил СТО Pandora (сервис стриминга музыки а-ля Spotify). Оригинал для любителей лонгридов: https://goo.gl/b9v9Ga
Вкратце, вот сама система:
1. В начале каждого квартала задайте себе вопрос: Что было бы крайне тупо в нашем положении не сделать в следующие 90 дней? (формулировка важна, она отсекает большую часть nice to have фич, хотя они все равно просочатся).
2. Вопрос себе могу задавать все сотрудники компании - все идеи приветствуются, у каждого может быть свой инсайт.
3. Опишите каждую идею в нескольких пунктах на одном слайде (не более слайда на идею). Каждый может описывать свои идеи.
4. Оцените приблизительно объем работы разработчиков для воплощения каждой из идей.
5. Пандора оценивает этот объем в долларах: $5 - это объем, который требует одного сферического разработчика в вакууме в течении месяца. Соответственно, три месяца одного человека = $15
6. Если у вас 10 разработчиков, у вас всего $150 долларов, которыми вы можете распоряжаться.
7. (Подсказка: вы можете оценивать в командо-спринтах, если ваш R&D крупный - например у нас сейчас 20+ серам-команд, и оценивать на уровне одного разработчика будет затратно. С другой стороны, если вы планируете на уровне команд, а не всей компании, размер в разработчиков-месяцах все еще подходит вам).
8. Итак, на каждом слайд с идеей у вас должна быть стоимость в долларах.
9. Выберите маленькую команду, которая будет заниматься планированием. Идеально, если это ключевые люди в компании (например, фаундеры, продакт-менеджеры, деливери, директора CSM и т.д.). Берите людей, которые точно заинтересованы в успехе компании/продукта, не просто классных сотрудников (они могут трудиться ради ЗП). Демократия здесь излишня.
10. К примеру, если у вас 5 людей в этом «комитете» ;), и объем доступных разработчиков $150 - выдайте каждому по 6 стикеров стоимостью $5 каждый.
11. Распечатайте слайды и повесьте их на стену. Кратко (минута максимум) презентуйте команде каждую из идей.
12. После этого каждый из «комитета» с помощью своих стикеров «покупает» те фичи, которые особенно ценны для бизнеса на их взгляд.
13. Как вы понимаете, это приводит к очень жесткой расстановке приоритетов.
14. После первого круга вы можете торговаться и договариваться между собой, перемещать стикеры, так чтоб в итоге у вас был полный список фич, которые вы можете и хотите купить в этом квартале.
15. Кроме пользы в приоритетах, этот метод обеспечивает buy-in, то есть каждый психологически включается в то, чтоб этих целей достичь.
16. Получив ограниченный, достижимый объем функциональнсти в разработку, можно переходить к детализации историй, критериев приемки, UX и прототипам и т.д., в обычном вашем режиме работы.
Через 90 дней повторить все с ноля, заново, не опираясь на идеи, ранее сгенерированные в предыдущем цикле.
Firstround
This Product Prioritization System Nabbed Pandora 70 Million Monthly Users with Just 40 Engineers
Pandora CTO Tom Conrad explains how Pandora picks the most important features to build with its limited engineering power.
Отличное обсуждение на ту же тему приоритетов на Quora:
https://www.quora.com/Product-Management/What-are-the-best-ways-to-prioritize-a-list-of-product-features
https://www.quora.com/Product-Management/What-are-the-best-ways-to-prioritize-a-list-of-product-features
[прочесть за обедом] Что такое Product Owner и с чем его есть - в одной статье: https://productcoalition.com/product-owner-theses-2de0c60310f1
ProductCoalition.com
The Scrum Product Owner Theses
From Product Discovery to Product Delivery
И о полезном.
Наша наивная идея (и эти грешат многие материалы и тренинги по разработке продукта) состоит в том, что бэклог - это набор user stories для новых фич.
Но жестокая действительность разбивает наши мечты, приходя в виде тикетов от саппорта, технического долга вследствие срезания углов («надо успеть к релизу»), и ультиматумов (обоснованных!) от команды о необходимости выделять время для проработки архитектуры («ребята, ну сколько можно говорить и рисовать, давайте писать код!»).
Один из подходов, о которых я еще не писал - это матрица для форматирования бэклога на основе двух осей:
Прошлое - Будущее
Бизнес - Разработка
Основная идея состоит в том, чтоб зарезервировать % времени под каждый блок работы, и перестать мучаться в сомнениях при планировании каждого спринта.
В зависимости от специфики и зрелости вашего продукта, это соотношение будет разным. Очевидно, максимум внимания хочется уделять новым фичам. Я бы сказал, в моем случае (В2В энтерпрайз софт, с которым работают крупные глобальных корпорации, и есть определенные платформенные зависимости, 20+ скрам-команд, которые координируют свои усилия) это выглядит так:
Новый функционал - 60%
Техдолг - 10%
Проработка архитектуры - 10%
Саппорт - 20%
(один из разработчиков в каждой команде резервируется под сложные кейсы и срочную помощь энтерпрайз-кастомерам, изменения вносятся сразу также в коробку и выходят в следующем релизе для всех)
В итоге, приходится признать, что если ваш продукт довольно зрел, то на собственно развитие вы будете тратить не более 60-70% - и это еще очень хорошие цифры 😉
P.S> Это ок, если ситуативно цифры прыгают: например, одна из моих команд сейчас будет перевозить целый пул сервисов на новый фреймворк, и в краткой перспективе это выглядит как пробуксовка с точки зрения клиентов, но в итоге это ускорит работу критически важных компонентов архитектуры, добавит отказоустойчивости - в итоге снизит количество саппорт-тикетов и освободит время команды на разработку новой функциональности.
Наша наивная идея (и эти грешат многие материалы и тренинги по разработке продукта) состоит в том, что бэклог - это набор user stories для новых фич.
Но жестокая действительность разбивает наши мечты, приходя в виде тикетов от саппорта, технического долга вследствие срезания углов («надо успеть к релизу»), и ультиматумов (обоснованных!) от команды о необходимости выделять время для проработки архитектуры («ребята, ну сколько можно говорить и рисовать, давайте писать код!»).
Один из подходов, о которых я еще не писал - это матрица для форматирования бэклога на основе двух осей:
Прошлое - Будущее
Бизнес - Разработка
Основная идея состоит в том, чтоб зарезервировать % времени под каждый блок работы, и перестать мучаться в сомнениях при планировании каждого спринта.
В зависимости от специфики и зрелости вашего продукта, это соотношение будет разным. Очевидно, максимум внимания хочется уделять новым фичам. Я бы сказал, в моем случае (В2В энтерпрайз софт, с которым работают крупные глобальных корпорации, и есть определенные платформенные зависимости, 20+ скрам-команд, которые координируют свои усилия) это выглядит так:
Новый функционал - 60%
Техдолг - 10%
Проработка архитектуры - 10%
Саппорт - 20%
(один из разработчиков в каждой команде резервируется под сложные кейсы и срочную помощь энтерпрайз-кастомерам, изменения вносятся сразу также в коробку и выходят в следующем релизе для всех)
В итоге, приходится признать, что если ваш продукт довольно зрел, то на собственно развитие вы будете тратить не более 60-70% - и это еще очень хорошие цифры 😉
P.S> Это ок, если ситуативно цифры прыгают: например, одна из моих команд сейчас будет перевозить целый пул сервисов на новый фреймворк, и в краткой перспективе это выглядит как пробуксовка с точки зрения клиентов, но в итоге это ускорит работу критически важных компонентов архитектуры, добавит отказоустойчивости - в итоге снизит количество саппорт-тикетов и освободит время команды на разработку новой функциональности.
Очень хорошая подборка советов начинающим продакт-менеджерам и фаундерам стартапов (очень сжато, и на самом деле подойдет менеджерам в любых областях, не только в разработке софта).
История состоит в том, что один из ивестных фондов собрал фаундеров своих портфельных стартапов и менторов, и попытался их быстро проапгредить.
Темы, которые попытались покрыть:
1. Как думать, словно ты продакт-менеджер :)
2. Как понять, что строить именно сейчас
3. Как строить стратегию, базируясь на видении продукта
4. Как общаться со стейкхолдерами (не только акционерами/топами, но и командой)
5. Как разработать продуктовые истории, которые реально цепляют людей
6. Как создать исключительную продуктовую команду
7. Как вырасти из РМ в продакт-лидера
8. Как принимать решения, основываясь на данных
9. Как вырасти из РМ в фаундера и реального владельца продукта.
Ответы по версии 1st Round:
http://firstround.com/review/17-product-managers-who-will-own-the-future-of-nyc-tech-and-the-9-frameworks-theyll-use-to-do-it/
История состоит в том, что один из ивестных фондов собрал фаундеров своих портфельных стартапов и менторов, и попытался их быстро проапгредить.
Темы, которые попытались покрыть:
1. Как думать, словно ты продакт-менеджер :)
2. Как понять, что строить именно сейчас
3. Как строить стратегию, базируясь на видении продукта
4. Как общаться со стейкхолдерами (не только акционерами/топами, но и командой)
5. Как разработать продуктовые истории, которые реально цепляют людей
6. Как создать исключительную продуктовую команду
7. Как вырасти из РМ в продакт-лидера
8. Как принимать решения, основываясь на данных
9. Как вырасти из РМ в фаундера и реального владельца продукта.
Ответы по версии 1st Round:
http://firstround.com/review/17-product-managers-who-will-own-the-future-of-nyc-tech-and-the-9-frameworks-theyll-use-to-do-it/
Firstround
17 Product Managers Who Will Own the Future of NYC Tech — and the 9 Frameworks They’ll Use to Do It
Last year, First Round hosted a seminar of 17 rising star product managers in NYC, taught by some of the best product leaders in the tech industry. Here's who they are and what they learned.
Критически важные качества для Product Owner:
1. Адвокат пользователей/клиентов. Как я могу облегчить жизнь своим юзерам? Что их бесит? Чего им не хватает? Если вас не волнуют проблемы ваших пользователей и вам не хочется построить для них лучшее решение - это будет очень трудная и скучная работа, и легко выгореть.
2. Способность найти корень проблемы. Например, можно попросить человека решить почти невозможную задачу: «Помыть все автомобили в Лондоне за день/неделю», и посмотреть на его ход мыслей. Хороший Product Owner сразу спросит «Зачем?». Возможно, проблема в другой и ее можно решить другим, более дешевым способом. По этой же причине, когда вы видите человека, сразу же бегущего выполнять любые указание клиентов/стейкхолдеров - перед вами максимум Project Manager, но никак не Product Owner.
3. Не плоское мышление. Способность подумать, а не идти самым тупым путем. Возможно, есть готовые решения, и не нужно изобретать велосипеды. Возможно, прикручивать конвенциональное решение/библиотеку будет дороже в долгосрочной перспективе, чем подумать и внести минимальные изменения, которые дадут свое решение без лишних зависимостей и оверхэдов. Универсальных ответов здесь нет, и людей, действующих «по накатанной» без использования мозга, сразу видно.
4. Страсть к своему делу. Когда человек рассказывает о своей последней любимой фичуле, его глаза загораются, он начинает быстрее дышать и говорить 😉 Он думает о следующем эпике в душе утром. Он спросит у каждого разработчика, как его дела по задачам текущего спринта (ну и конечно он знает, кто чем занимается и способен понять ответ коллеги, но это другая история). Работа такого Product Owner выглядит как хобби, которым он занимается в течение недели, и еще получает деньги бонусом.
5. Он рекрутер. Этот человек находит ресурсы. Не только людей, коллег и соседние команды/департаменты включаются в его задачи и проблемы, но и - немаловажно - он способен найти ресурсы в своих людях, больше ресурсов чем те сами знали о себе. Человек способен рассказывать о будущем продукта так, что тебе хочется нажать на быструю перемотку и побыстрее оказаться в этом сладком будущем. Это очень полезное качество не только, чтоб собирать деньги на Кикстартере 😉 , но и для работы с командой и пользователями/клиентами.
Бонус. WHAT, WHY, not HOW. Одно из очень спорных, но чаще всего вредных качеств для Product Owners: непреодолимое желание переступить за рамки «ЧТО делать» и начать описывать и рассказывать «КАК делать». Даже для технических Product Owners, и я все время слышу от умных людей это ошибочное убеждение, что утро РО должно начинаться с перечитывания Software Requirements и BABOK. Это, конечно, не лишне, но в скроем вы стремитесь работать со зрелыми специалистами, формирующими самоорганизующуюся команду, которой не нужно подсказывать по каждой мелочи. Плюс вы наступаете на горло собственной песне - только джуны хотят, чтоб им все разжевали, но вам будет очень сложно удерживать синьоров, лидов и архитекторов, если вы будете им рассказывать все до мелочей. И главное, что вы должны осознавать - вы этих мелочей на самом деле не знаете, иначе это у вас было бы 15 лет опыта программирования сложных систем. Каждый должен заниматься своим делом, и лучше направить эту энергию на то, чтоб убедиться, а то ли вы строите, что нужно строить именно сейчас, и будут ли этим пользоваться.
На самом деле все еще жестче: РО единолично стоит отвечать только на вопрос WHY - вопрос, связанный с корневой проблемой юзера (job to be done) или бизнес-задачей (напр, увеличить retention), и даже WHAT решать с командой. У всех нужно развивать чувство product ownership, в конце концов.
Аминь )
1. Адвокат пользователей/клиентов. Как я могу облегчить жизнь своим юзерам? Что их бесит? Чего им не хватает? Если вас не волнуют проблемы ваших пользователей и вам не хочется построить для них лучшее решение - это будет очень трудная и скучная работа, и легко выгореть.
2. Способность найти корень проблемы. Например, можно попросить человека решить почти невозможную задачу: «Помыть все автомобили в Лондоне за день/неделю», и посмотреть на его ход мыслей. Хороший Product Owner сразу спросит «Зачем?». Возможно, проблема в другой и ее можно решить другим, более дешевым способом. По этой же причине, когда вы видите человека, сразу же бегущего выполнять любые указание клиентов/стейкхолдеров - перед вами максимум Project Manager, но никак не Product Owner.
3. Не плоское мышление. Способность подумать, а не идти самым тупым путем. Возможно, есть готовые решения, и не нужно изобретать велосипеды. Возможно, прикручивать конвенциональное решение/библиотеку будет дороже в долгосрочной перспективе, чем подумать и внести минимальные изменения, которые дадут свое решение без лишних зависимостей и оверхэдов. Универсальных ответов здесь нет, и людей, действующих «по накатанной» без использования мозга, сразу видно.
4. Страсть к своему делу. Когда человек рассказывает о своей последней любимой фичуле, его глаза загораются, он начинает быстрее дышать и говорить 😉 Он думает о следующем эпике в душе утром. Он спросит у каждого разработчика, как его дела по задачам текущего спринта (ну и конечно он знает, кто чем занимается и способен понять ответ коллеги, но это другая история). Работа такого Product Owner выглядит как хобби, которым он занимается в течение недели, и еще получает деньги бонусом.
5. Он рекрутер. Этот человек находит ресурсы. Не только людей, коллег и соседние команды/департаменты включаются в его задачи и проблемы, но и - немаловажно - он способен найти ресурсы в своих людях, больше ресурсов чем те сами знали о себе. Человек способен рассказывать о будущем продукта так, что тебе хочется нажать на быструю перемотку и побыстрее оказаться в этом сладком будущем. Это очень полезное качество не только, чтоб собирать деньги на Кикстартере 😉 , но и для работы с командой и пользователями/клиентами.
Бонус. WHAT, WHY, not HOW. Одно из очень спорных, но чаще всего вредных качеств для Product Owners: непреодолимое желание переступить за рамки «ЧТО делать» и начать описывать и рассказывать «КАК делать». Даже для технических Product Owners, и я все время слышу от умных людей это ошибочное убеждение, что утро РО должно начинаться с перечитывания Software Requirements и BABOK. Это, конечно, не лишне, но в скроем вы стремитесь работать со зрелыми специалистами, формирующими самоорганизующуюся команду, которой не нужно подсказывать по каждой мелочи. Плюс вы наступаете на горло собственной песне - только джуны хотят, чтоб им все разжевали, но вам будет очень сложно удерживать синьоров, лидов и архитекторов, если вы будете им рассказывать все до мелочей. И главное, что вы должны осознавать - вы этих мелочей на самом деле не знаете, иначе это у вас было бы 15 лет опыта программирования сложных систем. Каждый должен заниматься своим делом, и лучше направить эту энергию на то, чтоб убедиться, а то ли вы строите, что нужно строить именно сейчас, и будут ли этим пользоваться.
На самом деле все еще жестче: РО единолично стоит отвечать только на вопрос WHY - вопрос, связанный с корневой проблемой юзера (job to be done) или бизнес-задачей (напр, увеличить retention), и даже WHAT решать с командой. У всех нужно развивать чувство product ownership, в конце концов.
Аминь )
Утром попался пост парня о том, как всю свою профессиональную жизнь продакт-менеджера старался дистанцироваться от команды разработки 😂 (WHY?!).
В общем, конечно, мотивы могут быть разгаданы: не идти на поводу разработчиков и не утонуть в анализе багов и спорах о необходимости рефакторинга.
Но: это все нивелирует идею и перспективу иметь команду, которой не пофиг, которая проактивна и не заметает мусор под ковёр («все равно наш РМ не даст нам это исправить, у них сроки, давайте даже не будем его драконить»). И главное - все это приводит к тому, что вы не продакт, а проджект менеджер. А это совсем другая кухня.
В общем, если дать три совета:
1. Не бойтесь своей команды. Дружите, работайте вместе и находите компромиссы.
2. Не бойтесь вникать в технические детали. Я против того, чтоб РО/РМ диктовал реализацию, но проводить с командой груминг (рефайнмент) вы обязаны, не говоря уже о понимании того, как устроен продукт.
3. Ищите совместных решений и находите здоровый баланс между: новыми фичами, багфиксом/саппортом, техдолгом. Как я уже неоднократно писал, это ок если у вас на новую функциональность уходит 60-70% ресурсов, все прочее - самообман.
4. Бонус :) Обратная сторона тенденции тесно работать с командой все же существует - РО/РМ, которые не сильный бизнес/гуманитарной стороне вопроса, таким образом сбегают от юзеров, бизнеса, требований, необходимости все это балансировать и принимать тяжелые, но необходимые решения по бэклогу/роадмапу. Это тоже не ок :)
На конференциях обсуждают проблему, озвученную выше, и вы можете послушать, о чем идёт речь, если чувствуете, что сталкиваетесь с этим: https://youtu.be/Y-glrQUalXs
В общем, конечно, мотивы могут быть разгаданы: не идти на поводу разработчиков и не утонуть в анализе багов и спорах о необходимости рефакторинга.
Но: это все нивелирует идею и перспективу иметь команду, которой не пофиг, которая проактивна и не заметает мусор под ковёр («все равно наш РМ не даст нам это исправить, у них сроки, давайте даже не будем его драконить»). И главное - все это приводит к тому, что вы не продакт, а проджект менеджер. А это совсем другая кухня.
В общем, если дать три совета:
1. Не бойтесь своей команды. Дружите, работайте вместе и находите компромиссы.
2. Не бойтесь вникать в технические детали. Я против того, чтоб РО/РМ диктовал реализацию, но проводить с командой груминг (рефайнмент) вы обязаны, не говоря уже о понимании того, как устроен продукт.
3. Ищите совместных решений и находите здоровый баланс между: новыми фичами, багфиксом/саппортом, техдолгом. Как я уже неоднократно писал, это ок если у вас на новую функциональность уходит 60-70% ресурсов, все прочее - самообман.
4. Бонус :) Обратная сторона тенденции тесно работать с командой все же существует - РО/РМ, которые не сильный бизнес/гуманитарной стороне вопроса, таким образом сбегают от юзеров, бизнеса, требований, необходимости все это балансировать и принимать тяжелые, но необходимые решения по бэклогу/роадмапу. Это тоже не ок :)
На конференциях обсуждают проблему, озвученную выше, и вы можете послушать, о чем идёт речь, если чувствуете, что сталкиваетесь с этим: https://youtu.be/Y-glrQUalXs
YouTube
Дистанцирование продакта от команды / Евгений Некрасов, Avito
Презентация — https://goo.gl/4AXjSp
ProductCamp Perm, февраль 2018
Основатель: Михаил Карпов
Организатор и ключевой спонсор: RealtimeBoard
Партнёры: Дом.ру и Xsolla
ProductCamp Perm, февраль 2018
Основатель: Михаил Карпов
Организатор и ключевой спонсор: RealtimeBoard
Партнёры: Дом.ру и Xsolla
Вы конечно же читаете канал Кости Горского из Интеркома, но если вдруг пропустили - вот как раз последний пост на тему важности тесной работы с командой: https://news.1rj.ru/str/desprod/277
Telegram
Design & Productivity
Сегодня я в Лондоне. Осенью мы открыли тут небольшой офис разработки, так как в Дублине не успеваем нанимать людей с такой скоростью, с какой бы хотелось. В Лондоне клёво. На фотке — мой любимый кофешоп — Department of coffee and social affairs. Ещё в Лондоне…
Коллега поделился неплохим обзором общих антипаттернов по тестированию. Если вы РО/РМ, который давно работает (особенно в энтерпрайз) разработке, ничего особо нового вы не увидите. С другой стороны, иногда полезно уложить все в общую картину и вспомнить основы.
Вы, конечно, не отвечаете за тестирование ;), но понимать что такое хорошо, а что такое плохо - вы обязаны, не говоря уже о том, чтоб разговаривать со своими разработчиками на одном языке.
https://habr.com/post/358178/ - RU версия
http://blog.codepipes.com/testing/software-testing-antipatterns.html - EN оригинал
Вы, конечно, не отвечаете за тестирование ;), но понимать что такое хорошо, а что такое плохо - вы обязаны, не говоря уже о том, чтоб разговаривать со своими разработчиками на одном языке.
https://habr.com/post/358178/ - RU версия
http://blog.codepipes.com/testing/software-testing-antipatterns.html - EN оригинал
Хабр
Антипаттерны тестирования ПО
Введение Есть несколько статей об антипаттернах разработки ПО. Но большинство из них говорят о деталях на уровне кода и фокусируются на конкретной технологии или...
Вчера я был на замечательном воркшопе от MindTheProduct в Амстердаме.
MTP организовывают самые интересные конференции и тренинги по продакт менеджменту, две самые крупные - летом в Сан-Франциско и осенью в Лондоне; очень советую.
Я напишу о контенте и выводах, а сейчас хотел поделиться одним очень простым наблюдением. Огромная польза для РО/РМ с пост-СССР пространства состоит просто в возможности в течение дня отмериваться опытом с другими продактами со всего мира, узнавать как они решают те же проблемы, над которыми ты бьешься каждый день. Это незаменимо, особенно если вы строите продукт на глобальный рынок, или как минимум стремитесь быть специалистом топ-уровня.
Продолжение следует :)
https://www.eventbrite.com/e/product-management-essentials-102-training-workshop-amsterdam-tickets-43599757047
MTP организовывают самые интересные конференции и тренинги по продакт менеджменту, две самые крупные - летом в Сан-Франциско и осенью в Лондоне; очень советую.
Я напишу о контенте и выводах, а сейчас хотел поделиться одним очень простым наблюдением. Огромная польза для РО/РМ с пост-СССР пространства состоит просто в возможности в течение дня отмериваться опытом с другими продактами со всего мира, узнавать как они решают те же проблемы, над которыми ты бьешься каждый день. Это незаменимо, особенно если вы строите продукт на глобальный рынок, или как минимум стремитесь быть специалистом топ-уровня.
Продолжение следует :)
https://www.eventbrite.com/e/product-management-essentials-102-training-workshop-amsterdam-tickets-43599757047
Eventbrite
Product Management Essentials 102 Training Workshop - Amsterdam
Increasing your strategic impact as a product manager
Training Workshop Overview
Essentials 102 is an overview course intended for confident product managers who are looking to increase their strategic skills and influence. The intention of this course is…
Training Workshop Overview
Essentials 102 is an overview course intended for confident product managers who are looking to increase their strategic skills and influence. The intention of this course is…
Customer requirements are not Product Requirements.
Да, нужно слушать customer voice. Но это лишь один из источников наравне с сейлз, маркетингом, customer success, стейкхолдерами. В сумме все это может корректировать очередность выпуска фич в вашем роадмапе, но:
1. Помните о стратегии и видении; очень, очень легко потеряться в штамповке фич, которые «все юзеры хотят и ждут».
2. Продолжение п.1: не превращайте ваш продукт в франкейнштейна из меню и настроек («мы просто сделаем это опциональным»).
3. Помните, что решение о приоритетах бэклога принимает Product Owner/Manager, а не клиент. И даже не директор департамента или член совета директоров, которому кто-то позвонил.
И самое главное - все specials и кастомная разработка приводят вас в проектному мышлению и уводят от продуктового, демотивирует команду и уводят вас от стратегии по запуску и проверке фич, которые вы как продакт запланировали для достижения ваших целей.
Да, нужно слушать customer voice. Но это лишь один из источников наравне с сейлз, маркетингом, customer success, стейкхолдерами. В сумме все это может корректировать очередность выпуска фич в вашем роадмапе, но:
1. Помните о стратегии и видении; очень, очень легко потеряться в штамповке фич, которые «все юзеры хотят и ждут».
2. Продолжение п.1: не превращайте ваш продукт в франкейнштейна из меню и настроек («мы просто сделаем это опциональным»).
3. Помните, что решение о приоритетах бэклога принимает Product Owner/Manager, а не клиент. И даже не директор департамента или член совета директоров, которому кто-то позвонил.
И самое главное - все specials и кастомная разработка приводят вас в проектному мышлению и уводят от продуктового, демотивирует команду и уводят вас от стратегии по запуску и проверке фич, которые вы как продакт запланировали для достижения ваших целей.
Материалы с воркшопа Mind The Product. Если у вас нет времени или лишних денег посещать такого рода воркшопы (хотя стоит найти и то, и другое!), делюсь кратким гайдом с подборкой классных отобранных материалов по продакт менеджменту. Вы можете (и должны!) быть продакт менеджерами мирового уровня, а для этого нужно учиться )
Здесь нет контента самого воркшопа, выжимки по нему я напишу позже, как и обещал.
Здесь нет контента самого воркшопа, выжимки по нему я напишу позже, как и обещал.
Resource Guide - MindTheProduct - mishanestor.pdf
343.4 KB
Материалы с воркшопа Mind The Product.
Не так давно я писал о том, что вопрос WHY - главное орудие РО.
https://news.1rj.ru/str/productdev/43
Вчера мы проводили второй день тренинга по agile для всей команды и отдельное внимание уделили масштабированию на примере SAFe. Что интересно, это как эти три вопроса ложатся на уровни процесса:
1. WHY: уровень бизнеса/портфолио. Зачем мы финансируем вот эту программу в нашем портфеле, какие бизнес-задачи мы хотим решить.
2. WHAT: уровень программ/бизнес-эпиков. Что мы планируем строить, какие верхнеуровневые наборы фич можем здесь сформулировать.
3. HOW: уровень фич/скрам-команд. Как именно мы реализуем вот эту юзер-стори, какие технологии выберем, как это встроится в существующий продукт.
Естественно, здесь масса нюансов - и роль продакт-менеджера, и вовлечение архитектора, и идентификация зависимостей, внедрение Program Increment Planning и т.д., но в целом Фреймворк ещё раз подчеркивает важность умения «отпускать» - децентрализовать и давать командам свободу находить лучший способ реализации.
https://news.1rj.ru/str/productdev/43
Вчера мы проводили второй день тренинга по agile для всей команды и отдельное внимание уделили масштабированию на примере SAFe. Что интересно, это как эти три вопроса ложатся на уровни процесса:
1. WHY: уровень бизнеса/портфолио. Зачем мы финансируем вот эту программу в нашем портфеле, какие бизнес-задачи мы хотим решить.
2. WHAT: уровень программ/бизнес-эпиков. Что мы планируем строить, какие верхнеуровневые наборы фич можем здесь сформулировать.
3. HOW: уровень фич/скрам-команд. Как именно мы реализуем вот эту юзер-стори, какие технологии выберем, как это встроится в существующий продукт.
Естественно, здесь масса нюансов - и роль продакт-менеджера, и вовлечение архитектора, и идентификация зависимостей, внедрение Program Increment Planning и т.д., но в целом Фреймворк ещё раз подчеркивает важность умения «отпускать» - децентрализовать и давать командам свободу находить лучший способ реализации.
Telegram
Product Development and Management 🏋️♀️
Критически важные качества для Product Owner:
1. Адвокат пользователей/клиентов. Как я могу облегчить жизнь своим юзерам? Что их бесит? Чего им не хватает? Если вас не волнуют проблемы ваших пользователей и вам не хочется построить для них лучшее решение…
1. Адвокат пользователей/клиентов. Как я могу облегчить жизнь своим юзерам? Что их бесит? Чего им не хватает? Если вас не волнуют проблемы ваших пользователей и вам не хочется построить для них лучшее решение…
Какие бывают продакт-менеджеры?
- Продакт-исследователь (discovery) — фокусируется на исследовании рынка, поиске голубых океанов, трендов и инсайтов. Думает, что чем больше статистических данных, тем лучше получится продукт. Плачет после первого запуска, потому что это не так.
- Продакт-писатель [требований] — оборачивается пледиком и начинает строчить тикетули в Jira. Размеру его беклога больше, чем расстояние от Земли до Альфа-Центавра. Постоянно потеет, потому что хотелок написал много, а команда может сделать только четыре.
- Продакт-проектировщик (design) — обожает стикеры и почесать языком с потенциальными пользователями или стейкхолдерами (обратный типаж — великий гений создает своё шедевр в одиночестве). Рисует невнятные каляки-маляки, которые потом с болью превращаются командой в код. Быстро теряет интерес к продукту после MVP.
- Продакт-проджект — в его речи чаще слышны burndown chart и фокус-фактор, чем cohort analysis и коэффициент доверия. Скрамовский оунер, стремится не столько приносить ценность в продукт, сколько увеличить велосити команды. Плохо понимает, какой реальный профит принесёт то, что делает командой.
- Продакт-роадмеппер — прохвост, рисующий дороги-карты с датами. Когда выпуск фичи не попадает в дату, находится тысяча причин, почему его сбалансировано-построенный роадмеп правильный, а другие — нет. Любит говорить о том, как текущее корыто превратится в космический корабль. Не очень понимает, когда это все же наступит.
- Продакт-продажник — любит костюмы и очки с деревянными дужками. Ездит по пресейлам, продавая клиентам ожидания. Для команды использует только два приоритета: СРОЧНО и ВНЕЗАПНО. Уверен, что продукт должен делать деньги, а не ценность. Внедряет всё, что просят крупные и не очень клиенты, лишь бы их удержать.
- Продакт-маркетинг — умеет пользоваться Яндекс.Метрикой и скакалкой. Меряет конверсию продукта во всё, что угодно. Подготавливает рассылки, рекламу и флаеры. Любит писать фельетоны про «уникальный продукт» и «новое качество жизни». Сидит в твиттере и фейсбуке через телеграм на iwatch.
- Продакт-аналитик данных — знает, как считать когорты при помощи куба и сводных таблиц. Различает среднее от медианы. Слышал про моду и статистическую значимость. Любит навешивать цели на всё, что попадется под руку. Когда говорит и показывает графики с сияющими глазами, никто ничего не понимает, но все кивают. Впадает в аналитический паралич чуть менее, чем постоянно.
- Продакт-руководитель — любит водить руками в стороны, создавая муссоны. Ничего не умеет делать, кроме «синхронизировать» других для разработки продукта. Илита, кормящая своим продуктовым молоком личинок продактов. В резюме пишет, что делает в год по сто продуктов. Не человек — конвейер!
- Продакт-евангелист — спит в поездах за деньги компании. Когда бодрствует, говорит ртом в толпу на разных вписках. Вместо обоев дома клеит бейджики с конференций. Придумывает фичи, пока вещает. Забывает, что они еще не реализованы. Уверен, что его компания лидер рынка. Знает, куда этот рынок придет через 20 лет. Не знает, что выдаст команда через неделю.
- Продакт-блоггер — пишет обо всякой херне. Устраивает конкурсы. Каждое второе предложение начинает со фразы «Меня часто спрашивают…».
(Каждый может узнать себя в те или иные моменты 🙂 Источник: http://sergeytikhomirov.ru/vvedenie-v-produktovyj-menedzhment/)
- Продакт-исследователь (discovery) — фокусируется на исследовании рынка, поиске голубых океанов, трендов и инсайтов. Думает, что чем больше статистических данных, тем лучше получится продукт. Плачет после первого запуска, потому что это не так.
- Продакт-писатель [требований] — оборачивается пледиком и начинает строчить тикетули в Jira. Размеру его беклога больше, чем расстояние от Земли до Альфа-Центавра. Постоянно потеет, потому что хотелок написал много, а команда может сделать только четыре.
- Продакт-проектировщик (design) — обожает стикеры и почесать языком с потенциальными пользователями или стейкхолдерами (обратный типаж — великий гений создает своё шедевр в одиночестве). Рисует невнятные каляки-маляки, которые потом с болью превращаются командой в код. Быстро теряет интерес к продукту после MVP.
- Продакт-проджект — в его речи чаще слышны burndown chart и фокус-фактор, чем cohort analysis и коэффициент доверия. Скрамовский оунер, стремится не столько приносить ценность в продукт, сколько увеличить велосити команды. Плохо понимает, какой реальный профит принесёт то, что делает командой.
- Продакт-роадмеппер — прохвост, рисующий дороги-карты с датами. Когда выпуск фичи не попадает в дату, находится тысяча причин, почему его сбалансировано-построенный роадмеп правильный, а другие — нет. Любит говорить о том, как текущее корыто превратится в космический корабль. Не очень понимает, когда это все же наступит.
- Продакт-продажник — любит костюмы и очки с деревянными дужками. Ездит по пресейлам, продавая клиентам ожидания. Для команды использует только два приоритета: СРОЧНО и ВНЕЗАПНО. Уверен, что продукт должен делать деньги, а не ценность. Внедряет всё, что просят крупные и не очень клиенты, лишь бы их удержать.
- Продакт-маркетинг — умеет пользоваться Яндекс.Метрикой и скакалкой. Меряет конверсию продукта во всё, что угодно. Подготавливает рассылки, рекламу и флаеры. Любит писать фельетоны про «уникальный продукт» и «новое качество жизни». Сидит в твиттере и фейсбуке через телеграм на iwatch.
- Продакт-аналитик данных — знает, как считать когорты при помощи куба и сводных таблиц. Различает среднее от медианы. Слышал про моду и статистическую значимость. Любит навешивать цели на всё, что попадется под руку. Когда говорит и показывает графики с сияющими глазами, никто ничего не понимает, но все кивают. Впадает в аналитический паралич чуть менее, чем постоянно.
- Продакт-руководитель — любит водить руками в стороны, создавая муссоны. Ничего не умеет делать, кроме «синхронизировать» других для разработки продукта. Илита, кормящая своим продуктовым молоком личинок продактов. В резюме пишет, что делает в год по сто продуктов. Не человек — конвейер!
- Продакт-евангелист — спит в поездах за деньги компании. Когда бодрствует, говорит ртом в толпу на разных вписках. Вместо обоев дома клеит бейджики с конференций. Придумывает фичи, пока вещает. Забывает, что они еще не реализованы. Уверен, что его компания лидер рынка. Знает, куда этот рынок придет через 20 лет. Не знает, что выдаст команда через неделю.
- Продакт-блоггер — пишет обо всякой херне. Устраивает конкурсы. Каждое второе предложение начинает со фразы «Меня часто спрашивают…».
(Каждый может узнать себя в те или иные моменты 🙂 Источник: http://sergeytikhomirov.ru/vvedenie-v-produktovyj-menedzhment/)