需求方常常一句：「我想要做一個簡單購物車功能。」就把事情丟過來了。
開發者團隊只能默默地深呼吸，在心裡翻個小白眼，接著親切的詢問對方：「請問你他媽，呃，抱歉，請問你想像中的購物車是什麼樣子呢？」
談需求遇到的困難
通常需求方會希望可以用最快最便宜的方式完成需求，而開發方則會希望可以爭取更多的預算跟時間及人力。
需求方不能理解為什麼需要花這麼久的時間，為什麼這麼貴，為什麼要這麼多人。
開發方也不能理解，為什麼資源不給足，為什麼要一直壓榨我們。
所以談需求不只對需求方來說很困難，對開發方來說也很折磨啊～
其實談需求困難的原因在於，雙方對於同一件事的認知不同，尤其在需求範圍跟開發成本上，經常有非常大的分歧。
需求範圍
「我想要做一個簡單購物車功能。」「我想要一個簡單的XXX功能。」這些是很常從需求方口中聽到的說法。
對非開發人員來說，所謂的簡單，通常是指他們可以理解的事物，只要他們想像得出來的，就叫做簡單。
我只能說，說起來簡單，但做起來不簡單啊！
需求方甚至能夠說出「我想做出一個類似臉書的社群網站」、「我想做出一個類似Youtube的影音平台」，這對他們來說都叫做簡單，因為他們可以想像這是什麼東西（但是居然神奇地忽略所有細節）。
而這些在需求方想像中很簡單的功能，工程師卻總是回應：「沒有喔！這個要做很久！」然後大家大眼瞪小眼，開始討價還價。
其實不了解系統開發的人，通常會（故意？）沒有考慮到開發一個功能所需要的細節和流程，然而就是這些細節會花費掉所有的時間，不論是需求的細節，畫面的細節，後端邏輯的細節等等，所以他們才會誤以為開發很簡單。
例如，需求方想要一個簡單的購物車功能，但購物車不會只有購物車，購物車需要搭配結帳功能才完整，那付款方式會是什麼？是否需要串接金流API？可以跨店結帳嗎？非會員身份可以結帳嗎？等等，這些東西都加進來，就不是一個簡單的購物車了吧！
這邊指的需求範圍是：為了滿足這個需求，而開發的新系統，或者是舊系統的修改過程中，所有會變更到的畫面設計、程式碼、及機器配置
開發成本
前面的需求範圍的問題，會衍生出開發成本的問題。既然需求端無法想像這個需求範圍有多大，自然也無法理解開發這些功能需要的成本。
也許需求端都被那些神奇的廣告用語給欺騙了，好像用AI人工智慧就可以把程式碼變出來（好吧，至少2021年還做不到。）
但回過頭來面對現實，一個專案開發，不論是新專案或是既有系統維護，從需求訪談、設計規劃、開發執行、驗收測試，都需要時間跟人力，而這些成本完全取決於專案的範圍。
除了專案開始之前談需求很難同步認知以外，而專案開發最怕的就是中途的需求變更。軟體這兩個字，雖然有個軟字，但這並不代表它真的很軟，軟到可以隨便改變。
最常遇到的事情就是「這個改一下應該很簡單吧？」，然後搞得大家人仰馬翻。
這是因為非開發人員對於軟體的認知，通常僅停留在他們可以看到的部分，也就是畫面。
而他們常常用「投影片簡報」、「海報設計排版」，這種概念來想像或類比，因而覺得好像只是稍微移動一下圖片位置，或是調整一下用字，畫面就可以改變了，沒有什麼困難的。
我們很難要求他們想像，背後這些資訊跟邏輯，是怎麼組合跟流動，最後才呈現出他們看到的樣子。
如何改善？
需求方
學習相關知識
大家購買任何東西之前，總會上網看個評價或比價一下；出國自助旅遊之前，也會研究行程跟交通。
同樣的，花了一大堆資源去做一個系統，實在是沒道理不做功課吧？
所以我認為，如果想要做做資訊系統，需求方有義務去學習相關的知識，不一定要懂專業技術，但至少要理解軟體開發流程，或者乾脆找一個懂的人來處理。
總是用「你們是專業的，這些東西太複雜了，我不懂。」帶過，其實對雙方都是有害的。
一來是，在需求方不懂的情況下，很難掌握開發的實際狀況。
二來是，開發方總是被需求方弄得人仰馬翻，消耗資源，對整個專案來說沒有好處。
想清楚一點
提需求之前，要先想清楚一點。回到前面的購物車例子，雖然是一個簡單的購物車，但是每個人心目中的樣子都不太一樣。
如果可以事先把這些事情先稍微思考的深入一點，不求寫成完整的需求文件，或是有詳盡的流程圖，至少兩方對專案規模的認知會比較一致。
如果都沒有想過，一直用「這個應該很簡單吧」的心態，跟開發方溝通，很容易造成彼此不愉快。
開發方
多點耐心
雖然開發方可以要求需求方去學習相關知識，但是畢竟系統分析師、架構師、工程師們，才是開發上的專家，也才是真正在執行的人，所以專案開發上，還是需要技術人員的專業協助。
因此開發方可以多拿出一些耐心，用需求方可以聽得懂，可以理解的方式好好的說明。
「這樣的功能可能需要牽扯到DB欄位的變更，跟API資料格式的修改」，像這樣的敘述，很多需求方其實根本也聽不懂，也聽不進去。
所以為了溝通，我很常用其他東西來類比，來讓需求方可以想像，舉例來說，蓋房子的概念是我很常拿來用的，鋼筋水泥就是系統架構，畫面就是裝潢，我們可以改變裝潢，但很難把鋼筋水泥打掉。可是改變裝潢有時候也很困難，因為是系統櫃⋯⋯。
透過這樣的舉例，來讓對方理解，為什麼有些需求是困難的。
這樣的溝通，對雙方都有好處。
可以幫助需求方理解需求上的困難，也可以讓開發方省去一些事情，或是獲得更多資源。
結論
開發工作就是不斷地需求訪談、設計規劃、開發執行、驗收測試，如果可以有一個好的開始，就會有一個好的結束吧～
延伸閱讀：數位轉型過程中的溝通困難