故事背景：
全新的项目，全新的团队。
人员经验值情况：
产品：业务经验比较丰富，但是产品经验为零；
研发：梯队划分为两级【0-2年经验的/6-7年经验的】
测试：梯队划分为两级【0经验/资深测试】
leader: 空降兵
PM：无
项目起初现象：
需求层：新项目，具体想要做成什么样子其实产品也不是很清楚，需求来源没有实际的业务场景做推动，做的是自有产品，所以需求靠产品自己空想。一开始需求不明是最大的问题，甚至没有像样的需求宣讲。原型比较粗糙，PRD到第一版使用手册需要交付时才有第一版。
研发层：没有整体系统架构设计，代码也没有一些基础包，代码全是从零开始[当然用到了市面上开源框架]，没有针对业务的架构设计。各个开发自由度太大，编码规范没有，也没有互相商量，分到的业务模块各做各的，到联调阶段才会沟通。
测试层：不能针对需求设计写出对应的测试用例。或者说现有需求没办法写出测试用例。
PM：无，唯有有的就是大boss对时间的要求。
leader : 空降兵，组里成员不太叫的动。
项目后期现象：
需求层：需要对接售前，售后，各种需求堆过来，现有系统很难对接其他产品。
研发层：人员人心涣散，没有ower意识。
测试层：面临交付压力的收尾工作，需求，研发不给力，推动显得苍白无力加心累。
PM层 ：leader一直关心的是什么时候能发版，具体项目情况不知道，画饼比较大，实际项目乱成一锅。
leader: 偶尔催一下测试，让其催开发 fix-bug。需求界限不控制，随便产品和其他团队的要求，全盘接下。
项目最后结果：
项目层：项目实际没有用起来，已发版本也不能投入生产实际使用。
人员层：没有实际的成长，加上项目拖的心累。小兵，甚至 leader 都给小兵透露想跑路的想法。
此时意识到，PMO的重要性了：
从各个人员自身的技能角度讲，其实每个人都能在自己的岗位上胜任工作，开发测试，都没有遇到解决不了的技术问题，产品的设计能力稍微弱一些，但是不至于项目进行不下去。
主要问题：
1 每个迭代周期过长；导致一个产品需求做的太大，想不明白。各个地方漏洞百出。开发都出现了做着做着忘记需求的现象，不过没有需求文档也是很重要的原因。最后的测试工作量也太大，人员人手紧张，力不从心。正常两周一迭代比较合理，或者一周一迭代相对比较快的节奏。
2 项目推动靠产品一个人；不管是早会，还是进度，都是产品催着走，其他人习惯了延期或者不在乎延期。产品质量也是如此。
3 研发的ower 意识一点没有；当一天和尚撞一天钟的感觉。一群不畏leader的开发。
4 leader 基本算吉祥物摆设，对外不护犊子，对内也没办法带动团队。
说了这么多，其实核心还是缺乏PMO。以前觉得PMO很虚，而且搞不懂为什么越到高级开发，越注重对这方面的学习与应用，说的通俗些就是管理的一些方式方法，条条框框的应用。听起来俗套老道，但是对一个项目的生命周期有着至关重要的作用。虽不用说什么花里胡哨的东西要用起来，至少至少，不管是传统的瀑布模型的开发流程，还是所谓的敏捷开发流程，总要有一个是在项目里实际使用的，不然项目就会像上面这个样子。推动这些的就是PMO，也是身边的例子第一次感受到没有PM的后果有多严重。以后的研发之路，不管是项目的选择，还是实际的做事情，这些都是很好的教训。
原文：https://www.cnblogs.com/junbaba/p/14684380.html