[Из песочницы] Что должен знать не технический основатель о разработке ПО
Даже самую простую техническую задачу можно реализовать множеством способов. Каждый доступный подход имеет плюсы и минусы, и свою стоимость — можно сделать автоматизацию за копейки, а можно потратить целое состояние.
Обычно инженеры и компании по разработке ПО стремятся реализовать задачу с максимально высоким качеством, на которое они способны. В зависимости от их опыта и текущей стадии стартапа, полученное «высокое» качество может быть не достаточным, идеально соответствующим моменту, или же пустой тратой средств и времени.
Поэтому, чтобы действовать максимально быстро и эффективно, очень важно менять подход к разработке в зависимости от этапа эволюции стартапа.
Старт: поиск своего места на рынке
(search for market fit)
Это самое начало, когда новая организация ищет свой рынок. Основная цель на этом этапе — как можно быстрее опробовать новые бизнес-модели, не уделяя много внимания качеству реализации системы.
В течение этого периода требования к платформе могут кардинально меняться несколько раз. Большая часть кода с высокой вероятностью будет впоследствии выброшена. Влияние ошибок невелико, так как у платформы пока еще практически нет пользователей, как правило это семья и друзья.
На этом этапе бесполезно инвестировать много ресурса в качественную реализацию системы. Платить за хорошее качество даже опасно, так как это замедляет скорость исследования рынка и стремительно расходует деньги.
Приоритет: Скорость разработки.
Рекомендации:
- Ищите самый простой и быстрый способ протестировать свои идеи.
- Изучите рынок, возможно уже есть готовые системы или сервисы, которые вы можете использовать.
- Будьте настороже каждый раз, когда слышите разговоры о качестве решения, производительности, масштабируемости и т.д. Сделайте заметки на будущее и забудьте на текущий момент.
- Не поддавайтесь соблазну инвестировать в хорошее качество слишком рано. Ведь каждый раз вы будете убеждены, что текущий вариант решения проблемы обязательно выстрелит.
- После появления клиентов и перехода на следующий этап, будьте готовы к разговорам новичков о том, на сколько здорово было бы использовать тот или иной архитектурный подход с самого начала. Лучше так, чем потратить все деньги и создать идеальный продукт, который никому не нужен.
Развитие: захват ниши
Стартап нашел свой рынок и количество клиентов постоянно растет.
На этом этапе становится меньше кардинальных изменений в системе. Обычно добавляется новый функционал. Однако с ростом количества клиентов влияние ошибок возрастает.
Пользователи сервиса должны видеть, что решение стабильно и постоянно развивается. Следовательно, качественное развитие платформы выходит на первый план.
Приоритет: качество процесса разработки.
Рекомендации:
- Начинайте инвестировать в качество платформы больше.
- Обеспечьте следующие элементы процесса разработки:
- Частые и регулярные обновления системы.
- Автоматизированное развертывание изменений.
- Все изменения проходят этап код ревью.
- Качественное тестирование нового и старого функционала.
- Подготовьтесь к масштабным архитектурным изменениям на следующем этапе.
Масштабирование: экспансия на глобальный рынок
Стартап построил успешную бизнес-модель. Пришло время его масштабировать на новые рынки.
На данном этапе существующие требования меняются редко. Новые функции все еще появляются, но нефункциональные требования, такие как пропускная способность, скорость отклика и доступность системы, становятся наиболее важными.
Влияние ошибок огромное, и надежность платформы имеет решающее значение.
Приоритет: качество архитектуры.
Рекомендации:
- Пришло время максимальных инвестиций в качество платформы.
- При необходимости перепишите часть модулей для улучшения архитектуры.
- Обеспечьте следующие элементы процесса разработки:
- Качественное нагрузочное тестирование.
- Вертикальные команды — команды могут независимо друг от друга выпускать новый функционал.
- Горизонтальное масштабирование — каждый модуль платформы может масштабироваться за счёт добавления его новых экземпляров.
- Пробное развертывание (Canary deployment) — новые функции могут быть протестированы на малой части реальных пользователей.
Резюме:
Четко знайте свою стадию — каждый человек в команде должен понимать текущий фокус разработки. Выработайте привычку перед каждым принятием решений по реализации составлять список вариантов, отличающихся по времени, стоимости и качеству. Выбирайте наиболее эффективный для вашей текущей стадии:
- Срезайте углы, чтобы максимально быстро опробовать гипотезы на этапе поиска своего места на рынке.
- Постройте качественный процесс разработки и обеспечьте стабильный поток улучшений в ходе интенсивного развития.
- Модернизируйте архитектуру системы для масштабирования успешной бизнес модели на новые рынки.
P.S.: Эволюция стартапа не всегда так проста и линейна. Переход с одного этапа на другой требует времени и усилий. Успешный продукт (MVP) на старте может не сработать для более широкой аудитории на этапе развития. А эффективное решение для одной ниши, может плохо масштабироваться на новые рынки. Эти случаи возвращают старап к истокам, и приоритет разработки должен меняться соответственно.
