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