?

Log in

No account? Create an account

psilonsk


Блог об управлении проектами


Previous Entry Share Next Entry
Новые горизонты проектного управления
psilonsk


Мир проектного управления сильно изменился, друзья мои.

PMBoK, который был абсолютно бесполезен еще пятнадцать лет назад, можно спокойно использовать по назначению (аккуратнее только, там плотная бумага).
Регламенты проектной деятельности можно использовать так же, но не забудьте удалить электронные первоисточники - все эти девяносто две версии с правками от процессных аналитиков, комментариями юристов и высерами дружественных подразделений.
Что, тратили по полгода на согласование тонких нюансов процедур управления изменениями со всеми заинтересованными сторонами, мучились и пыхтели? Ну и дураки. Я тоже тратил, тоже дурак. Ну ладно, ладно, мы просто шли в ногу со временем в соответствии с нашим пониманием о том, что значит "в ногу".)

Смысл остается только в управлении проектными рисками, но этим в России все равно никто никогда не занимался. Да и само управление сильно меняется - на помойку отправляются все ваши псевдоматематические модели по оценке рисков (это комплимент - у вас их все равно нет). Да какие у вас риски с недельными итерациями выпуска продукта и с релизом MVP через три месяца после старта проекта? Начальство с Мальдив вернуться не успеет, а вы уже все сделали и дальше побежали.
А, слышу голос любителей хорошей архитектуры, чтобы на века. Забудьте, все устареет сто раз пока архитектор в оленястом свитере допинает свою картинку формата A0 хотя бы до соседнего стола.
Длинные проекты останутся только в длинных коридорах, ведущих в госкабинеты, но у них там свои цели и задачи.

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

А хорошая новость в том, что менеджеры проектов никуда не денутся, куда без них.)



Тут можно подписаться на мой телеграм-канал.


promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

  • 1
Такой подход может привести к тому что: сделали, все порушили. И получается, что тогда мы переходим к вопросам управления инфраструктурой - иметь резервные варианты и планы по возврату в исходное состояние. Но это опять про риски.

Подскажите, Вы в LinkedIn присутствуете? Так сказать, чтобы поделиться статьей со ссылкой на оригинал?

Пользуются те, кто работает на иностранный рынок. Причем довольно активно

Вот не ожидал тут такое прочитать :)

Смею заметить, что agile совсем не панацея, научиться в управление проектами «по agile» - это в первую очередь научиться управлению проектами, а PMBoK давно пора рассматривать именно как свод знаний «бывает и такое», а не как рекомендацию по применению всего.

"А, слышу голос любителей хорошей архитектуры, чтобы на века. Забудьте, все устареет сто раз пока архитектор в оленястом свитере допинает свою картинку формата A0 хотя бы до соседнего стола.
Длинные проекты останутся только в длинных коридорах, ведущих в госкабинеты, но у них там свои цели и задачи. "
Не скажу за Россию, а на ридной Израильщине длинных проектов хватает и хватать будет - банки, больницы и прочие энтерпрайзы.
Да и мои проекты, которым уже лет по 12-15-18, до сих пор бегают почти без апгрейда, ибо я из "любителей хорошей архитектуры, чтобы на века" :)

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

Кто не отдаст- тот уйдет на другую работу с повышением, а разгребать последствия наймут вас.
Хотя на самом деле разгребать должны владельцы бизнеса.

С удовольствием посмотрю на AGILE, скажем, в АСУТП на АЭС.
По вебкамере с другой стороны шарика. И никаким другим образом.


Длинные проекты были, есть и будут.


И риски там могут быть разнообразные. Например, что (название страны)авиация не смогла договориться с (название страны2)авиацией - и лететь на внедрение и обучение не на чем. А поездом - больно долго.


О, только хотел про это написать, ибо работа связана с энергетикой.
Согласен, что внедрять документооборот по ГОСТ -34 или PMBOK - излишество. Но менять раз в 2 недели требования к ПО которое управляет критически важные узлы.
Кроме того, жизнь состоит не только из IT проектов. Попробуй зааджайлить проект в котором цикл производства компонентов -- 6 месяцев

И если стоящее производство стоит несколько миллионов в час, да.
А авария может стоить нескольких лет в заведениях ФСИН...


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

Не хочу занудствовать, но вы описали lean, а не Agile. В Agile вполне может существовать разработка продукта через проект, более того, scrum (основной Agile Фреймворк в данный момент) ровно под это заточен: работа над определенным scope с полноценным бюджетированием и двумя уровнями планирования + отличный механизм управления изменениями и не менее отличный механизм обеспечения обратной связи от stakeholders.
Зато как раз под lean он заточен натягиванием совы на глобус: для организации настоящей петли обратной связи нужен single piece flow и возможность реагировать без календарных границ и ритуалов «остановить спринт».


Нет уж, давайте занудствовать. Тем более я недавно сдала PSM.
Мне кажется, это вы путаете lean и scrum. Lean-это оптимизация потока создание ценности. Там, кстати, про скоуп, бюджет и продукт вообще ничего не сказано. Он не про это. lean, Kanban прекрасно работают хоть в ватерфоле, хоть в скраме.
А Скрам-это как раз работа с постоянно меняющемся бэклогом, частыми поставками и петлями обратной связи(это все церемонии, а не только демо). Инкрементально-иттерационный подход.
Про двойное планирование не поняла. Планирование там только на спринт. Работа с бэклогом ведётся постоянно. Или вы под планированием имеете ввиду дизайн продукта? А может быть вовсе Less-планирование?

Edited at 2018-02-08 04:26 pm (UTC)

Ок, PSM отличный сертификат, поздравляю.

В комментариях вы упоминаете петли обратной связи. Сама эта концепция в айти была популяризирована книгой Lean Startup и сейчас цикл гипотеза-проверка-адаптация называется lean startup cycle. Книжка, кстати, хорошая, советую.

Очень важно четко понимать, что для работы этого цикла необходимо три вещи:
1. Сформулированная гипотеза в формате «если сделать это - получится такой результат» (true/false)
2. Средства и возможности измерения (как метрики так и возможность системы предоставить изолированные от других факторов данные)
3. Возможность быстрой адаптации
Этим трём целям удовлетворяет только single piece flow, т.е. подход, в котором команда полностью завершает работу над каждым элементом, включая сбор и анализ результатов, и только после этого начинает работу над следующим элементом.

Теперь про scrum.
В scrum используется цикл Деминга (PDCA), и хотя он тоже является циклом с обратной связью, он отличается от lean startup цикла фокусом на операционной деятельности, а не на состоянии продукта. Все обязательные ритуалы scrum, кроме демо - про эффективность команды. Цикл возврата элемента в бэклог в scrum guide не прописан: он остаётся на усмотрение product owner. Более того, scrum вообще не говорит об инструментах обратной связи, кроме demo.
Scrum не является single piece flow framework на уровне продукта, потому что сама идея итеративной доставки требует job batching. Соответственно scrum не даёт никаких инструментов для изолированной поставки и быстрых изменений.
И last but not the least, в scrum нет никакой возможности изолировать состояние системы для сбора знаний: спринты идут непрерывно друг за другом.

И, кстати, о том, что scrum не предназначен для среды, где нужен lean startup cycle вам должны были рассказывать на тренинге, в части объяснений про матрицу simple/complex/complicated/chaotic (cynefin framework и Stacey matrix). LSC он для chaos, в то время как scrum - для complex и complicated.

Двойного планирования в scrum нет, есть два уровня планирования: short term (планирование итерации) и medium term (приоритизация бэклога).

Ну и да, Agile не заканчивается на scrum, элементы lean можно и нужно применять в Agile, но знать разницу между разработкой продукта и реализацией продукта очень важно.

да, вы зануда :). Не могу с вами согласиться ни про одному пункту, вы как-то неверно понимаете PDCA и церемонии скрама. В гайде чётко сказано о чём именно церемонии. Прозрачность, инспекция, адаптация. Так же не могу согласиться про предназначение lean. Ну ИТ ближе Канбан-метод Андерсона, который использует и lean и 6 сигм. И Андерсон довольно чётко говорит, про что и для чего его метод. Говорить, что это для операционной деятельности и только для сложных упорядоченных систем- не понимать суть метода. Там принципиальное отличие от скрама в эволюционности и адаптивности системы изменений.

Edited at 2018-02-08 06:35 pm (UTC)

Можете не соглашаться, но почитать lean startup и про PDCA советую. Ну и про agile за пределами scrum, чтобы потом внезапно не разочароваться:)

Вы случайно работу не ищете? Если да, есть неплохой вариант, напишите на psilonsk@gmail.com.

Весь пост можно сократить до: ничего не изменилось.

Коода слышу про аджайл, всегда ржу. И еще ни разу не было такого, чтобы смеялась напрасно.


вот интересно, куда делся охуительный журнал matilda-bella с охуительными комментариями

  • 1