项目管理是一种服务

       几年前我的前上司（公司的PMO经理）经常挂在嘴边的一句话是：我是overhead，我是来给在座的各位项目经理服务的。当时听着总觉得有点虚，以为他是为了拉近跟我们的距离而这么说的，时隔3年有余，当我在新的公司，在弱矩阵组织架构下做项目经理时对这句话有了完全不同的理解，也非常认同前上司的这句话了，其实想想看大部分管理者何尝不是overhead（这里对overhead的定义是：管理本身不直接产生价值，管理的价值需要通过团队而实现，要么是更省钱、要么是更赚钱）。

        先来介绍一下我目前的项目团队基本情况吧，鄙人现在杭州一家互联网公司的PMO团队中工作，并被委派至一个电子商务部门做项目管理的，团队的成员都来自这个部门下的各不同小组（策划、UED、视觉、商务、开发、测试），他们的考评汇报关系是各自团队的负责人。通过初期的访谈调研得知整个电子商务部门里面相互间合作最怨声载道的事情是相互间都不卖帐，私下都相互指责，后流程团队都觉得是为前面的流程团队打工的，而策划总感觉要实现一个想法需要费太多的口舌。再通过观察发现各个小组之间的工作方式基本上是‘接力赛’，下一个流程的人员很少有机会能了解到上一个流程正在做的事情，后面步骤中往往拿到的是前面流程已经决定要做的方案了，要想修改之势必要‘大战一场’。。。

       我加入此部门时本着服务大众的目标、多干活、多让团队共同讨论决定、少发表个人看法的原则行事；第一步是将项目中涉及到的团队成员召集到一块，请部门负责人宣传了本项目的目标和重要性等事项，然后说了一下我接下来将如何执行这个项目的大概想法并听取了团队成员对这个项目的看法，权且当项目启动大会了；

        第二步，成立Feature team和进行daily meeting，将相关的同事拉在一起，灌输这是我们的项目，本项目将会须要大家的帮助，同时每天上午10:00-10:15在一起同步状态（借鉴Scrum站会的3个问题）。

        第三步，定义项目中的RoR即Role and Responsibility，这个RoR和他们各自在部门里的角色定义不完全一致，比如我们对于测试任务就不仅仅限测试人员承担和执行，视觉同事就要验证程序的视觉效果等。 

        第四步，在流程上从小处提高，定义了一个最简单的流程就是“当日问题当日决”，用于解决前期大家反映的需求澄清、沟通费时的问题。中后期辅以阶段性回顾反思会议，大家一起来做总结和反思过去的优缺点，以及如何改进团队的缺点。

        目前第一个项目已经基本按时交付了（延迟三个工作日，总项目时长3.5月，总花费32个人月），也基本达到了我当初的计划，写下这篇博客并不是炫耀自己的项目成功，更重要的是勉励自己在新的公司环境中服务好项目、服务好业务部门，在成功交付项目的同事希望提升自己，希望达到leadership without authority.