Comments 8
Надо процесс разработки встраивать в управление проектом.
1. Сроки проекта — не характеристика процесса.
2. Показатели продукта («сколько окон») — не характеристика процесса.
3. Характеристики процесса это количество объем хотелок на входе, и уровень качества их исполнения на выходе в заданном таймбоксе.
4. Не удовлетворяет качество — меняйте процесс (на этой мысли весь ISO стоит кстати),
5. Управление проектом — это неизбежные планирование, реализация и завершение. Выбор подходящего процесса — элемент планирования. Оценка прогресса проекта и продукта по характеристикам выходов процесса — элемент реализации (как и принятие решений в ходе).
6. В PMBoK например (и много где), есть кривая о стоимости внесения изменений в результат в начале и в конце проекта. И никакой agile и/или волшебный рефакторинг (будь он хоть ежедневный) эту кривую не исправит по той простой причине что конечный продукт будучи системой теперь требует гораздо большего внимания к себе в целом.
7. Проектный треугольник тоже аджайлом не отменяется.
1. Сроки проекта — не характеристика процесса.
2. Показатели продукта («сколько окон») — не характеристика процесса.
3. Характеристики процесса это количество объем хотелок на входе, и уровень качества их исполнения на выходе в заданном таймбоксе.
4. Не удовлетворяет качество — меняйте процесс (на этой мысли весь ISO стоит кстати),
5. Управление проектом — это неизбежные планирование, реализация и завершение. Выбор подходящего процесса — элемент планирования. Оценка прогресса проекта и продукта по характеристикам выходов процесса — элемент реализации (как и принятие решений в ходе).
6. В PMBoK например (и много где), есть кривая о стоимости внесения изменений в результат в начале и в конце проекта. И никакой agile и/или волшебный рефакторинг (будь он хоть ежедневный) эту кривую не исправит по той простой причине что конечный продукт будучи системой теперь требует гораздо большего внимания к себе в целом.
7. Проектный треугольник тоже аджайлом не отменяется.
Если не устраивает качество, менять надо не процесс, а людей. Хорошая команда вытянет любой меджерский идиотизм, плохая при любых наиправильнейших методиках выдаст в лучшем случае посредственный результат.
PMBoK тоже сгубил ни один десяток фирм. Если выкинуть за скобки людей и технологии, хорошо получаться будут только отчёты. Если можно продать результат до наступления Tнас, разводить бюрократию никакого смысла нет. Тем более, если клиент настолько глуп, что ему можно продать время работы вместо конечного результата.
А выводить доказательства из метафор — занятие достаточно бесполезное.
PMBoK тоже сгубил ни один десяток фирм. Если выкинуть за скобки людей и технологии, хорошо получаться будут только отчёты. Если можно продать результат до наступления Tнас, разводить бюрократию никакого смысла нет. Тем более, если клиент настолько глуп, что ему можно продать время работы вместо конечного результата.
А выводить доказательства из метафор — занятие достаточно бесполезное.
Если не устраивает качество, менять надо не процесс, а людей. Хорошая команда вытянет любой меджерский идиотизм, плохая при любых наиправильнейших методиках выдаст в лучшем случае посредственный результат.
Ничего себе у вас откровения.
PMBoK тоже сгубил ни один десяток фирм. Если выкинуть за скобки людей и технологии, хорошо получаться будут только отчёты.
Еще мощнее задвинули.
А выводить доказательства из метафор — занятие достаточно бесполезное.Не знаю как насчет доказательств, но выводы сделали вы в своем посте. Метафора стройки сами знаете что устаревшая, лично мне больше нравится «органическое программирование». Ну или метафора лечения пациента в крайних случаях. Не суть.
Процесс это то, как задачи получают своё решение. Не надо говорить про бюрократию и формальности, услышав про упомянутый всуе PMBoK. Наличие упомянутых двух сроков — как раз следствие отсутствия в проекте поставленного процесса, формального или неформального, способа превращения задач в их решение. К слову, PMBoK много говорит о том, как сделать так, чтобы срок у проекта был один, и в конце всем было хорошо. Он весь об этом. Об управлении проектом как системой, о том какие аспекты в видении проекта надо иметь, чтобы проект оказался там, где он должен быть.
Хорошая же команда отличается от плохой тем, насколько она способна следовать и видоизменять свой процесс, чтобы достигнуть цели. Уровень идиотизма менеджмента кстати так же можно различать, насколько он способен изменять и изменяться, вдобавок обосновав предварительно своё решение.
Всё о чем я пишу, видел и участвовал в подобном неоднократно. Описываемый в посте взгляд на УП мне тоже встречался. Я кстати счастлив что пишу об этом в прошедшем времени. Подход «люди — это главное» — это недостаток уровня менеджмента, который при каждой неудаче будет винить персоналии (по всем цепочкам влево-вправо и вверх-вниз) — это обратная сторона этого лозунга. А кстати и процесс — это тоже не главное, хотя он всегда существует (хаотический или управляемый). Главное — это соответствие процесса задаче.
Подход «люди — это главное» — это недостаток уровня менеджмента,
Не хотел, но придётся
Или на английском
А метафора не может быть устаревшей. Это не более чем метафора. Но и не менее.
Не хотел, но придётся
Проказница-Мартышка, Осел, Козел да косолапый Мишка
Затеяли сыграть Квартет.
Достали нот, баса, альта, две скрипки
И сели на лужок под липки — Пленять своим искусством свет.
Ударили в смычки, дерут, а толку нет.
«Стой, братцы, стой! — кричит Мартышка. — Погодите!
Как музыке идти? Ведь вы не так сидите.
Или на английском
PMI disclaims and makes no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes or needs. PMI does not undertake to guarantee the performance of any individual manufacturer or seller’s products or services by virtue of this standard or guide.
А метафора не может быть устаревшей. Это не более чем метафора. Но и не менее.
Не хотел, но придётсяУгу. В басне в общем-то «людей» и заменяют, и мораль можно увидеть в том, что такого рода менеджмент не приносит результата. То есть задача не решается не исполнителями, а менеджментом. В случае с PMBoK в области знаний «Управление человеческими ресурсами» есть кое-что про развитие команды.
А по поводу процитированного — напишите свой стандарт (можете даже не привлекать 500 экспертов) по управлению проектами (в духе «люди — это главное»), и возьмите ответственность за результаты его применения. Как только NASA возьмет его на вооружение, есть шанс что с ним ознакомятся многие.
«Управление человеческими ресурсами» — вещь хорошая, только я всё больше квартеты встречаю, где какая-нибудь мартышка этим самым PMBoKом трясёт. Точнее, если по количеству народа и задачам судить, то целые симфонические оркестры.
А NASA — не показатель. Это государственная контора, там денег не меряно. Выпускают они сверхсложный кустарный продукт мелкосерийны и дорогой. Если отойти немного в сторону и посмотреть на коммерческие проекты в той же области, там всё немного не так. (Да, видел вживую)
А NASA — не показатель. Это государственная контора, там денег не меряно. Выпускают они сверхсложный кустарный продукт мелкосерийны и дорогой. Если отойти немного в сторону и посмотреть на коммерческие проекты в той же области, там всё немного не так. (Да, видел вживую)
Давайте, тоже начну с метафоры:
Господь диктует Моисею Тору:- … не вари козленка в молоке матери его…
Моисей:- O, погоди, минуточку… А-а-а-а, я понял! Это означает — не ешь мясного с молочным?!
Господь:- Hе фантазируй. Пиши, что говорят — не вари козленка в моло…
Моисей:- Aааа, сейчас, ага, все — понял: надо иметь отдельную посуду для мяса и молока!
Господь (раздраженно):- Послушай, что ты несешь? Я же тебе ясно сказал! Не выдумывай, пиши, что диктуют: не вари козлен…
Моисей:- Bсе, все, вот теперь — понял: после мясного надо подождать шесть часов, прежде чем есть молочное, а после молочного…
Господь (устало, махнув рукой):- Э, делайте, что хотите…
Так вот, читая принципы Agile, редко кто читает обе части принципа. Ах, там написано: люди и их взаимодействие важнее процессов. Поэтому давайте на процессы забьем, ведь люди важнее. Вот где в этом принципе написано, что процессы не важны? Где? Да, люди важнее, но без адекватных процессов вы получите те самые T которые приводите. При классных людях и процессах соответствующих потребностям ваших проектов, при постоянном процессе улучшения этих людей и процессов, вы вообще покорите весь мир.
Господь диктует Моисею Тору:- … не вари козленка в молоке матери его…
Моисей:- O, погоди, минуточку… А-а-а-а, я понял! Это означает — не ешь мясного с молочным?!
Господь:- Hе фантазируй. Пиши, что говорят — не вари козленка в моло…
Моисей:- Aааа, сейчас, ага, все — понял: надо иметь отдельную посуду для мяса и молока!
Господь (раздраженно):- Послушай, что ты несешь? Я же тебе ясно сказал! Не выдумывай, пиши, что диктуют: не вари козлен…
Моисей:- Bсе, все, вот теперь — понял: после мясного надо подождать шесть часов, прежде чем есть молочное, а после молочного…
Господь (устало, махнув рукой):- Э, делайте, что хотите…
Так вот, читая принципы Agile, редко кто читает обе части принципа. Ах, там написано: люди и их взаимодействие важнее процессов. Поэтому давайте на процессы забьем, ведь люди важнее. Вот где в этом принципе написано, что процессы не важны? Где? Да, люди важнее, но без адекватных процессов вы получите те самые T которые приводите. При классных людях и процессах соответствующих потребностям ваших проектов, при постоянном процессе улучшения этих людей и процессов, вы вообще покорите весь мир.
Sign up to leave a comment.
Насыщенное состояние Agile