Basecamp: как делать меньше, а успевать больше
Продолжаю смотреть, как разные компании управляют командами разработки и не только в рамках рубрики #КакУНихУстроено. Сегодня очень - Basecamp.
Это компания, которая уже много лет делает продукты для управления работой и при этом последовательно демонстрирует удивительную мысль: чтобы управлять работой, не обязательно создавать еще больше работы по управлению работой. Революционно, понимаю. 😏
Basecamp довольно небольшая по меркам технологического мира компания, известная не только своим продуктом, но и подходом Shape Up.
И вот он особенно интересно выглядит сегодня, когда многие компании задаются вопросом: как повысить эффектность использования ресурсов, но не порвать командам выработку?
Обычно корпоративный ответ примерно такой:
- объединить команды;
- централизовать ресурсы;
- создать очередь задач;
- потом создать комитет, который будет управлять очередью задач.
И вот где-то здесь Basecamp говорит: а может, проблема вообще не в количестве людей? Как они работают Вместо бесконечного бэклога компания делает ставки на конкретные инициативы. На работу заранее выделяется ограниченный бюджет времени - обычно шесть недель. Не спрашивают: «Сколько месяцев вам понадобится?» Спрашивают: «Что полезного мы можем сделать за шесть недель?» И это принципиально другая постановка задачи. Если проект не помещается во временной бюджет - команда не добавляет еще три месяца разработки. Она режет объем решения.
То есть: время фиксировано, содержание можно менять. Маленькая команда - это обычно дизайнер и несколько разработчиков, получает достаточно автономии, чтобы самостоятельно понять, как именно решить задачу. Без ежедневного пересогласования решения с многоэтажной системой управления.
Мы часто пытаемся повысить эффективность через утилизацию ресурсов. Чтобы разработчик был занят на 100%. Чтобы аналитик был занят на 100%. Чтобы все специалисты были распределены максимально плотно. Выглядит эффективно. До момента, когда один человек одновременно участвует в четырех инициативах, посещает 17 встреч и уже смутно помнит, какой продукт он вообще делает.
Basecamp оптимизирует немного другое: не загрузку людей, а вероятность закончить ценную вещь.
Потому что при перераспределении ресурсов главный риск - не просто потерять 10–15% мощности, а оставить меньше людей в той же системе зависимостей, переключений и согласований. И тогда выработка падает гораздо сильнее численности.
Что можно забрать себе в копилку
Не обязательно завтра отменять Scrum/Kanban/Lean и объявлять шестинедельные циклы. Но несколько принципов выглядят очень здраво:
1. Ограничивать не только количество людей, но и количество одновременно запущенной работы. 2. Давать инициативе фиксированный инвестиционный бюджет. Не «делаем до победного», а: «На эту гипотезу мы готовы потратить 20 человеко-недель».
3. При нехватке ресурсов сначала сокращать скоуп, а не дробить людей между десятью проектами. 4. Считать результатом не занятость команды, а законченный бизнес-результат.
И, пожалуй, главное. Возможно, при реорганизации команд нам иногда нужно меньше думать: «Как эффективнее распределить людей?» И больше: «Как сделать так, чтобы этим людям приходилось делать меньше вещей одновременно?»
Потому что человек, загруженный на 100%, еще не обязательно производит много результата. Иногда он просто очень эффективно переключается между Jira, Zoom и чувством тревоги. 🙂🤙
