06-需求评审流程完善细则v1 1_20181010

1、需求评审流程完善细则一、直接发任务要求各部门杜绝直接发任务操作，从而规避评审环节；部门所有的任务必须来源以下几个方面之能性需求、非功能性需求、知识库问题，并且要求对非功能性需求进行定义，目前主要是 8 类：出差在途；沟通协调工作；会议或需求调研相关工作；系统部署及保障；项目管理中的 bug 修改；UI，UE 类需求；增补原需求工时；共性问题整改最初检查频率为每周一次，由项目监督部检查做提醒，部门经理约束，目前按一月一次执行，查到有直接发任务情况，由部门经理内部处罚。目前基本已经稳定很少了。基于手机盾的移动扫码电子签章解决方案二、需求评审提速目前定义需求评审合理周期（从提交到审核通过）：8 小时

2、以内需求评审周期不超过 24 小时；24 小时内需求周期不超过 48 小时；24 小时以上需求周期不超过 72 小时；一）、计算总的处理周期的时候排除非工作日以及非工作时间，工作时间定义为每天早上 8：00 到下午 18：00。二）、评审周期为开发负责人第一次收到需求评审为开始时间，到开发负责人发任务结束为结束时间，两者的时间差为需求评审周期。三）、步骤处理时长为需求评审中当个步骤的收到时间为开始时间，处理时间为结束时间，两者的时间差为步骤处理时长。四）、检查标准目前从三个角度进行：1）、整个评审流程所有处理步骤中处理时长最长的步骤处理人2）、整个评审流程中单个步骤处理时长超过 10 小时的步

3、骤处理人3）、整个评审流程中单个步骤处理时间占总时间之比超过 20%目前检查频率一周一次，由各部门经理对检查超期事项反馈，明确做出合理不合理的反馈，合理的说明原因，不合理的部门内部处理，合理超期比例较高的由部门内部宣贯提升速度。目前平均评审周期已由年初的 37.53 小时提速到 19.79 小时提速了 47.27%。下阶段优化工作：一）、增加需求紧急程度标签，分为紧急，一般，可暂缓。对于紧急或者可暂缓的需求需要由组长审核。2基于手机盾的移动扫码电子签章解决方案二）、增加需求难易程度标签，分为需要框架协助，需要标准版协助，很难，一般，简单。三）、细化各步骤超期标准，除设计人员需求评审和专业模块设

4、计专员评审步骤制定 4 小时超期标准。设计人员需求评审和专业模块设计专员评审步骤根据 B1 标准工时、紧急程度和难易程度制定标准。1）、B1 标准工时 8 小时以内，紧急需求 4 小时2）、B1 标准工时 8 小时以内，紧急度一般的需求 6 小时3）、B1 标准工时 8 小时以内，可暂缓的需求 8 小时4）、B1 标准工时 24 小时以内，紧急需求 8 小时5）、B1 标准工时 24 小时以内，紧急度一般的需求 10 小时6）、B1 标准工时 24 小时以内，可暂缓的需求 16 小时7）、B1 标准工时 24 小时以上，紧急需求 16 小时8）、B1 标准工时 24 小时以上，紧急度一般的需求

5、 20 小时9）、B1 标准工时 24 小时以上，可暂缓的需求 24 小时以上时间标准均为排除非工作时间之后的时间四）、对于超期标准增加消息提醒功能，提醒剩余多少时间超期。三、需求评审评价目前每月会有一份需求评审质量评价邮件，邮件里会对较好的设计人员以及不合格的设计人员，进行奖惩，由部门经理根据邮件意见，月浮动执行。本项工作略带主观性，由评审专员执行，目前要求扩大设计人员奖惩人员数量，争取按照 28 原则执行（每期奖励 20%的设计负责人，处罚 20%的设计负责人）3基于手机盾的移动扫码电子签章解决方案另：设计负责人资格每半年征集一次，由设计专员发邮件提醒，各部门经理推荐（目前无考核环节）下阶

6、段工作：一）、每月会收集一些评审较好的分享出来，对于评审不好的作为教材分析原因。二）、针对需求评审评价 1-5 星制定相应标准。三）、对于连续两月评审较差的人员由部门经理评估是否暂时取消其评审资格四、外网公开需求检查目前按照每周一发的方式执行，现由需求评审组整理一周外网公开类的需求由陆仁杰每周一发送给各开发负责人，由开发负责人反馈代码评审及复核。常见的检查问题如下：1）、公告公示模板有错别字、措辞不当、多余标点符号、排版等问题2）、公告公示签章偏移问题4基于手机盾的移动扫码电子签章解决方案3）、公告公示推送失败或者提示推送成功但未在外网展示4）、不需要推送的内容外网显示了5）、公告公示栏目推送

7、出错6）、个性化推送只有标题没有公告正文内容7）、交易统计数据调用接口或者直接访问数据库过于频繁导致系统奔溃8）、我司网站推送成果、第三方网站推送不成功或者显示内容格式较差下阶段工作：由检查人员标记“外网公开”标签由系统发送代办给开发负责人，需求已经提给许超未上线开发中。五、新员工代码抽查及满分代码抽查目前按照每月一份报告的方式执行，现由陆仁杰统计汇总，供各部门经理知晓。新人评审结果由部门经理录入到员工试用期目标中去。下阶段工作：项目管理新增新员工代码评审模块，录入待评审新人，发送待办5基于手机盾的移动扫码电子签章解决方案给导师整理代码反馈耗时索要预算，评审人员评审反馈评审耗时索要预算。需求已

8、经提给许超功能未上线开发中。六、需求质量评审1）、需求评审过程中，所有的设计人员和评审专员有权判断此需求完成后是否需要质量评审。设计评审专员重点关注以下需求：a)涉及钱的需求，涉及抽取的需求，涉及加的需求，此类需求一般都是要评审的b)未发现其他项目做的需求，较为新颖的c)应用性广泛的需求，某项目完成后进行质量评审后，其他项目再提的时候可以直接告知复用代码2）、需求完成且变成带更新后，责任人会收到邮件要求质量评审，填写预计评审日期。3）、每两周由检查员检查已到达预计评审日期的需求，要求按照评审示例文档提供。4）、质量评审专员评审，重点放在是否按照需求评审完成逻辑，是否很好的执行代码规范，是否还有

9、可改进的地方。5）、反馈填写到项目管理的相应功能菜单中，如果该质量评审不通过请勾选“需再次评审”，填写完成后会发送待办给相应的责任人。注意点：需要费心跟踪“需再次评审”的需求有没有整改到位。另外对于发现明显 bug 的需求（特别是钱，抽取，加），提高风险意识。如果有提前更新的要求暂时关闭菜单。下阶段工作：6基于手机盾的移动扫码电子签章解决方案由于实际操作过程中开发人员相应不及时经常了没有反应，比较浪费时间，而且流程细节方面也有很多问题给工作带来了很多不便。因此流程做了相关优化：a)、增加“反馈状态”字段，记录发送待办时间，根据此时间如果三天内仍然位反馈的服务自动再次发送待办。搜索条件增加“反馈

10、状态”，列表也增加“反馈状态”显示b)、 新增“待办次数”字段，发送一次待办改字段就累计+1，列表页面也展示该字段c)、发送给责任人的连接里需要按照示例上传相关代码d)、对于未反馈代码的，质量评审人可以重置“反馈状态”，列表新增“重置反馈”按钮，点击触发：1、重置“反馈状态”字段 2、发送反馈页面的连接给相关责任人（注意“待办次数”累计）3、记录发送代办时间 PS：此按钮只在“未评审”及“需再次评审”才显示e)、负责人反馈页面改造，列表页面新增“反馈状态”，“反馈时间”字段。反馈页面增加示例文本下载功能，以及上传相关附件功能。点击保存触发时间新增：1、更新“反馈状态”2、更新“反馈时间”字段目前需求已经提给许超功能未上线开发中。七、通用需求产品组分享按照原先约定，应该给每个需求贴有标签，但目前此项工作执行有折扣，功能才上线，目前主要标记整改需求以及外网公示需求（外网公示需求，必须做质量评审）。7基于手机盾的移动扫码电子签章解决方案下阶段工作通过给对项目组常见个性化需求打上“通用需求”标签，由系统自动组织邮件发送给产品部门，实现通用需求分析。项目组在系统未完善前，可采用邮件方式实现。八、需求标签此项功能已经上线，目前只定义了“外网公开”以及“整改需求”，实际运用中“整改需求”标签已改到非功能性评审类别中进行标记了。下阶段工作：初始化一些标签，