Последние 7 лет я занимаюсь разработкой продуктов для разработчиков — это API, DevOps и инфраструктура.

Одно из основных и самых главных отличий таких продуктов от приложений массового использования и даже b2b SaaS в том, что изменения в продукте долги и дороги.

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

Почему так?

Люди строят на наших API свои бизнесы

Изменение функционала влечёт за собой нарушение в их работе. Представьте себе, что вдруг упал Убер из-за того, что Гугл карты стали требовать новый параметр в API запросе построения маршрутов. Или упал сайт New York Times из-за того, что AWS решил изменить как работает load balancer и поломал всю их автоматизацию.

Наш API обеспечивает лишь часть функционала приложения клиентов.

Они расчитывают на стабильность, чтобы можно было создать работающий код и не трогать его до тех пор, пока не появится бизнес-необходимость. Некоторый код банков до сих пор работает на давно не поддерживаемых версиях языков программирования (runtimes) потому что он за 100500 файерволлами, служит для какой-то внутренней нужды и уже никем не поддерживается.

Он работает по принципу don’t touch what ain’t broken и все счастливы. Если мы решим, что надо бы заставить всех проапгрейдится с Python 2.7 до Python 3.9, то произойдёт то, что называется pull the rug from under the customer — выдернуть ковёр из-под клиента, как в мультиках, с последующим падением, разбитым носом и потерей доверия.

У наших клиентов ограниченные ресурсы.

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

Этот список можно продолжить, но суть в том, что в разработке API, инфраструктуры и инструментов для автоматизации очень мало свободы для резких изменений. Одно из следствий этого — эксперименты (A/B тесты) практически невозможны, их заменяют длительные периоды бета-тестирования, в которых особо инновационные клиенты готовы поучаствовать, рискуя тем, что их расходы не окупятся и придётся переделывать.

Похоронить неудачную фичу практически невозможно

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

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

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