Вступление
Эта книга — о том, как мы в Basecamp разрабатываем продукты. В ней описаны инструменты, которые вы можете использовать в своих рабочих процессах.
Вероятно, вы читаете эту книгу, поскольку столкнулись с типичными проблемами компаний, разрабатывающих программные продукты.
Болезни роста
По мере того, как команды растут, растут и проблемы:
- проекты, кажется, никогда не заканчиваются;
- продакт-менеджеры не могут найти время спокойно подумать о стратегии и будущем продукта;
- владельцы компании обнаруживают, что новые фичи выпускаются все медленнее, не то что в прежние времена.
Мы в Basecamp не избежали этих проблем — в какой-то момент из 4 человек мы выросли до 50.
Продукт Basecamp был создан нами в 2003 году для самих себя. В то время мы делали веб-сайты на заказ. Клиент, дизайнер и менеджер постоянно играли в испорченный телефон, теряя важную информацию. Мы хотели, чтобы Basecamp стал единым местом для обсуждения сделанной и будущей работы.
Оказалось, что у многих компаний похожие проблемы — информация «уходит в песок». Сегодня миллионы людей всех возможных профессий используют Basecamp как основной источник правды.
Первую версию Basecamp создала команда из трёх человек. Джейсон (Jason Fried), основатель, отвечал за дизайн. Дэвид (David Heinemeier Hansson) — за разработку (и как побочный продукт создал Ruby on Rails). В то время я работал дизайнером сайтов и интерфейсов. Я брал направление, обозначенное Джейсоном, и вместе с ним прорабатывал все детали.
С июля 2003 до запуска в феврале 2004 Дэвид работал только 10 часов в неделю. Мы знали, что справимся, только если эти 10 часов будут тратиться очень обдуманно. Приём «вколачивания» объёма работы во временные рамки был придуман как раз по этим причинам.
Я изучал техники, которые программисты используют для управления сложностью — факторинг, уровни абстракции, разделение ответственностей (SoC) — и решил попробовать применить их к дизайну и управлению продуктом.
Первая проверка идеи состоялась в 2009 году. К тому времени в компании было несколько программистов, мы продавали 4 отдельных продукта. Мы захотели объединить продукты в один, с единой авторизацией и оплатой. Это был огромный технический сложный проект с заковыристыми сценариями. Нам предстояло не только аккуратно переделать архитектуру, но и заставить всех поменять логины и пароли — необходимость этого непросто объяснить пользователям. Я был дизайнером и продакт-менеджером, поэтому опробовал техники «макетной платы» (breadboarding) и «карты проекта» (scope mapping), описанные в этой книге.
Результаты были настолько хороши, что мы решили использовать те же техники в 2012 году для полной переделки Basecamp 2.0. Вновь проект был технически сложен, и вновь работа прошла на удивление гладко.
К 2015 году в компании было много новых сотрудников, не имевших подобного опыта. Оказалось, что передать его не так просто. Продуктовая команда выросла в 4 раза и все работали удалённо. Перенимать знания «лицом к лицу» не получалось. Нам нужно было научиться формулировать, что и как именно мы делаем.
В то время я отвечал за продуктовую стратегию. Мне нужны были новые термины, чтобы описать наши процессы. Мы описали «формирование проекта» (shaping), «презентацию» (pitching) и «голосование» (betting).
По мере того, как мы документировали эти процессы, люди вокруг стали интересоваться, как именно это всё работает. Однажды Джейсон отозвал меня в сторонку и сказал: «Тебе стоит написать об этом книгу».
Вот она. По сути, тут две книги в одной. Первая — набор понятий для работы с рисками, неопределённостями и трудностями, возникающими у всех, кто разрабатывает продукт. Вторая — описание конкретных практик, которые мы используем для развития наших продуктов с учётом текущего размера компании.
Главные идеи книги:
1. Циклы в 6 недель
Мы работаем в рамках 6-недельных циклов. Это достаточно много, чтобы разработать что-то осмысленное, и достаточно мало, чтобы все видели финиш уже на старте. Так гораздо легче использовать время обдуманно. Почти все наши проекты выпускаются в течение 6-недельного цикла.
Основа наших решений — желание улучшить продукт за 6 недель. Никакого управления временем, подсчёта рабочих часов, отчётов за день. У нас нет ежедневных летучек. Мы не пересматриваем план работ каждые 2 недели. Вместо этого мы говорим: «Если этот проект выпущен за 6 недель, время потрачено не зря». Затем мы оставляем команду в покое, чтобы она спокойно достигла результата.
2. Формирование проекта
Мы формируем проект, прежде чем отдать его команде. Небольшая команда менеджеров прорабатывает все основные идеи будущих проектов, в то время как программисты работают над проектами, сформированными ранее. Важно, чтобы уровень проработки идей был золотой серединой — не слишком абстрактный (чтобы команды понимали, что нужно делать), но и не слишком конкретный (чтобы у команды была достаточная свобода в принятии решений).
Когда мы формируем проект, вместо оценки времени мы используем понятие «аппетит». Вместо «сколько времени это займёт?» мы спрашиваем «сколько времени мы хотим на это потратить?».
В этом основная идея формирования как процесса — сформулировать проблему и предложить решение так, чтобы проект вместился в наш «аппетит».
3. Ответственность команды
Мы перекладываем всю ответственность за проект на небольшую команду дизайнеров и программистов. Они сами ставят себе задачи, меняют объём работы, разбивают проект на части и работают над ними по своему усмотрению. Этот подход радикально отличается от общепринятого подхода, при котором менеджеры нарезают проект на задачи (тикеты) и раздают их разработчикам.
Вместе эти практики усиливают друг друга. Команды работают более автономно — у менеджеров и аналитиков уходит меньше времени на управление командами, появляется время лучше сформировать будущие проекты. К лучше сформированным проектам у команды меньше вопросов — она работает более автономно.
4. Управление рисками
На каждом этапе цикла мы управляем одним конкретным риском — не выпустить проект вовремя. В этой книге нет ничего про риск разработать ненужный проект (про это написано много других книг, рекомендуем Competing Against Luck). Возможно, у вас лучшие идеи на свете, но если вы не можете их воплотить, в чем их смысл?
Эта книга — о риске зайти в тупик, не успеть к сроку, потратить время на внезапные проблемы, и в итоге иметь планы, но не иметь времени на их воплощение.
На этапе формирования мы уменьшаем риск тем, что решаем все открытые вопросы верхнего уровня до передачи команде в работу. Проект не будет отдан, пока в нем есть видимые дыры или нечёткие зависимости.
На этапе планирования мы уменьшаем риск тем, что ограничиваем себя шестью неделями. Если проект не готов к сроку, обычно он отменяется. Этот «предохранитель» даёт нам уверенность, что мы не потратим в разы больше, чем планировали, на что-то, что часто требует пересмотра идеи.
На этапе разработки мы уменьшаем риск тем, что дизайнер и программист работают вместе с самого начала. Вместо отдельных заданий, которые, если повезёт, соединятся в последний день в работающий проект, команда разбивает проект на осмысленные части и выпускает их по одной, не дожидаясь конца цикла. Обычно команда начинает с самых непонятных частей и, выпуская часть за частью, получает возможность мгновенно понять, что в целом может пойти не так.
Как устроена эта книга
Часть 1 посвящена формированию — подготовительной работе, после которой проект готов к планированию. Каждая глава описывает этап процесса — определение «аппетита», описание решения, презентация. В этой части вы узнаете про конкретные приёмы (например, макетные платы и наброски толстым маркером), позволяющие держать нужный баланс абстракции.
Часть 2 — про голосование. Как мы выбираем, что взять в работу.
Часть 3 — про разработку. Чего мы ожидаем от команд, какими процессами они пользуются, чтобы понять, что делать, что уже ясно, а что ещё неясно, как взаимодействуют дизайн и разработка, и чем жертвовать, чтобы закончить работу в срок.
Наконец, Приложение — для тех, кто хочет начать менять работу в своей компании. Советы тем, кто хочет попробовать 6-недельные циклы, адаптировать наши техники к своему размеру компании, а также использовать для их применения наш продукт, Basecamp.