[Из песочницы] Что должен знать не технический основатель о разработке ПО

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

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

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

Старт: поиск своего места на рынке
(search for market fit)

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

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

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

Приоритет: Скорость разработки.

Рекомендации:

• Ищите самый простой и быстрый способ протестировать свои идеи.
• Изучите рынок, возможно уже есть готовые системы или сервисы, которые вы можете использовать.
• Будьте настороже каждый раз, когда слышите разговоры о качестве решения, производительности, масштабируемости и т.д. Сделайте заметки на будущее и забудьте на текущий момент.
• Не поддавайтесь соблазну инвестировать в хорошее качество слишком рано. Ведь каждый раз вы будете убеждены, что текущий вариант решения проблемы обязательно выстрелит.
• После появления клиентов и перехода на следующий этап, будьте готовы к разговорам новичков о том, на сколько здорово было бы использовать тот или иной архитектурный подход с самого начала. Лучше так, чем потратить все деньги и создать идеальный продукт, который никому не нужен.

Развитие: захват ниши

Стартап нашел свой рынок и количество клиентов постоянно растет.

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

Пользователи сервиса должны видеть, что решение стабильно и постоянно развивается. Следовательно, качественное развитие платформы выходит на первый план.

Приоритет: качество процесса разработки.

Рекомендации:

• Начинайте инвестировать в качество платформы больше.
• Обеспечьте следующие элементы процесса разработки:
  
  • Частые и регулярные обновления системы.
  • Автоматизированное развертывание изменений.
  • Все изменения проходят этап код ревью.
  • Качественное тестирование нового и старого функционала.
• Подготовьтесь к масштабным архитектурным изменениям на следующем этапе.

Масштабирование: экспансия на глобальный рынок

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

На данном этапе существующие требования меняются редко. Новые функции все еще появляются, но нефункциональные требования, такие как пропускная способность, скорость отклика и доступность системы, становятся наиболее важными.

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

Приоритет: качество архитектуры.

Рекомендации:

• Пришло время максимальных инвестиций в качество платформы.
• При необходимости перепишите часть модулей для улучшения архитектуры.
• Обеспечьте следующие элементы процесса разработки:
  
  • Качественное нагрузочное тестирование.
  • Вертикальные команды — команды могут независимо друг от друга выпускать новый функционал.
  • Горизонтальное масштабирование — каждый модуль платформы может масштабироваться за счёт добавления его новых экземпляров.
  • Пробное развертывание (Canary deployment) — новые функции могут быть протестированы на малой части реальных пользователей.

Резюме:

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

• Срезайте углы, чтобы максимально быстро опробовать гипотезы на этапе поиска своего места на рынке.
• Постройте качественный процесс разработки и обеспечьте стабильный поток улучшений в ходе интенсивного развития.
• Модернизируйте архитектуру системы для масштабирования успешной бизнес модели на новые рынки.

P.S.: Эволюция стартапа не всегда так проста и линейна. Переход с одного этапа на другой требует времени и усилий. Успешный продукт (MVP) на старте может не сработать для более широкой аудитории на этапе развития. А эффективное решение для одной ниши, может плохо масштабироваться на новые рынки. Эти случаи возвращают старап к истокам, и приоритет разработки должен меняться соответственно.

Let's block ads! (Why?)