{"id":14263,"url":"\/distributions\/14263\/click?bit=1&hash=b4dc4ce4b906960991e4705d10ce304ff5052bead202f1bda35bfb08e31596b1","title":"\u0421\u043a\u043e\u043b\u044c\u043a\u043e \u043c\u043e\u0436\u043d\u043e \u043f\u0440\u043e\u0434\u0430\u0442\u044c, \u0435\u0441\u043b\u0438 \u043f\u043e\u043a\u0440\u0430\u0441\u0438\u0442\u044c \u0433\u043b\u0430\u0432\u043d\u0443\u044e \u043a\u043d\u043e\u043f\u043a\u0443 \u0432 \u0447\u0451\u0440\u043d\u044b\u0439","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"edca0fea-02f8-5eb8-ae8c-3678b2acc040"}

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

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

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

Из моих презентаций

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Из моих презентаций

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

Проектный подход предназначен для сложной (comploicated) области, а Agile-методы работают в запутанной (complex)

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

История развития менеджмента в 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 — эволюция вместо революции».

Проектный подход ориентирован на управление выполнением работ, а Agile-методы – на создание ценности

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

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

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

Проектный подход требует компетентной команды, а Agile-методы позволяют обходиться без нее

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

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

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

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

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

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

Из моих презентаций

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

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

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

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

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

0
27 комментариев
Написать комментарий...
СлавалС

Если Agile методы про гибкий итеративный подход, то ему уже 100 лет в обед. Любой новый/эксперементальный тип устройства или изобретение чего-то принципиально нового так или иначе создается при помощи итеративности, поиск равновесия между значимыми факторами.
Если говорить проще, то синтетическая эволюция продукта обеспечиваемая людьми. А про эволюцию еще и Дарвин говорил )

Agile даже был на производстве, просто тогда больше делали, чем продавали, то как якобы надо работать.
Производство менее изменичвая среда и она материальна: "фарш невозможно провернуть назад, мясо из котлет не восстановишь". но даже и это условно, воостановление фарша стоит сильно дороже, чем присоздании ПО.

Любой новый тип устройств создавался именно при помощи agile - грамотная команда.
Сначала моделируют, потом прототипируют, потом опытный образец, опытная партия, изделия и релизы типов изделия. При этом развивается и экспертиза и окружение и оборудование.
Проект это не более чем использование накопленной экспертизы в определенной области. 
Наклепать новую форму или добавить подобную фичу - проект, потому как все или почти все известно заранее - окружение детерминированно. 
Создать новое приложение в новой сфере  - agile (прости господи) итеративный поиск какого-то решения в нетерминированной среде.

И весь этот agile можно назвать обычным русским словом  - изобретение : итеративный поиск решения в недетерминированной среде, с постепенной детерминизацией окружения, накоплением экспертизы и инструментария.

Ответить
Развернуть ветку
Максим Цепков
Автор

Agile - это набор ценностей, принципов и методов разработки, объединенный Agile-манифестом (2001) и разработанный в рамках IT-отрасли для реализации проектов в противовес проектному подходу и другим методам классического менеджмента. И он включает вполне конкретный набор методов и практик.

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

И если сравнивать с подходами по созданию сложных технических устройств или другими НИОКР, то есть явные отличия, которые хорошо видны тем, кто работал по классическим процессам, а сейчас пробует и использует Agile-методы и видит их преимущества, например, концерну Калашникова для разработки оружия, Северстали для разработки новых материалов, Росатому, который, в частности, применял его для доработки проекта АЭС в Финляндии, чтобы обеспечить требования безопасности ЕС без недопустимого увеличения стоимости (чего они не смогли добиться классическими методами). Обо все этом - есть доклады и материалы, ссылки есть в моей статье https://vc.ru/hr/101238 "Кейсы Agile-трансформации. Часть 2 — корпорации и госструктуры"

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

Ответить
Развернуть ветку
СлавалС

Agile манифест не более чем присвоение разумных и очевидных вещей. 

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

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

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

Голословное сравнение Agile vs классический подход это как анекдот про интеграл, шляпу и препода по математике.

Ответить
Развернуть ветку
Максим Цепков
Автор

Я вам сейчас ужасную вещь расскажу. Современные автомобили - это софт, миллионы строк кода, который управляет двигателем, тормозами и всем остальным, и не только когда автопарковка работает, а всегда, и когда водитель жмет на педаль тормоза, именно софт решает: тормозить двигателем или колодками. Так вот, этот софт пишут по Agile. Я еще в 2012 году слушал доклад на ReqLabs от аналитика, который работал в немецкой компании по разработке софта для автомобилей, о том, как у них там процесс устроен и работа с требованиями. При этом в Германии весь этот софт для автогигантов вынесен на субподряд, его пишут мелкие фирмы, а в автомобиле он интегрируется. Бойтесь теперь немецких автомобилей.

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

Так что мое сравнение - не голословно, а опирается на факты. А ваше отрицание - увы, нет.

Ответить
Развернуть ветку
СлавалС

Фактов я хочу добиться от вас.

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

Ответить
Развернуть ветку
Максим Цепков
Автор

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

А дальше - вопрос применения этих методов и их эффективности. Об этом - тоже есть факты в виде статистики. И в статье есть ссылки на различные отчеты, которые об этом говорят. 

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

Ответить
Развернуть ветку
Al Al

Спасибо за статью
Единственный минус - долго запрягаете
В начале статьи много воды

Ответить
Развернуть ветку
Иван Верес

Автор завязывайте с писаниной. Заголовок статьи раскрывается в 3-4 абзацах текста. А вы льете воду бесконечно. В интернете есть комедийеый ролик про группу которая решала как повесить табличку (прибить или приклеить). Вы напоминаеие этих бесполезных людей из ролика. 

Ответить
Развернуть ветку
Максим Цепков
Автор

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

Что касается содержания - то не раскрывается заголовок в 3-4 абзацах, и нет там воды. Там конкретные тезисы, подкрепленные примерами и объясняющие объясняющие, в чем именно разница. И в разных проектах разные тезисы будут играть существенную роль в выборе метода. 

Ответить
Развернуть ветку
Иван Верес

Не нравится критика - не выкладывайте писанину.

Agile это лишь дополнение к проектному методу. Причём дополнение настолько очевидное что многие его применяют не зная даже его названия.  

Ответить
Развернуть ветку
Максим Цепков
Автор

Agile - вовсе не дополнение к проектному подходу. Agile - это семейство методов, объединенных общими ценностями и принципами, которые были созданы именно потому, что проектный подход не смог обеспечить успешное ведение проектов IT-разработки: получалось не просто долго и дорого, а еще и не то, что нужно бизнесу для решения его проблем. И именно эту задачу Agile-методы решили - что обеспечило их широкое распространение, вопреки тому, что ценности и практики сильно противоречили традиционной корпоративной культуре - они основаны на инициативе сотрудников, а не на следовании регламентам и указаниям руководителей. Так что тут вы заблуждаетесь.

А критика - интересна от тех, кто владеет материалом по теме. А от тех, кто хочет заткнуть автора, обесценивая его статьи общими словами, такими как "вода" и "писанина", потому что не нравится ему то, что говорит автор, но аргументировано он спорить не может - скучна.

Ответить
Развернуть ветку
Иван Верес

Опять много букв.
Я не хочу обесценить ваш труд. В статье есть полезные вещи. 
Я по прежнему настаиваю что agile подход не является самостоятельным для большинства практических задач. Спорить и приводить аргументы не хочу. Мне кажется это очевидным, даже в вашем посте есть отсылки к этому. 
Просто пишите лаконичней и проще. Это мое пожелание от человека который узнал об agile подходе из вашего поста. Не тратьте время на мои комментарии. Просто прочитайте. 

Ответить
Развернуть ветку
Максим Цепков
Автор

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

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

Ответить
Развернуть ветку
Антон Кобельков

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

Ответить
Развернуть ветку
Антон Кобельков

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

Почему Agile имеет такой успех? Потому на заре появления информационных систем с их помощью в первую очередь решались наиболее острые проблемы. Если ни у кого на рынке информационных систем нет, то даже плохая информационная система принесет огромную выгоду, а ее устаревание не приведет к особой необходимости ее доработки. То есть, конкуренция велась на уровне самого наличия/отсутствия информационных систем. На современном рынке информационные системы есть у всех, поэтому конкуренция идет по линии эффективности их проектирования, эксплуатации и сопровождения. Поэтому сегодня проектные задачи ставятся  совершенно по другому, не так как 50 лет назад. Другая постановка задач как раз и приводит к другим формам проектного управления.

VUCA-мир – это всего лишь проявление задач нового типа. Разумеется, мы не можем выбирать систему управления проектом на основе того, что нам неизвестно, потому что мы не можем опираться на то, что мы еще не знаем. Мы точно не можем начать никакой проект, если модель мира не может быть построена. Как минимум, для постановки задачи необходимо представлять себе, как войти в контакт со стейкхолдерами, как результат проекта может с ними взаимодействовать, кто и как может создать этот результат.

Ответить
Развернуть ветку
Максим Цепков
Автор

Понимаете, специалисты по проектному управлению вовсе не хотят признавать его частным случаем Agile уже много лет. Да и по сути это не так, если взять PMBOK и, например, Scrum Guide, или описания Kanban-подхода то не сводится один к другому, все-таки это разные методы.

Та же удовлетворенность стейкхолдеров. Проектному подходу, по большому счету, на нее наплевать, это дополнительная активность, а не основная. Основная - снять ТЗ и его выполнить. А в Agile - наоборот, снять требования и их выполнить - лишь средство, чтобы обеспечить удовлетворенность стейкхолдеров. При этом выполнить можно по-разному, лучший софт - не написанный :) 

Ответить
Развернуть ветку
Антон Кобельков

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

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

Какой стейкхолдер согласится на методологию, при которой его потребности заведомо не удовлетворялись? Конечно же, классическое проектное управление тоже в первую очередь направлено на интересы стейкхолдеров. Просто в его рамках формируется единое ТЗ, которое должно быть выполнено полностью и каждое требование которого столь же важно, как и остальные требования.

Ответить
Развернуть ветку
Максим Цепков
Автор

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

Теперь по содержанию. Опыт показывает, что с существенной вероятностью ТЗ не соответствует потребностям Заказчика, и его выполнение не решает его бизнес-проблему. А если к этому добавить высокую динамику изменений мира, который влечет изменение требований уже в ходе проекта, то эта вероятность становится не просто существенной, а высокой. По опыту я бы считал, что в IT так - не меньше 50-70% Статистика, наверное, даст меньшую цифру, но там не однозначно: большинство исследований успешности проектов как раз оценивали, что проект уложился в бюджет и сроки, и таких проектов не более 1/3 и для Agile и для классики, а вот цифры про анализ ситуации "сделали по ТЗ, а оказалось не нужно" я не помню. Важно, что в классическом проектном управлении выясняется это только на внедрении, что и дает основной риск, устраняемый Agile-методами.

Ответить
Развернуть ветку
Антон Кобельков

Какие из принципов и ценностей, заложенные в Agile-манифесте,  запрещают выполнения проекта за один проход?

Ответить
Развернуть ветку
Максим Цепков
Автор

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

Ответить
Развернуть ветку
Антон Кобельков

"Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев." - значит, буквально понимаемый Agile не является логически законченной методологией или фреймворком. Это примерно как если бы PMBoK требовал бы, чтобы длительность любого проекта составляла бы строго 1 год.

Вы правда считаете, что если проект следует всем требованиям Agile, но периодичность выпуска составляет 1 неделя, то это уже не Agile? Мне кажется, что для документов уровня методологии или фреймворка указание точных сроков это достаточно рискованное занятие.

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

Ответить
Развернуть ветку
Антон Кобельков

"Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев."- ну кстати тогда все Scrum команды, которые работают с периодом более двух недель, тоже к Agile не относятся. Ведь они в принципе могут выпускать продуктс минимальным указанным периодом две недели (а что им собственно препятствует?). Если могут, но не делают, значит не соответствуют принципам Agile.

Ответить
Развернуть ветку
Максим Цепков
Автор

"От пары недель до пары месяцев" - без догм, но определенные рамки накладывает. Scrum Guide в первых версиях жестко требовал, чтобы результат спринта поставлялся пользователям, сейчас это требование смягчили до deliverable - то есть продукт, который в принципе может быть поставлен и имеет ценность, просто поставка тоже имеет накладные расходы, поэтому мы делаем ее не каждый спринт. Можно поставлять и чаще, сейчас есть continuous delivery, а во времена, когда манифест формулировали - этого не было.

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

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

Ответить
Развернуть ветку
Антон Кобельков

Вот этому принципу Agile формально не удовлетворяет 99,9% проектов, особенно если вспомнить про выходные и праздничные дни: "На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе."

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

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

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

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

Ответить
Развернуть ветку
Paul ttt
Проектный подход предназначен для сложной (comploicated) области, а Agile-методы работают в запутанной (complex)

Только наоборот же: complex is used to refer to the level of components in a system. If a problem is complex, it means that it has many components. Complexity does not evoke difficulty. On the other hand, complicated refers to a high level of difficulty.

Ответить
Развернуть ветку
Максим Цепков
Автор

Что именно "наоборот"? Перевод названий областей или применимость методов? Метод для Complicated-области Sense-Analyze-Respond, проектный подход - частный случай реализации: на фазе анализа строим план, и далее действуем по нему. Метод для Complex-области Probe-Sense-Respond, и итерационные Agile-методы как раз его реализуют. А перевод названий Complicated как Сложная, а Complex как Запутанная исторически сложился на русском пространстве.

Или цитата на английском была призвана пояснить что-то другое? Тогда просьба пояснить подробнее, плюс указать на источник, потому что, возможно, важен контекст.

Ответить
Развернуть ветку
Аня Вытнова

Привет! Провожу небольшое исследование, которое касается компаний, внедривших Agile/Scrum/Kanban систему в работе.
Если вы руководитель и покупали такое обучение или услуги консультантов - мне будет очень полезен ваш опыт

Созвон ~30 мин

Пишите в личные сообщения

Ответить
Развернуть ветку
24 комментария
Раскрывать всегда