大家好，我是培训时长N年半的培训生，菜..菜包。
喜欢 ..xx..xx..xx..篮球。
长时间培训，感觉需要写点东西，欢迎指正、交流。

背景

包子进入新公司三四个月了，到目前为止，被划入业务开发组还不到两种，也就是说接触业务还不到两周。
最近三天包子参与的新需刚进入测试，但是让包子感到可怕的是，刚进入测试三四天，开发人员、测试大佬和产品经理就连续熬夜甚至通宵三四天！可怜包子也跟着陪熬了三天，这以前真的是想都不敢想的，这还只是刚进入简单的UI测试阶段！！
今天包子一觉醒来，感觉真的得说点什么才好。这样的效率，对开发人员、对产品经理，甚至对产品本身，都是一种严重的伤害。

从开发到测试，出了什么问题？

那到底是出了什么问题，导致开发、测试、产品这三方人员需要在刚进入测试阶段就连续熬夜甚至通宵？？到底是什么原因造成了IT行业那么多单身狗呢？？

1. 产品说把已上线的一个功能页面位置移动一下，里面内容全都不改，开发组长说代码不用动（是不是很开心？什么都不用做？）。完了到测试阶段测试说数据不对，逻辑是错的！Are you kidding me？？一个已上线N久的页面，你现在跟哥说不对？？ 问了两波开发过这个页面的开发人员，都说自己是对的？一问开发组长，开发组长开始撸代码逻辑，一顿操作后，说都不对，代码需要重新写！！what？？想象下包子脸上的表情....
2. 接着上面的问题，包子只好重新开发接口。包子平时找产品、找业务开发组长讲业务，大家都说太忙，没时间。那好吧，现在只能在测试阶段重新写代码，业务找你们问清楚问仔细了，除了问业务，还要问涉及到的后端表、字段的设计和用法等等...最后写完这个接口，前前后后居然花了包子快3个小时的时间。。要是以前，这写接口的时间，包子得鄙视死自己。
3. 好吧，接下来还是和包子相关。测试又给包子提了Bug了。说列表上数据不对，上一步流程执行后，数据流转到包子负责的列表这里时，某些字段数据没改变，所以bug直接就提给包子了。包子一脸懵逼，好吧，只能去找上一步流程的开发人员。包子找到人后，被人家反问了一句，那些状态需要改变吗？？额...额。。。额！！！
4. 终于不是包子了。包子坐着看书的时候，突然旁边争论起来了，是这次业务开发的组长和组员，仔细一听，组员哥们列表的数据好像又有问题，业务开发组长说你查错了，要查表A关联表B，组员说不是的，要查表C关联表D，然后就开始争论起来了......停停停，包子喊了一下，这表当时是谁设计的？好吧，是另外的同事设计的。。有没有讲解？？没有，都是靠自己理解。。。好吧，那只能看谁理解对了。。。
5. ...
6. ...
7. ...

归根结底，问题到底出在哪？

像上面列举的几个问题，都只是冰山一角。。
问题总是以你想不到的各种姿势出现，而你总是不知道用什么姿势来配合。

正所谓一个巴掌拍不响，其实也适合描述我们。
以上所有的问题，都不是单单某一方面就能造成的，从业务方、产品经理、开发人员、测试人员都或多或少存在着需要改进的问题，这些问题或许很小，但一旦爆发出来，往往就会出现了很多脏数据，导致业务混乱，从而造成业务方无法正常业务运转，产品人员、开发人员、测试人员没日没夜地加班加点改Bug。

我们可以对以上几点进行简单的分析，很明显可以得到一下四点 ：

1. 开发组长和组员没有详细了解业务流程，产品经理与开发方没有在业务流程上达成统一共识。
2. 开发组长与组员在系统设计及代码层面没有统一共识，导致不同开发人员对应同一设计有不同理解。
3. 开发人员对于不是自己设计的系统部分，开发时没有主动寻求多方了解和确认，一股脑地先干了再说。
4. 开发组长上线前没有review code，功能出问题导致业务数据错误。实际上已经在线上出问题了。

包子的观点？

包子想先表达一下自己的两点持有的观点，不谈解决方案，因为包子暂时还没资格，各位看官若有不同观点，欢迎交流。

• “任何技术，最后都要回归业务”。

• “复杂计划，简单执行”。

  针对第一点，包子不是说把技术认为一文不值，而是认为，技术的实现，需要从具体的业务场景出发考虑，才能设计出最大程度适合业务的代码。无论前端开发、后端开发、测试人员甚至UI设计师，都需要认真深入业务场景，走出自己的职业范畴，以业务方的角度看待问题，然后再回归自己的角色，才能设计出最符合业务的代码。如若不然，开发人员基本只会局限于编码的角度考虑问题，无非就是代码性能、简洁性等问题，设计师基本只会局限于页面视觉效果，测试人员只会关注单个功能是否能走通等等。这样的情况下，根本没有考虑业务方实际场景，如操作便利性等等。这样看起来貌似各方都完美完成各自的任务，但如果面对未来快速变化的业务，却显得不堪一击！！

  对于第二点，可能很多看官不理解，其实指的就是有计划得执行各项任务。相信在某些开发团队中，都存在这样一个场景：产品人员PRD人手一份发下来（有时候甚至没有PRD），然后就只跟开发负责人进行简单评审，完了开发负责人直接一套数据库设计直接做完，剩下的就让开发人员自己看PRD和数据库设计开干，说开发过程有问题直接问。其实这是一种很经典的“简单计划，复杂执行”的场景。试想一下，如果开发负责人跟产品人员简单评审后，开发负责人理解了90%以上的业务需求，然后自己设计了数据库满足了自己理解的业务的90%，那么如果全部由开发负责人完成的话，算是满足了90%*90%=81%的业务需求，然而开发人员呢？？只会是更低！那么产生的后果就是，顺利的话，开发人员在开发过程中，不停地跟开发负责人确认各种业务和编码层面的设计，开发阶段花费大量时间，最后测试阶段也许产生少许bug；不顺利的话，开发人员根据自己的理解，先干了再说，完了在测试阶段，发现业务的设计和自己理解的根本不一样，只能花费大量的时间修改代码，甚至等待上线后，才发现各种不对，对业务产生巨大损失。

  对此，包子想说，若能在实际开发之前，能多安排时间做出有效沟通，各方之间统一枪口，统一思路，如业务方和产品人员、产品人员和开发人员、开发人员内部等等，其实剩下的就是落地执行的事了。曾经有同事跟包子说“我们这边的需求都是很紧急的，根本没有时间做这样太多的统一沟通”；包子只想说，其实没有时间做统一沟通，到最后，加班熬夜改bug的时间往往比前期统一沟通花的时间要多得多。所以“复杂计划，简单执行”比“简单假话，复杂执行”更适合团队的工作。当然，“复杂计划，简单执行”的有点远远不止这些，如在开发过程中，有开发人员请假，那么这时候团队内的开发人员随时可以无缝对接上，因为大家思想统一，枪口统一。