一直以來我都覺得自己是個典型性程式設計師。

比如出門時候我總是穿格子衫、牛仔褲，戴著黑框眼鏡背個雙肩包；
比如休閒時候我是個死宅，喜歡玩遊戲和看小說；
比如一直到23歲時候我依然是“妹手軟”，沒談過戀愛。

當然可能也有些其他方面的特徵

比如擁有還不錯的邏輯思維能力；
比如我對新技術總是充滿興趣，願意主動學習；
比如我對工作和生活充滿熱情，精力非常旺盛。

就這樣波瀾不驚的工作了幾年以後，突然有一天我不想再天天對著電腦敲程式碼了，我想嘗試一些和人打交道的事情。
正好這時候領導找我談話，問我想不想做需求，於是我就順理成章地從一名程式猿變成了產品汪。

就如自古以來所說的“商而優則仕”以及現在娛樂圈的“演而優則唱”一般，
有的人說程式設計師到了35歲就要考慮轉型，轉管理轉產品或者轉售前。
其實我覺得是否轉行這個事情根本還是取決於個人，
取決於你自己的個人性格、愛好、特長，取決於這些“內因”，而不是所謂的年齡、發展前景、環境因素等“外因”。
簡單地說，你自己覺得你最喜歡做什麼，最擅長做什麼，做什麼事情讓你最快樂、最能給自己帶來成就感，那你就去做什麼。
就比如Java之父，詹姆斯·高斯林今年63歲了還在寫程式碼，並且去年還跳槽去了亞馬遜繼續做雲端計算的開發。

當然我這邊文章主要不是談程式設計師是否轉產品經理的事情，所以對這個問題就此打住。
我從開發轉做需求開始到現在也有一年多了，剛開始轉的時候其實非常痛苦，特別不習慣，經常跟身邊小夥伴抱怨。
但好在自己也是個不輕言放棄的人，不斷自我反思堅持了下來，到現在終於感覺在產品的道路上初窺門徑。
但總的來說，在這個行業裡我依然屬於新人，需要學習和掌握的東西還有很多，再次不敢高談闊論，
只是把自己的一些經歷和理解記錄下來，一則作為自我總結的成果，二則分享給大家，希望能給剛從程式設計師轉產品的人一些幫助。
 

產品知識體系

在這個資訊爆炸的社會，知識是不值錢的。甭管你需不需要，知識就在那裡，堆積如山，當你需要的時候，你只需在網上輕輕點幾下，知識就出來了。
但是知識確實又很重要，因為有了知識你才能搭建出你的知識體系。
微信公眾號“島上十點”的喬治王在知識體系上舉了個例子：
這有點像搭房子，每一塊知識的碎片都是一塊磚，有的人搭了一座尖頂的高塔，因為他可能對某一項知識專精，也有人搭了個四合院，佔地大，什麼都能聊個十塊八塊的，但是絕多數人只是守著一地的磚，它們東一塊西一塊，有的是磚而有的只是泡沫板，根本搭不起房子。
然後他舉一個身邊簡單的例子就是：
我的同事們為了孩子能擠進一個好點兒的小學大費周章，同事不乏美院或者數學類專業出身，教個小學初中生綽綽有餘，但是他們依然給孩子報畫畫和奧數班。
老師往往有成體系的教育方式，怎麼對話怎麼引導怎麼驗證都有自己的方法，知識只是最基本的內容，而家長有的往往只有知識。
所以雖說知識都是一樣，但是幫助你打底子的人不一樣，在如何系統的、多維度的傳授知識上，人家才是專業的。

同樣的，在產品崗位上，我們也有著數不清的知識，
無論是近幾年出版的各式各樣的有關產品經理的書籍，或者是“人人都是產品經理”、“產品經理社群”等網站平臺，
相關的文章、觀點、案例可謂是層出不窮、百花齊放，我們不愁找不到學習的內容。
然而在學習時候，我們就應當順便搭建出自己的知識體系，
比如產品經理的職責主要可分為需求、設計和運營三大板塊；
需求又包括需求調研、需求分析等，設計又包括系統分析、系統設計等，運營又包括市場推廣、內容營銷、活動策劃等；
對於需求調研裡又包括瞭解問題領域、做好涉眾分析、規劃業務範圍、規劃需求層次、進行客戶訪談等，需要獲取業務用例，進行業務建模，提煉業務規則、獲取非功能性需求，然後得到業務需求報告、建立業務模型和領域模型；
而建立業務模型時候我們需要根據業務用例用活動圖、時序圖、協作圖等描述業務用例場景，最後用包圖進行分類......

就這樣一步一步，從職能從上往下的進行劃分，將零碎的知識從下往上的進行聚合，最後最好再用思維導圖畫出來，就構成了一個屬於我們自己的產品知識體系。

而這個產品體系就是我們自己的房子，
具體怎麼搭建，每個人都有一套適合自己的方式；而搭建成怎樣的房子，符合自己的需求即可。
但重要的是一定要有一套自己的房子，這才是自己立足的根本。

產品思維

從程式設計師轉產品，我們需要學習很多新的知識、新的技術還有新的軟體工具，
但我覺得只要是一名合格的程式設計師，無論知識技術還是軟體工具，短時間上手應該都不是問題。
真正最難轉變的是思維方式，是將技術思維轉變到產品思維上。

對於產品思維這個概念一直是眾說紛紜，我對產品思維的理解就是如何做好一個產品的思維方式，
簡單來說就是，我要做一個產品，這個產品的使用者是誰，它解決了使用者什麼問題，它比其他類似產品的優勢是什麼，它的價值（盈利點）在哪。
也就是說作為產品經理思考時候，使用者是第一位，一定要解決使用者的“痛點”，讓使用者覺得好用，並能創造價值。

而對於技術思維和產品思維比較，用下面表格來說比較直接：

技術思維	產品思維
功能	業務
HOW	WHY
像專家一樣行動	像小白一樣思考

功能vs業務
作為程式設計師，當要做一個專案時候，我們最關心的是這個專案有哪些功能，然後考慮每個功能如何實現；
而作為產品經理，當要做一個專案時候，我們看重這個專案的業務場景是什麼，解決使用者什麼問題。
兩種思維方式做出來的產品，很可能就是以下結果：
技術思維做出的產品，柴米油鹽食材一應俱全，但使用者需要做什麼菜都能實現，但是需要自己配各種佐料和食材；
產品思維做出的產品，就是已經把每種菜的食材佐料配好了，使用者直接選擇就可以。
就好比美圖秀秀，它面向的使用者是廣大普通社會群眾。
這些使用者首要關心的是把自己的照片美化，所以有了一鍵美圖。
假如它只提供了各種美圖的方式，我想很多像我一樣的直男或者非專業人士一定不會考慮去使用它了。

HOW vs WHY
有一種方法叫“5W1H”法，即分析問題時候思考下： 
why：為什麼做
when：什麼時候去做
who：誰去做
what：做的目的是什麼
where：從哪裡入手
HOW：怎麼做
從技術思維的角度關注一個需求時候，總是先關注一個需求如何去實現，即HOW；
而從產品思維上來關注一個需求時候，應該多問一下WHY，為什麼需要這個需求，多思考為什麼，從而找到需求或問題的本質。
引用人人都是產品經理社群作者@有趣的程式設計師的一個例子就是：
哈佛商學院教授西奧多.萊維特曾說過，”人們不想買一個四分之一英寸的鑽頭，而是想要一個四分之一英寸的孔。”
作為技術人員時，遇到這樣的需求，你需要考慮的是How，如何提供給顧客四分之一英寸的鑽頭，鑽頭要多長多鋒利等等。
而作為產品，你需要考慮的則是Why，你要思考或是詢問為何顧客需要一個鑽頭呢，自然不是回家擺著，而一定是他需要打一個洞。
那麼再問，為何要一個洞，可能答案是掛一副畫，裝飾一個牆面等等。
等你挖掘到客戶的真正需求時，你的解決辦法就不僅僅是給她一個鑽頭而已

像專家一樣行動vs像小白一樣思考
作為程式設計師，我們日常接觸到最多的還是技術人員，這些人一般來說邏輯思維都較強，擅長使用和處理各種軟體，所以總是將這種形象代入到客戶身上。
但作為產品人員思考時候，將使用者想得越“小白”越好，假設他們是不懂電腦，不太會玩手機，甚至不會打字的人。
比如我們在設計手機APP時候，其中一個原則就是簡單，易上手，不需培訓。
如果我們做的東西，給我父母年齡段的人使用也毫不費力的話，那就說明這個產品真的滿足了簡單、好用。
當然這點挺難的，尤其是對於一些功能性的軟體，但我們在思考時候也得必須考慮到這點。

產品方法論

在各個行業和崗位上都有一定的原則和經驗，歸納起來，就成了方法論。
產品和技術一樣，需要通過不斷的學習和積累加上不斷的思考才能有所突破，
對於我來說，以下是我這一年多以來形成的自己的一些做產品的方法，算是拋磚引玉，給大家做做參考。

專案啟動
任何產品啟動都有其啟動的源頭，即其願景。
瞭解願景的方式有很多，可能是招標檔案，可能是相關業務調研，也可能是公司的商業戰略。
具體的方式跟行業或者產品型別相關，但在專案啟動時候一定要搞清楚這個問題：
為什麼要開發這個系統？我們用這個系統能解決什麼問題？
接下來是進行涉眾分析，搞清楚這個問題：
誰關心這個系統？會涉及到他的什麼利益？
然後就是投入和風險：
這個系統願意花多少錢？允許多少時間？
客戶參與度如何？有沒有度量方式？技術上是否存在風險？是否有重要人物反對？以前是否被取消過？
在專案啟動前對專案進行提前摸底，才能順利進行接下來的工作，避免返工以及儘可能避免風險。

需求分析
在專案啟動時候我們瞭解了專案的願景後就可以開始梳理業務流程，進行需求調研了。
業務流程是和現實掛鉤，客觀存在的，進行業務流程梳理時候需要拋開計算機的概念，這樣才能徹底搞清楚客戶的業務。
根據專案的願景我們可以把專案按照法律法規、崗位手冊、職務說明等或者直接的客戶訪談拆分為一個個的業務，
並確定每個業務的範圍、目標、流程和涉眾期望，從而獲取業務用例。
然後用文字、活動圖、時序圖等方式將其表示出來，即形成一個個業務模型。
需求調研是一件很繁瑣的事，其難點在於使用者的需求難捕獲、易變。這時候我們可以把自己想想成使用者，然後問這幾個問題：
對系統有什麼期望？打算在這個系統裡做些什麼事情？
做這件事的目的是什麼？做完這件事希望有一個什麼樣的結果？
當每個需求我們自己都能回答好這幾個問題時候，自然做出來的業務模型就是合理可用的模型了。

系統設計
根據我們需求分析的結果，就可以進行系統設計了。
將業務用例抽象為系統用例，即考慮如何用系統實現這個業務，為完成這個業務我需要哪些功能？
確定完功能以後，接下來考慮的是互動設計和視覺設計。
互動設計即系統如何和使用者進行互動，使用者如何一步步作業系統以完成對應業務；
視覺設計即系統的UI效果。
有的人可能覺得UI效果交給美工就行了，但我覺得產品經理一定要參與視覺設計，
首先優秀的視覺效果一定是和業務掛鉤的，
比如某個按鈕圖示，其圖示內容就應該讓客戶知道這個按鈕大概是做啥的，
或者介面的整體風格配色，也應該是和業務背景掛鉤的。
而這些業務和功能，產品經理應該是最熟悉的，所以他也是必須參與的。
當然進行這些設計時候還有很多原則，比如主頁面一定要清晰、儘量避免繁瑣的操作，儘量將資料視覺化展示等。

其他注意事項
產品經理作為承接使用者和技術人員角色，溝通能力是非常關鍵的；
產品經理需要控制整個產品的進度，包括事情的優先順序和整體資源的協調；
產品經理一定要有責任心，敢於擔當，敢於背鍋；
產品經理要和各個部門打交道，所以最好培養出良好的人際關係。

最後再說點什麼

我覺得程式設計師是最適合轉產品的崗位了：
一則是程式設計師大都有較強的邏輯思維能力，可以很好地完成分析和設計工作；
二則是程式設計師懂技術，轉產品以後和技術人員交流更協調；
三則是程式設計師出身的產品經理設計的產品，產品開發往往根據可行性更高。
當然是做程式設計師還是做產品經理，主要還是看自己的內心，
沒有最好的崗位，只有最適合自己的崗位。
如果你決心要進入這個領域，別懈怠，別放棄，持續努力下去吧，去迎接更好的自己！