程式碼之道

第3部分 (第3/4頁)

把一些資訊文件化，或者與其他團隊分享某個想法，那就寫一個白皮書。相對來說，這做起來也很容易，但能給作者和你的團隊帶來尊敬和影響力。

？ 反思職業生涯。最後但並非最不重要的一點，專案的這個清靜時期是你審視職業生涯現狀的最理想時機。你現在處在你理想中的位置嗎？你的職業生涯在向正確的方向前進嗎？你準備好迎接新的挑戰了嗎？你需要做些什麼，以使自己忙碌並並能富有激情？如果透過上述反思，你覺得必須改變一下，那麼，越早採取行動越好。

儉則不匱

差不多已經司空見慣了：產品的兩個版本之間的時間被不必要地浪費了。而實際在這段時間內做的事情常常還是有害的。其實，只需要一點點的想法和思考，你的開發團隊就可以在不帶來任何傷害的前提下，提高他們自身的能力，提高產品，提高他們的見解，乃至提高整個組織的效力。為你的“停工期”好好計劃一下吧，開足馬力勇往直前！

txt電子書分享平臺

為什麼我們會在這裡？

2004年6月1日：“我們開會的時候”

別浪費我的時間。拜託，請你不要浪費我的時間。也許我翻過桌子去用膠帶封住你的嘴，我才能避免眼睜睜地看著你浪費我生命中寶貴的60分鐘。召集一次會議怎麼能給人以權利去浪費別人的生命？如果時間是金錢的話，大部分會議都是不景氣的市場。我很厭煩那些可以把車快速開下懸崖、卻開不好一個會議的人。

我不想再參加這種會議了。如果你逼著我去一個會議室，請為我準備好，因為我會質問你想上演的任何“絕技”。你浪費我的時間，那我也要讓你的時間像火把一樣燃燒。不喜歡這樣嗎？別考驗我！我會質問你什麼呢？聽好了，因為下面就是……

我用來打斷你的自助式“聚會”的第一個問題是，“為什麼我們會在這裡？”我們聚在一起到底想幹什麼？有理由嗎？如果你沒有讓所有人清楚這個理由，大家可能會各有所想，並且像狗一樣追著自己的尾巴，結果自然是一無所獲。我不知道——也許你應該預先發一個議程，或者一些我們將要討論的文件？拜託你做點什麼！

如果你把會議的主旨作了通告，我可能還會提醒你，一定要堅持這個主旨！我不關心是否還有另外50個會議，去做另外的50個決定、討論另外的50個話題或者更多的資訊共享。我現在參加這個會議，我就只想專注於這個會議。如果有人想要談論其他的什麼事情，讓他在我們結束之後再上演他自己的秀吧！

作者注：如果有人試圖轉移話題，你該如何不失禮貌地打斷他呢？我喜歡的方法是，對他說：“讓我們先把這個話題討論完，然後再談你的話題。”通常情況下，當你結束了第一個話題之後，所有人都想離開了。那個會議干擾者將不得不另外安排一個會議，並且邀請合適的人參加（這樣要好得多）。如果那個干擾者堅持認為應該先討論他的話題，那麼首先討論他要這麼做的理由（這時候會議實際上仍然聚焦在原先的話題上）。如果理由很充分，那麼是你的會議時機還不成熟，因而是你的會議需要另行安排。在這種情況下，沒人會介意離開當前的這個會議。

我們正在試圖做什麼？

接下去，我的問題是，“我們正在試圖做什麼？”

？ 我們是在試圖做出一個決定嗎？很好，就讓我們做個決定，其他的像頭腦風暴、狀態檢查、流言澄清等統統跳過。

？ 我們是在試圖共享資訊嗎（比如一個狀態彙報會議）？很好，把資訊列表上的內容過一遍，但不要試圖去做什麼決定或者解決什麼問題。

？ 我們是在試圖收集想法嗎？很好，捕捉每個人的想法，無論它們有多荒誕都不要作出批評或論斷。最後，挑出其中最好的一個即可作為會議的成果了。

這裡的要點是，混合會議是低效的，常常會徒勞無功。大家都知道了為什麼會聚到一起來，也知道了會議正在試圖達成什麼目標。如果你必須中途改變這些前提，那你要深思熟慮之後，讓每個人都意識到，現在規則已經變了。否則，你會浪費所有與會者的時間，永無止境地糾纏不清，最後還不得不重新召開會議。如果你要這麼做，麻煩你不要邀請我。我不會參加的！

作者注：有個典型案例，就是在Scrum會議上提出設計問題來討論。Scrum會議是用於共享資訊的，不是用於收集想法或做決定的。沒什麼像設計討論一樣，不經意間就能讓Scrum會議脫離軌道。然而，因為設計討論