В преддверии старта новой программы по управлению проектами, мы встретились с нашим экспертом и по совместительству вице-президентом Санкт-Петербургского филиала PMI Иваном Селиховкиным, чтобы узнать, чем дышит отрасль управления проектами сейчас.
Иван Селиховкин
Ну, могу нарисовать скорее обобщенный портрет довольно типичного заказчика. И его проблемы понятны, и зачастую исходят из его характера. То есть, очень часто то, с чем приходится иметь дело лично мне, это российская компания, которая за какой-то предыдущий период быстро выросла — разрослась с десяти человек до ста человек или с десяти человек до трехсот. То есть, выросла достаточно, до такого размера, где управляемость перестает быть интуитивной, но в то же время проблемы эффективности заботят первых лиц, руководителей бизнеса.
Проблемы, с которыми эта компания сталкивается, можно разделить на несколько категорий. С одной стороны есть бизнес, у этого бизнеса есть проектное управление, а бизнес не понимает, как свои интересы транслировать в менеджеров проектов.
Менеджеры что-то делают, команды работают, ребята все хорошие — бизнес не очень счастлив. И он не знает, как ему еще объяснить, что ему нужно. Он не всегда может это сформулировать. Менеджеры не всегда его слушают. Это первая группа проблем, вокруг которой бизнес переживает и пытается, в том числе при помощи «правильного» проектного управления ее решить.
С другой стороны, сами менеджеры, я имею в виду — само проектное управление внутри. Бизнес, как правило, не знает, как оно должно выглядеть, и не хочет в это лезть, что вполне оправданно. Ему не интересно вникать в нюансы. Он надеется, что те, кто у него есть — те люди, которые в нем уже работают, они в этом разбираются, — но тоже не уверен. Переживает. Думает, что вдруг причина неэффективности в том, что проектное управление какое-то «неправильное».
Ну и третье — это люди. Людей на рынке не хватает вообще, инженеров и менеджеров, и разных специалистов. И третья группа проблем широкая — это как их растить, как их удерживать, что еще сделать, может ли на это проектное управление как-то повлиять. Обычно из того, с чем мне не доводилось работать, эти три группы проблем всплывают точно, и про них надо что-то обязательно говорить, предлагать, искать совместное решение.
Иван Селиховкин
Здесь я бы попытался ответ разбить на две части. Как обычно — для меня это обычно, — задать себе вопрос: а кто такой менеджер проектов? Что он делает? Чем он занят вообще? Может быть, исходя из этого, легко найдется ответ, чего ему не хватает.
С моей точки зрения, менеджер проекта занят, во-первых, своей карьерой. Сейчас в меня полетит тухлый помидор, но на самом деле среди менеджеров проектов гораздо больше людей тщеславных. Их удельный вес очень высокий. Это не хорошо, не плохо — это факт. И я, наверное, довольно тщеславный. Менеджер, первое, делает свою карьеру.
Второе — он обслуживает интересы бизнеса, в чем-то бизнесу помогает. Как любят говорить мои коллеги, раз менеджер проекта не приносит напрямую деньги, он чем-то другим полезен бизнесу. Он не зарабатывает, он не сейлз, но что-то такое привносит со своей стороны.
И третье — менеджер проектов отвечает за команду. Это человек, который ведет за собой команду и отвечает не только за свою карьеру и за то, чтобы понравиться бизнесу, а еще и чтобы как-то представлять команду, быть адвокатом команды, и не только.
И как правило, какая-то из этих трех ног у менеджера хромает. Например, присутствует перекос в строительстве карьеры, если человек чересчур тщеславен, и ему плевать на все. Это быстро выжигает этого менеджера изнутри и сжигает за ним мосты, с ним перестают работать. Как и наоборот: отсутствие тщеславия полное — это противопоказание быть менеджером, безусловно. Потому что в этой профессии для менеджера проектов очень много агрессивного и тяжелого, и чтобы ее любить, нужен какой-то мотиватор. Хотя бы в виде тщеславия, хотя бы небольшой его доли.
Точно так же с бизнесом. Бывает, что менеджер легко не находит с бизнесом общий язык — а это иногда встречается, когда менеджер очень академичен, он говорит: “Вы дураки, и не лечитесь. И управлять проектами нужно так, а не иначе, немедленно измените это все в своей компании вы, уважаемый TOP-руководитель”. Но так, как правило, никогда не случается. Вот умение воспринимать, чего бизнес хочет от проектных команд и подстраиваться адекватно под них, это важно.
Точно так же — и отвечать за команду. Это очень частая боль, особенно у адекватных людей. Потому что менеджер часто бывает либо диктатором по отношению к команде либо, наоборот, нянькой. Это такой соблазн: начать заботиться, гипер-опекать команду, и так далее. Найти баланс, поймать его, как-то не бояться суровых строгих инженеров, которым ты, может быть, не являешься на глубоком уровне, не во всех областях, которыми занимаешься, и в то же время не проявлять жесткость чересчур — этот баланс редко у менеджера находится.
Мы в одном из сообществ, которыми я занимаюсь, пытались как-то представить, из чего состоит менеджер проектов— хорошо, грамотный, сбалансированный, гармоничный менеджер проектов. И нарисовали такого паука: MindMap. Получились у этого паука несколько ног, ключевые из которых — это soft skills, методики, методологии. Ну еще отраслевые знания, но это немножко, маленькая такая нога, которая у каждого «паука» индивидуальна.
Так вот, большинство проблем отнести можно к чему-нибудь из этих четырех вещей. У кого-то хромают soft skills, у кого-то, наоборот, хромает все остальное, но на soft skills человек пытается вытягивать. Его иногда называют демагогом, человеко-менеджером или разными другими обидными словами. У кого-то не хватает методических вещей: человек просто не знает, какие инструменты можно применять, а у кого-то – методологии, то есть, человек знает разрозненные инструменты, но никак не может увязать их в связную последовательность действий, которая в одном случае нужна такая, а в другом — иная. Вот, пожалуй, из таких двух частей я бы отвечал на вопрос. Задумывался бы о том, кто такой менеджер, и чем он бизнесу полезен, а с другой стороны, задумывался, из чего состоит гармоничный менеджер. Вот обычно тут и можно найти недостатки.
Да. Здравый смысл, безусловно, оборачивается в новые и новые конфетки. Они продаются под разными брендами. Это касается гибких и негибких подходов. В самих гибких подходах неудержимый поток, все новые и новые появляются на этом поприще истории. Поскольку я фокусировался последние два года на отделении PMI, то я на все это смотрел немножко сквозь призму PMI.
Не готов сказать, что я проанализировал весь рынок проектного управления и точно знаю все нюансы, — но из того, что вижу я в контексте PMI могу сказать, например, что PMI очень много вобрал в себя после этого бума двухтысячных имени гибких методологий. Четвертая и пятая редакции PMBoK здорово перестроились, и сейчас существует, например, PMBoK Software Extension, который просто… открываешь его — и как к себе домой. То есть, там спринты, беклоги, ретроспективы и все то, за что мы любим гибкие методологии, там прямо вобрано в него.
То есть, первое: традиционные стандарты тоже подстраивались и менялись и очень много вобрали в себя… Этот бум научил их очень многому. И во многом проектное управление изменилось благодаря этому буму сейчас, это первое.
Во-вторых, разнообразие, как ни странно, провоцирует и обратный процесс — поиски однообразия. То есть, когда у вас распределенная команда, когда у вас есть рынок менеджеров проектов («вам» — я имею в виду, некоторым видам бизнеса, некоторым корпорациям) нужно иметь надежные точки опоры, чтобы вы были уверены, что люди говорят на одном и том же языке и имеют минимальный достаточный набор навыков, нужных вам. В этом смысле очень усилились поиски единого стандарта в части управления проектами.
Ну и опять же, хорошо заметный мне процесс — очень больших успехов здесь достиг PMI и PMBoK. В частности, PMBoK стал в 2012 году стандартом ISO, чуть раньше он стал стандартом IEEE, а до этого он давно был американским стандартом ANSI. Но за счет того, что PMBoK стал, в том числе, в 2012 году стандартом ISO, он также стал стандартом в России, лег в основу очень многих ГОСТов и, в частности, основ национального стандарта, переведенных на стандарт ISO, который тоже у нас фигурирует. То есть, если задаться вопросом, существует ли всемирный стандарт проектного управления, то самый честный ответ — нет, совсем всемирного не существует. Но что ближе всего к нему подошло, это PMBoK за последние три года. Повторюсь: PMBoK, вобравший в себя очень много из гибких методологий и вырастивший отдельное ответвление от себя. Вот это наиболее заметно для меня.
Ну, еще один тренд — люди пытаются интегрировать разные методологии, скажем, Prince, PMBoK, что-то похватав из IPMA, и слепить во что-то одно. Тоже эти попытки регулярно предпринимаются. Больших успехов нет, но я с интересом отслеживал несколько из них. Вот, пожалуй, те тренды, которые я увидел.
Если говорить о том, что человек не хочет расти в менеджеры, не имеет такой цели и вполне себе счастлив, будучи, например, просто инженером и развиваясь как незаурядный инженер, — то проектное управление в любом случае его касается просто потому, что внутри проектного управления происходит коммуникация этого инженера и какого-то руководителя, например, проектного менеджера.
Что было бы полезно изучить, это методические вещи. Нет особенного смысла изучать методологии, вникать в нюансы PMBoK или пытаться в нюансах представит себе, как работает канонический Scrum или что-нибудь еще. Или в каких случаях лучше подходит Scrum, в каких — Kanban. Но полезно владеть менеджерским арсеналом, методиками приемов: как можно уточнять собственные оценки, как можно быстро прикинуть собственное расписание — собственное или своей группы, ну и так далее.
Всех этих методик, этих отдельных инструментов разрозненных много, и вот с ними наверняка инженеру придется иметь дело. При этом это как раз та вещь, в которой инженеры часто оказываются грамотнее менеджеров. Потому что менеджер в книжке прочитал и пришел к инженеру спрашивать. А инженер зачастую обладает математической грамотностью и просто большим инженерным здравым смыслом. Поэтому инженер не только может выстраивать эти отношения с менеджером — все равно придется, рано или поздно, — но и здорово помочь себе, команде и этому самому менеджеру, поправив его, схватив за рукав, удержав от каких-то существенных ошибок. То есть, короткий ответ: инженеру есть смысл изучать методические вещи и не сильно заморачиваться методологией, на мой взгляд.
Я ремонт делаю по Kanban. Вне IT управление проектами применяется достаточно широко. Но я просто регулярно занимаюсь проектами не IT-шными, консалтинговыми, это настоящие проекты с очень многими, привычными и в IT-проектах артефактами.
А в жизни… Я, в общем, всегда предостерегаю от воинствующих карго-культов. То есть, не нужно привносить все нюансы проектного управления во все аспекты своей жизни. Опять же, тут не нужно позволять методологиям обмануть здравый смысл. И это то, что лежит в методологической плоскости. Где подойдет Kanban, где простая наклейка на холодильник, а где что-то более тяжелое — это вопрос методологической грамотности потенциальных менеджеров.
Весь 2021 год мы уже работали как компания, юридически расположенная в Евросоюзе, и планомерно переносили в эту юрисдикцию основные бизнес-процессы, включая прием платежей, основные расходы и уплату налогов.
Справившись с первым шоком и стабилизировав работу команды, 01.03.2022 мы заявили, что останавливаем коммерческие проекты и ближайший месяц перебрасываем все силы на проведение поддерживающих психологических семинаров для всех, кому нужна поддержка в это непростое время.
Понимая, что наш статус EU-компании и принятое решение остановить все коммерческие активности дают нам немного времени (наши налоги уже не работают против людей), следующие 10 дней мы уделили организации и запуску открытого бесплатного проекта поддержки для всех наших клиентов и подписчиков.
За это время стало окончательно понятно, что мы больше не можем поддерживать своими налогами путь, который выбрала РФ, поэтому мы прекращаем экономическую деятельность в России — наша компания не принимает платежи и не платит налоги на территории РФ.
Текущие, запущенные проекты мы доводим до конца, так как всегда выполняем все взятые на себя обязательства, как и все предыдущие 12 лет нашей бизнес-практики.
Мы — бизнес-школа, учебное заведение. В мировой истории было достаточно позорных моментов, когда образование было недоступно людям с определенным цветом кожи, определенной национальностью или в силу других дискриминационных признаков.
Мы не поддерживаем дискриминацию в любом ее проявлении, в том числе по цвету паспорта людей, которые к нам приходят.
Мы будем работать с теми студентами, кто готов при поступлении подтвердить свою позицию относительно дискриминации и согласиться с нашими правилами работы.
Мы всегда работали на русском языке, с момента основания Школы. Русский — 8-й язык по количеству носителей в мире и это язык, на котором мы думаем и работаем. Наша задача — оставаться лучшей школой для тимлидов и менеджеров, и мы можем это сделать, работая на русском.
С пониманием ко всем, кто придерживается другой точки зрения, мы оставляем за собой выбор принимать обоснованные и последовательные решения в интересах наших клиентов во всех уголках мира.
