文|乡野山人左大瑞
到今天，是我担任项目经理的第七天。（文章发出的时候应该是第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，人们对于改变的莫名反抗，和单纯的情绪发泄。
五，感想
每次调整对于部分人来说都像是一次生孩子的阵痛，熟悉了原有的业务，做起来得心应手，接受新事物时会有一些抗拒，希望这个时间节点可以短一点再短一点。
这篇文章断断续续写了好几天，前几天和朋友聊，提到为什么想要在项目学习之初就写下来这些分享，一是自己给自己做一个总结，另一个是为了以后自己的回顾，可以在未来，以一个旁观者的身份去看待和分析自己在职业转变之初做的事情和心态调整对事态发展起到的作用。人生转变千千万万，希望我们每次都能保持好奇和热情，活到老学到老，话语简单，真正做到却需要一生的实践。
文中代表自我观点，因公司基因、行业类型每个公司处理方式可能不同，期待指点。
