开发流程中的问题总结和建议

一、现场需求调研人员对研发的开场白：

1.这个需求很紧急，麻烦抓紧安排。

2.局方领导检查，这个功能需要演示。

3.这个功能很简单，一天就做完了。

4.功能是项目验收用的。

5.这个功能需要再增加（修改）某某逻辑

二、功能开发完毕几个月后现场反馈的问题：

1.某功能（n个月前开发的）客户要用，升级怎么失败了？

2.某功能怎么查不出数据？

3.某功能客户要增加字段，请尽快调整。

4.某功能点击报错，麻烦定位下问题。

三、针对以上问题的分析

很多时候现场和客户对需求都不明确，根本不知道自己想要的是什么。都抱着先做出来看看样子，不行再改的态度去做需求。

如果现场在做需求分析的时候能多和用户沟通需求的实用性。例如使用场景、应用效果以及对功能最本质的需求。这样一来应该可以了解用户的本质想法以及期望效果，这种沟通后得到的需求单才算是一个负责的产物。需求本身就需要反复确认的环节，而不仅仅是将客户的语言简单转化后填写到需求单中。很多时候我们自己在心里都一种思想，将局方当做不可忤逆的角色。其实无论是局方还是需求调研都应该是平等的，我们是帮助局方更好的管理他们的资源提供便利，而不是被局方指挥的码农。局方的接口人也都不是随随便便找出来的，建设性的意见和建议也应该会合理的接受，出现不合理需求的时候我个人认为就是需求调研时我们的调研人员根本就没有真真正正的思考功能合理性，同样也提不出任何让接口人认可的建设性意见。

客户不催现场不问，需求做完了就放着等哪天客户想起来的时候才急着要升级。

这种功能做完不升级的情况举不胜举。等到某天局方的人想到这个功能了，现场才急急忙忙自己升级或者联系家里研发协助升级。很多时候功能已经拖了几个月，当时的升级文档现场找不到了，家里研发因为时间过久忘记了甚至有相关研发离职导致升级困难耽误时间。这种问题不单单是现场的责任，应该是流程管控的缺失导致的。

功能升级后几乎没用过，等检查的时候点了才发现存在问题。

现场功能升级后一直没有使用，等到集团或者领导检查时候才突击点下每个功能，发现了一些功能根本就无法使用或者报错。功能点不完善这个完全是研发的责任，如果有一个完善的测试流程这个问题是可以避免的。但很多项目组的开发模式都是研发开发功能、自测、提交文档升级包给现场。自测个人认为是一个没有任何约束性的测试，就和自己考试自己打分一个道理。

基础数据源问题导致查询无结果（统计程序没运行、相关原始数据表不存在）

很多情况功能查询无数据，都是后台的统计程序没有启动或者相关动态表没有创建导致的。现场维护人员如果看下日志应该是可以分析出原因而不需要联系研发定位问题。但目前来说愿意看日志的现场维护人员不多，其根本原因是部门没有统一日志格式的规范，每个人的功能里日志满天飞。这种日志除非自己写的，其他研发看起来都很费力更不用说现场维护的人员了。

功能健壮性几乎为零

人天生都是具有破坏意识的，就针对功能来说，如果可以把这个功能搞挂很多人的心理都有一种成就感。功能的健壮性和完整的测试体系有关。功能给客户使用的过程中不可避免会出现客户恶意的输入一些非法参数导致功能报错。如果有着页面标签参数校验组件的存在，应该也可以阻止绝大部分的问题。

一句话功能（客户需要xx日报表）导致垃圾代码堆积

这种功能姑且不论是否应该存在，就代码而言此类功能的重复度是最高的。此类功能应该是以动态参数配置共用一套代码来处理，而不应该每次拿到需求后就重新建包写重复的代码。

四、个人建议

1.需求管控

现场维护的每位员工都希望自己的需求都被排到优先级最高，导致了插队的现象产生，插队的理由也多种多样。

针对这种情况我希望大家能协商版本发布周期，以自然月内的所有需求为一个版本。等到下个月升级的时候将上个月版本内的功能一起上线，而不是针对单个功能点来进行开发上线。

2.升级工具

很多项目组的升级步骤是kill进程、替换class文件，jsp文件执行启动脚本。这种方式是最原始、最直白的升级方式同样也是最靠不住的方式，因为手工执行命令替换、修改每个文件的时候不能保证不会遗漏缺失。当重启现网系统发现各种报错后浪费的都是大家的时间。每次升级至少去1-2个研发支撑，原因就是在升级过程中有着各种各样的问题需要去解决，而这些问题恰恰都不是代码层面的功能性问题。

以以前在华为升级的经验，应该是研发提供升级包给测试、测试按照升级文档升级后测试功能。然后将测试过的升级包交给现场。整个升级过程有自动化工具执行，操作步骤就是简单的导入、提交。研发保障功能的实用性、测试保障功能的可靠性、升级工具来确保升级步骤的完整性。

3.日志规范

统一规范的日志方便阅读纠错，后续也可以写一些分析工具用来解析日志文件按照不同的功能过滤日志方便研发和现场定位问题。

4.简单报表抽象

简单的报表查询功能大概占总需求的15%，以我个人为例从开发到上线至少需要3人/天时间。大部分的报表类功能是可以做到抽象的，将模块骨架抽出以动态参数的形式组装实现配置即可用。

五、后记

以上的文字是我在行业工作以来的感受和建议、有理想化的意见也有实际摆在面前的问题。如果可以解决所有甚至只是一部分目前存在的不合理问题，我想这对整个流程都会是一个很大的进步。