"BP"的幾點思考

題圖：pixabay

近半年來除了負責常規的工做編碼外，還兼了一個另外的角色 【BP】。顧名思義，business partner。在我理解，同時兼顧了PM、PMO。這活兒可比安安靜靜的敲代碼難搞太多了，拉齊、賦能、高效、理想態、中間態這些詞兒一天到晚在腦子裏轉。深入纔有體會，回顧下，共勉。

下面在我的理解上分幾個維度來思考。

業務上

搞清楚業務方要作什麼事情。

就是理解業務方的需求，這個東西說難也難，說簡單也簡單。簡單在於你只須要聽清楚業務方的話術就行，難在在於通過你腦子思考以後，你怎麼用最簡單直接的話術描述出業務方要作什麼事情。你能說清楚，說明你懂了。

搞清楚業務方的目標，要什麼結果與收益。

業務方爲何要作這個需求，作這件事情有什麼收益。業務方更加關注的是業務價值，因此咱們在知足業務方關注的東西以外，在正常的交付以外，能有什麼技術收益或是沉澱。這是咱們須要考慮的東西。

發散思惟，擴展業務方的需求。

這個實際上是我瞎編的。怎麼把收益擴大，在排期、人力、市場、數據的基礎上作折中考慮。多個需求可否合併，代碼、流程可否抽象通用。技術最終是爲業務賦能的。這個思惟方式是高階技術人逃不掉的。

產品上

搞清楚參與的人及能拍板的人。

簡單來講就是找準能負責的老闆。讓參與人員明白項目的重要性，心理上提升緊迫性和優先級。

需求點認知拉齊。

有時候，需求講了不少次，各模塊的同窗還不知道本身要作啥。這個事情最好的辦法就是各模塊單獨輸出技術方案上評審。老闆們關注的視角能在更上層的維度給項目把關。

制定整體技術方案及評審，各模塊的技術方案及評審

繼上面說的，讓各模塊本身梳理清楚要搞什麼事情，本身負責的邊界在哪裏。以及該怎麼與上下游協做，協做時關注哪些東西。同時，技術方案是否合理，折中考慮是什麼？是否合理當場下定論。老闆會替你撐場子。

定排期，留buffer。

最後就是定排期了。要求各模塊給出本身的排期安排，可是大多數時候都沒有一個統一的輸出時間點。能夠試試相鄰上下游拉齊，最後整體拉齊。就算最後有gap，相鄰上下游開發完後能夠先開始聯調嘛。

最後最重要的就是留buffer。切忌憨批作得快可讓老闆另眼相看的思想，搞很差就等着跑路吧。

節奏上

不要信奉「先緊後鬆」，要「一直緊湊，一氣呵成」。

以前我也是信奉「先緊後鬆」的原則。以爲項目前期節奏緊湊些，後期視進度能夠放鬆下節奏，不用逼那麼緊。事實證實我錯了，多團隊協做的時候，各個團隊不只僅是隻爲你這個項目服務的。後期節奏放鬆的後果是：好比截止到週四，項目完成到95%，最後一點收尾的工做必定要在週五完成。不要拖到下週一，就算排期夠也不要。一個週末事後，工做上的銜接成本是很高的。再打個比方，這次疫情高峯期的時候管控的特別嚴格，封路的封路，禁足的禁足。後期，力度不到位致使不少民衆以爲快結束了沒啥好擔憂的，都去逛公園了。若是有一例，全盤GG。

重溝通。包括向上彙報、團隊間傳遞等機制。

溝通真的超級超級重要。包括上傳下達，重要的節點或風險要跟老闆彙報。老闆、業務的策略也要及時傳遞到各團隊。遇到跨團隊分歧及不明確的點及時拉小會解決。會議的原則是：

• 會前明確討論需求點背景、目標及分界點
• 感受推不動的拉上老闆，看看老闆是怎麼作的
• 會後同步會議結論（郵件或羣@全員）

日會日報機制。圍繞核心目標、進展、風險等核心信息記錄並同步。重要信息跟老闆反饋。

日會是有點噁心。可是頗有效。日報的做用是讓項目組全體成員瞭解目前的進度及風險，提早作好心理準備。

把控上

找對的人。

出現問題了找能解決問題的人。寫代碼的人解決不了找上級，一級一級往上回遞歸。最後解決不了找本身的老闆和業務。

搞清楚問題在哪裏？再找對的人要合適的解決方案。

先搞清楚問題點在哪裏。最好內心能有幾個待選的解決方案，這樣跟各模塊的老闆談的時候比較有底氣。同時，解決方案也不是必定要理想的方案。是要符合當前階段，各團隊都承認的合適的解決方案。

提早預估風險。至少及時暴露風險。

能在項目啓動前預估到風險最好不過。固然很難，最次也要作到有問題出來或者說風險出來的時候，及時暴露給項目全員，打好預防針。

總結上

1. 項目管理就是風險管理。
2. 節奏把控推動一直緊。
3. 會議原則善始善終。
4. 理解、思考、溝通、傳遞、同步、制度。

其實上面都是我瞎編的。下一篇講講怎麼寫技術文檔。