Basecamp: как из беспорядка в веб-студии вырос бизнес со своими правилами

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

У истории Zappos и истории Basecamp есть интересное пересечение: обе можно читать как рассказ о том, что происходит, когда предприниматель всерьёз занимается чужим неудобством.

Но мораль у них разная.

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

В Basecamp — другой вопрос: сколько лишнего можно убрать из продукта и организации, не потеряв результат, а улучшив его?

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

Сначала компания выросла — и стала хуже работать

В 1999 году Джейсон Фрид с партнёрами основал в Чикаго веб-студию 37signals. Компания занималась клиентскими сайтами, а не разработкой собственного массового продукта. WIRED

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

Здесь легко узнать обычный небольшой бизнес.

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

У 37signals было несколько возможных направлений: терпеть, нанимать людей для координации, искать подходящее программное обеспечение. Команда пробовала существующие инструменты, но не нашла удовлетворительного решения и начала создавать своё. В центре оказались понятные задачи: сохранять обсуждения, видеть ответственность и сроки, не терять замечания клиентов. Basecamp

Важен масштаб первоначального замысла.

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

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

Для предпринимателя здесь полезен вопрос: какое затруднение вы исправляете вручную снова и снова — и не приняли ли уже его за неизбежную часть профессии?

Они строили не воображаемый продукт, а инструмент для настоящих проектов

В разработке раннего Basecamp участвовали Джейсон Фрид, дизайнер Райан Сингер и программист Дэвид Хейнемейер Ханссон, известный как DHH. Фрид вспоминал, что Ханссон работал над проектом примерно по десять часов в неделю в течение семи месяцев; интерфейсом занимались Фрид и Сингер. Signal v. Noise

Это не была история о том, как основатели бросили всё ради огромной ставки на ещё не проверенный рынок. Новый инструмент появлялся рядом с существующей клиентской работой.

И пользовались им не только сами разработчики. Его видели заказчики студии.

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

Здесь произошёл принципиальный переход.

«Нам это удобно» — важное наблюдение.

«Другие люди хотят пользоваться этим в своей работе» — уже другое свидетельство.

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

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

Открыть схему

От внутренней проблемы до отдельного продукта: Клиентские проекты студии, Повторяющееся затруднение, Собственный инструмент, Использование клиентами. Редакционная схема по кейсу; показывает логику решений, а не измеренный эффект.

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

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

Они вышли на рынок, не закончив всё, что считали желательным

Basecamp запустили в феврале 2004 года. Объявление появилось в собственном блоге компании Signal v. Noise. Signal v. Noise

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

В подкасте REWORK Фрид рассказывал, что команда отвела себе тридцать дней после запуска, чтобы её сделать. Первоначально планировалась годовая оплата, но банк, обслуживавший приём платежей, не согласился с таким риском: если новая услуга быстро прекратит работу, возникнут обязательства перед покупателями. Поэтому пришлось перейти к ежемесячной модели. 37signals

Важно правильно понять этот эпизод.

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

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

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

Позднее в Getting Real этот подход выразили как различие между небольшим законченным продуктом и большой недоделкой: сократить объём, а не качество того, что решили выпустить. Basecamp

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

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

Basecamp полезен как пример дисциплины завершения: не сделать кое-как всё задуманное, а определить, что уже можно закончить и передать людям.

Продажи начались не «из ниоткуда»

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

Но у 37signals к тому времени уже был канал доступа к аудитории.

В Getting Real команда писала, что Signal v. Noise привлекал тысячи читателей в неделю. После объявления о Basecamp информацию подхватили другие заметные блоги. Основатели также прямо отмечали: первоначально они направляли продвижение прежде всего на дизайнерские компании. Basecamp

Получилось содержательное совпадение.

Разработчики понимали рабочую проблему. Первые потенциальные покупатели занимались похожей деятельностью. А часть этой аудитории уже знала компанию по её публикациям.

Поэтому фраза «запустились одним постом» не означает «продвижение не понадобилось». За постом стояли предыдущая работа, читатели и профессиональные связи.

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

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

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

Basecamp позволяет увидеть продвижение не как украшение уже готового бизнеса, а как постепенно создаваемую возможность вступить в разговор с будущими покупателями.

Хороший продукт не отменяет вопрос «как о нём узнают?». А известность не отменяет вопрос «почему за него заплатят?».

Побочный проект стал главным — после того, как это показали покупатели

Фрид рассказывал, что первоначальной надеждой было выйти примерно на 5 тысяч долларов ежемесячной выручки через год. Такой продукт мог бы стать устойчивым дополнением к студии — своего рода постоянным клиентом.

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

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

Сначала появилась работающая услуга. Затем — внутренний инструмент. Потом — внешний спрос. И только после этого изменился основной бизнес.

Это заметно отличается от подхода «сначала разрушим источник дохода, чтобы не было пути назад».

Здесь существующая деятельность помогла дойти до новой.

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

В истории Basecamp стоит замечать не только готовность начать новое, но и способность вовремя признать, что новое уже стало главным.

Их главным отличием стало не количество функций

На раннем сайте Basecamp обещал «управление проектами без боли». Это не формулировка про самое большое количество возможностей. Это обещание более удобного опыта работы. Web Design Museum

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

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

Вопрос — для кого вы создаёте продукт.

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

Для такого покупателя отсутствие лишнего может оказаться достоинством.

Но только если необходимое действительно работает.

Простота не равна бедности продукта. Простота — это результат отбора: какие действия мы хотим сделать понятными и от какой сложности готовы защитить пользователя?

У этой позиции есть цена. Придётся не выполнить часть запросов. Иногда — признать, что другому клиенту подходит другой инструмент.

Для основателя это трудное решение: отказ от функции может переживаться как отказ от будущих денег.

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

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

Открыть схему

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

Они не отказались от денег. Они иначе определили их роль

Историю Basecamp нередко сводят к лозунгу «никаких инвесторов». Это неточно.

В 2006 году Bezos Expeditions — личная инвестиционная компания Джеффа Безоса — приобрела миноритарную долю в 37signals. В объявлении основатели подчёркивали, что до этого не приняли предложений многочисленных венчурных фондов. Позднее Фрид объяснял: сделка с Безосом была нужна не для финансирования текущих операций, а в том числе ради его опыта и участия. Signal v. Noise

Ещё позже Фрид описывал её как способ снизить личный риск владельцев, сохранив возможность развивать компанию по собственному расписанию. Hey World

Поэтому важнее не противопоставление «деньги — свобода», а условия, на которых деньги приходят.

У Basecamp сформировалась выраженная позиция: прибыль нужна не только как показатель успеха, но и как источник самостоятельности. В собственном объяснении компания связывает финансовую устойчивость с возможностью выбирать направление работы без постоянной зависимости от следующего раунда финансирования. Это позиция основателей; точные текущие финансовые результаты из неё вывести нельзя. Basecamp

Практический вопрос здесь звучит так:

Какое устройство бизнеса позволит нам выполнять обязательства и продолжать работу, даже если завтра никто не предложит новых инвестиций?

Для некоторых проектов внешнее финансирование необходимо. Basecamp не доказывает обратного.

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

Самое трудное «нет» они сказали собственным продуктам

После успеха Basecamp компания создавала другие сервисы. Среди них были Backpack, Campfire и Highrise. Постепенно поддержка нескольких направлений стала требовать всё больше внимания.

В подкасте о смене названия Фрид и Ханссон вспоминали, что перестали быть довольны тем, сколько успевали улучшать в каждом продукте. В 2014 году они решили сосредоточиться на Basecamp, а с остальными направлениями поступить по-разному: отделить, передать, объединить или прекратить активное развитие. Компания тоже стала называться Basecamp. 37signals

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

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

Но у компании остаётся ограниченная способность качественно ими заниматься.

Здесь возникает неудобный вопрос:

Мы расширяем бизнес — или только увеличиваем число направлений, которым не можем уделить достаточно внимания?

При этом концентрация не стала пожизненным запретом на новое. В 2020 году компания запустила почтовый сервис HEY, а в 2022-м вернула название 37signals, под которым было удобнее объединять разные продукты. 37signals

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

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

Фокус — не обещание никогда не менять состав работы. Это готовность принимать решения о приоритетах.

Они начали проектировать не только программу, но и способ работы

К 2010 году WIRED описывал 37signals как компанию из шестнадцати сотрудников, работавших в девяти местах в трёх странах. Распределённая работа была частью её устройства задолго до массового перехода в удалённый формат во время пандемии. WIRED

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

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

В своём руководстве по коммуникации 37signals предлагает другой подход: преимущественно письменное и асинхронное взаимодействие, содержательные обсуждения вместо обмена обрывочными репликами, встречи — не как первый ответ на любую проблему. Важным вопросам нужно дать время, а не требовать немедленной реакции. Basecamp

В этом есть понятная организационная логика.

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

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

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

Из практики вырос Shape Up: передавать проект, а не бесконечный поток поручений

Позднее Райан Сингер описал подход к разработке Basecamp в книге Shape Up.

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

Здесь есть принцип, полезный далеко за пределами программирования.

Обычный вопрос: «Сколько времени нужно, чтобы сделать всё, что мы придумали?»

В Shape Up предлагается начать с другого: «Сколько времени эта задача для нас стоит — и какое осмысленное решение помещается в эти ограничения?» Объём можно менять; согласованный период не должен автоматически растягиваться вместе с каждой новой идеей. Basecamp

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

Можно немедленно объявить полную автоматизацию продаж. А можно определить ограниченный результат: сотрудник самостоятельно готовит один тип предложения по понятным исходным данным.

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

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

Для предпринимателя это меняет содержание делегирования.

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

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

Можно вовремя сделать ненужную вещь. Поэтому управляемое исполнение и правильный выбор задачи — две разные ответственности.

Открыть схему

Как подготовить работу к завершению: Сформулировать проблему, Определить границы и существенные риски, Выделить доступное время, Передать проект команде. Редакционная схема по кейсу; показывает логику решений, а не измеренный эффект.

Один из самых больших результатов компании она отдала бесплатно

Во время создания Basecamp Дэвид Хейнемейер Ханссон разработал инструменты, которые затем стали основой Ruby on Rails. В 2004 году Rails был опубликован как открытый программный инструмент для создания веб-приложений. 37signals

Для читателя, не связанного с разработкой, смысл можно объяснить просто.

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

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

Компания не утверждала, что открытость не имеет коммерческого эффекта. В Getting Real основатели писали, что публикация Rails принесла узнаваемость, обратную связь и вклад других программистов. Одновременно они рассматривали обучение аудитории как полноценный способ продвижения. Basecamp

Позже накопленный опыт оформлялся в книги — Getting Real, Rework, Remote, It Doesn’t Have to Be Crazy at Work и Shape Up. Basecamp

Здесь находится один из самых интересных уроков всей истории:

Компания может создавать больше ценности, чем непосредственно продаёт.

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

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

Однако хорошая философия не сделала компанию безошибочной

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

В апреле 2021 года основатели объявили изменения правил, включая запрет общественно-политических обсуждений в корпоративной системе и отказ от ряда внутренних комитетов. Фрид объяснял это стремлением вернуть внимание к работе и персональную ответственность. Hey World

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

Этот эпизод не отменяет продуктовых находок Basecamp. Но и продуктовые находки не делают любое решение основателей правильным.

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

У сотрудников есть собственное понимание достоинства, безопасности и договорённостей с компанией. Поэтому изменение культуры — не только вопрос того, что владельцы считают более эффективным.

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

Что мир получил благодаря Basecamp

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

Её вклад интереснее: она сделала видимым другой способ строить технологический бизнес и подробно объяснила, как сама пытается это делать. Продукт, открытый код, книги и описания рабочих практик позволяют изучать не только результат, но и решения за ним. 37signals

Из этой истории я бы выделил три главных урока.

Полезное большое дело может начаться с небольшой, хорошо понятой проблемы

Необязательно сначала придумать, как изменить целую отрасль.

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

Масштаб последствий не обязан совпадать с масштабом первоначальной декларации.

Рост требует не только добавления, но и отбора

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

Полезный вопрос не только «чего нам не хватает?», но и «что мешает хорошо делать главное?».

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

Сам бизнес тоже нужно проектировать

Основатель выбирает не только то, что будет продавать.

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

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

Для меня это самая сильная мысль, которую позволяет вынести история Basecamp:

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

Не становиться огромным — не значит делать маленькое дело

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

Но самое вдохновляющее здесь — не разрешение остановиться на малом.

Это возможность иначе определить амбицию.

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

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

История Basecamp предлагает предпринимателю задать себе два вопроса.

Первый: какое неудобство мы способны устранить для других?

Второй: какую компанию нам нужно построить, чтобы делать это хорошо и достаточно долго?

Первый помогает найти продукт.

Второй помогает не потерять смысл собственного дела по дороге к успеху.