Мы открываем список типов рисков разработки программного обеспечения с ошибками в оценке. Часто это отражается на доходах компании и приводит к провалу проекта.
Неправильно установленные заказчиком сроки
Часто бизнес-аналитик со стороны клиента уже определил сроки, которые намного жестче, чем рассчитывала техническая команда со стороны вендора. В результате команде поставщика приходится работать сверхурочно или добавлять новых людей, которых не было в первоначальном соглашении.
Решение: перед началом проекта команда разработчиков должна проинформировать клиента о высокой вероятности наступления рискового события. Если сроки не могут быть отодвинуты назад, имеет смысл сосредоточиться на наиболее важных функциях, а не распылять усилия на каждую задачу.
Например, если крайний срок связан с каким-то публичным мероприятием, на котором клиент должен показать демонстрацию минимально жизнеспособного продукта , вы можете сосредоточиться на пользовательском интерфейсе продукта и жестко запрограммированных данных.
Общая спецификация
Если спецификация проекта слишком краткая или объем проекта неясен, велика вероятность того, что несколько функций выпадут из него. В результате в процессе разработки будет добавлено больше требований к проекту; сроки будут сорваны, и будут накапливаться сверхурочные часы — все это разрушит командный дух.
Решение: не подписывайте контракт, пока не будете уверены, что все в его объеме указано. Начать лучше с бизнес-анализа и преобразовать бизнес-требования клиента в функциональную спецификацию, в которой все функции подробно описаны и расставлены по степени важности.
Клиент недоступен для команды разработчиков
По мере продвижения проекта клиент должен убедиться, что его ожидания материализуются, а команда разработчиков правильно выполняет требования. Если связь между двумя сторонами недостаточна, могут возникнуть задержки в информировании о препятствиях и предоставлении результата.
Решение: если клиент не может быть доступен для непрерывной синхронизации, стоит подумать о делегировании обязанностей владельца продукта другим компетентным заинтересованным сторонам либо с сайта клиента, либо с сайта поставщика.
Более подробно о том, как удаленно осуществить контроль выполнение проекта.
Клиент требует слишком много общения
Есть обратная сторона активного общения: когда его слишком много. Это может привести к ненужным обсуждениям, подробным разъяснениям технических вопросов нетехническим людям и застреванию в тупике.
Решение: если клиент настаивает на частых встречах, вам нужно добавить к смете несколько дополнительных часов. Также имеет смысл фильтровать техническую информацию, касающуюся очень мелких решений, которые не влияют на график и производительность проекта.
Неправильная оценка времени, частое расширение масштабов проекта и неправильное распределение ресурсов — типичные риски, связанные с графиком, связанные с разработкой программного обеспечения.
Работа в оффшорных командах
Это малоэффективный бизнес-риск. Если в обеих командах есть сильные технические лидеры, у них могут быть разные взгляды на реализацию продукта.
Решение: командам нужно больше времени на синхронизацию и общение, чтобы они могли обсудить любые возникающие препятствия и выработать последовательную стратегию.
Работа в разных часовых поясах
Вот где риск существенно возрастает. Команды должны сотрудничать в течение ограниченного времени, когда их рабочие часы пересекаются. Например, 9:00 в Нью-Йорке равняются 17:00 в Беларуси, поэтому время команд пересекается от двух до четырех часов. Это часто вызывает сверхурочную работу.
Решение: к оценке времени для синхронизации следует добавить время. Если есть возможность отправить на пару недель к клиенту выделенную оффшорную для погружения в проект, это снизит риски личных конфликтов и недопонимания, которые часто возникают на ранних стадиях проекта.
1 часть. Как управлять рисками при разработке ПО