Согласен с предыдущими комментариями. Вроде написали, что нужно все учесть, но, как и выше уже писали, работа с рисками не отражена (а это минимум процентов 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 спринта менялись основные требования к функционалу который был реализован/находился в процессе реализация и затрагивающий несколько команд одновременно? Как вообще была устроена работа с внеплановыми изменениями большего масштаба?
Согласен, при определенных условиях необходимость в части инструментов отпадает, но, как мне кажется, знания о базовых понятиях (диаграмма Ганта и тд) должны быть у любого ПМ.
ПМ без технички выезжают за счет сильных софтов, лояльной и мотивированной команды) Достойная статья, было бы неплохо если бы Вы развили ее дальше, как раз на предмет степени погружения в техничку, в идеале на примере какого нибудь проекта из личного опыта
Согласен с предыдущими комментариями. Вроде написали, что нужно все учесть, но, как и выше уже писали, работа с рисками не отражена (а это минимум процентов 15 бюджета). Думаю стоило бы больше прописать по теории, чем приводить пример. Момент с налогами тоже смутил, не слышал, что бы РП этим занимался, обычно либо считают чистый ФОТ либо ФОТ * коэф.накладных и этого достаточно.
Первый абзац это шедевр)))
Не могу сказать, что полностью согласен, но статья отличная пища для размышлений, тут и комментарии к статье могут потянуть на отдельный материал)
А какой сейчас показатель Change Failure Rate?
Звучит, конечно, сильно. Change Frequency = 100 это тоже по результатам одного квартала? Речь именно о полноценных релизах или хотфиксы тоже включены?
Какие временные интервалы между переходами?
хех, тут не поспоришь, а в ситуации с тендерами и "конторами" так совсем бывает грустно, вот победили "любой ценой", а по итогу лучше бы не участвовали...
Соглашусь с предыдущим комментарием, есть некоторый сумбур, но как месседж, что проектный менеджмент это не только про пинг по задачкам, то неплохо)
З.Ы. я бы еще и на сроки процентов 30 закидывал)
Сильно, практически допрос) тоже интересно, были ли те кто ответил правильно на все вопросы и как часто справлялись с 7? Пункт 1.2, на мой взгляд, спорный, может быть воспринято как банальное неуважение.
Соглашусь. Какой уровень технического бэкграунда в предметной области, с Вашей точки зрения, должен быть у РП? На эту тему уже были статьи на хабре, но все еще любопытно узнавать мнение людей с большим опытом) Желательно на примере)
Как рекомендация для начинающих прям неплохо) есть несколько мутных моментов, особенно бросилось в глаза планирование. Но, повторюсь, для тех кто заходит в сферу неплохо.
Интересно получлось, а были случаи, когда в ходе Discovery спринта менялись основные требования к функционалу который был реализован/находился в процессе реализация и затрагивающий несколько команд одновременно? Как вообще была устроена работа с внеплановыми изменениями большего масштаба?
Хорошая подборка, только поправьте ссылку на Kanban метод: инструкция к применению не туда ведет)
Согласен, при определенных условиях необходимость в части инструментов отпадает, но, как мне кажется, знания о базовых понятиях (диаграмма Ганта и тд) должны быть у любого ПМ.
ПМ без технички выезжают за счет сильных софтов, лояльной и мотивированной команды) Достойная статья, было бы неплохо если бы Вы развили ее дальше, как раз на предмет степени погружения в техничку, в идеале на примере какого нибудь проекта из личного опыта