快速響應階段最早是針對大眾網路服務的，因為大眾網路服務特別重視使用者的反饋意見。我相信它同樣適用於平臺產品、 基礎設施類產品、企業級產品。 即便建立了可靠的測試團隊，在正式開發產品前嚴格測試原型，你依然無法預料所有的意外情況，有些問題釋出後才會顯露端倪。你可以坐等問題出現，按部就班地安排在下次釋出時改進缺陷，但這樣做的代價太高。 關鍵不在於是否會出現問題，而在於能多快解決問題。 評估產品表現應該使用明確的、可量化的指標。你最關心產品哪方面的表現，是頁面訪問量、註冊使用者數、訪問停留時間、會員轉換率、訂閱數，還是廣告收益？具體使用哪些指標取決於產品的商業目標。應該給指標分出輕重緩急，並保持關注。此外，對於什麼樣的結果代表產品成功，什麼樣的結果代表失敗，應該做到心中有數。 如果產品是針對大眾的網路服務，追蹤使用者的使用情況從來都不容易。還好如今有專業工具可以協助追蹤使用者行為，例如谷歌分析工具（http://www.google.com/analytics）可以快速清晰地展現使用者使用網路產品的狀況。 如果是企業級軟體，我會派遣產品團隊成員（產品經理、 設計師、開發人員等）親自上門為客戶安裝軟體。這樣做總能迅速發現、解決問題，因為他們明白不安裝好產品就別想離開。
150 | 啟示錄：打造使用者喜愛的產品一旦問題反饋回來，產品團隊（產品經理、互動設計師、 主程式設計師、客戶服務人員、市場營銷人員等）應該至少每天召開一次簡短會議；討論問題的輕重緩急，確定最佳解決方案， 比如，透過網站釋出補丁，或是發表宣告公示處理辦法⋯⋯如果團隊事先做好心理準備，認識到快速響應階段的重要性，大幅提高產品或服務的質量便指日可待了。 除了使用網站分析工具掌握使用者行為外，還可以藉助問卷調查、郵件討論、留言板、現場測試等方式。我最喜歡察看網站分析工具提供的實時資料，例如，哪些頁面最受歡迎，使用者來自哪裡，他們在網站上停留的時間，兩次訪問的間隔時間， 還有頁面訪問量。此外，在快速響應階段，客戶服務人員、銷售人員和合作伙伴的意見也不容忽視。 跽驅第26章合理運用敏捷方法 Succeeding with Agile Methods 十大秘訣不少軟體產品團隊已經採納了敏捷方法，有些正在嘗試。 儘管敏捷方法（包括Scrum 和極限程式設計）有許多優點，但這類方法源自定製軟體（custom software）領域，不完全適用於開發產品軟體（product software）。許多產品團隊歷經磨難，才明白如何將敏捷方法應用到產品軟體領域。 本章介紹在產品軟體領域使用敏捷方法的訣竅。不瞭解敏捷方法的讀者，請參考 http://www.agilemanifesto.org。 注意這些訣竅只適用於產品軟體團隊，不適用於定製軟體團隊。
152 | 啟示錄：打造使用者喜愛的產品 1.產品經理即是產品負責人（product owner），他代表了客戶的需求，因而需要與產品開發團隊保持密切的聯系，協助督促開發程序，及時解決出現的問題。有些產品經理以為敏捷方法可以讓工作變得輕鬆，這是大錯特錯的。如果產品經理和產品負責人不是由一個人擔任， 通常會埋下隱患（參見第2章）。 2. 使用敏捷方法絕不等於省略產品規劃。產品經理仍然要明白產品的方向和目標，設定衡量產品成功與否的標準。只不過在敏捷環境裡，規劃週期應該適度縮短，反復迭代，採用輕量級的機會評估方法替代冗長的市場需求文件（參見第11章）。 3. 產品經理和設計師的工作進度應該比開發團隊領先一兩個迭代週期，確保你們有足夠的時間攻克難題。讓交互設計師和視覺設計師提前設計產品，充分發揮他們主導設計的作用，不能一邊設計一邊開發（參見第19章）。 另外，始終讓開發人員參與評估產品設計和產品原型， 及時反饋關於可行性、成本、解決方案的建議。 4. 儘量把產品設計工作拆分成獨立的部分，分而治之，但也不能拆得太細—好比設計建築不能一次只設計一個房間。目標是設計出符合基本要求的產品（參見第20 章）。值得注意的是，在敏捷環境裡，設計師必須加快第26章合理運用敏捷方法 | 153 工作速度，採用迅速製作原型的方法更能適應敏捷環境。 5. 產品經理的主要任務是定義有價值、可用的產品原型和使用者故事（user story），作為開發的基礎。用產品原型和使用者故事替代厚厚的產品需求文件和功能說明文件有三個優勢：①可以請使用者測試；②強迫產品經理全面認真地思考問題；③向開發團隊明確地描述每次迭代周期需要完成的任務。請使用者測試原型，根據反饋意見反復迭代修改原型設計，確保交給開發團隊的是有價值的結果，避免任何浪費，哪怕只是一個迭代週期。 6. 讓開發人員自主劃分迭代週期。有的產品功能可以在一個迭代週期完成，有的卻需要好幾次迭代才能完成。好的原型可以提高估算工作量和開發時間的精度。別忘了，開發團隊必須考慮產品的質量、效能、擴充套件性，應該讓他們自行決定如何劃分迭代週期。 7. 產品經理和互動設計師必須出席每天的晨會。晨會是一天溝透過程的開始，而不是結束，關於產品的討論會持續一整天。設計師向開發人員和測試人員展示產品功能： 開發人員互相展示完成的程式碼，讓測試人員測試，請設計師和產品經理過目；測試人員和開發人員在製作原型的階段識別潛在的問題，協助產品經理制定更合理的決
154 | 啟示錄：打造使用者喜愛的產品策，解決產品設計、開發的問題。 8.除非達到了產品經理的要求，否則不要輕易釋出新版本。產品經理必須確保交給使用者的產品能正常執行。過度頻繁更新版本會讓使用者感到不安（參見第24章）。 9. 在每次迭代完成後，產品經理應該向團隊展示產品現狀，以及下次迭代的產品原型，讓大家看到工作成果， 同時加深大家對產品的理解，增強團隊對這種開發方式的信心。 10.在團隊內展開敏捷培訓。聘請敏捷顧問協助你們完成向敏捷團隊轉型的目標，但是要確保敏捷顧問有過類似的工作經驗，理解產品軟體與定製軟體的差別。只有每位團隊成員都真正理解敏捷方法，你才能把工作重心放在執行上，否則敏捷方法就只能停留在教條式的理論層面。 跽驅第26章合理運用敏捷方法| 155？ 選代初期開發的產品能用做原型嗎？ 有些敏捷方法的倡導者和實踐者認為開發團隊可以把迭代初期開發的產品當做產品原型用。這種做法也許適用於定製軟體，畢竟定製軟體不需要我所說的產品管理， 也少有使用者體驗設計，然而，這種做法對產品軟體是行不通的，原因如下。 第一，用一個迭代週期來驗證產品創意（通常存在缺陷）時間太長。花幾個月時間驗證生產中的產品與用幾天時間驗證可更改的產品原型相比，後者效率顯然更高。 第二，在探索（定義）產品的階段，開發團隊還有許多重要的工作要完成。如果這時佔用開發團隊的時間開發產品原型，會消耗他們開發正式產品的精力。 第三，儘管敏捷方法鼓勵開發團隊不斷學習，快速反應，可一旦進入開發階段，設計出軟體架構後，再想改變產品設計思路，對開發團隊來說，無論是成本還是難度都太高了。
156 | 啟示錄：打造使用者喜愛的產品？ 敏捷方法可以用來開發產品軟體嗎？ 像 Scrum 這樣的敏捷方法的確解決了許多困擾軟體團隊多年的問題，但是多數產品經理、使用者體驗設計師、 測試人員，對敏捷方法持懷疑態度，不確定自己應該扮演什麼角色。毫無疑問，實施敏捷方法絕對離不開這些人， 出現這種情況是因為“原始”的敏捷方法並不適用於研發產品軟體。我發現解釋敏捷方法的起源可以幫助人們理解它的適用範圍。 Scrum 於1986 年誕生於日本，距今已有二十多年的歷史，許多人對此感到驚訝不已（這又一次證明了，新觀念要經過很長時間才能被人們廣泛接受）。值得注意的是， 這些方法起源於定製軟體領域，而不是產品軟體領域。 長久以來，開發定製軟體困難重重。原因之一是，雖然需求確實存在，但客戶通常不知道自己想要什麼。他們與軟體公司簽訂合約，把自己的需求告訴開發人員，由開發人員自行開發。等到交付軟體時，客戶往往發現到手的軟體和想象中的相差十萬八千里，於是又要求開發人員修改，如此惡性迴圈，客戶屢屢失望而歸。但是由於剛性需求一直存在，所以開發人員、軟體供應商、相關專業服務機構不必擔心沒有生意做。
第 26 章合理運用敏捷方法 | 157 另外，定製軟體領域長期以來很難招聘/留住頂級的程式設計師。部分原因是頂級的程式設計師更喜歡為成千上萬的用戶開發產品軟體，因而選擇在產品軟體公司工作。而且產品軟體公司能提供更具競爭力的薪資待遇。產品軟體公司必須開發出滿足大眾需求的產品，否則就得關門大吉，他們懂得只有用高薪吸引頂尖人才，推出優質的產品，才能獲得高額利潤。所以，多數資質普通的程式設計師留在了定製軟體領域。 定製軟體的客戶認為自己瞭解自己的需求，所以不需要什麼產品經理。他們也不需要使用者體驗設計師，這個原因更復雜，主要是客戶不理解什麼是使用者體驗（在定製軟體領域幾乎沒人認識到使用者體驗的重要性），以及對成本過於敏感（讓開發人員設計產品可以節約成本）。另外，使用者體驗設計人才極度短缺也是不能忽視的原因，即便定製軟體公司意識到使用者體驗的重要性， 也很難招聘到合適的使用者體驗設計師，因為他們早就被當成“香餑餑”被少數幾家大公司搶去了。同樣，定製軟體專案裡也鮮見測試人員，本該由他們完成的測試工作都被開發人員包攬了。 定製軟體的另一特點是大多數專案規模較小，一般用
158 | 啟示錄：打造使用者喜愛的產品來支援公司內部運營，比如人力資源、財務、生產系統， 有限的使用者數量使得可擴充套件性和效能表現通常不受重視。 以前，定製軟體領域常使用瀑布式開發方法，這樣做是為了便於客戶監督漫長的開發過程。實際上，瀑布式開發方法也同樣源於定製軟體領域。 產品軟體必須在各方面都儘量做到完美，才能贏得市場。所以必須由產品經理負責收集廣大使用者的需求；由用戶體驗設計師創造完美的使用者體驗；由測試人員測試產品，保證軟體可以像廣告裡說的那樣正常執行。 敏捷方法極大地提高了開發定製軟體的效率：增進了客戶和開發人員之間的交流；透過更頻繁的迭代來大幅度降低風險（客戶可以更早看到階段性的產品，再不必等到整個開發過程結束）；引進了現代軟體測試的理念；省去了撰寫連篇累牘的產品說明文件的麻煩（這些文件實際上少有人閱讀，很快就會被束之高閣）。 我認為敏捷方法同樣適用於產品軟體的開發，但應用時應該做出相應的調整。我曾經寫過相關文章（如何在開發過程中加入使用者體驗設計，如何管理產品的釋出和部署）。敏捷方法唯一不適合產品軟體開發的地方是在架構設計方面。