文|鄉野山人左大瑞
到今天，是我擔任項目經理的第七天。（文章發出的時候應該是第7個工作日）
年前聽朋友的慫恿報了PMP的培訓班，計劃三月份考試，因為懶且不積極看書，上課期間又出差在外，于是，延后到參加六月份的考試。所以項目經理是在我職業規劃里的，而正好，這個轉機來了，我也是特別的感恩。
上周四，領導對核心小組宣布組織架構的調整，原來的四個部門，融合到一個大的部門。四個部門之前每個都是完備的運轉體系，有leader、有產品、設計、技術、測試。基于原來的模式下，產品經理的職權有很大，他可以自定項目優先級，自由支配部門內資源；因業務的不同，業務部門也會提出不同的需求，導致有些部門某些時間段很閑，某些部門忙成狗。
這次的調整，將設計、技術和測試資源化為一個大池子，打破之前業務線的壁壘，讓資源流動和可控起來。
所以，這次的組織架構設置一個項目經理的職位，也就是本人（^ - ^），就是為了讓部門所做之事有一個全局的把握，說白了，誰都希望自己做的事情被領導看見，不然你苦逼兮兮的忙活半天，領導根本不知道。
項目一方面是對事兒的把控，還需要對資源的可控，讓團隊工作量處于一個張弛有度的狀態，基于團隊目前資源來約定并行項目的最大值，當資源使用度幾近飽和的，提前與領導報備，并與業務方確定項目優先級和預計項目資源可釋放時間。
基于上面的碎碎念，下面進入到正題，在這七天里面，基于我對于本次項目經理任命的理解，做了以下工作：
一，整理部門目前正在進行的項目
我之前是一個業務線的產品經理，團隊當時還有另外一個產品、交互，設計，然后是技術和測試資源。對于這條業務線的了解程度，那是門兒清，但是其他的三條業務線，基本是全抓瞎。
于是，領導在和所有產品經理（包括我十位同學）開會宣布組織架構調整之后，讓我匯總所有產品經理將目前手上的項目。收到項目的匯總后，我按照【項目名稱、需求方、業務部門、產品負責人、項目時間、項目資源（和組織架構保持一致的步調）、目前進度、備注】整理匯總。
同時和大部分產品經理進行了深度聊天（有請假未談成的，有部分不是很樂意進行深度溝通的），同步目前的組織架構情況，以及對部分產品經理的心靈表示安慰，弱化職權能力的縮減，重點突出在產品經理直接向領導匯報的好處，工作能力可以直觀的被看到，晉升通道也透明清晰。
通過這個表格，可以快速知曉目前進行中項目，以及團隊目前90%資源的狀態，從產品處收集的項目會有疏漏，譬如一些技術自發性質的解耦、數據清理等各種不需要產品參與的技術優化，所以整理完這個表格之后要跟各個leader老大同步信息，看是否有漏掉的正在進行的項目。
項目梳理的維度：
1. 上面提到的項目匯總表：
該表是對項目的一個整體了解，包括項目的需求方、資源、上線時間等等
2.已立項項目的項目日歷：
以天為維度記錄所有項目的【milestone、計劃工作、完成情況、延誤情況】，讓領導們直觀了解，所有項目的關鍵性節點，并能讓參與任意項目中的同事對任務節點清晰明了。
3.項目資源表：
每一個項目所使用的具體人、日（按組織架構的分組來細化），以及在所有資源池中的資源比。這個可以讓leader們清楚各個項目里團隊的資源投入，該表會重點給項目的業務方或者需求方看，目前團隊支持該部門所投入的資源。
4.項目進度表：
對項目進度的直觀把握，同時對于項目流中釋放出來的資源做同步更新，進度表中的資源比是還在項目中的人員（已完成環節的人員會釋放出來）與總的資源池。這個表中的資源比，可以給領導和各位leader了解資源占用情況，同樣的產品和業務方也能夠基于目前閑置資源做項目的流轉。譬如，目前設計資源、和H5資源較多的時候，產品和業務方都可以規劃一些運營推廣的項目活動。
說明：這幾個表，其實可以在一個project中全部搞定，但是我現在還沒好好研究會project，所以等我研究完了再說，目前階段先用這個吧。
二，確定項目流程
1. 需求溝通&調研
前期業務方和產品經理進行需求溝通，以及項目可行性的初步調研。
2.立項
立項的目的是確定項目是否可做，預計投入項目資源比。
對于運營活動類的項目，一定要有BRD，原因兩個：一是需要根據BRD來調研了解項目是否可做；二是需要基于BRD中設定的項目預計收入來確定項目資源投入。
3.需求評審
立項成功后，產品基于之前的需求溝通以及立項會，進入產品方案設計階段。方案設計完成后，進行需求評審。
評審的目的有兩個，一個是產品方案是否是業務方想要的；另一個是產品方案是否能夠最終落地，需要技術、測試等同學就方案討論是否有坑，或者無法實現的地方。
4.視覺評審（部分）
視覺評審是部門項目需要有的環節，新項目確認視覺風格，或者運營基調。如果對視覺要求不會那么高的項目，可以略過或者小范圍的開視覺評審會。
5.視覺驗收（部分）
和視覺評審存在的前提是一樣的，當需要視覺驗收時，技術開發完畢到測試階段時，需要設計師對技術開發的頁面進行視覺驗收，看是否符合當時的設計理念和細節調整。
6.業務驗收
上線前，由業務方驗收目前開發成果，或者借此機會給業務方培訓工具性或者后臺產品功能。該目的，一是確定東西是業務方想要的，二是確認業務方能用且會用。
7.項目上線后的復盤和學習
上線最終上線后，各環節參與的同事坐在一起，基于這個項目進行討論和學習，在環節中出現的問題，是否可以在下一個項目中做提前預案。
三，項目習慣
1.項目每日晨會
目前并行的項目很多，早上有大半的時間在參與各個項目的晨會。晨會的主要目的是：暴露問題、定位問題，分析問題，找到解決方案，落實到人。
2.項目同步郵件
每天項目組內人員同步每日進度郵件；我每周三、周五同步給業務方項目郵件，主要包括項目目前進度、資源比、需要業務方協調資源的事兒以及時間點、可能存在的風險點告知。
四，問題和難點
那么基于此的調整，目前暴露出來的幾個難點：
1，對于利益和權力被打散或削弱的人，內心難以接受。
2，對于其他業務的不了解，技術和測試的時間成本增多，可能會出現，項目參與人數多了但效率和成效未增加。
3，人們對于改變的莫名反抗，和單純的情緒發泄。
五，感想
每次調整對于部分人來說都像是一次生孩子的陣痛，熟悉了原有的業務，做起來得心應手，接受新事物時會有一些抗拒，希望這個時間節點可以短一點再短一點。
這篇文章斷斷續續寫了好幾天，前幾天和朋友聊，提到為什么想要在項目學習之初就寫下來這些分享，一是自己給自己做一個總結，另一個是為了以后自己的回顧，可以在未來，以一個旁觀者的身份去看待和分析自己在職業轉變之初做的事情和心態調整對事態發展起到的作用。人生轉變千千萬萬，希望我們每次都能保持好奇和熱情，活到老學到老，話語簡單，真正做到卻需要一生的實踐。
文中代表自我觀點，因公司基因、行業類型每個公司處理方式可能不同，期待指點。
