Что должен знать не технический основатель о разработке ПО

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

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

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

image

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

Резюме:


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

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

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

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 10

    +1
    Спасибо за текст!
    Люто лайкую!
    Вроде бы ничего нового не прочитал, но не мог спокойно читать, вскакивал и бегал по комнате от возбуждения.
    Для меня эта тема очень актуальна, так как нужно продвигать много стартапов.
      0
      Что должен знать не технический основатель о разработке ПО — что доходы от продаж должны быть всегда выше стоимости разработки.
        +1
        это невозможно хотя бы потому, что расходы появляются с первого дня существования, а доходы — только когда уже есть что продавать.
        0
        Было гладко на бумаге… Очень интересно, как вы в условиях ограниченных ресурсов, набрав клиентскую базу (читай легаси) на первоначальном «говнокоде» и никакой архитектуре, собираетесь делать качественный скачок? Экспериментировать на клиентах? Переписать весть проект с нуля?
        Чаще всего такие подходы заканчиваются или пожизненным вливанием доп. бабла в поддержку «говнокода» или смертью продукта с появлением конкурента, который подумал за ранее над тем что будет дальше.
        Во всём должен быть разумный компромисс. ИМХО.
          0
          Я участвовал в 3 стартапах.
          Первый за несколько лет развития пришел к иной бизнес модели и другому продукту, переписывая части системы. В итоге успешно продался.
          Второй, накопив понимания реальных потребностей, переписал платформу с нуля. В результате так же успешно продался.
          Третий на четверном году развития осознал, что существующая бизнес модель не позволяет масштабироваться, отложил реализованную систему и эксперементирует с новой моделью, скручивая новую платформу.
          Это идеальный редкий случай, когда удаётся все заранее предвидеть и предусмотреть.
          Я за поиск максимально простого и быстрого пути войти в цыкл:
          — получить обратную связь;
          — проанализировать;
          — доработать.
          0
          Написано как по учебнику, как будто первая версия априори готова к масштабированию, а не на выкид.
            0
            Первая версия чаще всего на выкид, согласен. Поэтому перед масштабированием и нужно переписывать где-то меньше, где-то больше.
            Академически получилось из-за желания упростить и, не погружаясь глубоко в детали, донести важные моменты для людей без глубоких технических знаний.
            0
            У статьи есть проблема с самого начала. Вот с этой фразы: «Обычно инженеры и компании по разработке ПО стремятся реализовать задачу с максимально высоким качеством, на которое они способны». И так как статья не рассказывает о том, что такое качество, то не технический специалист всяко на этом обожжется.
            При этом странно, что написав статью для не технических специалистов, вы, наверное, претендуете на то, чтобы быть техническим специалистом, но в отношении качества оперируете понятиями «высокое», «больше», «хорошее» и т.д.
            А ведь качество — это всего лишь степень соответствия полученного результата ранее заявленным требованиям. И его можно измерить, запланировать, управлять.
            Но по моему что ещё хуже — далее в статье к этому качеству намешано качество процесса и далее качество архитектуры. Всё же это более сложные темы, чем качество продукта (ПО). Читатель это точно поймёт? А автор статьи это понимает?
              0
              Спасибо за комментарий, ожидал подобной реакции от инженеров.
              Лет 5 назад и сам бы отреагировал точно так же.
              Прежде всего, когда человек без технических знаний обращается к инженерам, он ожидает, что проффесионалы своего дела предложат эффективное решение его проблемы, а не будут просить описать в деталях нужную реализацию.
              Дальше упрощаю и утрирую, что бы показать суть.
              Стартап просит реализовать MVP в виде одного окна, пяти полей и двух кнопок.
              Инженер описывает это в виде требований и реализует в соответствии с ними: микросервисы, очередя сообщений, покрывает все тестами, разворачивает несколько окружений и делает авто деплоймент.
              Стартап пилотирует MVP и понимает что нужно разделить форму на две и заменить/добавить несколько полей.
              Инженер переделывает всю реализацию.
              После нескольких итераций у стартапа заканчиваются деньги, а он так и не успел найти нужный продукт.
              Инженер весьма доволен собой, ведь сделал качественную реализацию в соответствии с требованиям, а стартап просто не знал что нужно рынку.
              Более эффективный ход событий для стартапа:
              — Инженер рисует форму и сохраняет данные в базу, а дальше многократно переделывает с минимальными затратами времени и денег, пока не начнут появлятся клиенты.
              — После этого добавляет автодеплоймент, выносит бизнес логику, покрывает тестами и т.д.
              — Когда нагрузка становиться существенной, рефакторит что нужно для масштабирования. На этом этапе у стартапа уже есть для этого ресурсы.
                0
                MVP в виде одного окна, пяти полей и двух кнопок
                это не MVP, это лендинг какой-то.

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

            Only users with full accounts can post comments. Log in, please.