不一致的溝通
需求確認的流程，資訊是不對稱的，開發團隊會以技術面以及以往的專案經驗去思考需求；客戶會從生活經驗中去思考需求，可能看了某新聞報導人工智慧用在商業決策上，大型購物平台提供了完整的金流與物流服務累積了一些對資訊技術的認知，綜合自身的商業策略、願景、業務、產品、市場去思考需求。
客戶可能在技術可行性上的認知不足，導致想法天馬行空，開發團隊也可能不了解顧客群的特性與產品的核心價值，設計了複雜而不實用的產品，產品負責人與雙方的溝通可能有誤差，導致需求認知不一致。
基於mockup去規劃與設計功能需求
也因此我傾向於先透過第一手的溝通內容，先萃取初期的需求，透過user story去描述需求，
但這樣的user story所能提供的需求規格不週延，遺漏了許多細節
為了替模糊的需求畫上明確清晰的輪廓
我會根據user story去設計mockup，讓開發團隊、Project Owner、利害關係人可以直接以使用者操作的角度去思考需求
mockup是樣板模型或草圖，我目前是使用mockups balsamiq這套軟體來作mockup
基於mockup去規劃與設計功能需求，這樣能在前期降低許多溝通成本與往後的修改成本
藉由mockup，大家有一個共通的參考依據，能夠把每個user story切割成更精確而周延的task，再一一去實作它們
藉由mockup，大家可以明確的知道應該多加什麼功能？還少了什麼？
製作mockup的時機
不過也不是每次都需要設計mockup
設計mockup也會形成時間成本與人力成本，參考上圖，當需求的明確性高的時候，我們設計mockup的成本會很高，也就是我們很肯定需求是什麼了，設計mockup反而是多此一舉，是一種浪費，比如說像是會員管理系統，已經是一個很制式的功能了，我們還得花時間去畫管理員的操作介面，使用者的操作介面等等數十張的mockup，然後去跟客戶溝通，顯然是多餘的，倒不如先做出來，直接請用戶去操作，因為它的修改成本很低，頂多用戶要求要有特殊的欄位，例如要有Line ID之類的問題。
而一些客製化的功能，如果不先製作mockup，到後面反而會發生很多問題，客戶會覺得我們設計的系統跟他當初講的怎麼差這麼多。這時候若在開發前花點時間去製作mockup反而能幫助我們降低往後修改系統的成本，是一個很棒的投資，能讓我們取得更多的客戶回饋資訊。
End
沒有留言:
張貼留言