随着互联网的普及，在国家“十四五”规划中提出“加快数字化发展建设数字中国”的战略远景，数字化成为企业发展的必经之路，数字化建设的落地一定是由技术团队来实现的。
现阶段的软件开发已经跟十几年前不一样了，记得大学刚毕业那几年，一个人可以干完整个系统，现在软件开发过程中的职责细分、前后端开发分离等等，都明确表示软件开发是一个多角色、多岗位的流程性活动，要确保软件开发顺利进行，并且按时按质按量交付，那么完整的管理理念是必不可少。
这一篇跟大家探讨的是关键节点管理，稍微了解一些软件开发的朋友，应该都知道一个软件（无论是业务系统、交易平台、还是面对个人用户的APP），从想法到最终上线交付客户使用，都存在以下图示中的四个关键环节，即需求调研阶段、设计开发阶段、测试阶段和交付阶段，可能有些团队的各个环节会有交叉，或者多个环节是由一个人来完成等等，无论怎样的表现形式，内在的这四个环节是必不可少的。
每个环节都会有人承担相应的角色，简单描述如下：
- 需求调研阶段对应的就是产品经理、需求分析师（互联网特别是移动互联网时代后，基本上就是以产品经理为代表了，需求分析师的工作基本由产品经理代替了）；
- 设计开发阶段，则是由UI设计师、交互设计师、架构师、前后端开发以及其他各类开发相关的角色来负责；
- 测试阶段主要由测试工程师（功能测试、性能测试、安全测试等等）来负责，很多时候需要将测试前移，也就是开发工程师也承担一部分测试工作，但由于开发工程师和测试工程师的思维模式就完全不同（回头再另外写一篇关于两者思维模式区别的文章），一个软件的完整测试工作，一定少不了专业测试工程师的参与；
- 交付阶段则会由项目经理、运维工程师等联合完成，确保研发出来的软件系统符合客户的要求，拿到阶段性的交付成果。
在各个环节中，都会有一些关键活动。我们认为一个流程性的工作，只有中间的关键节点都执行到位，才有可能最终拿到符合预期的结果，如果关键节点管控不到位，或者根本就没该关键节点，结果可想而知会是什么情况。
接下来我们一起逐个环节具体分析一下：
1、需求阶段
在需求调研阶段，最关键的动作是需求评审，因为需求评审是产品经理经过调研和产品设计之后的内容，是否能符合业务方的需求，以及后面需要开发团队去设计和写代码实现的内容，都包含在这个产品设计的需求描述中。在我们给客户做咨询的时候，很多客户会说我们团队也有做需求评审的，我会问客户一个问题，你们做的需求评审，有什么标准吗？做到了什么程度，是否符开发流程管控的要求？这时候对方一般会说这个没有，只是说有这个环节，那我们知道，一个关键动作做了和做到位了是有本质区别的。
我们对需求评审这个关键阶段是有要求的，标准其实很简单，就一句话：所有参与人达到认知一致。虽然这句话很简单，但里面包含两个关键词，即所有参与人和认知一致，必须非常清晰地认识到这两个关键词的含义。
首先，什么是所有参与人？我们认为跟该软件的迭代相关的人，都需要参与需求评审，即UI设计师、开发工程师、测试工程师以及该软件的需求方。产品经理负责组织需求评审，可以是所有人一起参与，也可以是分多次进行（例如需求方可能不方便随时参与），这是产品经理的职责，必须将产品设计的需求跟这些人沟通。
第二个关键词是认知一致，那么什么是认知一致呢？就是要让大家对产品设计的内容理解一致，并且真正理解产品设计的背景、解决方案，以及为什么这么设计。我们都知道，任何一个需求或者问题，都会有很多种方法来解决，对于客户的这个需求，产品经理是如何思考的，为什么选择这个解决方案，都应该让参与者理解，并且大家的理解要一样的。在查理芒格的人类误判心理学中，有一个重视理由倾向，说的是人类要做某件事情如果知道为什么而做，会做得更好。所以如果产品经理能将产品的设计背景、理由和目标都讲清楚，那么研发团队能做得更好。我们对产品经理的能力要求中会有这样一条，即输出的文档要无歧义的，不能输出一份文档，不同的人看了理解不一样，这是对产品经理基本素质的要求。所以产品文档一开篇，通常都是名词定义和解释，也就是在产品的设计中，什么东西叫什么很重要，我们日常生活中就有很常见的例子，如南方人叫红薯，北方人叫地瓜，说的都是同一个东西。这也是为团队内部交流做好准备，大家必须要有统一的语言，如果开发人员和测试人员对需求的理解不一致，在后面的协作中就会出现很多不必要的返工。所以对于认知一致，我们一个简单的说法来解释，就是面对界面上的一个按钮，所有人都知道它长什么样，放在什么位置，什么情况下点击会出现什么反应，大家的理解都是一样的。
2、设计开发阶段
设计评审，包括UI设计评审、交互设计评审、系统设计评审、接口设计评审等等，当然在一个拆细了的迭代版本中，未必每个评审都需要做，但对于一个完整产品的开发过程中，这些环节都是少不了的，因为跟前面说的一致，关键节点缺失对结果的影响肯定是很重大的。
这里我就拿接口设计评审来细分讲解一下。现如今的软件开发基本都是前后端分离的，因为软件产品的表现形式已经不仅仅是电脑使用这么简单了，移动互联网的成熟，同一款软件也会至少有PC端和移动端之分，而移动端又有更多的细分，如Android、iOS、公众号、小程序等等，这样开发团队就必须同时支持这些客户端的表现形式，那么前后端分离是迫不得已的选择。加上技术的发展和成熟，细分领域越来越专业，前端的各种技术框架出现，让某一个领域写代码更轻松，但各个端的技术体系都不一样，从而造就了开发的不同岗位和不同能力需求。为了实现一个业务逻辑，前后端的开发人员需要根据接口来实现业务交互，基本上都会在开始写代码之前做一些接口设计，定义有多少个API接口，每个接口实现的业务逻辑是什么，参数是什么，是否可以为空，取值范围是多少等等约定，那这些接口设计是否合理？是否覆盖全面？是否考虑到了很多异常场景？这些问题都需要接口设计者来思考，并通过设计评审用大家的智慧和经验来弥补缺失的部分，所以接口设计评审就会显得异常重要。
我举个例子来说明这块做得不好的场景，我们的一个客户研发团队，前后端开发工程师总共10个人不到，他们团队采用的是迭代开发方式，每个迭代的周期大概7-10天（即两周左右），细问之下了解到，前后端的开发时间（即写代码的时间），一般是3天左右，然后用2-3天的时间进行联调，再经过2-3天的整体测试和Bug修复阶段，达到可发布的状态。我听完之后就会发现问题所在，在我们的研发过程管理中，理论上前后端的开发都是参照接口设计来做的，只要接口设计稳定没变化，大家写的代码都符合接口设计，那么3天开发时间写的代码，前后端联调应该在半天之内就完成的，而不应该用3天时间。这种情况的发生，一定是前期接口规范设计不完善，导致在真正联调的时候再进行接口的完善，从而导致需要花这么多时间。我记得以前跟二维火的CTO交流，他们也曾出现过类似的现象，后来采用了一些规则方法后，就将联调的是时间节省了超过80%。
要解决这个问题其实并不难，通过前期的接口设计和相应的评审机制，确保接口在设计阶段就达到完善的状态，利用一些API工具（如Swagger、YAPI等）在开发过程中进行mock测试，可以确保前后端联调的时间尽量地缩短。
3、测试阶段
冒烟测试这个词来自硬件行业，举例说一块电路板经过设计和制作之后，需要在往后一个工序之前进行加电测试，通上电路板的标称最高电压，如果电路板冒烟了（就是烧掉了）则表明该电路板不符合质量要求，后面的工序是不需要去进行的。假如没做这个测试而进入到了后续的产品组装里面，如进入了一个电脑、电视、冰箱里，那客户拿到这个产品通电就烧掉了。在软件行业里面借鉴了这个概念，冒烟测试指的是软件的主功能流程测试，要确保主功能流程是正常的，后续的测试工作才有意义。
我们在过去接触的很多研发团队，都没有冒烟测试这个环节，甚至对什么是冒烟测试都不理解，那最终的结果自然是不尽如人意的。我们的管理理念中，也对冒烟测试有明确的要求，合格的标准就是冒烟测试一次性通过，导致冒烟测试不过的责任人需要承担相应的后果。
为什么我们会认为冒烟测试很重要呢？由于开发工程师和测试工程师的思维模式不同，开发工程师是直线思维，将需求的业务逻辑从头做到尾，实现就可以；而测试工程师则需要整体系统性思维，需要验证软件在各个分支和异常场景下的反应是否都符合预期。举个例子，做一个最简单的四则运算的程序，开发工程师则会将基本的加、减、乘、除功能写好，一般这样就会提交给测试工程师来验证，如果连基本的加减乘除都不能用，例如把1+1计算成3，或者5x5就系统出错，那这样的质量下测试工程师是不需要往下测试的，这些基本的主要功能是开发工程师要确保的，在这个例子中，测试工程师测什么呢？需要验证的是分支和异常场景，例如输入的数字是否合法？用户输入非法字符程序是否能正常反应？用户输入的数字过大，程序能否正常反应？除法输入0能不能有正常反应？不能用户一旦输入不符合要求的内容，程序就报错或者崩溃，因为软件在用户手里，会怎么使用我们是无法预知的，但我们软件需要做到在这些不符合要求的场景下使用，也是有正常反应的，例如告知用户输入范围等等。
所以冒烟测试通过是对测试工程师工作的保障，否则为了解决主流程的问题，花费测试工程师的大量时间，造成测试工程师的无用功，在反复的冒烟测试过程中，也让开发工程师在反复返工，是造成研发团队效率低下的很重要环节。
以上我详细分析了软件开发流程中的3个典型关键节点，我们认为流程性的工作，只有做到按照规范一次性把事情做完，团队工作效率才是最高的，只要出现了返工，就会导致局部或者整体的效率低下，作为管理者，重要的是制定合理的流程和规范，让团队中每一个人都能严格遵守规范，这样团队的协作效率才高。对于过程中的关键节点，管控到位、执行到位了，那么结果自然不会有太大的偏差，而关键节点出现问题，甚至某些关键节点都没有做，那能否拿到理想的结果，可想而知了。
