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

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

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

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

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

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

Важно продумать насколько трудоемким будет процесс замещения таких компонентов.

Могут возникнуть проблемы с безопасностью ПО.

Чтобы минимизировать этот риск необходимо:

• Использовать шифрованные соединения, по возможности (SSL).
• Организовать penetration test силами сторонних профессионалов.
• Использовать openid или использовать двухфакторную аутентификацию (если безопасность действительно важна).
• Купить сервис защищающий от DOS атак.

Необходимо протестировать все варианты использования приложения или сервиса.

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

Необходимо проводить регулярные встречи, обсуждать текущие проблемы и прогресс – ежедневные стендапы и ретроспективы.

Назначьте ответственного за проведение этих мероприятий и добавьте задачи:

• Проведение ретроспективы раз в две недели.
• Проведение ежедневных стендапов.

Плохое качество ПО может оттолкнуть первых пользователей.

Необходимо провести ряд мероприятий, обеспечивающих лучшее качество ПО:

• Лучше еще до начала разработки – поговорить с командой о необходимости тестового покрытия.
• Ревью кода разрабатываемого продукта – в ходе ревью также необходимо проверить наличие тестового покрытия.
• Написать тест-кейсы – содержащие описывающие все варианты использования системы.
• Организовать интеграционное тестирование.

Могут возникнуть проблемы с пропускной способностью системы и устойчивостью.

Необходимо проверить, что система будет работать стабильно при количестве клиентов, описанном в бизнес-модели X2.
Если необходимо – использовать облачный хостинг – чтобы обеспечить эластичный рост производительности – при увеличении нагрузки на систему.

Для контроля этого риска необходимо:

• Изучить паттерны использования системы основными группами пользователей.
• Установить мониторинг с профайлингом, например, New Relic
• Провести нагрузочное тестирование
• Продумать стратегию масштабирования при усилении нагрузки на систему

Могут неожиданно возникнуть проблемы с надежностью облачных решений или ЦОД. Поэтому необходима возможность быстро переключиться на другой ЦОД или альтернативное облако (лучше от другого вендора).

Рекомендуемые задачи:

• Спланировать стратегию восстановления доступности системы
• Аренда альтернативного облака
• Протестировать восстановления доступности системы