作為應屆生進入外包公司任職產品經理是一種怎樣的體驗？面對各種狀況和交接該如何處理？

和大部分應屆畢業生一樣，我們總是會被灌輸一種思想，那就是“剛畢業的學生，對于工資待遇、公司背景什么的不要有太多要求，能找到一個“合適”點的公司學點東西磨練磨練自己才最重要······”

就這樣，我進入了一家足以讓我得到磨煉的外包公司工作。

記得面試時，是老板親自面試的我，依然清晰的記得老板對我說公司有四五十號人，產品、技術、測試、運營等崗位都配備相關的人員?。?！當時的我面試通過后，萬分開心，認為自己來到了一個規模完善、經營狀況良好企業。

但真正進入企業正式工作后才發現這四五十號人中，其中的30名左右的包括java、.net、Android、前端、測試等技術人員并非我們老板旗下的員工，實際是合作伙伴關系，只是對外宣稱是自己公司的員工（騙騙客戶罷了），實則屬于本公司人員的只有產品部。那么我作為產品經理跟不屬于本公司的技術、測試等人員合作起來，簡直就是一件要命的事情。

當時很無奈，但另一方便覺得自己只是一個應屆畢業生，給的工資還可以，就堅持留了下來。后來，也就是那一年，我深深的體會到了作為一名外包公司的產品經理不僅需要足夠強大的內心、技能、與口才。

而且在每個項目及工作流程中都要和UI、技術、測試、運營等做好足夠的配合，把控好工作流程、項目進度等。否則，項目一旦延遲上線或者上線時出現很嚴重的BUG，無法跟客戶交代，這個鍋都會甩向我。

當然，與其說自己是一名產品經理，倒不如說自己是一名項目經理來的更為實際。因為我們屬于項目外包公司，老板通過人脈關系或者投標等方式承接甲方的項目，項目承接下來后，需求部分由我們產品部自己做，到代碼的實現、測試部分都要由其他人來做。

為了避免來自客戶以及老板、對方同事等的甩鍋，我盡可能的將每個工作流程都做的相對全面，大概包括以下幾點：

做好充足的用戶調研、需求采集、需求確認

需求部分永遠是一個項目的key，如果前期需求做不好，走錯路、會錯意，那么后面所有的程序都是白搭，因為你連客戶爸爸的需求都沒理解清楚，其他都是無用之功。

• 用戶信息調研：用戶信息采集是需求的一個重要部分，首先要理清楚所做項目的目標用戶，用戶調研數據對后面的產品設計起到很重要的作用。不同類型的目標用戶不管是在視覺上還是技術操作上，都存在著不同的差異。
• 需求采集：采集客戶的本質需求，將客戶的需求進行詳細的分析，弄清楚問題的要求，比如：需要輸入什么數據，要得到什么樣的結果，最后應輸出什么。需求分析的目的就是幫我們確定產品方向。
• 需求確認： 需求采集完后，我會將客戶的需求用Xmind、Excel分別整理出思維腦涂和功能清單提供給老板和客戶進行需求確認和項目報價。在這過程中盡可能的將需求進行功能分類，細致化，讓客戶可以更好的分辨出我們整理的需求、功能是否與他們的本質需求有出入之處，一旦有出入，及時做調整。

原型設計階段

原型圖遠比文字能更好、更直觀的表達自己的想法，所以原型設計是一個梳理功能、再次確認需求的重要階段。因為本人是個典型的處女座女生，所以在工作中喜歡做到盡善盡美，寧愿多加班也要盡可能的做出高保真的原型，目的是為了更好的將我們的產品設計、產品交互以及功能梳理給客戶做詳細的展示與講解。

在原型設計階段，我會根據不同的用戶群體做不同的交互設計，例如：我負責的第一個項目，他們的使用群體包括兩類，一類是B端用戶（政府的工作人員，年齡在30-45歲），另外一類是C端用戶。針對這種用戶，他們不擅長操作電腦或使用軟件，我盡可能的會將交互做到最簡單，同樣在字體字號上面會做個備注，讓美工盡量做得盡量大點（當然，這只是一個建議）。

需求再次確認

作為一個年輕的產品經理，經驗不足是真的，但有一點是我的長處，那就是從不吝嗇多跑幾次客戶那，和客戶當面確認需求，和客戶多溝通、多交流。因為原型圖相對于文字能直觀的表達自己的想法與設計，所以每當我做完原型設計后，都會到客戶那做原型講解，我會盡可能的將自己的想法全部表達出來。

當自己的設計與客戶的需求有出入時，做好標記，如果出入比較小，我一般都是當時改好，現場給客戶確認。如果出入比較大，我會重新梳理，再次提供新的設計方案給客戶進行確認。當然，因為自己本身是技術出身，大學期間也是學的技術，所以設計的方案大部分都是在技術上確認可行的，一旦拿不準主意，就會向技術人員請教，確保設計的可行性，避免天馬行空的設計。

因為自己在需求確認階段及其重視，所以在擔任產品經理階段，經常會和客戶保持電話、微信聯系，都成了客戶的老熟人了。

PRD文檔編寫

作為一個這種特殊性質的外包公司的產品經理，PRD文檔對自己而言，簡直是救命的稻草，它不僅是和技術等人撕逼的證據，同時在這種小公司，也是可以避免背鍋的證據。所以在寫PRD文檔時，我會將客戶認為重要的點表達清楚，避免后面因為自己沒有表達完整，然后鍋從天上來。

需求評審會議

和客戶確認好需求后，我會召開一次全面的需求評審會議，把美工、技術、測試等人全部叫齊，將需求和設計對接給例會人員。在會議之前，我會將原型、功能清單、PRD需求文檔等提前發給例會人員，讓他們提前了解項目，以至于更好的在會議上提出他們的問題，我一一做解答，提升會議的效率。

設計、開發階段

需求評審會議結束后，項目進入UI界面設計、代碼實現階段。

UI界面設計：美工設計好的界面，我會發給客戶確認，目的是讓客戶了解下界面的整體色調以及我們的設計想法，避免后面所有界面設計完、開發完后，被客戶全部否認來的強。

開發階段：人們常說技術人員做出來的東西，會讓你覺得那不是你自己親生的孩子，和設計師設計出來的美美的界面會有很大的差別。這都不是重點，重點是，我們的技術人員還不是自己公司內部人。

所以在開發階段，我不僅要把控好項目進度，同時還要三天兩頭跑去對方公司盯著他們做的成果，一旦發現界面做出來嚴重“扭曲”就會拿設計圖和技術人員溝通，溝通不行就撕逼。他們如果不肯配合，我就只能找他們的老板和技術人員溝通了，因為作為一個小姑娘家的，老板們還是不太會為難我的。

測試、驗收階段

系統開發結束后，部署到測試環境，開始進入測試、驗收階段，畢竟公司小，作為產品經理的我是和測試人員一起參與系統測試、驗收的，通過建立Easybug，將所有的BUG全部寫入進去BUG系統，分好BUG優先級，安排技術人員進行BUG修復。

當然在這個過程中最討厭的莫過于一BUG未平，一BUG又起，這也和技術人員的能力有著很大的關聯。

試運營階段

測試、驗收結束后，讓客戶參與試運營階段， 親自參與使用系統或者APP等。一般在這個階段不會遇到的太棘手的問題，因為前期不管是需求還是測試階段，我們都盡可能的多花心思處理。

項目正式上線

試運營結束后，客戶也確認沒有問題后，產品正式上線，這算是一個項目告一段落，后面開始進入正式運營階段。

針對于以上的九個階段，我都會在項目開始前，進行時間周期的把控，在項目進行中，進行階段進度的把控。及時采取相應的措施去解決存在的問題，盡可能保證項目按照預定的時間上線。

當然，在整個過程中，最難的莫過于和不屬于本公司的技術、測試等人員進行溝通與合作，這個過程有時讓你懷疑人生。但還好，內心足夠強大的我覺得所有的問題都會迎刃而解，只不過過程會比想象的難點。

以上是我作為外包公司產品經理的工作流程和感觸，寫的比較口語話，目的是為了更直觀的表達自己的想法，如有需要改進的地方，還請各位大佬多多指教~

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

題圖來自Unsplash，基于CC0協議