阿里妹導讀
本文深入探討了理解業務的重要性及其對於軟體開發流程的深遠影響。
一、什麼是業務？
業務是指一個企業或組織所從事的主要活動，包括生產、銷售、服務等方面的工作。簡單來說，業務就是公司或組織為了實現其目標而進行的各項活動和操作。在軟體開發中，理解業務意味著要了解客戶的需求和問題，並加以解決。只有深入瞭解業務，開發人員才能設計出更符合客戶需求的軟體系統。— 來自 ChatGPT
二、為什麼業務難以理解？
為什麼理解業務這麼難呢？個人理解有以下幾點原因：
1.透過上面對業務的定義來看，業務是一個非常籠統的概念，導致理解起來不是那麼容易。
2.俗話說：“隔行如隔山”。對於一些 C端業務還好，因為自己可能就是使用者，能夠更好代入業務，知道使用者需要什麼。而對於一些 B 端業務，往往個人很難深入接觸該業務，只能透過產品的需求來了解業務。
3.真實情況是，很多業務線，天天思考業務的業務同學都洞察不出業務真正的痛點，靠開發或其他角色去補位，絕大部分情況下就是個偽命題，“深入業務”很容易變成一句 PUA。
4.很多業務知識是需要日積月累的，大部分是以“年”為單位的。
三、我們需要理解業務嗎？
理解業務看起來是一個非常困難的過程，所以我們還需要理解業務嗎？回答肯定是不容置疑的。如果我們對業務沒有足夠的理解，肯定也就沒辦法支援好業務。
四、理解業務的優點
1.能夠幫助我們更清晰地理解需求，減少理解差異，減少返工。
2.能夠幫助我們去思考需求的合理性，以技術視角給出一些建議，幫助產品最佳化需求，這也是支撐好業務的基礎。
3.能夠幫助我們去發現更真實的需求，用專業的決策去支撐業務。
4.能夠幫助我們評估需求的優先順序，合理利用資源。
5.能夠幫助我們找到技術的發力點，使用合適的技術去高質量支撐業務。
6.更夠讓自己更有參與感，而不只是一個工具人。
理解業務的優點還有很多，這也是我們為什麼需要理解業務的原因。
五、如何理解業務？
說了這麼多，那麼到底怎麼去理解業務呢？上面說到業務是一個非常籠統的概念，所以要理解它肯定也不是一蹴而就的。理解肯定是從淺到深的，主要分為以下幾個層級：
(一) 理解實現
簡單來說就是拿到需求文件之後，我知道該怎麼去實現這個需求，比如用什麼技術棧？用什麼工具或元件？主要有以下幾個要點：
1.能夠根據需求文件梳理清楚需求，產品功能邏輯
2.知道具體該如何實現這個需求，是否有現成的工具或元件能夠支援。如果沒有，應該如何去調研？（這對於確定開發排期很重要）
3.梳理清楚需求後，可以再梳理下實現該需求都需要哪些介面
a.根據需求文件，梳理實現需求需要的介面；
b.確定介面的入參和出參（資料格式和欄位說明）；
c.介面的呼叫流程也要寫清楚；
d.和後端逐條核對介面，有問題的及時討論確定。定下最終的介面文件，前後端都需要嚴格遵守。然後就可以開始開發了（前端可以先根據介面文件 mock 資料）；
以上這些都是實現需求最基本的要求，能做到這些基本就可以順利的完成需求。但是為什麼會有這個需求？這個需求要解決的問題是什麼？有沒有更好的解決方式？這些就不在這一層的考慮範圍之內了，所以常常處於這一層的同學會覺得自己是一個工具人。
(二) 理解需求
在網際網路產品開發中，需求是指使用者對產品的期望和要求，包括功能需求、效能需求、使用者體驗需求等。通俗的定義是人們對產品的期望和要求。比如我餓了想吃飯，我想吃米飯，但是你給我一碗麵條，那就是沒有滿足我的需求。
如何理解需求，需要想清楚這幾個問題：
1.這個需求的使用者是誰？
2.這些使用者提出這個需求的場景是什麼？
3.這個需求能夠幫使用者解決什麼問題？
瞭解了這些之後我們可以將自己代入使用者視角，想想自己面對這個問題時，我的需求是什麼？我希望這個系統是什麼樣的，能幫我解決什麼問題？然後根據自己在技術方面的經驗和思考，給出一些意見和建議，將自己的理解融合到系統開發中。這樣就算是跨入了支援好業務的門檻：有參與，有思考，有理解
(三) 理解業務
理解了需求能夠讓我們更好地支援需求，但是能不能更好地支援業務卻不一定。因為業務是一個比較籠統的概念，不像需求那麼具體。即使做好了每一個需求，也不一定能做好這個業務。要想抓住業務的關鍵點，就需要更加深入地探索真實的業務。我們需要探究以下幾個問題：
1.這個業務的客戶是誰？使用者是誰？（客戶不一定等於使用者，使用產品和服務的是使用者，購買產品和服務的是客戶）
2.這個業務能夠解決客戶的什麼問題？能夠解決使用者的什麼問題？
3.這個業務能給公司解決什麼問題？能給公司帶來什麼價值？
如果能深入瞭解到這些問題的答案，那麼就可以從一個更高的視角來看待業務，知道業務的重心在哪裡，從而也就能知道該從哪個方向去促進業務的發展，在技術和設計方案上也能更加前置和全面地進行思考。
(四) 理解行業
1.瞭解這個行業的現狀，友商都有哪些，他們是怎麼做的？
2.瞭解公司在這個行業的佈局、優劣勢、目前所處的位置和戰略規劃等等。
六、其他思考
(一) 上下游質檢
一個產品往往是多個角色分工協作的產物，一般包括：業務方，產品，研發，設計，測試等等。一個產品做出來，業務覺得不好用，研發說產品需求和設計就是這樣，產品說業務提的需求不明確，業務說反正就是不好用。到頭來也不知道是誰的問題。
整個流程其實是環環相扣的，上游鏈路沒想清楚，下游跟著一起肯定也就走歪了，習大大說過“人生就像扣扣子，第一顆釦子扣錯了，下面的都會錯”。
所以對於上游鏈路的質檢就變得很重要。在傳統流水線作業中，下游必須保證上游提供的產物是符合要求的，否則就沒辦法繼續加工，如果每個環節的零件都是不符合要求的，那麼最終生產出來的產品肯定也是不合格的。
作為產品需要對業務方的需求進行質檢（去除不合理的需求，補充完善不清晰的需求，把抽象的業務需求具象化為產品能力）。
作為前端，我們需要對於上游（需求文件、設計稿、介面文件）進行質檢，才能確保我們在業務支撐中更加高質量、高效率地前行。那如何有效地進行質檢？就需要我們做到理解需求，理解業務。
(二) 幫助理解業務的方法
圓桌研發模式
圓桌研發模式是一種集體智慧和協作的研發方法，它強調團隊合作、資訊分享和平等參與，以實現高效的創新和問題解決。在這種模式下，團隊成員可以圍繞一個共同的問題或專案展開討論和合作，每個人都有機會發表自己的觀點和想法，同時也會受到他人的啟發和影響。舉例來說，一個公司的研發團隊在開發一款新產品時可以採用圓桌研發模式。團隊成員可以每週舉行一次圓桌討論會，共同探討產品的功能設計、技術實現、使用者體驗等方面的問題。每個成員可以就自己負責的部分發表看法，同時也可以提出對其他部分的建議或意見。透過這種方式，團隊可以充分發揮集體智慧，快速找到最佳解決方案，推動產品的迭代和最佳化。圓桌研發模式能夠激發團隊成員的創造力和合作精神，促進專案的成功進行。它也可以幫助團隊成員之間建立更加緊密的聯絡，提高協作效率。因此，這種研發模式在企業創新和專案開發中得到了廣泛的應用和認可。
讓開發人員參與業務部門的會議
這樣不僅提高了他們對業務需求的理解，還促進了技術團隊與業務團隊之間的溝通，從而提高了專案的交付效率和質量。
開發人員親身參與和體驗
開發人員也可以親身參與和體驗業務應用，觀察使用者是如何使用產品的，業務流程是怎樣運轉的。可能閱讀再多的檔案資料也不如親身體驗，親眼所見。
網際網路應用全球加速
網際網路應用加速解決方案面向各行各業的網際網路應用，提供一站式加速網路訪問、提高網路穩定性的服務。
點選閱讀原文檢視詳情。