當(dāng)過程序員的產(chǎn)品經(jīng)理市面上還是不少的。產(chǎn)品經(jīng)理和程序員首先在思考問題的方式上還是有些不同的。做過程序的產(chǎn)品經(jīng)理，在設(shè)計(jì)或?qū)崿F(xiàn)一些客戶需求時(shí)，一般肯定都能落地，因?yàn)樗部紤]了技術(shù)實(shí)現(xiàn)的思路等。

我做程序員有8年的經(jīng)驗(yàn)了，雖然沒有干過產(chǎn)品經(jīng)理，但是對(duì)產(chǎn)品經(jīng)理和程序員之間的“矛盾”也是了解一二。

產(chǎn)品經(jīng)理和程序員核心的矛盾其實(shí)在于產(chǎn)品經(jīng)理在產(chǎn)品設(shè)計(jì)及需求變更的時(shí)候并沒有深入的了解過程序，可能他們感覺產(chǎn)品的變更很簡(jiǎn)單，但是對(duì)于程序員來說就是大量程序的重構(gòu)，而程序員本來就對(duì)自己寫的代碼付出過心血，如果突然推翻，程序員必然會(huì)心存怨恨。程序員必然會(huì)對(duì)產(chǎn)品經(jīng)理提出的調(diào)整方案作出回應(yīng)，比如懈怠，爭(zhēng)吵等。

核心的的矛盾在于：溝通

如果說產(chǎn)品經(jīng)理在干產(chǎn)品的時(shí)候多了解程序的實(shí)現(xiàn)以及需求變更會(huì)對(duì)程序帶來的調(diào)整及工作量的情況，我相信程序員也不會(huì)針對(duì)產(chǎn)品經(jīng)理了。

程序員轉(zhuǎn)產(chǎn)品經(jīng)理

我個(gè)人認(rèn)為這是個(gè)很好的事情，既能好好的干好產(chǎn)品，又深入聊好軟件編程的情況，也有過相關(guān)的項(xiàng)目經(jīng)驗(yàn)，這樣對(duì)于產(chǎn)品本身來說是件好事。

程序員完成的產(chǎn)品

我是一個(gè)老程序員，也做了一個(gè)狗樣的產(chǎn)品，望大家給進(jìn)行指點(diǎn)指點(diǎn)。項(xiàng)目開源在gitee上，大家搜索：青鋒后臺(tái)管理系統(tǒng)，或者私下給我，我給你們預(yù)覽地址。（項(xiàng)目源碼已開源）

下面附帶幾張圖片：

職業(yè)寫代碼只有 1 年，業(yè)余也寫了一些，一個(gè)人參加黑客馬拉松拿過獎(jiǎng)，已經(jīng)轉(zhuǎn)產(chǎn)品經(jīng)理 2 年多了，平時(shí)會(huì)關(guān)注技術(shù)方面的東西，說下自己的一點(diǎn)體會(huì)和總結(jié)。

優(yōu)勢(shì)：

• 數(shù)據(jù)方面
• SQL，大多數(shù)公司的數(shù)據(jù)的產(chǎn)品化其實(shí)都比較一般，很多數(shù)據(jù)都需要研發(fā)來跑腳本，這個(gè)時(shí)候會(huì) SQL 就基本可以不去麻煩 RD，他們的時(shí)間是很寶貴的
• EXCEL，由于有編程的基礎(chǔ)，寫 EXCEL 的公式基本都是得心應(yīng)手，查文檔基本足夠了，復(fù)雜點(diǎn)的需求還可以寫點(diǎn) VB 腳本來解決（個(gè)人用的是 Google Doc，支持 Javascript）
• Python
• 完成重復(fù)性勞動(dòng)，比如每天要給別人數(shù)據(jù)周報(bào)，SQL 查出來的數(shù)據(jù)可能格式上不能滿足，通過 Python 進(jìn)行一些格式化，轉(zhuǎn)置之類的操作可以一條命令生成數(shù)據(jù)周報(bào)
• 爬蟲，做競(jìng)品分析的時(shí)候，花兩三個(gè)小時(shí)就能把競(jìng)品所有的數(shù)據(jù)都爬下來（一些反爬蟲的需要反編譯，繞過驗(yàn)證碼之類的估計(jì)麻煩一點(diǎn)），統(tǒng)計(jì)成圖表
• 稍復(fù)雜一點(diǎn)的數(shù)據(jù)分析，近期在學(xué)習(xí)《精益數(shù)據(jù)分析》，無計(jì)算機(jī)背景估計(jì)會(huì)比較難看懂
• 工具的使用
• Google，任何事情問別人之前，請(qǐng)先嘗試自己解決
• 選最好的工具，作為一個(gè)超級(jí)工具控，在做任何事情之前會(huì)為自己挑一件趁手的兵器
• 用好冷門的軟件，你能想到的所有功能都已經(jīng)有現(xiàn)成的軟件了
• 盡量使用快捷鍵
• 復(fù)用，寫代碼的時(shí)候要把多處用到的代碼寫成函數(shù)，寫文檔之類的事情也是一樣，做一份 PRD 的模板，自己定義好樣式和規(guī)則，不要總是重復(fù)無規(guī)則的勞動(dòng)
• Bug 定位，遇到 Bug用 Chrome 的開發(fā)者模式或者 Charles 之類的抓包工具，看懂自己業(yè)務(wù)的 API 基本沒什么難度，可以很快定位是前端還是服務(wù)器或者是數(shù)據(jù)的的問題，就不用天天跑到研發(fā)面前說：這個(gè)頁面加載不出來了。
• 技術(shù)調(diào)研，能知道功能大致是怎么實(shí)現(xiàn)的，要接入第三方服務(wù)時(shí)，可以看懂開發(fā)者文檔，知道什么功能能實(shí)現(xiàn)，什么不能實(shí)現(xiàn)，不要瞎提需求（不過這里會(huì)有個(gè)坑，后面說）
• 同理心，能理解研發(fā)的辛苦，溝通起來也會(huì)順暢一些

劣勢(shì)：

• 思維容易局限，覺得用戶能理解一切，不用說和用戶交流，我經(jīng)常和同事交流的時(shí)候都覺得：你怎么這都不知道
• 項(xiàng)目推動(dòng)，雖然和研發(fā)溝通起來可能會(huì)有又是，但是作為產(chǎn)品是需要多方溝通的，要出面撕逼的時(shí)候容易慫；對(duì)排期沒有其他產(chǎn)品那么敏感

雷區(qū)：（這其實(shí)是我最想說的東西）

• 千萬不要覺得自己做過研發(fā)，就可以對(duì) RD 指手畫腳，需要尊重他人在自己領(lǐng)域的專業(yè)性
• 利用技術(shù)手段提升工作效率是好事，別陷進(jìn)去，產(chǎn)品最終拿出來說話的還是有沒有解決用戶的問題，而不是解決你自己的問題
• 技術(shù)調(diào)研什么的，還是謹(jǐn)慎一點(diǎn)，判斷失誤是常有的事

說了這么多，還是喬老爺子的話比較牢靠：stay hungry，stay foolish，平時(shí)多學(xué)習(xí)一點(diǎn)東西，做事的時(shí)候謙虛一點(diǎn)。

我的建議是程序員可以轉(zhuǎn)行做運(yùn)營(yíng)，但是最好不要轉(zhuǎn)型做產(chǎn)品，原因如下；

首先束手束腳，產(chǎn)品經(jīng)理要求的是敢想敢干，但是一個(gè)產(chǎn)品經(jīng)理是程序員出身他的思考方式就會(huì)從程序員角度出發(fā)。想要做什么產(chǎn)品的時(shí)候首先想到的是技術(shù)上能不能實(shí)現(xiàn)，而不是我就要這個(gè)產(chǎn)品怎么做是你們的事。

其次產(chǎn)品重技術(shù)輕應(yīng)用，程序員做產(chǎn)品會(huì)太過于強(qiáng)調(diào)技術(shù)而輕視市場(chǎng)的應(yīng)用性，簡(jiǎn)單來說就是做出來的是一個(gè)技術(shù)領(lǐng)先但沒有什么市場(chǎng)需求的產(chǎn)品。

第三不利于市場(chǎng)拓展，一個(gè)優(yōu)秀的程序員是需要具有技術(shù)思維的，但是一個(gè)具備非常優(yōu)秀技術(shù)思維的人基本上不可能或者說很少有能做到市場(chǎng)思維的。這就會(huì)導(dǎo)致技術(shù)思維蓋過市場(chǎng)思維。

綜上所述，程序員轉(zhuǎn)型的最好崗位是運(yùn)營(yíng)。

沒有啥稀奇的吧，我們公司的產(chǎn)品經(jīng)理都當(dāng)過程序員，只是角色變了，考慮問題的思路也變了。程序員只關(guān)注自己的任務(wù)，關(guān)系一個(gè)點(diǎn)，但是產(chǎn)品經(jīng)理不同，你關(guān)注的事面，是產(chǎn)品的各個(gè)方面，包括供貨，生產(chǎn)等。產(chǎn)品經(jīng)理任務(wù)更重，責(zé)任更大，是產(chǎn)品的領(lǐng)航者。

說起程序員和產(chǎn)品經(jīng)理的關(guān)系，用相愛相殺來形容最恰當(dāng)不過，彼此嫌棄又不離不棄。其實(shí)，這也很正常，因?yàn)閮烧叩闹R(shí)體系和思維結(jié)構(gòu)不一樣，關(guān)注的重點(diǎn)也不一樣，所以在協(xié)同工作過程中，難免會(huì)出現(xiàn)一些分歧和摩擦，出現(xiàn)互相埋怨和吐槽的情況。

如果是做過程序員的人來當(dāng)產(chǎn)品經(jīng)理的話，這種狀況會(huì)不會(huì)得以改善呢？也許會(huì)，也許不會(huì)，這個(gè)不得而知，但是當(dāng)過程序員的人，肯定知道什么樣的產(chǎn)品經(jīng)理是程序員會(huì)喜歡和接受的。

平等、尊重與理解是第一前提

首先，產(chǎn)品經(jīng)理應(yīng)該明確知曉項(xiàng)目/團(tuán)隊(duì)的目標(biāo)，與程序員是同一利益共同體，所有的討論、分歧、摩擦、思想碰撞都是對(duì)事不對(duì)人的，也不存在必然的領(lǐng)導(dǎo)和被領(lǐng)導(dǎo)、上級(jí)和下級(jí)的關(guān)系。

產(chǎn)品經(jīng)理跟程序員之間是平等的協(xié)作關(guān)系，雙方的命運(yùn)與產(chǎn)品息息相關(guān)。有時(shí)候程序員對(duì)產(chǎn)品傾注的情感，付出的努力，并不比產(chǎn)品經(jīng)理少；程序員對(duì)產(chǎn)品的期望和思考，也不比產(chǎn)品經(jīng)理低，有時(shí)候甚至高于產(chǎn)品經(jīng)理。

舉個(gè)例子，大部分的產(chǎn)品經(jīng)理在設(shè)計(jì)新房時(shí)可能考慮了電梯、逃生通道、水電、電器接入，但程序員想得會(huì)更多，他們會(huì)關(guān)注停電停水之后房間里需不需要備蠟燭、緊急照明燈以及儲(chǔ)備用水。

程序員是產(chǎn)品/項(xiàng)目的實(shí)際實(shí)施者和創(chuàng)造者，產(chǎn)品經(jīng)理是幫助產(chǎn)品創(chuàng)造的設(shè)計(jì)者和連接者，是團(tuán)隊(duì)中的一員，而不是突出的個(gè)人。放棄你改變世界的想法，以平等、尊重彼此的心態(tài)，和程序員們做朋友、做隊(duì)友。

不打擾，多給程序員時(shí)間和空間

產(chǎn)品經(jīng)理要學(xué)會(huì)在大多數(shù)時(shí)候，讓程序員忘了你的存在，但在最需要你的時(shí)候你才挺身而出。

程序員非常討厭的一點(diǎn)是當(dāng)他思維在高度集中、效率奇高構(gòu)建思維、飛快碼字的時(shí)候，產(chǎn)品經(jīng)理不斷地跑過來說一些無關(guān)痛癢的“點(diǎn)”打斷他的思維。斷了的思維有時(shí)候會(huì)延續(xù)不上，甚至有時(shí)候會(huì)讓產(chǎn)品實(shí)現(xiàn)邏輯上少掉一個(gè)關(guān)鍵的分支。不用在產(chǎn)品實(shí)現(xiàn)的時(shí)候頻繁出現(xiàn)刷存在感，當(dāng)他需要你的時(shí)候，他會(huì)自己找你。即便你自己發(fā)現(xiàn)了產(chǎn)品問題或者bug，如果不是核心的、致命的問題，請(qǐng)先記在一個(gè)列表里，集中給他。

友情提醒：下午3點(diǎn)開始到晚上，是程序員思維活躍、工作較為高效的時(shí)間段。

有擔(dān)當(dāng)，敢擔(dān)當(dāng)，不貪功

產(chǎn)品設(shè)計(jì)/實(shí)現(xiàn)出現(xiàn)問題時(shí)，擔(dān)當(dāng)而不推諉；需要資源支持時(shí)，巧取而不豪奪（這里的“豪奪”是指動(dòng)不動(dòng)搬上下級(jí)關(guān)系施壓）；在產(chǎn)品有成績(jī)和突破時(shí)，表達(dá)而不貪功。在協(xié)作、磨合過程中，有擔(dān)當(dāng)，敢擔(dān)當(dāng)，不貪功，善良比聰明更重要。

所有產(chǎn)品經(jīng)理都繞不過去的一個(gè)坎是“老板需求”。什么是老板需求？說白了就是：老板需要一個(gè)這樣的東西，老板想要這樣做。但老板不接觸程序員，他接觸產(chǎn)品經(jīng)理。如果你只是老板需求的轉(zhuǎn)發(fā)者，而不是產(chǎn)品需求的過濾者、把關(guān)者，可能會(huì)被視為“無擔(dān)當(dāng)”。

老板需求跟用戶需求、產(chǎn)品基礎(chǔ)需求應(yīng)該是平等的，也有合理、不合理之分，也有優(yōu)先級(jí)。當(dāng)產(chǎn)品經(jīng)理發(fā)現(xiàn)老板需求不是太合理時(shí)，產(chǎn)品經(jīng)理要冒著丟掉飯碗的風(fēng)險(xiǎn)與老板據(jù)理力爭(zhēng)，動(dòng)之以理，曉之以情。這叫敢擔(dān)當(dāng)。這也是對(duì)程序員勞動(dòng)最基本的尊重。

產(chǎn)品經(jīng)理不是光鮮亮麗的角色，他和程序員一樣，也只是團(tuán)隊(duì)中的一員，跟大家榮辱與共，同享成敗。這樣的產(chǎn)品經(jīng)理，才是一個(gè)合格的產(chǎn)品經(jīng)理，也是程序員們喜歡的產(chǎn)品經(jīng)理！希望以上的回答對(duì)你有所幫助！

記得之前參加團(tuán)建活動(dòng)，是真人 CS。

我們一共沒幾個(gè)產(chǎn)品經(jīng)理，但有幾十個(gè)程序員。

所以場(chǎng)面估計(jì)你也能想象出來了...并不是刺激的對(duì)戰(zhàn)，而是慘絕人寰的群毆。

被 BB 彈打成狗（哎，原來不就是狗嗎）的一個(gè)產(chǎn)品經(jīng)理急中生智，大喊：『我以前也寫過代碼！我是自己人！』

其他正在施暴的程序員面面相覷，表示十分感動(dòng)，但仍然拒絕了他的求情，繼續(xù)按在地上打了半個(gè)小時(shí)。

...

我在哈工大讀書，學(xué)的是計(jì)算機(jī)，寫了六年代碼，畢業(yè)后做的卻是產(chǎn)品。

所謂對(duì)程序員和產(chǎn)品經(jīng)理之間的調(diào)侃，主要原因無非就在兩方經(jīng)常有矛盾出現(xiàn)，而矛盾出現(xiàn)顯然是因?yàn)殡p方一邊是需求提供方，一邊是需求實(shí)現(xiàn)方。

矛盾的類型也簡(jiǎn)單，就是大家提到的這么幾種。

同時(shí)寫過代碼，又做過產(chǎn)品的我，實(shí)際上仍然沒有很好的通用法則，能解決所有矛盾。

不過做過產(chǎn)品總監(jiān)一職后，的確理解完全不同了。產(chǎn)品工作和研發(fā)工作都是我的管理范疇之內(nèi)，看事情的角度就完全不一樣。

過去做程序員，總覺得提供的需求更改很煩、給的需求不合理很煩、給的截止時(shí)間不合理很煩。

做產(chǎn)品經(jīng)理的時(shí)候，也會(huì)覺得程序員總是推卸責(zé)任、完成得不及時(shí)或者不夠好。

其實(shí)從整體的工作配合上來看，出現(xiàn)問題是難免的，關(guān)鍵是如何預(yù)防、如何解決。

...

這是一些切身體會(huì)得出的經(jīng)驗(yàn)性建議：

對(duì)于研發(fā)人員：

1. 做好更改需求的準(zhǔn)備

很多固執(zhí)的程序員會(huì)把改需求當(dāng)成錯(cuò)事。

改需求？你怎么不早想清楚？
改需求？你知道我工作量多大嗎？
改需求？那我不干了。

實(shí)際上，在互聯(lián)網(wǎng)產(chǎn)品這個(gè)領(lǐng)域內(nèi)，改需求肯定會(huì)是家常便飯。

我沒有做過統(tǒng)計(jì)，但我接觸到的已經(jīng)成立一年的公司，幾乎都經(jīng)歷過大改版，也就是代碼全部重寫。這對(duì)研發(fā)團(tuán)隊(duì)來說自然很痛苦，但卻是不可避免的。

互聯(lián)網(wǎng)的需求更替是頻繁的，一方面是大環(huán)境隨時(shí)在發(fā)生變化，去年你還在刷微博，今年已經(jīng)是朋友圈了。另一方面，需求獲取的渠道也是多樣的，產(chǎn)品經(jīng)理可能會(huì)有新的發(fā)現(xiàn)和新的判斷，未必都是之前沒想清楚。

當(dāng)然，如果需求都是老板從什么《易經(jīng)》中得到感悟、從云卷云舒花開花落里得到啟示，讓你手忙腳亂給他改來改去，那也沒意思了。

既然改需求是經(jīng)常會(huì)出現(xiàn)的，那就要求還是得做好更改需求的準(zhǔn)備。

有這么幾種方法：

1.1 提高代碼的可復(fù)用性、可擴(kuò)展性等等

讓一些產(chǎn)品中很可能會(huì)用得到的各種控件、功能模塊做成可復(fù)用性很強(qiáng)的代碼，在產(chǎn)品增加類似功能，或者修改原有類似功能時(shí)，將會(huì)大有裨益。

可擴(kuò)展性則是各種接口、數(shù)據(jù)庫以及底層結(jié)構(gòu)不要寫死，盡量用可擴(kuò)展的方式寫。比如現(xiàn)在有五個(gè)分類，不要寫死就五個(gè)，要寫成 n 個(gè)分類，目前是五個(gè)。嗯，這是常識(shí)了，但有的程序員還是會(huì)比較隨意，寫代碼沒有遠(yuǎn)見。

其他的代碼特性，如果有利于降低產(chǎn)品的更改和優(yōu)化成本，也要加深關(guān)注。

1.2 根據(jù)產(chǎn)品規(guī)劃來做好充分準(zhǔn)備

每個(gè)功能的實(shí)現(xiàn)方法都有很多，怎么選擇并不是只看當(dāng)下的成本如何，而是要關(guān)注未來產(chǎn)品的整體規(guī)劃。

可能目前要完成功能 A，有 1、2、3 多種方案，方案 1 成本最小。但未來要完成 A、B、C、D 很多功能，方案 3 更有利于整體成本最小。那就要選方案 3 未雨綢繆。

多跟產(chǎn)品團(tuán)隊(duì)交流，了解未來產(chǎn)品要做成的樣子、哪些功能會(huì)是必須的、哪些功能是可能會(huì)有的，多從長(zhǎng)遠(yuǎn)來看。

1.3 合理預(yù)留出修整的時(shí)間

首先，不要把研發(fā)時(shí)間就當(dāng)作完成時(shí)間。研發(fā)功能只是一部分，測(cè)試、改 BUG 以及處理意外情況的時(shí)間都要預(yù)留出來。

有兩種情況要多預(yù)留出修整的時(shí)間。

一種是研發(fā)團(tuán)隊(duì)自己對(duì)功能沒有把握，可能是全新的功能，可能是比較難做的功能，可能出現(xiàn)許多 BUG 和功能實(shí)現(xiàn)糟糕的情況，那就要多預(yù)留出時(shí)間。

另一種是產(chǎn)品團(tuán)隊(duì)表示對(duì)功能也有疑慮，比如在提供需求時(shí)表示這個(gè)功能很有可能要調(diào)整，或者對(duì)功能本身信心不足，那也要多留時(shí)間做調(diào)整。

2. 理解需求，防止返工

研發(fā)團(tuán)隊(duì)通常會(huì)缺少對(duì)需求的理解，尤其會(huì)出現(xiàn)這種情況的就是外包團(tuán)隊(duì)。

我聽說過太多花了幾十萬請(qǐng)外包團(tuán)隊(duì)，最后開發(fā)的結(jié)果特別不滿意，不能拿來用。合同又已經(jīng)簽好，還得給錢，就是賠了夫人又折兵。

有的技術(shù)團(tuán)隊(duì)和產(chǎn)品團(tuán)隊(duì)都坐在同一間辦公室了，居然都經(jīng)常缺乏溝通。技術(shù)團(tuán)隊(duì)不知道當(dāng)前做的功能是給誰做的、是提供什么功能、滿足用戶什么價(jià)值的。

這些不是很高深的理論，也不需要深入學(xué)習(xí)，只需要通過產(chǎn)品經(jīng)理做些了解，就能少挖一些坑，也就不會(huì)輕易返工。

比如，有的產(chǎn)品頁面可以是提前加載緩存，也可以是每次都刷新，但要看用戶平常是在 WiFi 環(huán)境下用還是在移動(dòng)數(shù)據(jù)下用，這是產(chǎn)品經(jīng)理清楚的。產(chǎn)品經(jīng)理在功能細(xì)節(jié)上不會(huì)想到實(shí)現(xiàn)層面這么具體，所以就需要研發(fā)團(tuán)隊(duì)去理解剛才說的需求，做一些判斷。

另外，如果是在開發(fā)之前就意識(shí)到做出來的功能會(huì)跟產(chǎn)品經(jīng)理想象的不同，那就必須及時(shí)提出來，千萬不要等開發(fā)完成，大家都覺得不靠譜，再重做，那樣不管對(duì)誰來說成本都太大了。

3. 善于用數(shù)據(jù)、理論以及通俗的解釋來進(jìn)行溝通

程序員最應(yīng)忌諱的就是說『這個(gè)做不了，說了你也不懂』、『這個(gè)太難，懶得跟你解釋』。產(chǎn)品經(jīng)理聽完肯定會(huì)覺得是推卸責(zé)任。

正確的方式是：用通俗易懂的客觀事實(shí)來解釋。

嗯，這個(gè)彈窗做不了。

為什么現(xiàn)在做不了？是因?yàn)榇a實(shí)現(xiàn)可能要花三個(gè)月。

為什么這么久？是因?yàn)樾枰{(diào)用底層驅(qū)動(dòng)層面的東西。

為什么要調(diào)用底層驅(qū)動(dòng)的東西？是因?yàn)榘沧肯到y(tǒng)原本的框架和協(xié)議就是這么定的。

如果想看協(xié)議，我可以給你找出來。

這樣一步一步往下解釋，把所有理由說明白，別沒有耐心，只要產(chǎn)品經(jīng)理是講理的，他會(huì)理解你。

他聽懂了你的解釋，也會(huì)有利于他找出另外可接受的一種解決方案。

哦，我懂了，這個(gè)用彈窗形式太復(fù)雜。

那我們換作跳轉(zhuǎn)到普通頁面吧。

這樣問題就解決了。

對(duì)于產(chǎn)品：

產(chǎn)品經(jīng)理要在不斷的迭代和更改需求的風(fēng)險(xiǎn)中被程序員認(rèn)可乃至尊重，我覺得最重要的還是『講道理』。

切忌說出『我不管，反正得做完』或者『老板就這么定的，我也沒辦法』這樣的操蛋話。

1. 對(duì)產(chǎn)品功能有規(guī)劃，并提供給研發(fā)

對(duì)自己的產(chǎn)品都沒有大致規(guī)劃，是產(chǎn)品經(jīng)理的大忌，也是出現(xiàn)問題的主要原因。

• 一年后產(chǎn)品成熟了要給用戶解決怎樣的問題？
• 未來半年內(nèi)產(chǎn)品要做成什么樣子？
• 三個(gè)月內(nèi)產(chǎn)品應(yīng)該主要提供哪些功能？
• 這一個(gè)月的產(chǎn)品具體方案是做哪些？

這些都要認(rèn)真去考慮并且規(guī)劃。

當(dāng)然，長(zhǎng)遠(yuǎn)的產(chǎn)品規(guī)劃在很多情況下（市場(chǎng)變化、團(tuán)隊(duì)更替、產(chǎn)品轉(zhuǎn)向）確實(shí)用途不大，但越短期的規(guī)劃，對(duì)研發(fā)團(tuán)隊(duì)越有幫助。

正常來說，預(yù)估三個(gè)月內(nèi)產(chǎn)品的功能還是完全可以的，除非老板和產(chǎn)品經(jīng)理都沒想明白產(chǎn)品到底該做成什么。

把這些規(guī)劃想明白，并傳達(dá)給研發(fā)團(tuán)隊(duì)，讓他們?cè)诂F(xiàn)在的代碼里就給未來的功能留下空間，是最好的避免代碼重寫的方法。

2. 提供需求要足夠具體

這要求產(chǎn)品經(jīng)理做到兩點(diǎn)：

第一，讓產(chǎn)品需求文檔特別特別具體。

具體并不是說，要按照大公司的 PRD 去完成。而是說，不要缺東西。

對(duì)于需求文檔來說，頁面邏輯、頁面布局、功能邏輯和每個(gè)功能的使用細(xì)節(jié)，都要存在。并不只是畫個(gè)交互圖就叫需求文檔了。

你給了研發(fā) 5 個(gè)頁面，結(jié)果研發(fā)做著做著，來問你，好像缺了個(gè)頁面。你補(bǔ)完一個(gè)，研發(fā)做了一會(huì)兒發(fā)現(xiàn)又缺了一個(gè)...最后七零八碎的 10 個(gè)頁面拼湊出來，發(fā)現(xiàn)根本不好用，所以又推倒重來。

如果研發(fā)經(jīng)常來問你某個(gè)地方該怎么做時(shí)，你就要反思是不是需求文檔寫得不夠好了。

第二，要說明每個(gè)需求背后的原因。

這個(gè)在上面表達(dá)過，程序員明白了需求背后的原因，會(huì)選擇更合理的方案去完成。

千萬別提『你別管為什么了』，而是不管他問不問這個(gè)功能為什么要做成這樣，都要告訴他為什么。

3. 熟悉基本的研發(fā)背景和研發(fā)能力

『產(chǎn)品經(jīng)理到底需不需要懂技術(shù)』是我被問到的關(guān)于產(chǎn)品經(jīng)理的問題中的 TOP 5。

這個(gè)問題我的回答是：要按照需求，了解基礎(chǔ)知識(shí)，并不需要知道實(shí)現(xiàn)細(xì)節(jié)。

了解基礎(chǔ)知識(shí)、不需要知道細(xì)節(jié)是指產(chǎn)品經(jīng)理應(yīng)當(dāng)知道最基本的一些理論。

比如做安卓操作系統(tǒng)，要知道安卓原生提供了哪些控件，這樣在設(shè)計(jì)方案時(shí)可以盡量使用它們。在代碼實(shí)現(xiàn)時(shí)，調(diào)用一個(gè)控件可能只需要幾行代碼，但自己重寫一個(gè)功能界面，可能就是成千上萬的代碼量了。

比如是在手機(jī)網(wǎng)頁上的產(chǎn)品，要知道哪些交互是在 H5 上較容易實(shí)現(xiàn)的，而哪些交互是實(shí)現(xiàn)效果非常糟糕的。如果依照在 iOS 上的動(dòng)畫效果來要求 H5，開發(fā)成本可能會(huì)是指數(shù)級(jí)上升的。

按需，是說對(duì)于產(chǎn)品經(jīng)理，千萬不要買《iOS 入門指南》、《安卓開發(fā)手冊(cè)》或者《H5 設(shè)計(jì)實(shí)例》來學(xué)習(xí)，除了裝點(diǎn)下書架不會(huì)有別的意義。

因?yàn)楸旧黹_發(fā)的指南和手冊(cè)，講述的全是實(shí)現(xiàn)細(xì)節(jié)，對(duì)你清楚安卓的基本控件或者 H5 的常用交互完全沒有幫助；同時(shí)，不同的產(chǎn)品有不同的特性，也有不同的代碼特點(diǎn)，你只需要了解你負(fù)責(zé)產(chǎn)品的技術(shù)背景即可，有的同學(xué)居然決定從 C 語言先開始看，簡(jiǎn)直是讓人扼腕。