產品經理的成長往往需要歷經多個項目和實際演練，而在這個過程中，產品經理可能會因為項目或實際工作中遇到的問題而產生一些疑惑，比如產品經理為什么有時候做的事情，并不屬于產品經理的崗位范疇？這些事是否真的有意義？本篇文章里，作者也有相似的困惑，不如來看看他的成長思考。

一、背景

畢業后在一家中型互聯網公司某部門就職產品經理崗位，部門以公司產品為開發平臺，承接各種數字化轉型項目，以項目經驗孵化各行業普遍共性問題的解決方案。入職以來，日常工作內容為需求調研、需求分析、產品設計、跟蹤開發、產品測試、用戶反饋與功能迭代、實施與交付。

二、問題

由于團隊人員配比不足，無法細分職責到具體崗位，每天面對多而繁雜的各種事，難免會產生疑問：明明是產品經理，為什么感覺大部分的時間都在做非產品經理的事？做這些事有沒有意義？

三、經歷

1. 了解公司，了解部門、了解項目、了解團隊

公司是一家傳統的面向工業行業的互聯網企業，客戶對象大多是重資產流程性行業，而部門某種意義上可看作公司的外包，專門負責啃硬骨頭，負責處理時間緊、任務重的項目，若人手不足，直接調配外包人員來堆疊人力，因此部門的人員流動較大，工作交接過程中信息損耗程度極高。

可能是由于上市盈利和經營范圍要求，公司承接了一個集成化大型系統中的陌生領域的B to C子系統，項目特點是上線時間要求急，開發任務量大，合同范圍邊界不清晰，需求模糊，用戶的數字化水平低，決策分散等。

項目從立項至終驗經歷了整整2年時間，大概時間節點為2021年1月-4月項目立項、調研；2021年5月-7月項目開發，部署；2021年8月-10月修補功能，初驗；2021年11月-2021年12月完善功能，產品上線；2022年1月-2022年9月產品優化與迭代；2022年10月項目試運行結束，終驗。

由于人員配比不足，研發組長由于主要精力都在項目中的C端方向，所以默認B端方向由我單獨來安排計劃與分配任務，在團隊中兼任項目經理、產品經理、測試、交付與實施的角色，即除了寫代碼，其他工作均是我來完成。歷經一年多時間，在只有不到1.5個開發人力的情況下，系統按期上線，并保障穩定運行10個月。

2. 區分客戶、區分用戶、區分項目、區分產品

1）選型失誤，舉步維艱

項目開發與優化周期接近18個月，經歷了多次返工及功能迭代，導致原本12個月的工期延長到了18個月，究其原因，工作到產品經理層面的時候很多前置工作已經確定，根據招投標文件確定好技術架構，領導層面出于種種原因會根據功能清單及標書要求選擇合適的開發平臺。

但是領導也有預估不到的情況，有時也會判斷失誤，因此再決定技術架構及產品選型之前的技術討論將是啟動前期需要仔細論證及決策的，否則項目一旦啟動，地基開始搭建，后續更改技術架構幾乎是不可能的事項。

評審需求時經常遇到開發的答復說實現不了，某些功能依賴于技術平臺，平臺不支持的功能，他們也沒辦法，大多數人不想做第一個吃螃蟹的人，不想去通過自己寫代碼實現某些定制化的需求。而一些需求又確實不能妥協，通過現有的技術平臺又無法實現，產品和研發之間就差打起架來，功能上線寸步難行，

2）五臟不全，效率低下

一個合格的團隊是由項目團隊、產品團隊、開發團隊、測試團隊、UED團隊等組成。在項目制為主的公司里，構成往往不會這么全，實際情況往往是身兼多職，公司會讓開發人員兼職“交付經理和項目經理”既負責開發工作，又負責現場的需求收集及項目交付；讓產品經理兼職實施和交付人員，常駐現場，直接對接客戶需求……

項目開展過程中，主要的工作內容是對接主要用戶收集一線需求、與主要領導溝通匯報項目進度、協同其他廠家對接系統、產品原型設計、系統業務測試、產品培訓與項目實施等工作。因此每天的時間安排十分混亂，經常多事并行，優先級不僅僅由需求側確定，很大程度上也受限于人員的效率。

可想而知，在多任務并行的情況下，每項工作都無足夠的時間處理，尤其是設計階段的思考、測試階段的場景覆蓋。在這種背景下，項目進度無法明確把控進度，而且很多突發事項經常打亂節奏，看起來公司節約了人力，實際上效率大打折扣。

3）決策慌亂，迷失方向

決策能夠直接影響項目的成功與否，無論是團隊內部的管理決策還是客戶對象的需求決策都能影響產品上線的質量。在團隊里，項目經理負責需求和工期的決策、產品經理負責功能與設計的決策、研發經理負責上線時間及產品質量的決策，三者兼備才是保證一個項目高質量交付的基礎，同時還需要業主方的配合與決策把關。

從大的方向看此項目屬于智慧城市項目范疇內，系統建設具有一定的非標準化特性，由于主要一把手的管理思維不同，定制化項目基本上是常態，因此對于關鍵問題的決策將會直接影響一個項目的成敗，衡量好各方利益得失，以最小的成本贏得項目的快速交付將是考察一個團隊的核心指標。

智慧城市項目大多關聯管理者的政績要求，因此大多數項目都會要求快速部署。根據前期的功能清單快速搭建起業務系統，而后根據甲方需求再進行修改，這種實施方案在行業內可能已經屢見不鮮，大多數公司能較好的完成初期的工作內容，交付出部分常用且重要的功能，待回款建立強關聯關系時再逐漸響應優化內容。

倘若決策失誤，或者關鍵節點未向領導匯報確認，一旦自以為是，盲目開始，勢必會出現需求不符合管理者要求的狀況，項目勢必返工，浪費人力、財力。找準能做決策、能拍板的領導者，將為項目直接指明方向。

4）定制開發，不成體系

用戶會隨著場景的不同產生不同的需求，對這種特殊需求的分析能力是考驗產品經理基本能力是否過關的一個有效驗證。

一般情況下，對于簡單的功能需求，只需要產品經理抽象出業務流程，通過流程圖、線框圖等可視化圖形表達出模型向甲方確認后產出原型即可進入評審階段，開發團隊會基于現有開發平臺能力，和過往的開發經驗認知對功能設計給予評價和反饋，兩方達成一致，即可進入到功能開發階段；而對于較為復雜的功能需求，則需要產品經理能夠準確的理解甲方的意圖，尤其是具備話語權或者領導者的特殊要求。

對于開發而言，以標準化的通用需求快速開發部署，直接浪費前期的大量工作量。

比如查看考勤詳情需求，一般而言設計思路是按照根據組織架構自上而下按照公司、部門等維度以時間、個人為檢索條件查詢考勤記錄和員工出勤情況，而管理者希望是通過員工一次的考勤情況直接擴大范圍查詢一段時間內的考勤記錄，交互操作上的差異是：【選擇部門-選擇時間-選擇人員-切換時間】和【選擇部門-選擇人員-選擇時間】，因此在設計的時候，若無法洞察到管理者的特殊訴求，很容易給客戶留下業務抽象能力和理解能力不足等印象。

然而這類項目倘若直接以客戶表達的訴求為設計終點，又容易陷入后期客戶變更需求導致的增加開發工作量，而通用的功能設計實現難度較大，開發成本較高，因此如何以合情合理的理由說服客戶對產品經理來說也是一個極大的考驗，讓客戶相信團隊的專業度，相信給出的建議是具有權威和信服力的，才能有效避免一些由客戶需求變更帶來的附件問題。

5）工期緊張，變相偷懶

項目過程中由于業務體量較大、工期緊，中期增加了很多外包人員，由于項目欠缺項目管理，整個開發過程散亂、無序，各種規范均未建立起來的情況下就貿然開始開發，后果可想而知：缺乏產品文檔，導致開發起來全憑產品經理的口述；缺乏接口文檔，交接梳理降低了開發效率；缺乏測試文檔，導致bug復現率極高且場景測試不全，產品上線后發生了很多事故。

于個人而言，由于團隊配額不足，推動建立體系和規范的過程無法一蹴而就，且需要整個團隊的配合，對于部門的管理風格來說也是不切實際的，因此到后期基本演變成各個崗位為減少自身工作量各自為戰，變相的偷懶，表面上是快速解決了當下暴露出的問題，實則降低了項目交付的效率，因為問題遲早都會暴露，只不過都默認了解決問題的那個人并非自己。

因此在這種環境下就不得不去適應并且尋找方法增加效率，對產品的負責態度、個人的工作態度在這個時候便會突顯非常重要的價值，以自身的工作態度影響團隊成員，并促使大家保持一致的目標，讓所有人能感受到成就感，項目才不至于一塌糊涂，畢竟亡羊補牢，為時未晚，但凡是個正常人都不會想著項目越做越差，只會越做越好。

3. 人力成本、開發成本、時間成本、項目成本

兼顧多個崗位帶來的直觀感受是在各種成本之間學會了平衡與取舍，專職產品經理時，一心只想著優化體驗、滿足客戶需求、迭代功能等。

而現在懂得兼顧人力成本（投入的團隊人數）、開發成本（需要的開發資源及時間）、時間成本（項目交付期限內需要的時間）、項目成本（項目利潤），考慮的是能否在使用合理資源的情況下，較好地完成一個功能的上線，會去結合團隊整體的情況評估需求的優先級，合理排期，安排資源，從而更好的保證開發進度，促進項目正常交付。

但是弊端也很明顯，作為產品經理，首要考慮的應該是需求合理性及功能的適配性，開發資源等要素不是考慮的重點，這樣以來主要精力會被占用，導致一部分精力受限或者限制功能設計的可擴展性。

領導常說我們做的是項目，不做產品，有些功能不用考慮那么完善，滿足客戶需求即可，不用耗費較大的人力成本去開發一個使用人數較少，適應范圍較大的功能。

但從個人成長的角度來說，設計的時候還是要以產品的角度考慮功能，評審后再針對具體的項目進行簡化和取舍，否則時間久了設計思維和設計視野很快就會被限制在一個開發平臺內，對產品功能的嗅覺能力會變得極不敏感，最后儼然變成一個處處妥協的完全聽從客戶要求的“傳話人”而非“需求分析師或者產品經理”。

要求所有崗位都能履行職責往往是理想狀態，可遇不可求！大家都希望有一個配合起來很愉快很順利的團隊，都希望和高素質的人合作辦事，和高效率的人一起工作事半功倍，但是往往一個項目的成功和失敗遵循的是木桶效應，項目的上限受限于短板。

作為團隊的橋梁，產品應該學會合理的協調各方，向下兼容，遇到能力和素質較差的不能僅僅只學會抱怨，適當地采用其他方法，站在他們的角度思考，鍛煉同理心，學會與每個人交朋友，才能幫助這個集體成長，幫助項目取得成功。

在有限的資源下，消耗合理的時間，完成合理范圍內的功能開發與交付，才能最大程度的減少項目成本，為部門和公司創收！而平衡好這個關系僅靠一個角色基本上是不可能實現的，但是同時做了多崗位的角色后，再去處理這個關系反而會顯得比較容易，也許這就是做了這么多“雜事”后的最大收獲吧，學會了“平衡”。

四、反思

1. 適當踩坑、變相思考

畢業入職，即是一張白紙，如何在一張白紙上摩畫出美麗的畫卷是每個職場新人和領導應該思考的問題。

大廠或者具備成熟管理模式的外企等單位能夠在新人最需要學習的時候使人醍醐灌頂，成功的人往往是學習能力和執行能力很強的人，這種成長路線是絕大多數人向往的。

而創業公司往往會因為建制不全或者過于扁平化管理的方式則需要吃一墊長一智，經歷過某些事，踩過坑，才能如獲珍寶，成功的則是學習能力和思考能力很強的人，這種成長路線很曲折，稍微不小心就會因為選錯路而掉下山崖，而挺過來的這些人能夠從過往經驗中總結出適合自己的生存之道，讓自己適應于各種環境。

無論選擇什么樣的成長路線，適當踩坑或許能全面鍛煉一個人，一味地執行無法獨立思考，過度放養則顯得雜亂無章。

經歷過的感受才能更真切，踩過的坑才知道哪里最痛，才知道如何一步一步爬出陷阱，才能真正形成自己的經驗。把握好踩坑的頻率與時間，或許更有利于成長。

2. 停止抱怨、順其自然

不是每個人的成長路線都是一帆風順，停止吐槽，停止內耗，學會接收，學會思考。

習慣了與自己節奏相匹配的人合作以后，到了陌生環境，難免會顯得格格不入，會抱怨公司、抱怨領導、抱怨項目、抱怨團隊等，一切的不順利全都歸咎于外部原因。

低價值付出雖然不會帶來短暫的收獲，但是能帶來復利式增長，當下需要的只是時間，等待時間去驗證。

因此，停止抱怨，接受眼前的一切，接受目前遭遇的種種，接受現實給予的“當頭一棒”，待褪去身上的稚嫩，留下的一定是矢志不渝的堅持。

記得朋友說過“理性的分析與計較總會被上帝戲耍，因為總會在某個時候失去一些東西”，不要過度思考，不要自己給自己鉆牛角尖，堅信當下所經歷的勢必會對未來產生影響，并且這種影響一定是積極的。

3. 知己知彼、瞄準目標

隨著經歷越來越豐富，我們的人格也將越來越立體，越來越清晰，什么是符合自己發展需要的，什么是多余無用的基本上是能夠判斷出來。

結合過往，給自己定下來年目標，制定合理且可行的OKR，切忌好高騖遠，不切實際，制定行之有效的方法并嚴格執行才能離目標越來越近，否則只會適得其反，最后因無法實現目標而過度自責，懊悔不已。

真正的去了解自己，揚長避短，一步一個腳印，踏踏實實，向著理想中的自己穩步向前，越過山丘，做難而正確的事！