Когда приходит время погашать технический долг: опыт LinkedIn

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

Это было в октябре 2011, за несколько недель до второго объявления о доходах LinkedIn после выхода компании на IPO. Бизнес шел хорошо по всем измеримым параметрам. Мы успешно превратились из частного стартапа в публичную компанию. Акции выросли на 171% с первого дня продаж. Мы должны были объявить, что заработок за второй квартал вырос на 126 процентов по сравнению с аналогичным периодом прошлого года. Более 50 миллионов людей присоединились к нашей профессиональной социальной сети за последние 12 месяцев, а всего число участников составило 131.2 миллиона. Нашу компанию оценивали в 9 миллиардов долларов.

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

Так и случилось в один осенний вечер. На волне большого успеха я обнаружил себя в комнате, полной задумчивых и взволнованных продакт-менеджеров LinkedIn. Я стоял перед ними, чтобы рассказать новость, которую не хочет рассказывать ни один лидер отдела разработки. Никаких крутых новых функций в течение ближайших двух месяцев. Все это время мы будем лишь перестраивать нашу инфраструктуру. Эти продакт-менеджеры были амбициозными. Успех бизнеса привел их к ожиданиям продолжающегося роста и выдающихся результатов. Их задача заключалась в создании новых функций и продуктов, которые позволят LinkedIn продолжать развиваться. Остановка на два месяца в мире высоких ставок и ментальности “двигайся быстро и ломай вещи” не входила в их планы. То, что я, новичок в команде, говорю им, что нужно остановиться ненадолго, чтобы развиваться быстрее, не добавляло мне популярности. Особенно учитывая то, что они уже видели, как мои предшественники пытались сделать что-то подобное и провалились.

У вас будет только один шанс, поэтому вам бы лучше сделать всё верно, — сказал один из продакт-менеджеров.

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

LinkedIn был основан 5 мая 2003 года. К 2011, когда компания стала публичной, у нас накопилось 8 лет хорошо обоснованных и безвредных по отдельности технических компромиссов, которые превратились в то, что команда разработчиков называла shit show. Наши благие намерения теперь лишь осложняли быстрое развитие программного обеспечения и масштабирование бизнеса. Чем больше инженеров мы нанимали в команду, тем медленнее все становилось. Все уже устали от препятствий, которые мешали нам развиваться с необходимой и желаемой скоростью.

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

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

Григорий Петров: Технический долг и как его отдавать

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

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

В случае LinkedIn, типичном для быстро растущего стартапа, мы не уделяли техническому долгу достаточно внимания, и в 2011 пора настала пора платить по счетам. Так, будучи публичной компанией в течение нескольких месяцев, наша команда инженеров начала то, что мы назвали “Проект InVersion” — полная перестройка устаревшей структуры разработки программного обеспечения LinkedIn. В течение двух месяцев проекта все разработчики работали над ним одновременно. Примерно на середине пути мы буквально сожгли все мосты позади, уничтожив старую инфраструктуру. Единственным способом создания новых функций было закончить новую платформу. Мы жили мечтой.

В проекте было много технически сложных аспектов. Создание крупных продуктовых Agile-команд, работающих над большими частями ПО — это огромный вызов для каждой компании. Но вещи, которые мы привносили в LinkedIn с проектом InVersion — continuous integration, автоматическое развертывание, разработка программного обеспечения на базе магистралей, A/B-тестирование, canaries-сборки и т.д — были не такими уж сложными. Было много работы, и мы не только создавали инновационные вещи, но у нас был план и мы знали, что делали. Сложнее всего было решить начать работу, затем снова убедить себя, что мы можем это сделать, пока мы сталкивались с естественными препятствиями в этом сложном деле. Две вещи помогли ребятам с этим справиться: всеобщая вера в то, что мы движемся в верном направлении, и достаточное количество лидеров, чтобы заменить друг друга при недостаточной уверенности одного из них.

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

Мы запускали разные функции несколько раз в день против одного раза в месяц раньше. Разработчики были счастливы и проводили больше времени, создавая новые функции, а не занимаясь борьбой с инструментами. Угасания талантов, которое могло случиться в устаревшей системе, не произошло. Наблюдатели снаружи заметили ускорение улучшений на сайте linkedin.com и в наших мобильных приложениях, но лишь озадачивались вопросом, что случилось. А наш бизнес продолжал показывать хорошие результаты.

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