Операционные проблемы могут отрицательно сказаться на результатах проекта. Управление проектом должно планировать эффективное выполнение проекта и находить баланс между потребностями команды разработчиков и ожиданиями клиентов.
Компромисс в дизайне
Часто команды пропускают важные этапы проектирования и бросаются выполнять «настоящие» задачи разработки. Однако, без надлежащего планирования, прототипирования и построения информационной архитектуры весь процесс — пустая трата времени разработчиков.
Решение: при оценке проекта предусмотрите достаточное количество часов проектирования для проведения семинаров по продукту, стратегии UX, дизайна пользовательского интерфейса и тестирования удобства использования.
Отсутствие разработчиков
В некоторых случаях разработчикам приходится работать над несколькими проектами параллельно, если не хватает ресурсов. Если период поддержки предыдущего проекта также продолжается, разработчики могут быть отвлечены действиями по исправлению ошибок.
Решение: если оба проекта по совместительству долгосрочные, имеет смысл выделить дублирующего специалиста. Однако, это повысит стоимость проекта и снизит производительность обоих специалистов, поскольку они могут сбиваться при переключении между контекстами.
Нестабильная рабочая нагрузка
Если у нас рабочая нагрузка составляет менее четырех часов в день на человека, трудно переключаться между контекстом двух проектов. Этот риск возрастает, когда критические проблемы возникают в двух проектах одновременно.
Решение: такие случаи требуют дополнительного согласования. Имеет смысл приостановить проект и накопить разумное количество задач, если рабочая нагрузка составляет менее 8 часов.
Без тестирования
Некоторые клиенты надеются, что разработчики смогут самостоятельно протестировать проект и сэкономить на QA.
Решение: нанять специалиста по контролю качества. Они лучше умеют обнаруживать скрытые ошибки и посвящают свое время только тестированию.
Нет поддержки после запуска
После того, как проект запущен, команда поставщика часто не оказывает никакой поддержки или сосредотачивается на критических проблемах, в то время как более мелкие проблемы могут не входить в сферу компетенции.
Решение: в начале проекта укажите, как долго будет осуществляться поддержка после ввода в эксплуатацию. Включите часы для передачи знаний и передачи деятельности.
1 часть. Как управлять рисками при разработке ПО