Риск-менеджмент IT проекта: 7 самых распространенных рисков в разработке ПО

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

А вы задумывались о том, что может случиться в ходе выполнения проекта? Каждый из вас может составить перечень рисков, в котором вы участвуете. Почему? Потому, что…

Не существует проекта без риска

Давайте начнем с определения риска. Термин относится к:

· событию, которое еще не произошло,

· возможности события,

· событию, которое можно предотвратить,

· событию негативного или позитивного характера,

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

Говоря об управлении рисками IT проекта, важно обозначить возможные источники этих рисков. Когда мы можем распределить возможные риски по категориям, то их поиск и управление становится намного проще. Тем не менее, категории должны отражать природу взятого проекта. В риск-менеджменте в контексте IT, можно выделить три больших вида рисков.

· внешний риск 🎩 – результат влияния клиента,

· внутренний риск 🔧 – результат самого процесса разработки ПО,

· персональный риск 👥 – результат усилий, качества и вовлеченности отдельных участников команды в проект.

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

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

🔴 Последствия

· перегруженные (или недогруженные) спринты,

· брошенные незавершенные задачи,

· полная или частичная переделка приложения,

· изменения в расписании,

· незавершенные или растянутые спринты,

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

✅ Решение

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

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

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

Слово “команда” относится к каждому участнику проекта – клиенту, проджект-менеджерам, разработчикам, тестировщикам, дизайнерам, аналитикам.

🔴 Последствия

· задержки сроков выполнения,

· негативное влияние на мотивацию других членов команды.

✅ Решение

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

Коммуникация необходима для эффективной работы во время проекта по разработке ПО. Какие последствия влечет за собой слабая коммуникация?

🔴 Последствия

· пробелы в знаниях,

· задвоенные задачи,

· сниженная продуктивность.

✅ Решение

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

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

Что такое проектная документация? Продукт с минимальным функционалом (MVP), описания задач в JIRA и выделенное место для проекта в Confluence – всё это очень важно для успеха проекта.

🔴 Последствия

· хаос,

· команда, зря тратящая время на повторяющиеся вопросы касаемо базовой информации о проекте,

· отсутствие хороших контрольных показателей для использования членами команды как во время проекта, так и после него,

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

✅ Решение

Даже минимальная проектная документация может сыграть большую роль в предотвращении последствий.

Согласно лучшим практикам Agile: “работающее ПО важнее детальной документации”. Тем не менее, не надо считать документацию малозначительным элементом. Как же лучше решить эту проблему?

Отведите некоторое время на написание документации с самого начала. В таком случае, у вас не будет никаких отговорок. Используйте такие инструменты, как JIRA, Confluence или QA Touch – они действительно облегчают работу. Также существует много более специализированных инструментов, которые помогут вам написать документацию для ИПП и других отчетных материалов по проекту. Определите какая информация должна всегда быть доступной. Хорошее место для ее хранения – Confluence. Это система, позволяющая найти всю базовую проектную документацию, членов команды, их роли и другую важную информацию по свойствам проекта, его среды, описания пользователей и перечня функций.

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

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

🔴 Последствия

· дезорганизация,

· задержки сроков выполнения задач,

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

· демотивация команды.

✅ Решение

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

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

🔴 Последствия

· задержки проекта по срокам из-за молчания клиента,

· демотивация других членов команды.

✅ Решение

Покажите клиенту как важно для вас поддерживать хорошие отношения с ним с самой первой встречи. Обозначьте какие решения всегда должны быть приняты совместно и какие – разработчиками/проджект-менеджерами самостоятельно. Когда вы отправляете email с запросом к клиенту, обозначьте почему задержка с ответом может повлечь за собой проблемы (например, трудности с оказанием услуги в срок). Если ни один из способов достучаться до клиента не работает, проджект-менеджер должен принять меры для улучшения коммуникации с заказчиком.

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

🔴 Последствия

· задержки реализации проекта,

· незавершенная задача, мешающая выполнению остальных задач,

· неудовлетворенность клиента,

· плохая рабочая атмосфера.

✅ Решение

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

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

Давайте поговорим о том, почему не надо быть как этот парень 🙂

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

Когда нужно начать идентификацию рисков? С самого начала, конечно же! Начните со списка возможных рисков, которые должны быть учтены на протяжении всего проекта. Этот список должен обновляться по ходу действия.

Существует много инструментов и техник, улучшающих процесс идентификации рисков:

📖 анализ документации,

✅ детальный анализ целей проекта,

📝 контрольные списки, опирающиеся на опыт предыдущих проектов,

🌐 мозговой штурм – обычный разговор между всеми членами команды может сотворить чудеса.

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

Что вы думаете о процессе управления рисками, представленном в этой статье? Как я говорила ранее, не существует проекта по разработке ПО без рисков. Важно понять, что риск – это нормальное явление в сфере IT. Поэтому нет смысла их бояться. Если вы…

· проводите регулярные собрания,

· незамедлительно решаете проблемы,

· ищите, делитесь, документируете и понимаете информацию и данные,

· мотивируете всех членов команды внутри вашей организации,

… вы добьетесь успеха с большой долей вероятности.

А что вы думаете на этот счет? Присоединяйтесь к нашим размышлениям в комментариях!

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