体系化敏捷管理架构（四）

4、敏捷管理在质量管理体系中的优势
　　我们可以比较容易的做到让做事的人提交工作结果，比如：述职报告、会议纪要、技术文件等，但只是提交而已。通常的体系管理中，是用一张张表单来规范这些提交结果的。带来的弊端有两个，第一是随着管理的精细化，表格会越来越多，工作越来越形式化；第二是规范化管理不适合应对变更和突发情况。
　　在我曾经工作过的一家实行13485体系管理的企业，就一直重复发生着这样的事：一款有缺陷的产品在生产着，知道缺陷原因，技术部门根据销售提出的需求做了改进，中试，并通过评审，可以落实到产线；向生产和采购部门发出变更通知后，便引起轩然大波；因为落实这个对产品的简单改动，牵涉到从销售到生产乃至财务所有部门，望着需要完成的一堆表单，哪个部门都不愿先动手。整个公司如临大敌，销售催技术部门强推；技术部门督促采购订货；采购部门催生产计划订数量，催财务添加料号；生产计划说按新BOM表的产品没有订单，催销售部门落实订单数量；财务催仓库统计现有零件库存，催采购部门统计未交付原零件订单；产线催仓库配料生产；仓库催生产计划确定按哪个BOM单生产；生产计划又催销售部门确定那些订单用新零件；销售部门催采购落实新零件交货期，之前无法确定更改数量；。。。最后闹到老板那，老板特批采购先买100个试试；一番折腾后，销售怕下一批产品，订货跟不上，拒绝100个装新零件的产品发货，又闹到老板那；最终100个产品又装回老零件。再后面，这件事就不了了之了，直到客户又因为相同质量问题投诉退货。
　　上面的例子这家企业里还有类似的很多版本，但结果相同：小小的事做不成，只有老板不顾体系规定亲历亲为才有点用。完善的表单、规范，的确降低了对岗位用工素质的要求，让人机械的做事，从而提高了效率，稳定了质量，降低了成本。然而一旦需要许改变和调整，质量管理体系就像一块铁，宁折不弯，所付出的代价就是不得不废了整块铁，换上新的。
敏捷管理体系中，只有需求单和评审表单，两种表格，强调对成果的实时消化和传递。上述的例子如果按敏捷管理体系的方式执行，就会是另外一个样子：
　　销售提出了改进产品缺陷的原生需求，经公司评审通过后，如指定销售方为该需求的总发起人，则销售方成为这个需求中最大权力者（当然也可以指定其他人，只要评审中通过）。销售方将这个大需求拆分，首先流转子需求要求技术部门完成整改，通过评审；然后要求采购取得新零件的供货周期；得到采购信息后，再根据自己的订单情况供货情况，要求生产计划对安排生产变更；生产计划接到这个流转需求后，向采购提出购买新零件的需求。。。每个部门在公司规定的职能权限内，向需求方负责，并流转自己不能完成的需求。每一个终端需求发生异常，都会由父需求进行流程调整，如还是无法解决，由父需求的父需求负责变更需求。这样无论是订单延迟，还是生产工艺有问题，相关父需求都会第一时间介入解决。销售方即使安排有误，会因为子需求无法完成，第一时间得到通知而变更需求。你会发现，敏捷管理体系会神奇地自动将执行人逐步地推向正确地流程，并最终满足需求。

5、敏捷体系框架如何解决常规权力分配和实际项目管辖权之间的矛盾
　　敏捷体系框架需要对原生需求进行评审，这个很重要。在传统PMP管理中，项目经理是被动地接受要管理的项目的。殊不知，在项目合同签订时埋下的锅，会背在项目经理身上。名义上，项目经理权力最大，但再大的权力也无法解决原生需求中的先天缺陷，而造成这个先天缺陷的人却不对这个锅负责。造成这样尴尬局面的原因是因为没有对原生需求进行评审。很多公司会有规定和合规部门去审核项目合同，事实上会流于形式，因为后续项目如何开展和当初审核的人没有直接关系了。
　　所以在实施敏捷体系框架的PMP管理中，接受需求后，项目经理权力不仅最大，还赋予他向签订合同的销售、合规审核人员等流转子需求的权力。当项目实施条件得不到正常满足，他有及时止损，或变更需求的权力，向挖坑的始作俑者流转需求的权力。同时审核机制又对项目经理的行为进行约束，约束人必须对其做出的评审结果负责到底。评审人可以拒绝项目经理所代表父需求通过评审，令其整改。但项目经理有其子需求的一票否决权和发起新需求的权力，可以责令评审人连带或协助完成项目整改。这种相互约束的机制，会把背后的相互推诿，直接暴露在台前，无所遁形，只要公司最高层面想解决问题，就一定可以解决。这种相互约束的机制同样可以应对抱团舞弊问题，在关键需求中加入中立方作为评审人后，能及时发现相应问题。如当时评审机制无法解决的，中立方可以保留意见并发起原生需求交公司高层评审通过后，进行舞弊问题调查和追溯。
　　我以一下例子，进一步说明，这是一个世界500强企业中几乎天天发生的事：
　　销售和客户商谈价格，因为某个设备的改造按规定一定需要公司的外方工程师来做，价格下不来（当然降价其实是可以做的，只是灰色油水少了很多）。销售就咨询项目部门的经理级主管，主管口头向销售保证可以在项目执行时不要外方工程师参与，于是销售就降价签下了这个合同。走形式，合同也自然是通过合规，这种细节费用不细究是谁也搞不清楚的。在项目执行时，项目经理发现一笔预算大大超支了，这笔预算就是需要外方工程师的费用。向销售询问，销售说是项目经理的领导同意的，于是项目经理试图按此操作，向公司外方发出的内部订单中没包括外方工程师赴中国现场调试的费用。公司外方部门，当然不接受这个订单，因为不符合公司规定。到这一步项目做不下去了，开会讨论，项目经理全盘否定了自己当初的说法，把销售卖了。而且即使搞到了进口零件，国内工程师的安装调试不能保证施工质量达到合同规定标准，这种风险没有人愿意主动站出来担责。
　　抛开公司内部积重难返，暗箱操作，灰色的部分不谈，到目前为止把无辜的项目经理顶到风口浪尖上，而且他没有权限解决。如果使用敏捷体系框架去做，这时项目经理可以把解决问题的子需求流转给这个部门经理和销售解决，让埋锅的人自己背锅，承担责任，以后就不敢埋锅了，。
　　敏捷体系框架按需求最大的原则，将权力临时赋予需求方。整个体系中的角色都需要为满足需求服务。当需求完成后，权力灭失。常规的权力分配是按部门、职称等公司部门架构制定的，这种权力和职位头衔就像军衔，代表了身份和能力的评级。而销售、项目经理、工程师等是做事时的职务（角色）。在敏捷体系框架中可以这么认为：从公司行政管理的需求角度看，公司按部门设置的职位和相应的权力时有效的；从项目执行的需求角度看，按部门设置的职位无效，按项目设置的职位及权力有效。

6、写给老板看的话
1）老板的个人能力变得不重要
　　公司和团体时一个集体，个体再有能力，如果不能发挥集体的力量，所得到的成就时极其有限的。这就是体系的作用，让大家一起按规则做事。敏捷体系框架中每个自然人都是平等的，一旦老板作为一个角色投入这个体系，他既可以通过总需求控制公司整体运行节奏，也可以作为终端需求执行人解决具体问题，更可以参加评审、变更需求决定一些关键点的生死去留。
　　所以老板的个人能力变得不重要，他的决定性特征不是拥有公司股份或法定代表公司，而是公司部分或所有最高层需求的发起人。这样也利于合伙人制度的推行，合伙人之间的矛盾也容易化解，法律意义上的责任追溯更加方便，他们之间会更倾向于合作解决问题。

2）实行之初的阵痛
　　敏捷体系框架的施行是要有决心坚持的，如果没有忍受最初阵痛的决心，没有坚持体系规则的决心，不如不搞。敏捷体系框架是建立在可追溯原则下的，施行后会让原先隐藏的灰色面甚至黑暗面无所遁形，浮出水面。所谓的阵痛并不是面对这些毒瘤，而是拔除它们。你会发现原先认为办事得力的助手，其实只会拍马屁，欺上瞒下；原先不听话的愣头青，原来办事勤恳踏实；采购在明目张胆的收回扣；财务在做假账。。。。一夜之间，天塌了。
　　这时候，不要慌，坚持是第一步。按体系流程去解决逐步解决问题，体系会帮你去发现那些真正有能力的人，将他们和你之间的距离拉近。但在什么时候用什么方法，仍需要自己去尝试。不要害怕发布的需求无法满足，无法满足是因为你没有坚持、没有按变化去调整变更。

3）一言堂是体系施行的大忌，要学会放手
　　敏捷体系框架中的人虽然是平等的，但为了服务于最大的需求所有人，生杀大权还是掌握在这个最大的需求所有人手里。老板要是还是啥事都要管，啥事都要经自己审批，体系的存在是无意义的。
　　敏捷体系框架的最终目的是让专业的人干专业的事，把老板从琐事里解放出来。所以，要学一会慢慢相信体系的作用，放手改变自己，而不是榨取体系的其他优点。体系没有要求你一下子放手，但阵痛过后，就应该逐步放开。要试着用制度和规则去约束办事的人，允许其他人逐步适应和不断进步。某种意义上说，你放开的程度越高，意味着体系运行的越成功。你所作的应该是在真实的数据上指点江山，或者干脆享受一群人高效打工给你带来的利益。

4）敏捷体系框架去伪存真后，再任性妄为，不是人傻就是钱多
　　当提出需求后，敏捷体系框架是按事务自然发展的规律来执行的。如果一个需求不切实际，是拍脑袋任性提出来的，首先是通不过评审的。万一评审时，大家的眼睛都瞎了，不敢和老板对着干，同意继续，那就流转。执行人拿到需求后，无法执行，按规则肯定不能背锅烂在手里，会拆分出子需求，让提出原始需求的人去面对那些不切实际的需求点，如：市场调查、民意测验、头脑风暴、更换执行人。这些流程走下来，会让不切实际的需求止步，但不会抹杀那些看似不切实际，但实质是创新的需求。创新如果没有人去尝试，那就是条件不满足，如：资金、奖励、技术积累等，总之随着工作的开展，问题点、闪光点、阻碍、利益等一切都会浮上台面。当反馈给公司决策层的信息会越来越明确，高层所要做的是根据真实信息来判断和决定。当事确不可为，虽然没有后悔药，但可以及时止损。当这一切还是阻挡不了最终失败，作为当事人的老板应该是无怨无悔的。但必须指出的是，敏捷体系框架不会阻止你再一次重蹈覆辙。
　　很多创新团队都在做不可为之事，所以被认为是在烧钱。敏捷体系框架中并没有阻止烧钱，但要求每一步烧钱要烧出结果，这个结果包括失败的原因，总之钱多不能乱烧。通过分析烧钱得出的结果，来决定下一步怎么烧钱，乃至赚钱。