软件质量的焦油坑

阿朱出品 必属精品

此文章是源头是昨天我的一个朋友抱怨他们团队的产品质量不高以及他认为啥啥问题，我给他讲的一个故事。我告诉他，你猜测的问题、根源以及解决方法，可能都是错的。嘿嘿

我经常回忆起人月神话中的一段话，栩栩如生：“我们看到恐龙、猛犸象、剑齿虎正在挣脱沥青的魔爪。挣扎得越剧烈，陷入的越深，没有哪只野兽足够强壮或熟练，它们最终都沉没了。大系统编程在过去的十年间就像焦油坑，许多大而强有力的野兽在其中已经惨烈地失败了”。

软件质量不高，是一切最好的由头或源头，于是，噩梦开始了。

一、是架构或平台有问题？

于是整平台。从性能、安全、可安装部署、可系统初始化数据初始化、可运维监控报警可诊断、可产品改进、可更自由的二次开发，一路改进。这消耗了我大量的心血。既要继承过去（否则升级难度极高，给定制开发团队和实施团队带来阻碍），又要面向未来。

底层平台改好后，上层业务应用系统也得匹配改啊。

于是，梳理接口（URL层接口、JS层接口、逻辑层接口、数据层接口）。接口梳理好，没用的，调用不符合规范的，通通改。这里面我带领团队研发了接口标准规范、接口检查工具等等。

二、是有平台大家不会用或瞎用吗？

有了好的平台，需要推广啊。但我发现平台做的东西对于应用研发来说不怎么感兴趣，一句老话：我想要的你不给开发，你开发的都是通用方案我们还得写很多代码，所以你的平台没啥多大作用。

于是，我又建立了定期反馈沟通机制。让平台研发骨干和其他研发中心的开发leader每月沟通座谈一次，梳理需求分析需求完善平台。

但是，发现平台明明有这个功能，但应用研发还是自己开发。应用研发线的人员对平台并不熟悉。于是，我安排平台研发中心完善文档、做FAQ、做沙盒测试环境、做DEMO。并且在新版本发布后，规定平台研发人员到各个应用研发中心主动宣讲新版本变化。并且积极动员平台人员日常写最佳使用平台实践的文章，在内部问答平台上积极主动回答问题。

三、是应用研发人员瞎用平台吗？

做了这么多平台研发人员的工作，还得做做应用研发人员的工作。

明确规定了开发Leader的职责，结束了开发leader和核心开发的混淆历史。但开发leader有了专责后，核心开发又没有了人手，这个问题另外解决。

开发leader要：

分析方案、设计接口、识别共用代码、分析BUG

根据以上分析，得出日常开发规范最佳实践，并且进行推广

根据以上分析，研发代码生成工具、代码模板、代码检查工具和检查流程检查动作要求，并且进行推广

为了开发leader能这么做，而不是继续事实上回到核心开发的角色，还为开发Leader按此规定了明确的绩效，还有排名还有奖励。

四、质量不高，是测试不到位吗？

我也觉得有这个问题。因为大量测试人员不懂技术，只在外围做功能测试。

但测试人员还在流程机制上存在另外一个问题，就是前期产品经理和客户讨论时，开发人员和测试人员都不能参与讨论、前期方案学习、预备设计。所以开发人员和测试人员对需求背景、来龙去脉变化（这可能影响未来设计尺度）、对功能要求都不太熟悉。

所以我又改变了工作流程。让开发leader、测试leader在方案讨论期就一起讨论一起设计一起学习。并且还启动了交底机制。也就是说，产品经理给开发人员测试人员讲解功能，然后产品经理提问开发人员测试人员看他们懂了没懂，对大家共性的盲点给予强调重申。在开发后但还没有提交测试前，产品经理要自己先预测一下，觉得在业务实现没有扭曲没有大遗漏再提交测试。在测试方案出来时，产品经理要过一遍测试方案，看测试重心对不对、测试场景遗漏没。

为了让测试到位，还启动了测试转型。招聘有开发基础的测试人员，在新人招聘新人训练的时候不分岗位，根据工作能力工作特点分流到开发岗和测试岗。对于现有测试人员，进行开发能力培训，对于没法接受开发能力提升的，转型转岗到QA。这都是血泪史啊。

对于转型成功的，就开展灰盒测试、白盒测试。对数据变化进行测试、会自己自动化制造数据、自动化测试、也会利用平台研发人员制作的一些工具进行接口测试。

五、是组织分工有问题？是有些事没人干，有些事瞎干吗？

过去我们开发新产品，都是一班人马，从客户需求调研、第一版原型、多个试点，成为产品V1.0。这样的产品势必在架构、快速验证、试点定制方面存在多方平衡矛盾。致使新产品一出现就带有根的缺陷。

于是，我们把新产品研发独立出来团队叫创新产品研发，专门做新产品原型，目的就是快速验证客户市场是否存在、新产品是否满足客户需求。所以需要快速而脏的开发，赶快找试点去给客户用，客户反馈立刻修改。

但是这样的代码怎么可以用于大规模商用和长达10年的市场推广呢？于是，我们又有了新产品研发中心。把试点好的产品原型，和当做竞争对手产品研究一样。研究完了，按照新的架构设计、产品设计，全部重新代码开发。曾经我们想走捷径，能重用的代码尽量重用，新产品研发中心也为了赶工期于是就尽量重用，越做越有问题，最后还是绕了回去。这个现象需要大家警醒。

新的产品刚刚出来还有不少细节问题，而且定制研发中心的人还不熟悉。于是我们又启动了扶上马送一程的机制。也就是说，第一个客户交付系统，由新产品研发中心主做，定制研发中心派来项目经理/产品经理/开发leader/测试leader一起干。到了第二个客户交付系统，由定制研发中心主力承担，新产品研发中心也派来这四大骨干角色，但主要做方案把控和成果审核。到了第三个客户交付系统，就由定制研发中心全部承担，有了问题问新产品研发中心的明确对口人，别到处瞎找人，别自己瞎琢磨。

我们过去大客户定制和小客户定制都放在一个定制研发中心。但发现大客户定制的方案复杂度高、周期长，而小客户定制中心都是来料加工型。工作方法、工作周期、工作质量要求都很不同。所以我们就分离了。到了大客户定制研发中心，发现还有两类问题，一类是客户紧急需求，一类是大块修改方案。于是我们在大客户定制中心又按区域划分了紧急需求响应小组、大方案定制小组。紧急需求响应需要快速诊断问题快速开发快速发布，不能做长时间的方案分析设计开发测试，但这又是大客户深度定制版本，所以对人要求很高，所以派了骨干来搞，而大方案周期长，腾挪余地多，所以可以中庸手和新人来随着大项目缓慢成长，只要四大骨干角色建制在，就问题不大。

我们过去只有服务中心一个大杂烩，什么都搞。我梳理了工作大块，把主动运维发现问题解决问题做成一个专职部门，专门搞主动运维，收主动运维服务费，有业绩要求。把被动响应客服中心转过来的疑难问题交给技术支持工程师团队，他们是有日常客服服务费支撑。这就是深度服务和常规服务的区别。主动运维团队和技术支持工程师团队都有自己的研发团队和技术来研发工具来诊断问题。

有些问题是代码问题甚至是平台问题，为了衔接服务中心和研发中心，我们又重新定义了QA的工作重心，就是解决组织间的衔接问题。从流程、职责、SLA要求、预警机制、定期会议报告和会议磋商机制，都建设了个遍。为了让QA人员更加深入了解各研发中心的工作实际情况，而不是拿着流程规定当令箭，我还要求QA人员每月盯一个研发团队，跟着他们一起开会，听方案听报告听例会，让大家都是以研发专业性角度来审视问题，这给QA人员提出了很高的专业要求。所以，一方面我们号召测试人员转QA，一方面我们鼓励QA人员参与到用户体验测试环节，让他们也熟悉产品系统功能。这都是痛苦啊。

六、是人的能力有问题吗？可能单兵作战能力就弱

我们干企业应用软件苦逼毛利低工资低，做行业软件又公司知名度不高。所以招聘的人相对基础都比较弱。这就容易引起恶性负循环。

所以我卡严了人才编制、人才招聘关。但发现问题并没有得到缓解，我就看看到底大家怎么招人的。跟了几个招聘面试，发现大家问问题就问不到点子上，对找来的人的工作职责以及相对应的工作专业要求都没有明确认识和明确问答。

于是，我又带骨干梳理了各个岗位各个级别的工作职责、每个职责相对应的工作专业要求和素质要求。针对每个专业要求，又梳理了该怎么评测专业，该常问什么问题、问题的核心答案应该是什么方向。大家有套路的面试。

对于校招新人招聘，也实现了拔尖策略，从通过率来看，几乎一个班40个人只有2-5个通过。但是这样的数量规模远远满足不了快速发展要求，于是启动了3月、6月、9月这三个月份的每个季度都有招聘的机制。3月份招聘考研失败的、6月份招聘班里拔尖高潜的、9月份进行大规模校招。

校园新人拔尖招来了，还要精心的培训。所以，我又成立了专门的新人培训部，专职进行校招新人培训。

新人培训一共要3个月。第一个月学技术学业务学产品，一共四周共20天，每天上午学下午练，周五考试。我们把新人按照招聘面试笔试后的ABC成绩进行搭配，让他们分小组进行学习交流、团队间PK排名。每天下了班，他们自己做小组总结，每个人每天轮值做组长做报告。每个月根据四周的考试成绩进行末位淘汰，优胜奖励并发表学习心得供大家分享。对于不想出骨干给新人讲解的研发部门，就实行后序选人，优秀的人就会被积极出讲师的部门先抢走。这样就鼓励各个研发部门积极出骨干讲师来带新人。当然，讲师当月绩效有带新人这项工作，由新人培训部负责人进行打分。

第二个月，由新人培训部人员和各个研发对接需求，把校招新人能做的开发工作测试工作都放进新人培训部。由新人培训部的工作人员进行结果负责和结果审核。这就是一个很好的过渡期，让新人能直接做真正的商用项目，真正的接受严格的正规的开发流程考验。由新人培训部工作人员对新人的工作效率工作质量进行打分，月末进行末位淘汰。

第三个月，就是双向选择，新人真正进入部门。每5个新人指定一个师傅，条件好的部门可以2个新人一个师傅。师傅和新人的工作绩效进行绑定，新人工作绩效不好就会影响师傅的绩效。师傅要做的定期动作就是：任务分配、每日晚会问答、任务成果审核与指导。

对于现有人，为了让大家仍然持续提升，我又推行了双周学习会机制。一个月，有两个半天用于学习。这两个半天，主管不能安排任务，大家都学习。学习有很多方面，由各团队自行定义。学业务学产品学解决方案、搞CodeReview复盘会，大家一起分析重大漏洞、代码隐患，总结最佳实践和改进建议。学习后的总结，抄送给HR部门。

每周，还有公司级的技术大讲堂。内容就是来自各个研发部门的双周学习会的总结。HR部门发现各个研发部门共性的学习内容，然后找到总结比较好的团队，推动他们出讲师在公司级别再分享一次。

每年，也会进行岗位认证培训考试。有笔试有面试答辩，考薄弱产品、薄弱技术、薄弱流程和规范。

日常绩效、学习分享、岗位认证成绩，这构成了一个人年度晋升的重要参考数据。

七、最后思考

等等，等等等等等等。让我静静，我想静静。

我们到底在搞毛啊？我们花了这么多这么大的力气，我们到底在搞毛啊？

我们的具体突出问题是什么啊？是什么在影响公司业绩啊？我们这么搞真的对吗？我们是不是把事情搞复杂了？（我这还是作为CTO能力推力行的，对于不是CTO，想搞以上那些更是难以上青天）

现在，我来到了互联网公司，才发现，很多思路有新的角度。下一篇文章我再告诉你。

哈哈哈，你看了这么长的文章，原来是根本没用的，是作茧自缚的。哈哈哈哈。笑的好凄惨。

你还赞吗？你还转吗？