在需求分析中就可以避免的那些错误3

1、尽力区分和剔除那些【鸡肋需求】

     【鸡肋需求】：就是那些看上去很屌但用户并不会去使用和关注的功能需求。

      经手的项目中，曾经有个【鸡肋需求】让项目的开发成本增加了30%，投标公司减少60%（因为技术有点难），工期拖后了N天，但用户觉得”然并卵“。那就是”在WEB页面上动态显示一场地内作业机械设备的位置。“

        当时这个功能看上去很美，但上线后并没有被使用过几次，仅仅是向BOSS们秀了一下。

        我很一直后悔当时虽然预感到些功能需求”然并卵“，但没有尽力找个理由把该功能需求在文档中删除掉。

 

2、在需求调研阶段就确定每个功能的代表用户，验证人员。在需求文档完成后，请代表用户进行评审方案。请验证人员评审测试方案。以保证功能不偏离一线用户需求。

       公司行政想开发一套排班考勤系统来规范本公司和外包公司人员的上班考勤行为，避免代打卡和虚报出勤人数。但在需求调研阶段并没有去访谈一线用户和外包公司，只是听了行政人员的一面之辞。

      系统测试阶段才把这些人拉来测试，结果可想而之。一线用户提出很多修改建议，导致开发量成倍增加。外包公司以各种理由拒绝测试和使用该系统。

      后来做到一半功能，开发商就跑路了，因为需求偏离度太大了。

 

3、在需求阶段就定义好软件项目的生命周期和运营成本，以防止未来缺经费导致运维困难。

      曾经公司为了加强节能管理上马了一套《机械设置油电管理系统》，用于实时监控大型设置是在用柴油动力还是在用电力，督促司机尽量用电力作业以节约成本。本来项目计划运营一年，司机养成节能习惯了就可以不用了。所以系统设计和维保均没为做长期使用打算，只和开发方签订了上线后保一年的合同。

    但后来公司为了统计需要，一直在使用该系统，超过了三年。因为软件和硬件缺乏维护，数据采集出现了问题，导致数据准确率越来越低，目前只用成电表的数据能采集到。最终出来的报表根本不具有使用价值。

 

    重点是：软件项目的生命周期要首先和用户确认好，到了时间就准时下线。如果还需要使用就必须重新启动项目和申请资源。因为软件运营需要大量人力和财力，没有预算就很难执行下去。