Практика построения проектного офиса в ИТ-компании

Меня зовут Александр Прямоносов, я директор и совладелец компании WiseAdvice-IT, стоял у ее истоков.

Мой профессиональный путь – около 20 лет, и все эти годы так или иначе связаны с автоматизацией предприятий на основе 1С. Я начинал сервис-инженером, потом занимался управлением большими проектами, позже руководил коммерческим блоком, проектным офисом. И стал свидетелем множества шишек, которые мы успели набить на этом пути. Это наш практический опыт, все по-честному.

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

Но так было не всегда.

«18 лет за 30 минут». Немного пафосное выражение, но я пытаюсь соответствовать духу конференции Инфостарт, поэтому такая фраза мне очень понравилось.

Я расскажу:

• как менялась наша компания;

• что происходило в структуре и методах управления проектным офисом;

• как, по сути, за один день мы перешли к текущей структуре проектного офиса, почему это хорошо, и что дает.

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

С чего все начиналось

Все началось в 2003 году, когда мы создали свою компанию. Мы – это несколько 20-летних амбициозных ребят, которые что-то внедряли на 1С 7.7.

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

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

• Бизнес развивался с нуля, и мы ощущали быстрый рост – это были бешеные сотни процентов.

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

Мы попробовали это тиражировать.

• Чтобы это тиражировать, нам нужно было нарастить объем деятельности, т.е. увеличить количество клиентов и проектов. Этим мы и начали заниматься.

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

• И начали расти – в какой-то момент наш объем деятельности вырос примерно в 2 раза.

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

На слайде показано, что примерно происходило.

• Мы впервые начали ощущать, что наши клиенты становятся недовольны компанией.

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

• Мы поняли: хаос нарастает, и с этим нужно что-то делать.

Первая адаптация структуры

Сначала мы создали определенную структуру.

• Сделали какие-то правила и образ технологий.

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

• Тогда мы поняли, что сами мы уже не тянем. Нам нужны новые руководители и даже продавцы.

Мы разделили зоны ответственности и полномочий между владельцами. И структура №2, которая представлена на слайде, – это наша точка отсчета в период 2006-2009 гг.

Мы взяли:

• ТСКФ (типовую систему качества франчайзи), добавили к ней элементы ГОСТа и PMBOK, и создали прообраз фреймворка.

• Взяли шаблоны документов, описали инструкции.

• Сформулировали правила взаимодействия между производством и продажами.

И все снова более-менее поехало.

Зоны ответственности больше не конфликтуют: теперь понятно, кто отвечает за продажи, а кто – за производство проектов.

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

Все сломать и построить заново

А дальше произошел очередной виток нашего роста – проектный офис нашей компании вырос до 90 специалистов.

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

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

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

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

Функции проектного офиса

Функции проектного офиса, как мы их видели, представлены на слайде.

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

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

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

• Тогда мы взяли еще руководителя центра разработки и подчинили ему программистов.

• В зону ответственности руководителя центра разработки включили внедрение технологий.

• Он писал стандарты, инструкции, библиотеки решений.

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

Структура оставалась простой.

• Был руководитель проектного офиса, которому подчинены руководители проектов и аналитики.

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

Преимущества и недостатки структуры

Это было уже лучше:

• Мы отделили разработчиков, назначили им методолога, наставника и друга – руководителя центра разработки.

• А руководителей проектов определили в профильное подразделение в подчинение к руководителю проектного офиса.

Но эта структура тоже имела недостатки:

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

• Плюс руководитель проектного офиса отвечал еще и за все технологии работы этих двух групп специалистов.

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

Но мы сделали вывод: такая структура управления ИТ-отделом или ИТ-компанией работает в масштабе до 80 человек. Причем надо, чтобы количество программистов было примерно равно количеству остальных специалистов.

И снова изменения

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

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

На тот момент наша организационная система проектного офиса включала:

• руководителя проектного офиса, который отвечал за руководителей проектов;

• руководителя центра разработки, который отвечал за программистов;

• руководителя центра аналитики и консалтинга.

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

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

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

Но на самом деле нет. Все не совсем так. Вернее, совсем не так. Потому что «пирог» оказался с горчинкой. В чем же горчинка?

И снова перемены

Каждый из наших руководителей опять-таки не стремился к какой-то целостной системе.

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

• Руководитель аналитиков говорил: нет, не так, мы будем работать по-своему.

• Руководитель проектного офиса просто смотрел на все это большими глазами и не понимал, что ему делать.

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

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

Их было очень сложно помирить. Я помню, как мы с руководителями могли подолгу заседать в переговорной. У нас была очень большая повестка, но мы не успевали пройти даже 30% вопросов, потому что каждый раз спотыкались обо что-то концептуальное. Мы не могли уходить в частности, потому что они были глобально недовольны друг другом. Они постоянно говорили, что сосед работает неправильно, его сотрудники работают не так, как нужно. И вообще: «Он отбирает у меня деньги, мешает мне добиваться успеха!»

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

Мы вывели, нащупали на практике магическое правило «40 человек на одного руководителя» – некий лимит управления. А компания к тому времени насчитывала уже больше 100-120 специалистов проектного офиса. Поэтому в рамках матричной структуры она вряд ли бы еще выросла.

Экстрим

От несогласованности все уставали. Мы понимали, что нужно что-то делать и делать быстро. А дальше начался экстрим.

• За 3 недели мы сломали старую структуру.

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

• Внутри проектных отделов создали иерархию по специалистам.

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

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

• Еще мы внедрили единую систему управления нашими проектами на основе Jira/Confluence. Но долго ее адаптировали под свои задачи.

И уже через 3 недели после принятия решений мы уже работали в новой структуре, формулируя правила и проводя улучшения в процессе.

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

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

Текущая структура

На текущий момент мы работаем в такой структуре, как на слайде.

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

Есть руководитель проектного отдела, у него три блока по видам задач:

• управления проектами;

• аналитика и консалтинг;

• разработка.

В управлении проектами у нас администраторы проектов, руководители проектов, руководители корпоративных проектов. Мы ввели единую систему грейдов, и это – три типа грейдов руководителей проектов.

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

• Руководители проектов – это руководители среднего масштаба проектов. Они используют технологию каскадного внедрения, иногда гибрид с гибкими технологиями.

• Руководители корпоративных проектов отвечают за наиболее сложные и наиболее масштабные проекты.

В блоке аналитики и консалтинга у нас есть:

• тимлиды в виде главных функциональных архитекторов – в их задачи входит наставничество, помощь другим архитекторам и работа на проектах на ведущих ролях;

• также здесь трудятся архитекторы;

• аналитики, методологи;

• и консультанты.

В подразделении разработки есть:

• тимлиды – технические архитекторы;

• ведущие разработчики;

• и разработчики middle+.

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

Такая структура позволяет добиться:

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

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

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

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

• Мы ввели грейды специалистов (25 критериев хард скилов + 7 критериев гибких навыков) и единые тарифные сетки. Когда ко мне подходили руководители проектных отделов и просили себе отдельную сетку потому, что у них другой вид учета, я им отказывал. Некоторые элементы мотивации едины у всех. В них достаточно свободы для управления, но то, что нам нужно было сделать единым, мы сделали единым.

• Фреймворк по управлению проектами – главные принципы, от которых мы никогда не отходим – это тоже единая история.

• Единые подходы к управлению и развитию персонала и корпоративная культура.

• Единая система коммуникаций и взаимодействия.

• Единая система отчетности.

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

К этим единым комитетам относятся:

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

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

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

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

• Методологический комитет по управлению методологическими и функционально-техническими требованиями проектов.

Этих 5 пунктов достаточно, чтобы не упустить единство по всей компании.

Единая система и стандарты управления

Несколько слайдов о том, как мы сейчас работаем в рамках единой системы управления. На слайдах скрины в основном из Jira/Confluence и можно посмотреть, как мы подходим к распределению новых проектов:

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

• Сопоставляем с профилем специализации отделов.

• Сопоставляем с объемом проекта – мы никогда не зайдем на проект, если у нас нет хотя бы костяка команды.

Планирование и оценка доступности ресурсов.

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

Оценка доступности ресурсов. Здесь можно посмотреть по всему проектному портфелю, по каждому отделу, что у нас происходит, что будет через 3-4 месяца.

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

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

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

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

Также у нас есть единая система управления развитием компании – она представлена в виде единой канбан-панели.

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

На управляющем комитете мы проверяем результаты этих работ.

Результаты

Итоги перехода на новую структуру проектного офиса:

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

• Но при этом маржинальность наших проектов выросла на 9% и сохраняет стабильный тренд к повышению.

• Индекс удовлетворенности заказчиков прибавил более 7%.

• А индекс удовлетворенности персонала – вырос на 14%. Сотрудники начали чувствовать больше внимания к себе, к вопросам развития карьеры и навыков, а не только к рабочим моментам.

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

Но ключевая причина, почему эта система работает, и почему я в нее верю и верят в нее все руководители, – это эффект в головах.

• Каждый руководитель понимает, что никто в его деятельность не вмешивается.

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

• В итоге у него получается хорошая команда, и всем участникам этой команды работать друг с другом максимально комфортно, потому что руководитель их выбирал по определенным принципам.

Эффект и в головах специалистов, они тоже ощущают больший комфорт.

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

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

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

Выводы:

• Идеальной структуры проектного офиса не бывает.

• Но чтобы выстроить правильную структуру, вам нужно понимать цели компании хотя бы на 5 лет вперед.

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

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

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