Риски: классификация

Продолжаем серию блогов про управление рисками. Переходим к практике и разбираем конкретные примеры, каждый из которых относится к определенному пункту в классификации, принятой в Digital Zone.

Организационные риски

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

Безответственная перегрузка проекта несущественными, но затратными работами со стороны заказчика. Неожиданные организационные задачи (оформление документов, пропусков, лицензий и пр.)

Внезапные командировки и длительная работа в незапланированном режиме при создании интернет магазина.

Решение: максимальное регламентирование организационных процессов. Описание большинства проблемных точек автоматически делает их эффективнее.

Технические риски

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

Решение: резервирование оборудования и каналов по принципу n+1, с учетом стоимости обслуживания риска.

Незнакомая технология

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

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

План по компенсации наступления риска — заложить в проекте сумму и время на дополнительные работы. Возможна смесь подходов: эксперименты провести, но в самых критичных местах, по которым ожидается высокий риск или потенциально больший срок работы. Остальные участки оставить в рамках проекта, но заложить сумму (меньшую) и время на неожиданности.

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

Нехватка операционного финансирования

Контрактные условия проекта — 100% постоплата. Длительность — год, состав — 8 сотрудников. Финансовая служба легко посчитает затраты на ведение проекта, на возможные риски по задержке сдачи. Очевидно, что они должны покрываться прибылью с других заказов или оборотным кредитом. Отдельно отметим, что финансовый план такого проекта должен учитывать стоимость денег. То есть, в затраты должна входить реалистичная процентная ставка по займу на сумму, необходимую для ведения контракта. В случае гарантированного финансирования из прибыли, пожалуй, более честно будет указать процентную ставку по депозиту, но в этом случае риска как такового нет.

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

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

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

Кадровые риски

Проект требует программиста на языке Cobol в версии для IBM TSO, а у нас он всего один. И если ему захочется задауншифтиться на Гоа, то кто работать?

Решение: сделать кусок на Cobol до начала проекта. Уговорить заказчика, что Groovy круче. Или хотя бы Fortran, для него у gcc фронтенд есть. Найти второго программиста на Cobol на этой планете и взять его на работу. Посадить его изучать Java.

В целом кадровый риск есть всегда, даже если вы 100% проектов пишете на BASIC и в компании 100 программистов на нем.

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

Правовые риски

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

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

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

Внешние риски

Смена генерального директора компании-заказчика. Новый директор формирует другие требования к итогу проекта, и исполнитель вынужден либо подчиниться, либо расторгать контракт, неся потери и выпадая из плана (см. финансовые риски).

Смена любого стейкхолдера проекта, например при создании сайтов.

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

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

Некачественное или несогласованное с вами исполнение работ третьими лицами (реализовали не то API, к которому вы были готовы архитектурно).

Финансовые проблемы у заказчика

Несвоевременная закупка лицензий заказчиком.

Решение: не забывайте отражать ответственность заказчика в контракте.