? ? ? ?產品經理和開發(fā)人員前世是冤家，在此生約定互相折磨颅湘。在筆者的工作經歷中话侧，鮮有和諧共處的時候，絕大多數(shù)都是針尖對麥芒闯参，視對方為傻叉掂摔。甚至有些情況下，發(fā)展成為了人身攻擊和物理傷害赢赊。
? ? ? ? 回過頭仔細想想，產品經理和開發(fā)人員能有什么仇什么怨级历？都是一條繩上的螞蚱释移，并不是第敵人。很多時候沖突的原因寥殖，只不過是工作方式玩讳、思維方式的差異而已。本文從開發(fā)人員的角度總結總結哪些讓人為難的場景嚼贡，也算是為世界和平做出點貢獻熏纯。
1. “獨裁者”溝通方式
? ? ? ?產品經理和開發(fā)人員大部分情況下是一個鏈條上的兩種分工，并不存在上下級關系粤策，只有上下游關系樟澜。產品經理為需求負責，開發(fā)人員為實現(xiàn)負責叮盘。倘若產品以“經理”的姿態(tài)去溝通秩贰，往往結果適得其反∪岷穑“這個需求我拍板毒费，出了問題我負責”，姑且不談是否能真的負責愈魏，這種姿態(tài)觅玻，也基本把開發(fā)人員的優(yōu)化意見拒之門外，長此以往培漏，得不償失溪厘。常言道，“聽人勸牌柄，吃飽飯”桩匪，不妨聽聽開發(fā)人員的想法，認真思考思考友鼻，沒準能讓方案錦上添花傻昙。
2. 一句話需求
? ? ? ?這種情況很常見闺骚。筆者曾經接到過一個需求，PRD文檔刪減掉“轉化”妆档、“抓手”之類的詞語外僻爽，就剩一句話加一個按鈕：實現(xiàn)支付功能，至少支持微信贾惦。至于商品怎么管理胸梆，價格怎么管理，售前售后有什么需求须板，如何對帳碰镜，怎么退款，一概不提习瑰。
? ? ? ?一句話需求的本質是绪颖，產品經理沒有付諸更多的精力去形成方案，只是把這個過程拋給了開發(fā)人員甜奄。不出問題柠横，反而很奇怪。
3. 拍腦門定需求
? ? ? ?筆者遇到過一些靠譜的產品經理课兄，需求的提出有著比較完善的邏輯分析和數(shù)據(jù)支撐牍氛，同時還有清晰的目的，在這種情況下烟阐，不管設計方案有多違反直覺搬俊，對于開發(fā)人員而言，也是心服口服的蜒茄∮颇ǎ可惜，多數(shù)情況下不是這樣扩淀。
? ? ? ?在某個項目中楔敌，在開發(fā)過程中評審下版本需求，發(fā)現(xiàn)驻谆，還處在開發(fā)中的界面在新版中完全變樣卵凑，開發(fā)提出疑問后，答案是胜臊，更改后更好看勺卢。在這個案例中，開發(fā)中的和新需求至少有一個是拍腦門的產物象对。未上線的需求白白浪費了大量資源黑忱，很多重要的需求被擠壓，形成了技術債務。
4. 需求不分主次甫煞，全都要
? ? ? ?開發(fā)資源在一段時間內是有限的菇曲，實踐中通常按照重要性和緊急程度制訂優(yōu)先級進入開發(fā)流程。道理很簡單抚吠，做到卻很難常潮。
? ? ? ?同樣是在某APP迭代中的案例：新版本中增加了新題型，PRD中對于交互方式的描述非晨Γ酷炫喊式，大概一款益智游戲的效果一樣吧，什么氣泡大小按照內容適配萧朝，還需要隨機移動岔留，氣泡消除時，再加個爆炸效果... 結局大家大概能想到检柬，產品研發(fā)爭吵一番后献联，不了了之。在這個案例中厕吉，新題型的支持是剛需，算是重要且緊急械念，酷炫效果卻不是头朱。對于一幫并不是做游戲的程序員而言，開發(fā)酷炫效果的時間成本非常高龄减，遠遠超過功能本身项钮。最關鍵的是，根據(jù)用戶量和使用場景預估希停，這個需求覆蓋到的用戶可能最多也就兩位數(shù)烁巫，占比約等于0。
? ? ? ?除此之外宠能，一個版本在工作量遠遠超支的情況下亚隙，所有功能點的優(yōu)先級都是P1；很長一段時間內數(shù)據(jù)量基本保持在個位數(shù)的情況下违崇，需要支持模糊搜索等也是常見的主次不分阿弃。
? ? ? ?需求主次不分的本質原因大概是：產品設計時未充分考慮產品的定位，用戶的真實需求以及現(xiàn)實條件羞延，同時渣淳，貪婪。
5. 越俎代庖給方案
? ? ? ?無論是產品經理還是開發(fā)人員伴箩，都是專業(yè)化程度比較高的崗位入愧。生活中大多數(shù)產品經理都是沒有開發(fā)背景的，在這種情況下，帶著所謂的“技術方案”去和開發(fā)人員溝通需求棺蛛，很難會有好的結果怔蚌。
? ? ? ?在沒有開發(fā)背景的情況下，這些“技術方案”哪來的鞠值？對于計算機專業(yè)出身的產品經理媚创，很有可能來自于當年課堂上的學習的理論；而對于完全行外的產品經理來說彤恶，基本上都是從搜索引擎上獲取的钞钙。
? ? ? ? 至少在軟件工程領域，課堂所授已經遠遠落后于實踐声离，指導意義可想而知芒炼。而在搜索引擎上獲取的方案，無法做到所有的外部條件都和當前一致术徊，也只能在某些技術點上有些用而已本刽。
? ? ? ?一個合適的“技術方案”需要充分考慮整個項目的節(jié)奏、人力調配赠涮、后續(xù)迭代子寓、架構變動等，所以笋除，盡可能的信任開發(fā)人員吧斜友。
6. 盲人摸象或多米諾骨牌需求
? ? ? ?一生都生活在一個屋子里的人，是無法理解“房屋”這一實體的垃它。產品經理在提需求時鲜屏，經常會僅描述需求本身，而忽略了所處的業(yè)務環(huán)境国拇。
? ? ? ?盲人摸象式需求忽略了新功能在整個業(yè)務中的地位洛史，多米諾骨牌需求則忽略了新需求對于其他功能的副作用。這兩種需求較為類似酱吝。
? ? ? ?還是上文中提到的"支付功能"需求也殖，在不描述商品、定價务热、權益交付等業(yè)務邏輯的情況下毕源，僅僅描述支付本身，會讓開發(fā)人員一臉懵逼陕习。這是典型的盲人摸象式需求霎褐。
? ? ? ?在k12教育業(yè)務中，用戶歸屬地是一個很重要的信息该镣。項目初期冻璃，用戶歸屬地通過班級學校等關系間接獲取。當上線支付功能后，發(fā)現(xiàn)一個嚴重的問題：支付功能的使用場景中省艳，用戶是不具備班級學校關系的娘纷，權益添加出現(xiàn)了嚴重的問題。經過緊急研究后跋炕，添加了用戶歸屬地的直接屬性赖晶。 衍生問題緊接著就來了：新的歸屬地邏輯和舊的歸屬地獲取邏輯在某些情況下會產生沖突，導致舊功能出現(xiàn)異常辐烂。這個案例我們僅從多米諾骨牌的角度解讀遏插，新的邏輯變更并未同步考慮舊邏輯兼容問題，造成了嚴重的數(shù)據(jù)混亂以及二義性纠修。
7. 空中樓閣式需求
? ? ? ?無論是產品設計還是架構設計胳嘲，絕大部分時間都是在解決實體與實體間關系的問題。我們經常遇到這種情況扣草，需求點在有明顯上下業(yè)務依賴的情況下了牛，跨越依賴業(yè)務的設計，直接奔向“空中樓閣”辰妙。
? ? ? ?同樣在支付系統(tǒng)中鹰祸，沒有對商品管理、購物車等前置業(yè)務進行設計的情況下密浑，直接“收錢”蛙婴，業(yè)務的坍塌只是時間問題。
? ? ? ?另外一種經常遇到的場景是肴掷，需求中沒有體現(xiàn)是關系還是屬性敬锐”炒可以這樣認為呆瞻，有明確的取值范圍，且足夠簡單径玖，可以作為屬性處理痴脾，例如用戶的性別、出生年月梳星，無需單獨創(chuàng)建業(yè)務實體赞赖，使用特定值作為屬性即可。如果新增信息需要單獨維護冤灾，甚至有可能有附加信息前域，則需要采用關系的方式進行處理，例如學生的班級韵吨。問題經常出現(xiàn)在從前者到后者變更的時候匿垄。
? ? ? ?舉個例子：原設計中，用戶的性別只有男、女椿疗，分別定義為兩個數(shù)字漏峰，1、2届榄；需求變更后浅乔，性別需要能夠單獨維護，比如自由添加“心理男”铝条、“心理女”等性別定義靖苇，此時，就需要將性別設計為實體攻晒，用戶需要與性別建立關系顾复；分歧由此產生，對于開發(fā)者而言鲁捏，從屬性到關系的轉變芯砸，工作量驟增，對于產品經理而言给梅，不就是增加了一個對已有信息維護的需求假丧，怎么需要這么久。
8. 前后矛盾的需求
? ? ? ? 這種需求很容易理解动羽，就不再舉例了包帚。當產品經理需求去問開發(fā)人員舊版本設計方案時，就需要警惕前后矛盾的需求了运吓。至于產生原因渴邦，不在本文范疇。
9. 要求“靈活”的需求
? ? ? ?“靈活”是一個很寬泛的詞語拘哨，每個人的理解都不一樣谋梭。一旦某個需求，提出了“靈活性”的要求后倦青，基本上相當于把開發(fā)人員一腳踢到了地獄瓮床，未來任何調整遇到困難時，都會歸咎于“實現(xiàn)不靈活”产镐。
? ? ? ?一個典型的需求描述：“xx功能需要具備靈活擴展的能力”隘庄。相信我，對于這句話癣亚，開發(fā)人員和產品經理對于“靈活擴展”的理解是肯定不一樣的丑掺。倘若更換成，“題庫系統(tǒng)未來2月需要能夠支持完形填空述雾、閱讀理解等包含子題目題型的接入街州，半年內需要支持自定義題型接入”蓬豁，會更清晰一些。起碼將“靈活性”限定在了題型擴展領域菇肃，前期設計時就可以測重考慮這部分地粪。
以上九把刀，刀刀催人老琐谤。
