筆者在某雲計算廠商做過兩年半的對内産品的PM，期間也遇到了不少大大小小的坑。私以為做産品經理，一定要懂得總結，平時會有一些淩亂的想法，就借此機會整理出來，将在這段經曆中遇到的坑總結分享給大家，希望也能夠幫助到其他跟筆者一樣境遇的産品經理。

背景

産品H為一款監控産品，從0到1在某雲計算廠商内部中孵化。從筆者開始做這款産品到筆者離職，經曆了兩年半的時間。期間的工作除了對産品的調研、原型設計以及跟進開發測試外，還有很重要的一部分職責是内部推廣。

但是，在這款監控産品對内發布之前，各個業務部門并不是不用監控的，大多數業務部門搭建了自己的Zabbix等開源監控系統，更有一些體量大、業務相對複雜點的部門自己根據自身的業務開發了監控系統。所以，産品H從一開始所面臨的壓力就很大，因為對業務部門而言替換産品的成本很高。

接下來，筆者想根據産品H演進的過程來講一下遇到的坑，以及當時是怎麼做的以及對于更好做法的思考。

一、内部産品從0到1，該如何冷啟動？

做産品H的團隊，架構師、研發、産品經理、測試等等都是初來這個公司的新人，公司招這麼一批新人的目的也是因為我們這麼大公司，不能老用别人家的監控産品吧。但現有的工具團隊中，沒有人懂該如何做好監控産品，所以從别的大廠挖了一些有相關經驗的研發過來（筆者例外，之前沒有運維或監控的經驗，完全是新人一個）。

面對前提背景中，各業務部門已經有在使用中的監控系統，産品H想要取代那些産品，實施的思路是這樣的：

先有簡單的采集（服務器基礎指标、端口監控指标、進程監控指标）和報警功能（如果讀者對運維監控系統不太了解的話，那差不多可以比喻成業務方都在用5G手機了，然而我們開發出老年機希望他們來用），然後再給兄弟部門推廣，并讓兄弟部門給點使用建議給其他業務部門推廣。

首先，這個思路的第一步就出現了問題。

如果想要通過産品本身的優勢吸引到用戶來使用，那第一步裡做的事情明顯遠遠不夠，業務方們已經在用功能更加成熟的監控系統了，根本不屑于用這樣的産品。如果是依靠政治手段進行推廣，那一開始滿足最基本的功能就想推廣成功，很大程度上取決于産品經理的跨部門溝通能力。

産品H面臨的就是第二種情況。

作為負責去推廣這個V1.0産品H的産品經理，當年的我确實too young too simple，以為大領導都發話了，那大家一定會配合我的吧，很快就被現實打臉了——兄弟部門總是以還有别的事要忙為理由婉拒接入産品H（私底下更是直接罵這是什麼傻X系統，根本沒法用）。

也因為這個挫敗，領導給我的績效評了一個0.95（基準線是1）。所以，我當時面臨的情況大概就是自己的團隊沒有能力和時間提供更好的技術和産品，而兄弟部門也拒絕接入這shi一樣的監控系統，上級領導也沒有通過權力來幫助我的意思。最後，本來抱怨的我調整了自己的思路，既然兄弟部門已經煩我了，那我為什麼不把他們煩到底呢？

所以接下來的時間，我跟他們的溝通特别頻繁，沒事就往他們工位跑，一個上午可能就跑兩三次，督促他們該做什麼要做什麼，并表達了這是我的任務希望大家幫幫忙配合一下（多虧我是女生）。

有一次他們要去團建，我纏着兩個運維非要他們解決十幾台機器的監控部署問題後再走，他們的領導也是很無奈~

所以，總結一下：如果你的内部産品V1.0版本不具備替換别的産品的硬實力，那作為産品經理的你就要發揮出你的軟實力了。

1. 如果是妹子，就發揮好妹子的優勢。女性的形象更加柔和，所以一般對方也很難直接拒絕。
2. 不要以為領導發話了，底下的人就會全力配合。在對方不怎麼配合的情況下，頻繁地去工位找他們溝通會有助于你的推進進度。
3. 體諒他人。表示你能體會到他們真的很忙，但是手頭這件事也是非常重要的，不然領導也不會發話說要接入這款産品。
4. 适當施壓。如果對方還是不斷拿别的工作來搪塞，那就可以和他一起找他的領導，希望他的領導能夠幫助協調這兩件事情的優先級，并且給一個完成的時間點（能有個時間點，也好回去給自己的領導交差哇）。
5. 涉及到決策的事情需要用郵件等方式來記錄，避免扯皮。

二、沒有UI/UE，靠産品經理和前端的審美怎麼讓産品優雅起來？

對于内部産品，資源往往是給不足的，所以沒有UI/UE也是必然的。相信大多數的産品經理雖然有不錯的審美，但完全交給自己來設計視覺，會覺得該不知如何下手，好不容易找到個可以抄的UI設計，前端做出來的效果往往相差很多。

一開始，我們團隊認為這是内部使用的工具型産品，沒有必要追求好看的外表，而更應該注重産品本身的作用，但很快就被現實打臉。業務方即用戶，根本不會站在我們的角度去想，做的不好看不好用，就是産品有問題，管你是對内産品還是對外産品，我是用戶我就是老大。

後來，我們就把一些關鍵的頁面送到UED部門排期做設計，一般普通的頁面就依然由前端和産品經理來把控交互和視覺。以此來平衡産品叠代速度和優雅與否的問題。

其實很多UI設計師除了會做設計外，還會寫CSS，所以如果有這樣的設計師，其實給産品設計視覺效果并不會減緩産品叠代速度，反而有助于産品的快速發展。隻可惜當時我所在的部門沒有UI設計師的HC。

這段經曆也讓我意識到：雖然在産品經理需要關注的事情中産品的外觀不如産品能力重要，但往往有好看的外表才會使用戶有繼續探索使用的意願。所以，作為産品經理的你我，在部門無法給足你資源的情況下，就需要自己找資源了，向别的部門借人借時間也是一種途徑。

三、上線流程不明确，開發、測試都不爽該怎麼辦？

有一段時間，也是産品H快速發展的時期，幾乎每隔兩天就有一次上線，而且這段時期也是領導的敏感期，所以領導經常突然給我們加需求，就要保證領導的需求盡快上線（當然作為産品經理，也會評估下領導的需求是否為必要，但内部産品的功能往往很難依賴于數據驅動，領導的需求也經常跟自身的崗位有關）。

雖然我也身兼産品功能測試，再加另外一位測試開發，測試還是很難跟上産品功能叠代速度。而且叠代太快，導緻測試對于近期要上線的功能優先級很模糊（即便有文檔和項目跟進記錄），再加上我們上線前會有很多個環境進行測試驗收，測試的心态一度處于奔潰的邊緣……

而開發也幾乎是淪為“上線工程師”，每天都要提防今天是不是有上線，作為産品經理的我，也在每天提醒開發今天要上線的内容，導緻經常打斷他們的思路，大家的脾氣都變得有些暴躁。

很慚愧的是，我是在開發和測試都已經不爽的時候，才發現了不對，而不是一開始就看到我們的上線流程出現了嚴重的問題。為此，我也承受了很大的壓力，主要來自于開發和測試的不信任感，即便我想要做出改變，他們也很難有所認同。

這時候，我們的架構師兼領導站出來說下周給大家一個方案。而作為産品經理的我，怎麼能讓領導去出具體的方案，所以周末加了個班，理出來一套方案，來供領導拍定。

既然開發和測試都已經忍受不了如此頻繁的上線，那我們必然是要做出一些讓步的。方案中規定每周僅周三上線一次，最晚不超過周四上午，但領導額外提出的緊急需求例外，要盡可能滿足領導的要求。并且在方案中詳細說明了每一個環境的作用是什麼，以及每一個環境需要跟進的人員有哪些。

雖然測試和開發之前對于我老是跟進每一個環境有點兒不耐煩，但作為産品經理就是需要面對這些來自内外部的壓力啊，該自己扛的責任還是要扛的。

四、給的開發人員都是新手該怎麼辦？

由于某些原因，我在帶隊做某一個很重要的功能時，領導給安排的開發、測試人員都是新人（剛畢業或者剛入職不久），一方面他們對業務本身不是很熟悉；另一方面對互聯網的流程認知有所欠缺（可能不太懂要仔細閱讀PRD，以為需求評審後按照原型再憑借記憶去做就可以，甚至對産品經理崗和自己的崗位分别職責是什麼都不太懂），并且這些新人在開發的過程中，全程沒有高級工程師監督和指導，高級工程師全部被分配做别的産品了。

可能本身在安排資源的時候，就有些問題，但作為産品經理，不管面對什麼樣的資源條件，都要讓團隊離目标更近。所以，我也會要求盡量減少自己對資源的抱怨，自己努力做出一些改變來适應現狀。

既然手裡的開發資源都是新人，那麼每一步都需要說明清楚細節。以下是每一步遇到的問題，以及對應的解決方法：

1. 産品roadmap

在一切開始前，先制定好産品的roadmap，同步給團隊所有人。一個是讓團隊每個人都知道目标和計劃，另一個是讓大家做事有節奏感（找到好的節奏感，大家的協作會更加順暢，更容易事半功倍）。

2. 需求評審

在我做需求評審的過程中，我覺得最難的是讓大家注意聽我剛剛說了什麼，因為開會的時候，大多數人還是很難保持注意力集中。

在以前跟高級工程師講需求的時候，他們往往會各種提問，發散思維，産品經理不僅要快速思考他們的問題還要避免因為發散過度導緻跑題。但面對新人，需要注意的是：如何讓他們懂得和記住我剛剛說了什麼？

這時候，會議紀要就很重要了。可能越有儀式感，大家就越重視吧，會議前發送會議邀請，會議後發送會議紀要，會讓大家莫名對這件事有所重視。另外一點會議紀要很清楚地梳理出本次評審會議讨論的事項和決策點，如果真有人在會議上又走神，那回過頭看看會議紀要也能知道：要做什麼？以及，當時提出的問題要怎麼解決？

3. 進度把控

高級工程師往往已經有很好的自我要求，所以作為産品經理，面對他們不怎麼需要擔心他們的進度。但對于新人，往往沒有很好的owner意識，在做這個功能的時候，新人開發們對于制定好的子任務時間要求沒有嚴格遵守，請假的直接請假，滞後的也沒有想要補救。

雖然做過項目複盤，大家很明白自己哪些地方做的不好，但基本上還是沒有改善。

所以，在需求評審會中我加了一項：研發、測試初步給定自己的時間點。

我會先給出一個deadline（比真實的時間早3-5天），根據這個deadline，研發和測試評估自己任務所需時間，以此畫出一個時間軸。我會在會議紀要中，将這個時間軸發布出來，并要求如果還有問題，需郵件回複來調整時間（當然要抄送領導）。

這樣做後，大家對于時間點的感受更加明确，即便前一周的進度有滞後，但想到自己的完成時間點在哪裡，就會在下一周裡就會把進度趕上來。

4. 漏看最新版的PRD和原型

在項目開發過程中，往往會出現一些因素導緻原本的需求要有所調整（要确保整體進度和質量時，往往會犧牲一些小的體驗和功能）。

公司提供了jira、看闆等需求管理工具，我平時會用jira來管理需求，更新了内容後，jira會自動給任務中的所有人發送郵件通知更改内容，但往往大家的郵箱每天都會收到很多封郵件，漏看更新内容也是常有的事，群裡一個個@也還是會存在漏看的情況，最終就導緻大家都任務理解不一緻了。

為了避免這種情況，我把PRD和原型都使用在線查看的方式供研發和測試閱讀。這樣的好處是，我的更新都會實時上傳上去，研發和測試打開看到的内容就都是最新的。

5. 代碼質量問題

新人的經驗畢竟少，所以寫的功能出bug率比較高，也是意料之中的事情，但當時我們比較離譜的是自測都沒有通過就提交給QA來測試。

可能大家看到時間點快到了就着急提測，結果自測并沒有覆蓋全面，導緻整個流程都無法跑通。後來，我們就要求所有研發開發完成并自測後，通過郵件的形式提測給QA，郵件中需要寫明需求說明、所在分支、測試環境、影響範圍、自測case等。

感覺大家都是注重儀式感的人，有了這個提測郵件後，大家會更加謹慎的提測，畢竟被QA打回會被所有人看到，是件很丢臉的事情┓( ´∀` )┏。

五、産品功能V1.0發布後，有很多人希望再多支持一些功能再推廣該怎麼辦？

做産品經理的我們，經常可以聽到的話就是：V1.0版本一定要快、準、狠。

V1.0版一定要能夠抓住用戶最本質的需求，快速地解決問題。V1.0版越簡單越能看出一個産品經理的自信。

對外産品雖然無法直接接觸到用戶，但通常可以根據運營數據、A/Btest等方式來作為判斷依據。但對内産品，卻要面對來自各個業務方甚至自己團隊的大量建議和要求，就會有很多幹擾信息。内部産品在做一個全新功能時，往往根據産品經理對業務方的調研做出一個自己認為是正确的V1.0版後，時常要面對的大量吐槽：缺這個功能少那個體驗。

其實，這都是因為業務方不知道推出這個V1.0版想讓他們來做什麼事造成的。産品H跟市場上其他競品相比，起步晚、實力懸殊，但作為用戶把它跟市場上那些數一數二的産品作對比，這是再正常不過的，不過好在既然是對内産品，那就可以直接與業務方溝通這個功能的V1.0的目的是要做什麼。

讓業務方了解目标後，再對照V1.0的功能，看看是否可以滿足，對于其他的建議和要求，也可以回複業務方在接下來的叠代中會進行上線。

還需要做好的是：記錄每個需求和對應的報告人，如果他的建議和要求上線，那就及時通知，讓對方有一種自己被重視的感覺，也方便建立友好的溝通。

其實，除了以上這些坑，還有好多坑，諸如：領導也會對産品提一些需求，但這些需求在領導腦子裡一天就能變好幾個樣，那産品經理就需要把握好産品或功能的定位，抗住壓力，自己去判斷值不值得做以及在什麼時間做。而大多數的領導還是會聽進去他人的意見的，就怕沒主見的産品經理。

也許讀者看到我的這些經曆，會覺得我這個前任公司流程管理制度上有些亂，也許很多人根本不會遇到我的這些情況。的确部門從一開始流程管理就比較混亂，因為當初大多數人都是高級工程師，都已經有一個比較好的自我規範的習慣，但随着部門中新人越來越多，這套完全靠自我驅動的方案就行不通了。

産品經理不僅要有解決産品需求的能力，還要有發現團隊問題并解決的能力，内部團隊沒問題後，才能更好地對外輸出成績。

不管怎樣，我還是從中學到了很多。産品經理就是帶着一堆人去做一些實現部門目标、提升大家績效的事情，并分析内外部環境給團隊尋求資源的那個人。

在做産品H的兩年半中，我能夠感覺到自己已經從那個隻會分析需求、管理項目的産品經理成長到能夠帶着團隊一起實現提升業績目标的人物了，更加清晰地認識到産品經理所面對的壓力和責任，這份責任感雖然沉重，卻也是讓我熱愛這個崗位的原因之一。

本文由@草木夏 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自Unsplash, 基于CC0協議。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部