Методология Shape Up: как перестать «тонуть» в задачах и начать выпускать качественные продукты 0:26
В условиях, когда традиционные подходы вроде Scrum и Agile часто приводят к бесконечным собраниям, нечетким оценкам и «зависанию» проектов, методология Shape Up предлагает иной взгляд на разработку программного обеспечения. Райан Сингер, соавтор подхода и ветеран компании 37signals (создателей Basecamp), в разговоре с Ленни Рачитски обсуждает, почему современные продуктовые команды теряют темп и как вернуться к эффективному ритму работы. Ключевая идея метода — переход от жестких дедлайнов к «аппетитам» на время и фокус на предварительном формировании (shaping) идеи до того, как она попадет к инженерам.
💡 Принципы формирования (Shaping) 15:20
Формирование — это интенсивный процесс, предшествующий разработке, цель которого — сделать идею настолько «острой» и понятной, чтобы инженерная команда могла взяться за реализацию без бесконечных уточнений.
- Работа от «аппетита»: Вместо того чтобы оценивать огромный концепт, команда определяет максимальный объем времени (например, 6 недель), который бизнес готов выделить на задачу.
- Гибкий объем: В рамках этого фиксированного времени команда варьирует объем функционала (scope), чтобы успеть создать что-то ценное.
- Итерации на доске: Shaping — это не написание длинных документов (PRD) или рисование пиксельно точных макетов в Figma. Это сессии у доски, где дизайнер, инженер и менеджер «прощупывают» задачу, чтобы увидеть её границы.
- Критерий готовности: Идея считается сформированной, если команда может описать её через ключевые движущиеся части (желательно не более 10) и все участники понимают, что именно нужно строить.
По мнению Сингера, основная причина провала многих проектов — нехватка деталей на этапе старта. Часто инженеры получают задачу, которая выглядит простой, но при попытке её реализовать обнаруживаются «бомбы замедленного действия» в коде, о которых не знали на этапе планирования.
🛠 Реальность vs Теория 31:23
Сингер подчеркивает, что Shape Up — это не «священное писание», которое нужно внедрять тотально. Многие команды совершают ошибку, беря из метода только 6-недельные циклы (или «спринты»), но оставляя старый процесс «шинковки» идеи на задачи (тикеты).
- Опасность «бумажного шредера»: Если менеджер «нарезает» тикеты, а инженер просто их исполняет, пропадает ответственность и вовлеченность. В Shape Up задача выдается команде как цельная концепция, а уже сама команда решает, как её разбить на задачи.
- Размер имеет значение: Идеальный момент для внедрения метода — когда компания сталкивается с первыми проблемами масштабирования (30–50 человек в продуктовой и инженерной командах), и основатели начинают замечать, что стали работать медленнее, чем когда были маленькой командой.
- Различия в контексте: Важно помнить, что Basecamp — уникальная компания с высокой концентрацией сеньор-инженеров и отсутствием отдела продаж, который давит на разработку. Не каждая компания может работать именно так, поэтому задача лидера — адаптировать принципы под свои реалии.
📈 Роль менеджера по продукту (PM)
В модели Shape Up фокус работы PM смещается. Вместо «мастера ритуалов» или человека, который занимается микроменеджментом внутри спринта, PM становится стратегом.
- Движение вверх по потоку: PM проводит больше времени, разбираясь в бизнес-контексте, потребностях клиентов и том, какая именно часть проблемы принесет наибольшую ценность.
- Переговоры: Вместо того чтобы просто собирать хотелки, PM «торгуется» с руководством о том, что реально достижимо в рамках отведенного «аппетита».
Сингер отмечает, что с развитием ИИ-инструментов, которые ускоряют написание кода, роль PM будет всё больше сводиться к тому, чтобы четко понимать, что именно стоит строить, так как «строительство» (реализация) становится всё более дешевым и доступным ресурсом.
