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

Дмитрий Семенов

Каждый день мы сталкиваемся с различными рисками… Вы когда-нибудь задумывались о том, что может произойти, пересекая улицу на красный свет? К примеру, вы можете стать участником ДТП – это результат риска, на который вы пошли в данном случае. Давайте поговорим сегодня на тему оценки рисков в IT и управления этими рисками.

Недавно мы наткнулись на интересную статью, которая понятным языком описывает 7 самых распространенных рисков в разработке ПО и рассказывает, как ими можно управлять. Для вашего удобства приводим ниже ее перевод.

Спойлер! В конце статьи будут советы и случаи из практики нас и наших друзей-партнеров ;-) Приятного чтения.

Анна Калемба
QA инженер

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

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

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

Что такое риск – определение

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

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

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

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

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

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

Риск-менеджмент в IT – источники риска

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

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

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

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

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

7 распространенных рисков при управлении проектом в разработке ПО

🎩1. Изменение требований и приоритетов

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

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

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

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

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

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

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

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

✅ Решение

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

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

👥 2. Недостаточная вовлеченность

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

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

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

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

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

✅ Решение

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

👥 3. Нехватка коммуникации

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

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

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

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

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

✅ Решение

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

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

🔧🎩 4. Плохая документация

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

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

· хаос,

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

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

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

✅ Решение

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

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

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

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

👥5. Незапланированное отсутствие члена команды

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

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

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

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

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

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

✅ Решение

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

🎩6. Слабая коммуникация с заказчиком

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

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

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

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

✅ Решение

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

👥7. Невыполнение проекта в срок

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

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

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

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

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

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

✅ Решение

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

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

Идентификация рисков в разработке ПО

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

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

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

Какие методы лучшие в идентификации рисков?

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

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

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

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

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

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

Риск-менеджмент IT проекта – краткие выводы

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

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

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

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

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

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

А на сладкое - комментарии специалистов из сферы Digital, ежедневно сталкивающихся с вопросом оценки и предотвращения IT рисков

Управление рисками и предотвращение их - это мечта многих айтишных компаний. Сорванные дедлайны, наложение проектов, внезапный уход менеджера со стороны клиента - всех и не перечислить. Чем больше анализируешь проект до старта и прописываешь график работ с учётом всех возможных факапов, тем менеджеру проектов спокойнее на душе:-) Но порой проблема «может вылезти» откуда ее совсем не ждёшь. Тогда нужно включать уже умение работать с этими появившимися рисками, что не менее важный скилл любого проджекта.

У нас небольшая компания, и самые откровенные риски, которые у нас случаются, это срыв сроков. Заболел программист: просрочка, клиент проверил сайт и написал неожиданные правки - наслоение проектов. Как мы с этим боремся? Стараемся выдыхать и формализировать: работу команды, отчеты клиентам каждую неделю, подумываем даже написать свою программку для учета проектов внутри компании. Часто спасает опыт похожих проектов: как по оценке, так и по реализации.

Когда клиент обращается с похожей задачей — это нас спасает. Мы делаем сайты - от самых простых на тильде до интернет-магазинов с синхронизацией 1С, чем проще проект, тем легче его спрогнозировать и, наоборот, чем сложнее: тем больше часов мы можем заложить на определённые моменты в работе. Ну и, конечно, психология. Многие клиенты похожи, и примерно понятно уже после первой встречи, как презентовать работу тому или иному человеку, и на чем стоит сделать акцент, чтобы избежать лишних замечаний и недопониманий.

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

Анна Захарченко

asmart-group.ru/

, директор IT-company ASMART

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

Примеры таких рисков:

1. Недостаточная вовлечённость клиента в детали в процессе выполнения проекта. «Работа идёт, всё в целом нормально, результаты видны, я доверяю команде!». Но никто не понимает требования к разрабатываемой системе лучше конечных пользователей, да и нельзя всё предусмотреть на этапе планирования, поэтому в результате мы приходим к потоку изменений на поздних этапах, когда заказчик переходит от рассмотрения системы в целом к отдельным деталям. И хорошо, если это незначительные правки, а ведь какие-то изменения могут потребовать достаточно много переделок.

2. Излишнее внимание клиента к мелочам в ущерб основной цели. Какая у нас основная цель? Чаще всего – запустить продукт и начать его использовать. Это одинаково важно как для внутренних корпоративных продуктов, так и для продуктов широкого рынка. Но иногда клиент начинает заниматься полировкой деталей ещё до запуска продукта, даже не зная, будет ли востребован пользователями тот, или иной функционал.

3. Непонимание клиентом важности систем аналитики (это важно, в основном, для продуктов открытого рынка) и, как следствие, невозможность принимать обоснованные решения о приоритетах в развитии проекта

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

Михаил Герасимов

www.tulasoft.com

, директор компании ТулаСофт

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

Но, универсального рецепта нет и если пытаться предотвратить все риски - можно запараноить и закрыться дома в кладовке, не желая выходить на улицу

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

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

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

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

Был у нас случай, когда человек, начинал себя подозрительно вести и впоследствии был обязан передать свои знания по проекту другим людям, и не зря. Во время обучения дополнительно была обновлена документация, которая не обновлялась с начала проекта. В итоге оказалось, что тот самый человек решил уволиться, а на нём был завязан большой объём мало-документированных знаний.

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

Сергей Москвин

web.evapps.ru

, Senior QA Engineer, компания EvApps, группа компаний Smartech

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

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

0
22 комментария
Написать комментарий...
Ксения Иванова

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

Ответить
Развернуть ветку
Михаил Смирнов

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

Ответить
Развернуть ветку
Руслан Ишмухамедов

Да такие риски я не закладывал никогда 🙈😂👍

Ответить
Развернуть ветку
Александр Балакирев

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

Ответить
Развернуть ветку
Руслан Ишмухамедов

Согласен 👍

Ответить
Развернуть ветку
Alfred Stolyarov

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

Очень такое низкоуровневое описание. Управление тестированием на основе рисков в книге по подготовке на тест менеджера занимает почти половину книги. Это очень обширная тема. И там много вкусняшек описано. Например, как это все привязать к деньгам, что более понятно для клиента.

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

Ответить
Развернуть ветку
Андрей Типикин

Полностью согл

Ответить
Развернуть ветку
Александр Афанасьев

Риски присутствуют всегда 

Ответить
Развернуть ветку
Anastasiya Dyakova

Мне кажется в нынешнее время все мы немножко риск-менеджеры💪

Ответить
Развернуть ветку
Дмитрий Родионов

Легко читать. Круто то, что можно использовать статью  как шаблон. Риски есть всегда и во всём. Умение управлять и контролировать их- это то к чему надо стремиться.

Ответить
Развернуть ветку
Руслан Ишмухамедов

Риски на стыке коммуникации с заказчиком (не важно – внутренним или внешним, но у любой разработки есть конечный заказчик) - согласен, на этом участке многие риски переросли в сложности

Ответить
Развернуть ветку
Светлана Пинтарич

Хорошая статья, написанная понятным для восприятия языком. Спасибо за полезную информацию 🙏

Ответить
Развернуть ветку
Юлия Уренёва

Спасибо, было интересно.

Ответить
Развернуть ветку
Владимир Кузьмичев

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

Ответить
Развернуть ветку
Joseph Fekadu

Эх, хорошо написано! 

Ответить
Развернуть ветку
Сергей Рябочкин

Как у классика: "Опыт - сын ошибок трудных" ;-)

Ответить
Развернуть ветку
Женя Мильченко

Недостаточная вовлечённость клиента в детали в процессе выполнения проекта - как по мне, самая существенная проблема.

Ответить
Развернуть ветку
MitApp MitApp

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

Ответить
Развернуть ветку
Артем Рост

Крайне полезная статья! Большое спасибо!

Ответить
Развернуть ветку
Александра Радина

В статье больше перечислены внутренние риски. Хотелось бы задать вопрос экспертам: а какие внешние риски указали бы вы?

Ответить
Развернуть ветку
Татьяна Овсянникова

Спасибо за интересную статью! Легкая для понимания и восприятия!

Ответить
Развернуть ветку
Dmitry Entin

Оригинальная статья, судя по всему, из разряда "Risk Management for Dummies" с характерной желтой обложкой.
Примитивно и сбивчиво, и местами не совсем про риски.
А вот цитаты и комментарии - другое дело :)
Для первого ознакомления с темой рисков - вполне годно.

Ответить
Развернуть ветку
19 комментариев
Раскрывать всегда