背景：
其实，我几乎每天都有登录博客园，不管是看看新闻还是关注一下技术文章，但是这三年就一直提不起兴致来写个博客。这三年经历很多，先后考了ACP、NDPD、TOGAF，也经历岗位变动，现在又回到项目管理岗；
世事浮沉，命运总是那样百转千回，心态也是动荡不安。这个浮躁的时期，我都忘记了原来写博客，原来是一种可以让自己内心安宁的事。因此，我想把我这几年做项目管理，最新的一些感悟写下来。加之本身今年我又重新管理IT项目部，我便思考出了
我自己认为的一套项目管理手册，我自己的评价是像神雕侠侣中的【般若龙象功】，不是什么正统功法，但是威力是够的。也如龙象功那样，创建功法的人是把自己的一些思考和猜想放到里面，其实自己也没练成，我自己也一样！索性就写在博客园中
看看有没有园友一起参悟。
正文：
需要写在前面的是，这套手册有些地方，是结合我们公司的实际情况而制定的，例如：
- 对于30万以上，并且跨域2个以上部门的项目要上数字化委员会去立项，这个数字化委员会是由公司VP级以上高层组织的虚拟组织，管理项目的立项、跟踪与结项；
- 对于30万以下，周期小于一个月的项目，是由数字化委员会的秘书组织，也叫需求管理委员会来做审批与结项，这个组织是由IT、财经、人资、流程、审计的部门leader组成；
这样的组织设定好处就是，项目是立项是严谨的，项目由业务部门自主申请，IT辅导与接收业务部门的制定的《项目立项报告》并组织需求管理委员会进行初审，通过后根据情况递交到数字化管理委员会审批；
审批通过后，由我这边IT项目部承接项目，统筹项目组织，推进项目进展。 因此，作为一个IT的项目管理部门，我所面临的项目种类也是五花八门的，而项目种类的不同，采用项目的管理制度就必然不同。
所以，我将项目分为以下6大类：
不同类型的项目，决定了使用不同的交付模式进行管理，在过往的项目管理机制中，其实我一直擅长使用敏捷交付模式，那是因为IT的项目管理场景大多以用户需求为起点，针对需求进行快速迭代，
像攀岩一样，以一个抓手为起点，爬上去再寻找下一个抓手。这种模式虽然号称短平快，但是弊端同样明显。 例如：
- 缺少整体规划，产品往哪个方向发展，全部由用户反馈来决定，系统往往越做越臃肿，迷茫的时候甚至分不清楚是真需求，还是伪需求；
- 需求无限积压，这种模式往往以响应用户、拥抱变化为宗旨。而用户的需求是无限的 ，甚至只是某些仅仅是满足个体诉求，需求价值评估难；
- 生命周期模糊，生命周期都不清晰常常会让一个项目不知道什么时候是个头，尽快软件产品是可以无限迭代的，但是我从业的管理类系统是需要讲收益的；
所以，我这里项目分成 ：系统建设、产品迭代、基础设施、推广运营、数据应用、方案咨询，这么6大类，也仅仅是产品迭代适用于敏捷，其余的还是主张瀑布或者混合模式（整体规划，分步实施）；
===================================================================华丽的分割线=================================================================================
当拿到一个项目的时候首先需要确定这个项目采取什么样的交付策略，瀑布、敏捷还是混合式交付。确认交付策略之后，自然就是要确认团队配置：
如果这个 项目组织架构的搭建 是"龙象功"中的一招，那应该是最厉害的那招，实话说这招我始终，始终没有练会。 这个组织架构的模型也不是我原创，主体还是抄了《华为项目管理之道》中的APTE框架；
为什么？为什么这招这么难练，正对着那句话： 做对事选对人，选对人才能做对事！
在我现在任职的公司，一直没有这种项目总监的说法，更习惯的模式，还是 IT出一个IT项目经理，业务方出一个业务方项目经理。这种内部甲乙方项目经理，看似双方把责权利都分的清楚，实则乱七八糟，我做了几个项目下来有内部甲方真把自己
当甲方的，有IT项目经理遇到业务问题不知道招谁去出解决方案的。 还有那种外部采购项目内部的两个项目经理，遇到问题就甩给供应商，只知道给供应商项目经理施压的。
乱象丛生，我内心里还是还是十分认可华为这套APTE架构，先不管项目中的title叫什么，总归从抽象的角度来看，一个项目肯定要有人负责业务价值（AR）、解决方案（SR）、交付执行（FR），这也被陈为项目铁三角；
好比AR，你可以叫产品经理、也可以叫业务侧项目经理，但肯定是要有专人来负责这个。
好比PD，我还是认为一个项目只有一个负责的Leader，什么内部甲方项目经理、内部乙方项目经理、供应商项目经理，拉扯起来谁听谁的呢？
惭愧的是，从我写完这份项目管理手册以来，已经实践了至少3个项目，都没按这个方式来，特别是PD这个位置，从来没有定准过。
也许跟企业的文化有关，毕竟这个为止是自上而下的，我这个level其实定不来这个，再说PD这个地方要找一个合适的人来胜任，极难！！
但是，我还是希望能践行这一套架构，一个项目有且只有一个负责人！
===================================================================华丽的分割线=================================================================================
在写制定这份项目管理手册的时候，我一直在想一种"还原论"，试图以一种产品设计的逻辑来思考问题，就是说如果这个《项目管理手册》是一个产品的话，那它是不是应该还原成最简单、最基础的组成元素。
而项目指导手册最基础的组成元素，我认为应该只有： 项目类型、项目组织、交付模式 这三种元素。 而这三种元素组合出来就会推演出不同的项目管理架构；
我这么说还是有点迷糊，举个例子：
- 项目类型：新系统建设；
- 组织架构：APTE模型；
- 交付模式：瀑布模式；
如果是这三者组合在一起，就会出现我图中最左侧的瀑布管理的架构，这里我称之为最低交付要求，也约束不同角色的职责，类似于RACI；
以此类推，项目类型+组织架构+交付模式=项目管理架构 （图中标题叫：项目交付模式其实不准确）
这些交付物(文档)的定义，我也同样是采用这种"还原论"的思考方式来制定的，列出的是在各种交付模式下的 最低管理要求 。
尽管我的下属向我抱怨，即便是最简单的敏捷交付模型，依然有繁重的 【Paper-Work】， 可是根据我踩过的坑，这些Paper-Work是能保命的，解决的是工作留痕以及信息对齐的问题；
===================================================================华丽的分割线=================================================================================
关于第一部分：基础体系，就先写到这里。 差点忘了，我把整个手册的目录贴一下：