Риски — это неизбежная реальность любого бизнеса. Избежать их полностью практически никогда невозможно. Управление рисками строится на том, чтобы минимизировать вероятный ущерб и повысить эффективность деятельности компании. Алексей Александров, генеральный директор компании SEBEKON, рассказал «Бизнесологу», как управлять рисками в IT-проектах.
Алексей Александров, генеральный директор компании SEBEKON, эксперт в области разработки сложных web-проектов.
— Шеф, я заболел. Работать в ближайшую неделю не смогу.
— Нет, договор на подключение эквайринга мы не заключили еще.
— А давайте сделаем так. Я точно не знаю как, но хочется попробовать.
— Ой, а начальник еще не согласовал дизайн. И вообще он сейчас в отпуске, вернется через две недели.
Знакомо? Все эти фразы — это иллюстрации рисков, которые возникают в любом it-проекте.
За всеми it-рисками, на наш взгляд, почти всегда стоят люди:
- кто-то переоценил себя и своих коллег и замахнулся на амбициозный проект, на которых не хватило сил и ресурсов;
- кто-то, наоборот, грамотно посчитал все ресурсы и замахнулся на масштабный проект, который по факту не нужен его компании на данном этапе развития;
- кто-то решил, что нашел грамотного исполнителя, который сделает все правильно без дополнительного участия заказчиков в проекте.
Если не классифицировать и не оценить риски на подготовительном этапе, то у заказчиков есть большая вероятность либо сильно затянуть сроки внедрения, либо вовсе не получить проект, а у подрядчиков — нарушить сроки или вовсе провалить проект и чувствительно ударить по репутации.
У опытных web-разработчиков есть уже перечень рисков, которые можно предотвратить на старте проекта. Причем для каждого нового проекта этот реестр будет индивидуален.
- Как мы управляем ИТ-рисками
- ИТ-риски и их классификация
- Недостаточная поддержка проекта со стороны заказчика
- Недостаточная поддержка со стороны пользователей ИТ-системы
- Несоответствие реализации бизнес-процессов в системе ожиданиям заказчика
- Расширение функциональных требований в процессе реализации проекта
- Недоступность членов рабочей группы
- Изменение состава рабочей группы
- Изменение бюджета и сроков проекта
- Несвоевременное предоставление необходимых документов со стороны заказчика
- Несвоевременное заключение договоров заказчиком со сторонними сервисами, получение тестовых и боевых доступов для интеграции
- Неполнота отражения ожидаемых результатов проекта
Как мы управляем ИТ-рисками
В нашей компании есть документ: таблица с описанием рисков, с которыми мы когда-либо сталкивались в своей практике. Она постоянно дополняется и расширяется. На ее основе для каждого нового проекта мы готовим отдельный документ по возможным рискам. Он содержит не только перечень рисков, но и их описание, способы его предотвращения и устранения последствий.
Для некоторых заказчиков мы даже делали отдельные презентации по возможным рискам, но впоследствии отказались от этого. Некоторым такие меры могут показаться лишними: достаточно проговорить возможные риски в рамках очередной встречи заказчиков и подрядчиков. Однако в том, что касается рисков, лучше сделать как минимум отдельный документ, в котором зафиксировать все риски проекта и способы их минимизации.
ИТ-риски и их классификация
- По источнику риски бывают внутренние, т.е. происходящие внутри команды разработчиков, и внешние, зависящие от компании-заказчика.
- По степени влияния риски делятся на высокие, средние и низкие.
Рамки статьи не позволяют детально рассмотреть все существующие риски, поэтому мы выбрали из своей практики пример проекта по разработке CRM-системы.
На начальном этапе мы сформировали список возможных рисков, оценили их по степени влияния, описали и составили рекомендации по уменьшению и/или преодолению риска.
1. Недостаточная поддержка проекта со стороны заказчика
Степень риска: низкая.
Недостаточный опыт управления и низкий уровень знаний специфики бизнеса могут привести к задержке решения ключевых вопросов о планировании работ, выделении ресурсов, приемки конечных результатов проекта.
Чтобы уменьшить риск, необходимо:
- предоставить руководителю проекта необходимые полномочия;
- привлечь в рабочую группу (далее: РГ) экспертов с необходимыми для проекта компетенциями.
Многие заказчики полагают, что их финансового участия в проекте достаточно. Часто на роль руководителя проекта по созданию сайта со стороны клиента, например, в среднем сегменте, назначают менеджера по продажам. Логика простая: он умеет продавать, значит разберется и в разработке интернет-магазина. Между тем, этот менеджер не обязан знать отличия офлайн- и онлайн-поведения покупателя. Безусловно, у него есть свои представления о хорошем интернет-магазине, но они могут расходиться с бизнес-задачами компании в целом.
И вот под его руководством сделали дизайн, сверстали, напрограммировали. Он посмотрел, не вник, но работу принял. А потом оказывается, что все работает не так, как задумывалось: первый же заказ не попал туда, куда нужно, или попал, но по другому сценарию и т.д.
Чаще всего такого рода риски возникают в небольших компаниях либо в огромных госпредприятиях (например, в вузе в рабочую группу по разработке сайта могут включить преподавателей, которые в принципе плохо понимают, зачем нужен сайт). Чем крупнее компания, тем больше шансов, что у нее есть IT-отдел, который будет заниматься проектом.
2. Недостаточная поддержка со стороны пользователей ИТ-системы
Степень риска: средняя.
Поддержка со стороны пользователей системы крайне важна для успеха проекта. В противном случае возможно увеличение стоимости / продолжительности проекта, неполное / неправильное понимание требований заказчика.
Чтобы уменьшить риск, необходимо:
- дать четкие указания, касающиеся поддержки проекта, подготовить и провести собрание, подготовить приказ или иной документ, в котором будут зафиксированы эти указания;
- контролировать участие сотрудников компании-заказчика в проекте;
- провести обучение сотрудников компании-заказчика;
- передать промежуточную версию системы сотрудникам для тестирования.
В среднем в проекте бывает 5-6 итераций. Если пренебречь последним пунктом, то подрядчик может допустить ошибки, которые фатальным образом скажутся на функционировании всей системы.
3. Несоответствие реализации бизнес-процессов в системе ожиданиям заказчика
Степень риска: низкая.
Недопонимание бизнес-процессов заказчика подрядчиком может привести к несоответствию реализованной системы ожиданиям заказчика.
Для преодоления данного риска необходимо:
- согласовать протоколы встреч с участниками со стороны заказчика.
- настроить и провести показ прототипов системы для детализации требований.
4. Расширение функциональных требований в процессе реализации проекта
Степень риска: средняя.
Расширение функциональных требований к системе после завершения первого этапа приведет к увеличению сроков и бюджета ИТ-проекта. Риск в том, что часть уже сделанных работ может оказаться лишней из-за изменения архитектуры решения.
Чтобы уменьшить риск, необходимо:
- ответственно относиться к выработке требований к системе на подготовительных этапах и согласованию итоговых документов;
Под ответственностью понимается взвешенное отношение к формированию технического задания. Так, лучше сделать минимальный функционал и потом его дорабатывать, чем сразу нагородить множество функций и на этапе тестирования понять, что половина из них лишние.
- привлечь ключевых пользователей будущего решения к обсуждению и согласованию формулировок на начальных этапах.
Для преодоления риска следует обсудить расширения и после этого принять одно из решений:
- пересмотреть согласованные рамки текущего этапа проекта — добавить недостающие этапы работ, если их действительно необходимо провести;
- включить эти этапы в дополнительное соглашение по следующему этапу проекта либо в договор сопровождения;
- отказаться от расширительных требований и продолжить работу в рамках ранее утвержденного перечня работ.
5. Недоступность членов рабочей группы
Степень риска: низкая.
Физическое отсутствие одного или нескольких членов РГ может привести к задержке решения вопросов по проекту и к увеличению сроков проекта.
Чтобы уменьшить риск или полностью его преодолеть, необходимо заранее планировать встречи с учётом отпусков и командировок, а также назначить заместителей.
6. Изменение состава рабочей группы
Степень риска: средняя.
Смена участников РГ в ходе проекта может привести к нарушению сроков и низкому качеству работ.
Чтобы уменьшить риск, необходимо:
- заранее планировать встречи с учетом отпусков и командировок;
- мотивировать участников проекта сохранять состав РГ в неизменном виде.
Для преодоления риска необходимо:
- привлечь дополнительных сотрудников из компании при изменении состава РГ для помощи в работе новому участнику;
- скорректировать состав работ, выходных результатов или рамок текущего этапа, если невозможно быстро решить вопросы замены участника РГ;
- скорректировать сроки выполнения работ, если невозможно изменить рамки проекта.
Этот риск может возникнуть как на стороне заказчика, так и на стороне исполнителя. Новым участникам рабочей группы необходимо время для того, чтобы вникнуть в ход проекта. Как правило, в таких случаях времени обычно не бывает. Новому разработчику нужно пересмотреть все, что было сделано до него. Новому руководителю проекта нужно прочитать множество документов, протоколов встреч, наладить контакт со всеми участниками и т.д.
Для подрядчика этот риск связан с рисками 8 и 9. Например, заказчик не предоставил нужные документы и\или доступы к сторонним сервисам. Руководитель проекта перебрасывает разработчиков на другой проект, чтобы у них не было простоя в работе. В итоге, когда доступы получены, разработчики могут быть еще заняты на другом проекте. И тут заказчику либо приходится ждать, когда они освободятся, либо опять ждать, когда другие разработчики вникнут в проект.
7. Изменение бюджета и сроков проекта
Степень риска: низкая.
Неопределенность объемов и сроков финансирования проекта может привести к затруднениям при планировании и использовании необходимых ресурсов. в итоге проект может быть затянут. Несоблюдение графика платежей может стать причиной задержки проекта, вплоть до прекращения работ.
Чтобы уменьшить риск, необходимо:
- согласовать и утвердить бюджет всего проекта, график платежей;
- соблюдать график платежей;
- своевременно проинформировать стороны, вовлеченные в проект, в случае нарушения графика платежей и выработать общее решение вопроса задержки платежа;
- соблюдать график сдачи работ по проекту;
- определить порядок действий при нарушении сроков платежей или сдачи работ
Для преодоления риска необходимо своевременно провести встречи со всеми сторонами и выработать согласованный план действий:
- сдвиг плана проекта;
- уменьшение объема работ;
- перенос работ на другой этап и т.д.
8. Несвоевременное предоставление необходимых документов со стороны заказчика
Степень риска: низкая.
В случае несвоевременного предоставления заказчиком документов, необходимых для реализации проекта, возможен сдвиг сроков реализации этапа ТЗ и проекта в целом.
Чтобы уменьшить риск, необходимо:
- заранее сформировать запрос на предоставление документов в начале разработки ТЗ;
- составить график предоставления документов;
- включить данные по статусу получения документов в отчет по проекту.
Для преодоления риска следует скорректировать план проекта, перенести работы по на более позднее время.
9. Несвоевременное заключение договоров заказчиком со сторонними сервисами, получение тестовых и боевых доступов для интеграции
Степень риска: средняя.
В случае несвоевременного предоставления заказчиком тестовых / боевых доступов к сторонним сервисам, необходимым для реализации проекта, возможен сдвиг сроков запуска.
Чтобы уменьшить риск, необходимо:
- сформировать запрос на предоставление доступов в процессе разработки ТЗ;
- составить график предоставления доступов;
- включить данные по статусу предоставления доступов в отчет по проекту.
Для преодоления риска необходимо скорректировать план проекта, перенести работы на более позднее время.
Несмотря на то, что на каждом проекте мы фиксируем возможные риски и просим заранее организовать все регистрации, доступы и договоры со сторонними сервисами, все равно часто случаются простои из-за несвоевременного заключения договоров. При этом мы со своей стороны для избежания простоев разработчиков можем перекинуть их на других проекты, с которых потом не всегда оперативно можем вернуть их обратно.
10. Неполнота отражения ожидаемых результатов проекта
Степень риска: средняя.
Решения, проговоренные устно на рабочих встречах, могут быть не зафиксированы документально.
Чтобы уменьшить риск необходимо:
- документировать все существенные результаты встреч и совещаний в протоколах или иных документах;
- согласовывать в письменной форме протоколы встреч со всеми участниками.
Для преодоления риска необходимо оперативно добавить новую утвержденную и согласованную информацию во все исходные документы и устранить все разногласия.
Однажды менеджер одного из наших проектов передал его на тестирование заказчику. Во время тестирования вылезли ошибки. Менеджер со стороны заказчика позвонил нашему менеджеру и перечислил, что нужно поправить. Наш менеджер передал все разработчикам для исправления. Ошибки были устранены, сайт заработал как надо.
Наш менеджер выставил счет на оплату проведенных работ. В компании-заказчике эта сумма не была согласована внутри и стала неприятным сюрпризом. Дальше была череда изматывающих встреч, в ходе которых мы со своей стороны доказывали свою правоту и отстаивали стоимость работ, заказчики пытались уйти от оплаты без договора. В итоге для нас все закончилось благополучно, но нервов было потрачено много. Зато теперь мы на каждую работу, не прописанную в основном договоре делаем дополнительное соглашение и не приступаем к реализации работ до подтверждения со стороны заказчиков.
Список рисков можно продолжать бесконечно. И все они, как правило, взаимосвязаны друг с другом. Для наглядности мы собрали в схему описанные выше риски и стрелками показали их зависимости друг от друга. Помните, что даже риск, оставленный без внимания, тянет за собой как минимум еще один.
