Scrum появился осенью 1995 года и по сей день остается самым популярным Agile фреймворком разработки программного обеспечения. Первое руководство по Scrum уже в 2001 году включало всё то, с чем сталкивались большинство из нас: распределение по ролям, артефакты и церемонии (планирование спринта, стенд-ап, демо и ретроспективы). Концепция уточнялась, но это был всё тот же Scrum, с которым в том или ином виде работал практически каждый в IT хотя бы немного.
В это же время в технологическом плане был сделан гигантский скачок: десятки фронт и бэкенд фреймворков, определивших вид современного интернета, появились и стали неотъемлемый частью нашей жизни мобильные телефоны и приложения для них, облачные технологии, блокчейн, AI и IoT. Технологии развились настолько, что позволяют миллиардам людей получать доступ к практически любой информации и сервисам в любой точке мира.
Однако в сфере проектных подходов и Scrum в частности нет даже сотой доли этого прогресса, они остались практически неизменны, хотя есть явная неудовлетворенность итоговыми результатами, как и у бизнеса, так и у непосредственных исполнителей. Как же так вышло и что с этим делать?
Второй игрок в подходах к разработке
Помимо легких подходов вроде Scrum и Kanban существуют и тяжелые проектные подходы, они появились в большинстве своем раньше гибких:
1975 – был организован институт PMI (Project Management Institute) в США. Именно они издают PMBoK (с 1996 года) – справочник для менеджеров проектов. Это самый популярный стандарт для проектного управления во всем мире, буду говорить именно о нём далее по тексту.
1989 – был организован стандарт из Великобритании PRINCE2.
1996 – Microsoft и IBM сформировали подходы RUP.
Все эти стандарты представляют описание последовательных процессов разработки и реализации проекта, направленных на то, чтобы удержать его в треугольнике “сроки - бюджет - содержание”. Родились они из личного опыта и практики родоначальников стандартов, которые попытались систематизировать те подходы и решения, которые хорошо работали в их проектах и передать знания другим менеджерам.
Их называют тяжелыми проектными подходами потому, что они более формализованы и подробно описаны, больше уделяют внимание практическим методам и процессам, чем общему подходу и философии. Достаточно сравнить объемы изданий на английском языке: Scrum руководство в 14 страниц и PMBoK 7-ой редакции на 370 страницах. Я не буду подробно останавливаться на их принципиальных различиях, но нельзя не отметить, что семейство Agile фреймворков и тяжелые подходы находились в тесной связи долгие годы и влияли друг на друга и на то, как разрабатывались проекты и продукты в сфере ПО.
Концепция, отраженная в PMBoK от PMI не стояла на месте как и Scrum, на сегодняшний момент доступна 7 редакция. Однако по существу мало что изменилось, но, например, в PMBoK впервые описал гибкие методологии разработки Scrum и Kanban в 5 редакции в 2013 году как о возможной опции, полноценно включил практики уже в 6 редакции с расширенными рекомендациями по использованию.
Пара слов о ПО для проектного управления
В этой сфере прогресс ощутим и заметен, однако в нём не так много золотых стандартов, которые используют все, таких, например, как система контроля версий Git при разработке ПО. Появился Git, кстати, в 2005 году, а его предшественник SVN в 2000, я даже застал работающие проекты на SVN, хотя я не такой уж старый.
Задачи вместо физических досок ведут в таск-трекерах, документацию хранят в вики и правят совместно в режиме реального времени. Для упрощения построения планов и планирования ресурсов используют ПО для построением диаграммы Ганта, это позволяет удобно следить за ходом проекта, отмечая отклонения.
Среди программного обеспечения высокая конкуренция: лучшие UI/UX специалисты бьются за каждый пиксель интерфейсов, а разработчики за каждую миллисекунду быстродействия (или нет, но я пользуюсь облачной Jira, возможно в этом проблема). Последний тренд – использование AI для утилитарных нужд руководителя проектов: записать встречу и подвести итоги в письменном виде, генерация и накидывание идей, накидывания шаблонов документов по планированию рисков и т.д.
Мы все немного ретрограды, когда дело касается процессов
Потребность в выполнении задач бизнеса для зарабатывания денег огромная, крупные сервисы сражаются за увеличение конверсии в 0,001%, что выражается в миллионные прибыли. Спрос на увеличение эффективности продуктов и проектов есть, но ни Scrum/Kanban, ни классические проектные подходы не предлагают за годы кардинальных и радикальных изменений в себе, чтобы это обеспечить. В чем же причина?
Потому что Agile и классические проектные подходы это воплощение базовых принципов для решения задач. Человеческий мозг – одна из самых сложных вещей во Вселенной, а управляя проектами, мы имеем дело с десятками уникальных мозгов других людей, взаимодействием между ними и гнетущей неопределенностью.
Эти факторы формируют два ключевых подхода:
Тяжелые методологии хороши, когда мы примерно представляем, что хотим получить. Например, нам нужен сайт, мы уже делали сайты, но нужно определиться, каким он должен быть. В этом случае мы собираем требования, пишем документацию, определяем состав работ, бюджет и оцениваем сроки. Разработка может осуществляться с помощью спринтов Scrum или Kanban доски, суть подхода: стремление учесть максимальное количество деталей до начала разработки с помощью проектных инструментов и методик.
Гибкие методологии исходят из предпосылки, что невозможно предусмотреть всё и нет смысла долго проектировать и планировать, а истину лучше искать в процессе. В частности, Scrum хорош, когда у нас есть нечеткая цель и мы не знаем в какой форме она может быть решена. Представим, что мы разрабатываем приложение для фитнеса. Мы знаем, что пользователи хотят следить за своим прогрессом, но не понимаем, как именно они предпочли бы это делать – через графики, тексты или подсказки. Вместо того чтобы тратить месяцы на создание окончательной версии приложения, мы начинаем с простого прототипа, получаем обратную связь от пользователей, тестируем разные подходы и постепенно улучшаем его.
Обращу внимание, что ни один из подходов не имеет ультимативных преимуществ перед другим, и у каждого есть свой набор недостатков и ограничений. Думаю, каждый бывалый ITшник может вспомнить пример пары провальных проектов с применением каждой методологии, а то и не пару, а десяток-другой.
Хотя подходы к разработке существенно не изменяются уже много лет, у меня есть надежда, что в следующие лет 20 появится новая методология. Как это будет работать пока до конца непонятно, но ключевая задача состоит в том, чтобы по-новому взглянуть на неопределенность, двигаться сразу в нескольких направлениях для ее уменьшения, учитывать множество вариантов и быстро принимать решения по устранению проблем. Да, я знаю, больше похоже на фантастику, но у каждого должны быть свои мечты :)
Не забывайте о людях
Любая разработка ПО предполагает оперирование базовыми вещами: содержанием, сроками, бюджетом, людьми и взаимоотношениями между ними. И именно люди главный враг человечества в проектных подходах после неопределенности.
Это сами люди: мы несовершенны, сложны, непознаваемы полностью даже самими собой, по-разному мыслим, справляемся с конфликтами и проблемами, можем иметь личные интересы, противоречащие интересам других людей и команды. Иногда мы проявляем не лучшие наши черты: глупость, жадность, нерешительность, некомпетентность, лень. Всё вышеперечисленное без малейшего осуждения – это просто данность, с которой мы живем и взаимодействуем каждый день.
Мы встречаем много людей на протяжении нашей IT жизни, классический конфликт “плохой проджект - плохой разработчик” уже набил оскомину и никогда полностью его не искоренить. Но хочу дать вам напутствие: цените коллег, которые бок о бок с вами сражаются с неопределенностью и особенно тех, кто греет вам душу, а не задницу. В следующий раз на очном дейли митинге обнимите проджекта или разработчика, которого цените и скажите ему: “Я хочу провести следующие тысячу митингов с тобой!” :)
Комментарии (6)
dplsoft
16.10.2024 07:48вы, меня, "конечно извините" за то что сейчас скажу, но информация в статье... ну не знаю... скажем так... ложна. ?...
Сначала про даты и хронологию. они не верны.
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. Там вам систематизированные сведения дадут не только об истории? но и текущем состоянии вопроса. И да будет всем счастье и не будет таких статей.
Извините если обидел.
dplsoft
16.10.2024 07:48пара "уточнений опосля":
RUP - это именно методология - это методика создания методики управления проектом
Тут важно уточнить что не "проектом вообще", а "процессами разработки ПО" - которые являются частью процессов проекта. Можно было бы сказать что "проектом разработки ПО", но тогда придется выкинуть "за скобки" кучу процессов, типа взаимоотношения с клиентами или управление договорами и пр. Какое-нибудь "управление портфелями проектов" - так и вообще штука из "перпендикулярной реальности" по отношению к этому. Потому всё же "процессов разработки ПО".
ICB, NCB, PMBoK - это именно свод знаний и систематизация всех вариантов
ICB и NCB - всё же не свод знаний в том виде как это дает PMBoK (поправьте меня?).
ICB и NCB - это перечень требований о том, что должен знать и уметь специалист по управлению проектами.Сами знания - они во вне - в "окружающих источниках" (читайте книги, разные) а умения - достигаются на практике.
Добавлю что экзамен в IPMA - длится от 1 до 3-х дней на разные ступени. Письменный 4-х часовой экзамен с открытыми вопросами в первый день (для младшей ступени этого достаточно). Имитационная игра во второй, и собеседование (на английском, французском или кажется немецком?) в третий день.
Alex_Skosyrev Автор
16.10.2024 07:48Спасибо за подробный и полезный комментарий!
Действительно, надо было лучше разобраться: и в хронологии, и в определениях, чтобы всё было чётко. В следующий раз подготовлюсь лучше.
Искреннее уважение к вам за то, что так подробно разобрали статью!
mtryakin
Спасибо за статью!
PMBoK - это энциклопедия с описание методов проектного управления. Нельзя управлять проектом по пмбоку. Это как изучать русский язык по словарю.
Насчет "новых подходов". Вы можете что-то предложить, что будет лучше итарационной работы с проверкой? Какую работу или вид работ неспособны закрыть существующие подходы?
Alex_Skosyrev Автор
Спасибо за отклик!
По PMBoK – да, всё верно, я и отразил, что это справочник.
Как я и писал в статье, у меня нет готового полноценного ответа. Если бы мне предложили написать фантастический роман о проектном управлении, в котором была бы такая система, то я думал больше в сторону противодействия разрастания содержания проекта.
Например, система внутри крупной компании с ИИ, которая обучена на тысячи их проектах с указанием хронологии проекта, принятых решениях и итоговой стоимости, сроках и конечном эффекте – показателях. А также загруженные данные о всех участниках проекта, причем как исполнителей, так и заказчиков и заинтересованных лиц с расчетом синтетической оценки правильности принятых решений.
При каждом изменении содержании проекта по инициативе исполнителей, заказчиков или заинтересованных лиц, то это изменение проходило бы через систему ИИ и выдавало бы вердикт-рекомендацию по внесению данного изменения. Уровня "этот маневр будет стоить нам 51 год с вероятностью в 80%" или что-то вроде того :)
Если изменение имеет высокие риски для проекта и скорее приведет к проблемам, то данное изменение подтверждается только руководителем инициатора изменения и руководителем проекта совместно. Если решение принято, то система визирует изменение, вносит его в проект и формирует риск-план с указанием конкретным исполнителям/заказчикам что нужно сделать, чтобы это изменение прошло с наибольшей эффективностью (например, что заказчик должен уточнить требования за какой-то срок).
В общем, как видно, романист из меня не очень, но пока какой-то такой взгляд на грядущее будущее.
Alex_Skosyrev Автор
Понял, что возможно ответил не совсем корректно на вопросы. Отвечу отдельно.
Как я и изложил в статье, я считаю что текущие подходы и не изменяются, потому что они с лихвой закрывают текущие потребности, они не идеальны, но позволяют достигнуть результата в текущих условиях.
Главный вопрос: а что нужно добавить в классический проектный или гибкие проектные подходы, чтобы увеличить их эффективность?
Вот тут у меня и нет простого ответа, потому что у нас есть те проблемы (неопределенность и сами люди) и как сделать так, чтобы универсально для всех повысить количество успешно закрытых проектов на 1% я не знаю. Но мне было бы очень интересно пообщаться с коллегами на эту тему, поэтому и написал эту статью, узнать их мнение.