No.11 項目管理 - 如何解開進程死鎖？

引例

從前有一個用戶去申請貸款，流程複雜，需要準備各種資料

用戶：要是批的少，我就不申請了！

貸款機構：你不申請，我怎麼知道能給你批多少？

用戶：要是批的少，我就不申請了！

...

無限循環下去

產品經理在工作中常常充當 項目經理 的角色，是一個項目團隊的協調人，對進度負責。但是有時會有一種無力感。想要溝通，卻無從下手。

這種無力感簡稱：推不動

---------------------------------

1. 進程死鎖

仔細想來，很多時候都陷入了一個死鎖當中。

定義兩個命題：

• 命題P: 貸款機構完成批款

• 命題Q: 用戶完成申請

內蘊條件：

• ┐P -> ┐Q

• ┐Q -> ┐P
• P <=> FALSE
• Q <=> FALSE

目標：

• P <=> TRUE
• Q <=> TRUE

計算命題真假，不出意外地：

(┐P -> ┐Q) ∧ (┐Q -> ┐P) ∧ ┐P ∧ ┐Q -> P ∧ Q

<=> ┐P ∧ ┐Q -> P ∧ Q

<=> ┐(┐P ∧ ┐Q) ∨ (P ∧ Q)

<=> P ∨ Q ∨ PQ ∨ PQ

<=> P ∨ Q

<=> FALSE

本身命題為假，除非 P 和 Q 至少一個為TRUE，下面結合具體 Case 探索如何來解鎖。

2. 案例分析

Sample One： 數據對接

做大數據的都知道數據的重要性，越是豐富，真實，大量的數據越有價值；一個項目對接多家不同的數據源再常見不過。

一個項目需要跨企業溝通，姑且叫做 企業A 和 企業B，其中A給B提供數據，B使用A的數據。

• 企業A：作為數據源提供數據

  • 出於數據安全，企業A不可能直接拿出資料庫的全量數據給B看
  • 所以開始時，B了解A的數據是局限的，甚至只是定性的

• 企業B：作為數據需求的提出方

  • 出於風控等原因，企業B不會教會A使用數據的能力
  • 所以開始時，A不可能精確知道B需要哪些數據欄位

• 目標是：雙方確認需要的數據欄位，並批量提供數據。

In case of： 雙方都沒有類似項目經驗

① 如果走 Yes or No 的離散邏輯

企業A：你不告訴我需要哪些數據，我怎麼給你數據？

企業B：你不給我看看有哪些數據，我怎麼知道需要哪些數據？

企業A：你不告訴我需要哪些數據，我怎麼給你數據？

...

無限循環下去

已經證明結果是FALSE，必然是走不通的。

② 如果部分實現P/Q命題，不斷逼近 P v Q <=> TRUE

既然P和Q互為條件和結論，那就讓其中一個命題先強行實現，哪怕不精確，再循環的進行修正，提高精確度。在此不得不定義一下什麼叫精確度，定義B不多不少地拿到所有需要的數據類型，視為精確。

A企業 進行業務講解，並對數據分類和標註，如訂單，物流

B企業 根據數據分類和業務講解，猜測哪類數據可用，並向A索要數據

A企業 給脫敏數據，但是

不見得欄位精確

不見得包含關鍵項

不見得數據可用

B企業 檢查數據格式，數據清洗，驗證數據可用性

如果數據不可用，詢問A有無可替代數據

可能會發現原本認為不需要的數據，重新需要

更新數據需求，提向A

企業A 再給一批數據

企業B 再次驗證數據，更新數據需求

企業A 再給一批數據

企業B 再次驗證數據，更新數據需求

... ...

直到數據滿足條件

Conclusion： 開荒和附用

階段一 破冰

通過歸納和籠統的說明，犧牲精確度，強行讓P和Q命題至少有一個為TRUE。使得不觸碰雙方底線的同時，能夠繼續推進。

A對B講解業務並對數據分類，讓B可以粗糙地提出數據需求，A第一次給B的數據也是不精確的，但是至少是有的，通過犧牲數據的精確度，強行讓P命題為TRUE，自然 P ∨ Q <=> TRUE

階段二 調精

在雙方的底線範圍之上，互相摸來摸去，去做實驗，就像『猜數字』遊戲一樣。

給對方一個輸入，對方給一個結果和反饋，調整後再給對方一個輸入；

這個過程就像兩個人互相摸底，是個不斷循環的來回溝通的工作；

十分費時費力！

階段三 附用

當完成了開荒之後，P <=> TRUE，同時Q <=> TRUE，下次遇到類似項目的對接時候，就無需再進行破冰和調精的 開荒步驟 了。

對於企業A，下次遇到類似的數據需求，P <=> TRUE，故P v Any <=> TRUE

對於企業B，下次再對接類似的數據源，Q <=> TRUE，故Q v Any <=> TRUE

Sample Two： 需求與排期

許多公司都有專門做系統服務的部門，給各條業務線提供基礎服務。當業務線和基礎服務部門對接時，通常效率很低。跨部門對接，大家都懂的。

部門A：業務部門

• 有修改基礎服務的需求時，會提交給基礎服務部門B
• 在A看來，B的溝通成本很高，凡事都要走流程，進度也走的慢

部門B：基礎服務部門

• 一個基礎的系統服務，會同時支持多個業務線
• 各個業務線都會給B提需求，B的需求池永遠是超負荷狀態
• 由於對接的業務線太多，又只是提供服務的介面文檔或SDK，所以B對各條業務線的具體業務不可能如數家珍

於是問題來了，對於部門B

1. 他要給一大坨需求排期，就得知道每個需求的價值和估算的工期，以排優先順序
2. 這些需求非常多，又來自於各個業務線，不可能每一條都問的很細
3. 所以只有排期後，才會對排上的需求做詳細的評審和對接
4. 但是如果不提前做詳細的評審和對接，很難精確的估算工期，就沒法精確的排期

如果不排期，就沒法評審

如果不評審，就沒法排期（精確）

...

小團隊是不會遇到這樣的問題的，因為都是先評審細節和實現，再估工期，再排期。

嘗試用剛才的結論求解

破冰

A向B描述需求，因為B對A是黑盒，所以並不一定描述的精確

B歸納需要重點確認的細節，並和A確認

A確認後，B粗略的評估工期並排期

由於犧牲了工期的精確度，所以最後的實現可能和這次排期的Road Map相差甚遠

調精

B和排上本期需求的業務線進行詳細的需求評審

修正工期，並做出本期各條業務線需求的總甘特圖

附用

每條業務線的需求是會有共性的

當明確了某類需求的工期後，下次再遇到就可以在一開始就估出精確的工期

不用經歷先排期再修正排期

3. 產品經理該幹什麼？

無論是 Sample One 的數據對接，還是 Sample Two 的需求評審和排期，在開荒的階段都有大量反覆溝通和修正的過程。

溝通，協調，向外對接的職能肯定是PM去乾的，PM是對外的統一出口

• Sample One中，需要反覆地

  • 對內溝通哪些數據能用，哪些數據不能用
  • 對外要數據

• Sample Two中，需要反覆地

  • 溝通和確認技術細節
  • 後期開發和測試還需要解答遇到的技術細節問題

但是產品經理既不可能幫數據挖掘工程師去研究數據，也不可能幫開發去對接細節。

• 不懂數據挖掘，怎麼去拍哪些數據能用？

  • 因為數據挖掘的RD只會讓PM去要某一類的數據，然後PM去索要
  • 具體發來是什麼樣的，RD和PM也都不會提前知道
  • 當別人發來數據時，PM沒有判斷能力，又去找RD

• 不懂開發，怎麼去確認技術細節？

  • 系統對接時，尤其是聯調測試時，對方很多時候會問PM技術細節
  • PM沒有回答的能力，只能原封不動的把原話傳給RD

所以通常的狀態是，PM成了 傳話筒 ，別人問一句，PM找一次RD，然後再把RD的話回復過去，效率極低！

積極了解輸出，嚴格把控輸入

以 Sample One 為例，雖然PM不是干數據挖掘的，但是必須對數據RD的工作有定性的了解，不能夠所有問題都直接丟給RD，需要明確和充分理解我們向對方輸出的需求，讓自己在回答他們問題時有判斷的能力。

• 原來的數據為什麼不能用？
• 我們這次溝通目的是需要什麼樣數據？
• 這些數據需要滿足什麼條件？
• 必須包含的欄位？
• 時間跨度大致需要多長？

對於這些數據怎麼去挖掘，不需要知道，而要知道

• 我們需要什麼樣的數據輸入給RD
• 我們希望這些數據輸出的結論是什麼

4. 所謂工作經驗

最後說說我對工作經驗這個詞的理解：所謂工作經驗，更多的不是技能的強弱，多少，而是經過多次開荒後，積累的大量的附用能力吧。