Что можно сделать с риском
4 стратегии работы с рисками, о которых следует знать каждому руководителю проекта
Большая часть проектов изначально неверно оценивается по срокам и бюджетам. Руководители слишком оптимистичны и не думают о возможных проблемах (рисках). За это они расплачиваются: тратят слишком много усилий на борьбу с последствиями материализации рисков. В итоге плановый срок проекта зачастую превышается в разы. Как грамотно управлять рисками, рассказывает наш эксперт Максим Якубович.
В предыдущей статье мы рассмотрели два риска для проекта «Внедрения CRM и автоматизации процессов управления отношениями с клиентами».
Риск 1. Выбор программного продукта без понимания полного списка требований к нему. Приведет к необходимости делать большое количество доработок продукта под процессы компании (а это означает «расползание» рамок проекта и рост объемов работ).
Риск 2. Изменение требований к программному продукту по ходу проекта внедрения. Приведет к «расползанию» рамок проекта и росту объемов работ по нему.
Управление рисками сводится к тому, чтобы нивелировать их влияние на проект, а в идеале – полностью убрать потенциальную проблему из проекта.
Планируя реагирование на риски, важно сопоставлять стоимость последствий их материализации и стоимость мероприятий по реагированию. Экономическая суть управления рисками сводится к выбору антирисковых мероприятий, которые стóят меньше, чем последствия риска, но при этом сводят вероятность или влияние риска на проект к минимальному значению (в идеале – к нулю). Поэтому мы должны проработать несколько вариантов антирисковых мероприятий и выбрать оптимальные.
В литературе по управлению проектами чаще всего описываются четыре стратегии работы с рисками.
Рассмотрим их на примере нашего кейса.
Стратегия уклонения предполагает полное исключение риска из проекта. Мы должны придумать реагирование, которое позволит быть уверенными, что риск не материализуется. Это самая «дорогая» стратегия, т.к. для некоторых рисков она вынуждает отказываться от определенных работ, менять цели проекта или, в самом радикальном случае, отказываться от проекта.
Попробуем уклониться от риска неполного списка требований (риск 1).
Можно ли быть уверенным на 100%, что мы собрали все требования? Я считаю, это невозможно. Даже если мы будем считать, что собрали все, по ходу реализации проекта может возникнуть новое требование.
В случае изменений требований к программному продукту по ходу проекта внедрения (риск 2), мы можем избежать риска материализации, если пропишем в контракте, что требования изменять нельзя ни под каким предлогом и ни при каких обстоятельствах. Согласитесь, это звучит как минимум странно.
Стратегия передачи перекладывает последствия материализации риска и ответственность за реагирование на третью сторону, при этом сам риск не устраняется. Эта стратегия практически всегда предполагает финансовые затраты на передачу и получение финансовой компенсации в случае материализации риска.
Можем ли мы передать кому-то риск, связанный с неполными требованиями? Как вариант, мы можем передать работу, связанную со сбором требований, консультантам «под ключ», прописав в контракте штрафные санкции за ошибки (это будет непросто, но вполне возможно).
Можно передать и риск, связанный с изменением требований. Но нужно подумать, кому его передавать. Ключевым источником изменения требований, как правило, выступает заказчик. В уставе проекта (или контракте на проект) руководитель проекта прописывает, что при любом изменении требований понадобится пересмотр базового расписания проекта и базового бюджета. В этом случае, если риск материализуется, команда получает дополнительное время и дополнительный бюджет.
Стратегия снижения является самой распространенной и может применяться к любому риску, т.к. подразумевает уменьшение вероятности или влияния риска на проект.
Применим эту стратегию для наших рисков. Сначала проработаем риск с неполными требованиями.
Можно ли как-то снизить вероятность того, что список требований окажется неполным? Я думаю, если мы сбор требований выведем в отдельный проект или этап проекта, при этом на эту работу привлечем профессионального бизнес-аналитика (или нескольких), и выделим на проект представителя заказчика, который будет отвечать за утверждение требований, то резко снизим вероятность того, что некоторые важные требования будут пропущены. Но лишь снизим вероятность, а не полностью устраним этот риск.
Как можно снизить влияние риска, связанного с неполными требованиями, на проект? Один из вариантов – учесть вероятность пропуска требований при проработке архитектуры продукта. Однако не для всех случаев он сработает. Некоторые новые требования будут крайне трудоемкими в реализации без серьезных переделок архитектуры.
Вероятность риска, связанного с изменениями требований, можно снизить, разработав и внедрив специальную процедуру работы с изменениями требований. Она должна внести ясность и понимание того, как обрабатываются запросы на изменения. Процедура заставит задуматься тех, кто хотел бы внести изменения в требования, о том, насколько сложно это будет сделать. И, возможно, приведет к желанию лучше проработать требования изначально.
Как можно снизить влияние риска, связанного с изменениями требований, на проект? Один из вариантов – включить алгоритм оценки влияния изменений на срок и бюджет проекта. Как минимум, принимая решения об изменениях, заказчик будет понимать их стоимость и от некоторых изменений, возможно, откажется.
Ну и четвертая стратегия – это принятие риска.
Как кажется из названия стратегии, до наступления риска предполагается «ничего не делать». С нашей ментальностью это часто любимая стратегия работы с рисками. Однако совсем ничего не делать – это не управление рисками. Есть два варианта для четвертой стратегии – активное и пассивное принятие.
Активное – формируется резерв времени и денег на устранение последствий материализации риска.
Пассивное – предполагает наличие плана Б (устранения последствий проблемы) на случай, если риск материализуется.
Рассмотрим стратегию активного принятия для риска неполных требований.
В случае если некоторые требования будут пропущены, нам нужно иметь запас времени и бюджета на их устранение. В каком размере заложить этот запас? Ответ зависит от количества пропущенных требований и сложности их реализации. Не имея никакого прогноза на этот счет, мы можем заложить любой резерв, на который согласится заказчик проекта. Понятно, что для руководителя, чем больше резерв времени и денег – тем лучше, а для заказчика проекта – наоборот. Поэтому размер резерва станет предметом переговоров.
Для риска изменения требований стратегия активного принятия та же. И размер резерва времени и денег так же становится предметом переговоров.
Пассивным принятием для обоих рисков станет использование резерва времени и денег, который был заложен в проект.
Итак, из описанных четырех стратегий нужно выбрать те, которые наиболее адекватно подходят нам с точки зрения стоимости воплощения.
Обобщим стратегии в таблице.
Проанализируем, какие из описанных стратегий наиболее уместны для риска, связанного с пропуском требований:
1. Стратегия уклонения от риска невозможна.
2. Передать работу, связанную со сбором требований, консультантам «под ключ», прописав в контракте штрафные санкции за ошибки в сборе требований. Вполне уместная стратегия, если у вас в штате нет своих бизнес-аналитиков или они заняты на других проектах.
3. Сбор требований выделить в отдельный проект или этап проекта – это возможный вариант и в случае выбора «водопадной» модели жизненного цикла проекта так оно и будет.
Привлечь профессионального бизнес-аналитика (или нескольких) – эта стратегия отличается от передачи сбора требований консультантам «под ключ» степенью ответственности. В этом случае мы не предполагаем, что бизнес-аналитики выплатят штраф, если пропустят какие-то требования. Просто может пострадать их репутация.
Выделить на проект представителя заказчика, который будет отвечать за утверждение требований, – это очень правильный шаг.
Учесть вероятность пропуска требований при проработке архитектуры продукта – если мы покупаем коробочный продукт, то сделать это уже невозможно.
4. Заложить запас времени в расписание проекта и резерв в бюджет проекта – я бы постарался это сделать.
Итак, из четырех стратегий для риска, связанного с неполными требованиями, я бы сначала попробовал отдать работу по сбору требований «под ключ» компании, специализирующейся на этом виде услуг. Если заказчик откажется от этого варианта, то использовал бы возможные мероприятия для стратегии снижения риска и стратегию активного принятия.
Для второго риска подход абсолютно аналогичен.
После выбора стратегий работы с рисками руководителю проекта необходимо заложить все антирисковые мероприятия в план проекта, добавить резервы времени и денег для тех рисков, по которым была принята стратегия активного принятия, рассчитать срок и бюджет проекта с учетом рисков. И только после этого можно согласовывать с заказчиком плановый срок проекта и его бюджет.
Проект, для которого сроки и бюджет рассчитаны с учетом антирисковых мероприятий, имеет гораздо больше шансов стать успешным.
Мне после полученных уроков на выполненных проектах стало понятно, что управление рисками – это одна из главных областей знаний, в которой должен развиваться руководитель проекта.
Удачи вам в управлении рисками и успешных проектов!
Эксперт по управлению проектами, консультант и бизнес-тренер консалтинговой группы «Здесь и сейчас».
Опыт работы в сфере управления проектами – более 10 лет.
20 выполненных проектов в роли руководителя проекта и руководителя программы проектов.
Опыт преподавания – 8 лет. Около 2000 студентов, прошедших обучение на его семинарах.
Преподаватель модуля «Управление проектами» Русской школы управления.
Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна.
Ведущий блога по управлению проектами.
11 правил управления рисками: полный гайд по методикам риск-менеджмента
Содержание статьи
Как уже не единожды говорилось, торговля на финансовых рынках является высокорискованным родом деятельности, а чтобы добиться успеха в трейдинге, следует минимизировать потенциальные риски. Этот аспект трейдинга также не раз освещался в этом блоге с разных сторон и всё же, есть необходимость в систематизации всех «озвученных» мыслей по данной теме в одном полноценном тексте. Поэтому я уверен, что этот пост будет полезен для читателей.
В этом посте пойдет речь о том, что можно сделать для сокращения рисков в трейдинге. Хочу подчеркнуть, что данный перечень практических действий был предложен одним из авторов статей для издания “Stocks & Commodities” Джорджем Р. Аррингтоном (George R. Arrington).
Рассмотрим перечень некоторых правил, которые следует соблюдать для сокращения возможного убытка. Думаю, что если вы торгуете или когда-либо торговали раньше, то многими из этих методов вы пользовались, возможно, даже не подозревая об этом.
Перед открытием сделок проведите тщательный анализ
Прежде чем подвергать свой капитал риску, следует обрести уверенность, что вы обладаете максимально полной информацией и полностью осознаете, по каким причинам вы хотите открыть позицию. Помимо скрупулезного анализа графиков необходимо также четко представлять, какой суммой капитала вы готовы рискнуть в конкретной сделке и где вы должны выйти из позиции, чтобы не потерять больше запланированного в случае, если рынок пойдет против вас.
Проводя анализ, подготовьте список инструментов с описанием причин открытия позиций и уровнями входа и выхода из них (если количество одновременно открытых позиций у вас невелико, такой список можно держать в уме). Просчитав риски, вычеркните из него слишком рискованные сделки и те, сигналы по которым вызывают у вас сомнения. Так вы проведете предварительный отбор сделок и исключите из торговли наименее эффективные из них.
Составляйте торговый план
В чем конкретно заключается план? Это список ваших ежедневных операций, соответствующих выбранному стилю торговли. Вам необходимо провести исследования и создать методику, подходящую вам по всем ключевым параметрами, после чего зафиксировать ее на бумаге.
Здесь же вы должны описать приемлемый риск на каждую позицию и на всю совокупность сделок, а также ожидаемые целевые ориентиры, оправдывающие планируемые затраты. Если вы закладываете риск на сделку в 2%, а выходите, получив лишь 1%, вы сразу же ставите себя в заведомо невыгодное положение, поскольку рано или поздно потери перекроют прибыль и торговля окажется убыточной. Если в процессе торговли вы исчерпаете установленные лимиты потерь, лучше прерваться на некоторое время, выйти из рынка и осмыслить произошедшее.
Проводите диверсификацию
Не переводите на торговый счет все свои сбережения
Убедитесь, что на вашем счете достаточно средств, чтобы уверенно поддерживать в рынке открытые позиции. Лучше всего иметь на резервном счете дополнительные средства, которыми можно оперативно восстановить маржинальное обеспечение в случае неблагоприятного движения цены. Некоторые трейдеры специально разделяют сумму для торговли на несколько счетов или вносят на основной аккаунт лишь такие деньги, что позволят открыть одну-две сделки, чтобы избежать соблазна задействовать в торговле весь доступный капитал.
Используйте Stop Loss
Даже если вы считаете, что в состоянии самостоятельно контролировать позиции в рынке и успеете при необходимости закрыть их вручную, это не так. Достаточно отвлечься от монитора на 5-10 минут, и резкий рывок цены может значительно уменьшить ваш депозит, или связь прервется в самый неподходящий момент, или пропадет электричество. В конце концов, в решающие минуты вам может попросту не хватить решимости закрыть убыточную сделку (терять деньги всегда жалко), и вы продолжите наблюдать, как в надежде на разворот цены на вашем счете растут убытки.
Помимо этого, можно воспользоваться стопом, выставленным по времени. Если ордер остается в рынке определенное время, за которое цена не демонстрирует ярко выраженной динамики, то сделка закрывается вне зависимости от имеющегося результата.
Отдавайте предпочтение торговле по тренду
Следование за трендом уменьшает вероятность получения убытков в сравнении с контртрендовой торговлей или в попытках поймать развороты. Если вы торгуете по тренду, то даже не совсем точный вход в рынок позволит закрыть позицию если не с прибылью, то хотя бы без потерь. В случае, если момент для открытия сделки оказался явно неудачным, уменьшайте размер риска.
Не бойтесь признать свою неправоту и получить убыток
Признать свои ошибки зачастую оказывается не так-то просто. Но если вы научитесь это делать и вовремя выходить из убыточной позиции, то сможете сохранить значительную часть своего депозита. Помните, что все профессионалы точно так же несут убытки. В этом им помогает давно известное правило: «Режьте убытки и давайте прибыли расти».
Помните о мерах защиты при торговле
Торгуйте в меру
Держите эмоции под контролем
Эмоции являются неотъемлемой частью жизни каждого человека, и ежедневная работа трейдеров с финансами, а особенно их потеря, только усугубляет эмоциональный фон, что может привести к стрессам и нервным срывам. Трейдер может испытывать беспокойство за открытую сделку, отчаяние при крупных потерях и другие негативные эмоции, которые отрицательно влияют на качество проведения анализа и оценки перспективности сделок. Поэтому для трейдера, в первую очередь, важно умение быстро успокаиваться и не позволять эмоциям доминировать над здравым смыслом.
Непосредственное влияние на эмоциональную нагрузку оказывает допускаемый в сделках уровень риска. Чем меньший риск вы закладываете на позицию, тем спокойнее будет идти ваша торговля.
Научитесь концентрироваться на стандартных ежедневных действиях: анализе рынка, оценке сделок, расчете уровней входа и выхода. Принимайте взвешенные решения на основе именно этих данных, а не бесплодных фантазий.
При сомнениях выходите из рынка
Если вы испытываете какие-либо сомнения по поводу уже открытых позиций или тех, которые только собираетесь выставить, то лучшим решением будет закрыть все ордера и остановить торговлю. Сомнения действуют как индикатор или подсказка, что, возможно, вы что-то упустили из виду или не до конца просчитали. Не подвергайте свои деньги риску, если по какой-то причине у вас пропала уверенность в собственных силах.
Выходите из рынка в случаях, если вы:
В заключение подведем итоги всему вышесказанному. Можно выделить 4 основных направления работы с рисками, по которым трейдер:
Как управлять рисками IT-проекта
Если какая-нибудь неприятность может произойти, она случится — гласит закон Мерфи. И сфера ИТ не исключение.
Команда SEBEKON рассказывает, как работать с рисками в IT-проекте, чтобы риски не стали управлять проектом.
В этой статье под IT-проектом подразумевается разработка сложного веб-ресурса — например, b2b-портала или интернет-магазина с множественными интеграциями с внешними системами.
Дилемма управления рисками любого IT-проекта простая: перестраховаться и заложить все угрозы в бюджет проекта, который вырастет до небес, или пропустить часть рисков — и тогда будет велика вероятность не завершить проект вовсе или получить неудовлетворительный результат.
Но даже если принять первый вариант как единственно верный, от рисков никто не застрахован.
Менеджер проектов компании SEBEKON
Генеральный директор компании SEBEKON
Как работать с рисками
Обычно ожидаемая реализация проекта не совпадает с реальной работой:
На практике управление рисками — это тонкий баланс между разумным и достаточным.
Существуют пять основных инструментов для работы с рисками:
Рассмотрим каждый из них подробнее.
Выявлять риски
Риски проекта определяются во время фиксации требований к проекту и отражаются в уставе или концепции проекта.
Устав проекта ― это документ, в котором зафиксирована основная информация о проекте: потребности заказчика, бизнес-задачи, высокоуровневые требования к проекту, критерии успешной реализации.
Концепция проекта ― документ, в котором собраны подробные характеристики проекта.
Выбор документа зависит от масштаба проекта.
Чтобы выявить риски, нужно проанализировать множество информации и сопоставить, как те или иные факторы влияют на возникновение рисков.
Рассказываем, что стоит сделать для этого.
Учесть опыт предыдущих проектов
Для примера возьмём согласование дизайна страниц сайта.
Дизайн всегда субъективная история, и нужно закладывать дополнительное время на решение вопросов в стиле «а давайте попробуем немного светлее или поиграем со шрифтами». Заказчик должен ещё до начала работ понимать, что любое изменение, требующее нескольких минут работы, в итоге выливается в часы и дни согласования.
Часто на стороне заказчика необходимо согласовать дизайн с несколькими департаментами — и не всегда сотрудники этих отделов могут быстро подтвердить изменения. Если речь идёт о крупной компании, то руководителю проекта придётся назначать собрание или созвон для обсуждения дизайна. И не всегда это получится сделать в ближайшие дни — часто согласование растягивается на недели, а то и на месяцы.
В нашей практике были разные проекты, но редко, когда удавалось согласовать дизайн в первой же итерации и по ходу работы не менять его. Гораздо чаще приходилось сдвигать сроки работ, потому что представители заказчика не смогли оперативно обсудить дизайн и согласовать его.
Оценить новизну критичных требований — как для заказчика, так и для исполнителя
Например, в проекте предполагается разработка нового функционала, которая требует совместной работы нескольких подразделений на стороне заказчика и дополнительных исследований на стороне исполнителя. Всё это увеличивает сроки согласований и влияет на срок проекта.
Принять во внимание особенности внутренней инфраструктуры заказчика
Самый очевидный пример ― требования к безопасности, которые могут существенно отодвинуть срок старта проекта. Это связано с необходимостью получения доступов в систему заказчика или требований по использованию определённого, разрешённого на стороне заказчика ПО, которые повлекут за собой дополнительную проработку архитектуры проекта.
Не забыть про покупку серверного оборудования или про согласование хостинга
Если про покупку хостинга заказчики обычно помнят, то про серверное оборудование в проектах могут забыть и не заложить в бюджет стоимость оборудования, лицензий, а также время на заключение договора с поставщиком оборудования и его доставку.
В зависимости от проекта серверное оборудование может быть стационарным — шкафы с оборудованием — или облачным, когда проект размещается в виртуальном пространстве.
Напоминание заказчику о закупке серверного оборудования на первых же обсуждениях проекта позволит избежать досадных простоев в работе.
Заложить внедрение интеграции проекта с внутренними системами заказчика
Об этом часто забывают, поскольку обычно в организации заказчика под проект выделяются не специально нанятые люди, а текущие сотрудники, у которых есть другая, основная работа. Они воспринимают новый проект как нечто второстепенное, что можно делать по остаточному принципу.
В итоге когда приходит время интеграций проекта с CRM-, ERP- и другими системами работа останавливается на неопределённый срок, потому что менеджер проекта со стороны заказчика не может оперативно подготовить необходимую документацию и доступы для интеграций.
Выявить заинтересованность в проекте ключевых стейкхолдеров
Стейкхолдеры ― это не только топ-менеджмент, но и будущие пользователи и эксперты, которые хорошо разбираются в вопросе и могут помогать с проектом или же оказывать негативное влияние.
На начальном этапе стоит понять, как взаимодействовать с так называемыми негативно настроенными стейкхолдерами, чтобы они не вредили реализации проекта. Под негативно настроенными мы понимаем не тех, кто намеренно вставляет палки в колеса, а тех, кто не понимает последствий от своих решений.
В нашей практике не раз случалось, когда некоторые стейкхолдеры не глядя согласовывали ТЗ, а на этапе тестирования готового проекта выяснялось, что всё должно быть совсем не так.
Например, руководитель департамента логистики должен был проверить сценарий по расчёту доставки товара. Но он был занят текущей деятельностью, мельком просмотрел ТЗ и отправил с пометкой «принято». В ходе тестирования этого сценария оказалось, что он должен быть реализован другим способом. В итоге пришлось откатить проект назад: пересмотреть внесение правок в сценарий, затем внести эти правки в ТЗ, согласовать это со всеми стейкхолдерами, переделать сценарий и заново его протестировать. На всё это ушло больше месяца, а кроме того, заказчику пришлось оплатить дополнительные работы.
Для наглядности можно составить матрицу влияния стейкхолдеров на проект и методы взаимодействия с ними. Например, такую:
Изучить соответствующее законодательство, поговорить с экспертами и опытными коллегами
У более опытных коллег за плечами больше реализованных проектов, они уже набили свои шишки и могут дать полезные советы. Эксперты помогут разобраться в отдельных нюансах относительно, например, сценариев пользователей или специфической функциональности.
При разработке ресурсов для государственных компаний изучение законодательства ― обязательный этап в работе над таким проектом. Например, сайты и порталы для государственных образовательных организаций должны быть сделаны с учётом требований Министерства образования.
Оценивать риски
Риски обязательно соотносятся с критичностью или некритичностью требований к проекту в целом.
Критичные требования отвечают за целевую функцию разрабатываемого продукта, включают необходимую инфраструктуру и возможности для разработки MVP.
К некритичным относятся остальные требования.
Для каждого риска выявляют следующее:
На базе этих параметров строится матрица рисков.
Остановимся подробнее на степени управляемости рисками.
Управляемые — риски, которые можно предугадать и акцентировать на них внимание уже на начальном этапе проекта, определив для них ответственных и держа под контролем.
Самый очевидный пример ― опять же дизайн сайта. Сразу понятно, что на этапе согласования могут возникнуть сложности, доработки, переделки и бесконечные правки. Поэтому мы на старте проговариваем этот момент с заказчиком, согласовываем, кто будет лицом, принимающим окончательное решение, и письменно фиксируем максимально допустимое количество дней на согласование макета — в среднем, по нашему опыту, это обычно 5.
Неуправляемые — возможные риски, появление которых мы не можем предотвратить.
Например, один из неуправляемых рисков ― более ранний выпуск конкурентами на рынок похожего продукта.
Другой пример — подключение платёжной системы. В описании API говорится, что в ответ на запрос придёт одна строка, а по факту приходит три. И платёжная система на своей стороне не готова вносить правку, потому что на это нужно время, при этом тысячи пользователей этой системы об этом не просили. Так как нужна именно одна строка, разработчику приходится самостоятельно решать этот вопрос, тратить больше запланированного времени на разработку и фиксацию данной ошибки.
Запланировать мероприятия по предотвращению рисков
Для предотвращения рисков нужно понимать, как от них защищаться.
Грамотно выстроенные коммуникации внутри проекта играют главную роль для защиты от рисков и оказывают огромное влияние на успех проекта. Это означает, что все процессы взаимодействия регламентированы, роли всех членов команды закреплены и всё это зафиксировано в понятном для участников формате.
Важно сразу выстроить коммуникацию с заказчиками проекта, создать большую команду из представителей обеих сторон и все вопросы решать совместно.Для этого фиксируем ответственных для каждого этапа проекта в матрице «Роли и зоны ответственности» (RACI Matrix).
В матрице предусмотрены четыре роли:
Однако просто зафиксировать ответственных мало — нужно проанализировать заполненную матрицу, чтобы не было перекоса в одну роль:
После того, как разобрались с матрицей ролей, проактивно управляем рисками — фиксируем их и то, что нужно сделать для предотвращения.
Вместе с этим определяем план и способ коммуникаций на протяжении всего проекта: сколько раз в неделю и месяц, каким составом и при наступлении каких событий будем проводить созвоны или очные встречи, какой формат отчётности примем для фиксации договоренностей на этих встречах.
Также определяем инфраструктуру проекта:
Профессия
Project
manager
Предусмотреть действия при наступлении рисков
Стоит предусмотреть резервный план (contingency plan) на случай непредвиденных обстоятельств.
Задача этапа — выполнить его наиболее эффективным образом, а также собрать и проанализировать информацию о наступившем риске на будущее.
Не стоит тратить время на поиск виноватых — лучше предпринять всё необходимое, чтобы двигаться дальше и продолжать реализацию проекта. На этом этапе главная роль принадлежит коммуникации и поиску оптимального решения.
В нашей практике был проект, когда нужно было разделить один сайт, реализованный на Bitrix, на два. Один из них надо было интегрировать со штатной версией 1С.
Заказчик предполагал, что на разработку на своей стороне их специалисту понадобится три недели. По факту оказалось, что ранее созданная интеграция полностью кастомная — комплекты, цвета, размеры, остатки — и на стороне заказчика нет эксперта, который смог бы выполнить задачу. Пришлось подключиться нам и помочь с решением по интеграции. Дополнительно были пересмотрены сроки проекта.
Мониторить риски
Ситуация на проекте постоянно меняется ― это нужно принять как аксиому.
Например, если работать по Agile, то перед каждым новым спринтом могут меняться параметры проекта, обрисованные на этапе обсуждения. Следовательно нужно отслеживать изменения параметров рисков, корректируя внутрикомандный перечень топ-10 рисков.
На этапе мониторинга — если возвратиться к примеру с Agile, то это нужно делать в начале каждого спринта — важно отслеживать новые риски, изменять статус выявленных рисков, корректировать планы. На протяжении проекта перечень может значительно измениться.
К примеру, на крупном проекте на финальном этапе в команде заказчика появляется эксперт, который задаёт много вопросов и предъявляет новые требования к проекту, которые подразумевают изменение архитектуры проекта и кода. Если инициировать эти изменения, то есть риск сорвать плановые сроки реализации проекта.
Как вариант — провести встречу, обсудить, что беспокоит эксперта в текущей архитектуре, объяснить, почему реализовано именно так и наметить дальнейшие шаги. При этом важно постараться не увеличить объём работ проекта и не выйти за временные и финансовые рамки.
Каждый участник команды должен понимать важность работы с рисками
Ключевой момент управления рисками — их постоянное отслеживание и предотвращение, в идеале согласованное с длительностью циклов разработки проекта.
Оценка рисков и работа с ними зависят от размера и длительности проекта. Рекомендуем возвращаться к работе над рисками один раз в 1‒2 недели, в некоторых крупных проектах периодичность может быть увеличена до месяца.
Лучше составить неполный перечень рисков, чем не составить его вовсе.
В процессе общения с разработчиками или заказчиком лучше забыть фразу «все и так всё понимают»:
Главное в работе с рисками ― донести до всех участников проектной команды необходимость работы с рисками. Прежде всего нужно стараться не допускать наступления рисков, анализировать прошлый опыт и причины наступления для составления перечня возможных рисков в новых проектах, предотвращать непредусмотренные риски.
Пример перечня рисков проекта с комментариями и статусами можно посмотреть здесь.
Этапы оценки проекта: понятия, методы и полезные инструменты
Кто такой проджект менеджер, чем он занимается и как им стать
Как компаниям общаться с клиентами: ключевые тенденции и полезные советы
Мнение автора и редакции может не совпадать. Хотите написать колонку для Нетологии? Читайте наши условия публикации. Чтобы быть в курсе всех новостей и читать новые статьи, присоединяйтесь к Телеграм-каналу Нетологии.