今日分享：朱兰《质量手册》第五版，初识PQM（过程质量管理）P188~192，
书中内容：
什么是过程？
业务过程是为产出预期成果（产品或服务）而将人员、材料、能源、设备和信息结合成为工作活动的逻辑构成。
传统上，过程的每一块职能部分均由一个部门来负责，该部门的主管对这块绩效承担义务。然而，产出产品，尤其是顾客所购买产品（组织因此而存在）的那些过程却是横跨组织的职能部门水平地流动着的。传统模式中没有谁对整个过程负责。
为什么要管理过程？
当今企业经营的动态环境的特征可以概括为所谓的“六个C",即change (变革), complexity (复杂性)、customer demands (顾客需求). competitive pressure (竞争压力),cost impacts (成本冲击)和constraints （约束因素），这些因素显著地影响着组织实现其经营目标的能力。
经营目标的实现在很大程度上取决于那些大而复杂的跨职能业务过程，如产品计划、产品开发、开具发货清单、患者护理、原料采购、零件分销等等。这些如果长期得不到管理，这些业务过程中的许多都会变得过时、过载、累赘、成本过高、定义不当，不能适应持续变化的环境的要求。
过程绩效不良的主要问题源自部门要求与整个过程的要求之间的冲突。
过程绩效不良的另一原因在于所有过程在演化过程中均会遭受到的自然劣化。
以上这些都需要通过持续的过程质量管理来改善。
如何衡量过程好坏？
衡量过程的质量有三个主要的尺度，即效果、效率和适应性。
效果衡量：若产出能够满足顾客的需要则该过程便是有效果的。
效率衡量：若能以最小成本实现其效果则该过程便是有效率的。
适应性衡量：若随着时间的流逝，该过程面对所发生的诸多变化仍能保持效果和效率，则称其具有适应性。
过程质量管理（PQM ）的核心特征：
由质量控制、质量改进和质量计划所构成的质量管理过程在过程层次上的应用。这一方法具有一些共同的核心特征，这些核心特征包括：
有意识地面向顾客和顾客的需要；
对最影响顾客满意的少数关键的跨职能过程的特别关注；
每一关键过程有着明确的责任模式；
负责过程运作的跨职能团队；
读书感悟：
软件产品和服务的业务过程：
顾客需要-->售前方案-->合同签订-->需求分析-->系统设计-->开发-->测试-->交付-->运维
不同的子过程由不同的团队主责，每个过程都会为最终的产品产生影响，CMMI中的工程过程，占了很大的篇幅，本质就是软件过程质量管理。
新兴起的软件敏捷开发模式以及Devops模式，和CMMI相比，在过程质量管理上做出了革新，具体体现在：
1，PO，开发，测试 作为一个Team，一起工作，打破了需求分析，设计，开发，测试 之间的部门壁垒，信息传递和响应更高效；
2，SM的角色，保持Team免受外界其他因素干扰，作为专职的跨职能团队人员，为运营和团队成长负责；
3，工作的软件高于详尽的文档，将对最终产品作用不大的文档弱化，瞄准最终可工作的软件；
4，响应变化高于遵循计划，这点与有意识地面向顾客和顾客的需要 不谋而合；
5，Devops使用从交付前端到最终交付后端的一整套工具，将产品生产过程线上化，改善了关键过程的时间滞后，以及信息传递失真的问题；
敏捷运作模式在过程指标衡量方面的表现：
效果：
产品需求池梳理，以及迭代演示会，邀请客户参与，让业务职能部门更接近用户声音，保证最终产品的效果和客户预期一致；
效率：
尊重每个个体，激发其主观能动性，加上更准确的客户需要识别，减少了返工的内耗，整体成本和瀑布模式下的成本相比，有明显优势；
适应性：
和传统瀑布模式相比，敏捷模式的适应性更强，双周一个迭代，将纠偏和方向调整的周期缩短，意味着团队能够更快地适应外界变化；迭代回顾会让团队成员总结经验沉淀，能够快速应用到下一迭代中，有助于团队适应性的提升；
以上内容属于书中和作者观点，请大家以辩证思维阅读，结合自己经验，多看，多思，选择性吸收。
网友评论