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

Меня зовут Павел Громов, я айтишник с 2005 года. Побывал в ролях сисадмина, программиста 1С, руководителя отдела, ИТ-директора. Потом пошел в сферу управления проектами и попробовал себя в качестве РП с двух сторон – и от заказчика, и от исполнителя.

А сейчас стал руководителем проектного офиса – в терминологии компании «ИнфоСофт» руководитель департамента.

Кроме работы я люблю горы, велосипеды, мотоциклы. Как говорит мой друг: «Ты любишь все, что тебя пытается убить».

Сейчас я хочу продолжить тему моего доклада на INFOSTART EVENT 2022 – расскажу о новых этапах в истории реорганизации нашего проектного департамента:

• Что изменилось с того времени – какие ключевые решения мы приняли и каких результатов достигли.

• Какие факторы подтолкнули нас к новым изменениям и с какими проблемами мы столкнулись.

• Как мы разрабатывали и утверждали новые роли.

• Как преодолевали сопротивление изменениям от команды.

• Как работали с эффективностью, и что такое эффективность в нашем понимании.

• И когда, на наш взгляд, стоит начинать менять структуру управления в подразделении.

Доклад INFOSTART EVENT 2022

Кратко напомню, о чем я рассказывал в своем предыдущем выступлении:

• О проблемах, с которыми столкнулся наш проектный департамент на момент до начала внедрения изменений.

• О том, как мы реорганизовали структуру команды и в процессе изменений выросли в два раза – с 25 до 50 специалистов.

• Как мы научились работать со стажерами и экспертами – выстроили систему наставничества.

• Как улучшили мотивацию и продумали лестницу развития сотрудников в целом.

• И главное – как мы изменили подход к формированию проектных команд, создав самодостаточные «ячейки», способные выполнять все виды работ и быстро реагировать на потребности рынка без привлечения дополнительных специалистов. Эта модель была вдохновлена концепцией QRM-ячеек (Quick Response Manufacturing – быстро реагирующих ячеек) из бережливого производства.

• А поскольку логика QRM-ячеек близка к идеологии Scrum, выводом доклада было, что мы внедрили свой маленький Scrum – применили некоторые его методики. У меня даже слоган там был на эту тему: «Свой Scrum-велосипед ближе к телу».

А теперь о том, к чему все это привело.

Предпосылки для изменений

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

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

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

Но на практике стажеры быстро выросли и стали мидлами, у них появилась потребность наставлять других стажеров. Мидлов стало много, предыдущие мидлы стали сеньорами, а сеньоры – экспертами.

Ячейки разрослись, мы стали делить их на несколько. Так появилось множество новых команд и новых РП-шников. И когда РП-шников стало 8-9 человек, мой день превратился в тот календарь, который вы видели ранее.

Когда один человек не справляется: что делать с работой РП

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

1. Результативность руководителя проекта – обсуждение текущих дел, планирование работ, необходимость создания новых допников, планируемое количество актов в этом месяце, дебиторка и риски проектов. Плюс субъективно оцениваем качество работы руководителя проектов.

2. Бюджет проекта – смотрим баланс доходов-расходов по проекту.

3. Планирование сотрудников – мы планируем загрузку сотрудников практически на год вперед, с точностью 90% загрузки на 3 месяца вперед, и 70-80% на полгода, чтобы понимать, когда искать клиентов и продавать новые проекты.

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

5. Задачи на развитие – для каждого сотрудника продумывается отдельная программа в индивидуальных планах развития, нам важно, чтобы они не застаивались.

6. Идеи, предложения – если вдруг у РП есть что предложить.

7. Отзывы по проектам – обсуждение отзывов клиентов и в целом работа по подготовке отзывов по завершению проекта.

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

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

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

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

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

Это привело нас к мысли: нужно что-то, что поможет стабилизировать ситуацию. Здесь хочу поблагодарить Михаила Владимировича Пясковского, основателя «ИнфоСофт»: он предложил провести масштабное обучение Scrum для всех руководителей компании.

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

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

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

Появление новой роли

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

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

Что мы сделали? Мы разделили обязанности между РП и Scrum-мастером. И здесь мы наткнулись на три ключевые ошибки, в которые влетели с разбега и очень сильно:

1. Мы назвали РП “Product Owner”.

2. Мы разделили ответственность, а не обязанности.

3. Мы назвали все это Scrum.

Никогда так не делайте:

• Само понятие Scrum вызывает у сотрудников невероятное сопротивление.

• Роль Product Owner ломает понимание РП об ответственности.

• А разделение ответственности между РП и Scrum-мастером формирует невероятную почву для конфликтов между этими двумя сотрудниками.

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

Но мне введение новой роли не помогло никак:

• Да, я разгрузил РП, но загрузил себя.

• Мне стало сложнее – появилась дополнительная необходимость рулить не только РП, но и Скрам-мастерами. Контур управления вырос вдвое.

• График в календаре стал настолько плотным, что я приходил в офис в 7 утра, а уходил в 7 вечера, чтобы хоть что-то успевать. Время абсолютно закончилось.

Вот здесь, когда я осознал свою загрузку, решил: «Стоп, надо подумать».

Обязанности РД

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

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

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

Мне очень запала эта мысль в голову – институт замов. Вспомните, в любой государственной структуре, в любой крупной компании есть заместитель. Заместитель по экономике, заместитель по производству и так далее. А почему бы не подумать в этом направлении?

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

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

• Зеленым – главный руководитель проектов.

• Синим – главный Scrum-мастер.

• Розовым – администратор департамента, обычная административная работа.

• Оранжевым – это я.

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

Согласование новой структуры

Организационно новая структура управления выглядит так:

• У меня в подчинении – главный РП, главный Scrum-мастер и администратор департамента.

• У главного РП в подчинении администратор проектов, который помогает управлять и вести документацию, а также все РП ячеек.

• И по логике Scrum-мастера могут помогать разным командам, разным ячейкам.

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

Что важно было сделать, чтобы согласовать изменения:

• Объяснить собственнику бизнеса – для чего это нужно. Мои аргументы были такими:

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

  • Повышение эффективности – использование Scrum повышает эффективность сотрудников.

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

  • Повышение уровня отказоустойчивости.

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

• Договориться, что нормальный размер контура управления – 7 +/- 2 подчиненных.

Сопротивление команды

Как вы думаете, как команда восприняла изменения?

Можно ли вообще рассчитывать на то, что изменения будут восприняты без сопротивления?

• Нет, конечно. Любые изменения гарантированно приводят к сопротивлению.

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

• Держите команду в курсе обо всех этапах изменений.

• А еще лучше – советуйтесь. Потому что у вас точно работают грамотные, компетентные специалисты с высоким интеллектуальным уровнем, способные предложить идеи, до которых вы бы сами не додумались.

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

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

1. Выбрали новую структуру из нескольких вариантов.

2. Распределили Scrum-мастеров между командами с учетом совместимости с РП (важно: не каждый Scrum-мастер может эффективно работать с каждым руководителем проекта).

3. Обновили регламенты работы РП и разработали регламент работы Scrum-мастеров.

4. Продумали и изменили мотивацию РП.

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

   • На контур управления Scrum – на объем команд, с которыми работает Scrum-мастер.

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

В результате у нас появилось много новой учетной информации, и как следствие – целая экосистема Excel и Google-таблиц.

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

Автоматизация внутренних процессов

Автоматизируйте устоявшиеся внутренние процессы. Да, запускать новые процессы в Excel – нормальная практика, но потом их обязательно нужно автоматизировать. Когда у вас 25 специалистов, посчитать задачки на их развитие легко, а когда их 90 – уже нереально. Вы точно будете что-то забывать, задачки будут теряться – процессы точно нужно автоматизировать. Поэтому мы приняли решение:

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

• Использовать проектный подход к внутренней автоматизации – у нас сейчас есть несколько параллельных проектов по внедрению разных взаимосвязанных информационных систем.

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

Выводы

• Изменения приводят к еще большим изменениям. 100%. Чем сильнее вы меняетесь, тем сильнее возникает потребность в изменениях.

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

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

• Не забывайте про себя и свой контур управления. Вы тоже не резиновый, в вас не влезет такой объем управления. Вы не сможете управлять 20-ю людьми. Это не управление, это просто какая-то оперативная работа, но вы не будете развиваться. Вы не будете ничего делать с точки зрения роста над собой, роста над своим предыдущим состоянием.

Вопросы и ответы

Когда вы выделили в своей структуре руководителя проектов для руководителей проектов и главного Scrum-мастера – это была новая роль или ее занял кто-то из уже работающих специалистов?

Действительно, найти подходящих людей на позиции главного РП и главного Scrum-мастера оказалось сложно.

С главным РП ситуация чуть проще – там методика работы уже понятна. Мы просто освободили опытного руководителя проекта от управления своей ячейкой и передали ее ячейку в управление другим РП.

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.