Shape Up — Часть 1, Вступление

От переводчика

Привет! Я Артем, а это мой любительский перевод книги Shape Up от основателей Basecamp. К сожалению, я не нашел ее на русском языке и так совпало, что как раз в это же время я начал активнее заниматься своим уровнем английского. Для практики решил попробовать перевести книгу, посмотрим, удастся ли мне перевести ее целиком. Shape Up описывает нестандартный подход в проектном управлении. Их подход отлично подходит для разработки программных продуктов, но, на мой взгляд, применим и в других сферах. В общем, если будет полезно, буду только рад. Найдете ошибки или опечатки — можете смело писать мне в телеграм. Ну и на телеграм-канал можете подписаться, там буду публиковать главы по ходу перевода. Enjoy 🤘

Как перестать бежать в колесе и начать делать то, что важно

Эта книга — руководство, как мы разрабатываем продукты в Basecamp. Помимо этого, книга это набор подходов и техник, которые вы сможете применить с своих процессах.

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

Боль роста

Рост команд разработки вызывает типичные проблемы:

- Участники команды чувствуют, что работа над проектами бесконечна, и конца этому не видно

- Продакты не могут найти время для формирования стратегии продукта

- Основатели задаются вопросом: "Почему мы не можем выкатывать новые фичи также быстро, как раньше?"

Мы видели эти проблемы своими глазами, когда Basecamp вырос с 4 человек до 50.

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

Трое из нас разработали первую версию. Jason Fried, основатель Basecamp, курировал дизайн. Его со-основатель, David Heinemeier Hansson, спрограммировал это (и создал популярный фреймворк Ruby on Rails по ходу дела).

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

От первого прототипа в июле 2003 до запуска в феврале 2004 Дэвид работал всего по 10 часов в неделю. Мы знали, что ничего не добьемся этими 10 часами, если не будем использовать их осознанно. Наш фокус на объеме, который надо уместить в рамки доступного времени, был рожден именно в этих ограничениях.

По мере роста бизнеса я начал расширять свои навыки. Работа с Дэвидом над Ruby on Rails сделала мир программирования доступным для меня. Я изучил подходы, которые помогают программистам определять сложность задач: такие вещи, как факторинг, уровни абстракции и распределение зависимостей. Стоя одной ногой в мире дизайна, а второй в мире программирования, я размышлял о том, можем ли мы применить принципы разработки ПО для проектирования и управления продуктом.

Первый концепт этой идеи появился в 2009. К тому времени мы наняли еще несколько программистов и вывели на рынок четыре отдельных SAAS-продукта. Мы хотели объединить наши продукты в один с общей авторизацией и оплатой. Это было масштабной технической задачей со своими «подводными камнями». Нам приходилось обрывать путь пользователя при использовании продукта и заставлять их менять свой логин и пароль по причинам, которые было трудно объяснить. Я выступал в ролях дизайнера и менеджера продукта в этом проекте и использовал методы, описанные в этой книге, чтобы управлять его сложностью.

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

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

Чтобы управлять этими объемами, мы переключились с проектной работы на повторяющиеся циклы. (Чтобы найти удобную продолжительность цикла потребовалось 6 недель экспериментов. Об этом позже.) Мы формализовали процессы и моя роль снова сменилась с дизайна на управление продуктом и стратегию. Мне нужен был новый подход, что-то вроде слова «Shaping», для описания предварительной проектной работы, которую мы проделывали, чтобы обозначить границы и снизить риски проекта до того, прежде чем мы примемся за работу.

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

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

Это кратко о том, что вас ждет в книге.

6-недельные циклы

Для начала, мы работаем циклами, длиной в 6 недель. Шести недель достаточно, чтобы разработать что-то ощутимое от начала до конца. Но и это достаточно короткий срок, чтобы держать в уме дедлайн. Большая часть наших функций разрабатываются и запускаются за один 6-недельный цикл.

Наше решение основано на развитии продукта в следующие 6 недель, а не на микро-менеджменте. Мы не считаем часы и не спрашиваем, кто сколько времени потратил на задачи. У нас нет ежедневных созвонов. Мы не пересматриваем наш роадмэп каждые 2 недели. Мы фокусируемся на более высоком уровне. Мы говорим себе: «Если этот проект запустится через 6 недель, мы будем счастливы. Мы будем знать, что не зря потратили время.» Затем мы выделяем 6 недель и не дергаем команду.

«Шейпинг» работы

Затем мы «шейпим» работу, прежде чем передать ее команде. Небольшие senior-команды работают параллельно c цикл-командами. Они описывают ключевые элементы решения до того, как мы возьмем проект в работу. Проекты прорабатываются на нужном уровне абстракции: достаточно подробно, чтобы команды знали, что нужно сделать, и в то же время достаточно абстрактно, чтобы у них было пространство для самостоятельной проработки деталей.

Когда мы «шейпим», мы меньше фокусируемся на оценке работ, а больше на наших хотелках. Вместо того, чтобы спрашивать, сколько времени нам нужно на выполнение этой работы, мы спрашиваем, сколько времени мы хотели бы потратить на это? Сколько стоит эта идея? Это задача «шейпинга», опустить проблему и предложить концепт решения, которое впишется в рамки наших хотелок.

Ответственность команды

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

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

Риски целеполагания

На каждом этапе процессы мы фокусируемся на определенном риске: риске не успеть сделать вовремя. Эта книга не про риск сделать неправильные вещи. Другая книга может помочь вам с этим (мы рекомендуем «Competing Against Luck»). Ваш навык определения правильных вещей придет после формирования навыка делать вещи правильно. Вы можете составить лучшую стратегию в мире, но если вы не сможете ее реализовать, какой в этом смысл?

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

Мы снижаем риски в процессе «шейпинга», решая открытые вопросы до того как мы зафиксируем сроки. Мы не даем проект команде, которая все еще распутывает остатки прошлого.

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

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

Как строится эта книга

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

Вторая часть про Отбор — как мы выбираем среди проектов те, которые будем делать следующие 6 недель.

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

Напоследок, в Приложении будут некоторые материалы, которые помогут вам запустить изменения в вашей компании. Это определенные советы, как запустить первый 6-недельный цикл, подсказки и адаптация методов под размер вашей компании и конкретное руководство по внедрению Shape Up с помощью Basecamp.

Часть 2 — Принципы шейпинга