本文作者主要總結(jié)了自己在畢業(yè)后入產(chǎn)品這一行里，踩過的坑和學(xué)到的一些知識。一起來看看~

還沒畢業(yè)的時候，因為畢竟欠缺相關(guān)經(jīng)驗，我進(jìn)入了一家做智能硬件的創(chuàng)業(yè)公司實習(xí)，從此開始我的產(chǎn)品之路。從去年4月份到現(xiàn)在在這里也有一年多時間了，雖然平時有寫工作日志，但還沒有系統(tǒng)全面地復(fù)盤總結(jié)。得承認(rèn)，還不是因為懶。

很幸運(yùn)，我的主管也就是我們公司的產(chǎn)品總監(jiān)，他是國內(nèi)一流院校畢業(yè)的工科生，有10年的行業(yè)經(jīng)驗。令人驚訝的是，他好像樣樣都懂，尤其是技術(shù)層面，而且邏輯清晰、思維敏捷，可以快速從復(fù)雜的業(yè)務(wù)流程中理出頭緒并得出可供參考的方案，雖然可能不是最優(yōu)的方案，但能夠在短時間做到這點我很佩服。

一開始主要是熟悉當(dāng)前運(yùn)營的幾個平臺，以及業(yè)務(wù)流程和功能邏輯。那時候我們平臺組的產(chǎn)品就我老大和我倆人，遇到問題我只好去問測試和開發(fā)的小伙伴，因為老大忙，我也只能挑晚上下班后去打擾，一開始熟悉的速度也慢，跟開發(fā)討論問題都沒有底氣，自信心明顯不足。

開始熟悉

（1）打基本功

慢慢地老大陸續(xù)交給我一些我們內(nèi)部平臺和后臺系統(tǒng)中某個功能點的設(shè)計，單純的進(jìn)行某個功能點的設(shè)計，跟開發(fā)討論出方案并執(zhí)行落地、上線，這個階段的我更多是一名執(zhí)行者和初級的推動者。

老大其實是做好需求分析和功能設(shè)計了，我的任務(wù)就是幫他把構(gòu)想轉(zhuǎn)換成原型交互、文檔。這一階段就是在跟團(tuán)隊磨合，打基本功。

（2）承擔(dān)責(zé)任

后來老大交給我負(fù)責(zé)我們唯一的對外開放的平臺型產(chǎn)品，這個平臺其實作為我們很多業(yè)務(wù)的入口和展示有一定的戰(zhàn)略作用，但由于早期的人手不足，在開發(fā)上線后一直處于疏于管理的狀態(tài)，沒有及時的迭代。很多業(yè)務(wù)端的需求還沒有實現(xiàn)平臺化，而且與市場上的競品相比有一些差距，平臺可以說是“百廢待興”的狀態(tài)。

（3）需求管理

隨著我對這個開發(fā)者平臺的接手，越來越多的需求直接或間接從業(yè)務(wù)端導(dǎo)給我，這時就涉及到了對需求的管理以及其優(yōu)先級的判斷，這就對我提出了更高的要求。我需要站在更高的角度去審視整個產(chǎn)品，梳理出所有的功能、業(yè)務(wù)邏輯，從而去思考我們要做的需求在整個產(chǎn)品中的實現(xiàn)方式。

（4）項目管理與封閉開發(fā)

前段時間，我們有一個內(nèi)部的平臺需要開發(fā)，因為老板催得緊，我們快速地成立了一個不到10人的小團(tuán)隊赴外地進(jìn)行封閉開發(fā)，我有幸作為項目owner負(fù)責(zé)項目的整體質(zhì)量。

從最初的交互設(shè)計到與視覺定稿、評審開發(fā)、與開發(fā)溝通、測試驗證，到最后項目按期完工，我發(fā)現(xiàn)封閉開發(fā)的效率還真的是高，有問題一說大家一起討論馬上就能出方案。這對我來說真的是很寶貴的經(jīng)驗。

（4）競品分析

這個工作平時做的較少，也沒有人要求做，因為我們的產(chǎn)品本身就已經(jīng)很多需求在排隊。我自己會偶爾看看我們主要的競品的平臺，保持持續(xù)地關(guān)注，分析思考各自的優(yōu)勢與功能的適用場景，并定期更新競品分析報告，更新的頻率一般是一到兩個月一次，可以看到競品最近迭代了哪些功能和內(nèi)容。

（5）兼容性考慮

同時我負(fù)責(zé)的平臺跟公司其他系統(tǒng)平臺是有數(shù)據(jù)流通的，所以針對某些功能的設(shè)計需要考慮到跟其他平臺的兼容性。比如：我在新的版本中要增加幾個字段，那這些數(shù)據(jù)結(jié)構(gòu)就變了，因為開發(fā)會改變新數(shù)據(jù)存入數(shù)據(jù)庫的表結(jié)構(gòu)，那對于以前的老數(shù)據(jù)如何兼容？

因為老數(shù)據(jù)是沒有這些新增的字段的。

踩過的坑

（1）需求理解不一致

開發(fā)、測試對業(yè)務(wù)流程、版本要達(dá)到的目的理解不充分，不清楚需求的意義以及它能解決的問題。而且是發(fā)生在項目開發(fā)階段之中，評審會已經(jīng)通過了并且都已講過的……所以開發(fā)過程中的及時溝通還是很重要的。

（2）需求的變更沒有保持團(tuán)隊的信息同步

導(dǎo)致開發(fā)測試信息不對稱，變更的需求測試不充分。我們是一個團(tuán)隊，如果真要變更需求，一定要保證大家信息同步，而且開發(fā)過程中盡量不要做需求變更……程序猿們會很難受。

（3）周五進(jìn)行版本升級，線上出了問題

周五晚上進(jìn)行的版本升級，結(jié)果到線上發(fā)現(xiàn)有嚴(yán)重的bug，只好晚上熬夜解決，最終看當(dāng)天是解決不了的，跟老大商量還是決定做了版本回退，血的教訓(xùn)。

（4）偽需求的開發(fā)

業(yè)務(wù)端提的需求，而且還是高優(yōu)先級插隊進(jìn)來的，我們開發(fā)完，后來他們又說其中某個模塊又用不到了……需求的真實應(yīng)用場景沒有分析充分，業(yè)務(wù)端過來的需求有的他們自己都沒想好，需要更合適的方法去解決。

（5）早期的思維錯誤

為了趕進(jìn)度而出的原型，未考慮完全，存在明顯的硬傷，即使評審也問題很多，對開發(fā)無益。應(yīng)該在保證自己工作質(zhì)量，即使因此delay了也不要為了趕進(jìn)度強(qiáng)行輸出，這樣的方案一定是漏洞百出的。

（6）兼容性問題

平臺的某個模塊升級，而未考慮到跟它相關(guān)的老數(shù)據(jù)的兼容性而出現(xiàn)問題。這個設(shè)計缺陷當(dāng)然就被我們測試leader抓住了，我接鍋……

后來老大語重心長地引用《孫子兵法》中“先為不可勝，以待敵之可勝”來勉勵我，讓先武裝好自己，等把自己武裝到?jīng)]有弱點，再去發(fā)現(xiàn)敵人的弱點。

周會的收獲

每周一早上我們會召集研發(fā)各部門負(fù)責(zé)人的周會，CTO主持會議，老大讓我每次都參與旁聽， 因為涉及到公司所有業(yè)務(wù)線的所有環(huán)節(jié)，我更多時候是懵逼狀態(tài)，但聽的多了自然是對自己的工作有些收獲與啟發(fā)的。

（1）一個需求的導(dǎo)入需要思考

現(xiàn)存哪些問題–>期望達(dá)到的目的–>功能使用的場景–>驗收要達(dá)到的效果–>期望完成的時間點和優(yōu)先級。

（2）閉環(huán)意識

任何時候都要有閉環(huán)意識，多思考一個功能/產(chǎn)品在整個業(yè)務(wù)閉環(huán)起到什么作用。

（3）關(guān)注原始需求，思考最優(yōu)的解決方案

因為有些需求，看似是一個需求，要挖掘出他們的根本需求，他們?yōu)槭裁刺岢鲞@個需求，遇到了什么問題，實際上總有更好的實現(xiàn)方式，最好的做法不是滿足客戶/用戶的需求，而是在滿足他們的基礎(chǔ)上，讓他們感到驚喜。

其他的點

（1）身兼多職

因為我們還是創(chuàng)業(yè)公司，人手不多，所以在我們規(guī)劃版本時需要身兼多職，不僅要規(guī)劃好這個版本要上的功能，還要做好交互設(shè)計并盡可能的去照顧用戶體驗，同時還要兼任項目經(jīng)理，保證項目按期完成。

（2）設(shè)計

交互設(shè)計的能力在這一年中得到了極大提升，最開始用axure連動態(tài)面板都不會用，原型丑陋到滿屏的黃色隱藏框，因為要做多個彈框，到現(xiàn)在我還保存著最初的原型文件。

（3）運(yùn)營

因為我所負(fù)責(zé)的是平臺型產(chǎn)品，用戶一般是跟我們合作的TOB的客戶和一些開發(fā)者，所以這里沒有怎么涉及到留存、促活以及數(shù)據(jù)分析，就是做一些日常的平臺維護(hù)與審核工作。

（4）技術(shù)

平時跟開發(fā)測試溝通的多了，“技術(shù)黑話”不得不去了解，接口、表結(jié)構(gòu)、寫死、post請求……

代碼打包、部署，以及前端頁面的“檢查元素”查看請求的后端接口與響應(yīng)……為了更順暢地跟程序猿哥哥們溝通，這些還是很有必要加強(qiáng)的。

作者：舅本華，微信公眾號：舅本華

本文由 @舅本華 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Pexels，基于 CC0 協(xié)議