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

Бизнес-модель может в итоге и не сойтись.

Проверить потенциальные причины:

• Слишком узкая клиентская ниша.
• Высокая стоимость привлечения новых клиентов.
• Высокие расходы и маленькая маржа.
• Не учтена высокая конкуренция на рынке.

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

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

Не нужно прокрастинировать или не признавать этой проблемы.

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

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

Необходимо определиться с Уникальным Торговым Предложением.

Например, можно выбрать в категориях:

• Цена.
• Качество.
• Сервис.

Возможно, у вас еще в принципе нет или есть, но неправильное, понимание целевой аудитории продукта или услуги.

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

Может возникнуть очень чувствительный риск того, что вовлеченность пользователей будет недостаточной.

Необходимо установить каналы коммуникации с клиентами, которые позволят понять:

• Ожидания пользователя (чего он хочет добиться используя продукт).
• Насколько пользователь в состоянии сам освоить продукт, и как улучшить этот процесс

Кроме того, обязательно стоит добавить возможность прямого общения – это добавит в глазах пользователя ценности вашему продукту или услуге.

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

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

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

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

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

Всегда есть риск того, что в итоге будет слишком низкая вирусность распространения продукта.

На это укажет малое количество рекомендаций и отзывов.

Необходимо построить систему мотивирующую пользователя (необязательно материально).

Система мотивации может быть органично вписана в ваш продукт. Например, multiplayer в играх.

Риск того, что будет слишком малое количество платных пользователей.

Варианты действий:

• Заранее проанализировать альтернативные варианты того, за что пользователи платят деньги.
• Непрерывный анализ ценообразования. Возможно, необходимо опустить или поднять цену.
• Заранее проанализировать другой клиентский сегмент, например от b2c к b2b.
• Заранее обдумать направления pivot.

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

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

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

Проверьте лицензии вашего ПО, библиотек или контента – убедитесь, что никому ничего не должны.

Если есть что-то требующее выплаты роялти – организуйте выплаты.

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

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

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

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

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

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

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

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

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

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

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

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

Может возникнуть проблема полноты требований для реализации ПО.

Необходимо регулярно проводить демо продукта (например, раз в две недели) и сессии планирования.

Назначьте ответственных с помощью задач.

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

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

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

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

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

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

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

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

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

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

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

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

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

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