К сожалению, в случае с начальством, фасилитатор не всегда поможет, ибо у некоторых эго чудовищных размеров(тут ничего не поделаешь) или какие то моменты непонятны и тут они будут вгрызаться до полноты осознания, а учитывая график первых лиц, все приходится делать на одном созвоне, потому что потом не будет возможности, а решить надо и вопрос не для переписки. А вообще статья дельная, особенно для начинающих)
Жизненно) Хотя бывают моменты, когда некоторые пункты из "Что РП в силах изменить: " надо перевести/дублировать в категорию "Что РП не в силах изменить:"
Спорное утверждение. У тех.лида /архитектора своих дел тьма, а тут ему еще управление проектом накидывать... Если тех.лид /архитектор погружается в менеджерскую часть(планы, бюджеты, общение с заказчиком, со смежниками, отчетная часть и тд) месяца через 3-4 его экспертная составляющая просядет, а если еще и бюрократизации компании большая так вообще пу - пу - пу. Понятное дело, что на начальном этапе РП с опытом работы разработчиком будет эффективнее(больше понимает, меньше времени на коммуникации), но спустя небольшой период времени, чистый РП(без опыта разработки) погрузится в проект достаточно, что бы разница между ним и РП с опытом разработки была несущественной.
согласен, не так важно,с точки зрения планирования можно просто корректировать значение SP, которое команда способна выполнить за спринт. Тут имел ввиду, что что может 2SP за 15 минут это норма, а если нет, то на ревью можно будет разобраться в чем дело, может просто переоценили задачу и тд (если конечно именно эта задача как то повлияла на спринт).
Спорный момент, пользуетесь часами при оценке, значит должны адекватно учитывать трудозатраты и оглядываться на ситуации когда оценили в час, а вышло 15 минут. При SP все зависти от базового значения и его корреляции со временем) P.S На практике, попасть точно с оценкой можно только в случае типовых задач, которые 20 раз делали и всем все понятно, а так, в среднем по больнице синусоида +/- 15% от оценки и неожиданные всплески
Согласен с предыдущими комментариями. Вроде написали, что нужно все учесть, но, как и выше уже писали, работа с рисками не отражена (а это минимум процентов 15 бюджета). Думаю стоило бы больше прописать по теории, чем приводить пример. Момент с налогами тоже смутил, не слышал, что бы РП этим занимался, обычно либо считают чистый ФОТ либо ФОТ * коэф.накладных и этого достаточно.
Первый абзац это шедевр))) Не могу сказать, что полностью согласен, но статья отличная пища для размышлений, тут и комментарии к статье могут потянуть на отдельный материал)
Только по итогам одного квартала примерно в два раза сократилось количество простоев, а Time to market вырос в 10 раз. Параметр Cycle Time у нас составлял 50, сейчас он равен примерно 15–20. Частота релизов (Change Frequency) вначале равнялась 30, теперь она достигла планки в 100. Результаты реально серьёзно улучшились: мы чаще релизимся, меньше откатываемся и быстрее делаем свои задачи.
Звучит, конечно, сильно. Change Frequency = 100 это тоже по результатам одного квартала? Речь именно о полноценных релизах или хотфиксы тоже включены?
Сначала испытываем на фокус-группе (например, на себе любимых), потом на 1 % всех клиентов, потом 10 % и далее 50 – 80 – 100 %
хех, тут не поспоришь, а в ситуации с тендерами и "конторами" так совсем бывает грустно, вот победили "любой ценой", а по итогу лучше бы не участвовали...
Соглашусь с предыдущим комментарием, есть некоторый сумбур, но как месседж, что проектный менеджмент это не только про пинг по задачкам, то неплохо) З.Ы. я бы еще и на сроки процентов 30 закидывал)
Сильно, практически допрос) тоже интересно, были ли те кто ответил правильно на все вопросы и как часто справлялись с 7? Пункт 1.2, на мой взгляд, спорный, может быть воспринято как банальное неуважение.
Соглашусь. Какой уровень технического бэкграунда в предметной области, с Вашей точки зрения, должен быть у РП? На эту тему уже были статьи на хабре, но все еще любопытно узнавать мнение людей с большим опытом) Желательно на примере)
Как рекомендация для начинающих прям неплохо) есть несколько мутных моментов, особенно бросилось в глаза планирование. Но, повторюсь, для тех кто заходит в сферу неплохо.
Интересно получлось, а были случаи, когда в ходе Discovery спринта менялись основные требования к функционалу который был реализован/находился в процессе реализация и затрагивающий несколько команд одновременно? Как вообще была устроена работа с внеплановыми изменениями большего масштаба?
К сожалению, в случае с начальством, фасилитатор не всегда поможет, ибо у некоторых эго чудовищных размеров(тут ничего не поделаешь) или какие то моменты непонятны и тут они будут вгрызаться до полноты осознания, а учитывая график первых лиц, все приходится делать на одном созвоне, потому что потом не будет возможности, а решить надо и вопрос не для переписки. А вообще статья дельная, особенно для начинающих)
Да, об этом. Может сформулировал некорректно. С Вашей точки зрения, по каким критериям следует оценивать РП?
Соглашусь, речь шла о человеке, который осознанно пришел в сферу.
Жизненно) Хотя бывают моменты, когда некоторые пункты из "Что РП в силах изменить: " надо перевести/дублировать в категорию "Что РП не в силах изменить:"
Какой уровень понимания проекта Вы ожидаете от РП? 5 лет это бОльшой срок, за это время можно и разработчика вырастить из вчерашнего студента.
Тогда только Scrum-master'ом))))
Спорное утверждение. У тех.лида /архитектора своих дел тьма, а тут ему еще управление проектом накидывать... Если тех.лид /архитектор погружается в менеджерскую часть(планы, бюджеты, общение с заказчиком, со смежниками, отчетная часть и тд) месяца через 3-4 его экспертная составляющая просядет, а если еще и бюрократизации компании большая так вообще пу - пу - пу. Понятное дело, что на начальном этапе РП с опытом работы разработчиком будет эффективнее(больше понимает, меньше времени на коммуникации), но спустя небольшой период времени, чистый РП(без опыта разработки) погрузится в проект достаточно, что бы разница между ним и РП с опытом разработки была несущественной.
согласен, не так важно,с точки зрения планирования можно просто корректировать значение SP, которое команда способна выполнить за спринт. Тут имел ввиду, что что может 2SP за 15 минут это норма, а если нет, то на ревью можно будет разобраться в чем дело, может просто переоценили задачу и тд (если конечно именно эта задача как то повлияла на спринт).
Спорный момент, пользуетесь часами при оценке, значит должны адекватно учитывать трудозатраты и оглядываться на ситуации когда оценили в час, а вышло 15 минут.
При SP все зависти от базового значения и его корреляции со временем)
P.S На практике, попасть точно с оценкой можно только в случае типовых задач, которые 20 раз делали и всем все понятно, а так, в среднем по больнице синусоида +/- 15% от оценки и неожиданные всплески
Согласен с предыдущими комментариями. Вроде написали, что нужно все учесть, но, как и выше уже писали, работа с рисками не отражена (а это минимум процентов 15 бюджета). Думаю стоило бы больше прописать по теории, чем приводить пример. Момент с налогами тоже смутил, не слышал, что бы РП этим занимался, обычно либо считают чистый ФОТ либо ФОТ * коэф.накладных и этого достаточно.
Первый абзац это шедевр)))
Не могу сказать, что полностью согласен, но статья отличная пища для размышлений, тут и комментарии к статье могут потянуть на отдельный материал)
А какой сейчас показатель Change Failure Rate?
Звучит, конечно, сильно. Change Frequency = 100 это тоже по результатам одного квартала? Речь именно о полноценных релизах или хотфиксы тоже включены?
Какие временные интервалы между переходами?
хех, тут не поспоришь, а в ситуации с тендерами и "конторами" так совсем бывает грустно, вот победили "любой ценой", а по итогу лучше бы не участвовали...
Соглашусь с предыдущим комментарием, есть некоторый сумбур, но как месседж, что проектный менеджмент это не только про пинг по задачкам, то неплохо)
З.Ы. я бы еще и на сроки процентов 30 закидывал)
Сильно, практически допрос) тоже интересно, были ли те кто ответил правильно на все вопросы и как часто справлялись с 7? Пункт 1.2, на мой взгляд, спорный, может быть воспринято как банальное неуважение.
Соглашусь. Какой уровень технического бэкграунда в предметной области, с Вашей точки зрения, должен быть у РП? На эту тему уже были статьи на хабре, но все еще любопытно узнавать мнение людей с большим опытом) Желательно на примере)
Как рекомендация для начинающих прям неплохо) есть несколько мутных моментов, особенно бросилось в глаза планирование. Но, повторюсь, для тех кто заходит в сферу неплохо.
Интересно получлось, а были случаи, когда в ходе Discovery спринта менялись основные требования к функционалу который был реализован/находился в процессе реализация и затрагивающий несколько команд одновременно? Как вообще была устроена работа с внеплановыми изменениями большего масштаба?
Хорошая подборка, только поправьте ссылку на Kanban метод: инструкция к применению не туда ведет)