起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識為什么說B端SaaS產品經理需要讓研發團隊懂業務？
編輯導讀：想要做好一個產品，光靠一個人孤軍奮斗是沒用的，合適的團隊才是最重要的。而團隊對業務了解得更多，也就更有利于業務的順利開展。本文作者梳理總結了讓研發團隊快速熟悉業務的幾個方法，供大家一同參考學習。
01 前言
我們奮戰數天做出來的需求，研發同事會覺得不可理喻；
功能已經實現出來后，才發現需求或代碼設計上有錯誤，得花費額外的時間修改，甚至是重構，導致迭代延期；
大多數產品經理應該都遇到過以上情形，這些情況的出現無疑會增加我們的時間成本。
排除團隊成員技能因素，如果經常遇到以上的情況，也許我們首先需要思考的是，團隊成員足夠理解了產品業務嗎？
有人說，研發人員只需要按照產品給的需求實現即可，只要技能足夠厲害就好，并不需要懂業務。
當然這樣做也能讓團隊最終完成工作，只不過，懂業務的團隊會完成得更好，就像一份美味的菜肴，掌勺的廚師在制作菜品的時候，也提前對顧客口味有過充分的了解。
02 為什么需要讓團隊成員理解業務？
隨著在B端SaaS領域做得越久，筆者越來越多地遇到因團隊成員不懂業務，而使研發實現上出現問題的情況，也越發深刻地認識到讓研發人員懂業務的重要性。
做產品并不是一個人的戰斗，我們需要充分激活團隊的力量，團隊理解業務后將會給產品經理的工作帶來額外的增益。
1. 把關需求，減少錯誤
B端的SaaS產品經理需要為用戶設計完整的功能方案，如果功能上線后發現設計方案有缺陷，可能會給企業用戶造成經濟損失，即便是輕微的問題也會降低用戶對平臺的信任度，影響下次續費。
一個熟悉業務的設計、研發團隊，在一定程度上能夠幫助產品經理發現設計方案的缺陷。開發中有一個環節是開發之間互相進行代碼走查，與這個類似，團隊成員對業務熟悉后，在評審和實現的過程中，也能覺察產品的需求方案有沒有不符合業務場景的地方。
例如以下情景：
某租房APP要實現電子發票功能，產品經理小明設計的方案是，用戶支付成功后即可開發票，工程師A覺得電商平臺一般都是這樣，拿到需求就開始做了。
然而，此時工程師B提出了質疑，假如支付的是租房押金，也允許開具發票嗎？
小明反應過來，自己漏了這個場景，實際情況是押金在財務上是不開發票的，小明非常慶幸這位工程師及時提出了質疑，避免了后面上線后再發現問題。
上述情景中，工程師B至少知曉了2個業務知識點，才得以及時發現了這個問題，其一，是知道租房APP中是有押金繳費的；其二，知道押金在財務上不予開具發票。
假如按工程師A的做法，拿到需求后就去開發，那么很有可能上線后會造成事故，不該開票的訂單開出了發票，給財務同事的工作帶來不必要的麻煩。
事故出現后，責任并不在開發同事的身上，而是因為產品經理沒有把場景考慮完整。
誠然，一個合格的產品經理在設計需求時必須要考慮完整的場景閉環，不出紕漏，但實際情況是，我們沒辦法確保每個需求都能考慮得詳盡周到。
相信很多產品經理都有過情景中類似的經歷，事后在心里會非常感謝某個研發在進入開發前，及時指出了需求中未考慮到的業務場景。
視覺、研發實現需求的周期通常會比產品設計階段的周期更長，也就是說，他們比產品經理接觸需求的時間通常會更多，如果需求設計有缺陷，懂業務的團隊成員大概率會察覺到問題，在上線前就提出來，產品經理能及時調整方案。
所以，假如團隊成員也熟悉業務，能夠讓我們的工作避免發生許多不可挽回的錯誤。
2. 理解需求，降低溝通成本
產品經理幾乎每天都要與團隊成員溝通，大家都希望自己提出來的需求團隊成員能夠快速理解，以減少在溝通上所花的時間。
而讓團隊成員熟悉業務，就是一項行之有效的方法。
因為B端產品的需求是基于實際業務場景產生的，而實際業務經常會有一定復雜度，不太容易理解，所以團隊成員在評審和實現的過程中可能產生不少疑問，如果熟悉業務，他們就能夠站在實際業務場景中去考慮，減少因業務不熟而提出的疑問。
情景：
一次需求評審會上，產品經理小明講到，要增加修改訂單的功能，且已支付訂單的支付時間也可修改，研發同事一致認為，這個功能不合理，市面上哪有產品允許修改支付時間的，都是根據實際時間來取值，這樣做不符合規范。
小明講解到，是因為有部分房租是通過線下收到的費用，管家收到錢后會錄入到系統，但有時候會錄錯，需要將支付的時間改為實際收款的那天。
大多數研發聽到這后點了頭，但研發A這時提了個疑問——
研發A：“不改時間也不會有什么影響吧，金額是對的就行了?！?/p>
小明：“財務每月做賬時，報表的金額數據對應的日期必須為真實收費的日期。如果時間改成了在對應賬單月份之后的月份，就在報表里面歸到補收統計，反之，則歸到預收統計?！?/p>
研發A：“什么是補收和預收呢？”
小明：“補收就是收的往月的費用，預收就是提前收以后的費用?！?/p>
研發A：“這樣隨便改時間的話就統計邏輯就復雜了，不太建議這樣做?！?/p>
小明：“…”
類似的情景我們經常會遇到，產品解釋后，三兩句說服了還好，如果說服不了，還會繼續pk幾十分鐘，也許到了開發階段還得解釋，溝通成本很高。
情景中都是平臺上經常發生的業務，如果小明詳細講解過，研發A就會知曉在真實的業務場景中，管家可以在線下收費然后錄到系統，且財務需要按真實收費的時間來統計補收、預收等數據，那么就能理解這個需求的合理性，降低溝通成本。
03 怎樣講解能讓團隊快速熟悉業務？
團隊成員合作的越久，對業務會越熟悉，在沒有專門講解的情況下，這個過程可能需要半年甚至更長。我們都希望每個成員剛加入團隊，就能對業務足夠了解，讓項目高效運轉。
所以對團隊成員進行業務培訓存在著很高的必要性，那么怎樣講解才能讓團隊成員快速熟悉業務呢？有以下兩個方法可供參考：
1. 帶入故事，幫助理解
很多領域都有一些特有的業務，對于研發人員來說確實會有點生澀不易理解。
舉個例子，財務上有2種算賬方式，權責發生制和收付實現制，在做財務數據統計的需求時，不同的報表所用的方式不同，如果不理解這2個業務知識，很容易出現最終呈現出來的數據不準確的情況。
按常理來說，我們可以拿百科上專業的解釋來講解這2個業務知識指的是什么，但書面上的用語聽起來生硬難懂，也容易讓人忘記。
我們知道在需求表達的過程中，信息越是豐富，越容易被理解，而故事，則是能夠把信息之間有機結合在一起的非常好的載體。
因為一個完整的故事需要具備六要素：時間、地點、人物、起因、經過、結果，將這些與業務知識結合在一起去講述時，就產生出了故事的一個重要作用——‘畫面感’，聽起來就好像是發生在我們生活中的一件事情，能夠把聽眾帶入到完整的業務場景中去感受、理解。
例如下面這個故事：
菜市場有個賣肉的老王，賺的錢每天都會上交給他老婆，這天有個顧客一次付了2000元，讓老王接下來1個月每天都給他留2斤豬肉。
老王回家很開心地跟老婆說，今天多賺了2000元，老婆夸老王越來越會做生意了，沒細問是怎么賺的，獎勵了老王200元生活費。
過了幾天，老婆發現怎么肉突然不夠賣了，錢卻沒變多，于是問老王這是怎么回事，老王說上次的2000元其實是未來1個月的錢，于是老婆很生氣地說這類錢不能算成當天的收入，不然進貨會不準，罰老王洗碗一個月。
上述故事場景中，老王他老婆算賬的方式就是權責發生制，只把應收的錢，歸為當天的收入，收到的未來的錢，不算進當期收入。
與之相對應的收付實現制，就是老王的做法，把當期實際收到的錢都算為收入。
就像聽過的某個童話故事，過了十多年畫面感還是會存留在腦海中一樣，這樣把原本難懂的書面解釋結合到故事中，雖然沒有童話那般豐富有趣，卻也能達到相近的效果，比直接用書面用語講業務知識，能更通俗易懂且印象深刻。
我們在實際應用時，也可以根據具體講解的業務，給出類似這樣合適的故事。
2. 繪制流程，輔助表達
在講述業務的時候，為了讓講解更加完整與飽滿，我們通常都會詳細描述實際業務場景，而因為B端SaaS產品業務場景較為復雜，僅用文字或語言描述會顯得不夠清晰明了，如果此時附上一張帶有角色的業務流程圖，則能直觀地體現出不同角色、業務知識之間的聯系。
因為流程圖能夠同時擁有這幾個特征：節點化、方向性、可分支、角色劃分。
下面針對這些特征進行說明，先看看這個業務場景：
小王今年剛畢業參加工作，通過某平臺租了一間公寓住，到了月初，平臺照例生成了待繳賬單，小王想著能緩就緩吧，先不管了，2個月后小王打開APP一看，賬單包含了房租、水電燃氣費、寬帶費、窗戶維修費，除此之外還產生了不少違約金。
小王發現自己支付寶里邊的錢不夠，不過幸好身邊存著1000元現金，于是跟管家說，能不能在線上先交一部分，剩下的當面給現金你，管家表示可以。
管家上門收到了錢，然后將支付記錄錄入到了系統，并把錢交給了公司財務部門。
這個場景聽下來，確實提到了很多業務知識，卻并不容易吸收，正是因為知識點多，所以短時間內不容易看出哪些是重點，以及之間有什么關聯。
此時不妨運用一下流程圖的4個特征：
1）節點化
將場景中所有的關鍵事件提煉出來作為流程中的各個步驟，這個過程就是節點化。假如沒有節點化，那么遇到越是復雜的業務場景，為了讓聽眾理解，我們越是會用更多的文字或語言去闡述，內容更多聽眾反而更不容易抓到所有重點，這樣就形成了一個困境。
而節點化能夠拆分出一個復雜的業務場景中所有的關鍵事件，這些事件可以是系統執行的關鍵邏輯，或是業務場景中的關鍵業務行為，這樣抽絲剝繭，就把一個復雜的場景高度提煉了，聽眾一眼就能看出整個業務場景中的關鍵事件是哪些，解決了在復雜業務中快速找到關鍵事件的問題。
2）方向性
流程圖中一個節點之后用箭頭指向到下一個節點，即為方向性。方向性是流程圖特有的特性，體現出了不同關鍵事件之間發生的先后順序，誰是這件事情發生的前置條件。
在業務場景中，方向性可以直觀展示出所有事件之間的先后順序，這樣聽眾很容易就能理解這些業務事件之間的關聯性、前后邏輯。
3）可分支
可分支是指流程圖中支持增加判斷節點，每個判斷節點之后可以指向多個路徑。有時候業務場景中并不只有1種路徑，不同的業務行為會帶來不同的業務結果，這時用純文字和口述表達會顯得復雜，而流程圖可分支的特性就很直觀的表達出了這種情況，使其他人容易看出這里存在多種情況，以及不同情況會產生什么業務結果。
4）角色劃分
在跨職能流程圖中支持標注各步驟對應的角色，即為角色劃分。標注角色后能夠讓人直觀的知道，業務場景中的每個業務事件是由誰觸發的，便于理解業務中不同角色間的協作關系。
可以看出，當這幾個特征運用到了一起時，最終呈現出來的效果，就是把復雜的場景進行了抽象化、邏輯化、可視化。
我們將以上4個特征結合起來，整理出完整的流程圖：
圖中寥寥幾字，便體現出了完整的核心業務，最重要的是與純文字相比，非常便于短時間內理解并加深記憶，有助于讓團隊成員快速熟悉業務。
這個方法因為繪制了完整的流程，所以講解起來思路清晰，且不容易遺漏知識點，如果將故事和流程法結合使用，將產生不錯的培訓效果。
04 結語
對于C端產品來說，團隊成員自身就可以成為用戶去體驗，一般不需要專門的業務講解。
但做B端產品時，因為我們無法成為真正的用戶，很難體驗到實際場景，所以如果產品經理能花精力進行業務講解，同時結合了系統功能，在短時間內讓其他人也熟悉了業務和功能，那么對于整個團隊的工作來說，將帶來額外的增益。
作者：子文，公眾號：SaaS產品聞
本文由 @子文 原創發布于人人都是產品經理，未經作者許可，禁止轉載
題圖來自Unsplash，基于CC0協議
所以應該用權責發生制還是收付實現制呢??
大部分企業是用的權責發生制，收付實現制主要是非盈利組織在用，比如政府機構。所以，老王他老婆的做法才是對的。
我們公司特地讓我在現場觀摩 ，然而每次問到他們的專業時，他們就很不耐煩，他們覺得很簡單的東西，我這邊覺得非常難理解，畢竟不是他們專業的，導致調研也沒調出個啥，還得坐辦公室空想
有些行業業務屬性很強，內行人很明白，外行人一開始會完全不懂很正常，這個需要時間沉淀，專業術語可以百度，另外除了問一線人員，公司本部應該還會有其他資深的人士，也可以去問問。
但是很多公司產品經理都只是分配任務，都不會詳細講解業務需求，導致開發和設計做出的產品存在很多缺陷，我是做設計的，經常因為對一個業務不了解，做設計思考的層面都比較局限，都無從下手，也很想從實際業務以及客戶角度去設計相關的需求，但是一個人是做不了的
我們團隊會強制要求產品經理提的需求里面，要有需求背景（業務場景、現狀）、需求價值，如果需要的話還會加上用戶故事，久而久之我們的開發經理、測試經理現在已經非常熟悉業務了，評審會上經常能提出建設性的意見，思考什么樣的產品方案更合理。
其實你們也可以向leader提對需求質量的要求，需要講清楚需求背景、需求價值，否則視為需求不完整，有權利提出挑戰、質疑。
我提過很多次，上班第一天就建議公司為團隊做一次產品的培訓，讓我們都了解產品，到現在都沒有培訓，我們團隊都沒有人了解自己開發的產品，一問三不知，哈哈，做需求的時候也是零碎，都不理解需求的本質，我也是很無奈，提過很多次，讓我們都了解需求，知道客戶需求的本質，可是就是不走這個程序，尷尬??
產品經理的失職。。。
不僅技術懂業務，產品經理更要了解技術的數據結構怎么搭建的
是的，在設計產品時，我們也需要了解數據結構的設計和技術實現難易，因為這方面已經有很多文章做出了詳盡的論證，本文想從另一個點帶來思考，技術懂業務對產品設計影響