Операционные риски в разработке ПО

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

Компромисс в дизайне

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

Решение: при оценке проекта предусмотрите достаточное количество часов проектирования для проведения семинаров по продукту, стратегии UX, дизайна пользовательского интерфейса и тестирования удобства использования.

Отсутствие разработчиков

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

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

Нестабильная рабочая нагрузка

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

Решение: такие случаи требуют дополнительного согласования. Имеет смысл приостановить проект и накопить разумное количество задач, если рабочая нагрузка составляет менее 8 часов.

Без тестирования

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

Решение: нанять специалиста по контролю качества. Они лучше умеют обнаруживать скрытые ошибки и посвящают свое время только тестированию.

Нет поддержки после запуска

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

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

1 часть. Как управлять рисками при разработке ПО

2 часть. Организационные риски в разработке ПО

4 часть. Технические риски в разработке ПО

editor