頭條楓林網我做了五年招聘的業務，從C端的產品有魚開始，做過兩套獵頭系統，深入過獵頭公司的運營管理，到現在正在做獵頭平臺的產品，對招聘這個業務有了比較深刻的理解。從開始單純的以網際網路的方式切入這個行業，到現在的業務運營驅動。這裏填了很多坑，有很多的思考，其中最簡單最重要的一點就是：要懂業務。
四個字很簡單，但實際上懂業務很難。懂業務涉及的方面很廣，我曾經一段時間內覺得懂業務很簡單，足夠聰明，很快就能夠進入業務。但實踐中不斷的打臉，對於業務要做到「懂」這是一個系統性的工程。要經歷一系列的本質上的轉變。
從心裏尊重業務
如果心裏一直是瞧不上業務，就無法站在業務的角度去看待問題、理解問題。這個是研發最常見的、最本質的問題。常見的研發的一些偏見：
- 業務系統需求不統一
- 個性化嚴重
- 沒有一個統一的人負責需求
- 變化快
- 體力活多
- 沒有成長
這些是一些偏見，缺乏正確的認識和正確的處理方式造成的。但也不能說是錯誤的。
另外一個點，研發往往會希望自己能夠主導，變成產品、或者是技術的驅動。這樣，有足夠的話語權、足夠的自由去做自己想做的事情。這種心情可以理解，但不得不說在大多數情況下都是錯誤的。從本質上，我們要明白業務是核心，產品是要解決業務的問題，幫助業務達到指數級的增長。簡單一點理解，問問自己這個模式下，最小的閉環最不可或缺的是哪些環節？一定是業務上的畫圓，然後產品技術一定程度幫助業務規模的增長有機會呈現指數級。
杜絕三個錯誤
在做業務系統的時候，有三個錯誤很可怕，不容易發現，但過後對整體的影響又是巨大的。
- 脫離業務設計產品
- 沉溺於業務的某個細節
- 用嚴密的邏輯完善業務
這是三個錯誤在發生的時候，比較難以被發現——在發生的時候，看起來挺好的，並沒有什麼不合適。那到底該如何發現、如何評判的呢？
根據我的經驗，為何會脫離業務設計產品呢？是否要做這個功能，做了這個功能能達到什麼效果沒有圍繞著業務進行。這裏深層次是一個功能點優先順序的問題，到底先設計開發什麼樣的功能點，依據應該是業務上的優先順序（但是這個優先順序，也並不是業務單方面決定的）。在解決了業務問題的基礎之上，再鼓勵一些創新性的發揮，是極好的。這個可以在管理上 適度權衡 。因為業務的問題恐怕很難全部解決。
沉溺於業務的某個細節是第二個錯誤。通常研發在開始瞭解業務的時候，瞭解了某些業務的工作場景可能就認為自己瞭解了業務的全面，專門為這個場景設計各種功能提高效率。這本質上不能說不好，但是做多了團隊會疲勞，大家會覺得沒有實現自己的價值。這個問題的本質也是瞭解業務沒有了解全面，分不清重要的程度。
最後一個錯誤是一個深坑。我在之前的文章裡也有說明，當一個不懂業務邏輯的聰明人接手業務，梳理業務的時候，只能從邏輯的正確與否，是否完備的角度評判，會將業務搞的複雜無比，不光業務怨聲載道、產品開發也是如此。結果就是浪費了時間，卻沒有解決問題，而且看起來還找不到問題所在，因為所有的邏輯就是「正確」的啊。這裏深層次要考慮的是，」正確「的依據是什麼呢？放在業務整個系統性的工程裡，到底處於什麼樣的位置呢？我舉一個經歷過的例子，我們之前獵頭的KPI有七八百項，可以想象麼？但實際業務中，有經驗的業務管理只會用到幾項。不能說那七八百項不對，但是在業務場景下需要考慮麼？不需要。無論是業務管理，做業務系統產品，真的要記住這個深坑。
系統性理解業務的標誌
寫到這裏，我想對之前的討論做一個總結。到底什麼是懂業務？什麼是對業務的系統性理解.
熟悉業務的各種流程、各種場景，並且能夠對細節進行整體的優先順序排序。
更重要的是整體的優先順序排序，無論業務提到了什麼問題、產品技術設計的過程中遇到了什麼問題，都要將這個點放到整體的邏輯中考慮，這個點處於排序的什麼位置，對於使用者的影響是什麼樣的。長此以往，無論是自己的感覺，還是業務的評價都會是：「懂業務」。
如何做到懂業務
說起來容易，做起來很難。在招聘這個行業也是填坑填了五年。總的來講有兩點：
- 明確業務運營驅動的本質
- 產品和技術的負責人都要成為業務專家
產品技術驅動看上去很美，但我們還是要面對現實。業務運營上的閉環是第一個要完成，圍繞這個閉環轉的越來越順是第二個要完成的。這兩個階段，產品技術大多是提速的作用。這個正確的認識，是必須要建立起來的。
不知道大家是否遇到過這樣的一些問題：
- 為什麼業務這邊沒有一個特別懂的人
- 為什麼業務的需求都不一樣，有矛盾
- 為什麼業務的需求就不能統一
- 為什麼業務這邊沒有統一的對接人
- 為什麼業務不能內部討論，統一輸出
類似這樣的問題很多，但為什麼這些不是我們產品和技術去搞清楚呢？
有的團隊確實有業務很強的人，業務能力非常精通。但如果要求他具備產品的思路，具備很強的系統性思維，能夠把業務邏輯梳理得很好是不現實的。這樣的人萬里挑一，每一個人都是各個公司追逐的物件。
但並不是沒有這樣的人就不能解決問題。所以，產品技術要衝到業務當中去，到群眾中去，去了解、整理、系統化。產品可能有很多事情做，PRD、互動、協調推動等。但我覺得在業務驅動的產品中，產品更應該再往前置，甚至和業務一起工作充分保證產品的邏輯和業務的邏輯能夠契合。
結語
針對業務和研發的關係，家家有本難唸的經。我已經聽過很多個版本，結合我自己的經歷。做了以上的總結，歡迎交流。
不過，業務和產品技術的關係是不斷變化的，業務到一定的規模真正的引擎就會換成產品技術，這時候產品體驗、技術實力將會是關鍵。這個話題我們後面聊。