Павел Алферов: Agile, Scrum и «византийская система управления». Разбор полетов в мире ИТ-проектов
В мире, где каждый новый проект может решить судьбу компании, наличие компетентных лидеров, профессиональных команд и отработанных методологий оказывает ключевое влияние на успешное завершение проектов. Однако на практике всегда ли стоит применять гибкие подходы, такие как Scrum? Каково их реальное влияние и понимание в бизнес-среде? И насколько глубоко внутрикорпоративная политика и личные отношения могут влиять на процесс управления проектами? Вместе с Павлом Алферовым, известным экспертом, профессором школы управления СКОЛКОВО постараемся разобраться в этих сложных вопросах.
Некоторые говорят, что традиционные методологии управления проектами устарели и не соответствуют реальности современного бизнеса. Согласны ли вы с этим мнением?
Если взять ИТ, именно проекты по разработке программного обеспечения, то сейчас классические технологии действительно редко применяются. Почти все перешли на Agile. А вот в проектах инфраструктурных все еще «правят бал» традиционные методологии. И если посмотреть, например, на строительство домов, там все еще по старинке, по классическому подходу.
Я бы сказал так: есть четыре волны проектного управления.
Первая волна, это 50–60 годы прошлого века. Там главное было — сроки и деньги. Знаете, все эти диаграммы Ганта, PERT и так далее. Но к 1980-м стало ясно, что такой подход не решает все задачи.
Потом пришли 90-е. Появилось то, что мы сейчас называем «классические (или традиционные) методологии управления проектами». Тут уже стало понятно, что, кроме денег и сроков, надо учитывать и другие вещи: заинтересованные стороны, риски, качество и многое другое. Много аспектов. И по всем этим аспектам нужно было составлять планы.
В десятые годы XXI века на сцену вышел Agile. Его авторы сказали, что мир стал такой сложный, такой переменчивый, что долгосрочное планирование — это не наш метод. Лучше планировать по частям, спринтами.
Но вот интересно, что и этот подход, Agile, достигает своих пределов. И сейчас наступает новый этап — этап гибридизации. Берем немного от классики, немного от Agile и смешиваем. Именно на таком подходе реализуются многие сложные проекты и на Западе, и у нас. И исследования ведутся в этом направлении.
А как менялось восприятие роли менеджера проекта? И какие компетенции стали сегодня особенно актуальными, на ваш взгляд?
Первоначально менеджер проекта был таким рациональным механиком, который настраивает организационную машину реализации проекта, и ведь фокус внимания был на харды. Он должен был четко спланировать, четко организовывать, четко проконтролировать работу. Но чем дальше, тем больше стало понятно, что, кроме хардов, ему нужны софты.
Ведь важно не только как, но и с кем ты работаешь — общение с людьми, коммуникации, понимание их мотивации, договоренности, решение внутренних проблем.
Если брать сложные проекты, то одних хардов и софтов иногда бывает мало. И вот тут уже говорят о новых вещах. Например, как сохранять свою энергию, не теряться в работе, заботиться о себе. Появились новые понятия, такие как VQ, коэффициент жизненной энергии.
И еще PMI добавил в картину TQ (Technology Quotient). Это техническая компетенция, или технические навыки. То, что менеджер должен понимать современный технологический мир, и чем современные технологические решения могут помочь. Сегодняшний менеджер проекта должен быть в курсе новинок: чат-боты, нейронные сети и так далее.
Сейчас обсуждаются более тонкие материи, слабо формализуемые навыки: как учиться доверять своей интуиции, как разбираться в обстановке при недостатке информации, как чувствовать проект целиком (холистически). Чем сложнее проект, тем труднее сделать общую детальную картину этого проекта. И нужно как-то себя настраивать, чтобы интуитивно ловить эту общую картину.
Уверен, что финальная точка еще не поставлена и роль менеджера проекта точно будет дальше развиваться.
Ну вы уже упомянули о переходе от водопадных к гибким методологиям, когда у нас случился этот переход и почему?
Если рассматривать развитие подходов к управлению проектами в контексте времени и места, можно увидеть интересные детали. На Западе, где эти изменения начались гораздо раньше, все происходило плавно. Это было как естественное развитие — от классических методик к agile. Там с середины 2000-х и до 2010-х эти изменения наиболее активно себя проявляли. Но к концу 2010-х стало очевидно: ИТ-сфера приняла аgile окончательно.
А что касается России... О, тут все гораздо интереснее! Можно даже назвать дату, когда agile начал свое массовое наступление. Это произошло после 2016 года, когда Герман Греф на Гайдаровском форуме сказал, что те, у кого не будет agile, умрут в страшных муках, потому что их система управления будет неспособна работать по-новому. Но главным драйвером, который вызвал переход от водопадных моделей к гибким, стал «рост неопределенности».
Лучше всего я показываю это своим студентам на модели «CINEFIN (Киневин) — есть такая модель о разных степенях неопределенности. Автор модели придумал «домены неопределенности», в зависимости от того, в какой «домен» ты попал надо действовать по разному. Но общая идеи очень простая: чем выше уровень неопределенности, тем сильнее меняются твои управленческие методики.
Если все ясно и просто, то управление проектом простое, как раз по старым методикам. Поднялась неопределенность — приходится включать мозги, подтягивать экспертов. Это «сложный домен». Но когда мы говорим о разработке ПО, тут уровень неопределенности сильно выше — это уже «запутанный домен». В такой ситуации подходы водопада бессильны. Здесь уже нужны гипотезы, эксперименты, быстрые итерации.
И есть домен, где уровень неопределенности зашкаливает — «хаотический». Когда все вокруг меняется так быстро и неожиданно, что никакие стандартные методики не работают. Это такое ситуативное управление, штабное управление, когда мы должны срочно вытащить ситуацию из кризиса.
Поэтому отвечая на вопрос главное, почему начался переход, — это рост неопределенности окружающего мира. И похоже этот рост пока не собирается останавливаться.
В последние годы многие проекты, особенно крупномасштабные, сталкиваются с провалами, несмотря на применение современных методик. В чем, на ваш взгляд, корень проблемы?
На эту тему есть статистика, я ее часто показываю, как менялся процент провальных проектов с 1994 по 2020 год. И суть в том, что очень сильно выросла успешность проектов, но так продолжалось примерно до десятых годов, а дальше она остановилась. То есть все равно до сих пор пятая часть проектов проваливается. Но причины здесь совершенно разные. Есть даже отдельные большие реестры причин провалов. А в целом, на мой взгляд, они сводятся к нескольким вещам.
Первое — слишком оптимистичное представление на входе. Мы проект провалили, потому что обещали сделать за сто рублей полет на Марс. Вдруг выяснилось, что за сто рублей никто никогда на Марс полететь не сможет. И мы его делаем, например, за миллион. И вот выясняется, что у нас проект провален, потому что вместо ста рублей потратили миллион. Но это не значит, что проект провальный сам по себе, просто те базовые предпосылки, на которых строились расчеты по проекту, были неверны. Поэтому первое — это когда провальный проект на самом деле не провальный, а просто слишком оптимистичный взгляд в начале.
Вторая причина — это изменения. Ну, то есть проект шел нормально, как мы говорили, но случилась высокая турбулентность мира, и в процессе выясняется, что мы делаем не то, что нужно. И проект становится провальным.
Ну а третье — управление, плохое управление проектом. Я считаю, что если нормально посчитали на входе и не произошло драматического изменения внешних условий, то все остальное — это неумение собрать вместе разные аспекты, спланировать, проконтролировать, организовать работу с людьми для того, чтобы проект вытащить.
Некоторые эксперты утверждают, что гибкие методологии, такие как Agile и Scrum, стали модными словами, которые компании используют без понимания их реальной сути. Согласны ли вы с этой критикой?
Для начала давайте разграничим Agile и Scrum. В первую очередь рассмотрим, что такое Agile. Мы имеем перед собой манифест Agile, который умещается всего на одной странице. Однако каждый из нас может трактовать эти четыре ценности и 12 принципов, описанные в манифесте, по-своему. Из-за этой многогранности толкований возникают ситуации, когда говорят: «Мы работаем по Agile, и поэтому у нас нет четкого плана». Так, в российском контексте порой можно услышать фразу о «3A»: авось, аврал и Agile. Если в компании не удается качественно организовать работу, то такой хаос иногда оправдывают утверждением: «Это не дезорганизация, это у нас Agile».
Теперь перейдем к Scrum. В мире Agile методологии работы принято называть фреймворками. Вот Scrum как раз такой фреймворк. Он представляет собой конкретный набор правил и рекомендаций, охватывающий двадцать страниц, где детально расписано, как реализовывать Agile с точки зрения авторов. Однако даже имея четкие инструкции, на практике, особенно в российских реалиях, Scrum часто адаптируется под уникальные особенности команды или организации.
Например, в гайде написано, что вы ежедневно проводите стендапы, где команда собирается поговорить, что сделала за прошлый день, что планирует и какие имеются проблемы. Прекрасная практика, да. Значит, наши люди говорят: «Ну вот еще каждый день вставать рано, вообще программисты этого не любят. Поэтому мы будем собираться раз в неделю. Но называть это все будем Scrum. Вообще, с точки зрения скрам-гайда не имеем права так называть. Но мы будем». И дальше вот так же, Scrum-гайд говорит, в конце каждого спринта надо провести собрание, где мы обсуждаем, как мы поработали, что нужно поменять в работе - ретроспективу. Ну вот еще две недели, каждые два часа собираться, болтать непонятно о чем! Мы будем собираться, ну например, раз в квартал. Если ничего не меняется, можно и раз в квартал собраться.
И вот из-за этой разноголосицы часто Agile и Scrum действительно становятся модными словами, которые каждый формулирует как хочет.
Как вы относитесь к утверждению, что бизнес часто воспринимает ИТ-проекты как «черный ящик», не понимая их настоящую стоимость и сложность?
Да, это верно. Многие ИT-проекты действительно наполнены техническими деталями, специфическими терминами, фреймворками и протоколами. Айтишникам потребовалась многолетняя учеба, чтобы понимать все эти нюансы, так почему бизнес-специалисты должны освоить это сразу? Сейчас ситуация лучше, чем 10-15 лет назад, многие освоили технические премудрости, но все равно язык ИТтшников еще долго будет отличаться от языка обычных людей.
И тут надо не возмущаться, что ИТ — это как черный ящик. А принять как данность и думать, как бизнесу объяснить выход их черного ящика. Не сам черный ящик, он слишком сложный, чтобы объяснить. Но ключевые вещи, связанные с бизнесом, надо обязательно стремиться объяснить. И взаимосвязи, там, условно, что нельзя 10 000 строк кода поменять за пять минут. Миллион строк кода за два дня поправить. То есть бизнесу надо объяснить базовые связи между элементами.
Нужен ли своеобразный «переводчик», который будет неким мостом между менеджерами проектов и бизнес-лидерами, для более эффективных коммуникаций?
Для плохих проектных менеджеров, конечно, нужен. Хороший менеджер проекта должен сам выступать таким толмачом. То есть менеджер ИТ-проекта должен в достаточной степени разбираться в ИТ, чтобы объяснить бизнесу, что там происходит. Он не должен быть экспертом, но должен понимать и уметь объяснить другим, в чем суть — это часть его профессиональной компетенции.
Другой момент — часто, особенно в крупных компаниях, выстраивается схема многослойного управления, когда на стратегическом уровне есть куратор проекта от бизнеса, а на среднем уровне есть некоторый ответственный за проект, его называют руководителем проекта, но я рекомендую его называть ЕOЛ — единое ответственное лицо, или директор проекта. И есть руководитель проекта от ИТ. И вот руководитель проекта от ИТ именно таким толмачом и работает – объясняет бизнесу как что работает.
Но если нет такого ИТ-руководителя проекта, а есть только человек от бизнеса, то да, руководителю проекта нужен какой-то помощник-переводчик. Потому что не надо рассчитывать, что человек, который никогда ИТ не занимался, вдруг поймет всю специфику.
Проекты цифровой трансформации регулируются теми же законами проектного управления?
Не совсем. Во-первых, проект цифровой трансформации — это не проект. Если мы говорим о цифровой трансформации компании, то это программа проектов или портфель проектов. Это может быть совокупность не только проектов, но и продуктов. Сейчас появилась альтернатива проектного подхода — продуктовый подход.
Проектная команда собирается и в конце проекта распускается. В продуктовом подходе команда собирается и делает этот продукт пока в нем есть смысл. Яркий пример — личный кабинет клиента. Вы же не сделали его и забыли – нет, он постоянно развивается и команда выпускает все новые и новые версии. Это хорошо видно на примере систем банк-клиент. Как раньше их делали? Условно банки собирали команду, делали банк-клиент, переводили в промышленную эксплуатацию и расходились.
Сейчас ни один банк так не делает, есть постоянная команда, которая, скажем, делает первую версию банк-клиента, вторую и последующие. Это базовый продукт, который постоянно развивается. Поэтому в портфеле или в программе цифровой трансформации будут и проекты, и продукты. И самой цифровой трансформацией нужно управлять как более сложным объектом, чем отдельный проект или продукт.
Насколько сильно политика и внутрикорпоративные игры влияют на успешное управление проектами и изменениями?
Драматично влияют. Я называю это «византийская система управления». У нас очень многие решения принимаются на основании личных взаимосвязей, личного общения, личных отношений. И поэтому руководитель проекта не может избежать этих ловушек. Точнее так: если он будет игнорировать эту сферу, его проект обречен на провал. Поэтому он должен разбираться, понимать расклады, кто за его проект, кто против, почему против, что можно сделать, чтобы убедить, поддержать проект или хотя бы не мешать. Это лишь часть работ руководителя проекта. И если он не будет ее делать, то какой бы замечательный успешный проект ни был, он провалится. Просто потому, что люди — это люди со своими интересами. И им нужно помогать выравнивать их интересы с интересами проекта.
Вот такие нюансы, например, могут драматически разрушить многие проекты: может, проект у вас и хороший, но лично вот ты мне не нравишься. Поэтому я тебе буду всячески мешать делать твой проект. Как бы он хорошо ни был описан, какие бы выгоды компании ни принес.
Опубликовано 29.08.2023
