AI 新聞與投資
啟示錄:打造使用者喜愛的產品

第20章 基本產品

19 / 41

Minimal Product 削減功能還是延長工期? 我號召產品團隊放棄老式的產品設計方式。比如,不再試圖定義最終產品,轉而定義只滿足基本要求(價值、可用性、 可行性)的產品,簡稱基本產品。一旦基本產品定義完成,通過了使用者測試,它就是一個不可分割的整體,去掉任何元素, 都不可能獲得預期的效果。 你見過這樣一幕嗎?產品經理製作了完善的產品說明文檔,詳細標註了各項產品功能的重要等級。然後,開發部門根據這份文件估算開發成本和開發時間。雖然剔除了開發團隊力不能及的功能,但得到的進度表還是比產品經理設想的多幾個月時間。於是雙方開始協商,先是爭論估算是否準確,然後不得不削減功能,縮小測試範圍,減少公開測試時間,要求僱傭第20童基本產品 | 123 額外的開發人員⋯⋯不知不覺時間已經流逝。我猜測你多半見過這一幕,即使沒有見過,也能猜到結果:最後開發出來的產品完全不是有機的整體,產品經理不滿意,開發人員不滿意, 使用者更不會滿意。很多團隊把這種情況看成理所當然的、不可避免的,其實這是不合理的流程造成的結果。因此,我建議採用另一種產品設計方式。 第,產品經理與設計師合作設計產品的高保真原型,這個原型只具備實現商業目標的最基本功能要求,以及良好的用戶體驗和吸引力。只設計基本功能的產品可以把複雜度降到最低,把開發時間減到最少,因而是非常重要的。 第二,邀請一位開發人員(比如架構師或主程式設計師)參與設計原型。請他檢查原型,幫助產品經理和設計師估算各種功能的直接成本和間接成本,指出設計上的誤區,並分析、評估尚不確定是否可行的功能。等產品原型確定時,他詳細估算出所有產品功能的時間成本。這樣一來,各項功能孰去孰留已經明瞭,而且對各方都是透明的,開發團隊心裡也有底了。 第三,請真實使用者驗證(測試)產品原型,這一點至關重要。在產品團隊全力開發產品前,產品經理和設計師必須確信產品是使用者需要的,然而僅僅相信還不夠,必須透過使用者測試來驗證。這好比不能僅僅因為開發人員相信程式碼沒問題,就允

124 | 啟示錄:打造使用者喜愛的產品許釋出程式碼一樣,必須對程式碼展開測試。 一旦基本產品確定,透過了目標使用者的測試,就不可能再削減任何功能。如果還能削減,那說明你定義的不是基本產品。 當然,根據產品原型估算的開發時間也不是完全準確,比如,對某些功能的開發時間的估計可能過於樂觀。如果出現這種情況,只能延長工期,不能削減功能,因為你已經沒有東西可削減了。儘管如此,由於估算的依據從一紙文件變成了精減功能的原型,精度還是大大提高了。即使延長工期,情況也遠沒有以前嚴重。 由於開發的是基本產品,一旦進入軟體開發環節,產品經理就不能再隨意修改設計。過去產品經理經常要求更改產品設計,主要是因為一開始構思不全面、不徹底。設計高模擬原型能夠迫使產品經理改掉這個壞毛病。 有人認為,類似 Scrum 這樣的敏捷開發方法可以用另一種方式解決這個問題。雖然我也建議大家採用敏捷方法(因為敏捷方法確實有其優點),但它並不能解決這個問題,反而可能帶來新問題。相關內容請參考第26 章。 因此,設計產品時一定要考慮哪些功能是最重要的,爭取設計出只滿足基本要求的、不可刪減的產品。就像我從前的老板常說的—一斷腿的狗打不了獵。

第21章產品驗證 Product Validation 證明產品的價值、可用性、可行性前幾章裡已經提到了產品驗證的概念。產品驗證是指在正式開發、部署產品前,驗證產品說明文件描述的產品是否符合預期要求。 過去驗證產品的代價不菲,而且困難重重。通常只有生產成本極高的產品才會這樣做,比如汽車。如今建立模擬原型的成本已經非常低了,如果還有不做產品驗證的團隊,我會感到非常驚訝。 產品團隊對自己的產品往往過於自信,不願意驗證產品, 只顧埋頭開發,總想等到公開測試時再收集反饋意見。毫無疑問,到那時再想大幅修改產品是不可能了,因此許多產品剛發布時表現得非常糟糕,這也不足為奇。

126 | 啟示錄:打造使用者喜愛的產品產品經理向產品團隊提供最終的產品說明文件前,需要進行以下三項重要的驗證。 可行性測試首先要明確在現有的技術條件下,能否成功開發出產品。 邀請架構師和開發人員深度參與技術調研,尋找可行的方案。 有些方案通向死衚衕,但總有些是可行的。 重點是讓開發人員尋找產品設計裡那些難以克服的障礙, 現在發現遠比損失了時間和資金後發現來得好。 有些產品的技術風險較大,如果你的產品存在可行性風險, 一定要提前解決這些問題。 可用性測試互動設計師應該與產品經理密切合作,想方設法突出產品的功能特性,讓不同型別的使用者都能明白如何使用。 可用性測試往往能發現沒能成功實現的產品需求,如果測試得當的話,甚至能發現原本被忽略的產品需求。最好規劃多次迭代測試,確保實現最佳的使用者體驗效果。 一定要請真實的使用者來試用可用性原型,從目標使用者那裡可以得到寶貴的反饋資訊。雖然產品經理和設計師也能從設計和使用原型的過程中掌握大量資訊,但這些都不能代替讓真實