當過程序員的產品經理市面上還是不少的。產品經理和程序員首先在思考問題的方式上還是有些不同的。做過程序的產品經理，在設計或實現一些客戶需求時，一般肯定都能落地，因為他也考慮了技術實現的思路等。

我做程序員有8年的經驗了，雖然沒有干過產品經理，但是對產品經理和程序員之間的“矛盾”也是了解一二。

產品經理和程序員核心的矛盾其實在于產品經理在產品設計及需求變更的時候并沒有深入的了解過程序，可能他們感覺產品的變更很簡單，但是對于程序員來說就是大量程序的重構，而程序員本來就對自己寫的代碼付出過心血，如果突然推翻，程序員必然會心存怨恨。程序員必然會對產品經理提出的調整方案作出回應，比如懈怠，爭吵等。

核心的的矛盾在于：溝通

如果說產品經理在干產品的時候多了解程序的實現以及需求變更會對程序帶來的調整及工作量的情況，我相信程序員也不會針對產品經理了。

程序員轉產品經理

我個人認為這是個很好的事情，既能好好的干好產品，又深入聊好軟件編程的情況，也有過相關的項目經驗，這樣對于產品本身來說是件好事。

程序員完成的產品

我是一個老程序員，也做了一個狗樣的產品，望大家給進行指點指點。項目開源在gitee上，大家搜索：青鋒后臺管理系統，或者私下給我，我給你們預覽地址。（項目源碼已開源）

下面附帶幾張圖片：

職業寫代碼只有 1 年，業余也寫了一些，一個人參加黑客馬拉松拿過獎，已經轉產品經理 2 年多了，平時會關注技術方面的東西，說下自己的一點體會和總結。

優勢：

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

劣勢：

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

雷區：（這其實是我最想說的東西）

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

說了這么多，還是喬老爺子的話比較牢靠：stay hungry，stay foolish，平時多學習一點東西，做事的時候謙虛一點。

我的建議是程序員可以轉行做運營，但是最好不要轉型做產品，原因如下；

首先束手束腳，產品經理要求的是敢想敢干，但是一個產品經理是程序員出身他的思考方式就會從程序員角度出發。想要做什么產品的時候首先想到的是技術上能不能實現，而不是我就要這個產品怎么做是你們的事。

其次產品重技術輕應用，程序員做產品會太過于強調技術而輕視市場的應用性，簡單來說就是做出來的是一個技術領先但沒有什么市場需求的產品。

第三不利于市場拓展，一個優秀的程序員是需要具有技術思維的，但是一個具備非常優秀技術思維的人基本上不可能或者說很少有能做到市場思維的。這就會導致技術思維蓋過市場思維。

綜上所述，程序員轉型的最好崗位是運營。

沒有啥稀奇的吧，我們公司的產品經理都當過程序員，只是角色變了，考慮問題的思路也變了。程序員只關注自己的任務，關系一個點，但是產品經理不同，你關注的事面，是產品的各個方面，包括供貨，生產等。產品經理任務更重，責任更大，是產品的領航者。

說起程序員和產品經理的關系，用相愛相殺來形容最恰當不過，彼此嫌棄又不離不棄。其實，這也很正常，因為兩者的知識體系和思維結構不一樣，關注的重點也不一樣，所以在協同工作過程中，難免會出現一些分歧和摩擦，出現互相埋怨和吐槽的情況。

如果是做過程序員的人來當產品經理的話，這種狀況會不會得以改善呢？也許會，也許不會，這個不得而知，但是當過程序員的人，肯定知道什么樣的產品經理是程序員會喜歡和接受的。

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

首先，產品經理應該明確知曉項目/團隊的目標，與程序員是同一利益共同體，所有的討論、分歧、摩擦、思想碰撞都是對事不對人的，也不存在必然的領導和被領導、上級和下級的關系。

產品經理跟程序員之間是平等的協作關系，雙方的命運與產品息息相關。有時候程序員對產品傾注的情感，付出的努力，并不比產品經理少；程序員對產品的期望和思考，也不比產品經理低，有時候甚至高于產品經理。

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

程序員是產品/項目的實際實施者和創造者，產品經理是幫助產品創造的設計者和連接者，是團隊中的一員，而不是突出的個人。放棄你改變世界的想法，以平等、尊重彼此的心態，和程序員們做朋友、做隊友。

不打擾，多給程序員時間和空間

產品經理要學會在大多數時候，讓程序員忘了你的存在，但在最需要你的時候你才挺身而出。

程序員非常討厭的一點是當他思維在高度集中、效率奇高構建思維、飛快碼字的時候，產品經理不斷地跑過來說一些無關痛癢的“點”打斷他的思維。斷了的思維有時候會延續不上，甚至有時候會讓產品實現邏輯上少掉一個關鍵的分支。不用在產品實現的時候頻繁出現刷存在感，當他需要你的時候，他會自己找你。即便你自己發現了產品問題或者bug，如果不是核心的、致命的問題，請先記在一個列表里，集中給他。

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

有擔當，敢擔當，不貪功

產品設計/實現出現問題時，擔當而不推諉；需要資源支持時，巧取而不豪奪（這里的“豪奪”是指動不動搬上下級關系施壓）；在產品有成績和突破時，表達而不貪功。在協作、磨合過程中，有擔當，敢擔當，不貪功，善良比聰明更重要。

所有產品經理都繞不過去的一個坎是“老板需求”。什么是老板需求？說白了就是：老板需要一個這樣的東西，老板想要這樣做。但老板不接觸程序員，他接觸產品經理。如果你只是老板需求的轉發者，而不是產品需求的過濾者、把關者，可能會被視為“無擔當”。

老板需求跟用戶需求、產品基礎需求應該是平等的，也有合理、不合理之分，也有優先級。當產品經理發現老板需求不是太合理時，產品經理要冒著丟掉飯碗的風險與老板據理力爭，動之以理，曉之以情。這叫敢擔當。這也是對程序員勞動最基本的尊重。

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

記得之前參加團建活動，是真人 CS。

我們一共沒幾個產品經理，但有幾十個程序員。

所以場面估計你也能想象出來了...并不是刺激的對戰，而是慘絕人寰的群毆。

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

其他正在施暴的程序員面面相覷，表示十分感動，但仍然拒絕了他的求情，繼續按在地上打了半個小時。

...

我在哈工大讀書，學的是計算機，寫了六年代碼，畢業后做的卻是產品。

所謂對程序員和產品經理之間的調侃，主要原因無非就在兩方經常有矛盾出現，而矛盾出現顯然是因為雙方一邊是需求提供方，一邊是需求實現方。

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

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

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

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

做產品經理的時候，也會覺得程序員總是推卸責任、完成得不及時或者不夠好。

其實從整體的工作配合上來看，出現問題是難免的，關鍵是如何預防、如何解決。

...

這是一些切身體會得出的經驗性建議：

對于研發人員：

1. 做好更改需求的準備

很多固執的程序員會把改需求當成錯事。

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

實際上，在互聯網產品這個領域內，改需求肯定會是家常便飯。

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

互聯網的需求更替是頻繁的，一方面是大環境隨時在發生變化，去年你還在刷微博，今年已經是朋友圈了。另一方面，需求獲取的渠道也是多樣的，產品經理可能會有新的發現和新的判斷，未必都是之前沒想清楚。

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

既然改需求是經常會出現的，那就要求還是得做好更改需求的準備。

有這么幾種方法：

1.1 提高代碼的可復用性、可擴展性等等

讓一些產品中很可能會用得到的各種控件、功能模塊做成可復用性很強的代碼，在產品增加類似功能，或者修改原有類似功能時，將會大有裨益。

可擴展性則是各種接口、數據庫以及底層結構不要寫死，盡量用可擴展的方式寫。比如現在有五個分類，不要寫死就五個，要寫成 n 個分類，目前是五個。嗯，這是常識了，但有的程序員還是會比較隨意，寫代碼沒有遠見。

其他的代碼特性，如果有利于降低產品的更改和優化成本，也要加深關注。

1.2 根據產品規劃來做好充分準備

每個功能的實現方法都有很多，怎么選擇并不是只看當下的成本如何，而是要關注未來產品的整體規劃。

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

多跟產品團隊交流，了解未來產品要做成的樣子、哪些功能會是必須的、哪些功能是可能會有的，多從長遠來看。

1.3 合理預留出修整的時間

首先，不要把研發時間就當作完成時間。研發功能只是一部分，測試、改 BUG 以及處理意外情況的時間都要預留出來。

有兩種情況要多預留出修整的時間。

一種是研發團隊自己對功能沒有把握，可能是全新的功能，可能是比較難做的功能，可能出現許多 BUG 和功能實現糟糕的情況，那就要多預留出時間。

另一種是產品團隊表示對功能也有疑慮，比如在提供需求時表示這個功能很有可能要調整，或者對功能本身信心不足，那也要多留時間做調整。

2. 理解需求，防止返工

研發團隊通常會缺少對需求的理解，尤其會出現這種情況的就是外包團隊。

我聽說過太多花了幾十萬請外包團隊，最后開發的結果特別不滿意，不能拿來用。合同又已經簽好，還得給錢，就是賠了夫人又折兵。

有的技術團隊和產品團隊都坐在同一間辦公室了，居然都經常缺乏溝通。技術團隊不知道當前做的功能是給誰做的、是提供什么功能、滿足用戶什么價值的。

這些不是很高深的理論，也不需要深入學習，只需要通過產品經理做些了解，就能少挖一些坑，也就不會輕易返工。

比如，有的產品頁面可以是提前加載緩存，也可以是每次都刷新，但要看用戶平常是在 WiFi 環境下用還是在移動數據下用，這是產品經理清楚的。產品經理在功能細節上不會想到實現層面這么具體，所以就需要研發團隊去理解剛才說的需求，做一些判斷。

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

3. 善于用數據、理論以及通俗的解釋來進行溝通

程序員最應忌諱的就是說『這個做不了，說了你也不懂』、『這個太難，懶得跟你解釋』。產品經理聽完肯定會覺得是推卸責任。

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

嗯，這個彈窗做不了。

為什么現在做不了？是因為代碼實現可能要花三個月。

為什么這么久？是因為需要調用底層驅動層面的東西。

為什么要調用底層驅動的東西？是因為安卓系統原本的框架和協議就是這么定的。

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

這樣一步一步往下解釋，把所有理由說明白，別沒有耐心，只要產品經理是講理的，他會理解你。

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

哦，我懂了，這個用彈窗形式太復雜。

那我們換作跳轉到普通頁面吧。

這樣問題就解決了。

對于產品：

產品經理要在不斷的迭代和更改需求的風險中被程序員認可乃至尊重，我覺得最重要的還是『講道理』。

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

1. 對產品功能有規劃，并提供給研發

對自己的產品都沒有大致規劃，是產品經理的大忌，也是出現問題的主要原因。

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

這些都要認真去考慮并且規劃。

當然，長遠的產品規劃在很多情況下（市場變化、團隊更替、產品轉向）確實用途不大，但越短期的規劃，對研發團隊越有幫助。

正常來說，預估三個月內產品的功能還是完全可以的，除非老板和產品經理都沒想明白產品到底該做成什么。

把這些規劃想明白，并傳達給研發團隊，讓他們在現在的代碼里就給未來的功能留下空間，是最好的避免代碼重寫的方法。

2. 提供需求要足夠具體

這要求產品經理做到兩點：

第一，讓產品需求文檔特別特別具體。

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

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

你給了研發 5 個頁面，結果研發做著做著，來問你，好像缺了個頁面。你補完一個，研發做了一會兒發現又缺了一個...最后七零八碎的 10 個頁面拼湊出來，發現根本不好用，所以又推倒重來。

如果研發經常來問你某個地方該怎么做時，你就要反思是不是需求文檔寫得不夠好了。

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

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

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

3. 熟悉基本的研發背景和研發能力

『產品經理到底需不需要懂技術』是我被問到的關于產品經理的問題中的 TOP 5。

這個問題我的回答是：要按照需求，了解基礎知識，并不需要知道實現細節。

了解基礎知識、不需要知道細節是指產品經理應當知道最基本的一些理論。

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

比如是在手機網頁上的產品，要知道哪些交互是在 H5 上較容易實現的，而哪些交互是實現效果非常糟糕的。如果依照在 iOS 上的動畫效果來要求 H5，開發成本可能會是指數級上升的。

按需，是說對于產品經理，千萬不要買《iOS 入門指南》、《安卓開發手冊》或者《H5 設計實例》來學習，除了裝點下書架不會有別的意義。

因為本身開發的指南和手冊，講述的全是實現細節，對你清楚安卓的基本控件或者 H5 的常用交互完全沒有幫助；同時，不同的產品有不同的特性，也有不同的代碼特點，你只需要了解你負責產品的技術背景即可，有的同學居然決定從 C 語言先開始看，簡直是讓人扼腕。