Agile-методы и проектный подход – в чем разница?

Недавно вел модуль, посвященный Agile на Advanced Business Management в Стокгольмской школе экономики. И в обсуждении с участниками модуля проявилась мысль, что в рассказе про Agile-методы обязательно надо фиксировать, в чем отличия с классическим проектным подходом. Потому что проектный подход многие менеджеры изучали, и им надо понимать разницу. У меня в презентации это, конечно, было, но мало и я не делал на этом акцента. И в статьях серии «Менеджмент цифрового мира» я тоже разбирал проблемы проектного подхода, а потом, отдельно – Agile методы. Поэтому я пару недель назад я сделал выпуск на радио ТМFM об этой разнице, а сейчас публикую развернутую статью.

Вопрос о разнице между проектным подходом и Agile-методами — непростой. Потому что за 20 лет развития Agile вобрал многие практики классического менеджмента, и наоборот, классический проектный подход вобрал практики Agile, и различие стало гораздо менее отчетливым, чем в нулевых.

Но объединить их – не получилось, и PMI-институт теперь сертифицирует по Agile-методам тоже. А объединить не получилось потому, что есть принципиальные различия, и не только во внутренней конструкции, но и в представлении о контексте применения и решаемых задачах. Об этом и поговорим.

И для начала – пара примеров о том, что такое, собственно, принципиальная разница. В чем разница между роялем и скрипкой? Конечно, они совсем разные, хоть оба и музыкальные инструменты. Но у скрипки есть одна принципиальная возможность, которой нет у рояля: она может играть звуки произвольной высоты, в отличие от рояля, который настроен на фиксированные ноты. Правда, именно эту возможность при исполнении обычной музыки по нотам – не используют из-за ограничений нотной записи. А потому именно ее не часто упоминают.

Другой пример – плита, микроволновка, мультиварка. Все они готовят пищу за счет термообработки. При этом сильно по-разному устроены, и можно описывать внутреннее устройство каждой. И это устройство, естественно, определяет и возможности приготовления конкретных блюд, и используемые рецепты и время приготовления. И это – важно. Но для выбора устройства важно другое. Микроволновка греет блюда по всему объему, что делает ее незаменимой для быстрого разогрева пище. А мультиварка умеет поддерживать режим медленного кипения, обеспечивая приготовление каш, варку на пару и другие сложные процессы готовки без человеческого внимания: поставил, и через заданное время получил готовое.

Обратим внимание, что в приведенных примерах разница заключалась в некоторых комплексных внешних качествах. Которые, конечно, определяются внутренним устройством, но напрямую из него не следуют. И их надо отдельно проявлять при сравнении. Так и при сравнении Agile-методов с проектным подходом надо проявить, какие же принципиальные представления об организуемой деятельности и устройстве мира заложены в эти методы и обуславливают их различие. Потому что дальше ты смотришь, как устроена организуемая тобой деятельность с точки зрения этих представлений – и выбираешь метод.

Перед обсуждением различий стоит пару слов сказать про сам проектный подход, project management. Хотя проекты строительства соборов, зданий, мостов, кораблей реализовывались очень давно, современный проектный подход вырос вовсе не из реализации строительных проектов. Современный проектный подход появился на рубеже 1960-х и 1970-х, и в основе его лежит опыт инженерных проектов, хотя такие практики, как диаграммы Ганта или PERT были известны гораздо раньше и, естественно, были использованы. А первое руководство, PMBOK появилось вообще недавно, в 1996 и преимущественно основано на опыте IT-проектов. Потому что именно проблема низкой успешности IT-проектов была в фокусе внимания.

Отметим, что эту задачу успешно решить проектному подходу как раз не удалось, здесь он проиграл конкуренцию Agile-методам, которые тоже не дают гарантий, однако позволяют вести проекты дешевле и большими шансами на успех. Об этом есть статистика, можно посмотреть 2013 IT Project Success Rates Survey Results, 2018 IT Project Success Rates Survey Results и Standish Group 2015 Chaos Report и другие. Подробнее я писал об этом в статье Статистика успешности Agile. А теперь вернемся к вопросу различий.

Первое различие между Agile-методами и проектным подходом состоит в представлении об устройстве мира. Проектный подход исходит из того, что это устройство может быть понято могучим человеческим разумом, который, опираясь на него, построит путь, гарантированно или с высокой вероятностью ведущий к цели. Конечно, на этом пути могут быть опасности и неопределенность, но ее могучий разум тоже поймет и заложит в риски проекта.

Agile-методы, наоборот, исходят из того, что модель мира не может быть построена. И, как следствие, гарантированный путь к цели не может быть намечен. Это ограничение, может не носить принципиального характера, а быть связано со временем: может, картину мира и можно построить в принципе, но это требует столько времени, что проект становится бессмысленным. Или ограничение может быть связано с динамикой изменений: мы признаем, что мир меняется так быстро, что мы не сможем поддерживать адекватную картину, а раскрыть закономерности изменений – не получится. В любом случае, следует признать невозможность построить путь к цели и потому двигаться к ней следует малыми итерациями, постоянно сверяя направление движения и оценивая приближение к ней.

На мой взгляд, именно это различное полагание об устройстве мира и представляет собой основную причину, по которой проектный подход не может полноценно включить в себя Agile-методы. Это – принципиальное различие. Agile-методы появились в 2000, и к середине нулевых их успех стал настолько масштабным, что его нельзя было игнорировать. Именно тогда начались первые попытки объединения. Сначала – в рамках разработки третьей версии SWEBOK, массива знаний по программной инженерии, которая вышла в 2004. Затем – в рамках разработки четвертой версии PMBOK, массива знаний по проектному подходу, вышедшей в 2008. Получалась эклектика. И последующие версии PMBOK не смогли решить эту проблему. Именно потому, что в ее основании лежат различные ответы на онтологический вопрос о возможности построения модели мира. Да, модель нужна частичная, того участка, который касается проекта. Но зато построить ее надо не в отдаленном светлом будущем, а во временных рамках проекта.

Перевод вопроса возможности построения модели в практическую плоскость очень важен. При этом он превращается в следующий вопрос: что быстрее и дешевле – провести исследования и построить модель, которая позволит провести проектирование пути к цели с гарантированным успехом, или сделать эксперимент на основе имеющихся сейчас знаний, принимая риски провала? В создании сложной техники ответ состоит в том, что эксперимент – дорог, новый самолет тщательно проектируют на численных моделях, так что построенный опытный образец – летает и имеет примерно предсказанные характеристики, хотя и требует доводки.

Казалось бы, в разработке софта эксперимент тоже дорог, разработчики пишут код, тестировщики его проверяют, а потом оказывается, что сделано совсем не то. Но это – неверная параллель. На самом деле, написание кода – это не производство опытного образца, это такое низкоуровневое проектирование. А то, что для самолетов делает производство, в IT делает среда разработки по кнопке «собрать проект» и вот этот эксперимент – дешев. И дешевый эксперимент как раз вызвал совсем другой подход к разработке софта, массовое производство образцов с ошибками и их отладку. Это было выяснено давно, есть статья Джека Ривза (Jack W. Reeves) 1992 года «What is software design» (перевод), где все подробно разобрано. Поэтому вместо тщательного проектирования в IT – многочисленные эксперименты. Так дешевле.

Это тоже принципиальное различие. Когда в классический проектный подход добавляют итерации, то каждая из них представляет собой такой мини-проект, с планированием и достаточно гарантированным исполнением плана. В Agile-методах, наоборот, итерация представляет собой эксперимент, результаты которого не слишком жалко выбросить. Конечно, это будет замедление, но идти не туда 2 недели гораздо легче, чем идти не туда полгода или год и обнаружить, что мы зашли в неверную сторону очень далеко.

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

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

Кстати, именно такой подход к учету неопределенности в сроках начал из мира IT проникать и в классический менеджмент, в том числе в организацию работы на конвейере. Изначально в работе на конвейере человеческий фактор исключался за счет нормирования операций, которое гарантирует, что на каждом рабочем месте рабочий успеет качественно ее выполнить. Качество такого проектирования – отдельный вопрос. Например, одном из советских заводов качественная сборка автомобилей получалась при скорости конвейера в 60% от расчетной, а выше резко возрастал процент брака. А вот Тойота пошла по другому пути: увеличить скорость конвейера, предоставив при этом каждому рабочему кнопку остановке, если он не успевает завершить операцию. И оказывается, что средняя скорость при этом получается выше, не взирая на остановки. Так и в IT – мы планируем поток задач оптимистично, но учитываем, что реально выполним не все.

Разница в отношении к планам очень хорошо проявляется, когда выясняется, что разработанный софт, или маркетинговая акция не оправдывает ожидания и не позволяет решить бизнес-задачи. В классическом проектном подходе подрядчик говорит: «Конечно, печально, что это выяснилось так поздно. Но сделанное соответствует тем требованиям которые вы сами одобрили, поэтому давайте вы примете и оплатите сделанное. А потом закажете нам новый проект, мы его тоже сделаем. Мы учтем уроки, он будет существующего и через некоторое время процесс наверняка сойдется!» Если мы работаем по Agile, то для нас сотрудничество с заказчиком важнее чем следование контракту роль которую выполняет детальные требования, и готовность к изменениям важнее следования плану. Поэтому в тот момент, когда на очередном демо выясняется, что результат не соответствует ожиданиям и не позволяет решить возложенные бизнес-задачу, то заказчик с подрядчиком садятся и пытаются найти решение в сложившейся ситуации, которая даст выгоду обоим сторонам, или, в крайнем случае, минимизирует потери. Деньги при этом тоже учитываются, но они становятся ограничением: ведь если подрядчик обанкротится, то он точно не сможет решить бизнес-задачу.

Вопрос обеспечения адекватной обратной связи по результатам очередной итерации необходимо рассмотреть отдельно. Дело в том, что для получения обратной связи в рамках итерации не просто должен быть выполнен определенный объем работ, а должно быть создано ценность для конечного потребителя. В IT это называется «выделить MVP», minimum viable product. И это кардинально изменило подходы к работе с требованиями, проектированию и планированию этапов проекта. Потому что в классике сначала проектировали структуры данных – целиком, по площади, делали справочники – они ведь являются основой, а потом добирались до документов, которые тоже делали последовательно, по типам, например, сначала договора, потом движение товаров, потом – платежную часть. А если мы хотим принести пользователям ценный продукт, то мы должны действовать совершенно не так, мы должны сделать поддержку какого-то целостного процесса, а для этого – реализовать кусочки из самых разных частей системы, и уложить это в один-два спринта. В работе с требованиями это породило подход user story, который позволяет мелкую нарезку и который пришел на смену комплексному проектированию системы. А в реализации – разработку почти на живую нитку с постоянным рефакторингом и проблемы с архитектурой. Это – накладные расходы, но без этого адекватную обратную связь получить невозможно, и велик риск долго идти не в ту сторону.

Аналогично надо разрабатывать новые продукты, постоянно проверяя то, что получается. Это – сложно, а в каких-то случаях наверняка невозможно. Но в IT такие изменения тоже представлялись невозможными или слишком дорогими, а их удалось сделать. Получается и в других отраслях. Концерн Калашникова и Северсталь применяют Agile-методы при разработке нового оружия и материалов, и у них получается сделать MVP за спринт, а преимуществом как раз является ранняя отсечка неверных путей. И даже такую штуку, как конференции, которая вроде как представляет собой целостный конечный продукт в IT тоже получается готовить итерациями. Программный комитет делает фрагменты программы, их апробируют на целевой аудитории, их рекламируют и продвигают в сообществе, и это дает обратную связь. Конечно, она – фрагментарная и не целостная, и какой получится конференция в целом – неизвестно, но, с другой стороны определенные провалы и конкретные перспективы часто можно увидеть на ранних этапах.

Необходимо отдельно отметить, что разработка через эксперименты позволяет использовать незрелые технологии. Есть такая шкала – Technology rediness level (TRL), разработанная NASA для оценки технологий, закладываемых при проектировании космических кораблей. Когда Боинг проектирует новый самолет, то разрешается закладывать технологии со зрелостью не ниже 8 из 10, и именно это позволяет Боингу контрактовать самолеты на стадии детального проектирования. Если же мы посмотрим на современную IT-разработку, то там активно используются технологии уровня 4-5. И не из-за тяги к новизне и риску, а потому, что более зрелых технологий, для мобильной разработки просто не успевает появиться – железо развивается очень быстро.

Таким образом, IT-разработка принципиально лежит в зоне высокой неопределенностью. И именно поэтому классический проектный подход в ней не работает, несмотря на все предпринятые усилия. У меня об этом была отдельная статья «Развитие и провал регулярного менеджмента в IT».

И так же обстоит дело не только в IT. Это можно наблюдать для любых социальных систем, например, в маркетинге или при создании новых продуктов. Потому что надежной модели человека – нет. Была версия, что люди принимают решения рационально, на этом базировалась экономика. Но многие исследования, включая эксперименты Даниэля Канемана, за которые он получил Нобелевскую премию, показывают, что это не так. Впрочем, экономисты все равно не могли отказаться оснований своей науки, а просто объявили, что изучают модели, основанные на абстракции homo economicus, принимающем рациональные решения. Конечно, физики тоже работают с абстракциями, такими как материальная точка. Отличие в том, что материальная точка во многих случаях хорошо описывает поведение реальных физических тел, а вот homo economicus поведение реальных людей не описывает. Подобно этому многие руководители разработки в IT успешно игнорируют результаты Ривза о том, что кодирование представляет собой низкоуровневое проектирование, и потому результат разработки по проекту не гарантирован.

И тут мы еще не учитываем, что результат разработки, софт, важен не сам по себе, а будучи встроенным в социальную систему – в бизнес или потребительский рынок, которая при этом изменяется с высокой динамикой. При этом встройка софта еще и изменяет эту систему, заранее изучить ее просто невозможно, ее не существует. Это уместно проиллюстрировать парой примеров из моей практики. Первый из логистики. В свое время компания Спортмастер, сделав очередной заказ товара на сезон с учетом предполагаемого роста сети, обнаружила, что существующая технология работы склада не позволяет обработать входящий поток товара с нужной скоростью. Было придумано решение – оперативная сортировка поступившего товара на несколько складов, каждый из которых будет снабжать свои каналы сбыта, без вскрытия коробов и с приемкой уже на складах назначения. Для поддержки нужен был софт, который позволит грузчикам на складе оперативно такое деление провести с приемлемым качеством в режиме 24*7. При этом невозможно было заранее исследовать бизнес-процесс – его просто не существовало на момент постановки задачи, его создавали вместе с софтом, который являлся его основой.

Другой пример – из работы Банка России. В острой фазе финансового кризиса 2008 для обеспечения ликвидности был придуман механизм кредитов без обеспечения. И, естественно, потребовалось оперативно, то есть за неделю-другую создать систему, которая бы обеспечивала банкам доступ к этим кредитам. Опять-тки, никакого бизнес-процесса на входе не было, его создавали и адаптировали к реальным условиям и меняющейся ситуации одновременно с системой.

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

Обобщая все, сказанное ранее про неопределенность и отсутствие гарантий результата, уместно вспомнить Кеневин-фреймворк (Cynefin framework). Он разграничивает простую и сложную области, в которых устройство мира могучий человеческий разум может понять, построить модель и реалистичный план действий, от запутанной области и области хаоса, в которых реалистичный план действий построить невозможно, и надо действовать иначе, через эксперименты.

Подробный рассказ про Кеневин-фреймворк требует отдельной статьи, и, наверное, я напишу ее в будущем, а пока хочу дать ссылку на свою статью «Место Agile-команд в компании», где я немного его разбираю. А здесь отмечу, что проектный подход как раз полагает устройство мира известным, и именно на этом основано планирование проекта. А Agile-методы работают там, где модель отсутствует, и это – еще одна грань отличий.

Основная практическая проблема, которую вскрывает Кеневин-фреймворк состоит в том, что человеку легко ошибиться и принять запутанную область за сложную: мы видим отдельные объекты, понимаем их устройство, и нам кажется, что еще немного – и мы построим комплексную модель. А оказывается, что объектов так много, а связи между ними столь сложны, что построить модель не получается.

История развития менеджмента в IT дает яркий пример такого заблуждения – RUP, Rational Unify Process. Неопределенность в проектах IT-разработки и ключевая роль человеческого фактора в успехе, которые делают неприменимыми классический менеджмент, были уже осознаны. Но все равно, в компании Rational были собраны четверо гуру и большая команда, чтобы создать метод ведения проектов, гарантирующий успех. Попытка провалилась, получился очень сложный фреймворк, который практически невозможно применить. Но именно RUP dj многом лег в основу PMBOK. Отметим, что помимо RUP теми же авторами был создан UML, который до сих пор является мощным средством визуального проектирования – команда была реально сильной. Совсем недавно аналогичным образом и, частично, с участием тех авторов был создан Agile-фреймворк SAFe, который тоже претендует на исчерпывающую модель менеджмента. Он, безусловно, лучше классического проектного управления, поскольку в его основе, наряду с практиками Agile, лежит концепция цепочек создания ценности. Но гарантий все равно дать не может.

Кстати, о концепте цепочек создания ценности. Строго говоря, он не относится ни к Agile-методам, ни к классическому менеджменту. Он пришел из системы Тойоты вместе с Lean. Идея состоит в том, что нам не просто надо создать некоторый продукт, надо чтобы этот продукт удобно решал проблему потребителя. Естественно, мы его для решения этой проблемы придумывали, но вовсе не факт, что он будет решать ее хорошо. Это известно всем, кто смотрел, например, мобильные приложения – для любой цели в Apple Store или Google Play их существует множество, и только несколько являются популярными и хорошо решают задачу, приносят ценность потребителям.

Аналогичная ситуация и с другими результатами проекта. Например, результатом проекта создания бизнес-центра или торгового центра является вовсе не его строительство и сдача в эксплуатацию. Для инвестора результатом является сдача площадей центра в аренду по ценам, обеспечивающим возврат инвестиций. А для города – решение инфраструктурных проблем в конкретном месте и появление точки роста. И то и другое в классическом проектном подходе находится за рамками проекта, относится к области программы. А внутри проекта мы имеем лишь выполнение определенных работ. У меня об этом была статья «Проекты – для достижения результата, а не для освоения бюджета» для профильного журнала «Управление проектами» и те, кто его оценивал согласились, что проблема – в методологии, а не в конкретном применении.

Концепт цепочек создания ценности вместе с Lean был переосмыслен для IT-менеджмента и вошел во многие Agile-практики и методы. В частности, sprint review или демо в Scrum должен оценить именно пригодность для решений задач бизнеса или проблем пользователей того, что создано в итерации, а не просто показать, что сделано. И в ряде случаев это требует специальной организации, потому что не всегда есть люди, которые могут оценить это в ходе демонстрации, и не всегда их можно позвать на демо. А без этого обратная связь оказывается фиктивной и не достигает цели. Углубляться в это я не буду, у меня были отдельные статьи «Завершение спринта в Scrum — демо и ретро» и «Kanban и Lean — эволюция вместо революции».

Отмечу, кстати, что Lean и система Тойоты не была взята в IT механически. Если слушаешь консультантов по промышленному Lean и Lean в IT, кажется, что речь идет о сильно разных подходах. И это – не случайно. Дело в том, что изначально они ориентированы на организацию физического труда, а в IT мы имеем дело с творческим, интеллектуальным трудом. И это накладывает свои особенности, например, лишняя работа, muda для умственного труда имеет свою классификацию. Отметим, что хотя проектный подход тоже разрабатывали для ведения IT-проектов, то есть для организации умственного труда, практики организации физического труда или, во всяком случае, хорошо нормируемого труда, брали из регулярного менеджмента гораздо менее критично, не учитывая этого различия.

Вернемся к Кеневин-фреймворку. Сложность конкретной области, конкретного проекта квалифицируется как относительно достижений человечества в целом, так и относительно команды, которая в ней работает. То, что для команды junior-сотрудников лежит в сложной или запутанной области, для опытной команды является простым, просто потому, что им не известны соответствующие модели. Понятно, что можно научиться, но это требует отдельного времени. Можно так же позвать экспертов, если они доступны. И проектный подход как раз требует, чтобы это было сделано, во всех руководствах написано, что необходимым требованием для успеха является компетентная команда. А вот для Agile-методов это является не обязательным. Более того, успех Agile во многом связан с тем, что он решил проблему дефицита разработчиков, возникшую с появлением персоналок. Компьютеры стали доступны мелкому и среднему бизнесу, и сразу потребовалось множество систем для их автоматизации, а количество разработчиков – не увеличилось. На постсоветском пространстве проблема была решена за счет того, что тога развалилась оборонка и множество инженеров пошло в IT, на на западе такого резерва не было, и проблему решило появления Scrum.

Отмечу, что сейчас из-за бурного развития технологий и дефицитного рынка персонала отсутствие компетентной команды становится нормой, а не исключением. Квалифицированные специалисты идут в проекты с новыми технологиями, в которых компетентных людей нет в принципе, и поэтому освоенными технологиями занимаются молодые, которые опыта еще не приобрели. Об этом у меня тоже была отдельная статья «Реальность цифрового мира: проекты делает некомпетентная команда».

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

Естественно, фокус на достижении бизнес-цели является не частью процесса, частью корпоративной культуры. Если Agile-методы реализуются в культуре, в которой принято делить ответственность и не брать чужую работу, а, может, и акцентировать внимание, подставлять тех, кто не справляется, то этот потенциал не будет реализован, а статус-митинги превратятся в выяснение, кто виноват. Эта опасность – известна, тем более что поиск виноватых является достаточно привычным поведением, поэтому при внедрении это поведение требует изменения.

И в заключении я хочу привести метафору, которая у меня родилась на сопоставлении японской системы менеджмента с западной на одной из IT-конференций, где одновременно были специалисты из Японии, Европы и Израиля и была развернутая дискуссия между ними. Японская система менеджмента в целом значительно ориентирована на работу в изменяющемся мире, и этим она схожа с Agile-методами, которые много почерпнули из Lean и системы Тойоты в целом. Я тогда написал статью «Запад и Япония: два взгляда на бизнес-процессы», где и появилось сравнение, которое я хочу привести.

Проектный подход ориентирован на путешествие по цивилизованным местам с дорогами и картами, а Agile-методы – на путь по слабо известным землям без хорошей карты. Хотя в замысле было не так, он проектный подход должен был обеспечить путешествие по неизведанным местам, а не только по цивилизации.

В заключении я хочу подчеркнуть, что различия, о которых я говорил – методологические, они – в идеальной картине, а не в ее реализации. Реализация может быть разной. Многие различия касаются не организации процессов, а ценностей и культуры. И опытные Agile-коучи приносят эту культуру, часто даже не всегда осознавая отличия. Это видно и по их выступлениям, и по разбору конкретных кейсов на конференциях. Но очень часто Agile- процессы пробуют взять без этой культурной составляющей, сохраняя существующую корпоративную культуру. И тогда заложенный в методологию потенциал теряется, проект не решает бизнес-задачи, а лишь осваивает объем работ, сотрудничество с заказчиком отсутствует, участники проекта не работают на достижение целей, а выполняют обязанности и требуют полной определенности в постановке задачи, изменения не принимаются, и так далее. Но в проектном подходе этот потенциал отсутствует в самом начале, по построению. При этом опытные руководители проектов, естественно, могут его приносить и реализовывать проекты на человеческом факторе, не взирая на методологические проблемы.

Таким образом, если у Вас есть руководитель проекта, которому вы доверяете, и который берет ответственность, то выбор конкретной методологии – за ним. А вот если его нет, то Agile-методы имеют потенциал, описанный в статье, и дальше вопрос выбора должен опираться на то, насколько этот потенциал нужен в вашем проекте и насколько совместимо ли использование Agile-методов с корпоративной культурой.

На этом я завершаю статью. Это было продолжение серии статей «Менеджмент цифрового мира», полное оглавление серии – на моем сайте https://mtsepkov.org/NewMngSeries