А. Воронина:

Доброе утро, дорогие друзья! В эфире «Медиаметрикс» и это программа «Продвижение с Анной Ворониной». Сегодня у меня в гостях Светлана Бантос, эксперт по управлению проектными рисками. Светлана, доброе утро!

С. Бантос:

Доброе утро всем!

А. Воронина:

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

С. Бантос:

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

А. Воронина:

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

С. Бантос:

Да.

А. Воронина:

И уже отрабатываешь его в процессе самой апробации?

С. Бантос:

Всё верно. Потребитель видит продукт на какой-то стадии и уже может сказать, что нужно поправить. Потребителю это удобно, с одной стороны, а с другой стороны, может всё это вылиться, особенно на крупных проектах, в то, что мы можем потерять качество продукта. Agile хорош чем? Он хорош своей быстротой, что очень быстро процессы идут, и можно увидеть какой-то результат. Но здесь именно вопрос качества. Да, я соглашусь, что Agile будет работать в каких-то стартапах, в каких-то небольших проектах, это очень эффективно. Но, когда идёт вопрос работы с крупными заказчиками, например, по внедрению какой-то IT-системы, в частности, вот я лично работаю с системами нашего отечественного вендера, это фирма 1С. И крупный заказчик предпочитает всё-таки использовать технологию Waterfall, то есть каскадная технология либо по-другому технология водопада. В данном случае для заказчика это удобнее. Почему удобнее? Потому что там для них всё понятно, для них именно с точки зрения заказчика риски минимальны. В каком смысле минимальны? Например, заказчик объявляет конкурс, тендер. Если это госзаказчик, будет 44 ФЗ, закон у нас есть такой. Либо, если это какие-то акционерные общества, муниципальные образования либо ещё что-то, то есть те, которые с участием госбюджета работают, они используют 223 ФЗ. Кто работает в проектах, знаком с этими законами. Здесь, по таким правилам, всегда нужно использовать, скорее всего, договорную технологию, когда подписывается сразу общий бюджет, этапы сразу все расписываются, сроки этих этапов, вся ответственность – то есть всё в одном документе, всё и сразу. Почему это удобно для заказчика? Потому что мы знаем, что, если крупный проект, то это крупный заказчик. У крупного заказчика есть куча подразделений – юридический отдел, отдел безопасности, ещё что-то. И каждый выполняет свою функцию, и каждому удобно отследить именно свою часть через технологию Waterfall. Поэтому они держатся за это и, чтобы применять у такого клиента Agile, это, наверное, всё-таки руководство должно своей волей принять такое решение, рискнуть и сделать по такой технологии проект.

А. Воронина:

А есть в России такие крупные организации, которые рискуют и уже применяют Agile?

С. Бантос:

Герман Греф. Сбербанк, конечно, рискует, и у него это хорошо получается. Если возьмём крупных интеграторов, IT-проекты, то внедрение именно вчистую Agile-технологий – я, по крайней мере, такого не видела. Да и у нас сейчас куча мероприятий проходит, где спикеры рассказывают о том, что Agile – это хорошо, и тем не менее он признают, что в чистом виде Agile в крупных проектах не применяется. Обычно это комбинированный подход, основа – это всё-таки Waterfall, это каскадная технология, и где-то там можно применить элементы Agile. Когда это работает, когда возможно такое сделать? Например, объявил закупки заказчик, заказчику нужно срочно. Они свою стадию закупки провели в течение месяца-двух, а это очень короткий период времени на самом деле, когда ты пройдёшь согласование всех документов внутри компании, это месяца 4-5 обычно проходит. И вот за 2 месяца они согласовали и вышли на рынок с конкурсом. И, как правило, в таких конкурсах техническое задание описано общими словами. И на первоначальный этап по технологии Waterfall отводится не месяц или два, а это снятие показаний, если юридическим языком говорить, постановка задачи на самом деле идёт, интервьюирование заказчика. Вот здесь достаточно на такие короткие проекты времени отводится очень мало. И мы успеваем снять буквально общие фразы, а далее, как начинается разработка, вот тогда в этом случае мы начинаем уже применять Agile-технологии. Мы разрабатываем по первоначальной постановке, спрашиваем непосредственных пользователей: «Это так?» Они нас поправляют, и мы дальше уходим, далее дорабатываем и опять приходим к ним. Вот именно этот элемент Agile – он здесь работает.

А. Воронина:

А сам Waterfall, правильно ли я понимаю, что это, по сути, поэтапное внедрение проекта в уже текущую деятельность компании?

С. Бантос:

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

А. Воронина:

Как давно проектный подход уже внедряется в России?

С. Бантос:

Очень давно.

А. Воронина:

Это советский период?

С. Бантос:

Да, ещё в советский период.

А. Воронина:

Или ещё раньше?

С. Бантос:

Давайте вспомним даже времена, когда мы строили различные гидроэлектростанции, покоряли целину и т. д. Это всё, по сути дела, проекты, и уже тогда апробировались эти технологии. Конечно, потом создались некие сообщества, которые уже систематизировали знания, например, РМI. Подход PMI института, у нас есть такой международный, вот они систематизировали знания и внедрили в массы. Написали некую инструкцию, методику, мы знаем, она называется PMBoK, и там прописаны все моменты, каким образом пользоваться.

А. Воронина:

А в чём суть этой методики?

С. Бантос:

Вот как раз суть методики – это достигнуть какой-то определённый результат, уникальный результат, и пройтись по всем стадиям, о которых мы уже говорили – ТЗ, разработка, далее внедрение. Описаны все процессы в этих стадиях, как работать с этими процессами, как их выстраивать. В частности, я специализируюсь в проектных технологиях на работе с рисками. Это один такой достаточно большой раздел в проектной технологии. Каждый специалист считает свою область важной, и я считаю, что это очень важно. В каком плане? Есть такая статистика, что все IT-проекты от 70 до 80% неуспешные. Что такое неуспешные? Это не значит, что их начали и не закончили. Нет, неуспешный проект может закончиться по-разному. Может закончиться – будут достигнуты результаты, но не в то время, когда это было действительно необходимо, либо мы получим результат, но не с тем качеством.

А. Воронина:

Это ты говоришь про стартапы?

С. Бантос:

Нет, это даже не про стартапы, а про крупные IT-проекты, когда…

А. Воронина:

Уже готовые, упакованные, которые, по сути, просто внедряются в новую систему? Приведи пример.

С. Бантос:

Как у нас, пример привожу, как я работаю. У нас есть разработчик, вендер-фирма 1С, у них есть стандартные готовые конфигурации, программные продукты. Например, управление производственным предприятием либо какая-то крупная, мощная ERP-система. Она стандартная, в ней прописаны все основные производственные процессы, которые могут быть на предприятии. Что происходит? Когда мы приносим это коробочное решение к заказчику, у заказчика, естественно, есть какие-то свои требования. Он хочет поменять те или иные процессы, изменить формы, виды отчётов, документов и т. д. И он заказывает проект, он говорит: «Вот я, например, работал до сегодняшнего дня в другой системе, а мне теперь нужна вот эта система, 1С. Давайте сделаем так, как было нам удобно, и используем те плюсы программного продукта, который мы на текущий момент приобрели». И мы начинаем проекты по внедрению, то есть дорабатываем программный продукт, докручиваем и уже передаём заказчику в том виде, в котором он хотел, о котором он писал соответствующее ТЗ. Таким образом у нас работают проектные технологии в 1С.

А. Воронина:

Можно ли вообще изначально предугадать все риски, связанные с проектом? Условно, вот есть проект, и ты уже понимаешь и пишешь: вот 10 рисков, и вот вам инструкция, как их решать.

С. Бантос:

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

А. Воронина:

А какие риски, если отойти от проекта? Это баги, это возможность нападения хакеров, это что-то сломается на серверах – что туда включается?

С. Бантос:

Всё, что вы перечислили, всё может сыграть. Но, как правило, на каждом проекте есть руководитель проекта, он сосредотачивается на определённых рисках. Какие это риски? У каждого руководителя проекта есть задача сделать так, чтобы проект достиг цели, как мы говорили уже. Но он должен достичь этой цели в рамках определённого времени, бюджета, и качество должно быть на уровне. И вот, когда у нас ведётся проект, может случиться, из примера рассказываю: сделали постановку задачи, поставили ТЗ и стали делать разработку. И вот когда мы делаем разработку, мы проверяем на заказчике, вот, например, эта технология Agile, он тестирует, и мы смотрим, действительно ли это то, что нужно было. Заказчику всё нравится, он тестирует, проходит эти итерации, но чем мы здесь можем поплатиться? Здесь у нас минус такой, что мы видим такой момент – время. Мы начинаем вываливаться за рамки отведённого времени, и в этот момент тяжело становится исполнителю и заказчику также. Но вроде функция руководителя проекта вообще в чём выражается? Он должен работать с рисками и должен работать таким образом, что он должен подготовить заказчика к приёму тех результатов, которые будут выполнены в результате разработки, предположим. И когда руководитель проекта работает на заказчика и пытается, даже я скажу так, угодить ему и выполнить все его требования, он волей-неволей попадает под его влияние. Он уже начинает делать так, чтобы не было конфликтных ситуаций, ещё что-то – задача у него такая становится. И вот здесь риски срабатывают такие, что всё выполняем, вот был у нас проект такой, у моего клиента, когда я контролировала риски на проекте, случилось следующее. Выполнили определённые этапы работ, выполнили и подписали акты выполненных работ, всё хорошо, но риск, как говорится, был в следующем. Мы увидели, что исполнитель ушёл из тех временных рамок, которые были изначально заложены. И в результате акты подписаны, проект выполнен, а юридическая служба клиента вдруг решила посмотреть этот договор. Открывают договор и видят, что сроки просрочены. Что делает юридическая служба? Её задача – выставить неустойки, это её работа. Особенно, если мы возьмём какую-то организацию, которая работает, например, госорган по 44 ФЗ, он не имеет права не выставить эти неустойки. Если они не выставят, они получат штрафы как на уровне лиц внутри заказчика, так и на уровне самой организации, кто в этом участвовал. Поэтому здесь как раз, когда срабатывают такие риски, необходимо помочь руководителю проекта – помочь ему принять решение, помочь ему не уйти в сторону работы полностью на заказчика, а всё-таки объективно взглянуть на картину, происходящую на проекте, и дать ему возможность уже в процессе реализации проекта исправить данную ситуацию. На текущий момент вот эта область работы с рисками не совсем проработана на нашем рынке и, скажем так, на текущий момент мы – вот такие специалисты, которые как раз смотрят и помогают ERP. Мы работаем и помогаем в данном случае.

А. Воронина:

Для тех слушателей, которые только что к нам подключились, напоминаю, что у нас в гостях Светлана Бантос, эксперт по управлению кредитными рисками. Светлана, правильно я понимаю, что вообще в принципе есть руководитель проекта, и эксперт по управлению рисками подключается на этапе, когда уже всё плохо, и начинает условно разруливать эту ситуацию? Как это работает в жизни?

С. Бантос:

Спасибо за вопрос, это очень хороший вопрос. Вот в этом месте мы подходим к такому явлению, как есть юридический отдел в компании, который вроде как должен работать с такими рисками, например, с этими же неустойками. Но что мы видим, как работают юристы? И притом они это делают не из-за того, что целенаправленно они так хотят, а потому что на самом деле в своей ежедневной рутине они не могут сделать большего. Юрист появляется, когда заключается договор, он смотрит на него, видит все пункты, разделы договора, выравнивает их, делает удобными и полезными с точки зрения, на какой стороне юрист выступает. Например, мы рассмотрим всё так же исполнителя. Он смотрит, есть ли для него вот эти правовые риски, в данном случае в договоре. И далее юрист отходит на второй план, у него рутина ежедневная, он занимается какими-то проблемами в бизнес-процессах клиента, но никак не проектами. А далее случается – упс! И в какой-то момент подходит руководитель проекта к нему и говорит: «У меня случилась ситуация. Пойдём, будем уже разбираться». То есть к юристу приходят, когда уже всё состоялось, и юрист уже говорит: «Ну давай, будем составлять уже документы и пойдём в суд». И дальше он помогает, конечно, перед судом бывают процессы, которые переговорные, так скажем, но эти переговорные процессы так или иначе, если вдруг мы не договоримся, они перетекают в судебные органы. Вот как выступает у нас юрист. Как мы уже говорили, руководитель проекта – внутри проекта, и он работает на заказчика. Он вроде как работает на своего работодателя, его наняли для того, чтобы проект состоялся, чтобы добиться цели, но так или иначе он всегда будет ориентироваться на заказчика, на его хотелки, на его потребности. И в этот момент, видите, такой разрыв.

А. Воронина:

То есть ему надо угодить и там, и там, и ещё быть в рамках договора?

С. Бантос:

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

А. Воронина:

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

С. Бантос:

В рамках подхода PMI, конечно, управление рисками всегда было.

А. Воронина:

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

С. Бантос:

Это, как правило, всегда был руководитель проекта.

А. Воронина:

Он сам же был?

С. Бантос:

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

А. Воронина:

Есть какая-то методичка по управлению рисками?

С. Бантос:

РМВоК.

А. Воронина:

А, тот же самый РМВоК, где можно подглядывать?

С. Бантос:

Конечно, в РМВоК всё есть. Там описаны технологии, процессы, каким образом, как составлять карту рисков, как с ней работать. Есть даже на рынке специальные программные продукты, где можно все риски выписывать. Там в результате будет «Итого» по тому, что ты ввёл в эту программу – тебе покажут, что с этими рисками делать, дальнейшие твои действия. Но как таковой прямо методички к конкретному случаю, к конкретному проекту, конечно, нет. Мы уже вначале говорили, что проект – это что-то уникальное, в результате чего создаётся уникальный продукт. И каждый проект, который мы запускаем, он вообще индивидуален. На моей практике не было ещё таких проектов, которые бы прямо совпали.

А. Воронина:

А когда проект тиражируется, тоже отличается уже от изначального? Когда мы тиражируем проект на другие организации, например, отличаются они?

С. Бантос:

Ну, мы можем тиражировать подход, наверное, но не проект. Можно, наверное, если мы в рамках проекта разработали какой-то программный продукт, мы можем его растиражировать. Предположим, вот «Газпром» у нас был, у «Газпрома» есть куча дочерних компаний. Вот он может растиражировать разработанный программный продукт и всех завести в единую систему. Я уровень рассказываю.

А. Воронина:

Но ты это объединяешь в один проект или это всё-таки несколько проектов, связанных соединённой цепочкой?

С. Бантос:

Это может быть как один проект, а может быть несколько проектов. Вот был у нас такой опыт: крупный заказчик заказал систему, мы её разработали и всё, на этом этапе мы закончили свои работы, а дальше заказчик самостоятельно стал тиражировать разработанный программный продукт на свои дочерние общества. А есть такие проекты, когда изначально сразу же заказчик говорит: «Вот есть я, головная организация, вот здесь у меня ещё есть 10-15 «дочек», и мне туда тоже нужно поставить и ещё интегрировать систему с кучей других систем». Прямо один в один – такого я не видела.

А. Воронина:

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

С. Бантос:

Давайте начнём, наверное, с конца – международный уровень и что происходит в России? У нас, конечно же, есть определённый подход, свой менталитет. Могу рассказать вам именно про свой опыт, как мы говорим именно про работу с рисками, и проговаривали, что, если на международном уровне управлению рисками отводят очень большое внимание, прямо даже выделяют отдельных людей. То есть люди понимают, насколько высоки риски даже не в том смысле, когда проект не успешен, не состоялся или ещё что-то, а когда теряется репутация фирмы из-за таких проектов. Вот поэтому они очень дорожат этим, и уровень управления рисками очень высок. У нас в российских реалиях это не так, отличается, конечно, как я уже говорила, руководители проекта занимаются тем, чем успевают. В частности, я рассказываю вам про рынок именно 1С, потому что вот здесь у меня колоссальный опыт, и я понимаю и вижу, что здесь происходит. Особенно в рамках сегодняшнего дня мы видим, что вроде как государство у нас повернулось в сторону отечественных разработчиков, идёт замена иностранного ПО на ПО российских разработчиков. Поэтому здесь тенденция такая, что всё-таки фирма 1С стала подтягиваться к тем моментам именно в части ответственности вот этого проектного подхода по полной технологии, которая описана в пи-эм-боке.

А. Воронина:

А что касается разницы советского периода, например, и сейчас проектного управления?

С. Бантос:

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

А. Воронина:

Неготовый корабль?

С. Бантос:

Неготовый космический корабль в космос с минимальным функционалом.

А. Воронина:

Согласна, согласна, действительно это не так всё просто. С точки зрения руководителей проектов есть ли сейчас какие-то учреждения, которые готовят, или курсы, где там вообще учатся? Или это нужно самому садиться, сёрфить интернет и искать эти кейсы, разбирать и на практике уже применять?

С. Бантос:

На самом деле да, у нас много организаций, которые учат управлению проектами. Вот, например, в частности фирма 1С для своих франчайзи, для своего рынка организовала на базе своего учебного центра официальные курсы для руководителей проектов. Прямо идёт курс, написанный на основе РМВоК, где расписаны все те стадии, которые рекомендуются к применению в рамках реализации проектов на 1С. Это такой курс, такая упрощённая методика, которая взята из РМВоК, на основе РМВоК. Ну и, соответственно, у нас есть подход PMI, это международный институт, который готовит руководителей проектов, и именно там можно себя сертифицировать.

А. Воронина:

Даже сертификат получить?

С. Бантос:

Да, получить сертификат.

А. Воронина:

Международный сертификат и быть в прямом смысле с бумажкой?

С. Бантос:

Да, с бумажкой, и быть руководителем проекта таким признанным. Если вы откроете, например, «Хедхантер» или какой-то другой ресурс, где у нас люди, соискатели ищут работу, мы увидим, что там крупные заказчики, крупные работодатели пишут требования к свои потенциальным работникам о том, что наличие сертификата института PMI.

А. Воронина:

Сколько нужно учиться, чтоб получить такой сертификат?

С. Бантос:

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

А. Воронина:

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

С. Бантос:

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

А. Воронина:

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

С. Бантос:

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

А. Воронина:

Дорогие друзья, с нами была сегодня Светлана Бантос, эксперт по управлению проектными рисками. Светлана, спасибо большое за интересную беседу. Дорогие друзья, одежда ведущей предоставлена российским дизайнером Вадимом Мерлисом. А вам мы желаем хорошего дня. До свиданья, всего доброго!

С. Бантос:

До свиданья, спасибо, всего доброго!