Подход к работе в basecamp (37signals)

Довольно старый но очень познавательный пост в блоге SVN, как они сами написали отвечающий на вопросы:

Как вы парни на самом деле работаете? Как выбираете какими вещами заниматься? Какие у вас команды по размеру? Как вы структурировали вашу работу?

То есть в принципе те вопросы которые всегда интересовали их “последователей”. Как же они за счет такого скудного функционал могут разрабатывать свой продукт. Судя по всему процесс у Basecamp эволюционирует, и если на момент публикации поста в 2017, они по словам Джейсона Фрайда на версии 5.2 то сейчас, в 2023 версия должна быть близка к 7.0. Что же можно вынести для себя из статьи?

6 недельные итерации

Команды в Basecamp работаю по 6 недельным итерациям, каждый цикл содержит проекты 2 типов (автор использует термин batch, переведу это как пачка).

Большая пачка — проекты которые целиком могут занять весь 6-недельный цикл, обычно они берут 1-2 таких проекта. Для каждого большого проекта существует свой собственный проект в Basecamp где ведется вся коммуникация и документация.

Маленькая пачка более мелкие проекты улучшения, исправления и понятные инициативы которые могут занять и день и пару недель. Обычно берут 4-8 таких проектов.

После завершения цикла берут 1-2 недели на проекта за пределами расписания, исправления проблем, pet-projects и на подготовку нового цикла.

Интересное замечание что это не спринты:

Note: These are not sprints. I despise the word sprints. Sprints and work don’t go together. This isn’t about running all out as fast as you can, it’s about working calmly, at a nice pace, and making smart calls along the way. No brute force here, no catching our collective breath at the end.

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

Что можно взять себе:

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

Экстремально маленькие команды 2-3 человека

Один большой проект — одна команда. Команды собираются на лету и по желанию — кто чем хотел бы заняться. В команде 1-2 программиста и дизайнер (я так понимаю 1 бекэнд, 1 фронт). Руководит дизайнер!!! Вера что дизайнер должен уметь затащить разработку меня радует, хотя, далеко не всякому дизайнеру такое под силу.

We only hire designers who are capable of leading projects, but yes, small team sizes help reduce management requirements to begin with. So it’s sort of a 1–2 punch — designers who can lead, small teams.

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

Все работаю в одной среде

Для “сигналов” это естественно basecamp, считается что разделение команд по инструментам это:

• крайне неэффективно
• не дает полную картину команде

Что верно но к сожалению не всегда возможно. Если невозможно то что делать? Об этом ниже.

В Basecamp не придерживаются трекинг времени так как считают что бесполезно оценивать запланированные и полученные результаты. Задача в том что есть фиксированный лимит времени — 6 недель. Точка. Можно двигаться внутри если команда успевает или наоборот опаздывает.

Питчинг

Кажется это самая интересная часть процесса. Этот то момент когда идея, откуда бы она не пришла, обретает форму и готова быть представлена. Делается это в текстовом виде по ряду причин:

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

Пример питча большого проекта.

Запуск цикла

После питчинга, сортировки проектов по пачкам, публикуется пост о запуске где структурирует все работы которые запланированы. Для себя они используют конечно basecamp, один из объединяющих проектов, мне видится что для этого подойдет база знаний (wiki, notion, confluens).

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

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

Как работает QA

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

Вместо заключения

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

1. Как вы структурируете вашу работу? Отличается ли подход к реализации
2. Как вы выделяете время
3. Как решаете что делать и что не делать?
4. Как доносите до команды новые идеи?
5. Как вы начинаете новый спринт?
6. Где вы общаетесь?
7. Как организована команда или команды? Насколько они оптимальны?

Ну а после, попытайтесь найти точки для улучшения.