Как работают в Basecamp? Разбираем публичную методичку компании

Привет. Вы слышали про 37signals? Это ребята, которые изобрели Ruby On Rails, потом построили систему управления проектами Basecamp, после этого пошли уже менее известные проекты: Backpack —система управления знаниями, Highrise —система CRM и мессенджер Campfire. Компания, продуктами которой пользуется более 3 миллионов человек ежедневно — имеет в своём штабе всего 14 постоянных сотрудников. В данной статье я расскажу о глобальных принципах работы, в следующих пройдемся по командным ритуалам, карьерному развитию внутри Basecamp и посмотрим на критерии программистов для устройства в компанию.

Чтобы не пропустить посты – подписывайтесь на мой инстаграм и телеграм, там я буду уведомлять о выпуске новых частей, а так же постоянно рассказываю про свою карьеру тимлида в крипте, старте в IT и успешном work-life балансе ✌🏻

Я познакомился с этой компанией и их стилем управления впервые, когда прочитал книгу «Rework: Бизнес без предрассудков». После этого я проникся их идеологией и сразу в ход пошли книги «Remote: Офис не обязателен» и «Не сходите с ума на работе». Книги были особенно актуальны, когда в начале локдауна нужно было переходить на полностью удалённую работу и предстоял процесс выстраивания процессов.

По моему мнению, концепты управления проектами от Basecamp конечно довольно принципиальны и трудно выполнимы в больших компаниях (не просто так у них 14 человек), но конечно многому у них стоит поучиться. Но сейчас не о книгах.

Я случайно наткнулся на методичку для работников Basecamp, в которых кратко задокументированы процессы работы в их компании и хотел бы начать конспектировать основные процессы на русском языке.

И так, как же устроена работа в Basecamp?

В Basecamp работают 6-8 недельными циклами. Обычно в году бывает 6 циклов. Два из них – 8 недельные и чаще всего они проходят летом

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

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

Этот подход особенно важен для продуктовых команд, так как очень полезно заранее понимать полный объем работы, за которую нужно браться. В компании есть примерная стоимость фич по времени – 1 маленькая фича занимает неделю времени. Более комплексная может растянуться до шести недель, но не более.

Таким образом, планирование задач ограничивается временным бюджетом. Если мы понимаем на планировании, что фича мелкая – она не должна выходить из оценки в 1 неделю, так как бюджет времени на задачи – фиксированный. Мелкие фичи не должны делаться больше срока за счёт большего количества работы сотрудников. Таким образом, почти все проекты укладываются в обычные 6 или летние 8 недель работы.

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

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

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

Достаточно трудно уследить за тем, что все делают и что полезного в этом, если просто наблюдать за доской задач или историей коммитов (это так же забирает много времени)

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

Во-первых, это ежедневный вопрос “Над чем вы сегодня работали?” , который представляет подробную информацию в виде личного рассказа. Этот вопрос является отличной темой для разговора, если вы видите, что кто-то работает над чем-то, что вас волнует или о чем вам интересно узнать побольше. Basecamp просит не игнорировать этот вопрос и периодически просматривать данные логи (минимум два раза в неделю)

Второй вопрос еженедельный – “Над чем вы планируете работать на этой неделе?” . В данном вопросе нужно подробно описать все задачи на неделю, рассказать о ваших идеях относительно выполнения задач и рассказать, какие цели будут выполнены к концу недели

Третий этап – сердцебиение (интересное название ретроспективы 🫡) Этот вопрос является командной версией вопроса “Что вы делали в этом цикле?” . Здесь подводятся итоги цикла, отмечается завершённая работа и подводятся результаты. Каждый руководитель команды обязан написать или поручить кому-то из команды написать этот отчет через неделю после завершения цикла.

И четвертый, финальный этап коммуникации, это старт цикла (kick-off, я не знаю как перевести это дословно). Это так же командный вопрос, в котором нужно написать “Над чем вы собираетесь работать в следующем цикле?” Здесь представляется план на ближайшие шесть (или восемь летних) недель. Каждый руководитель команды обязан написать или поручить кому-то из команды написать этот отчет до начала цикла, чтобы другие участники могли ознакомиться и как-то помочь с выполнением задачи, а так же понимать, могут ли пересекаться рабочие задачи.

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

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

Все эти отчеты и вопросы так же идут в финальную говодую презентацию “Что мы сделали”, которая является подведением общих итогов.

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

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

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

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

Вероятность того, что ваша идея сразу же попадет в следующий цикл компании – не высокая. Даже если ваша идея действительно крутая и ее одобряют другие участники команды – нужно понимать тот факт, что идей всегда больше, чем времени и в каждом цикле можно сделать только несколько задач. Питч может быть крутой и полезный, но менее приоритетный. Не расстраивайтесь по этому поводу. Самый долгий питч в Бейскэмпе лежал в бэклоге год, но после этого его все равно взяли в работу.

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

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

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

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

При этом, в любом случае желательно подбирать команды таким образом, чтобы совместное рабочее время составляло хотя бы 15-30-60 минут в день. Поскольку если у вас часто будут проблемы, которые можно решить за пару минут – тратить на это целый день будет не приятно и не продуктивно для вас. Старайтесь искать компромиссы.

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

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

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

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

Когда нужно использовать базу данных, это тоже должно выполняться “самообслуживанием”. У нас должен быть сценарий, который каждый может запустить для восстановления. Не нужно идти к девопсам и ждать, пока кто-то сделает это за нас.

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

Как только образуются проблемные места, например, множество функций, ожидающих «мобильной интеграции», команду начинает тянуть к микро-менеджменту и расписанию. Оно превращается в сложный путь с зависимостями и обеспечением того, чтобы команда X была доступна в нужный момент для команды А, чтобы никто не был заблокирован. Это плохо согласуется с организационными устремлениями, поэтому Basecamp приходится работать над тем, чтобы противостоять этому.

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

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

Мы ограничиваем себя 40-часовой (32-часовой летом) рабочей неделей. Ограничение рабочего времени заставляет нас расставлять приоритеты в работе, которая действительно важна. Здоровый сон и насыщенная качественная жизнь вне работы не должны быть потеряны ради нескольких дополнительных часов в офисе.

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

Итоговое ревью о том, как работают в Basecamp: