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

Технический долг — это забалансовая стоимость технологических работ, которые необходимо выполнить в будущем. Он накапливается, если выбрать ограниченное / менее дорогое техническое решение сейчас и отодвинуть полное / более дорогое решение на будущее. Не внедряя полное решение сейчас, компании сталкиваются с необходимостью «переделать» разработку программного обеспечения в будущем.

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

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

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

Вот четыре распространенных способа, которыми стартапы накапливают технический долг. .

1. Позвольте мне сначала привлечь клиента, а позже сосредоточиться на дорожной карте продукта

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

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

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

Требования крупных клиентов часто вынуждают их быстро добавлять необходимые функции в продукт. Фактически, такие предложения усложняют согласование сроков, что приводит к тому, что стартапы сокращают углы и сокращают путь.

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

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

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

Урок: Переработка продукт для обобщения функций из реализаций для конкретных клиентов может потерять четверть в год.

2. Мой продукт стабилен, зачем его менять?

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

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

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

Основой программного продукта являются его технология и архитектура. Эти двое нелегко изменить. Если нагрузка на функции слишком велика, фундамент может рухнуть.

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

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

Я испытал это на собственном опыте, когда предлагал клиенту переписать технологию. Это была работа, требовавшая 80-100 человеко-месяцев, и клиент не хотел тратить столько времени на переписывание кода для стабильного продукта, который приносил постоянный доход.

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

Урок: Когда производительность команды падает за пределы допустимого уровня, внедрение новых технологий помогает ускорить работу. увеличение разработки продукта 2x-3x.

3. Мы приняли технологию с открытым исходным кодом — она ​​рассчитана на будущее

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

Некоторые компании на ранней стадии даже не имеют инвесторов. В таких обстоятельствах принятие рентабельных мер является ожидаемым шагом.

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

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

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

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

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

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

Урок: Переход более чем на две основные версии платформы с открытым исходным кодом требует более 25% годовой пропускной способности всей группы.

4. Позвольте мне удовлетворить насущные потребности и изменить архитектуру продукта только в случае необходимости

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

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

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

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

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

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

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

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

Урок: Понимание видения продукта и заблаговременное определение нефункциональных требований (NFR) позволит избежать необходимости полной перестройки.

Итоги

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

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