全程测试，从需求到设计到代码 软件测试
去年，我们要让软件开发团队管理上台阶。
我们由于处于企业管理软件开发领域，而对日外包大部分接的单子都是管理软件之类的单子，但是人家的项目管理、进度、质量都比我们好，如果他们再配合管理咨询公司作为合作伙伴，再加上大规模的服务呼叫中心，像我们之类岂有出路?
于是我们就想到了引入对日外包的开发过程管理。
大家一想起对日外包，就想到了大量的文档和大量的代码工人，想到了详细设计说明书甚至到函数级、伪代码级。
要不要引入的时候，我们内部也做了争论。觉得对日外包，人家接的单子额比国内客户大，所以也能招聘大规模的员工，而且对日外包，日本人是很理性的看待项目周期的(国内客户要求一个月开发完上线)，而且日本人都做了半年到一年的调研和设计分析(国内调研几乎只是一个上午，坐在一起瞎聊，根本不成方法)。所以对日外包不适合咱们。咱们没有钱招聘一定数量的人(即使我们只需要普通员工，而不是人才，我们也没多余的钱)，当然我们也无法分离那么多专职的项目管理、开发、测试、文档、配置管理岗位。我们的客户对于软件的认知决定了我们无法在调研、设计上下太多功夫(单子额就那么大，客户认为软件就值那么多钱，当然无须对软件生产各个环节进行重视)。
不过，我还是坚持进行引入。是骡子是马，咱们拉出来遛遛。还没遛，就说不行。这不是小时候的小马过河了么?
引了进来，合作伙伴给我们派了一位质量控制部的人员。
一入手，发现有个很关键的问题，方法的源头。
因为对日外包，都是接单生产，主要是编码、测试，保证生产进度和质量要求。但编码之前的所有环节，对日外包公司并不清楚。他们只知道拿人家给的设计书开始coding，设计书怎么来的，前面环节产生过哪些文档，不清楚。
幸亏我们过去有系统的调研方法，从调研描述现状、然后分析优化的组织结构、工作流程、考核报表、岗位职责四大块来描述需求。客户优化后的流程、工具中包含手工纸张信息、EXCEL信息、软件信息。
把这些转变为软件中的功能、权限、报表也一气呵成。组织结构和岗位职责决定了功能点和功能权限、工作流程决定了软件流程、工作流程中使用的纸张信息、EXCEL信息、软件信息就是数据输入，报表就是数据输出。这就是一个企业管理软件的四大块：组织权限、输入、处理流程、输出。
所以说，企业管理软件的开发是有方法和规律的，比较容易，就连最难的调研和需求管理也有方法。所以企业管理软件的开发，现在主要集中在大规模开发团队的组织、任务调度、人员培训(大规模的开发，必然需要的是一般素质的人员，而非高级人才，否则不可能有那么多资金来实现大规模开发)、大规模开发团队的质量和进度(人多了，各个层次各个水平的人都有，理解都不同，如何保证质量和进度是很关键的，否则很容易项目预算失控。一般素质的人多了，对于管理的要求是很高的，很容易成为乌合之众，只消耗不产出)。我特羡慕KFC，不管我们在大江南北哪里，迟到的KFC是一样的口味和品质，享受的服务和环境也差不多，这很难。那么多店，而且都是授权店而非自主经营店，那么多一般员工，而且员工流失和临时员工也非常多，居然能保证一样，管理水平实在了得。所以我经常学习KFC和丰田，如何使一般员工大规模配合工作。
对于企业管理软件开发过程中的文档，我们一般有需求分析说明书，其编写格式和思路，和我们的需求调研方法一致，也就是说，我们的需求调研的结果，落实到纸面，就有需求分析说明书，另外还有一份需求调研报告，是偏向于项目过程叙述的。
需求分析说明书回来，研发部内部会进行大家一起学习理解，然后讨论。
文章来源于领测软件测试网 https://www.ltesting.net/
