起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識To B 產品的研發矛盾：效率高 or 響應快？
toB 研發和銷售兩種不同的節奏經常會使得產品經理左右為難，那么我們到底是應該選擇效率高呢還是響應快呢？
如果你處于toB企業產品行業當中當產品/項目經理，一方面，可能經常會有銷售/實施部門的人向你或者老板吐槽研發的效率不高，客戶也經常認為研發的響應太慢，想辦法施壓推動；另一方面，開發團隊已經覺得自己已經在滿負荷工作了，客戶需求還是源源不斷的來，原定的開發計劃都沒法按時交付。
作為產品經理，會發現自己左右為難，忙于一面“擋需求”，一面“增效”（嗯，其實就是讓研發加班）。其實這其中的一個原因，是toB研發和銷售兩種不同的節奏和思考方式所導致的，只有解開這個根因，才能真正對癥下藥。
產品研發團隊想要效率高
研發團隊最關注的點是提升整體的研發效率，特別是敏捷式的開發，非常注重開發中的精力集中，才能夠在計劃的時間內交付承諾的功能。
一個高效的敏捷開發團隊日常所關心的是：
- 我們上幾個迭代完成了多少故事點（Story points）？
- 我們能不能按規劃完成未來兩個產品路線上的需求？
- 我們對需求點的評估是否準確？
- 開發團隊的負荷如何？
- 我們怎么償還我們的技術債務？減少緊急情況的出現？
- 我們的技術架構應該是如何的，才能符合當下和未來的業務需求？
對于研發團隊來說，高效就像是跑馬拉松一樣，保持著穩定的高節奏（每一周或兩周一次迭代發布），沿著產品路線持續推進，哪怕有高優先級的需求插入，也應該是可以安排到下一個迭代再去考慮。
這種高效有一個重要的前提條件：在進入開發前，已經提前給需求點定義好優先級，然后開發人員可以按照定好的優先級逐個需求進行開發。這個優先級應該來源于一個中長期的產品愿景，然后研發團隊一同來分解，逐步來實現和驗證商業價值，而這個價值并不是著眼與某個或某幾個客戶，而是從公司和市場的長期價值。
銷售團隊想要響應快
從銷售團隊的角度來說，可能是完全不一樣的思維模式。銷售人員的激勵模式決定了他們的收入不是與公司整體的盈利掛鉤，而是和自己手上特定的客戶是否能夠簽單、收款成功相關。而這些客戶很可能是現有的標準產品所不能完全滿足，擁有一些自己特定痛點的。
這些痛點會體現在整個銷售和實施周期上，客戶部門，無論是領導還是員工，都不斷會提出他們的一些需求，這些需求有真實的，也有拍腦門YY的，也不管三七二十一先提出來，然后這些需求就會變成與簽單和收款相關的工作項。
這些需求很可能會在售前實施售后過程中的任何時間點提出來，不管這些需求點是否在我們原定的產品路線里面，銷售團隊都需要產品和開發團隊盡快進行需求可行性和工作量的評估，也需要我們盡快安排進行開發，這樣才能盡快答復客戶和推進報價、簽單和收款。
所以，跟研發團隊關注自己的效率不同，銷售團隊更看重的是研發團隊的響應速度：能夠快速理解客戶需求、做出和確認產品方案、進行開發工作量的評估、排期和開發出自己的客戶所關注的需求點（不管這些需求點是不是我們原來的產品路線上），總之能夠越快響應客戶越好，恨不得在客戶看來，研發團隊就是專門為他們服務的。
不同的視角，不同的節奏
總結一下研發和銷售兩者視角的差異：
- 產品研發部門更多考慮能夠滿足大量客戶的通用需求，更希望實現前后一致、經過慎重思考、意外情況少的需求和管理過程，只有這樣他們才能夠根據這些明確的需求去進行評估、進行軟件的架構的統籌設計。對于他們來說，規劃之外的打擾越少，團隊的效率才能越高，也越能減少開發過程中的失誤；
- 銷售團隊是一個客戶一個客戶地來打單，從這個角度來看，他們向公司匯報時不斷強調客戶的需求點是十分合理的做法，因為這樣才能讓產品研發團隊盡快安排資源來實現功能，進而簽單。如果不能夠對大客戶的額外需求進行快速響應，對銷售是非常不利的。
這種視角上的差異導致兩個團隊的步調的差異，而步調的差異就會導致兩個團隊之間的磨合和溝通出現問題：
- 如果按照銷售團隊要求的響應快的步調走，研發團隊會覺得自己不斷地各種的評估和答復工作所干擾，這種干擾還無法預測隨時都可能出現，手上的開發任務還得回頭加班做，更不用說隨時加插的開發任務了；
- 如果按照研發團隊要求的效率高、低擾動的步調走，銷售團隊就覺得一點簡單的問題都要讓客戶等很久，這單子沒法做了。
如何處理節奏的矛盾？
方法A：咬定路線不放松
我們可以選擇忽略那些緊急的需求，相信我們原定的產品路線規劃中的需求才是滿足用戶真正的通用需求，嚴格按照產品路線進行研發才是效益最好的投入。所有的額外需求我們都在下一個產品路線規劃周期的時候再考慮。
這種規劃方式可能在2C產品里面能夠走得通，因為在2C產品里面不會有哪一個特定的用戶的商業影響力足夠達到能夠影響到我們的產品路線（當然，這里不是指不去聽取用戶的建議，而是指不是非得按某個用戶的說法去做）。
但在2B里面這種想法沒有多少可操作性，特別是面向大客戶的企業里面，營收額是塊狀組成的，單獨一個客戶的影響力可以十分巨大，一個客戶的交易就很可能會打動到管理層為之調整策略。
方法B：銷售驅動產品路線
另一個極端，就是產品規劃把所有客戶要求的需求點都提到更高的優先級，按照投入產出比或者合同金額排個序，然后按優先級從高到低開發，最后再把剩下的時間留給原來的產品規劃、架構、償還技術債、長期的學習和研究。
關于銷售驅動的根源和帶來的問題在《2B產品的隱藏陷阱：銷售驅動》里面有更詳細的分析，此處就不再贅述。在產品還沒有成型，還在打前兩三個燈塔標桿客戶的時候，銷售驅動是可行的。但面對更多的客戶的時候還采用這種方式，公司就會不經意間向項目外包的方向去滑落，但又不是以專業的方式去做項目。結果很可能就是產品規劃凌亂，客戶也沒有能服務好。
方法C：給研發力量劃分投資組合
比起上面兩種極端的方法，還有一種折中方案。就是劃分出一個特定部分的研發力量來專門針對緊急的銷售驅動的干擾，例如一個季度中的15~20%的工作量，把大客戶的需求點分散到各個迭代中來完成。這樣我們才能保證到不受干擾的研發力量，去從事開發通用需求，填補技術債務等等非緊急但很重要的工作。
采用這個方式需要持續管理和落實，不然還是會因為客戶需求的“緊急”性，慢慢滑落到“銷售驅動”。
還有一種方式是采用專門的項目實施團隊，或者通過外包人力，通過項目試試的方式來專門服務所有銷售驅動的需求。例如：向SAP一類的大型產品在實施時是通過項目的方式，為每個客戶配備專門的開發團隊，來處理定制需求和系統集成等工作（當然SAP的實施項目范圍遠遠不止開發，還包括和埃森哲配套進行咨詢服務等等，這是由SAP面向的都是超大型客戶和非常復雜的需求所決定的）。當然，這個要求產品的核心架構和接口能夠對第三方擴展進行支持。
可落實又有靈活性的產品路線
第三種方式，可以有效解決效率高和效應快兩者之間的矛盾。我們能夠得到一個既能夠落實的中長期產品路線，又具有一定的靈活性能夠響應客戶意料之外的額外需求。保護好既定計劃的時間之后，我們可以：
- 比起原來被銷售驅動所一拖再拖的產品規劃，現在可以更好地承諾按時完成原定計劃的工作了，團隊也沒有理由或者借口把原計劃的工作不斷地后延；
- 比起簡單粗暴地拒絕客戶的任何要求，現在團隊是可以去快速響應客戶的需求的，而且，因為給這些需求劃定了配額，也倒逼銷售團隊將這些銷售驅動需求排列優先級，優先去滿足利益最大化的需求；
- 當產品完善到一定的程度，知道什么時候把客戶的定制需求可以下放到外部或者內部的專門的團隊去響應這些需求。
總結
上面講述了toB大客戶產品所特有的一種研發矛盾，這種矛盾緣自與團隊中不同角色不同的激勵和考核方式：銷售團隊想要研發團隊能夠快速響應，來滿足特定客戶的復雜需求，從而帶來收入；研發團隊想要的是盡量少的打擾來達到持續的生產力。作為處于中間的產品團隊，則要站在整個產品乃至公司的高度來進行規劃和調和。
作者：梵天，公眾號：梵天Daozen（fantian-daozen）
本文由 @梵天 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自 Pexels，基于 CC0 協議
塊狀理論很受用，文章寫得很不錯了，一看就知道是實操很厲害的。其實無非就是產品團隊+實施團隊來組合了。
響應快就是效率高的一部分吧？
如果真的要做選擇的話，我覺得可能是效率和數量二選一。
因為
我想查的全，但是數據多了會慢。
我想查得快，但是速度快了數據量必然有限
小孩子才做選擇
乍一聽很有道理，但是人生處處都在做選擇。