# Джефф Лоусон: «Перестаньте давать разработчикам готовые решения, делитесь с ними проблемами»

Источник: https://www.youtube.com/watch?v=41C3BE6Vi50
Канал: SaaStr
Опубликовано: 15.01.2021

---

В современном мире, где цифровые технологии проникают во все сферы бизнеса, пропасть между топ-менеджерами и разработчиками становится одной из главных угроз для выживания компаний. В рамках подкаста SaaStr основатель сообщества Джейсон Лемкин обсудил с генеральным директором Twilio Джеффом Лоусоном ключевые идеи его книги «Ask Your Developer». Лоусон подробно рассказал о том, почему классические методы управления в IT больше не работают, как концепция «команды двух пицц» помогает конкурировать за лучшие кадры с технологическими гигантами и почему успешный бизнес сегодня строится на дешевых экспериментах.

## 📘 Мост между бизнесом и кодом: почему родилась книга «Ask Your Developer»
[[JUMP:00:04]]

Уникальное положение Джеффа Лоусона [02:43] позволяет ему видеть технологический бизнес с двух сторон. С одной стороны, он сам является профессиональным программистом, понимающим внутреннюю логику разработки, ее сложность и подверженность сбоям [02:56]. С другой стороны, как генеральный директор публичной компании Twilio, Лоусон ежедневно сталкивается с типичными болями топ-менеджмента: необходимостью сокращать издержки, ускорять релизы и повышать предсказуемость бизнес-процессов [03:21]. По его наблюдениям, большинство бизнес-лидеров просто не умеют разговаривать с разработчиками на одном языке [03:33], что приводит к взаимному непониманию и срыву важнейших проектов.

По мнению Лоусона, руководители часто пытаются применить к разработке стандартные управленческие шаблоны, которые там не работают:

*   **Требование жестких сроков и фиксированного функционала.** Когда бизнес требует назвать точную дату релиза с конкретным набором фич, разработчики часто ставят его перед невозможным выбором: они могут гарантировать либо дату (но без обещаний по функционалу), либо функционал (но без гарантии сроков) [04:12]. 
*   **Попытка решить проблему срыва сроков увеличением бюджета.** Интуитивная реакция любого менеджера на задержку проекта — выделить больше денег и нанять больше людей [04:25]. Однако Лоусон напоминает о классическом законе Брукса (хотя и не называет его по имени напрямую): добавление новых людей в опаздывающий проект лишь сильнее затягивает его сдачу [04:50].

Книга «Ask Your Developer» задумывалась как практическое руководство, призванное устранить этот коммуникационный барьер и дать технической и нетехнической сторонам общий понятийный аппарат [05:02].

## ☠️ От «Build vs Buy» к «Build vs Die»: новая реальность цифровой экономики
[[JUMP:05:02]]

Еще 15 лет назад венчурный капиталист Марк Андриссен сформулировал свой знаменитый тезис о том, что «программное обеспечение пожирает мир» [05:28]. Однако тогда, в начале 2000-х годов, в корпоративном секторе доминировал тренд на аутсорсинг IT-услуг [05:53]. Бизнес рассматривал технологии как поддерживающую функцию (наподобие администрирования офисных ноутбуков или ведения бухгалтерии) и стремился передать их сторонним подрядчикам, не видя в них источника конкурентного преимущества [06:06].

Сегодня ситуация кардинально изменилась. Джефф Лоусон считает, что интерфейс взаимодействия любой компании со своими клиентами стал практически полностью цифровым [06:19]. Он приводит в пример эволюцию банковского сектора:

*   **Раньше:** Привлекательность банка для клиента определялась качеством оформления физического отделения, вежливостью кассира и тем, дадут ли его ребенку леденец на входе [06:32].
*   **Сейчас:** Банк — это мобильное приложение в смартфоне [06:46]. Клиент оценивает банк исключительно по скорости работы приложения, удобству транзакций и регулярности появления полезных функций.

В такой реальности цифровая инфраструктура больше не может быть отдана на аутсорсинг [06:59]. Как только один сильный игрок на рынке осознает это, начинает нанимать разработчиков и выстраивать с ними непрерывный цикл обратной связи, остальные компании отрасли вынуждены следовать его примеру, чтобы не потерять клиентов [07:13]. По мнению Лоусона, классическая дилемма «создавать или покупать» (Build vs Buy) в цифровую эпоху трансформировалась в жесткий ультиматум «создавать или умереть» (Build vs Die) [07:38]. Выживают те компании, которые умеют быстро адаптироваться к меняющимся запросам потребителей с помощью собственного софта, в то время как покупка готовых шаблонных IT-решений ведет к неизбежному технологическому отставанию [07:52].

В подтверждение этого тезиса ведущий Джейсон Лемкин поделился личным опытом: при выборе специализированного банка для управления финансовыми потоками SaaStr объемом $20 млн в год [08:57] представители финансовой организации сразу же признались на звонке в Zoom, что их мобильное приложение оставляет желать лучшего [09:10]. Это показывает, что даже в консервативных нишах качество софта вышло на первый план при оценке надежности партнера.

## 🍕 Сила малых команд: как масштабировать модель «двух пицц»
[[JUMP:09:23]]

Многие руководители ошибочно полагают, что для реализации масштабных цифровых проектов требуются огромные бюджеты и гигантские штаты специалистов [10:01]. Лоусон, опираясь на свой опыт работы инженером в Amazon, утверждает обратное: начинать нужно с малого [10:13]. Главным двигателем прогресса внутри компании должна стать автономная микрокоманда (модель «двух пицц», размер которой не превышает 10 человек) [10:27].

Каждая такая группа должна иметь:

*   Четко очерченный сегмент клиентов [10:27].
*   Конкретную проблему этих клиентов, которую необходимо решить [10:27].
*   Понятные метрики успеха в решении этой проблемы [10:39].

Такой подход решает сразу две важнейшие задачи. Во-первых, он помогает привлекать и удерживать лучших инженеров. Талантливые разработчики не хотят чувствовать себя безликими винтиками в огромной машине из 500 человек, решающих абстрактные задачи [10:53]. Им важно видеть прямой результат своей работы. Во-вторых, работа в небольшой группе сокращает дистанцию между разработчиком и конечным потребителем [11:05]. Когда инженеры находятся в непосредственной близости к проблеме клиента, исчезают лишние уровни абстракции, мешающие созданию качественного продукта.

Более того, модель малых автономных команд позволяет небольшим компаниям успешно конкурировать за кадры с такими гигантами, как Google или Facebook [17:36]. Стартапы не всегда способны предложить аналогичный уровень зарплат или опционов [17:49], но они могут дать разработчику то, чего нет в корпорациях:

*   Максимальную автономию в принятии архитектурных решений [18:02].
*   Возможность напрямую влиять на будущее бизнеса [18:02].
*   Ощущение значимости своей работы.

Лоусон шутит, что в Google с его 50 000 инженеров разработчик может годами отвечать за оптимизацию кнопки «Назад» в браузере Chrome [18:15], не понимая своего реального вклада в успех компании. В небольшой же продуктовой команде инженер сразу видит, как его код меняет жизнь пользователей к лучшему.

## 💡 Главный принцип: ставьте перед разработчиками проблемы, а не задачи
[[JUMP:11:19]]

Один из центральных тезисов Лоусона звучит так: «Делитесь с разработчиками проблемами, а не готовыми решениями» [11:19]. В традиционных компаниях цепочка создания ценности выглядит линейно: бизнес-аналитики или продуктовые менеджеры общаются с клиентами, пишут детальные технические задания (PRD — Product Requirements Documents) и «перебрасывают их через стену» инженерам, которым остается лишь механически перевести текст в код [11:32].

Лоусон убежден, что этот подход неэффективен:

1.  **Отсутствие контекста приводит к ошибкам.** Если программист не понимает, зачем он пишет конкретную строчку кода и какую боль клиента она закрывает, он может совершить архитектурную ошибку, даже не заметив этого [11:58].
2.  **Потеря внутренней мотивации.** Разработка софта — творческий процесс [02:03]. Задача вида «сделай текстовое поле длиной строго в 40 символов» демотивирует сильного специалиста [16:32]. Но если поставить перед ним вызов: «Сделай так, чтобы клиент мог открыть счет менее чем за минуту вместо нынешних десяти» [16:06] — это разжигает профессиональный азарт и заставляет искать элегантные инженерные решения [16:19].

Для того чтобы разработчики глубже понимали потребности клиентов, необходимо целенаправленно разрушать искусственные барьеры (силосы) внутри компании [13:18]. Часто отделы поддержки, продаж и продуктовые менеджеры стремятся «защитить» инженеров от прямого общения с пользователями [13:31, 13:44]. Частично это оправдано (разработчик не должен тратить все свое время на разбор рутинных тикетов), однако полная изоляция вредна [13:56].

Лоусон предлагает практические инструменты для интеграции инженеров в клиентский опыт:

*   **Регулярные дежурства в техподдержке.** В Twilio каждый разработчик раз в квартал или дважды в год проводит день на линии поддержки клиентов [14:23]. Лоусон вспоминает, как во время своего дежурства обнаружил, что 75% поступающих тикетов связаны с необходимостью ручной настройки бэкенд-системы силами инженеров поддержки [14:37]. Клиентам приходилось ждать решения по два дня [14:50]. Сразу после смены Лоусон инициировал создание автоматического интерфейса для самостоятельной настройки этой функции пользователями [15:03].
*   **Участие в звонках отдела продаж.** Периодическое присутствие инженера на встречах с потенциальными клиентами в качестве слушателя помогает ему лично услышать, как бизнес формулирует свои потребности [15:16]. Это вызывает восторг у всех участников процесса — от самих инженеров до клиентов и сейлз-менеджеров [15:28].

## 🏹 Охотники и фермеры в разработке: как распределять роли и мотивировать на рутину
[[JUMP:22:05]]

Любой IT-проект состоит не только из увлекательного создания новых фич с нуля, но и из рутинной работы: исправления багов, рефакторинга кода, оптимизации производительности и поддержки масштабируемости систем [22:05]. Заставить высококлассных инженеров заниматься «неинтересными» задачами бывает непросто.

Джефф Лоусон предлагает решать эту проблему двумя путями:

*   **Формирование чувства собственности (ownership).** Руководитель не должен преподносить рутину как скучную обязанность по исправлению ошибок [22:31]. Задача должна формулироваться иначе: «Вы владеете этим сервисом, ваша цель — сделать так, чтобы пользователи им восхищались» [22:44]. Лоусон приводит бытовую аналогию: мы убираем мусор в своем доме не потому, что это захватывающий процесс, а потому, что мы чувствуем себя хозяевами этого места [23:08].
*   **Понимание психологических типов инженеров.** Руководителям необходимо разделять разработчиков на «изобретателей» и «эксплуататоров» (созидателей и масштабировщиков) [23:35]. Лоусон сравнивает это с классическим делением в отделе продаж на «охотников» (hunters), которые умеют находить новых клиентов и закрывать сложные сделки с нуля, и «фермеров» (farmers), эффективных в удержании, развитии отношений и апсейлах [24:01]. В разработке ситуация аналогична: одни инженеры способны за вечер написать работающий прототип новой идеи, а другие получают искреннее удовольствие от наведения порядка в кодовой базе, выстраивания архитектуры под миллионные нагрузки и обеспечения отказоустойчивости систем [24:38]. Задача менеджера — распределить людей по подходящим ролям [24:51].

## 🤝 Симбиоз Product Management и Engineering: уроки Bloomberg
[[JUMP:25:03]]

Разделение обязанностей между продуктовыми менеджерами (PM) и техническими лидерами часто становится зоной конфликтов. По мнению Лоусона, ключевая роль продакт-менеджера на уровне компании заключается в стратегическом планировании: распределении бюджетов и штата инженеров между наиболее перспективными клиентскими сегментами и проблемами [26:05]. 

На уровне же конкретной микрокоманды задача PM — не диктовать инженерам технические решения, а фасилитировать их общение с клиентами, делиться инсайтами и организовывать процесс совместного поиска ответов на бизнес-вызовы [26:56]. Продакт-менеджер не должен монополизировать право на общение с пользователем [27:35].

В качестве иллюстрации Лоусон рассказывает историю одного из продуктовых лидеров Twilio по имени Бен [28:15]. Свою карьеру Бен начинал программистом в Bloomberg, занимаясь разработкой одного из многочисленных информационных виджетов для знаменитого торгового терминала [28:28]. В самом начале работы он поинтересовался у руководителя, когда сможет лично пообщаться с трейдерами, использующими его софт [28:42]. Менеджер удивился и ответил, что в компании так делать не принято [28:55]. 

Тогда Бен самостоятельно нашел знакомого трейдера и пришел посмотреть на его рабочее место [29:08]. Результат поверг инженера в шок:

*   **Ожидание разработчиков:** Во время написания кода команда представляла свой виджет главным элементом на огромном 24-дюймовом мониторе [29:22].
*   **Реальность:** На экране трейдера виджет оказался крошечным окошком размером 24 на 24 пикселя в самом углу дисплея, где шрифт был практически нечитаемым, а графики — неразличимыми [29:34].

Вернувшись в офис, Бен немедленно переписал логику масштабирования шрифтов и отображения информации [29:47]. Этот важнейший продуктовый инсайт никогда не был бы получен, если бы инженер оставался запертым в рамках стандартного ТЗ [30:00].

## ⚾ Эра дешевых экспериментов: API как цифровая цепочка поставок
[[JUMP:31:07]]

Успех таких гигантов, как AWS, Stripe и Twilio, обусловлен тем, что они предоставляют бизнесу не готовые законченные решения, а базовые строительные блоки [31:07]. Лоусон называет это «цифровой цепочкой поставок» [31:20]. По аналогии с автомобильной промышленностью Детройта, где заводы не собирают каждую гайку самостоятельно, а опираются на сеть специализированных поставщиков, современная разработка ПО строится на интеграции надежных сторонних API [31:32].

Главным следствием этого процесса стало радикальное снижение стоимости инноваций [32:23]. В 1990-е годы внедрение любой крупной корпоративной системы (например, ERP) стоило миллионы долларов, растягивалось на годы и требовало личного согласования на уровне CIO [32:36]. При этом около 60% таких проектов завершались полным провалом, не принося бизнесу никакой ценности [33:02]. Это была эпоха «высоких ставок».

Сегодня разработчик может зарегистрироваться на платформе вроде Twilio или Stripe, привязать карту, потратить один доллар и за несколько минут собрать работающий прототип новой идеи [33:27]. Финансовый риск провала стал ничтожным [34:04].

Лоусон убежден, что непрерывное проведение экспериментов — обязательное условие для инноваций [33:52]:

> «Наша вероятность наткнуться на следующую большую идею напрямую зависит от количества гипотез, которые мы проверяем в единицу времени» [34:18].

Он напоминает спортивную метафору основателя Amazon Джеффа Безоса: в бейсболе при самом удачном стечении обстоятельств игрок может выбить максимум гранд-слэм и принести команде четыре очка [34:30]. Но в бизнесе, особенно в интернете, один успешный удар (« swing ») может принести миллион очков [34:44]. Поэтому задача прогрессивного руководства — не искать причины отказать сотрудникам в реализации новых идей, а создавать условия для быстрого и безопасного проведения сотен мелких экспериментов [35:10].

## 🏗️ Инфраструктура разработки и управление рисками
[[JUMP:36:00]]

Для того чтобы эксперименты проходили быстро и не вредили основному бизнесу, компания должна выстроить качественную внутреннюю платформу для разработчиков [36:13]. Лоусон снова проводит параллель со сферой продаж: профессиональным сейлзам не выдают бумажные блокноты — их снабжают CRM-системами, инструментами генерации лидов и аналитикой, вкладывая в эту инфраструктуру огромные деньги [36:26]. Без качественного инструментария сильные продавцы просто уволятся [36:52].

Точно так же инженерам нужны надежные инструменты для написания, тестирования, быстрого развертывания кода в продакшн, мониторинга и логирования ошибок [37:17]. Лоусон отмечает, что передовые технологические компании тратят от 40% до 50% своего совокупного R&D-бюджета исключительно на развитие внутренней платформы разработки [37:29]. Эти инвестиции многократно окупаются за счет повышения производительности всех продуктовых команд.

При этом бизнес часто блокирует быстрые эксперименты из соображений безопасности и комплаенса, опасаясь утечек персональных данных клиентов или репутационных рисков при сбоях тестового софта [38:06]. Лоусон считает эти опасения абсолютно оправданными, но призывает решать их методологически, а не запретами [38:31]:

*   **Использование концепций бережливого стартапа.** Лоусон рекомендует книгу Эрика Риса «The Lean Startup» для понимания того, как проверять гипотезы без развертывания кода в основной инфраструктуре [38:31].
*   **Изоляция данных.** Эксперименты можно проводить на выделенных дешевых доменах за $7 [38:57], используя синтетические данные или простейшие защищенные облачные инструменты (например, таблицы Google) на этапе прототипирования [39:24], прежде чем переносить успешно доказавшую свою ценность фичу в основной контур безопасности корпорации [39:50].

## 🌍 Распределенная работа и «правило трех часовых поясов»
[[JUMP:41:08]]

Пандемия COVID-19 навсегда изменила ландшафт найма IT-специалистов, доказав жизнеспособность распределенной модели работы [44:59]. При этом Джефф Лоусон остается последовательным сторонником поддержки локальных сообществ. Он подчеркивает, что верит в потенциал Сан-Франциско не из-за веры в монополию Кремниевой долины на таланты, а просто потому, что сам живет в этом городе [41:46]. По его мнению, технологические лидеры, чей бизнес процветает, обязаны инвестировать ресурсы обратно в свои локальные сообщества, особенно в периоды кризисов, помогая тем сферам и людям, которые пострадали от экономических потрясений [41:59].

Обсуждая логистику распределенных компаний, Лоусон дает несколько практических рекомендаций:

1.  **Соблюдение географического баланса внутри микрокоманды.** Члены одной автономной группы должны находиться в пределах максимум трех часовых поясов друг от друга [43:56]. Это гарантирует достаточное количество часов пересечения рабочего времени для оперативного обсуждения вопросов без необходимости вести переписку по 24 часа. В качестве примера Лоусон приводит executive-команду самого Twilio: CPO живет в Сан-Диего, руководитель продуктового направления — в Сиэтле, а руководитель аппарата (Chief of Staff) — в Нью-Йорке [47:45]. Разница во времени не превышает трех часов, что позволяет комфортно работать.
2.  **Формализация связей между удаленными командами.** Сами микрокоманды внутри себя могут общаться неформально и быстро [48:10]. Но если две взаимодействующие команды разделены океаном и полушариями, коммуникации между ними должны быть строго регламентированы и формализованы [48:22]. Попытки заменить выверенные процессы ночными созвонами приводят лишь к профессиональному выгоранию сотрудников [48:48].
3.  **Гибкость внутренней структуры.** Руководителям не стоит навязывать единый формат работы для всей корпорации. После открытия офисов Twilio пошла по пути самоопределения команд: те группы, которые хотят работать очно, возвращаются в офисы; приверженцы удаленки остаются дома [45:38]. Компания позволяет сотрудникам свободно переходить между отделами, чтобы каждый нашел наиболее комфортный для себя рабочий стиль [46:04].

## 🎁 Социальная миссия «Ask Your Developer»
[[JUMP:49:02]]

В завершение беседы Джефф Лоусон подчеркнул, что написание книги не было для него коммерческим проектом. Все доходы от продаж «Ask Your Developer» напрямую направляются в благотворительные фонды и некоммерческие организации, помогающие людям из малообеспеченных и недостаточно представленных слоев населения получить востребованное технологическое образование [49:28].

Среди поддерживаемых организаций:

*   **NPower** — помогает ветеранам вооруженных сил и молодежи из малообеспеченных семей осваивать IT-специальности [49:41].
*   **SMASH** — образовательная программа в области STEM для старшеклассников из латиноамериканских, афроамериканских и индейских общин [49:55].
*   **Black Girls Code** — инициатива, популяризирующая программирование среди темнокожих девушек [49:55].

Покупая книгу, читатели не только получают ценные инсайты по управлению командами, но и вносят непосредственный вклад в создание более инклюзивной и разнообразной технологической индустрии [50:08].