曾淑旭的試用評比

編輯導語：產品經理在日常工作中經常會與各部門打交道，比如在做項目時，會與技術部門進行交流溝通，提交需求等，但在溝通的過程中，不免遇到一些難題，比如技術無法實現，這時應該怎么辦？本文作者就此進行了詳細的分析，我們一起來了解一下。

需求討論清楚了，方案評審通過了，策劃和設計工作也完成了，項目已全面進入開發階段……

你剛要松口氣的時候，技術突然跑過來跟你說：“老哥，你這個需求搞不了啊。”

有項目經驗的朋友，應該能夠體會到，這個場景多么地令人奔潰！

前面所做的全部工作，可能都得推翻重來。項目進度將會受到巨大的影響。

這樣的情況，說多不多，說少也不少。

負責的項目多了，其實還是挺常會碰到的。

如果是你，遇到這樣的情況，要怎么辦？

直覺上，應該馬上暫停項目，然后趕緊召集相關干系人重新對項目進行評審。

這樣的“答案”，邏輯上沒有問題，挺合理的。

但是，在實操層面，我想說，先別著急，事情可能還遠遠沒到那一步。

進入全面開發階段之前，項目肯定已經經過了多方的評審。

我們是得到了“可以搞”的保證后，才開始搞的。

到了全面開發階段，再發現“搞不了”，概率其實很低。

根據經驗，大概有80%的概率，是個“假陽性”的誤報。

01

那么，怎么判斷項目是不是真的搞不了呢？

我猜，很多朋友可能已經聯想到一個老生常談的爭論：

“產品經理需不需要懂技術？”

你可能會想，如果產品經理懂技術，那就可以和技術battle，甚至一開始就不會設計出“技術上實現不了”的方案……

首先，我的觀點，向來都是“產品經理不需要懂技術”。

但是，在這里，我不想深入去討論這個話題，也不希望各位朋友從這個角度去思考本文要討論的場景。

上面說了，這個“搞不了”的反饋，有80%的概率是個“假陽性”的誤報。

在這80%的情況里面，其實更多的是“人”的問題，而不是“技術”的問題。

所以，要甄別它們，靠的也不是“懂技術”。

02

在全面開發階段，技術突然跟你反饋說：“這個需求搞不了。”

如果你項目經驗比較少，或者對團隊不夠了解，那么，很可能就會被“唬住”。

因為很多時候，其實完全是搞得了的。

下面，我會羅列出現“誤報”的幾種常見情況。

你在重新召開評審會之前，不妨先看看，真實的情況會不會是下面這樣的。

1. 技術沒看清楚需求內容

“這個真搞不了。這里面很復雜，有A、B、C 3種情況。B和C因為某某原因，是不能這么搞的。”

“嗯，所以我PRD上寫了‘僅針對情況A’。”

“……那沒事了。”

你沒有看錯，就是這么低水平的烏龍。

老實說，這種情況出現的概率還不低。

所以，我一直強調“在真實的世界里做產品”。

當你不是架空地去想問題，而是真正地去開展工作時，你總能碰到一些意想不到的困難。

在真實的世界中，光是“準確完整地傳達信息”，就很困難，經常出差錯。

當然，解決方法也很簡單。

反復說明，直到信息充分傳達為止。

2. 技術沒有正確理解項目的要求

曾經，有個需求是這樣的：

“從3個題庫里面隨機抽取5道題，要保證每個題庫至少要有1道題。”

然后技術跟我說，這個搞不了，里面需要很多判斷，很復雜。

具體怎么個復雜法，他也沒法表述清楚。

我思考了下，說，能不能這樣：

“第1題從題庫A中隨機取，第2題從題庫B中隨機取，第3題從題庫C中隨機取，第4、5題則在3個庫中隨機取，但要去重。”

技術想了想，說這樣搞可以。

為什么原來不能搞，現在又能搞了呢？

那是因為，技術以為，“每道題出現的概率要一致”，“題目出現的位置也要隨機”。

然而，從業務上看，并不需要做到這個地步。

像這樣的問題，無法像第一種情況那樣，事先在PRD上完全說明清楚。

因此，需要與技術仔細溝通，并在溝通過程中，細心地甄別出雙方在“理解”上的錯位。

3. 技術他自己的確搞不了，因為還需要其他技術來配合

曾經，我想給某個小模塊增加一個狀態變化。

但是，負責的技術說沒辦法搞。

我非常困惑，這應該是非常簡單的功能呀，怎么會沒辦法做呢？

“要增加狀態變化，需要新增一個字段來控制。”

“那加就是啦。”

“可我這邊只負責調用，沒辦法加字段。得某某組那邊才能加字段。”

“我……”

這看起來，多少有點讓人哭笑不得。

但，設身處地想想，其實也挺正常。

我們從外部看，會覺得技術部門就是一個整體，技術的問題他們內部理應自行溝通協商解決。

但是，每個人都有自己的分工，做著自己的工作。互相之間，關聯性沒那么強。

一個項目，往往需要技術部門不同分工的同事協同完成。

有時候，碰到涉及面較大的問題，更是需要讓不同分工的同事聚在一起，從各自的角度出發，提出意見，討論解決方案。

希望他們能自發地組織起來進行協作，其實是一種挺偷懶的想法。

在沒有項目經理的情況下，產品經理應該有意識地成為“組織者”。

當發現需要多人協作時，主動地組織起各方，高效地達成合作。

當然，這就需要產品經理充分了解團隊的工作分工。

4. 其實是技術沒時間搞

這個情況是，雖然技術上可行，但是預計花費的時間過多。

如果真的這么去做了，很可能無法按期上線，或者影響到其他項目的上線。

那么，解決思路也很清楚。

要么調整方案，要么修改開發排期，給與更多的開發時間。

要注意的是，有一些比較老油條的技術，嫌麻煩，不想搞，會“欺負”產品經理不懂。

他不說”時間不夠“，而是含糊其辭地說，“太復雜了，搞不了。”

這一點，產品新人要注意甄別。

5. 技術對項目的重要級認識不足

某種意義上講，沒有什么需求是實現不了的，只是成本的問題。

有時候，技術的意思，其實是：

“（因為沒法把工作量控制在合理的范圍內，所以，）這個需求搞不了。”

比方說，這個項目需要10個單位的工作量。

技術根據自己對需求的理解，認為以這個項目的價值，超過5個單位的工作量，就不合理了。

然而，因為這個項目重要級比較高，哪怕是花費10個單位的工作量，也是值得的。

當然，這個工作量的問題，需要在評審的時候提出來討論，并且最終與領導達成共識。

不是產品經理自己單方面覺得“值得”就可以了。

這種情況下，產品經理需要把項目的重要級，以及領導已知悉并同意的情況，給技術傳達清楚。

特別的，有時候，“搞不了”的意見，是技術組長給出的。

這時候，“糾纏”具體某個技術就沒有意義了，應該直接和技術組長溝通。

03

有2種的態度，我認為是有問題的。

一種是，認為既然領導已經審批通過了，那么技術就應該按要求去完成。

有問題，不關我的事，你們內部自己協商解決。

我只關心結果。

另一種是，盲目地認為“專業的事情交給專業的人處理”。

既然技術說了不行，那就不行。

沒必要去了解其中的細節，反正我也不懂。

這2種工作方式，我多少有碰見過。

個人覺得，至少作為產品經理，是不應該如此的。

04

上面列舉的幾種情況，需要產品經理具備不同的能力，分別用不同的方式妥當應對。

但是，無論哪種情況，一個不變的前提是，需要產品經理深入其中，充分調研，了解個中細節，敏感地發現問題所在。

從“搞不了”變成“搞得了”的過程中，產品經理的溝通協調工作，發揮了重要的作用。

換個角度來說，這也是產品經理的職責所在。

你是否也碰到過這樣的問題？你是怎么處理的？

#專欄作家#

簡明產品論，微信公眾號：簡明產品論（ID：JianMingPM），人人都是產品經理專欄作家。在真實的世界里做產品。

本文原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議