В последние несколько лет основная дискуссия в сфере управления проектами IT ведется между сторонниками методов аджайл, с одной стороны, и сторонниками водопадного метода управления. Складывается впечатление, что все развитие управленческой теории ограничивается только этими двумя методиками, по крайней мере, они явно доминируют в информационном поле. Аргументы в пользу обоих методов давно высказаны, все сильные и слабые стороны понятны, также, как и понятны ограничения на сферу применимости обоих методов.
В этой статье я расскажу о практической реализации альтернативного указанным выше подхода к управлению мультипроектной IT-средой. Надеюсь, что мой опыт поможет кому-то увидеть новые возможности там, где раньше виделись лишь новые проблемы.
Очевидные решения — не всегда выход
Вызов, с которым столкнулся проектный офис IT в нашей компании, был связан с резким, буквально в течение полугода, увеличением количества входящих новых проектов с одновременным ростом их сложности. Кроме того, сфера бизнеса (аутсорсинг расчета заработной платы, бухгалтерских и HR-процессов), в которой работала компания, накладывала дополнительные требования по соблюдению сроков и качеству. Любая ошибка, допущенная при подготовке системы, даже выявленная через год, два или три, остается в сфере ответственности исполнителя и серьезно влияет на финансовый результат основной услуги. Соответственно, требования к качеству в разы выше, чем при «обычных» внедрениях.
Возникшее в связи с перегрузкой сотрудников снижение качества было воспринято всеми крайне болезненно. Понятно, что первые два решения «в лоб» — «придержать» продажи или пропорционально расширить штат — руководство компании не поддержало. Кроме того, расширение штата технических специалистов, даже в небольшом согласованном объеме, наткнулось на ограничение рынка труда. Кто искал специалистов 1С, тот меня поймет.
Следующими очевидными шагами были привлечение 1С франчайзи на субподряд и привлечение фрилансеров.
- К сожалению, в первом случае мы выяснили, что франчайзи не могут соблюсти требуемые параметры по качеству и срокам работ. При этом в разы, а где-то и на порядок, дороже собственных ресурсов. Все что они делали, в итоге, было далеко за рамками бюджета проектов.
- Работа с фрилансерами дала чуть лучшие результаты в смысле бюджета, но их поиск был не сильно проще, чем поиск штатных сотрудников.
Экстенсивные простые решения не привели к успеху, проекты продолжали множиться, и нам, поневоле, пришлось идти по пути изменения в системе управления.
Конечно же, модное слово «аджайл» было у всех на слуху. Конечно же его рассматривали. Рассматривали, впрочем, не очень подробно, так как недостатки были очевидны для всех.
- Проекты без документирования? Да, заказчики будут очень рады предъявить вам штрафы за неверный расчет через пару лет работы.
- Ежедневные встречи проектной группы и доска с бумажками-задачами? Да, это очень удобно, когда команда сидит в нескольких разных городах.
- Выделенные проектные самоорганизующиеся группы? Конечно, надо только увеличить штат в несколько раз, а проектов у нас больше, чем исполнителей, и позволить каждой группе реализовать собственные решения. А потом научить бухгалтеров работать в этих разных по настройкам базах, а техподдержку их обслуживать (без документации, у нас аджайл).
И все это при том, что конечный результат вполне понятен уже на старте проекта, а заказчику не слишком хочется в нем участвовать — он же отдает процессы на аутсорсинг, это не его боль. Спринты и промежуточные результаты не интересны, интересно чтобы в час Х сотрудники получили зарплату от нового провайдера услуги без ошибок.
Если на вопрос нет ответа, может быть стоит изменить сам вопрос?
До начала бурного роста, в компании была устоявшаяся методика работы с проектами. К каждому прикреплялся менеджер (РП), один (два, три — в зависимости от объема) консультант 1С и программист. Консультант вел проект от начала до конца, знал о нем все. Заказчик, понимая это, часто требовал закрепления такого сотрудника за ним и после окончания основного проекта внедрения. После каждого крупного проекта мы гарантированно теряли 0,25 — 0,5 FTE в группе внедрения, эти ресурсы уходили на поддержку и дальнейшее развитие клиента. Понятно, что такие потери не просто было восполнять.
Другой серьезной проблемой являлось нестабильное качество. В зависимости от того, кто именно был исполнителем, оно могло сильно варьироваться. Да, у нас были внедрены чек-листы выходного контроля качества. Да, они приносили пользу, но всех проблем не решали. Кроме того, исполнитель часто либо сознательно скрывал известные ему проблемы, либо не считал их важными. Выявлялись они уже на этапе эксплуатации системы, что вело к дополнительным расходам на экстренное устранение с одной стороны, и снижало удовлетворенность заказчика с другой.
Еще одна проблема описываемой схемы — низкая устойчивость проектов к форс-мажорам с персоналом. Когда сотрудник «выходил из строя» (отпуск, длительный больничный, увольнение) объем передаваемых дел был очень большим, многое терялось, возникали ошибки и проблемы в коммуникациях. Даже имея довольно серьезное документирование всех работ, передать проект целиком было очень трудно.
В рамках описанной схемы, все мероприятия по ускорению проектов и повышению качества давали только ограниченный эффект, а нам нужен был прорыв. С прорывом не получалось до тех пор, пока не был изменен вопрос, который мы все себе задавали. Вместо «Что и как улучшить?», я в какой-то момент задался вопросом: «А почему это все до сих пор не развалилось?». Иными словами, решил проанализировать сильные стороны системы. Такая постановка вопроса, на удивление, дала эффект.
К сильным сторонам можно было отнести:
- Развитую практику проектного управления. Фактически, каждый проект находился под пристальным вниманием РП, деятельность РП была регламентирована процедурами и, с точки зрения СМК, тут контролировался не только конечный результат, но и процесс. Все это позволяло, как правило, узнать о проблемах раньше, чем они наносили непоправимый вред.
- Хорошее взаимодействие между проектным офисом и ресурсным департаментом. Сидя в одной лодке IT-дирекции, они были лишены возможности свалить друг на друга проблемы проектов, и нам приходилось искать решения вместе.
- Бюрократия внутри компании. Как ни странно, структура корпоративных процедур и правил была построена таким образом, что позволяла тормозить процессы по формальным основаниям, давая необходимый для исполнителей запас времени. Внутри системы имелся некий буфер, демпфирующий резкие изменения ситуации.
Все три фактора давали возможность оперативно перебрасывать ресурсы в проблемные места и «затыкать дыры». Плохой метод, но рабочий. Особенно плохо было то, что при этом у каждого исполнителя одновременно было несколько открытых проектов, между которыми ему приходилось переключаться, иногда даже в течение одного дня.
Здесь каждый, кто работал в мультипроектной среде, должен был бы задать мне вопрос: а что же с конкуренцией за ресурсы? Почему РП не «перегрызли» друг друга и почему исполнители спокойно относились к перемещениям между проектами? Ответ прост, и он кроется в системе мотивации персонала. Это можно было бы написать капсом, и это именно то, что нас спасало: в компании не было проектного бонуса.
Совсем не было. Ни в каком виде. В наследство от американского менеджмента нам досталась система премирования на основе карт сбалансированных показателей (BSC), так нелюбимая всеми знакомыми мне HR. К моменту кризиса она сильно отстала от жизни, и особо ни к чему никого не мотивировала, но и не создавала дополнительных внутренних конфликтов. Как показала практика, в отсутствии дополнительного давления сотрудники показывали более высокие результаты, чем можно было ожидать.
От правильного вопроса — к правильной методике
Собрав всю эту информацию воедино, наконец-то удалось понять, что мы делали не так.
Исторически мы смотрели на нашу деятельность как на портфель проектов, что обусловливало применяемые методы. Теперь же стало понятно, что оптимизация большого количества однотипных проектов аналогична задаче управления позаказным производством. А уж в этом направлении за прошедшие 30 лет наработаны прекрасные методики, как раз и позволяющие выйти из тупика.
Как совместить теорию PMBoK и теорию управления производством, спросите вы? Мой ответ — через метод критической цепи (CCPM), довольно давно включенный в PMBoK, и, в свою очередь, являющийся проектным расширением теории ограничения систем (ТОС), давно и прочно занявшей свою нишу в управлении производственными процессами. Эта теория не только полностью описывала текущую ситуацию с внедрениями, но и дала возможность предсказать последствия следующих изменений.
Вообще, и ТОС, и CCPM содержат в себе пошаговую инструкцию по применению, они очень технологичны. Однако, практически все авторы книг по этим теориями сходятся в том, что внедрить их не в компании в целом, а в ее части — гораздо труднее. Нам, по ряду причин, пришлось ограничиться рамками IT-дирекции, что наложило свой отпечаток на последовательность действий.
Итак, что же было сделано
Раз мы решили, что у нас позаказное производство, фабрика, и вообще конвейер, именно его мы и начали строить. Проекты типизировали и разбили на технологические операции (ТО). Сразу стало понятно, что часть получившихся операций можно без потери качества отдать в техподдержку, где более дешевые ресурсы.
Далее, большинство сотрудников получили специализацию — привязку к конкретным ТО. Таким образом, на каждом проекте вместо 1-2 консультантов мы задействовали 4-7. Естественно, это серьезно увеличило требования к коммуникациям внутри проектных групп, но, как я писал ранее, проектное управление у нас было сильной стороной и РП в целом справились. Поддержку им дали проработанные методические материалы — карты ТО и технологическая процедура выполнения работ. Вся подготовка была реализована на принципах СМК, когда для каждой технологической операции были детально описаны условия ее старта (вход) и результаты исполнения (выход), а содержание операций по возможности было регламентировано.
Понятно, что любые изменения встречают противодействие сотрудников, привыкших к определенной последовательности действий, просто в силу инерции мышления. Преодоление такого сопротивления в нашем случае было облегчено действующей системой премирования, о которой я упоминал выше. Если у сотрудника нет четкой финансовой мотивации работать против изменений, то они проходят гораздо легче. При внедрении новой схемы работы компания не потеряла ни одного сотрудника, что само по себе довольно важно.
И что же получилось в итоге?
Теперь о тех плюсах, которые мы получили по итогам первого года работы по конвейерной производственной схеме. Затрудняюсь ранжировать их по степени важности, поэтому просто перечислю в том порядке, который пришел в голову.
- Значительное повышение прозрачности операционной статистики. Учет времени в разрезе ТО позволил абсолютно точно локализовать места возникновения максимальных потерь времени, и предпринять меры по их минимизации.
- Снижение трудозатрат на каждую отдельную операцию в результате узкой специализации сотрудников и наработке ими собственной экспертизы в конкретной узкой области. При этом важно понимать, что каждый сотрудник обычно специализировался более чем на одной ТО и на каждой ТО было более одного сотрудника. Таким образом, мы побороли риск потери экспертизы в случае выбытия сотрудника.
- Победа над «плохой многозадачностью» (термин ССРМ). Каждая конкретная ТО по длительности меньше проекта в целом, и, завершив ее, сотрудник оказался свободен для участия в другом проекте. Это дало нам возможность выделять сотрудника на задачу в монопольном режиме для ее скорейшего завершения. Еще два следствия такого подхода — радикальное уменьшение времени простоя (в этот момент можно переключить ресурсы на ТО другого проекта) и возможность вести проекты ограниченным составом — сотрудники подключаются по мере высвобождения.
- Необходимость передачи работ с одной ТО на другую повлекло за собой серьезное повышение качества конечного продукта, т. к. теперь мы естественным образом реализовали рекомендации СМК о промежуточном контроле качества, когда в роли контроллера выступает следующий по ходу технологического процесса участок. В итоге, исполнители потеряли возможность сдавать конечным пользователям не полностью завершенные задачи под лозунгами «доделаю потом» и «а вдруг не заметят».
- Сократив «такт» исполнения единицы работ мы, в полном соответствии с рекомендациями ССРМ, уменьшили влияние «студенческого синдрома» — еще один плюс к скорости и качеству.
- Серьезно повысилась устойчивость проектов, особенно крупных, к выбытию сотрудников. По моей личной практике, даже смена 30% участников проекта не привела к сколько-нибудь значимым негативным последствиям.
- Эффект, который мы не предсказали заранее, но который оказался приятным бонусом — мы победили привязку сотрудников к заказчику после завершения проекта, о которой я писал выше. С заказчиком одновременно взаимодействовало большое количество специалистов, и выделить из них кого-то одного, чтобы требовать его постоянного присутствия, стало невозможно. Передача в техподдержку серьезно упростилась.
- Радикально снизились требования к квалификации персонала при подборе. Теперь мы смогли набирать менее дорогих специалистов и очень быстро получать от них результат требуемого качества, адаптация новых сотрудников стала гораздо проще и короче.
Естественно, ни один метод не лишен минусов, и ряд проблем, с которыми мы столкнулись, я здесь тоже перечислю.
- Значительный рост затрат на внутрипроектную коммуникацию и координацию. Особенно, в первые полгода, когда сотрудники привыкали к новой схеме работы, а описания ТО часто менялись по ходу получения новой информации и ее интерпретации. Особо важным оказалось наличие серьезных управленческих компетенций и ресурсов — именно нагрузка на РП по обеспечению коммуникаций и передаче информации возросла многократно. Основные методы решения проблемы — усиление роли горизонтальных коммуникаций между участниками проекта (кто сказал аджайл?) и серьезная проработка способов передачи процесса между ТО. На горизонте года, в целом, можно было констатировать снижение остроты проблемы.
- Неудача официального внедрения управления через буферы, рекомендуемое ССРМ. Трудности с донесением буферной схемы до заказчиков заставили отложить этот шаг до полной стабилизации конвейера. Для внутренних целей мы зашили буферы в длительность финальных технологических операций проекта, что, в принципе, частично закрыло вопрос.
- Неизбежные конфликты между сотрудниками на разных ТО, с целью переложить друг на друга ответственность за ошибки. А также отсутствие заинтересованности в результате проекта как единого целого и увлечение «локальной оптимизацией». Указанный эффект имел место, но, на удивление, незначительное. Возможно это заслуга корпоративной культуры, возможно — естественное состояние человека, который стремится при прочих равных всегда сделать «как лучше». Мы строили процесс исходя именно из такого предположения, оно же включено в основу ССРМ: сотрудники хотят работать хорошо, не надо им в этом мешать. Теперь уже точно можно сказать, что подход себя оправдал.
Для развития эффекта, через полгода после запуска конвейера было решено пересмотреть систему мотивации. Общий принцип использования системы сбалансированных показателей не изменился, но сами показатели были серьезно переработаны. Основная задача была – не допустить, чтобы принцип премирования отдельного сотрудника вступал бы в противоречие с целями отдела, департамента, и компании в целом. В итоге, получилась довольно сложная схема, включающая в себя как командные, так и индивидуальные показатели сотрудников.
Первые результаты внедрения новой системы мотивации по итогам квартала показали обнадеживающие результаты, мы увидели повышение активности сотрудников в плане экономии трудозатрат и борьбы за новую выручку. Однако, для получения статистически значимых данных и доведении системы до ума, нужен период до года.
Заканчивая статью, хотелось бы заметить, что многие сочтут приведенный в ней пример слишком специфическим. Действительно, в разных областях IT нужны специальные подходы, и описанный выше метод не претендует на универсальность. Однако, я считаю, он показывает, что всегда есть возможность выхода за рамки общепринятой «моды», даже если это мода на методы управления.
Как человек из области управления проектами, я уловил ключевые изменения только в том, что вы по сути сотрудников "специализировали" для определенных операций, за счет чего у вас выросло качество и скорость (что естественно) + ввели общее управление портфелем проектов (есть стандарт для управления именно портфелем проектов - PPM). По сути у вас классический PMBOK, с детальным распределением ролей и общим распределением ресурсов между проектами. Так работают все крупные интеграторы (инженеры специализированы и работают на куче разных проектов). Серверная версия MS Project даже умеет сама ресурсы "пилить" внутри компании. Не понял в чем принципиальные отличия - если поясните, буду благодарен.
"...в отсутствии дополнительного давления сотрудники показывали более высокие результаты, чем можно было ожидать."
Это интересно! Хорошо бы понять, где тонкая грань между полезным конструктивным напряжением и вредным дополнительным давлением.
Да, ничего фантастического и нового нет, но Вы же на это и не претендуете? Для внедрения 1С это очень важно, и многим может помочь, потому что практически везде на проектах складывается сильная зависимость от ведущих сотрудников.
Ставлю плюс за то, что написали про недостатки системы и за хорошие вещи про оплату труда.
Если удается выстроить конвейер, то вряд ли это можно назвать мультипроектной работой. Проект от типовой работы отличается именно уникальностью технологии. Но это терминологические тонкости.
По сути, разумеется, при наличии общей технологии и нужно идти по пути специализации и выстраивания конвейера. Следующий очевидный шаг - автоматизация. Применительно к ИТ это разработка типовых библиотек и шаблонов, позволяющих свести программирование к настройке.
Нет. Не отличается. Проекты действительно могут становиться типовыми работами.
Это для заказчика он проект, а исполнитель их может штамповать по шаблону)
Добрый день! Спасибо за описание интересного опыта адаптации аджайла. В ходе прочтения статьи возник вопрос - Вы пишете, что разделили процесс по технологическим операциям и каждую из них выполняли определенные консультанты. Можете привести пример подобных ТО, чтобы попробовать "примерить" данный подход к моим проектам?
И еще вдогонку второй вопрос - вы обходились совсем без документирования? У нас на опыте использования аджайла столкнулись с такой проблемой, что в течение полугода внедряли сложный витиеватый процесс, где много условий, следствий и исключений. И в итоге через несколько месяцев поняли, что именно его надо От и До задокументировать, т.к. к этому времени даже уже команда проектирования и Заказчик стали путаться во всех ветках и условиях, а про тех, кто в дальнейщем должен будет сопровождать и понимать почему в том или ином месте система ведет себя определенным образом - про это уже и речи быть не может. Поэтому мы пришли к выводу, что некоторые моменты неизбежно нужно документировать, дабы не заблудиться в процессе
Интересно, а что именно не получилось с буферизацией?
Добрый день. Например, такие:
Всего было выделено 17 ТО. Но, в зависимости от предментной области, объема проекта и т.п. детализация, как мне кажется, может очень сильно меняться
Я специально указал в статье, что отсутствие документирования для нашего бизнеса было неприемлемо. Мы очень подробно фиксировали требования, и иногда приходилось совместно с заказчиком разрабатывать и утверждать детальные регламенты взаимодействия (в т.ч. за рамками ИТ-системы).