How to Begin to Shape Up 如何開始 Shape Up¶

Option A: One six-week experiment 選項A：一個六週的實驗¶

You don’t need to change everything all at once. If the whole product team isn’t ready to make a big change, just start off with a single six-week experiment. These are the steps to take:

你不必一次改變所有事情。如果整個產品團隊還沒準備好做出重大改變，那就從一個單一的六週實驗開始。以下是需要採取的步驟：

Shape one significant project that can be comfortably finished within six weeks. Be conservative and allow extra time on your first run.
塑形一個可以在六週內輕鬆完成的重要專案。第一次執行時，請保守估計並預留額外時間。
Carve out one designer and two programmers’ time for the entire six weeks. Guarantee that nobody will interrupt them for the length of the experiment.
為整個六週時間，安排一位設計師和兩位程式設計師的時間。保證在實驗期間，沒有人會打擾他們。
Instead of a proper betting table, simply plan for the team to do the work you shaped for this one experiment.
不採用正式的投注桌，只需計劃讓團隊完成你為此單一實驗塑形的工作。
Kick off by presenting your shaped work to the team, with all the ingredients of a pitch. Set the expectation that they will discover and track their own tasks. (Hand Over Responsibility)
透過向團隊展示你塑形的工作來啟動，包含提案的所有要素。設定期望，讓他們發現並追蹤自己的任務。（移交責任）
Dedicate a physical space or a chat room to the cross-functional team so they can work closely together.
為跨職能團隊提供一個實體空間或聊天室，以便他們可以密切合作。
Encourage them to Get One Piece Done by wiring UI and code together early in the project.
鼓勵他們在專案早期將 UI 和程式碼連接起來，以完成一件作品。

You don’t need to worry about Mapping the Scopes or Showing Progress right away. You should see a big leap in progress just by dedicating uninterrupted time, shaping the work in advance, and letting the team work out the details.

你不需要立即擔心「映射範圍」或「顯示進度」。僅僅透過投入不間斷的時間、提前塑形工作，並讓團隊處理細節，你就會看到進度上的巨大飛躍。

Once the team gets used to Getting One Piece Done, the stage will be set for properly mapping scopes down the road. It’s the same idea, just repeated. Later still, when they are good at defining scopes, you can use the hill chart to Show Progress on those scopes.

一旦團隊習慣了「完成一件作品」，就可以為未來正確映射範圍奠定基礎。這是一樣的想法，只是重複執行。之後，當他們擅長定義範圍時，你可以使用山丘圖來「顯示這些範圍的進度」。

This approach lets you demonstrate success with one team and a single six-week commitment. With credibility gained from a good outcome, it’ll be easier to lobby for a bigger change and convert the wider team to working this way.

這種方法讓你透過一個團隊和一個六週的承諾來展示成功。透過良好的結果獲得的信譽，將更容易遊說更大的變革，並讓更廣泛的團隊以這種方式工作。

Option B: Start with shaping 從塑形開始¶

Sometimes it’s not possible to get a team together to work for six weeks because somebody else, a CTO perhaps, controls the programmers’ time. In that case, you can start by shaping a compelling project with clearer boundaries than past projects. Present the project and put it through your company’s existing scheduling process (even if it’s a paper shredder). Better-shaped work can shine a light on the engineering team and help them open up to things like longer cycles or a more deliberate betting process.

有時無法讓團隊聚集在一起工作六週，因為其他人，也許是技術長，控制著程式設計師的時間。在這種情況下，你可以從塑形一個比過去專案更清晰界限的引人注目的專案開始。展示該專案，並將其提交到貴公司現有的排程流程中（即使它像 paper shredder 一樣）。塑形更好的工作可以為工程團隊帶來啟發，並幫助他們接受更長週期或更慎重的投注流程等事物。

Option C: Start with cycles 選項C：從週期開始¶

Another approach is to start by working in six week cycles. For teams that formerly used two-week sprints, this removes the overhead of constant planning meetings and gives programmers more time to build momentum and hit their stride. Once the team has more room to breathe, it’ll be natural to think more about how to shape the work to take advantage of this new capacity.

另一種方法是從六週週期開始。對於過去使用兩週衝刺的團隊來說，這消除了不斷進行計劃會議的額外負擔，並讓程式設計師有更多時間建立動力並達到最佳狀態。一旦團隊有更多喘息空間，自然會更深入地思考如何塑形工作，以利用這種新產能。

Fix shipping first 先解決交付問題¶

Build your shipping muscles before you worry too much about improving your research or discovery process. You can have the best customer insight in the world, but if you can’t turn it into a project and ship, it won’t matter. First get the team into a rhythm of finishing things. Once you have the capability to ship, then you can start improving the inputs to your shaping process.

在過於擔心改善研究或發現流程之前，先培養你的交付能力。你可以擁有世界上最好的客戶洞察力，但如果你無法將其轉化為專案並交付，這就毫無意義。首先讓團隊進入完成工作的節奏。一旦你有了交付的能力，就可以開始改善塑形流程的輸入。

Focus on the end result 專注於最終結果¶

Sometimes it can be scary to give the teams more free rein to set their own tasks and schedule. You might wonder: What if they don’t use up all the time we dedicate for the cycle? What if one of the programmers or designers sits idle at some point in the cycle?

有時讓團隊有更多自由來設定自己的任務和排程可能會令人擔憂。你可能會想：如果他們沒有用完我們為週期分配的所有時間怎麼辦？如果程式設計師或設計師在週期的某個時間點閒置怎麼辦？

To overcome these worries, shift the mindset from the micro to the macro. Ask yourself: How will we feel if we ship this project after six weeks? Will we feel good about what we accomplished? When projects ship on time and everyone feels they made progress, that’s the success. It doesn’t matter what exactly happened down at the scale of hours or days along the way. It’s the outcome that matters.

為了克服這些擔憂，將思維從微觀轉向巨觀。問問自己：如果我們在六週後交付這個專案，我們會感覺如何？我們會對我們完成的事情感到滿意嗎？當專案按時交付，並且每個人都覺得他們取得了進展，這就是成功。在此過程中，以小時或天為單位的具體情況並不重要。重要的是結果。