我在B公司（為了保密，所以公司名稱用‘B公司’代替）擔任的是產品經理（PM）一職，由于B公司對公司架構進行了調整，我們整個產品部都被撤掉了，不再保留PM這個職位，因此離開，以下是我在B公司任職期間，對自己的職業生涯做的各個項目的總結。

文章嘗試使用了一些復盤的思維去寫。

B公司社區回顧目標

社區的目標是2017年4月份完成第一期的規劃（不包含手機端），6月完成第三期規劃（包含手機端）。

B公司社區評價結果

1.B公司論壇在四月份的時候按照原來構想完成了任務中的開發計劃，實際上線在5月份。

2.到了五月份，第二期的計劃如期的進行，并且提前完成了相關開發任務。手機端開發暫緩。

3.六月份，第三期的任務也完成了，不過完成的質量和速度不好。

4.七月到九月與其他項目做兼容，接入到B公司商城當中。

B公司社區分析原因

1.由于測試的時候發現比較多的問題，所以修復問題到正式發布到cn測試站用了大概2周的時間，任務上線實際上是五月份。

2.由于有了測試的經驗，在底層方面做了技術上的優化，所以第二期的任務如期完成。不過手機端的任務由于B公司建站那邊的任務比較重，我們這邊沒爭取到相關的開發人員過來。而且設計人手也不足，所以就暫停開發手機端。

3.第三期由于項目組有人員離職了，影響了相關的開發進度。

4.由于公司社區是所有項目當中做得最快的，所以擔當起了項目的排頭兵，進行各種試點工作，比如說進行兼容嘗試，不過在兼容的過程中，也發現了很多運維上的問題，以及B公司商城方面的框架問題，所以工作開展起來進度比較慢。另外B公司商城本身的開發工作就比較緊張，突然加入這些開發事項，打亂了本身B公司商城的計劃。

B公司社區總結

1.人員變動大。B公司社區一直以來得到的資源就不多，項目組的人員發生變動比較大，從原來的2個后臺，1個前端變成了最后只有1個后臺人員。前前后后變換了3個前端人員，2個后臺人員，而前幾個前端人員的代碼書寫不規范，以及技術人員的水平有限，導致維護代碼的難度加大。

2.資源少。在我接手B公司社區前，得到的資源非常少，沒有產品人員跟進，導致規劃有點混亂，而且沒有設計人員，導致界面做出來異常難看。

3.需求改動少。在跟進社區之后，第一件事就是確定過了需求，規劃好要制作的功能，并且迅速完成原型圖，讓技術人員能夠根據原型圖來進行開發。

4.代碼要規范。由于前端代碼不規范，導致了跟其他項目做兼容時，出現了各種問題，項目的速度也因為代碼的原因而拖慢了，所以社區花費了2個月的時間去進行重構，如果從一開始就避免的話，就可以節省2個月的人員投入。

B公司學院回顧目標

B公司學院在6月15號的時候進行規劃，并在2天時間內完成原型圖，然后交給技術人員去進行開發，項目在6月份完成。

B公司學院評價結果

B公司學院在6月按照進度完成。

B公司學院原因分析

1.規劃的方向做出了調整，原型比原來的計劃多花了1天時間。

2.規劃清晰明了并且符合技術的開發，技術知道開發的重點。

3.設計稿在很早之前就確定下來了，節省了等待設計的時間。

B公司學院總結

完善良好的規劃，技術人員的配合，設計稿的盡早確定，都對項目的進展有很好的幫助。

B公司PMS回顧目標

PMS是B公司公司的總后臺，擁有管理其他項目的關鍵配置的權限，另外擁有OA系統，員工的日常辦公都要在PMS里面去進行。

B公司PMS評價結果

1.開發完成得較早。

2.使用頻率低。

3.很多頁面的UI都不如人意。

B公司PMS原因分析

1.前期投入的人員較多。在前期時投入的技術人員都是各組的精英，因此完成的時間在這么多個項目當中算是比較早的。

2.復雜程度高。由于這個項目是總后臺，所以復雜程度相對來說比較高，測試起來也會比較困難，而且其他子項目也在開發階段，所以使用的頻率就更少了，沒提現出這個系統的重要性。

3.人員離職影響。由于之前負責該項目的產品人員離職了，留下來的文檔也不足以解釋清楚各個功能的作用以及原理，所以接手所需要的時間比較長，而且在后期補全文檔的時候也花費了大量的精力。

4.測試資源不足。產品新接手，對于項目的了解度不夠高，而測試的資源本來就不足了，在有限的時間內難以完成對整一個PMS進行測試。

5.前端人員資源不足。測試出來的那些結果，有很多一部分都是UI上的，而PMS在那個時候并沒有負責跟進的前端人員，導致測試結果出來了也被擱置了一段時間，沒有跟進修復，導致后來有人手了再跟進時，花費了比較長的時間。

6.很多地方沒有做到數據的規范。由于很多UI的提示沒有做到規范，所以都是按照各個技術人員的個人喜好和經驗來進行制作，導致了有很多的地方都不一樣，看上去不專業。

7.注意各項目的先后順序。總后臺完成的時候，各個子項目并沒有完成開發任務?？偤笈_的作用凸顯不出來。

B公司PMS總結

1.在項目規劃時，就及時做好各種規范。

2.根據項目的重要程度來調配資源，條件允許的話就固定人員，不要經常發生人員的變動，避免耽誤工期。

3.作為一個總后臺，應該在各個子項目完成之后再進行考慮規劃。

業績管理回顧目標

制作一個專門給營銷人員查看業績的系統，讓各個營銷人員都可以看到自己的排名、部門的排名、公司的排名，起到激勵的作用效果。

業績管理評價結果

開發周期只有五天，并且如期完成了銷售部門的要求。

業績管理原因分析

1.在PMS里面原本就擁有了話題功能，允許發表資訊并評論點贊。

2.在PMS里面原本就擁有了公告功能，允許發表公告，并且允許針對特定人群進行發布。

3.在PMS里面原本就擁有了組織架構的系統框架，可以直接引用，修改幅度不多。

4.擁有UC登錄中心。登錄采取的是UC的登錄方式，帳號統計由一個后臺來進行管理匹配權限，稍微做些修改就可以用到業績管理系統。

5.技術人員穩定有經驗。制作的開發人員都是技術經驗豐富，而且曾經開發過PMS后臺，了解代碼結構。

6.設計部門的設計稿很快就確定下來了。

7.原型圖補全的速度快。技術人員完成可以參考著設計圖就可以進行制作了，里面的相關規則已經規定好。

業績管理總結

產品人員得到需求之后，知道如何利用現有的資源，以最快的速度去完成，做出了較好的規劃，并且符合對方需求。

微信配置回顧目標

制作一個微信公眾號第三方平臺，客戶可以通過B公司的微信配置平臺完成對自己公眾號的管理。

微信配置評價結果

1.完成的速度較慢，超出預期完成時間。

2.存在技術在開發的過程中偷工減料的現象。

3.受接口的限制很高。

4.測試過程中發現很多問題。

5.服務器不穩定，增加了很多技術修復的時間。

微信配置原因分析

1.微信的接口時常進行更新變化，有些功能規劃好之后才發現微信不提供接口，導致要調整規劃。

2.由于是調用微信的接口，因此環境的穩定性很重要，當配置發生改變時，有些功能就會失效，必須技術人員去進行調整修復。

3.人員變動大，之前負責后臺的人員離職了，開發人員進行了變更。

4.平臺的粘性低，因此要把功能做得強大，所以一些功能會比較復雜，導致了開發難度加大。

微信配置總結

由于用戶完全可以使用公眾號平臺去進行管理，另外由于微信團隊的強大，功能的更新會比我們公司自己開發更快，而且自己開發會受限于微信提供的接口。從戰略上來看，要這個平臺需要一個穩定的團隊時常維護才可以跟上微信的步伐。而要增加用戶的使用黏性，只能把自身的平臺功能強大，聯合B公司其他項目來進行整合，提供一些微信團隊無法提供的服務，同時使得用戶用B公司的產品確實是產生了便利，那么B公司微信配置才能提高用戶黏度。

APP管理回顧目標

用戶設計好APP之后，通過APP管理平臺自動生成APP安裝包，內測沒問題就可以自己把安裝包上傳到各大APP下載平臺。

APP管理評價結果

1.開發人員嚴重不足，項目嚴重超期。

2.設計部分的項目完成時間晚，導致對接調整的時間急。

3.IOS的規則發生改變，導致項目規劃出現嚴重偏差，改變很大。

4.當初UI方面規劃得不太完善。

5.接口不穩定，很多地方需要修改。

APP管理分析原因

1.開發太慢，導致有很多規劃都已經過時了。

2.原規劃不好，很多細節沒考慮，導致要處理這些細節時，需要花費大量的時間精力。

3.接口不穩定，經常要改，增加了很多無謂的時間。

4.項目復雜程度高，開發人員有點吃不消。

APP管理總結

遇到一些復雜程度高的項目，在前期規劃的時候，就更應該花多一點時間去做考研去做規劃，把每個關鍵的位置都要規劃好，把整個框架搭建好，不然后期就要花費很多的時間去做調整，這樣會延長項目的開發周期，甚至可能由于開發周期太長了，已經不合時宜而導致了項目的難產。

該項目的很多地方就是由于前期規劃不好，導致在實際開發過程中，某一些功能的實現難度加大了。

我i在2017年10月31日整理交接文檔，并于 2017年11月1日 離職

end