Как реорганизовать работу проектного департамента, чтобы быть №1

Меня зовут Павел Громов. Я работаю во франчайзинговой компании «ИнфоСофт» руководителем департамента консалтинга и проектных внедрений. Если упростить, моя должность – руководитель проектного офиса.

У меня в подчинении проектные команды, которые внедряют корпоративные проекты в крупных компаниях. Мы внедряли Гособоронзаказ еще тогда, когда это не было мейнстримом – делали это на УПП, писали модули полностью с нуля. Еще мы автоматизировали на ERP крупные предприятия – морского приборостроения и аналогичные подобные.

Партнерская сеть «ИнфоСофт» существует уже более 25 лет. Это крупная компания из Новосибирска, которая занимает шестое место в рейтинге всех франчайзи и входит в топ-50 работодателей Российской Федерации по версии HeadHunter.

Мы 25 лет автоматизируем предприятия, которые занимаются производством.

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

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

Что за зверь NPS

Но когда мы хотим измениться – как понять, что мы меняемся к лучшему? Можно ли это каким-то образом измерить? 

В 2017 году мы решили, что эффективность изменений имеет смысл измерять через NPS – индекс потребительской лояльности. 

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

• Те, кто ставит от 0 до 6 баллов, – это негативщики, критики, те, кто никогда не посоветует вас.

• Те, кто ставит 7-8 баллов, – это нейтралы. Они, скорее всего, никому не посоветуют вашу компанию, но и не будут ничего плохого говорить.

• Промоутеры – те, кто ставит 9-10 баллов. Они точно посоветуют, будут вас рекомендовать.

Если от промоутеров отнять критиков, получится какое-то значение. Это значение и есть индекс потребительской лояльности NPS.

Есть еще индекс еNPS. Это то же самое, но про внутренних сотрудников компании.

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

Начиная с 2017 года мы у себя в компании измеряем оба этих показателя.

В 2017 году они у нас находились в районе около 50: 48 и 46.

Потом мы их на протяжении следующих 3 лет измеряли, одновременно внедряя некоторые изменения. Мерили – меняли, мерили – меняли.

И в 2020 году по обоим показателям у нас произошел существенный скачок. Расскажу, что к этому привело.

За 5 лет до реорганизации

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

• В 2017 году в нашем департаменте было примерно 20-25 специалистов, которые занимались внедрением проектов.

• Это были аналитики и разработчики, которые собирались в 2-3 проектные команды.

• Каждая команда параллельно могла делать 2-3-4 проекта.

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

• Мы не брали стажеров в работу.

• Вернее, стажеры в департаменте были, но как их развивать, было непонятно. Они приходили, как-то работали, иногда их брали в проекты. Они показывали абсолютно разные и не прогнозируемые результаты. Срок роста стажера мог вырасти колоссально.

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

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

QRM-ячейки

Вдохновляясь успехами наших клиентов, которым мы автоматизируем бизнес-процессы, мы посмотрели, что есть классная система – быстрореагирующее производство, методика QRM (Quick Response Manufacturing).

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

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

Структура департамента до и после реорганизации

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

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

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

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

Такое объединение специалистов мы назвали ячейкой.

Внутри ячейка выглядит следующим образом:

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

• Еще в команде есть разработчики и консультанты.

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

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

• кто такой архитектор:

• что он должен делать;

• какие у него ключевые обязанности;

• какие у него должны быть знания, умения и результаты его работы.

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

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

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

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

Где брать руководителей

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

• кто такие руководители проектов;

• какие у них компетенции;

• что они должны уметь;

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

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

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

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

Как, зачем и куда развивать сотрудников

Для развития сотрудников:

• Мы проработали единые лестницы развития, где переход на каждую ступеньку грейда четко регламентирован и прописан. Каждый сотрудник знает, сколько чего и как ему нужно сделать, кому сдать какие тесты и экзамены, чтобы перейти на следующую ступеньку. По своему индивидуальному плану развития (ИПР, наверное все слышали) он уже может прогнозировать свой переход – понимая, что, условно, через 3 месяца он будет зарабатывать больше. Ему становится намного комфортнее работать. А сотрудник, которому комфортно работать, приносит гораздо лучшие результаты и бОльшую отдачу внутри проектной команды.

• Мы придумали, как заинтересовать наставников в развитии стажеров. Я как отец троих детей хорошо знаю, что если ты быстро научишь своего ребенка зашнуровывать ботинки, ты освободишь себе колоссальное количество времени. Здесь работает абсолютно то же самое, потому что, присоединяя к сотруднику наставляемого, мы ему в тех же ИПР ставим цели, которые немного превосходят то, что может сделать аналитик или разработчик один. И человеку приходится делегировать свои задачи на наставляемого и объяснять ему, как это сделать. В какой-то момент наставляемый начинает хорошо решать задачи, и вместе эта пара решает гораздо больше проектных задач, чем они решали по-отдельности.
  В лестницу развития ведущих специалистов добавлена необходимость вырастить определенное количество стажеров либо наставляемых. И это является критерием для перехода на следующую ступеньку.

• Такой подход у нас сработал и помог значительно ускорить переходы между ступеньками, ускорить этап прохождения стажерства, обучения. Если раньше от начала обучения, прохождения стажировки до момента входа в проектную деятельность у стажера проходило от 3 до 6 месяцев, то теперь уже в первый месяц стажер получает какие-то небольшие проектные задачки: написать какую-то документацию, прописать какие-то мэппинги, может, небольшое ТЗ сделать. У него уже появляются настоящие задачки, которые помогают ему расти профессионально. Ему не нужно уходить в очередное абстрактное обучение – зачем его заставлять учиться, он и так только из института пришел. Мы сразу даем ему настоящую работу.

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

• Вопрос – куда развиваться архитектору – я уже немного осветил. Архитектор должен прокачивать навыки, которые у него в профиле оценены не на максимальные баллы. Кроме этого, архитектору можно развиваться в руководство или в продуктовую разработку. Можно придумать вариант, когда архитектор возьмет наработку с какого-то проекта и начнет ее дорабатывать уже как продукт – это будет уже не проектная деятельность, а продуктовая. Допустим, он может развивать производственные АРМ для автоматизации предприятий. Это же классный продукт, который можно доделать и развить в 1С:Совместимое приложение.

Результаты преобразований

В результате этих преобразований наш департамент вырос практически в 2 раза. На данный момент у нас:

• работает более 56 сотрудников;

• организовано 7 ячеек;

• и параллельно мы делаем 16 проектов;

• уровень NPS на 2022 год (прим. ред. доклад от 6 октября 2022 года) составил 78 баллов;

• а eNPS вырос до 88.

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

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

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

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

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

Вопросы

У вас классный опыт. Но есть одно маленькое «но» – это процесс, который реализован в ИТ-компании. Можно ли этот опыт в чистом виде или с какими-то небольшими изменениями переложить на инхаус-разработку – внутренний ИТ в коммерческих структурах?

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

При этом управляемость будет сохраняться, потому что вы держите в фокусе не 50 сотрудников, вы держите в фокусе ячейки, куда они входят. Контролировать становится проще.

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

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

Вы измеряли NPS у заказчика и eNPS у команды разработки. А в инхаус разработке кого будем мерить?

Сотрудников-айтишников из департамента – это будет еNPS. А NPS – это заказчики из других департаментов, которые заказывают разработку у ИТ-отдела.

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

Отличный вопрос. Я упустил это в докладе, хотя планировал рассказать.

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

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

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

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

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

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

Но это при условии, что предметная и функциональная области в этих проектах схожие?

Нет. В том-то и дело, что внутри команды многофункциональные специалисты. И они все друг друга перекрывают.

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

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

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

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

А премиальная часть на разных проектах одинаковая или разная?

Одинаковая и зависит от грейда.

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

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

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

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