Бесплатный фрагмент - Проектное управление из первых рук

Пара вводных слов: о нас и о книге, которую вы держите в руках

Авторы Станислав Кречетов,
Сергей Малоземов, Павел Азгальдов

У этой книги три автора. Каждый из нас шел собственной дорогой к управлению проектами. И однажды наши пути пересеклись в Топливной компании Росатома «ТВЭЛ» — одном из крупнейших производителей ядерного топлива в мире.

Сегодня Топливная компания шагнула далеко за пределы отраслевой специализации. Она запускает грандиозные проекты в самых разных сферах — научные, промышленные, IT и другие. В 2016 году, когда в компанию на должность руководителя проектного офиса пришел Станислав Кречетов, эта деятельность только зарождалась. В 2018 году к команде в роли директора по стратегии присоединился Павел Азгальдов.

О том, с какими трудностями пришлось столкнуться при внедрении системы проектного управления в Топливном дивизионе и как их удалось преодолеть, Станислав и Павел рассказали в главах «Гибкие методы проектного управления в корпорациях» и «Когда проектное управление действительно нужно».

Время шло и приносило с собой новые вызовы. В 2020 году в команду АО «ТВЭЛ» вошел Сергей Малоземов, организовавший методологический проектный офис, а затем и департамент проектного управления, что помогло вывести проектную деятельность Топливной компании на новый уровень. Как сформировать системный подход к работе проектных офисов, он описал в главе «Методология проектного управления».

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

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

А теперь, когда первые слова сказаны, давайте знакомиться!

Создатель и генеральный директор «Иннохаба Росатома», который сегодня является не только первым в стране deep-tech акселератором, но и проектным офисом и имеет свой инвестиционный портфель.

Родился 4 февраля 1985 года. В 2006 году окончил металлургический факультет Уральского федерального университета имени Б. Н. Ельцина по специальности «Информационные системы и технологии». В 2010 году получил диплом магистра Уральского государственного экономического университета по специальности «Организация предпринимательской деятельности».

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

Создал и возглавил IT-подразделение в структуре крупного холдинга. Параллельно вел авторский курс в Уральском федеральном университете. Сменил вектор развития карьеры и занялся реализацией промышленных проектов на заводе «Уралхиммаш», где прошел путь от руководителя проекта до директора по стратегии и проектам.

В 2016 году возглавил проектный офис в АО «ТВЭЛ». Занимался внедрением лучших практик проектного управления, в том числе agile-методологий, управлением стратегическим проектным портфелем компании и тиражированием методологии проектного управления на дочерние предприятия.

Более 15 лет работает в области стратегического планирования, управления проектами и продаж в крупных промышленных предприятиях. Серийный корпоративный предприниматель.

Директор департамента проектного управления АО «ТВЭЛ». Сертифицированный управляющий проектами (IPMA level B), сертифицированный профессионал в области Agile (ICAgile Certified Professional). Победитель Всероссийского конкурса «Проектный руководитель», дважды призер конкурса «Лучший по профессии в стройкомплексе атомной отрасли».

Родился 2 октября 1991 года. В 2016 году окончил с отличием Нижегородский государственный технический университет им. Р. Е. Алексеева по направлению «Ядерные физика и технологии». В 2017 году окончил с отличием Волжский государственный университет водного транспорта по направлению «Менеджмент. Управление проектами». В 2020 окончил аспирантуру.

Автор собственных курсов и деловых игр по проектному управлению, а также более 15 статей в профессиональных журналах. Выступал в качестве приглашенного спикера по тематике проектного управления на международных конференциях в Австралии, Бельгии, Испании, Турции, Японии.

В 2016 году стал первым отраслевым scrum-мастером в проекте по оптимизации объема зданий и сооружений ядерного острова одной из зарубежных АЭС. Подробнее об этом опыте Сергей рассказал в главе «Agile: впервые в атомной отрасли». После успешной реализации проекта был приглашен на роль методолога по проектному управлению на другую зарубежную «атомную» стройку.

В 2020 г. перешел на работу в АО «ТВЭЛ», где впоследствии создал и возглавил методологический проектный офис, а затем и департамент проектного управления, сформировал систему развития проектной деятельности предприятий и интеграторов дивизиона, а также внедрил целый ряд новых инструментов проектного управления.

Более 10 лет работает в области проектного управления в крупных промышленных и инжиниринговых компаниях. Практикующий эксперт в области проектного управления.

Член совета директоров, инвестиционный директор компании «Энергон», ранее директор по стратегическому развитию АО «ТВЭЛ» и сооснователь направления бизнеса «Электромобильность» в госкорпорации «Росатом». Имеет успешный опыт разработки стратегий для запуска бизнеса и повышения операционной эффективности.

Родился 21 февраля 1977 года. В 2000 году окончил Московский физико-технический институт, затем в 2003 году Российскую экономическую школу.

Принимал участие в реформировании системы налогообложения РФ, строил макроэкономические модели для Минэкономразвития и Минфина России. Работая в Минэкономразвития, реализовал множество инициатив по реформированию системы управления ЖКХ и привлечению частных инвесторов в эту сферу. В частности, впервые в России ввел систему долгосрочного тарифного регулирования в концессионных соглашениях.

В 2013 году поступил на программу двойной степени Erb Institute в Мичиганском университете: бизнес-школу Ross School of Business и школу природных ресурсов и окружающей среды. По окончании учебы стажировался и работал в Boston Consulting Group в г. Детройте, где получил ценный практический опыт работы в кросс-дисциплинарных и кросс-культурных проектных командах.

По возвращении в Россию в 2018 году приступил к работе в АО «ТВЭЛ».

Стратег с 15-летним опытом работы в частном секторе США и РФ и на госслужбе.

---

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

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

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

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

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

Продуктивного чтения!

Часть 1.
Проектное управление в крупных компаниях

Когда проектное управление действительно нужно: основные критерии

Автор Павел Азгальдов

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

⠀

На одном языке

Операционные задачи в компании решаются функциональными подразделениями в рабочем порядке.

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

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

Когда я только пришел на работу в АО «ТВЭЛ», в дивизионе еще не было своей системы проектного управления. На тот момент компания занималась в основном операционной деятельностью по производству ядерного топлива, все процессы в этом направлении были идеально отлажены. Даже НИОКР, которые традиционно реализуются в проектной логике, в ТВЭЛе выполнялись в процессной.

⠀

Изнутри

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

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

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

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

В АО «ТВЭЛ» проектный офис быстро стал давать нужные результаты, а вот на ряде предприятий дивизиона работа велась весьма формально: сотрудники проектных офисов не получили достаточных полномочий или были загружены задачами, не связанными с развитием проектного управления, или их инициативы не находили поддержку у руководства. Так что я пришел к выводу, что обособленный проектный офис, который отвечает за функционирование системы проектного управления на предприятии, нужен далеко не всегда.

Наиболее эффективен он в следующих случаях:

• Когда компания быстро расширяется, и необходимо масштабировать процессы. Ведь масштабирование — это не слепое копирование: необходимо вносить изменения, и лучше, если этим будут заниматься специалисты в области управления проектами.

• Когда компания осваивает новые виды деятельности, начинает работать с новыми товарными группами, для которых прежние процессы уже не подходят, и необходимо оперативно выстраивать новые.

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

Тут, кстати, уместно вспомнить еще об одном традиционном заблуждении, связанном с управлением проектами. Многие считают, что учиться проектному управлению не обязательно: достаточно быть крепким профессионалом в своем деле, а умение управлять проектами само приложится.

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

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

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

Поэтому, если вы планируете заниматься управлением проектами, управленческое образование в этой сфере вам просто необходимо. А еще — владение своей предметной областью и умение работать в команде. Впрочем, обо всем по порядку.

Первые шаги в проектном управлении:
смотрим по-новому

Автор Сергей Малоземов

Мы работаем в «Росатоме» — корпорации, которая занята высокотехнологичными проектами в самых разных сферах человеческой деятельности: от строительства крупных индустриальных объектов до создания узкоспециализированных IT-решений для бизнеса и промышленности. Работать здесь я мечтал со студенческой скамьи — но поначалу даже не представлял, что в итоге буду заниматься проектным управлением.

Я мыслил о чем-то, как мне казалось, более глобальном и важном: о науке и инженерных разработках в серьезной сфере, лучше всего — в ядерной физике. После школы уезжать из родного города не хотел. Поэтому Институт ядерной энергетики и технической физики Нижегородского государственного технического университета стал моим естественным выбором альма-матер.

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

О том, что эти вопросы объединяются емким термином «управление проектами», я тогда не догадывался. Я видел себя ученым и стремился мыслить соответственно. Главную ценность для меня составляли красота инженерного решения и техническая часть проекта. Все, что связано с маркетингом, планированием, финансированием, казалось вопросами более низкого порядка. Я не понимал, почему мне приходится заниматься этой, как я воспринимал тогда, «низкоквалифицированной работой».

⠀

Изнутри

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

---

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

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

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

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

Лишь комплексный взгляд на проект позволяет найти ответы на важные вопросы. Где будет востребовано ваше изобретение? Кому оно полезно и какие проблемы решает? Что еще нужно, чтобы воплотить задуманное в жизнь? Я узнал, что такое календарное планирование проекта. Собственноручно созданный график стал моей первой значимой победой на новой стезе — и параллельно первым шагом к профессиональному управлению проектами.

Наш дозиметр в итоге получился ровно таким, каким задумывался: он давал высокую точность подсчетов, был недорогим в производстве и мог менять конфигурацию в зависимости от потребностей заказчика. Год спустя мы с командой получили на него патент. А я решил получить второе высшее образование по специальности «Менеджмент и управление проектами».

Новая «оптика» — сквозь призму проектного управления — помогла мне иначе посмотреть на мир вокруг. В тот год в составе студенческого стройотряда я попал на площадку строительства Ростовской АЭС. И меня поразило, какой это грандиозный проект, сколько людей, процессов и дисциплин в нем задействовано. И мне захотелось самому заниматься реализацией таких проектов.

Однако попасть на работу в «Росатом» было непросто. Пропуском стала стипендия имени Эрика Николаевича Поздышева — легенды атомной отрасли, бывшего директора Чернобыльской атомной станции, взявшего на себя труднейшую задачу по управлению оставшимися энергоблоками после аварии 1986 года.

Я прошел конкурсный отбор и попал на базовую кафедру НГТУ имени Р. Е. Алексеева в АО «НИАЭП» (ныне — инжиниринговая компания АО «АСЭ»), где в течение года учился управлению жизненным циклом сложных инженерных объектов. Общение со специалистами базовой кафедры позволило структурировать знания в проектном управлении и вплотную заняться реализацией собственного проекта — организации производства дозиметров нового образца. Со многими экспертами кафедры мы дружим до сих пор, и их советы не раз помогали мне в профессиональных вопросах.

Помню первый крупный проект, в котором мне пришлось поучаствовать уже в качестве молодого сотрудника. Мы внедряли технологию Multi-D — комплексное IT-решение по управлению жизненным циклом сложных инженерных объектов. Это было новое слово в управлении проектами — программа увязывала между собой календарный график, сметы и электронную 3D-модель атомной станции, предлагая на выходе подробную визуальную модель создания объекта.

Я делал первые самостоятельные шаги в проектном управлении. Новый путь оказался, пожалуй, сложнее прежнего. Но мне он подошел.

Выводы:

1. Проектное управление способно принести плоды в любой отрасли, в любом деле. Не имеет значения, идет речь о строительстве АЭС или о внедрении небольшой научной разработки. Только оценивая инициативу с точки зрения проектного подхода, есть шанс успешно довести начатое до конца.

2. Инженер смотрит на проект с одной стороны, ученый — с другой, финансист — с третьей. И только системный управленческий взгляд дает объемное видение происходящего.

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

Приступаем к проекту: чего хотят стейкхолдеры?

Автор Станислав Кречетов

Когда я приехал в Екатеринбург из небольшого городка получать образование, я был уверен, что стану металлургом. Меня уже ждала работа на крупном предприятии и место на металлургическом факультете УПИ, нынешнего УрФУ. Но, как это часто бывает, проект «высшее образование» пошел не совсем так, как мне представлялось изначально: поступив в университет, я оказался на кафедре теплофизики и информатики в металлургии.

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

---

На одном языке

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

Работа программиста в финансовой компании в то время была сложнее и ответственнее, чем сейчас. Не примите эту мысль за ностальгию по старым добрым временам. Все обстоит строго наоборот: если бы сегодня молодому и амбициозному айтишнику довелось очутиться в том времени, он бы по-братски проникся к нам сочувствием. На тот момент 95% программного обеспечения, которое использовалось в повседневной работе, было самописным: сотрудники компании создавали его под себя и свои нужды, руководствуясь исключительно личными представлениями о прекрасном.

Универсальное ПО только начинало появляться на рынке, стремительно его захватывая. Но, как любая высокотехнологичная новинка, оно было доступно не всем. Наша компания не стала исключением. На тот момент у нас была установлена старая система, разработанная прежней командой IT-отдела, и функционировала она по принципу «работает — не трогай». Работала она, увы, не лучшим образом. Но как мы ни старались, оптимизировать ее не получалось.

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

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

⠀

На одном языке

«Водопадная», или каскадная, модель обязывает разработчиков действовать строго по принятому плану, не возвращаясь назад. Работа в рамках каскадной модели состоит из пяти шагов: аналитика, проектирование, разработка, тестирование и поддержка. Пропускать этапы нельзя, как и возвращаться на предыдущие ступени, — точно так же, как вода в водопаде никогда не потечет в обратную сторону, вверх по скалам. Сегодня каскадная модель считается уже плохо применимой для разработки ПО.

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

К нашему удивлению, получить ответы на эти простые вопросы оказалось чрезвычайно сложно. Например, выяснилось, что главный бухгалтер владела программой, что называется, со словарем — точнее со шпаргалкой, на которой была записана простая последовательность нажатия кнопок на клавиатуре. Требования одних сотрудников оказывались заоблачными, других — противоречивыми. Большинство же стейкхолдеров, хоть и жаловались на прежнее ПО, высказывались в том смысле, что если уж оно работает, то и делать ничего не надо — а то, не дай бог, станет еще хуже.

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

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

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

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

В описанной ситуации мы пытались принимать решения за стейкхолдеров. А вместо этого нам следовало убедить их, что наше решение на самом деле — их собственное. Мы слишком мало задавали вопросов и слишком часто предлагали готовые ответы. А надо было действовать строго наоборот.

⠀

Изнутри

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

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

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

Кто-то из читателей уже наверняка подумал: легко сказать — убедите стейкхолдеров в том, что проект выгоден! А как это сделать? Искусству убеждения посвящена масса книг, но почему-то далеко не каждый, прочитав их, становится переговорщиком. Что делать, если не чувствуешь в себе сил воздействовать на мнение людей? Где их взять?

На самом деле, все не так сложно. Любой менеджер в той или иной степени — это специалист по продажам. Чтобы перетянуть на свою сторону стейкхолдеров, вспомните, как действуют продавцы — и применяйте те же приемы. Давайте вспомним самые простые из них.

1. Проблемное интервью

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

2. «А почему Баба-яга против?»

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

3. Демонстрация выгоды

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

4. Мнение эксперта

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

Однажды нам никак не удавалось рассеять сомнения директора нашей компании по поводу одного из проектов. Переговоры не двигались с места ровно до тех пор, пока не выяснилось, что сомневающийся директор когда-то учился азам планирования у Дмитрия Гаврилова, преподавателя Высшей школы технологического предпринимательства Санкт-Петербургского политехнического университета им. Петра Великого.

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

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

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

Выводы:

1. Общение со стейкхолдерами — необходимая составляющая успеха проекта. Начинать его надо еще до вступительной аналитической фазы. Чем раньше и активнее вы приступите к коммуникации, тем больше времени и сил сэкономите в ходе реализации проекта.

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

3. Чтобы привлечь стейкхолдеров на свою сторону, используйте техники продаж. В конце концов, вы же фактически продаете коллективу свой проект. Ваша задача — сделать так, чтобы «клиент» решил «купить» его у вас.

Круги по воде:
как планировать и внедрять изменения

Автор Станислав Кречетов

Возглавив управление крупным и значимым проектом, вы ощутите себя демиургом. Ведь вы даете людям инструменты, которые помогают совершать позитивные сдвиги в компании, а значит — вы меняете мир к лучшему. Это ощущение значимости выполняемой работы и вашего позитивного влияния на мир — одна из самых приятных сторон деятельности управляющего проектом. Но не стоит увлекаться.

⠀

Изнутри

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

Внедряемый проект не автономен — он изменяет в деятельности организации очень многое. Своевременно предвидеть эти перемены, управлять ими и синхронизировать с реализацией основного проекта — одна из важнейших задач в сфере проектного управления.

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

Возможности рынка тут почти безграничны. Системы MRP управляют хозяйственными операциями и материальными потоками, CRM-системы упорядочивают взаимоотношения с клиентами, а ERP-системы приводят в порядок процессы управления в целом. Казалось бы, нанимай специалистов по специализированному ПО, внедряй — и получай дивиденды от роста эффективности бизнеса.

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

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

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

⠀

На одном языке

ERP, или Enterprise Resource Planning, дословно переводится как «планирование ресурсов предприятия». Это класс специализированного программного обеспечения, которое консолидирует потоки информации по производственным операциям, ресурсам и активам. Данные позволяют анализировать текущее состояние предприятия и планировать дальнейшие шаги по его развитию. Как правило, необходимость во внедрении ERP-системы появляется с ростом компании, когда менеджмент уже не справляется с аккумулированием всех информационных потоков по старинке — с помощью отчетов, бухгалтерской документации и собственных наблюдений — и это начинает сказываться на качестве управления. Важно с самого начала грамотно настроить ERP-систему с учетом всех особенностей предприятия, иначе проблем от нее может оказаться куда больше, чем пользы.

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

⠀

Изнутри

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

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

Основные ошибки в планировании изменений:

1. «Проблема лоскутного одеяла»

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

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

Чтобы избежать подобных неприятностей, следует помнить: любой проект компании — это лишь часть большого действия, и нужно заботиться о том, чтобы эти части хорошо сочетались друг с другом. Из отдельных ярких «лоскутков» необходимо сшить общее «одеяло» — оно должно получиться цельным и удобным в использовании.

2. «Синдром Бога»

В одном из крупных российских аэропортов (не буду называть его — скоро вы поймете почему) к проблеме обновления процессов подходят весьма серьезно. Настолько серьезно, что для этого там создан целый блок методологов. Правда, от результатов их работы весь аэропорт стонет. Такое ощущение, что главной задачей специалистов было загрузить ERP-систему по полной программе. В итоге не система работает на людей, а, напротив, люди работают на систему.

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

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

Мы и сами не избежали вышеперечисленных ошибок. Так, нам оказалась знакома проблема «лоскутного одеяла», когда выяснилось, что внедряемая ERP-система конфликтует с действующей на предприятии PDM-системой, отвечающей за управление продуктами, и создает много препятствий в работе. Грешили мы и «синдромом Бога», когда попытались сделать нашу систему как можно более глобальной — и тем самым тормозили ход давно и успешно налаженных кастомизированных проектов. Ликвидировать ошибки на ранней стадии и наладить работу тогда помогло именно тщательное наблюдение за всеми сопутствующими процессами и последовательный фокус на потребностях каждого из подразделений.

Внедрение ERP-системы помогло нам наладить на предприятии скользящее планирование на среднесрочную перспективу — на срок до 1,5 лет. Мы стали лучше видеть загрузку каждого из подразделений, что в свою очередь упростило процессы распределения задач и бюджетирование. Самым важным следствием стало существенное снижение числа срывов в сфере поставок. Раньше, когда изготовление заказа задерживалось, сотрудники тратили массу времени на поиск виноватого. ERP-система, оценивавшая загрузку каждого, сделала эти споры бессмысленными, а значит, можно было не тратить время и сфокусироваться на приоритетных задачах.

Затем пришло время вернуться к решению главной задачи — как организовать работу завода максимально эффективным способом? Найти ответ на этот вопрос нам помогла методика «Пять почему».

⠀ ⠀

На одном языке

«Пять почему» — методика анализа проблем, созданная японским предпринимателем Сакити Тоеда, основателем компании Toyota. Она позволяет с помощью последовательных ответов на вопрос «Почему?» добраться до первопричины любой проблемы. Изначально методика использовалась для устранения неисправностей производственного оборудования и ликвидации их первопричин. Впоследствии ее взяли на вооружение предприниматели, работающие в самых разных сферах, сделав ее качественным инструментом для решения не только производственных, но и организационных проблем, повышения качества и эффективности работы.

Сегодня правило «Пять почему» в бизнесе применяется в различных модификациях и для решения разных задач. В частности, если речь идет не о том, что случилось в прошлом, а о том, что должно произойти в будущем, — то есть о перспективном планировании — эта методика может быть модифицирована в «Пять чтобы что». В этом случае вы последовательно задаете вопрос «чтобы что?» к каждой формулировке стоящей перед вами задачи. Отвечайте на этот вопрос до тех пор, пока не дойдете до конечной цели.

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

Выводы:

1. Локальные изменения тянут за собой глобальные. Заранее анализируйте, как именно изменится ситуация в результате запланированного действия, какие процессы будут модифицироваться. Понимая общую взаимосвязь процессов, вы становитесь лидером, способным предвидеть и контролировать изменения.

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

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

Часть 2.
Руководитель проектов
и его команда

Типы проектов
и их лидеры:
каждому свое

Автор Сергей Малоземов

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

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

В деловой литературе можно найти массу вариантов классификаций проектов. Мы рассмотрим классификацию, разработанную в Росатоме. Она предельно практична и охватывает фактически все виды существующих проектов, и в этом ее несомненное преимущество.

⠀

На одном языке

Классификация проектов по видам деятельности:

1. Инвестиционно-строительные.

2. Проекты НИОКР.

3. IT-проекты.

4. Организационно-управленческие.

1. Инвестиционно-строительные проекты

⠀

На одном языке

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

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