需求:當甲方說這很簡單,怎麼用這麼長時間?該怎麼懟他?


需求:當甲方說這很簡單,怎麼用這麼長時間?該怎麼懟他?

這是簽單前常見的場景,因為追加金額是根據工作量結算,也就是投入多少人天,客戶自然想少掏錢,恨不得你一天就幹完。客戶總認為做個接口或者程序上的改動就像往奶茶里加珍珠一樣簡單,加個珍珠有這麼複雜嗎?他需要一個解釋,那該怎麼辦呢?

在討論這件事之前,先看看需求是什麼?相信大家都瞭解馬斯洛五層需求理論,從最底層的生理需求到最頂層的自我實現,需求可大可小,可詳細可簡略。那麼需求的實現,需要多長時間?比如解決今天晚飯的問題,這個需求我們可以點個外賣,或者自己做著吃,馬上就可以解決。但是如果像解決自己的身材問題這樣的複雜需求,就會開始無從下手了,即使知道怎麼做也需要大量時間。

所以接下來以從軟件設計的思路來看看,如果甲方提出減肥是個“簡單”需求,讓你兩天搞定,這時你該怎麼懟他,以及你認為需要多長時間完成呢?

從軟件上說,需求是明確的對功能的需要。一般來說流程分為五步:需求、方案、開發、測試、上線。

但實際沒有想象中那麼簡單,需求出現後不應該立馬給出方案,因為一般提需求的人往往不明確,首先是背景(現狀)不明確,比如已知一個男生要減肥,要直接給出方案是不科學的。因為少了很多前提條件。比如這個男生的年齡、萬一是80歲呢?再有這個男生的身高,萬一是2米呢?所以這時候需要對需求進行提問,深挖(可以參考5WHY法)。接下來就是目標不明確,以什麼標準衡量呢?是根據體重多少斤還是能不能穿上M碼的衣服?所以優化之後的流程是這樣的。

需求——問題——需求——方案——開發——測試——上線

我們根據這幾個問題,得知男生的現狀以及目標,我們根據自身經驗幫助他補充信息後,這才找到了“明確的對功能的需要”。23歲身高1米8的男生張三,為了穿上M碼的衣服,希望減到標準體重66kg。

接下來就是方案了,從軟件角度看分總體設計、詳細設計、這裡就不展開寫了。那減肥的方案是什麼呢?知乎上其實有很多方案。總體設計就是管住嘴,邁開腿。詳細設計就比較麻煩了。根據MECE原則,第一層級可分為運動和飲食,那我們來到運動,第二層級運動可分為有氧和無氧,那我們來到有氧(假設只有跑步),第三層級有氧分為跑步前、跑步中、跑步後,那我們來到跑步前。第四層跑步前可分為時間、地點、人物。那我們來到人物。第五層人物分為別人和自己,那我們來到自己。第六層自己分為自身攜帶的物品(外在)和自身的狀態(內在),我們選擇自身攜帶的物品。第七層自身攜帶的物品分為全身衣著物品和其他物品,我們選擇其他物品。第八層其他物品分為耳機、手機、水杯,我們選擇手機。第九層手機就不用再細分了,找到適合自己的計步軟件,開啟GPS,準備計時即可。

一個方案文檔上萬字很正常,越複雜的項目字數越多,因為這些描述都非常必要,不可刪減。

接下來就是開發,比如買跑鞋,下載相關的手機應用。

接下來是測試,跑鞋合不合適,衝刺100米怎樣?跑2km怎樣?這個手機應用的實際效果如何?能不能提供有效數據?

最後是上線,這時候就會發現很多問題了。理論上前面都做好了上線不成問題,然而。。。跑步三天後腿疼?(方案沒做好:跑步姿勢、步頻、步速、跑鞋、距離完全沒有規劃。測試不到位:即使有了規劃,當發現方案不適合自己時,沒有進行調整)

所以這不是個簡單的事,就是要投入很多工作量以保證方案落地,最終才能減肥成功。甲方爸爸,可以籤合同了嗎?

這是一個神奇的男人,你完全猜不出他會寫出什麼,連他自己也不知道。感謝你的閱讀。


分享到:


相關文章: