Укрощение хаоса: как управлять рисками в ИТ-проектах и не потерять деньги

Как часто вы сталкиваетесь с тем, что какие-то процессы в вашей жизни идут не по плану? И постоянно в голове возникает мысль: а почему я это не предугадал, ведь этого можно было избежать. К сожалению или к счастью, предусмотреть все варианты развития событий просто невозможно, даже КПД не равен 100%. 

Особенно такие ситуации актуальны, когда появляются две стороны, например, заказчик и исполнитель. И сфера ИТ не исключение. Рассмотрим ситуацию, вы договорились об объемах работ, и тут заказчик говорит: “просто добавь эту маленькую фичу”, то тут к гадалке не ходи, что она потянет за собой еще десяток взаимосвязанных задач. Как раз в этот момент мы сталкиваемся с риском “не уложиться в бюджет или в сроки”. Поэтому грамотное управление scope и оценка рисков помогают держать проект под контролем.

Управление рисками – это не просто скучная бюрократия, а жизненно важный навык, позволяющий не только избежать катастрофы, но и прийти к финишу с прибылью и довольным заказчиком. В этой статье рассмотрим, как возникают риски, какие они бывают и как ими управлять. Но для начала давайте познакомимся. 

Меня зовут Никита Россихин, я руководитель проектного офиса в компании RDN Group. Наша команда специализируется на разработке сложных и высоконагруженных решений для промышленных компаний: личных кабинетах, торговых площадках, порталах и интеграционных проектах. RDN Group одна из немногих партнеров 1С-Битрикс с компетенцией крупные корпоративные внедрения расширенного уровня, которая нужна для выполнения Enteprise проектов. Мой опыт работы управления ИТ-проектами составляет 10 лет, поэтому я готов поделиться своими знаниями с вами. 

За все время работы для себя я выделил два основных риска, к которым сводится любая проблема - это бюджетный риск с правовым полем контракта и сложностями аккаунта взаимодействия с заказчиком (не настроить заказчика против себя и в тоже время находится в правовом поле) и риск изменения объема работ. Но по факту это все равно по итогу сводится в бюджетный риск. Так как риск изменения объема работ тянет за собой временной риск, и сюда сразу же отнесем риск качества работ, потому что противодействовать риску, связанному с дополнительным объемом работ можно фаскт-трекингом. Простыми словами, это когда ты заваливаешь проект ресурсом, если что-то не успеваешь сделать, но при этом нужно помнить, что в таком случае увеличивается бюджет. И, соответственно, все вытекает в бюджетный риск. 

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

В таком случае возникает необходимость в срочном поиске замены и адаптации нового сотрудника, погружение его в проект. Этот процесс требует времени и ресурсов, что неизбежно приводит к увеличению бюджетных затрат.

Линия старта: договор и пресейл

Начнем с базы. Прежде чем погрузиться в пучину кода и дизайна, необходимо заключить договор. Определите, что для вас выгоднее: фиксированная цена (Fixed Price) или оплата по времени и материалам (Time & Materials). От этого зависит стратегия управления рисками. 

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

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

Грейд примерно следующий: если проект уровня Энтерпрайз, то мы готовы потратить на него несколько месяцев работы над пресейлом, но если мы видим, что заказчик не до конца понимает, нужен ли ему этот проект или нет, у него отсутствует сформированная потребность, нет проблематики, то можно потратить уйму времени просто на продажу идеи внедрения проекта. И тогда встает вопрос, а стоит ли овчинка выделки? Если заказчик не определился с потребностями, не имеет четкого видения конечного продукта, будьте готовы к тому, что пресейл превратится в долгий и утомительный процесс "продажи идеи".

Риск, аппетит или на что мы готовы пойти 

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

После чего нужно определить свой риск-аппетит – на какие риски вы готовы пойти ради потенциальной выгоды. Проведите скоринг лида, оцените потенциального заказчика и его проект. 

Многие компании отказываются от классического "водопада" (Waterfall) и не хотят начинать проект с ППО, в таком случае мы оцениваем проект, основываясь на нашей экспертности ресурсным подходом.

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

К этой оценке рекомендуется добавлять примерно определенный процент  – своеобразную "подушку безопасности", которая зависит от ваших прямых и косвенных затрат. Риски объясняются отсутствием ТЗ, ППО и тем, что "аппетит приходит во время еды" – заказчик захочет больше функциональности, чем планировалось изначально.

Roadmap и рентабельность проекта

После определения бюджета необходимо составить дорожную карту проекта (roadmap), отражающую взаимосвязь между временем, ресурсами и стоимостью. На этом этапе важно помнить, что создание продукта – это совместная работа команды разработчиков и заказчика.

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

Заложите в сроки время на согласования и итерации, которых может быть от 3 до 6. 

Также, предусмотрите больше времени на самые критически важные модули. 

И не забывайте о главном – рентабельности проекта.

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

Пример ROADMAP проекта

Вам также может быть интересен материал Компас CIO:

Движение без пробуксовок: как не тратить лишние силы на трансформацию бизнеса

Риски отдельных проектов — только верхушка айсберга: 88% трансформационных инициатив терпят неудачу из-за системных "пробуксовок". Как диагностировать, где именно застревает процесс изменений? Матрица из 9 типов проблем, спиральный метод устранения и конкретные техники работы с сопротивлением команды при внедрении новых процессов.

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

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

При использовании гибридного подхода суть работы заключается в следующем: каждая задача рассматривается как отдельный проект со своим жизненным циклом, включающим этапы аналитики, дизайна, разработки и тестирования. Жизненный цикл каждой задачи начинается с аналитики, где определяется объем работ. Ключевым моментом является согласование ЧТЗ (частного технического задания) и дизайн-макетов (при наличии дизайна) на эту задачу. После согласования этих артефактов, любые отклонения от них должны трактоваться как дополнительные работы.

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

Приемка и релиз: зона ответственности и тестирование.

Успешное завершение проекта зависит не только от качественной разработки, но и от грамотной организации процесса приемки и релиза. Необходимо заранее прописать в договоре:

• Критерии приемки: Четкие критерии, которым должна соответствовать система для успешной приемки заказчиком.
• Интеграционное тестирование: Необходимость проведения интеграционного тестирования для проверки совместимости системы с другими системами заказчика. Если заказчик отказывается от проведения тестирования и говорит, что не хочет тратить деньги на приемку, то важно прописать в договоре, что далее ответственность переходит на заказчика. Мы передаем корректный код, который работает на наших серверах. 
• Зону ответственности: Разграничение ответственности за ошибки и недочеты, возникшие на стороне заказчика (например, из-за некорректных данных).
• Сроки обратной связи: Регламентированные сроки предоставления обратной связи заказчиком. В случае нарушения сроков, подрядчик не несет ответственности за сдвиг сроков релиза.

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

Риски при переходе проекта в техподдержку

При переходе проекта к техподдержку примерно за месяц до релиза рекомендуется:

• Оформить юридическую основу: Составить договор, четко определяющий границы ответственности, состав команды поддержки (пул), уровни сервиса (SLA) и порядок приема задач. Это позволит избежать разногласий и четко понимать, кто за что отвечает.

• Установить личный контакт: Не ограничивайтесь формальным договором. Проведите "кулуарные" переговоры, чтобы установить доверительные отношения с командой поддержки и заказчиком. Обсудите детали взаимодействия и найдите взаимопонимание.Такой подход позволит не только юридически защитить ваши интересы, но и создать благоприятную атмосферу для эффективной технической поддержки, обеспечивающей стабильную и надежную работу вашего проекта.

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