为什么你的IT项目还在延期？

“对于一个IT项目而言，需求阶段和测试阶段是决定一个项目成败的关键，也是需要投入最大资源的地方。”

你的项目是否经常面临延期的风险？是否在熬夜赶进度？产品和技术是否经常发生争吵？想采用敏捷的方式进行开发，是否拥抱了变化，也拥抱了风险？阅读完本文，希望能够对你有所启发。
我们都很重视技术人员的能力，认为技术能力强，研发效率就高，但是实际是这样吗？很多开发人员只要能简单跑通代码就扔给测试了，结果因为很多原因反反复复地修改，耽误了时间。
我们轻视了分析设计和测试的投入比重，忙着早点进入写代码的阶段，这才是导致项目混乱的关键。

01 合理地接受需求

作为项目的负责人，首先要明确业务需求产生的价值是什么，因为很可能需求方未必想清楚了这个问题。例如运营部门提出要做一个引流活动，那么就需要明确这次活动投入的预算是多少，计划在哪些渠道投流，预计获客数量是多少，获客成本是多少。可能这里一些信息不见得和研发有直接的关系，但是可以倒逼需求方去认真思考，而不是随意提出方案，减少需求的变更概率。哪怕是在0到1的验证阶段，即使没有明确的量化指标，也需要搞清楚具体目的。比如验证用户群体对某个功能的具体反应程度。
作为产研部门要深入的了解业务并能够做出预判，如果一味地被动接受需求，那么可能所谓的“变化”就会一直困扰着你。
02 正确地输出需求

构建统一语言（UBIQUITOUS LANGUAGE）是效率的基石。产品经理：懂了没有？开发和测试：懂了！结果在验收阶段，产品发现不少功能团队理解有误。软件交付是一个多专业工种协同作业的行业，每个岗位人员知识背景的不同，对于同一概念，会自然地从自己的专业背景和掌握的知识背景去理解，往往产生了认知上的分歧，给项目带来了风险。为了让团队人员在认识业务需求层面迅速达到共识，减少分歧带来的问题，必须要构建统一语言，越复杂的业务统一语言的作用就越大。找到各个专业岗位和业务领域之间的交集点，是构建统一语言的关键，然后各个岗位再由统一语言映射到各自的工作中去。

为了更好地说明通用语言在实际工作中的作用，以用户认证为例，我们做一个简单的示范。
用户故事
描述：新用户打开移动应用后，进行认证时，查看到所有认证方式的列表。
验收条件：
      1. 认证方式有：手机验证码、微信。
      2. 手机验证码认证放在首位

描述：新用户选择手机验证码的认证方式，完成身份认证。
验收条件：
      1. 验证码为6位随机数字
      2. 重新发送验证码的间隔时间为30秒

接口

用户查看当前应用的认证方式列表
用户发送验手机证码

领域模型

测试用例描述
背景：一个新用户首次打开移动应用
事件：当他点击登录按钮时
结果：
1. 查看到认证方式列表，依次为手机验证码、微信
2. 手机验证码认证的界面被展示出来，字段有.......

以上基于Gherkin规则

运维系统描述

试想一下，如果整个团队都能够用类似的方式去明白每一个概念，不仅更加容易达成一致，还可以快速的响应的变化。
03 测试与产品迭代并行

如果测试仅仅是承接研发开发好的功能的质检，那么就不能够发挥其应有的作用。测试的本质是尽快地全面地发现问题，从而减少这些问题对研发造成的负面影响。
首先，测试应当尽可能地参与到早期业务分析和产品设计，尽可能深入地理解需求。同时也可以通过需求用例的帮助BA或者产品经理验证其需求的合理性，以及产品细节的打磨。找问题找缺陷要从设计阶段就开始进行。
其次，很多团队往往是等所有功能开发完毕了再做开发，测试人员在一段时间内工作量较少，而等到所有功能都开发完毕后再测试，工作量又相对集中，更重要的是，一些问题如果早期能够识别出来，就可能减少连锁问题的发生，从而减少研发的重复性工作。既然用户故事是独立的存在，那么测试工作就可以随着单个用户故事的开发完成而独立进行。

在设计阶段，测试也不能只是作为被动的信息接收者，也可以根据自己的知识背景提出自己的意见。
如果需求没有对性能做出明确说明，这个时候测试完全可以提出个人意见，让产品经理补充非功能性需求。例如：保持用户良好的体验，所有页面的数据响应不能高于3秒
而测试也就可以根据这条需求，进行性能测试的设计，不仅保证了完全覆盖，也反向的推动了需求的完善。
如果在代码编写完成之前测试用例就能书写完毕，开发人员完全可以对照测试用例进行自测。这样既可以替代繁琐的单元测试，也可以保证进入测试时的代码质量。
04 测试与需求映射

你的团队测试能覆盖所有需求功能点吗？很多时候，我们发现测试工作也做了，但是总是会遗漏一些需求上的功能点。为了达到产品和测试之间的高效协同，测试用例和用户故事（或者需求）之间就要制定基本的对应规则。我们以用户故事为例，每一个验收条件就应该对应一个测试用例。

05 结束语

随着互联网下半场的开始，很多项目会遇到业务逻辑更加复杂，技术要求更加多样的困难，还需要深入的了解业务，合理的进行架构设计（比如利用领域驱动设计进行分析、软硬架构的协同等）。不过无论怎样，只要能够保持良好的沟通以及合理的资源调度，那么就可以让软件研发保持顺畅的节奏。