Хабрахабр

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

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

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

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

image

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Резюме:

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

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

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть