Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Тенденции централизации и децентрализации управления в производстве ПО противоречивы и неоднозначны. Часть компаний впервые переходит к формализованному управлению проектами разработки с помощью некоторой организационной структуры (например, в Проектного офиса) после значительного укрупнения и усложнения бизнеса, часть же успешных мировых корпораций, наоборот, стремится к максимальной децентрализации, предоставляя отдельным успешным командам высочайший уровень автономности в части процессов производства и управления. Аналогичные противоречия мы видим в эволюции ролевой модели в каждой команде разработки: от упразднения роли проектного менеджера (Scrum, MSF) с заменой на скрам-мастера до тотальной и единообразной автоматизации и формализации каждого направления в разработке ПО в каждом проекте (управление требованиями, разработка, тестирование, документирование и т.д.). Более того, в составе «гигантов IT-рынка» такие противоположенные события происходят одновременно в разных продуктовых \ географических направлениях.
Вне зависимости от того, какой подход к управлению проектами разработки с соответствующей ему ролевой моделью выбран в организации почти всегда одна из важнейших областей управления остается недостаточно осознанной – это комплексное управление рисками. Парадигмы софтверной разработки и управления проектами в различных отраслях экономики предлагают довольно схожие классические процессы и артефакты для риск-менеджмента: регулярная оценка и мониторинг рисков, создание карты (реестра, каталога) рисков и разработка для них планов управления (например, план по митигации и план по аварийному преодолению), оценка \ прогнозирование ущерба от рисков и создание резервов, разработка процессных производственных моделей, в которые уже заложены планы по борьбе с типичными рисками. Цикл регулярной активности по управлению рисками также довольно схож во всех популярных методологиях: от начальной идентификации и ранжирования до регулярной актуализации карты рисков и оценки затрат (включая резервы) на борьбу с негативными последствиями.
Тем удивительнее, что такое весьма общее теоретическое видение проблемы управления рисками среди специалистов разных отраслей (IT, финансовые сервисы, строительство, научная деятельность) находит весьма слабый практический отклик на российском софтверном рынке, где формализация и дисциплина соответствующих процессов во многих даже лидирующих IT-компаниях остается слабой.
Также следует указать на специфические расширения привычных подходов риск-менеджмента, относящиеся к разработке ПО. Иногда это процессные модели и артефакты, иногда - элементы организационного развития, иногда - специальные акценты в типичной корпоративной деятельности:
Организация технологических и архитектурных комитетов (снижение технологических рисков);
Чрезвычайно активная образовательная \ менторская деятельность в IT-компаниях (снижение технологических рисков);
Сильные организационные матрицы (для снижения рисков в области HR);
Элементы парадигм разработки (например, в SCRUM церемонии демо, ретроспектива и стендап в том числе направлены на снижение технологических рисков).
Безусловно лучшим на проектном уровне является следующий системный подход:
Анализ и документирование типичных рисков в проекте (программе проектов) разработки ПО;
Разработка планов управления и создание резервов различного типа;
Регулярный мониторинг и оценка рисков и планов управления ими;
Эскалация рисков в рамках проектной отчетности;
Оценка успешности использования планов управления и резервов;
Планомерное и последовательное изменение части производственных процессов для ликвидации возможных рисков.
Данный системный подход позволяет значительно снизить неопределенности в выполнении софтверного проекта, хотя и требует регулярного внимания и выделение (или хотя бы оценки) резервов различного типа – трудовых, финансовых и т.д. Выделенные активности могут быть выполнены как при методическом (или контролирующем) участии Проектного офиса, так и самостоятельно командами разработки. Примечательным является постоянный референс проектного уровня риск-менеджмент на другие (уровень подразделения, уровень корпорации).
Рассмотрим некоторые примеры из практики консультантов SSC, иллюстрирующие внедрение формализованных практик управления рисками в проектах софтверной разработки. Так в одном из крупнейших европейских FOREX-брокеров с масштабной in-house разработкой и низким уровнем управленческой зрелости был применен подход комплексного управления рисками в проектах по методологии PRINCE2. В течение первых трех месяцев пилотного применения риск-менеджмента было установлено, что проектный уровень является необходимым, но не достаточным, а управление рисками должно распространяться, как минимум, на тактический уровень управления компанией и способствовать не только реализации проектных целей, но целей подразделений корпорации и более того - косвенно быть связанными с общими стратегическими целями. Не смотря на в целом неуспешный опыт внедрения корпоративного риск-менеджмента, проектный уровень был поддержан менеджерами довольно успешно, что позволило повысить успешность проектов по двум целевым показателям: завершенность в установленные сроки и удовлетворенность спонсоров проектов (программ проектов). Внедрение процессов и артефактов управления рисками в 50+ проектах одновременно показало: модель мышления менеджеров, направленная на постоянное снижение проектных рисков, поддерживает сразу все стороны треугольника управления проектами: бюджет, сроки и качество. А вот корреляция применения формализованного риск-менеджмента с возможностями повышения объемов работ в проектах оказалась отрицательной. Также следует отметить специфику данного консалтингового проекта: при определенных условиях процессы управления рисками могут одновременно внедряться и «снизу-вверх», и «сверху-вниз», хотя задача их согласования в таком случае остается очень сложной.
Намного чаще внедрение формализованного риск-менеджмента происходит централизовано и в рамках усилий специального подразделения. Примечателен опыт одного из консультантов SSC при организации Офиса управления проектами (ОУП) в российско-американской IT-компании: при внедрении процессной модели для ОУП риск-менеджмент шел сразу же после появления проектной отчетности. Т.е. была высоко оценена та польза, которую данный процесс несет для бизнеса организации, не смотря на необходимость сложных ментальных усилий менеджеров по изменению мышления в проектном управлении. Описываемое здесь внедрение риск-менеджмента кардинальным образом изменило модель эскалации проблем в организации и частично изменило производственные процессы разработки ПО. По сути, ОУП изменил саму структуру операционного менеджмента при возникновении проектных проблем, переместив фокус с реактивного реагирования на события в сторону активного планирования и прогнозирования сложных технологических рисков в разработке ПО.
Таким образом, потенциал управления рисками в софтверных проектах является значительным для роста качества продукта и успешности команды разработки. Практическое освоение формализованного управления рисками – это вопрос 4-8 недель для каждого проекта и требует минимальных управленческих и лидерских навыков, что позволяет каждому проектному менеджеру, скрам-мастеру или тим-лиду начать его самостоятельно. Впрочем, централизованное внедрение, как показывает практика консалтинговых проектов SSC, решает эти задачи быстрее и обеспечивает более надежное закрепление риск-менеджмента в реальной практике IT-компании. Вне всяких сомнений и без исключений, затрачиваемые усилия окупаются в течение первого года использования данного процесса даже в самых «спокойных» проектах, потому что разнообразные риски разработки коммерческих продуктов и сервисов только увеличиваются с развитием рынка. Внедрение формализованного риск-менеджмента – это довольно простой и дешевый способ борьбы с постоянной «технологической энтропией», которая во многих странах осложняется экономическими и геополитическими источниками нестабильности.
