第一章 Introduction 入門¶
This book is a guide to how we do product development at Basecamp. It’s also a toolbox full of techniques that you can apply in your own way to your own process.
這本書是 Basecamp 產品開發方法的指南，同時也是一個工具箱，裡面充滿了各種技巧，讓你可以根據自己的需求靈活應用到自己的流程中。
Whether you’re a founder, CTO, product manager, designer, or developer, you’re probably here because of some common challenges that all software companies have to face.
無論你是創辦人、技術長（CTO）、產品經理、設計師，還是開發人員，你來到這裡，可能是因為遇到了所有軟體公司都必須面對的共同挑戰。
Growing pains 成長的陣痛¶
As software teams start to grow, some common struggles appear:
當軟體團隊開始擴大時，常會遇到一些共同的挑戰：
- Team members feel like projects go on and on, with no end in sight.
- 團隊成員感覺專案沒完沒了，看不到盡頭。
- Product managers can’t find time to think strategically about the product.
- 產品經理忙得喘不過氣，無法抽出時間從策略層面思考產品方向。
- Founders ask themselves: “Why can’t we get features out the door like we used to in the early days?”
- 創辦人不禁問自己：「為什麼我們無法像創業初期那樣快速推出新功能？」
We saw these challenges first-hand at Basecamp as we grew from four people to over fifty.
在 Basecamp，我們從四人小團隊成長到超過五十人時，親身經歷了這些挑戰。
Basecamp started off in 2003 as a tool we built for ourselves. At the time we were a consultancy designing websites for clients. Information would get lost in the game of telephone between the client, the designer, and the person managing the project. We wanted Basecamp to be a centralized place where all parties could see the work, discuss it, and know what to do next. It turned out lots of companies had this “information slipping through the cracks” problem. Today millions of people across all kinds of industries rely on Basecamp as their shared source of truth.
Basecamp 最初於 2003 年作為一個我們為自己開發的工具開始。當時我們是一家為客戶設計網站的顧問公司。在客戶、設計師與專案負責人之間的溝通中，資訊經常遺失。我們希望 Basecamp 成為一個集中式的地方，讓所有參與方都能看到工作內容、討論並了解下一步該做什麼。結果發現，許多公司都有「資訊從縫隙中溜走」的問題。今天，來自各行各業的數百萬人依賴 Basecamp 作為他們共享的真實來源。
Three of us built the first version. Jason Fried, Basecamp’s founder, led the design. His co-founder, David Heinemeier Hansson, programmed it (and created the well-known web framework Ruby on Rails as a by-product). At the time I was a web designer with a focus on usability and user interfaces. I executed Jason’s design direction for key features of the app and collaborated with him to fill in details of the concept.
我們三個人開發了第一個版本。Basecamp 的創辦人 Jason Fried 負責設計，他的共同創辦人 David Heinemeier Hansson 負責程式編寫（並且在此過程中創造了知名的網路框架 Ruby on Rails）。當時我是一名專注於可用性與使用者介面的網頁設計師。我負責執行 Jason 設計方向中的關鍵功能，並與他合作填補概念中的細節。
From the first prototypes in July 2003 to launch in February 2004, David only worked ten hours a week. We knew we wouldn’t get anywhere with those ten hours of programming unless we used them very deliberately. Our intense focus on “hammering” the scope to fit within a given time budget was born under these constraints.
從 2003 年 7 月的第一個原型到 2004 年 2 月的正式發布，David 每週只工作十小時。我們知道，僅靠那十小時的程式編寫，除非我們非常有計畫地運用，否則無法有所進展。在這樣的限制下，我們對於「壓縮」範圍以符合既定時間預算的強烈專注也因此誕生。
As the business grew, I started widening my skills. Working with David and Ruby on Rails made the world of programming accessible to me. I learned the techniques programmers use to tame complexity: things like factoring, levels of abstraction, and separation of concerns. With one foot in the design world and one foot in the programming world, I wondered if we could apply these software development principles to the way we designed and managed the product.
隨著業務成長，我開始擴展自己的技能。與 David 及 Ruby on Rails 一起工作，使我能夠接觸到程式設計的世界。我學會了程式設計師用來駕馭複雜度的技巧，例如：抽象化、分層處理和關注點分離。站在設計和程式開發兩個領域之間，我開始思考是否能將這些軟體開發原則應用於我們設計和管理產品的方式。
The first test of this idea came in 2009. By then we had hired a few more programmers and offered four separate software-as-a-service products. We wanted to bundle the products together into a seamless suite with single-sign-on and unified billing. It was a massive technical undertaking with treacherous user-facing flows. Besides getting the underlying architecture right, we had to interrupt customers on their way in to the product and make them change their username and password for reasons that weren’t easy to explain. I wore the designer and product manager hats on the project and prototyped the breadboarding and scope mapping techniques described in this book to manage the complexity.
這個想法的首次實踐出現於 2009 年。到那時，我們已經招聘了更多程式設計師，並提供了四個不同的軟體即服務（SaaS）產品。我們希望將這些產品整合成一個無縫的套件，並實現單一登入與統一計費。這是一個龐大的技術挑戰，還涉及到對使用者界面流的調整。除了確保底層架構的正確性，我們還必須在用戶進入產品過程中打斷他們，要求他們更改帳號和密碼，而這些變更的原因又難以解釋。我在這個專案中同時擔任設計師和產品經理，並利用本書中描述的麵包板（breadboarding）和範圍規劃（scope mapping）技術來管理這些複雜度。
We had such good results that we decided to apply the same techniques again in 2012, when we redesigned Basecamp from scratch for version 2.0. Again there was a lot of surface area to manage and again the process was surprisingly smooth.
我們取得了非常好的成果，於是決定在 2012 年再次運用相同的技術，重新從零開始設計 Basecamp 2.0。這次，雖然仍有大量的工作範圍需要處理，但過程依然出奇地順利。
By 2015, we had a core team that had lived through these experiences and hit an impressive stride. But we found it hard to articulate what we were doing to new hires. Our product team had quadrupled and everyone worked remotely. That made it hard to pass on our intuitions. We needed language to describe what we were doing and more structure to keep doing it at our new scale.
到 2015 年，我們擁有了一支經歷過這些挑戰的核心團隊，並且達到了令人印象深刻的工作節奏。然而，我們發現很難向新員工清楚表達我們的工作方式。我們的產品團隊已經擴大了四倍，且每個人都在遠端工作，這讓我們難以傳遞我們的直覺。我們需要一套語言來描述我們的工作方式，並且需要更多的結構來保持在新規模下持續運作。
To manage this new capacity, we switched from ad-hoc project lengths to repeating cycles. (It took some experimentation to find the right cycle length: six weeks. More on that later.) We formalized our pitching and betting processes. My role shifted again, from design and product management to product strategy. I needed new language, like the word “shaping”, to describe the up-front design work we did to set boundaries and reduce risks on projects before we committed them to teams.
為了應對這種新規模，我們從臨時專案時長轉變為重複週期的方式。（經過一些實驗，我們找到了一個適合的週期長度：六週。稍後會詳細說明。）我們正式化了提案和投注的流程。我的角色再次轉變，從設計與產品管理轉為產品策略。我需要新的語言，像是「塑形（shaping）」這個詞，用來描述我們在專案開始前所做的前期設計工作，目的是設定界限並減少風險，然後再將專案交給團隊。
Just as we were getting better at articulating the way we work to ourselves, more and more of our friends and peers started coming to us to ask how we do it. Finally Jason pulled me aside one day and said, I think you should write a book about this.
就在我們越來越能夠清楚表達自己工作方式的時候，越來越多的朋友和同儕開始來向我們詢問我們是怎麼做的。最終，某一天 Jason 拉我到一旁，說：「我覺得你應該寫一本書來介紹這些內容。」
This is the result. You can think of this as two books in one. First, it’s a book of basic truths. I want it to give you better language to describe and deal with the risks, uncertainties, and challenges that come up whenever you do product development. Second, the book outlines the specific processes we’re using to make meaningful progress on our products at our current scale.
這就是最終的結果。你可以把這本書當作一本包含兩個部分的書來看。首先，它是一本基本真理的書。我希望它能給你更好的語言，幫助你描述和應對在產品開發過程中會出現的風險、不確定性和挑戰。其次，本書概述了我們在當前規模下，為了在產品上取得有意義的進展而採用的具體流程。
Here’s a short overview of the main ideas in the book.
以下是本書主要觀點的簡短概述。
Six-week cycles 六週週期¶
First, we work in six-week cycles. Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely. The majority of our new features are built and released in one six-week cycle.
首先，我們以六週為週期來工作。六週足夠讓我們從頭到尾建立一些有意義的東西，並且短到足以讓每個人從一開始就能感受到截止日期的迫近，因此大家會明智地利用時間。我們的大部分新功能都是在一個六週週期內建成並發布的。
Our decisions are based on moving the product forward in the next six weeks, not micromanaging time. We don’t count hours or question how individual days are spent. We don’t have daily meetings. We don’t rethink our roadmap every two weeks. Our focus is at a higher level. We say to ourselves: “If this project ships after six weeks, we’ll be really happy. We’ll feel our time was well spent.” Then we commit the six weeks and leave the team alone to get it done.
我們的決策是基於在接下來的六週內推動產品進展，而不是微觀管理時間。我們不計算工作小時，也不質疑每一天的時間如何分配。我們不進行每日會議，也不會每兩週重新思考我們的產品路線圖。我們的焦點在更高層次。我們對自己說：「如果這個專案在六週後能夠交付，我們會非常高興，並且會覺得我們的時間得到了很好的利用。」接著，我們投入這六週的時間，並讓團隊自行完成任務。
Shaping the work 塑形工作¶
Second, we shape the work before giving it to a team. A small senior group works in parallel to the cycle teams. They define the key elements of a solution before we consider a project ready to bet on. Projects are defined at the right level of abstraction: concrete enough that the teams know what to do, yet abstract enough that they have room to work out the interesting details themselves.
第二，我們在將工作交給團隊之前，會先進行工作塑形。一個小型的高層小組與週期團隊平行工作。他們在我們考慮專案是否準備好開始時，先定義解決方案的關鍵元素。專案會在適當的抽象層次上進行定義：具體到足以讓團隊知道該做什麼，但也足夠抽象，讓團隊有空間自行解決有趣的細節。
When shaping, we focus less on estimates and more on our appetite. Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This is the task of shaping: narrowing down the problem and designing the outline of a solution that fits within the constraints of our appetite.
在塑形過程中，我們較少關注預估時間，更多關注我們的需求。與其問「這項工作需要多少時間？」我們問的是：「我們希望花多少時間？這個想法值多少？」這就是塑形的任務：縮小問題範圍，設計一個符合我們需求範圍的解決方案大綱。
Making teams responsible 讓團隊負責¶
Third, we give full responsibility to a small integrated team of designers and programmers. They define their own tasks, make adjustments to the scope, and work together to build vertical slices of the product one at a time. This is completely different from other methodologies, where managers chop up the work and programmers act like ticket-takers.
第三，我們將完全的責任交給一個小型的整合團隊，這個團隊由設計師和程式開發者組成。他們定義自己的任務，調整範圍，並合作一次建構產品的一個垂直切片。這與其他方法論完全不同，在那些方法中，經理會將工作切割開來，而程式開發者則像是接任務的工人。
Together, these concepts form a virtuous circle. When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously.
這些概念共同形成了一個良性循環。當團隊更具自主性時，高層的人可以花更少的時間去管理他們。花費在管理上的時間越少，高層的人就能夠塑造出更好的專案。當專案被更好地塑形時，團隊擁有更清晰的界限，從而能夠更加自主地工作。
Targeting risk 針對風險¶
At every step of the process we target a specific risk: the risk of not shipping on time. This book isn’t about the risk of building the wrong thing. Other books can help you with that (we recommend Competing Against Luck). Improving your discovery process should come after regaining your ability to ship. You can have the best strategy in the world, but if you can’t act on it, what good does it do?
在每個步驟中，我們都針對一個特定的風險：無法按時交付的風險。這本書並不是關於建立錯誤產品的風險。其他書籍可以幫助你處理這個問題（我們推薦《Competing Against Luck》）。改善你的探索過程應該是在恢復交付能力之後的事。如果你有世界上最好的策略，但無法付諸行動，那又有什麼用呢？
This book is about the risk of getting stuck, the risk of getting bogged down with last quarter’s work, wasting time on unexpected problems, and not being free to do what you want to do tomorrow.
這本書是關於卡住的風險、被上一季的工作拖住的風險、浪費時間在意外問題上的風險，以及無法自由地去做明天想做的事的風險。
We reduce risk in the shaping process by solving open questions before we commit the project to a time box. We don’t give a project to a team that still has rabbit holes or tangled interdependencies.
我們在塑形過程中透過解決開放問題來降低風險，這些問題需要在我們將專案分配給時間框架之前解決。我們不會將一個仍有未知問題或糾結依賴關係的專案交給團隊。
We reduce risk in the planning process by capping our bets to six weeks. If a project runs over, by default it doesn’t get an extension. This “circuit breaker” ensures that we don’t invest multiples of the original appetite on a concept that needs rethinking first.
我們在規劃過程中透過將專案時間限制在六週內來降低風險。如果專案超過了預定的時間，默認情況下不會延長時間。這個“斷路器”確保我們不會對需要重新思考的概念投入超過原先預期的資源。
And lastly we reduce risk in the building process by integrating design and programming early. Instead of building lots of disconnected parts and hoping they’ll fit together in the 11th hour, we build one meaningful piece of the work end-to-end early on and then repeat. The team sequences the work from the most unknown to the least worrisome pieces and learns what works and what doesn’t by integrating as soon as possible.
最後，我們在建設過程中透過早期整合設計和程式開發來降低風險。我們不是建立許多不連貫的部分，並期望它們在最後一刻能夠拼湊在一起，而是早期就先建構出一個有意義的完整工作部分，然後重複這個過程。團隊會從最不確定的部分開始，依次進行，並且通過盡早進行整合來學習什麼有效、什麼無效。
How this book is organized 本書的架構¶
Part One is all about Shaping — the pre-work we do on projects before we consider them ready to schedule. Each chapter explains a specific step of the process, from setting the appetite on a raw idea, to sketching out a solution, to writing a pitch that presents the potential project. Along the way you’ll learn specific techniques — like breadboarding and fat-marker sketching — to keep the design at the right level of abstraction.
第一部分是關於「塑形」— 我們在考慮將專案排程之前所做的前置工作。每一章節解釋了過程中的具體步驟，從為一個原始想法設定預期，到勾勒解決方案，再到撰寫提案來呈現潛在專案。在這過程中，你將學到具體的技巧，例如麵包板原型設計和粗線條草圖繪製，這些技巧能幫助設計保持在適當的抽象層次。
Part Two is about Betting — how we choose among the pitched projects and decide what to do six weeks at a time.
第二部分是關於「投注」(Betting)— 我們如何從提案的專案中選擇並決定每六週要做的事情。
Part Three is about Building — the expectations we place on the teams and the special practices they use to discover what to do. We’ll look at how the teams figure out what to do, how they integrate design and programming, how they track what’s known versus unknown, and finally how they make the hard calls to finish the project on time.
第三部分是關於「建構」— 我們對團隊所設定的期望，以及他們用來發現該做什麼的特殊做法。我們將探討團隊如何決定要做什麼、如何整合設計和程式設計、如何追蹤已知與未知的部分，最後，他們如何做出艱難的決定來按時完成專案。
Lastly the Appendix gives you some help for when it’s time to make changes at your company. There’s some advice on how to try your first six-week experiment, tips on adjusting the methods to your company’s size, and specific guidance for how to implement Shape Up using Basecamp.
最後，附錄將提供一些幫助，當你準備在公司內部進行變革時。裡面有關於如何嘗試第一次六週實驗的建議、調整方法以適應公司規模的技巧，以及如何在 Basecamp 上實施 Shape Up 的具體指導。