项目过程管理.docxVIP

沃尔（北京）软件有限公司 项目过程管理 文档信息 编制日期： 2023/06/28 当前版本： V1.1 导出人： 李亮 版本 修改内容 修改人 V1.0 初始版 李亮 V1.1 增加开发提交日志使用说明 李亮 项目资料 使用人员：项目经理、产品经理、项目负责人 建立原则： 根据时间建立目录，一般为录音文件，建立目录时要把时间和录音对应的部门或者事件填写全部填写到目录名称里 根据业务部门建立目录，一般为用户提供的文件，比如商务结算大表，归类到商务-报表目录下 上传附件，尽量不要传压缩包，因为在检索附件内容时，可能检索不到压缩包里的东西 尽量做到第一时间上传附件，避免过程中文件丢失 如果同一个文件，前后有不同版本，那么要在附件名字上作区分 附件名字，一定要简明扼要，不可以直接用微信、企业微信里的随机名字 产品管理 使用人员：项目经理、产品经理、项目负责人、测试组 建立原则： 按照业务部门合理划分模块、功能点 产品管理的目录应该和第一版的系统功能菜单是相同的，后续功能菜单可能会调整，但是产品管理的目录不会调整 需求管理 使用人员：项目经理、产品经理、项目负责人、测试组、开发负责人 建立原则： 需求来源：要合理使用 产品规划：由项目经理、产品经理直接产出 用户反馈：由使用用户提交工单、提交调查问卷总结的需要修复或升级的需求 竞品调研：由项目经理、产品经理吸取其它竞品的优缺点，根据系统的特性做特殊化处理 内部需求：由测试、运维、开发提出提升工作效率的需求 需求类型：要合理使用 功能需求：由项目经理、产品经理提出业务方面需求 体验优化：由使用用户提交工单、提交调查问卷总结的需要业务提升、提升使用体验的需求 安全需求：由项目经理、技术负责人、客户提出的各类网络安全、硬件安全等需求 技术需求：由项目经理、技术负责人、客户提出的关于系统技术底层的需求 优先级：要合理使用 p0最大、p4最小 合理判断是属于需求还是bug，比如：系统某个潜在的隐患，需要修改很多功能，这属于需求，因为在已开始设计阶段未发现有这样的隐患。而如果设计阶段考虑了这个问题，但是没处理好，引发了其他或者更具体的问题，这时才建立为bug。 如果某个需求在多个功能或者多个项目中存在，则要添加到需求库中 需求和任务的关系 需求和任务是一一对应的，即一个需求，一定对应一个主任务。主任务可以向下分解若干层级。此目的是为了形成整个项目的开发进度计划。 需求中各选择人员的说明 审批人：当需求需要更高层级的人审批时，选择指定人，该人可在通知消息里，审阅该需求的目的、描述、设计思路等是否合理，不合理则驳回进行修改。 主责人：即该需求对应的主任务的执行人，主任务的审核人为需求的创建人。主任务的执行人，为项目的负责人，目前拥有项目负责人权限的是：梁承毅、朱庆桂、王贝贝、李亮。 对于创建需求的人来说，可能不知道是前端还是后端，也不知道分配给具体哪个人，需要由项目负责人根据需求的复杂度、技术要求、时间要求等条件，综合评估最合适的开发人员。 即此处为需求的主要负责人，而非实际完成人。 协作人：即如果知道需要哪个人来完成，则选择具体的开发人员，如果不知道，则空着。由主责人进行分解、指派。 关于需求应该挂在哪个节点 根据需求内容、需求类型、影响功能点数量来考虑应该挂在哪个节点。 比如：需求类型为功能需求，那么一定要挂在具体功能点。 需求类型为非功能需求，那么需要前确定此需求是新需求，还是在原有需求上的升级。 如果是升级，则和原需求再同一个节点下，建议用复制、变更等操作。注：一定不要随便挂在某个节点下，并且随意编辑需求标题、内容。将来无法回溯这个需求的全过程。 如果不影响任何功能，比如安全要求、效率要求，这种要挂在开发平台这个大模块下。便于后续遇到问题，能第一时间判断是不是多个相关需求造成的关联影响。即第一时间排除需求的问题。 如果影响多个功能，但都是同一个模块下的，比如计算税额的规则调整，此需求仅涉及商务模块下，则此需求挂在商务这个大模块下，不需要细致到具体功能点。 如果影响多个功能，但都是不同模块下的，比如电子签章，不仅影响多个功能，且可能未来还会增加多个功能。则当前时间节点，将该需求挂在开发平台这个大模块下，如果后续有增加功能，则在新功能的完整需求中，一定要包含关于电签的内容。即新增加功能，不需要单独建立电签的需求。 关于需求文档如何编写 针对本公司的特性，需求文档要兼顾开发人员、测试人员都能看懂，所以暂定本公司的需求文档需结合需求文档和开发文档的特性，而非给用户进行确认的需求文档。 各项目负责人编制需求文档的风格不同，并且项目负责人更了解自己的团队，也形成了各自的特色、常识性需求点。故需求文档不做形式要求，只做内容要求。 需求文档