在閱讀《啟示錄--打造用戶喜愛的產品》，作者說要在需求階段做好高保真原型，在實踐中的若干疑惑？

01-29

閱讀《啟示錄--打造用戶喜愛的產品》，作者說要在需求階段做好高保真原型，然後針對原型進行各種測試。這個道理我明白，要在開始的階段對各種不可控的因素進行最大限度的控制，而在後期大大的節省修改帶來的時間和人力成本，然而在實際的工作中似乎根本沒有時間去做詳盡的高保真原型，開發人員在拿到低保真之後也就開始進行相應的軟體設計工作。我想請問一下各位在實際的工作中都是在哪個環節對「不可控」進行有效地控制，本人產品新人一枚，望各位大神賜教。

昨天和產品解決方案中心的總經理中午吃飯的時候聊這麼幾個事情：

1、中國人做開發的時候，總是接到需求就開始做編碼準備，需求都沒整理完就開始做開發，需求細化與開發同步進行，結果工作經常推倒重來，開發模塊沒法細分，工作量難以分解，出來的東西經常都和一坨屎一樣。

2、國外的大型軟體公司（指歐美的），接到需求後，先花超過20%的事件細化需求，確認產品原型後再進行開發分解，然後再把分解後的工作量轉包給中國和印度公司編碼。

3、我有一個同學去了加拿大做PM，第一次接到項目預估開發量的時候，按照在國內的習慣加30%的事件估算出兩周左右的工作量，結果被PMO直接打回，要求調成1個月。

我只是想說，中國的軟體環境就是這樣了，這是甲乙雙方的問題：超低的預算、人力的限制、甲方工期預計上的不專業，導致了這麼一系列的問題的產生。即使，我們在開發初期把全部模塊的需求都確定並完成高保真，都很難保證在開發中期的時候甲方會不會進行改動，你的部門老大會不會改。在國外，這樣的改動要麼就是因為需求凍結的原因被打回，要麼就是另外再立一個附加項目把原來項目的資源重新調整；在中國，他們會要求你在原有資源進度的情況下進行改動，這不就是逼人加班么？

問題是，現實就是這樣，如果你先把東西都準備好了再進行編碼，事件100%來不及，所以只能需求細化與編碼同步進行，這就是殘酷的解決方案。

根據我一年經驗的專業畫圖仔的經驗：

1、在公司裡面，往往老闆早上丟了個需求過來，下午就又改變主意了；

2、往往開完評審會，又要各種修改需求；

3、往往開發過程中，發現我擦這個場景沒考慮到有問題，又要改需求；

綜上所述...原型圖能講明白想法流程就好..沒必要過分追求高保真

很多時候解決的不是需求而是領導的要求