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

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

Когда отношения не заканчиваются на сдаче

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

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

Каждый баг — ваш баг

Самый непосредственный эффект — на ответственности, и он не абстрактен. Каждый баг в продукте KeepFlow — наш баг. Каждая просадка производительности проявляется в наших собственных числах. Каждый раздражённый пользователь — прямой вердикт работе, которую сделали мы. Некому передать тикет.

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

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

Строим на срок жизни, а не на дедлайн

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

Когда вы строите то, что будете эксплуатировать годами, расчёт почти по каждому выбору переворачивается:

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

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

Петля обратной связи замыкается

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

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

Когда продукт ваш, заметить и починить — одно и то же движение. Инженер читает тред в поддержке, узнаёт паттерн за тремя жалобами и выкатывает исправление в тот же день — без цепочки согласований, без счёта, без спора о том, входит ли это в объём. Люди, ближе всех стоящие к проблеме, имеют и контекст, чтобы её понять, и полномочия, чтобы её решить. За месяцы это накопление мелких, ничем не заблокированных улучшений и есть бо́льшая часть того, что отличает продукт, который терпят, от того, на который полагаются.

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

Не гонимся за трендами

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

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

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