今天这篇文章，是初入简书的第一篇，也是锻炼自己通过简书复盘个人成长经历的开端。
一、自我介绍。
本人从业经历单纯，甚至有些过于”纵向”。总体来说一直在做质量管理、项目管理、PMO等岗位工作。先后任职民企、国企、上市公司、合资企、银行等行业，对其中各个企业的管理体系有深刻的理解，也颇为感兴趣。系统接触管理思维包括CMMI、GJB系列、ISO系列、IPD、ITIL、pmp、prince2等，直至2017年正式报名光环ACP课程，成为正统的敏捷门徒，有幸真正打开敏捷学习及从业之门。当然还有什么devops、管理x.0这类的还没有到吃透的地步。
二、聊聊“管理体系”。
开发人员从业的基础是IDE开发环境，这就是他们的工具，也是套路；各种环境+配置是支撑开发人员开展工作的第一步。那么对于IT项目管理从业者来说，我们的“套路”就是管理体系。按理说好好捋一下应该是，先有公司环境，然后搭建公司的项目管理体系、销售运营管理体系、售后管理体系等，他们是这样一个关系。但是对于项目管理人员从业者来说，从道法术的角度，一个合格的项目管理人员在上岗时候心中应该是至少有一套完整的管理体系的，这才是能够支撑管理者开展工作的工具和环境。
说到“管理体系”，这是能够反映一个软件企业成熟水平的一个东西。大企业有相对完备并且使用灵活的体系；成长中的企业有相对实用的规章制度流程规范等；小企业有自适应本地化的要求。与此同时，民营企业有民营企业的“精简适用”管理作风，国企、银行、政府等行业相对就是比较规范的管理配套。
但是，目前。针对“管理体系”，范围缩减到开发类项目的管理体系，普遍采用的基本分两种类型。一种叫做传统项目管理体系。一种叫做敏捷项目管理。而传统的也分为两个流派，一种项目管理体系的搭建是基于CMMI模型，一种是基于PMBOK（五大过程组、十大过程领域）；顺便说一句，还有人提到的高级项目经理宝典（信息系统项目管理师），其实实质也是基于PMBOK。
三、传统开发项目管理体系 之 基于CMMI模型的体系
CMMI,美国的，软件能力成熟度模型。分为5个等级。初始-优化级，目前国内刚开始采用CMMI2.0评估模型，它有20多个过程域。针对一个企业项目对过程域目标和实践要求的匹配性，来评估企业项目是否在这个等级达标。
CMMI其实挺鸡肋的，但是它这个对于一个企业的作用其实是挺复杂的。大致作用我总结了一下
第一，商务作用。我们常说的公司资质。投标用嘛。人无我有，人有我优。这些年也是被做烂了，对于一个企业是否能整整达到CMMI相应等级，其中水分含量也不得而知。反正这方面作用只有商务知道就好。
第二，真正的管理指导纲要。抛开CMMI的商务作用。其实仔细研究，它确实是一个值得深入学习和研究的纲要性的东西。从道法术的角度，我觉得应该是“法”。百科全书了解一下？这就是美国人高明和给力的地方。能够这么详细的罗列出来做一个项目在某些方面应该符合什么要求，你做到了就是好的。所以，这也是项目管理从业者比较兴奋的地方，入门极其容易，计算机毕业做不了开发是吗，没问题来一套百科全书，走上项目管理之路吧。我猜最开始很多人都是因为接触到了这样一套CMMI模型及其配套实例化的系列文档，开始走上了类似QA、体系工程师、内审员等岗位。但是这只是开端。
因为，任何一个企业，你拿着一套束之高阁的模型去指导具体项目的实施，我猜多数人是不会答应的。怎么办呢。怎么办呢？其实这是通常通过起来最难的地方。如何让这些知识能够对我们的项目发挥作用呢？这就不得不提企业中通常具有的一个部门了，它们可能叫PMO、或者项目管理部、或者质量管理部等等类似智能的部门。干啥呢？就是讲模型体系知识与自己项目特点类型本地化结合。怎么讲？比如我们是做国网项目的乙方，我需要对我司项目的需求管理过程加以规范化管理，确保符合甲方的要求，同时也能达到良好的需求管理作用。那么这时候，翻开我们的CMMI模型，对需求的约束大概是两部分。其一，需求开发。包括需求调研，需求分析，编写需求规格书。其二，需求管理。包括需求确认，需求变更控制，需求跟踪。那么这些法术如何运用到我们的公司项目管理中呢。这就需要PMO组织相关的人针对公司的项目类型进行界定，对管理方式进行探讨，直至管理内容覆盖需求开发和需求管理的部分。最终形成必要的管理要求、流程、模板极其案例。过程配备必要的宣贯引导和监督检查，确保流程能得到正确的理解和使用，久而久之能看到的效果就是大家都按照界定的这套标准去做项目去跟客户进行确认签字，对于变更有界定，对于变更内容有记录和追踪以及有理有据的跟甲方斗智斗勇。
最后，梳理一下，基本上基于CMMI模型的管理体系是很好识别的。打开一般分为四个文件夹：组织管理（组织资源等）、支撑管理（质量、配置等）、项目管理（对于风险、资源等）、工程管理（从调研-验收）
至于使用范围嘛，反正我接触的银行、保险、政府、国家电网等行业其实走这管理体系的比较多。原因？规范嘛，规范就会避免很多走捷径精简的风险。稳~ ，当然，稳的前提下，效率自然不容易提现出来。
四、传统开发项目管理体系 之 基于PMBOK模型的体系
实话说，单纯用PMBOK搭建企业项目管理体系的真没怎么见过。但是接触过做的好的大厂，基本都是PMBOK+cmm的结合。其实，如果真正接触这些管理思路，我们会发现，总体思路和控制点其实是一样的，只是分类的纬度不同和使用的类型划分以及管理的深度不同。
PMBOK相比于CMMI体系贯标至少会有一套模板案例来说，它没有具体的指导性流程。但是会告诉你在某个知识领域开展工作分位哪些步骤。你做吧。“方法”的层级。其实，具体企业执行恰恰缺的就是能够将方法引申转化为具体执行“术”的牛人。这也是最考验组织项目管理体系搭建是否能够在企业成功的标准。方法对术不适用也是很难执行顺利的。但是好在一直还是有这么多从业者在孜孜以求的探索和改进着，至少个人感知，2010年时候，也就是十年前，IT项目管理体系完善度、适用度以及整体行业的成熟度都是与现在不可同日而语的。
一个简单例子，09年听说公司领导是PMP花了将近一万银子，觉得NB至极呀。。现在嘛，刚毕业两年的同事跟我请教考完PMP，想再继续攻坚一下信息系统项目管理师应该注意哪些。
五，敏捷项目管理。
最近开始流行敏捷项目管理，大家都知道的哦。
首先，抛开敏捷官方的3355定义,我们需要思考一下，为什么现在用敏捷项目管理的多了。它有什么好？都谁在用敏捷？
个人理解，还是节奏快、竞争激烈带来的产物。真正学习了敏捷和运用了敏捷，我们都知道这种思维跟我们传统的项目管理的控制点，没有本质的区别。那么为什么用它不用它呢？
还是在于敏捷其实提供的是 道法术中术的东西多一点。就是可以参考的术比较多一些吧。相对于以上传统管理方式，之所以被称为传统。实际它们都在执行一个思路，就是“谋定而后动”。通常先计划再评审，评审通过再执行，执行过程有监控，发生偏差要纠正。是不是很传统，是不是很中庸，是不是跟我们从小被灌输的各种理论对得上。但是这种思维跟我们项目实际遇到的痛点就匹不上了。现在我们做项目都是争分夺秒，尤其做产品，争分夺秒这个词儿一点不过分。你晚出来面世一周，你就可能被扼杀在摇篮里。所以我也不要求你做的多完美，你先让使用者先看到一部分。给点信心，我们慢慢将它做强做大。大概就是这个思路。而我们原来的做项目怎么做呀。做一个宏大的计划，甲方认可了。开始干，干完需求找客户吃个饭签个字，没问题我们就按照这个设计，设计完毕，吃个饭签个字；我们就按照设计开始搬砖码字了，过程甲方可能根本都不参与。等到真正做好了拿给甲方看时候，甲方开始骂娘了，老子给你们那么多钱，就给老子弄这样的。我们自己也委屈，你都签了好几次字了呀。。。两种情形相比之下，是不是第一种对双方的损失会更小点。这就是之所以现在做项目越来越多采用敏捷的原因吧。
以上，感谢阅读。 个人微信：js_alice 公众号：晓陆成长社区
转载请微信先告知，谢谢~
网友评论