Беседы об управлении проектами. Часть 1.

После получения результатов опроса «Какая методология используется в вашем проекте?», стало понятно, что опять ничего не понятно. Что такое «Agile собственного приготовления»? Почему треть команд работают «как получится» и «через %опу», и ситуация не меняется? Это только у нас вот так  или на Западе тоже?

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

Иван, Миша, привет! Как оцениваете результаты опроса 2017?

[М.Р.] Всем привет! Несерьезный опрос подтверждает серьезные тренды =) Радует, что более 50% используют гибкие и бережливые подходы в работе, и этот показатель имеет в целом положительную динамику. Настораживает, что 8% используют Waterfall. Расстраивает, что более 30% до сих пор работают «через %опу» или «как получится».

[И.С.] А я считаю, что то, что лидируют «как получится» и «…собственного приготовления» — это хорошо, правильно и разумно.

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

Большинство стандартов очень легко относятся к выборочному использованию. Кроме, кстати, SCRUM-guide, где в описании фреймворка прямо “русским по белому” на странице 21 сказано «Роли, артефакты, правила и события Скрама не подлежат  изменению. При внедрении отдельных элементов данного фреймворка, полученный  результат не может называться Скрамом» (ну, то есть «ничего менять нельзя, не меняйте ничего»). Как-то в нем это сочетается со сказанным в манифесте «Люди и взаимодействие важнее процессов и инструментов».

В методологиях есть основа, некая мысль, или, как сказал бы Миша Рыжиков “мякотка”. То, в чем основная идея, без чего работать не будет. Ну, например, в Kanban это визуализация процесса, уменьшение Work in progress, выявления бутылочных горлышек для ускорения Time to market. И вот можно еще пару тезисов добавить, и это будет основное. Все, что служит этой цели — соответствует «духу канбан» и именно это тебе, менеджеру, и поможет. Какие роли, какие инструменты — все

orlov001m-800px
вторично, «мякотка» — она главное.

В PMI «мякотка» — это условно-неизменный устав проекта и гибкие планы (обычно, иерархические), которые можно очень сильно менять, уточнять. И охапка инструментов, которые тебе, менеджеру даны, чтобы «впихнуть невпихуемое», чтобы у тебя расписание не перерастало те сроки, которые заказчику обещал, чтобы «содержание проекта» не расползалось бесконечно, но и пользователи и заказчик не чувствовали себя обманутыми. Используй что нравится, но главный принцип, он вот такой.

Даже знаменитая методология «через %опу» — это не мрак, тлен и уныние. Иногда, это пример слишком серьезного отношения к «чистоте методологий».

Мне случалось видеть (преимущественно, в гос.секторе) глубоко демотивированные команды, безнадежно пофигистичное отношение ко всем, невыполнимые планы, которые нельзя менять и от которых нельзя отказаться. Короче, я видел, что такое на самом деле «через %опу». И я не верю, что это массово.

А приспосабливать методологии под себя можно и нужно. В этом смысле «SCRUM собственного приготовления» — очень правильный вариант. Сама формулировка говорит «люди переживают, что у них SCRUM какой-то не такой», но это же правильно! Фреймворки, стандарты, методологии — не святые коровы. Их нужно допиливать. Главное, чтобы «мякотка» не страдала, и чтобы работало так, как вам нужно. :)

Знаете ли вы серьезные исследования проектного управления, и подтверждают ли они картину этого несерьезного опроса?

[М.Р.] Не готов ответить за проектное управление в целом, но касательно гибких и бережливых подходов к разработке ПО рекомендую взглянуть на два бесплатных международных ежегодных отчета: 11-th State of Agile Report 2016 и State of DevOps Report 2017. Это позволит лучше понять тренды в применении гибких и бережливых подходов по всему миру. Для затравки, приведу пару результатов этих исследований, ну а глубже уже сами почитаете по ссылке:
Распределение по использованию различных Agile-фреймворков, подходов на 2016 год.

orlov001m-800px
Показатели по частоте установок, скорости поставки (time-to-market) и скорости реакции на инциденты.

[И.С.] По опросам видно, что в России Agile популярнее других подходов. И это правда. Другая правда, кстати, в том, что Agile — слишком широкий термин, по сути, система ценностей). Как мне быть, например, если считаю, что «люди и их взаимодействие важнее процессов и инструментов», но при этом использую Prince 2? Я вот как бы что-то практикую, и есть ли в этом противоречие? :)

Насколько я знаю, никто в мире не может корректно сравнить востребованность SCRUM, PMI, MSF и прочих — не удается сформулировать критерии. Менеджмент вообще сильно закрыт от научных исследований (перекрыт всевозможными соглашениями о неразглашении (NDA) и прочими «коммерческими тайнами»). PMI, к примеру, проводит подробные и достоверные исследования на предмет того, кто проектами управляет, сколько в какой стране за это платят (Россия, Украина и Беларусь не учитываются), и от чего это зависит (например — Project Management Salary Survey, пример от 2015 года здесь: https://www.pmi.org/learning/careers/project-management-salary-survey). Но там опять же нет данных о сопоставлении подходов.

Если говорить о субъективных впечатлениях (кто и что использует) — как-то развлекался, изучая статистику поисковых запросов google.

Сравнивал за периоды 2004-2017 популярность по регионам двух запросов: PMI (именно тот PMI, который относится к управлению проектами, а не к индексу промышленного производства) и SCRUM.

Картинка была примерно такой: PMI [Институт управления проектами] (красный) vs. SCRUM (синий):

orlov001m-800px

Мой друг Уехал в Австралию (навсегда). Он бизнес-аналитик. Помню, как спустя первые полгода мы плотно общались — говорил «все пропало, туту аналитики не нужны, у всех SCRUM» (и слово «SCRUM» произносил таким страшным голосом). В итоге, переквалифицировался в юзабилистов и счастлив (я до конца так и не понял, почему с его слов в австралийском SCRUM юзабилисты нужнее аналитиков) :)

При этом (вот теперь личный опыт), последние годы много общаюсь с западными (а не австралийскими) менеджерами. Возможно, это специфика моей тусовки, хотя она очень ИТ-шная, крайне разношерстная, и, думаю, вполне репрезентативная. Когда я говорю о SCRUM, коллеги из США и Европы меня не всегда понимают. Все знают слово Agile (он, скорее, как система ценностей — с ней все согласны, грубо говоря что-то вроде «за бумажками важно не потерять человека»). И далеко не все ИТ-менеджеры с ходу понимают, что такое SCRUM.

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

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

По вашим ощущениям, что изменилось в индустрии за последние два года?

[М.Р.] На крупных отраслевых конференция и в профессиональных сообществах уже все меньше и меньше обсуждаются практики, подходы и инструменты на «уровне команд», а все больше и больше обсуждаются подходы к масштабированию Agile на уровне крупных компаний с большим количеством команд разработки и мощным стыком с не IT-шным бизнесом. Сейчас набирают популярность такие фреймворки и подходы, как: Scaled Agile Framework (SAFe), Large-Scale Scrum (LeSS), The Nexus Guide и прочие.

Можно с уверенностью сказать, что теперь Agile уверенно пытается проникнуть в российский Enterprise, т.е. крупные компании и государство всерьез задумались о необходимости меняться, менять подход к организации работы, дабы не проиграть в конкурентной борьбе небольшим и агрессивным компаниям. На данный момент волна, так называемой, «Agile-трансформации» захлестнула: банковский сектор, телеком, IT в медицине и гос.секторе. Все начинают создавать/наращивать/обновлять свои IT-лаборатории и бегают «с фонарями» по рынку труда, ищут просветленных Agile-коучей и Scrum-мастеров. =)

Еще одно из изменений, Agile ценности и принципы, а также практические наработки: фреймворки, подходы, инструменты, «вызревшие» в IT-индустрии, начинают адаптироваться и в других областях: бухгалтерия, маркетинг и т.д. Также появился новый тренд Business Agility. Буквально недавно меня пригласили рассказать об Agile и Lean на Петербургском Медицинском Форуме, целевая аудитория которого  —  руководители и врачи коммерческих клиник. Скажу честно  —  это был интересный опыт.

[И.С.] В мире за два года ничего драматически не поменялось. Там «стабильность» лет десять уже. Есть проектные подходы (PMI Prince 2, IPMA и другие). Есть продуктовые (SCRUM, например). И те, и другие, по большому счету были придуманы лет 50 назад (например, родоначальник термина «Водопад», Winston W. Royce в статье «Managing the Development of Large Software Systems» (1970) некоторые принципы Agile предвосхитил, например, итеративную разработку).

Время от времени кто-нибудь перепаковывает термины, и это не надолго становится «сенсацией». Возникают какие-то гибриды.

Отвлекаясь от проектного управления, в регулярном менеджменте то же. Вот, например, была книжка по спиральной динамике (но она трудно читалась). А потом Фредерик Лалу написал «Открывая организации будущего» — и она стала хитом. Люди отправились серьезно обсуждать, когда у руля встанут бирюзовые организации (без иерархии) и можно ли всерьез сделать это в нашей компании и как. Вот в последние 2 года это и до России докатилось, пообсуждали немного (Герман Греф не преминул поговорить). При том, что этой теме тоже больше полувека. Обожаю Генри Минцберга (рекомендую его «Структуру в кулаке» — «Structure In Five»), он очень здорово анализировал, каким компаниям подходит какая иерархия, и почему одни хороши в механистических структурах, а другие — в адхократиях, и как одно в другое превращается.

Говоря о России, продолжается то ли кризис, то ли стагнация. Это косвенно сказывается на проектном управлении.

Денег стало мало. Бизнес отреагировал. Фактически, менеджеру проектов, который хочет рулить чем-то сложным и интересным (я сужу в первую очередь по ИТ сфере, но не только по ней) приходится становиться перед выбором: либо компании работающие на западных заказчиков, либо государственные или очень близкие им структуры. Раньше было очень много вариантов «посередине». Какие-нибудь компании 100 — 150 человек, работающие на российский рынок и эпизодически на зарубежный. А сейчас довольно жесткое расслоение.

Менеджмент в этих крайних вариантах и раньше сильно отличался. Компании, работающие на западных заказчиков — они разные, но, например, в ИТ огромную долю (сильно больше 50%) занимают аутсорсеры. Компании, которые иногда еще называют полушутливо «Bodyshop». Они продают руки и головы инженеров + свои компетенции + некоторые гарантии качества западным заказчикам. В таких компаниях на первом месте всегда «Accounting» (работа с заказчиком). Это не пресловутое agile-овское “работа с конечным пользователем”, нет, это обхаживание того, кто платит. «Самого-главного-на-стороне-заказчика».

Управление там часто трансформируется так: на первом месте сейлз [с нашей стороны] и «топы-со-стороны-заказчика» с их стороны. Всевозможный софт-скилз, создание доверия. А на втором-третьем местах уже хороший продукт, результат, командная работа. В таких компаниях одинаково хорошо себя чувствуют и PMI (и другие классические), и Agile (и другие гибкие) подходы. Но они одинаково не на первом месте, но все же очень важен результат. Важно, чтобы то, что создается, заработало (жили как-то до проекта, а вот после проекта должно обязательно возникнуть что-то новое, за что мы платим).

Компании, «гос.» (органы власти, ФУПы, ГУПы, компании с гос. капиталом и работающие на гос.сектор) — там на первом месте GR (Government Relationship). Как человек чуть меньше половины карьеры, проведший именно в афилированных с государством компаниях (я занимался медицинским ИТ, а на заре своего становления — почти все масштабное медицинское ИТ было государственным) — хорошо знаю, как там появляются и заключаются контракты, как принимаются работы. Очень важна лояльность, субординация. Переработки «вне контракта» так же горячо приветствуются (и являются частью «лояльности»).

Как поучал меня один мой начальник:

— У нас в госе есть одно запрещенное слово на «О».

— Какое? — наивно спрашивал я.

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

— Ответственность, — отвечал коллега.

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

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

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

И вот, в последние 5 лет перед отечественным менеджером встал серьезный выбор…

Продолжение следует… >>