產(chǎn)品經(jīng)理和開發(fā)人員前世是冤家，在此生約定互相折磨。在筆者的工作經(jīng)歷中，鮮有和諧共處的時(shí)候，絕大多數(shù)都是針尖對麥芒，視對方為傻叉。甚至有些情況下，發(fā)展成為了人身攻擊和物理傷害。

? ? ? ? 回過頭仔細(xì)想想，產(chǎn)品經(jīng)理和開發(fā)人員能有什么仇什么怨？都是一條繩上的螞蚱，并不是第敵人。很多時(shí)候沖突的原因，只不過是工作方式、思維方式的差異而已。本文從開發(fā)人員的角度總結(jié)總結(jié)哪些讓人為難的場景，也算是為世界和平做出點(diǎn)貢獻(xiàn)。

1. “獨(dú)裁者”溝通方式

? ? ? ?產(chǎn)品經(jīng)理和開發(fā)人員大部分情況下是一個鏈條上的兩種分工，并不存在上下級關(guān)系，只有上下游關(guān)系。產(chǎn)品經(jīng)理為需求負(fù)責(zé)，開發(fā)人員為實(shí)現(xiàn)負(fù)責(zé)。倘若產(chǎn)品以“經(jīng)理”的姿態(tài)去溝通，往往結(jié)果適得其反?！斑@個需求我拍板，出了問題我負(fù)責(zé)”，姑且不談是否能真的負(fù)責(zé)，這種姿態(tài)，也基本把開發(fā)人員的優(yōu)化意見拒之門外，長此以往，得不償失。常言道，“聽人勸，吃飽飯”，不妨聽聽開發(fā)人員的想法，認(rèn)真思考思考，沒準(zhǔn)能讓方案錦上添花。

2. 一句話需求

? ? ? ?這種情況很常見。筆者曾經(jīng)接到過一個需求，PRD文檔刪減掉“轉(zhuǎn)化”、“抓手”之類的詞語外，就剩一句話加一個按鈕：實(shí)現(xiàn)支付功能，至少支持微信。至于商品怎么管理，價(jià)格怎么管理，售前售后有什么需求，如何對帳，怎么退款，一概不提。

? ? ? ?一句話需求的本質(zhì)是，產(chǎn)品經(jīng)理沒有付諸更多的精力去形成方案，只是把這個過程拋給了開發(fā)人員。不出問題，反而很奇怪。

3. 拍腦門定需求

? ? ? ?筆者遇到過一些靠譜的產(chǎn)品經(jīng)理，需求的提出有著比較完善的邏輯分析和數(shù)據(jù)支撐，同時(shí)還有清晰的目的，在這種情況下，不管設(shè)計(jì)方案有多違反直覺，對于開發(fā)人員而言，也是心服口服的?？上?，多數(shù)情況下不是這樣。

? ? ? ?在某個項(xiàng)目中，在開發(fā)過程中評審下版本需求，發(fā)現(xiàn)，還處在開發(fā)中的界面在新版中完全變樣，開發(fā)提出疑問后，答案是，更改后更好看。在這個案例中，開發(fā)中的和新需求至少有一個是拍腦門的產(chǎn)物。未上線的需求白白浪費(fèi)了大量資源，很多重要的需求被擠壓，形成了技術(shù)債務(wù)。

4. 需求不分主次，全都要

? ? ? ?開發(fā)資源在一段時(shí)間內(nèi)是有限的，實(shí)踐中通常按照重要性和緊急程度制訂優(yōu)先級進(jìn)入開發(fā)流程。道理很簡單，做到卻很難。

? ? ? ?同樣是在某APP迭代中的案例：新版本中增加了新題型，PRD中對于交互方式的描述非常酷炫，大概一款益智游戲的效果一樣吧，什么氣泡大小按照內(nèi)容適配，還需要隨機(jī)移動，氣泡消除時(shí)，再加個爆炸效果... 結(jié)局大家大概能想到，產(chǎn)品研發(fā)爭吵一番后，不了了之。在這個案例中，新題型的支持是剛需，算是重要且緊急，酷炫效果卻不是。對于一幫并不是做游戲的程序員而言，開發(fā)酷炫效果的時(shí)間成本非常高，遠(yuǎn)遠(yuǎn)超過功能本身。最關(guān)鍵的是，根據(jù)用戶量和使用場景預(yù)估，這個需求覆蓋到的用戶可能最多也就兩位數(shù)，占比約等于0。

? ? ? ?除此之外，一個版本在工作量遠(yuǎn)遠(yuǎn)超支的情況下，所有功能點(diǎn)的優(yōu)先級都是P1；很長一段時(shí)間內(nèi)數(shù)據(jù)量基本保持在個位數(shù)的情況下，需要支持模糊搜索等也是常見的主次不分。

? ? ? ?需求主次不分的本質(zhì)原因大概是：產(chǎn)品設(shè)計(jì)時(shí)未充分考慮產(chǎn)品的定位，用戶的真實(shí)需求以及現(xiàn)實(shí)條件，同時(shí)，貪婪。

5. 越俎代庖給方案

? ? ? ?無論是產(chǎn)品經(jīng)理還是開發(fā)人員，都是專業(yè)化程度比較高的崗位。生活中大多數(shù)產(chǎn)品經(jīng)理都是沒有開發(fā)背景的，在這種情況下，帶著所謂的“技術(shù)方案”去和開發(fā)人員溝通需求，很難會有好的結(jié)果。

? ? ? ?在沒有開發(fā)背景的情況下，這些“技術(shù)方案”哪來的？對于計(jì)算機(jī)專業(yè)出身的產(chǎn)品經(jīng)理，很有可能來自于當(dāng)年課堂上的學(xué)習(xí)的理論；而對于完全行外的產(chǎn)品經(jīng)理來說，基本上都是從搜索引擎上獲取的。

? ? ? ? 至少在軟件工程領(lǐng)域，課堂所授已經(jīng)遠(yuǎn)遠(yuǎn)落后于實(shí)踐，指導(dǎo)意義可想而知。而在搜索引擎上獲取的方案，無法做到所有的外部條件都和當(dāng)前一致，也只能在某些技術(shù)點(diǎn)上有些用而已。

? ? ? ?一個合適的“技術(shù)方案”需要充分考慮整個項(xiàng)目的節(jié)奏、人力調(diào)配、后續(xù)迭代、架構(gòu)變動等，所以，盡可能的信任開發(fā)人員吧。

6. 盲人摸象或多米諾骨牌需求

? ? ? ?一生都生活在一個屋子里的人，是無法理解“房屋”這一實(shí)體的。產(chǎn)品經(jīng)理在提需求時(shí)，經(jīng)常會僅描述需求本身，而忽略了所處的業(yè)務(wù)環(huán)境。

? ? ? ?盲人摸象式需求忽略了新功能在整個業(yè)務(wù)中的地位，多米諾骨牌需求則忽略了新需求對于其他功能的副作用。這兩種需求較為類似。

? ? ? ?還是上文中提到的"支付功能"需求，在不描述商品、定價(jià)、權(quán)益交付等業(yè)務(wù)邏輯的情況下，僅僅描述支付本身，會讓開發(fā)人員一臉懵逼。這是典型的盲人摸象式需求。

? ? ? ?在k12教育業(yè)務(wù)中，用戶歸屬地是一個很重要的信息。項(xiàng)目初期，用戶歸屬地通過班級學(xué)校等關(guān)系間接獲取。當(dāng)上線支付功能后，發(fā)現(xiàn)一個嚴(yán)重的問題：支付功能的使用場景中，用戶是不具備班級學(xué)校關(guān)系的，權(quán)益添加出現(xiàn)了嚴(yán)重的問題。經(jīng)過緊急研究后，添加了用戶歸屬地的直接屬性。 衍生問題緊接著就來了：新的歸屬地邏輯和舊的歸屬地獲取邏輯在某些情況下會產(chǎn)生沖突，導(dǎo)致舊功能出現(xiàn)異常。這個案例我們僅從多米諾骨牌的角度解讀，新的邏輯變更并未同步考慮舊邏輯兼容問題，造成了嚴(yán)重的數(shù)據(jù)混亂以及二義性。

7. 空中樓閣式需求

? ? ? ?無論是產(chǎn)品設(shè)計(jì)還是架構(gòu)設(shè)計(jì)，絕大部分時(shí)間都是在解決實(shí)體與實(shí)體間關(guān)系的問題。我們經(jīng)常遇到這種情況，需求點(diǎn)在有明顯上下業(yè)務(wù)依賴的情況下，跨越依賴業(yè)務(wù)的設(shè)計(jì)，直接奔向“空中樓閣”。

? ? ? ?同樣在支付系統(tǒng)中，沒有對商品管理、購物車等前置業(yè)務(wù)進(jìn)行設(shè)計(jì)的情況下，直接“收錢”，業(yè)務(wù)的坍塌只是時(shí)間問題。

? ? ? ?另外一種經(jīng)常遇到的場景是，需求中沒有體現(xiàn)是關(guān)系還是屬性?？梢赃@樣認(rèn)為，有明確的取值范圍，且足夠簡單，可以作為屬性處理，例如用戶的性別、出生年月，無需單獨(dú)創(chuàng)建業(yè)務(wù)實(shí)體，使用特定值作為屬性即可。如果新增信息需要單獨(dú)維護(hù)，甚至有可能有附加信息，則需要采用關(guān)系的方式進(jìn)行處理，例如學(xué)生的班級。問題經(jīng)常出現(xiàn)在從前者到后者變更的時(shí)候。

? ? ? ?舉個例子：原設(shè)計(jì)中，用戶的性別只有男、女，分別定義為兩個數(shù)字，1、2；需求變更后，性別需要能夠單獨(dú)維護(hù)，比如自由添加“心理男”、“心理女”等性別定義，此時(shí)，就需要將性別設(shè)計(jì)為實(shí)體，用戶需要與性別建立關(guān)系；分歧由此產(chǎn)生，對于開發(fā)者而言，從屬性到關(guān)系的轉(zhuǎn)變，工作量驟增，對于產(chǎn)品經(jīng)理而言，不就是增加了一個對已有信息維護(hù)的需求，怎么需要這么久。

8. 前后矛盾的需求

這種需求很容易理解，就不再舉例了。當(dāng)產(chǎn)品經(jīng)理需求去問開發(fā)人員舊版本設(shè)計(jì)方案時(shí)，就需要警惕前后矛盾的需求了。至于產(chǎn)生原因，不在本文范疇。

9. 要求“靈活”的需求

? ? ? ?“靈活”是一個很寬泛的詞語，每個人的理解都不一樣。一旦某個需求，提出了“靈活性”的要求后，基本上相當(dāng)于把開發(fā)人員一腳踢到了地獄，未來任何調(diào)整遇到困難時(shí)，都會歸咎于“實(shí)現(xiàn)不靈活”。

? ? ? ?一個典型的需求描述：“xx功能需要具備靈活擴(kuò)展的能力”。相信我，對于這句話，開發(fā)人員和產(chǎn)品經(jīng)理對于“靈活擴(kuò)展”的理解是肯定不一樣的。倘若更換成，“題庫系統(tǒng)未來2月需要能夠支持完形填空、閱讀理解等包含子題目題型的接入，半年內(nèi)需要支持自定義題型接入”，會更清晰一些。起碼將“靈活性”限定在了題型擴(kuò)展領(lǐng)域，前期設(shè)計(jì)時(shí)就可以測重考慮這部分。

以上九把刀，刀刀催人老。

還是那句話，理解他人，換位思考，才能正確處理好產(chǎn)品與開發(fā)之間的關(guān)系！

另外，對現(xiàn)在我們的大多數(shù)朋友來說還是學(xué)編程技術(shù)最重要！栽一棵樹最好的時(shí)間是十年前，其次是現(xiàn)在。對于準(zhǔn)備學(xué)習(xí)編程的小伙伴，如果你想更好的提升你的編程核心能力（內(nèi)功）不妨從現(xiàn)在開始！

微信公眾號：C語言編程學(xué)習(xí)基地

整理分享（多年學(xué)習(xí)的源碼、項(xiàng)目實(shí)戰(zhàn)視頻、項(xiàng)目筆記，基礎(chǔ)入門教程）

歡迎轉(zhuǎn)行和學(xué)習(xí)編程的伙伴，利用更多的資料學(xué)習(xí)成長比自己琢磨更快哦！