Comments 9
Спасибо за статью!
PMBoK - это энциклопедия с описание методов проектного управления. Нельзя управлять проектом по пмбоку. Это как изучать русский язык по словарю.
Насчет "новых подходов". Вы можете что-то предложить, что будет лучше итарационной работы с проверкой? Какую работу или вид работ неспособны закрыть существующие подходы?
Спасибо за отклик!
По PMBoK – да, всё верно, я и отразил, что это справочник.
Насчет "новых подходов". Вы можете что-то предложить, что будет лучше итарационной работы с проверкой? Какую работу или вид работ неспособны закрыть существующие подходы?
Как я и писал в статье, у меня нет готового полноценного ответа. Если бы мне предложили написать фантастический роман о проектном управлении, в котором была бы такая система, то я думал больше в сторону противодействия разрастания содержания проекта.
Например, система внутри крупной компании с ИИ, которая обучена на тысячи их проектах с указанием хронологии проекта, принятых решениях и итоговой стоимости, сроках и конечном эффекте – показателях. А также загруженные данные о всех участниках проекта, причем как исполнителей, так и заказчиков и заинтересованных лиц с расчетом синтетической оценки правильности принятых решений.
При каждом изменении содержании проекта по инициативе исполнителей, заказчиков или заинтересованных лиц, то это изменение проходило бы через систему ИИ и выдавало бы вердикт-рекомендацию по внесению данного изменения. Уровня "этот маневр будет стоить нам 51 год с вероятностью в 80%" или что-то вроде того :)
Если изменение имеет высокие риски для проекта и скорее приведет к проблемам, то данное изменение подтверждается только руководителем инициатора изменения и руководителем проекта совместно. Если решение принято, то система визирует изменение, вносит его в проект и формирует риск-план с указанием конкретным исполнителям/заказчикам что нужно сделать, чтобы это изменение прошло с наибольшей эффективностью (например, что заказчик должен уточнить требования за какой-то срок).
В общем, как видно, романист из меня не очень, но пока какой-то такой взгляд на грядущее будущее.
Вы можете что-то предложить, что будет лучше итарационной работы с проверкой? Какую работу или вид работ неспособны закрыть существующие подходы?
Понял, что возможно ответил не совсем корректно на вопросы. Отвечу отдельно.
Как я и изложил в статье, я считаю что текущие подходы и не изменяются, потому что они с лихвой закрывают текущие потребности, они не идеальны, но позволяют достигнуть результата в текущих условиях.
Главный вопрос: а что нужно добавить в классический проектный или гибкие проектные подходы, чтобы увеличить их эффективность?
Вот тут у меня и нет простого ответа, потому что у нас есть те проблемы (неопределенность и сами люди) и как сделать так, чтобы универсально для всех повысить количество успешно закрытых проектов на 1% я не знаю. Но мне было бы очень интересно пообщаться с коллегами на эту тему, поэтому и написал эту статью, узнать их мнение.
вы, меня, "конечно извините" за то что сейчас скажу, но информация в статье... ну не знаю... скажем так... ложна. ?...
Сначала про даты и хронологию. они не верны.
1965год. начинается история международной ассоциации управления проектами - IPMA. International Project Management Association. Веха из разряда "слона то я и не приметил".
1969 год. начинается история PMI. Project Management Institute. Как человек, "сдавший экзамены IPMA", обязательно упомяну, что это американская организация, которая начала заявлять о себе как о "международной" много позже.
Про PRINCE2 много не скажу, кроме того, что таких национальных стандартов и подходов по управлению проектами наподобии "принца" - пред пруди было в истории. И европейских, и советских и американских, Захотите, вытащу Совнетовские конспекты и дам вам развернутую справку.
А кучка российских гостов? и я не только про 34-ю и 19-ю серию, всем набившую оскомину, но и про кучку всяких "ИСО МЭК" по управлению проектами и просто по менеджменту и процессам.
Теперь про "некорректные противопоставления".
Ставить в один ряд "конкретный подход", и базы знаний по управлению проектами... - это даже не теплое с мягким. Это мешать "котлеты", "мухи", и... "красное". добавив, что "в противовес им есть "холодное".
Тот же Prince2, Scrum, Agile, экстремальное программирование,(про RUP отдельно, потому что это методология по управлению проектами) - это конкретные методики и подходы.
В отличии от них - выпускаемые IPMA и PMI материалы - IPMA ICB (международные требования к компетенции), IPMA NCB (национальные требования к компетенции) и PMI PMBoK (книга знаний по управлению проектами) не содержат конкретных указаний "как надо" - они включают в себя и систематизируют накопленные сведения о разных методиках, подходах, инструментах и знаниях по управлению проектами. И водопад, и итеративный подход, и спирали, и четкое планирование, и адаптивное когда детализируемя по ходу развития истории - это всё там есть. Как конкретные примеры и знания о том, что так можно делать.
Прочитайте хотя бы "Руководство по проектному управлению" Родни Тернера и узнайте про "планирование по вехам" и "планирование набегающей волной" и и поймите что "итеративный подход" - это ... "частный случай" из кучи промежуточных вариантов организации процессов от жесткого планирования, до гибкого адаптивного процесса.
ICB, NCB, PMBoK - это именно свод знаний и систематизация всех вариантов - и больших тяжеловесных и маленьких легковесных, иногда с описанием того где какие методы хорошо подходят.
Кстати, смею сказать что "кибернетический подход" взятый в IPMA - имхо -более адекватен и системен чем древовидная структура процессов и подпроцессов PMI. И на экзаменах IPMA (взять тот же письменный экзамен) - оцениваются и качества менеджера - например риторика и умение излагать мысли на бумаге. Чего невозможно достичь крыженеием галочек в на тесте по PMI.
Теперь про RUP.
Ну какой нафиг IBM и Майкрософт?! Что за бред, извините меня ? Компания Rational начала выпускать свою унифицированную методологию по управлению программным проектом задолго до того как их купил IBM. А о майкрософте вообще речи нет.
И , RUP - это именно методология - это методика создания методики управления проектом. Это большой систематизированный шведский стол инструментов , "Процессный Фреймворк" в котором вы выстраиваете тот вариант процесса который вам нужен именно на этом проекте. можно построить, и главное - дать описание команде процесса, и что то неформальное легковесное с требованиями на салфесках, или какой нибудь аналог "extrim prigramming". А можно сделать тяжеловесное, с утверждением и согласованием каждого артефакта, трассировкой требований от фичи до теста и программного модуля.
А вы назвали это фактически тяжеловесным подходом и противопоставили какому то скруму.
Да как так то ?!
В общем отвечая на заголовок вашей статьи : всё с этим вопросом нормально.
Это, простите, "просто вы не в курсе".
Идите, пожалуйста, для начала - читайте по программной разработке RUP (причем желательно 6й руп, до того как его испортила IBM. можно ещё OpenUP почитать что бы увидеть как в RUP можно описать и вариант процесса по 34-му ГОСТ, и Agile - используя один и тот же подход к описанию процессов, в одном типе диаграмм), а по управлению проектами - упомянутую выше книгу Дж Родни Тернера "Руководство по проектному управлению".
После, желательно, пройдите курсы по управлению проектами в Совнете - национальной организации IPMA, разрабатывающей наш, российский NCB. Там вам систематизированные сведения дадут не только об истории? но и текущем состоянии вопроса. И да будет всем счастье и не будет таких статей.
Извините если обидел.
пара "уточнений опосля":
RUP - это именно методология - это методика создания методики управления проектом
Тут важно уточнить что не "проектом вообще", а "процессами разработки ПО" - которые являются частью процессов проекта. Можно было бы сказать что "проектом разработки ПО", но тогда придется выкинуть "за скобки" кучу процессов, типа взаимоотношения с клиентами или управление договорами и пр. Какое-нибудь "управление портфелями проектов" - так и вообще штука из "перпендикулярной реальности" по отношению к этому. Потому всё же "процессов разработки ПО".
ICB, NCB, PMBoK - это именно свод знаний и систематизация всех вариантов
ICB и NCB - всё же не свод знаний в том виде как это дает PMBoK (поправьте меня?).
ICB и NCB - это перечень требований о том, что должен знать и уметь специалист по управлению проектами.
Сами знания - они во вне - в "окружающих источниках" (читайте книги, разные) а умения - достигаются на практике.
Добавлю что экзамен в IPMA - длится от 1 до 3-х дней на разные ступени. Письменный 4-х часовой экзамен с открытыми вопросами в первый день (для младшей ступени этого достаточно). Имитационная игра во второй, и собеседование (на английском, французском или кажется немецком?) в третий день.
Спасибо за подробный и полезный комментарий!
Действительно, надо было лучше разобраться: и в хронологии, и в определениях, чтобы всё было чётко. В следующий раз подготовлюсь лучше.
Искреннее уважение к вам за то, что так подробно разобрали статью!
Простите за оффтоп, вы на каком языке сертификацию проходили? Там без английского никак? (свободного разговорного и письменного). Тоже хочу обучение пройти там.
Письменный экзамен IPMA - на русском. Совнет - национальная организация IPMA - и всё, в том числе и требования к квалификации - на русском.
Как минимум до уровня собеседования.Но "собеседование на французском" - это уже уровень A - управление международными программами. Ну и участие в этих программах на соответствующем уровне надо подтверждать, лет за 10 минимум кажется - нам с вами до этого далеко)
На уровень D - это 1 день, письменный экзамен на русском, ничего подтверждать не надо (ну может кроме условного стажа, что вы хотя-бы год или два вообще работаете и участвовали хоть в какой-то проектной деятельности - уточните текущие требования в Совнет).
_______________
Насчет крыжения галочек на тему PMI - ничего не скажу. Там, может, вопросы и на английском.
Если исходить из того что за последние 20 лет трудоемкость разработки программного обеспечения выросла в 1000 раз, то все очень даже динамично развивается. Сотни тысяч программистов годами и десятилетиями что-то ковыряют, выдумывают какие-то теории, создают какие-то проблемы и потом их решают. По итогу никто ничего уже не понимает. И при этом все неплохо зарабатывают.
И с этой точки зрения Ваша идея по-новому взглянуть на неопределенность и двигаться сразу во многих направлениях определенно имеет потенциал текущую ситуацию значительно улучшить. Если Вам удастся каким-то образом эту идею популяризовать, продвинуть в массы и монетизировать, то люди будут Вам очень багодарны. Насчет ИИ не уверен.
29 лет топтания на месте. Почему подходы к разработке ПО не развиваются?