О том, можно ли извлечь двойной эффект от совмещения классической и Agile-моделей, при этом не удвоив негатив, рассказывает Кирилл Булгаков, управляющий директор Т1 Консалтинг.
Почему «классика» не выходит из моды
«Классика» по-прежнему актуальна для крупных компаний, особенно госкорпораций — там, где нужны комплексные решения, охватывающие десятки ИТ-систем и процессов. Например, один из кейсов Т1 Консалтинг — внедрение централизованной системы для энергетической компании, которое требовало объединения 18 наборов ИТ-систем нескольких брендов. При таких масштабах именно алгоритм классического («водопадного») внедрения с требованиями, четко зафиксированными в техническом задании, обеспечивает результат. Ключевым условием является высокая детализация технического задания. После внедрения системы каждый пункт будет скрупулезно проверяться по установленным критериям. Места для разночтений при сдаче работы нет. Успех такого рода внедрений достигается и за счет жесткой управленческой вертикали: принятие решений сосредоточено в руках нескольких руководителей высшего звена, которым поступает конкретная, высоко детерминированная информация.
Высокий уровень формализации, с одной стороны, упрощает процесс принятия системы при работе с заказчиками, например, из госсектора. С другой стороны, процесс согласования сам по себе ресурсоемок, требует времени и высокого уровня участвующих в процессе согласования специалистов.
В классическом проекте есть две существенные итерации согласований: собственно ТЗ и приемка результатов на соответствие ТЗ. Это приводит к тому, что к моменту, когда система будет наконец внедрена, она отчасти может утратить бизнес-актуальность.
В этом рассуждении содержится ответ на вопрос о границах применимости классического подхода. Он возможен там, где процессы неизменны (например, автоматизация массовых функций бэк-офиса, не являющихся ключевыми для бизнеса), и там, где достижение даже частично актуального результата несет ценность (госсектор).
Для любых внедрений заказчику надо созреть: клиент должен понимать, зачем ему нужна система и почему именно такая. Тогда он получает результат, наняв профессионального подрядчика с опытом реализации подобных систем и управления масштабными проектами. Как показывает практика, в классическом проекте внедрения компетентность подрядчика отчасти может компенсировать незрелость заказчика. В Agile-проектах заказчик, как правило, оставляет функцию управления проектом в своих руках, привлекая только ресурс подрядчика.
Когда выгоден Agile
Agile-подход подстраивает требования к ИТ-системам к меняющимся запросам бизнеса, реализация решения происходит сравнительно небольшими итерациями. Но он не лишен особенностей, которые не позволяют модели стать универсальной. Так, гибкий подход предполагает, что правом принимать решения наделяются product owners — обычно это менеджеры среднего звена, узкие специалисты. Однако распространенная в России вертикальная культура управления (принятие решений не делегируется) становится естественным препятствием на этом пути. В результате в случае с крупным бюрократизированным заказчиком Agile-внедрение если и не обречено на провал, то осязаемый результат может отложиться на неопределенное время.
В классическом проекте внедрения компетентность подрядчика отчасти может компенсировать незрелость заказчика. В Agile-проектах заказчик, как правило, оставляет функцию управления проектом в своих руках, привлекая только ресурс подрядчика.
В условиях, когда делегирование невозможно, расцветает blaming culture (культура поиска виноватых). Никакие решения не делегируются, соответственно у нескольких топ-менеджеров образуется никогда не уменьшающийся стек решений к принятию. Неизбежно, что часть из них не рассматривается в срок, — время искать виноватых. Это очень характерная ситуация не только для нашей страны, но и для целого ряда культур. В итоге происходит определенная профессиональная деформация менеджеров. Однако в мире есть обратные примеры, где культура делегирования развита и любой результат, даже негативный, воспринимается как опыт.
Отсутствие жесткого плана, фиксированного бюджета, просчеты в управлении — все эти факторы зачастую приводят к избыточности затрат. При Agile-подходе затраты заказчика могут в несколько (от двух до шести, а иногда и более) раз превышать затраты классического проекта внедрения. С одной стороны, естественно переплачивать за скорость получения результатов, когда часть работы приходится переделывать. С другой стороны, перерасход и необходимость переделок часто являются результатом недостаточно грамотного проектного управления как такового.
Нельзя также не отметить, что масштабные проекты создания инсорсинговых ИТ-компаний крупнейшими отечественными организациями генерируют на рынке повышенный спрос на ИТ-специалистов, раздувая затраты еще больше. Для того чтобы начать работу в кратчайшие сроки, айтишникам переплачивают, порождая цепочку завышенных ожиданий.
Объединение подходов, но не проблем
При выстраивании модели управления проектом важен выбор правильной комбинации: в каких частях управляем внедрением сами и применяем Agile (в быстро изменяющихся процессах), в каких привлекаем внешнюю экспертизу и управление по принципу fix price (сложная специфическая экспертиза, результат важнее скорости).
В ряде случаев может быть применен гибридный подход, когда управляющий проектом от подрядчика привлекается также в рамках модели time & material, когда эксперт по управлению привлечен от подрядчика, но ответственность за результат подрядчику не делегирована.
Грамотная комбинация дает возможность оптимизировать затраты и для заказчика, и для подрядчиков — и при этом достичь результата. Правильный микс внешних и внутренних ресурсов и эффективная схема управления с развитой системой делегирования обеспечивают успех проекта.
Есть и другие слагаемые уравнения по проработке проектов на старте. Например, типичная отечественная проблема внедрения бизнес-приложений — изобретение велосипеда. Правильный подход при внедрении стандартных систем вроде SAP или Siebel — выделение достаточного ресурса на то, чтобы получить полноценную картину их функциональности, и формирование на ее основе как можно менее кастомизированного решения. Акцент именно на изучении имеющихся возможностей, обучении и адаптации пользователей. У нас же часто систему максимально перекореживают, получая неизбежные дополнительные затраты на сопровождение и развитие.
Наконец, традиционно отечественные предприятия тратили большие ресурсы на «простые» проекты — закупку «железа», лицензий. «Сложные» проекты регулярно оказывались неправильно оцененными (как в меньшую, так и в большую сторону). Следует отметить, что ситуация постепенно меняется. Проекты с измеряемым бизнес-результатом, правильным подходом к управлению уже, пожалуй, в большинстве.
Правильный микс внешних и внутренних ресурсов и эффективная схема управления с развитой системой делегирования обеспечивают успех проекта.
Что мода на Agile делает с ИТ-рынком
Под влиянием моды на Agile ИТ-индустрия меняется: крупнейшие заказчики, создавая инсорсинговые подразделения, забирают у игроков рынка функцию управления ИТ-проектами и оставляют им функцию body shopping (предоставление рабочей силы).
ИТ-компании оказываются ограниченными и в своей классической функции «кузницы кадров», когда вчерашние студенты, приходя на позиции стажеров, включаются в проекты и через относительно короткое время становятся востребованными (но не переплаченными) специалистами. В случае, когда у вас приобретают ресурсы на условиях time & material, заказчик заинтересован получить в свое управление опытные кадры, для стажеров места просто не находится.
В свою очередь «конвейерный найм» как ответ на необходимость в быстром покрытии ресурсных потребностей клиентов в принципе не позволяет формироваться на стороне компании-подрядчика ни вменяемой корпоративной культуре, ни содержательной экспертизе, отделяемой от конкретных носителей.
Для ИТ-компаний интересным путем не превратиться в агентство по найму разработчиков, которое не накапливает экспертизу и не выступает носителем яркой корпоративной культуры, является перенос предметных знаний и интеграционного опыта в создание собственных продуктов.
Но трансформация в вендора — сложный путь. Во-первых, за душой должно быть то, что можно трансформировать, — задел подтвержденной рынком экспертизы. Во-вторых, успех превращения зависит от организационной способности компании меняться: бизнес-процессы должны быть хорошо устроены и управляемы, нужен организационный и финансовый запас прочности. На российском ИТ-рынке этот процесс до конца еще никто не проходил. Тем интереснее и значимее будет результат пионеров.
* На правах рекламы