從程序員到產品經理，本文作者收獲頗多，借此文對個人經歷做個總結和復盤，也希望能夠給大家一點思考和啟發。

大家好，作者本碩均是計算機專業科班出身，畢業后一直從事軟件開發工作，先后經歷了Windows開發、Android開發、JAVA接口、微服務及HTML頁面相關的開發工作。

本文作為作者從事技術開發工作6年后轉崗產品經理的一些經歷和心路歷程，記錄并分享出來給需要的小伙伴參考，僅作為個人的經歷總結和復盤思考，歡迎大家留言討論，一起進步。

一、前世

1.1 把不擅長的事情變成擅長也是一種能力

在很多年以前，記得剛讀大一的時候，第一次上C語言實驗課，一段實驗代碼怎么都運行不出結果來，只好求助旁邊看著比較厲害的同學，同學過來看了看錯誤日志，經過一番分析，準確快速地解決了問題（這個場景相信開發同學在日常工作中很常見）。第一次感覺到人和人之間的差距盡然會這么大，對于自己毫無頭緒的問題，別人可以這么游刃有余的解決。

佩服之余，更多的是對自身的反思。有果必有因，經過后面不斷的摸索和思考，總結原因可能是沒有掌握程序調試的方法技巧；英語底子薄，錯誤日志讀不明白；自身興趣和態度問題等。

不同原因逐個攻破，在后續的學習工作中，不僅逐步加大了自己對“寫代碼”“調試代碼”的實踐能力，還對英語進行了惡補（當時也是為了考過四六級）。

在畢業時不僅編程能力顯著提升，英語水平也提高了，最終以63分的英語考研成績考入了北京某高校讀取碩士研究生。

1.2 技術工作的成就感（編寫一次，到處運行，控制機器的那種快感）

第一次接觸商業軟件開發是在讀研期間，每一個小功能的實現，每一次SVN代碼的提交都會讓我欣喜若狂?？粗约簩崿F的軟件功能被很多人使用，看著自己寫的代碼在不停地運行，不斷地產生數據，內心的成就感油然而生。

自此，未來的幾年都是在代碼的世界里不斷探索，不斷去尋求突破和成就感?；诖?，在畢業那年順利進入了一家知名企業擔任Android軟件開發工程師，自此開始了我的職業生涯。

（工作后的我也將近胖了20斤，可能是有了收入伙食變好了，也或許是到了該發胖的年紀。）

從拿到offer工作近兩年后，由于公司大量使用H5頁面替代Android原生開發，Android開發任務逐步減少。公司提供了兩個轉崗JAVA后端開發的名額，我毅然決然地轉崗的JAVA后端開發，主要是出于兩個原因：第一，我認為Android開發只是一整套系統開發的冰山一角，從事后端開發可以從整個項目的角度去思考，包括整體業務考慮、數據庫設計、接口設計開發以及H5頁面的實現等；第二，我在讀研期間前后端開發工作都有涉及過，轉崗只需要很少的時間和學習成本。

事實證明，這次轉崗也是非常順利成功，使我較深入理解了企業級商業軟件前后端的開發模式和工作流程，即便是現在作為產品經理，也是受益匪淺。

1.3 轉崗產品經理的原因

從開始C語言的學習到逐步入門軟件開發行業，然后從單純的軟件開發工作走出來，我走過了近10個年頭，也正是因為這樣的年齡關口使我不得不重新思考未來的職業規劃。從典型的軟件開發轉崗到產品設計崗，可能是我一條還不錯的轉型方案。

如果把產品經理工作比喻成建造房子，那么程序員的工作就相當于是建造房子所必須的木工或泥工，而項目經理則相當于是包工頭，在規定的時間、地點、人力物力有限的情況下，按質保量完成房屋建造任務。

產品經理重于“想”，程序員重于“做”，程序員總是在不斷實現產品經理的idea。

在這個實現過程中，程序員通過選擇某種或某幾種技術實現產品功能，從而獲得功能實現和技術提升的成就感。而產品經理的成就感則來自于一個idea從腦海到落地，從上線和用戶服務中獲得。

做一個能給用戶帶來價值或者給企業帶來效率提升的產品，將會極大提升產品經理的成就感。

二、轉型（開發工作積累與產品思維）

2.1?技術積累

對于一個軟件開發者來說，如果只是專注于產品業務和功能模塊的實現，而不注意個人技術矩陣的積累，那么在未來的職業生涯發展中可能帶來較大的風險。

在我剛參加工作那會，更多的就是關注產品業務，實現產品功能，對軟件某些業務模塊的理解程度甚至超過當時的一些產品經理。后來，我發現，一些資深工程師不僅懂基本的產品業務，更加厲害的是他們的技術矩陣和學習能力特別強，在工作的時候總是在改進方法，使用新技術，在工作之余也是不斷完善自身的技術架構，掌握時下熱門應用技術和框架，比如大數據相關技術、微服務系列、docker、一些前端JS框架等。

基于此，我也開始注重個人技術積累，嘗試使用新學的技術，并不斷自學一些新技術。這樣的一個過程，使我極大豐富了自身的技術架構，從開始入門的C/C++/C#語言、到中期的Java語言，Android開發、SSH架構，SSM架構到時下流行的微服務架構、Vue.js，JQuery等前端框架以及linux、數據庫等知識都有涉及，這都為我后續的產品經理工作打下了良好的基礎。

2.2 產品與業務

不記得曾經多少次評審過產品經理JIRA上的需求文件，也曾為了完成需求文件的提問KPI而“被迫”進行提問。絕大部分的程序員都是不太情愿逐字逐句的去看需求文件，他們會覺著產品經理需求文件太啰嗦。

但是，從產品經理的角度看，需求文件描述不到的功能點，又會被開發吐槽，這個鍋注定還是要產品經理背。所以，一般靠譜點的產品經理都會在需求文件中盡可能描述全面，細節描述到位。

曾經在老東家做一個智能組卷的需求，有一個新入職不久的產品經理負責這個需求，而我則負責這個需求的具體編碼實現。

在做需求評審的時候，我發現他的需求原型上畫了篩選條件，按章節/知識點進行匹配組卷，但具體的匹配規則則沒辦法提供。由于可能不懂數據庫相關知識，不了解數據模型的原因，甚至連章節、知識點、試題的對應關系都搞不明白；知識點-試題，是個多對多的關系，章節-試題也是多對多的關系。

鑒于此，最終由我來設計智能組卷匹配方案的規則，上線后很好地滿足了一線學校對此功能的需求。組卷匹配方案簡單來說就是個加權算法，對每個匹配出來的試題結果進行打分，按分值高低進行優先級排序。

比如，用戶選擇了三個知識點，則將匹配出來的試題分為以下幾類：試題剛好滿足知識點要求且只包含這三個知識點（優先級最高）、試題包含知識點但沒有全覆蓋知識點（覆蓋率越高，則優先級越高）、試題超出知識點范圍（超出比例越小，則優先級越高），無匹配知識點試題（優先級最低）。

作為一個軟件開發者，每做一個功能、一個產品，我都會去思考這個功能、產品到底能夠給用戶帶來什么價值，公司又是如何通過這個產品來變現的，有沒有可以替代的方案，新方案是不是可以簡化開發流程、節省開發工時或者能提升系統性能，甚至可以提升產品的用戶價值。通過對需求文件的深入評審，產品設計得到了較好的改進。

2.3 項目管理與整體研發流程

在幾年的軟件開發過程中，經常負責多個需求的開發對接工作。通過對各個需求文件的工時評估及人員工作分配和管理，到最終的測試上線，讓我掌握了基本項目管理能力。當然，我也自學了一些項目管理的理論知識。

同時，作為新員工導師，對新入職員工進行必要的技術及業務流程培訓，使我對已有工作進行梳理和總結的同時建立了與新員工的良好友誼，這些革命的友誼也將是未來持續發展的星星之火。

此外，我也積極參與公司號召的技術、業務分享會，也曾作為技術分享主講人做過公司內部的技術分享會。

三、今生

3.1 產品經理工作內容

轉崗產品經理后的工作內容，做過開發的同學相信都比較清楚了，無非就是以下這幾個方面：

• 需求收集（來源：競品分析、運營需求、老板需求、產品迭代改進等）；
• 需求分析（去偽存真、優先級劃分）；
• 產品設計及內部評審（需求提出方、產品同事、分管領導等）；
• 需求PRD文檔講解；
• 項目管理（工作量、進度、質量、性能要求等）；
• 產品測試與驗收；
• 產品上線和數據分析。

在我轉崗產品經理近一年的時間里，上面的所有工作我都經歷過，也有一些較為豐富的實踐經驗，也有一些產品方法論沉淀，在此先不展開說明，后續抽空再做個詳細記錄和總結。

3.2 產品工作中技術出身的優越性

• 與開發人員無障礙溝通，可以準確估算項目工時及兼任項目經理崗位；
• 在需求原型設計時，有效考慮需求技術實現性和性能問題，給開發講解需求順暢；
• 較好的需求管理能力，比如需求收集、排序，需求穩定性、版本迭代設計等方面具有較好的能力；
• 具有較好的信息收集能力（如競品數據分析）和數據分析能力（如統計報表分析）。

3.3 轉行需要跨過的一些坎

• 需要進一步加強組織、協調、溝通能力，很多問題困擾太久，要是能盡早溝通，主動溝通可能就不是個問題；
• 需要走出產品技術實現細節，進一步拓寬知識邊界，包括基本的UI、運營知識，行業知識認知等；
• 心態的轉變，程序員喜歡做確定的事情，而產品經理做的幾乎都是不確定的事情，本身不確定的事情被別人撕，容易出現心理障礙，因此需要擺正心態，積極面對；
• 需要加強產品經理的決策能力，要對需決策內容利弊足夠了解，果斷裁決，對結果負責。

3.4 產品工作的一些體會

產品工作的成就感雖然沒有程序員敲代碼那么強烈，但是產品經理的成就感是更深層次的。一個好的產品設計在滿足用戶需求和體驗的情況下，還能為開發節省大量的工時，為企業節省成本開支。

對我來說，從無到有完成一個產品的設計、開發、上線，并對用戶產生價值，這種成就感才是最真實的。

產品經理的工作可以讓我更加貼近生活，更多地去思考身邊的人和事，而不是只是鉆在代碼里，兩耳不聞窗外事。慢慢地，我發現自己和身邊的一切都在改變，因為我們看待事物的觀念變了。

關于產品經理工作相關總結，后續我將進一步梳理和記錄，期待與各位一起成長。

作者：李生才；聯系作者：lscncut@163.com

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

題圖來自 Unsplash，基于 CC0 協議