我对软件开发质量管理的认识

好了，我说一下我对软件开发质量管理的认识。先声明，我从来不觉得我说的话就是真理，认同不认同是各位的事情。只是我个人工作经历的思考。

我个人对软件开发的质量管理认识经历了三个阶段：

1.质量管理就tmd得管着那群不爱守规矩的技术猿们，不听话我就检查、评审、考核，考死你们；

2.管理即时服务，我要当技术猿们的仆人，为项目组做好服务。亲们，你们说我咋做你们才能愿意按规矩工作？

3.我定好规则，你tmd爱咋开发咋开发，才懒得理你们。

在第一个阶段的时候，我觉得质量管理工作就得依靠QA,QC.配置管理员等等各种跟质量管理相关的人来时刻盯着项目组的人。你这里没按流程来，你那里写的不符合规范，不符合模板，你写的程序bug率太高了。那时候头脑里都是“管理”、“控制”、“检查”、“工作提醒”……等等这些另程序猿们各种不舒服的字眼。

质量管理部作为一个检查部门，一般与研发部门是评级的，即便有的公司是级别比较高的，但因为不是行政的主管，还是个挑刺的部门，总让程序猿们反感，觉得被这样挑错式的管理是各种不舒服。所以研发部门会从上到下一致的抵制质量管理人员的工作。当然也有讨好的时候，当项目组能拿到项目奖金，且项目奖金的最终部分决定权在质量管理部门手中的时候，项目经理才会媚笑着跟质管人员套套近乎。

因此，质量管理工作不好做，不好推行。必须是一把手工程，必须让老大们给一把尚方宝剑才好使。即便拿了尚方宝剑，你也不能轻易用啊。技术人员随便一个工期紧张，你还要不要我按进度完成项目？随便几个借口就会让老大们乖乖的闭嘴。那时候在质量管理部，每天就想着如何跟技术人员们斗智斗勇，怎么能卡住技术人员分7寸，让他们乖乖的按照既定的流程和规范开发程序。

总是这样剑拔弩张的也不好吧？公司的领导们经常给质量部门和研发部门进行矛盾调和。在研发部门在公司的重要性的作用下，老大们没有像开始那么支持质管部门了。开始说服质管部门要注意跟研发部门的沟通方式，不要老想这管别人，限制别人。要转变思路，把自己变成研发部门的服务部门，质管人员都是服务人员……老板们的沟通能力就是强，一番苦口婆心下来。质管部门开始屈服。好吧，质管工作还得做，需要转化矛盾。

于是质管人员见程序猿们开始卑躬屈膝，见面先行礼，先到个万福（女QA）爷，您辛苦了，最近忙不忙？您看您有什么事儿小的能帮忙的？那个流程手续您抽空给补了吧？什么？工期压力很大，没时间？那咱简化成不？您看，您这个项目一直没交项目计划，都开发大半年了，我们也不知道您这项目开发到什么时候，我们的质量周 都没法写啊。哦，您说忙的没时间做计划？而且计划总是变化的，做了也没用？（你家计划要都不变，那还叫计划么，直接叫标准好不好？tmd做计划的时间没有，天天中午有时间一顿饭吃俩仨小时），您看是这样的，您这计划不做，老板们就不知道您到底都有什么工作能做，什么工作需要其他人配合的，如果该其他人或甲法做的工作，您都没说。等到最终项目无法按甲方和老板的要求验收的时候，挨骂的都是您。您这计划不仅仅是简单的做个工作任务分解、排个日期，分配个人员，这些都在您脑子里直接跟程序猿说就可以了。可是计划还包含了很多的配合任务啊，您都不说，别人咋知道呢？您看，为了减少您挨骂的风险，您做了计划肯定比不做计划占便宜。结果，为了一个项目计划，就废了姐一个多小时的游说工作。

技术人员为嘛那么讨论走流程？那么讨厌写文档？那么讨厌做计划？那么讨厌规范行事？个人总结就四个字：能力不足！！！

让程序猿或技术人员写文档是第一大难事，很多程序猿程序可以写的还不错，但写文档就不行了。这要追根溯源的话，就得扯到咱们的教育体系本身的弊端上了。高二开始文理分科，基本就把一半人的另一半能力给砍掉了。所以，很长一段时间我都最喜欢的是理科很牛，同时文笔又非常好的理工男，简直到崇拜的地步。而且很多技术文档，可没有写小说可以那么随意、天马行空的。技术文档里面体现了很多方法论的问题，体现了不同的思维方式的展现。程序猿习惯了代码的逻辑if else,if then,函数的调用关系。却不明白站在用户的角度描述需求的方式，不懂在系统高层的角度描述系统架构的方式。就是陷入细节的人，就不容易把握全局。习惯深度思维的人，就很难适应浅薄（非贬义）思维。

不愿意做计划的技术人员是实际上是计划能力、规划能力不足、考虑问题不够全面，同时对变化的事情又难于控制把握。所以会以计划总是变化，做了也没用来当借口。还有一个就是懒惰，认为被客户牵着鼻子走是非常容易的事情，而且还好跟公司当作借口。

说个题外话，在跟各种程序猿打交道的过程中发现一些问题（不一定是普遍规律）：

1.非计算机类、跟写程序类相关专业出身的人，程序可以研究的很深入，但是规范度不够；

2.研究生以上毕业的人，做事情的规划能力、系统化能力相对较好；

3.大部分博士都是工作非常认真负责的；

4.嘴皮子好事的程序猿写文档的能力更差。

现在又回到质量管理的工作，我既懒得跟程序猿项目经理去吵架，懒得对他们做控制管理，更不愿意去卑躬屈膝地讨好那些我觉得远远达不到让我崇拜的程度的程序猿们。而且在跟程序猿的交往过程中，也发现一些人才，对他们的管理简直舒服的不要不要的。话不多，告诉事情怎么做就规规矩矩的做，过程中不懂及时沟通，做完会及时通知。这样的人做的事情虽然不说完美，但基本能过得去就ok。有空的时候愿意学习的，就多指点一些，多鼓励。然后程序猿的自我成长飞速发展。

所以才想到，与其跟程序猿项目经理们等技术人员斗智斗勇的做质量管理，不如提高他们的各种能力。能力提高了，认识提高了，知道怎么做事是大家你好、我好、他也好。质量管理工作自然好做，只要规矩定好，让项目组自己执行，有不合适的地方提出来改进就行了。

我国公司里等级制度也很严重，以为一个领导带一群兵，这群兵乖乖只听这个领导的话，就是一个好团队。但与那些团队里每个人都具有领导力，都会以领导的角度思考问题做事的团队比，就弱爆了。都具有领导力的团队效率更高，考虑问题更全面。去看看海底捞的企业文化，我觉得跟这个每个人都把自己当领导类似。海底捞是每个员工都以老板的心态打工的。

再闲扯一个cmmi的事情。我参加过几家公司的cmmi评审过程，大部分强调的还是组织级的过程管理，项目组的过程管理等。没几个公司会强调个人cmmi的实施管理。

曾经看过一本cmmi的书，书中强调的一点就是：“每个人的cmmi做好是公司实施cmmi的基础。”

因此呢，我对项目经理的建议，哦，不各级领导们的建议，管理手下不如培养手下。如果一个项目组每个人都把自己当项目经理去考虑项目组的研发事情，大家开会集思广益，提高的可不仅仅是项目组，个人的能力提高也是几倍几倍的。

那些不管是在职场中，还是在自己的人生中不愿意成长拒绝成长的人，终将被淘汰。

推荐：