假如現在你有一些不錯的想法，雇用了一個工程師把想法實體化，
隨著時間過去，你發現有一些項目需要調整、功能範圍慢慢擴大，
最後這個專案一發不可收拾，一步步吞噬你的生活。
為什麼會這樣？
不一定是因為工程師不夠專業、也不一定是因為你對專案管理一竅不通、亦或是這個想法就是糟糕 ;
其實都是因為一些小小的誤會，讓專案在一開始就注定了最終的毀滅：
我們會以為產品是由一些功能所組成，
這些功能中有一些被否決，或是有其他功能加入，
所有的功能在白紙上清清楚楚 ;
其實這樣的想法是錯誤的，
你的專案不是一張白紙就能一目瞭然，它是有深度的。
線上圖書館終結實體圖書館
來看一些具體的例子，
這是一個新的專案想法：
很多人常常需要圖書館中沒有的書籍，當有人可能擁有這本書時，
需求者透過 app 發出請求，對方就會回應，而我們從每筆交易中抽取一些利潤。
功能列表非常簡單：
把產品規格傳給工程師後，幫這個 app 想一些殺手級的名字。
kaBooki？lib.rari.ly？hubsoda？
已經有人用了 hubsoda 這個名字了。
那我們可以思考一些需要解決的問題...
Q:
用戶要怎麼付款？
直接面交付現嗎？還是通過 app 付款？
A: 他們應該透過 app 信用卡付款，這樣我們才能從中收取費用。
Q:
用戶如何找書？
他們在 app 上需要做什麼樣的動作找書？
填寫書名和作者的表格嗎？
A: 他們應該用搜尋的方式找到書籍。
...所以我們需要一個書籍數據庫。
Q:
書籍的需求有哪一些？書商看得到所有書籍的列表嗎？
或者，我們和 Uber or Thumbtack 一樣向賣家發送通知呢？
A: 我們向有這本書的人發出請求
Q:
那麼，賣家需要把所有的書籍都放到 app 上嗎？
A: 嗯，沒錯。
Q:
怎麼運送這本書？用戶自己寄出，還是我們來處理？
A: 我們來處理。
Q:
所以你需要一個系統，告訴你需要拿取的書籍和目的地？
A: 不要好了，讓用戶將書寄給對方。
Q:
我們傳送收件人的地址給送件人嗎？如何處理運費？
A: 這些用戶必須住得很近。拿到書後，順便交一個新朋友？
Q:
所以，我們需要配對附近的用戶。
他們如何找到對方？app 上有即時的地圖可以安排見面嗎？
我們設定書的價格？還是他們自己討論價格？
A: 他們自己決定價格。
Q:
他們怎麼決定？app 上需要有聊天室嗎？
A: 他們可以打電話聯絡。
Q:
我們需要用簡訊驗證該號碼嗎？
這些問題會無限的延伸下去...
讓我們來看看功能列表現在的樣子：
列表中的每一個功能都可以再繼續延伸。
讓我們來釐清功能爆炸的原因...
這不是一般我們稱的特徵蔓延(feature creep)
最終功能列表裡的每個項目都是為了支持一開始的想法，
而不是將新功能不斷添加到產品之中。
跟技術上的考量無關。
這跟哪一些付款平台可以簡單融入 app 中沒有關係。
工程師可以建議你該用哪些技術，但是他無法決定你需要什麼功能。
也和市場上的考量無關。
你還在想會有人要用這個產品嗎？
實際上這些問題都只是用來驗證你的想法、
確定產品適不適合市場、還有了解定價策略，
沒辦法告訴你功能列表為什麼會多到爆炸。
我們都誤解了複雜性該怎麼運作。
我們以為每個功能和一開始描述的 “線上圖書館範例” 一樣複雜，
但這個觀點是錯誤的。
App 裡的功能就像地圖
越近看，就發現越多細節。
當我們建立或是在使用一個 app 時，規模還很小 ;
一個完整的 app 是需要經過一步步的試驗，
每一個階段你會發現一些問題，
接著你必須重新設計、加入新的步驟，或是加入新的功能。
就像你在規劃路線，在地圖上看起來是一條直線，
如果考慮到細小的部分，你會發現這條直線上還有幾個轉彎的街區和紅綠燈 ;
不同的通勤方式，路線又會不同。
建構一個軟體的時候也是一樣，
放大看後，你才會知道解決的方法。
那這樣我的產品會不會沒有完成的一天？
我們的目標是敘述功能，它通常都很複雜。
為了這個目標我們仔細看過每一個步驟，
越仔細看就會發現更多的問題。
複雜不是主要的問題，問題是我們要怎麼發現這些功能上的問題，
我們把產品規格交給工程師，一週後我們拿到初版的成果。
第一次使用的時候，我們一步步走過整個程序，發現了巨大的漏洞、
紀錄需要修改的地方，接著給工程師建構第二個版本。
經過幾次這樣的過程後，我們有了很好的解決辦法 ;
麻煩的地方在於往返的週期太長，每一個循環都為期數週或好幾個月。
這種複雜的流程是有必要的，
但是不停在工程師身邊周旋很耗時、成本又相當昂貴。
我們應該這麼做：
在我們編寫一長串的程式之前就要盡可能發現 app 中更多複雜的地方。
我希望利用最快又低成本的方式，一步一步建立更強大的功能列表，
我們寧願在規格上反覆修改，也不要在整個 app 的修改上花太多時間。
千萬不要走以下的流程：
而是走這樣的流程：
要有效的走過整個流程，我們需要兩件事。
第一，呈現功能列表，才可以重複過程。
第二，有效審問已建立的功能列表。
那麼我們怎麼做到呢？
將功能繪製出來
不要用商業的角度思考，以使用者的角度去思考。
1
首先，列出用戶目標，使用者在使用這個 app 的目的是什麼？
2
接下來，繪製出使用者的流程。
走過使用者達到這個目標前的每一個步驟，將它記錄下來。
3
你可以繪製 mockups ，紀錄使用者瀏覽的每一個介面，
也可以用一張紙或軟體繪製流程圖。
不管用哪一種方式，記得你的速度一定要快！
每一個介面都要在大綱上。
假如有一個步驟會出現在不同的介面上，就要據實的將它們一一分散畫出來，
我們需要更多細節！
光是這個過程就可以把 app 上零碎複雜的小東西都浮出檯面。
接下來我們來深入了解一些問題：
質疑所有的東西
像上面提到的問題比較偏向開放式的結果，我們很難知道要從哪裡開始。
這裡列出了適用於大多數軟體的常見問題列表 ;
問題分為四大類，讓你從大綱裡挑出問題。
看大綱中每一個步驟，套用列表中的問題，
如果這些問題可以延伸出新的步驟，把它添加在大綱上。
列表如下：
1. 用戶輸入
這些問題涉及範圍從用戶到產品。
開放式例子：自由輸入文字的形式、選擇要上傳的圖片、錄製影片。
互動式例子：將文字輸入到搜尋欄、顯示可以選擇的結果、在地圖上選擇地址、從預定選項中挑選。
2. 呈現給用戶的訊息
3. 使用體驗之間的交流
這些問題是關於用戶、產品、其他服務之間如何互相交流。
4. 企業所有者需要的功能
企業主需要從產品中獲得什麼。
全部整合在一起
建構大綱和審問的過程讓你知道 app 中少了什麼東西。
重複這個過程幾次，你就會有信心可以獲得一個非常穩定的功能列表。
聽起來很複雜吧？但你在某個工作階段上一定會碰到這些問題。
軟體的功能隱藏著很多複雜性，找出來，然後解決它們！
你現在有兩個選擇：
第一、發現用戶目標，建構模型或流程圖、質疑自己的假設，一步步揭開所有的問題。
第二、讓工程師開始建構你的app，每一個問題都花費一週的時間。
幾個月後，你會發現你可以用鉛筆和紙在一周內發現完全相同的東西。
找出每一個功能、建立大綱、並質疑你的假設。
快速的發現大部分問題，節省自己的壓力和痛苦，
將你的產品公諸於世，期待美麗的收穫吧！
