Web-automation.ru

Мы открываем список типов рисков разработки программного обеспечения с ошибками в оценке. Часто это отражается на доходах компании и приводит к провалу проекта.

Неправильно установленные заказчиком сроки

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

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

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

Общая спецификация

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

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

Клиент недоступен для команды разработчиков

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

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

Более подробно о том, как удаленно осуществить контроль выполнение проекта.

Клиент требует слишком много общения

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

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

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

Работа в оффшорных командах

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

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

Работа в разных часовых поясах

Вот где риск существенно возрастает. Команды должны сотрудничать в течение ограниченного времени, когда их рабочие часы пересекаются. Например, 9:00 в Нью-Йорке равняются 17:00 в Беларуси, поэтому время команд пересекается от двух до четырех часов. Это часто вызывает сверхурочную работу.

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

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

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

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