PMBoK за 2.5 часа: интервью с Иваном Селиховкиным
Друзья. не знаю как вы, но мы не верим в быстродействующие таблетки. Мы не верим в «похудение за 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 декабря этот год заканчивается. В конце года все комментирование должно быть закрыто, и работа формальн
