Друзья, не знаю как вы, но мы не верим в быстродействующие таблетки. Мы не верим в «похудение за 2 недели на 40 кг». Черт побери, верить-то хочется, но реальность обычно против…

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

4 года назад менеджер по управлению проектами (PMI PMP), автор книги «Управление ИТ-проектом с нуля в любой организации» Иван Селиховкин выпустил бесплатный курс «Практический PMBoK за 5 дней», который на сегодня уже скачало более 7.000 человек. Однако, не так давно Иван пошел дальше и выпустил курс «Практический PMBoK за 2.5 часа» (доступен бесплатно после регистрации).

5 дней — я еще понимаю, но 2.5 часа — как-то того… отдает похуданием за 40 минут. :) Поскольку мы с Иваном давно сотрудничаем, то решили выяснить, как так получилось, что курс ужался с 5 дней до 2.5 часов. И начав говорить, поняли, что надо делать отдельное интервью. В итоге, обсудили массу тем:

• Как из медицины попасть в управление IT-проектами
• Почему последние годы процент успешных проектов не меняется
• Три шага на пути создания проектного офиса
• Что такое гос.заказчики геройские, бизнесовые и заурядные
• Есть ли противоречие между PMI и гибкими методологиями
• …

Иван, привет! Как ты вообще попал в управление IT-проектами?

Привет!

Это такая интересная, но путаная и сложная история. Изначально образование у меня было в сфере медицины, собственно, в медицине я и работал, и в управление проектами пришел оттуда. Переход в управление проектами происходил в два этапа. Сперва я попал в сферу IT из медицины, а потом уже стал управлять проектами.

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

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

То есть, ощутил некоторую тоску, ощутил, что я не хочу этим заниматься всю жизнь. И в эту же секунду понял, что из медицины надо уходить. Там есть свои плюсы, есть свои минусы. Это решение я помню отчетливо: помню операционную, помню, как там пахло… И ушел в сферу IT.

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

Довольно быстро я устроился на работу, параллельно с работой учился, и это были первые полшага в сторону менеджмента. Учился на программиста.

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

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

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

И здесь произошел эффективный переход в менеджмент.

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

(Лучший доклад конференции Стратоконф: И.Селиховкин «Чему хороший ПМ может научиться у хорошего врача»")

А в какой момент в твоей жизни появился PMI?

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

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

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

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

Слушай, а почему PMI, а не гибкие методологии, которые там становятся все более или более популярными в последние годы?

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

«Тяжелая методология» – мной используется как термин для внутреннего использования, к этой же категории я отношу PMI или PRINCE2, еще охапку таких тяжелых, тяжеловесных стандартов. Я считаю субъективно – лично я, что менеджер в проектах должен владеть хотя бы одной тяжелой методологией. В противовес тяжелым я беру легкие. Это все что можно, опять же, всевозможные Agile и так далее.

Отличие в том, на мой взгляд, что тяжелая методология, как правило, не обязательно, но часто претендует на универсальность: не только позволяет управлять проектами. Вернее, не только разработки софта, но и проектом в целом. Тяжелая методология – да, она более универсальна, она подходит IT-шным и не IT-шным компаниям, но с другой стороны, у них высокий входной порог. То есть, чтобы ее освоить и начать из нее извлекать пользу, нужно потратить много сил, в отличие от гибких подходов, того же Kanban и Scrum, который можно воспринять очень, очень быстро, в течение дня. И в течение первой недели уже набить нормальные шишки и делать проект.

Тем не менее, мне кажется, менеджеру нужно иметь в арсенале одну тяжелую методологию, и совершенно не важно, какую. На PMI свет клином не сошелся. Если бы я к тому моменту знал какую-нибудь другую тяжелую методологию, я бы ее использовал вообще без проблем. ПЛЮС произвольный набор легких.

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

PMI, опять же, порой ошибочно противопоставляют гибким методологиям.

В последней редакции PMBoK, если посмотреть, там итеративный цикл разработки, прямо нарисован, там картинка. PMBoK подчеркивает: вот так и работайте. PMI сертификацию ввел по Agile и теперь тоже «страху дает» желающим. К ним очень по-разному относятся, в том числе и я, со скепсисом. Но не суть. Для меня PMI и Agile остались рядом стоящими.

С этим понятно, а что тебя подвигло записать в свое время курс «Практический PMBoK за 5 дней?»

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

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

Это для меня еще такой магнит, который обеспечит притяжение интересных людей. Довольно сложная это история: найти в жизни и в профессии людей интересных. Для этого есть разные способы, и бесплатный контент, курс «PMBoK за 5 дней» мне довольно сильно помог. Достаточно много людей мне говорили «Спасибо!», некоторые задавали вопросы, некоторые вступали в переписку, генерили идеи. И я с достаточно интересными людьми познакомился. Я думаю, что в свое время он полностью окупился – если он проектную энтропию в мире понизил, кого-то сделал, может быть, чуть более довольным, – ну и прекрасно. Значит, я усилия потратил не зря.

В какой момент «Практический PMBoK за 5 дней» стал «PMBoK за 2,5 часа»? Когда ждать «PMBoK за 15 минут»?

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

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

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

С другой стороны, какие-то вещи я стал объяснять, на мой взгляд, лаконичнее, с меньшим количеством воды не в ущерб материалу, – поэтому и объем курса удалось снизить с пяти занятий фактически до двух. Соответственно, курс был переименован в «PMBoK за 2,5 часа».

«PMBoK за 15 минут» ждать вряд ли стоит. Не думаю, что можно существенно еще сократить подачу материала, не потеряв где-то в смысле. Когда я записал «PMBoK за 2,5 часа», был еще один замысел – записать более-менее развернутый открытый курс – сейчас он состоит из трех занятий, – посвященный проектному менеджменту в целом. И «Практический PMBoK за 2,5 часа» – это третье занятие этого курса. Первые два тоже знакомят людей с тем, что такое вообще проектное управление, что такое легкие и тяжелые методологии. И уже на третьем занятии тем, кому интересно, я предлагаю нырнуть в недра PMBoK.

Кстати, по поводу последней версии PMBoK, что изменилось по сравнению с предыдущей?

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

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

Из других отличий… Довольно много мелких отличий, которые, может быть, замечают какие-то знатоки PMBoK. Но так, со стороны, если я начну комментировать, просто будет не понятно. Многие пожмут плечами: «Ну и что, какая разница?». В целом, я бы сказал, что PMBoK становится более выверенным, более точным. Даже вот третья редакция в свое время была такая водянистая, напоминала некоторые непонятные документы, с которыми я по работе сталкиваюсь частенько. Четвертый уже был неплох, пятый просто отличный. Мало лишнего, все по делу.

PMBoK становится все более гармонизирован, например, со стандартами ISO, с тем, что касается работы с качеством, работы с рисками. Собственно, это и бросается в глаза. Из таких наиболее понятных изменений – некоторые вещи просто исчезают из PMBoK. И одно такое понятное, очень конкретное изменение – исчезли все упоминания про проектный треугольник.

Ничего себе.

Люди со стажем, может быть, оценят. Казалось бы, такой бренд, который, по-моему, PMBoK ввел в свое время типа triple constraint – тройственное ограничение: сроки, состав работ и бюджет.

PMBoK вообще убрал треугольник, картинку убрал, само слово triple constraint в PMBoK больше не встречается. Как я понимаю, чтобы не вводить менеджеров в искушение, что я в треугольник уложился с проектом. Это не так, я все равно треугольник использую для того, чтобы объяснить, как PMBoK предлагает планы строить, базовые планы. У PMBoK это и есть грани треугольника. Если разобрать с этой точки зрения, многое ложится гораздо легче. Сам PMBoK, повторюсь, треугольник со своих страниц убрал, чтобы менеджеры на нем не зацикливались и не думали, что если в треугольник уложился, то в общем молодец.

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

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

Человечество вообще плохо умеет управлять проектами, это вполне естественно.

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

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

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

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

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

Загадка, где он может его получить, если сама жизнь не предлагает ему его опыт разнообразить? Но это важно, на мой взгляд. Получить разнообразный опыт можно, с одной стороны, меняя место работы. Я не говорю – прыгать с работу на работы – но менеджер, который управлял разными проектами, в госсекторе и не в госсекторе, с распределенными командами, и с командами, которые в одном и том же месте сидят, более гибкий.

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

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

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

Понятно, The Chaos Report – не про Россию, он вообще про мир. Но я думаю, что проблема такая же, всюду одинаково.

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

Очень часто я наблюдаю, как сами менеджеры превратно понимают менеджерские обязанности, то есть, многие мои коллеги работают в авральном режиме, включаясь только время от времени.

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

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

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

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

Менеджеров поругал, теперь бизнес поругаю.

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

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

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

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

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

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

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

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

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

Главная мысль – проектный офис это проект. Как это ни парадоксально, но это не очевидно большинству людей, то есть, строить проектный офис нужно в рамках проекта, – моя настойчивая рекомендация. С чего бы вы начали любой проект? Я бы начал его с того, чтобы спросил, а в чем цель, зачем? Мы строим проектный офис? OK – зачем? Правильно и вовремя заданный вопрос «зачем», а именно, в самом начале, – он от многих проблем вас убережет.

Зачем надо строить проектный офис, и зачем НЕ надо строить проектные офисы?

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

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

Первый вопрос – «Зачем», какова цель, чего вы хотите достичь?

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

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

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

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

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

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

Следующий шаг, он тоже один из самых ранних, это опрос заинтересованных лиц.

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

Для того, чтобы эти изменения произвести, нужна огромная энергия и огромная власть внутри компании.

То есть, когда организация загорелась идеей проектного офиса, даже выделила человека на это (часто это какой-то умный человек от проекта), важно спросить себя, хватит ли полномочий и энергии у того, кто это все запускает?

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

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

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

Хм, никогда не задумывался о проектном офисе как о проекте… Иван, я знаю, что ты много работаешь с гос.заказчиками. В компаниях, которые никогда с ними не работали (продуктовых, аутсорсинговых) – гос.заказчики воспринимаются как этакий Мордор, куда не понятно, как подходить, особенно если у тебя нет отката минимум 70%. Как вообще работать с гос.заказчиками, какие там особенности, принципы? Поделись своим опытом.

Да, действительно, Мордор немножко…

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

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

А есть какое-нибудь РАО «РЖД», то есть, компания с гос.капиталом. Это вроде уже и бизнес, но вроде еще и гос.сектор тот же. Влияние гос.сектора очень велико, и я бы их воспринимал тоже как гос.заказчика скорее, чем какую-то коммерческую фирму.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Когда готовишься к такой сертификации, волей-неволей мобилизуешься, подбираешься внутренне. Ведь что такое сертификация, что такой экзамен PMP на знание Project Management? Это набор ситуационных задач, около четырех часов тебя бомбят ситуационными задачами и просят выбрать правильный вариант поведения с точки зрения PMBoK, с точки зрения стандартов проектного управления. И ты четыре часа отвечаешь на эти вопросы, а потом получаешь итог: в теме ты или нет? Это достаточно интересно само по себе, и подготовка, и сам сертификат многое дает. Опять же, субъективно помогает многое понять.

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

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

Это большая вероятность получить интересное предложение: «Вот у нас консалтинговый проект, чтобы его выиграть, нужно привлечь в команду еще PMP-шника. Не хватает одного – пойдешь?»

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

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

Говорю субъективно, о том, как я бы делал на месте начинающего менеджера, – собственно, примерно так я и делал.

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

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

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

Просить больше ответственности и не просить за это денег.

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

Не бояться провала, не просить денег поначалу, пока вы действительно ничего не умеете.

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

Особенно в заказной разработке это имеет смысл. Это самое страшное в работе менеджера, мне так точно – страшнее всего именно это. Прийти к большому человеку, у которого гигантский кабинет, две приемных одна за другой, и вообще звонить ему нельзя, – и завести с ним какой-то конкретный предметный разговор и быть осмеянным, услышать: что за мальчишка вообще пришел?! Мне это психологически тяжело, например. Но это самое полезное, что может быть вообще в проектном управлении.

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

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

Понятно. Иван, а какие у тебя любимые книжки по управлению проектами?

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

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

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

Генри Минцберг «Структура в кулаке» (Structure in Fives). Книжка тяжелая для прочтения, немножко кондовым языком написана. Посвящена разным структурам компании. В свое время прочитал, у меня прямо в голове сошлось, куда я лез со своим проектным управлением, почему оно там не могло никак прижиться по определению просто. Тоже много взял на вооружение. Очень сильно перестроил свои подходы к проекту.

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

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

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

Возможно, именно вы скажете какое-то свое слово в проектном менеджменте. Мой призыв – набирайтесь опыта и не молчите. То есть, пробуйте всякое разное, а потом рассказывайте, что попробуете. У меня лично большое желание почитать какие-то интересные менеджерские заметки, поговорить с людьми-практиками. Если набравшись опыта, вы будете делиться им в какой-то нетривиальной манере, будет круто. Я с нетерпением буду ждать чего-то нового!

ОК. Иван, спасибо большое! Удачи!

Автор: eagleson

Источник