对工作分工的一点简介记录
今天谈需求的时候主管兼功能需求顾问的一句话XXX业务主管有个需求报表我已经让他出了表样且让他在系统中截图字段我一会转发给你开发一下让我打开了话匣子我们就交流了一下信息化业务关键用户、功能需求顾问、技术开发顾问的分工探讨。我的观点关键用户只需要给出自己需要什么表样数据怎么和系统勾稽是需求顾问的职责需求顾问对开发功能负责。主管观点关键用户要发挥更大的作用需求顾问的作用拉齐关键用户和技术起督导监督的作用。理由公司业务需求有很多特殊性只有业务顾问才能知道我司的需求顾问的业务能力还没有达到这个高度。对于该理论我不能苟同是不是在他的理论下需求顾问就只要是一个会议的拉起的职责把关键用户和开发拉到一起敦促关键顾问完成需求监督技术顾问完成开发所以我请教了一下当下最火的AI给一个机器化中肯的分工---------------------------------------------------------------------------------------------------------------------业务关键用户 需求顾问 技术顾问的工作职责界限的合理方式在 ERP 或大型信息系统实施中业务关键用户、需求顾问业务顾问与技术顾问的职责界限最合理的划分方式是遵循业务主导、技术支撑、需求翻译的协同原则 业务关键用户是“业务所有者”负责定义做什么What和为什么做Why确保系统贴合实际作业场景 需求顾问是“翻译官与架构师”负责将业务语言转化为系统逻辑How to map设计流程方案并填补业务与技术的鸿沟 技术顾问是“实现者”负责解决技术可行性How to build通过配置、开发或架构设计将方案落地。 三者并非割裂的流水线而是围绕“业务价值落地”形成的互补共同体。若界限模糊极易导致需求失真、开发返工或系统上线后无法实用。 业务关键用户业务场景的“守门人” 关键用户通常来自各业务部门骨干他们最懂一线痛点但往往缺乏系统思维。其核心职责边界在于“业务真实性”与“验收权”。 需求定义与场景还原负责收集本部门真实业务需求提供具体的业务场景如“原材料入库滞后”痛点而非直接提出技术解决方案。他们需明确业务目标、规则及例外情况。 流程验证与测试主导在系统测试阶段关键用户不从代码逻辑出发而是从“业务操作是否顺畅”进行验证。他们需设计基于真实业务数据的测试案例如模拟跨部门绩效分配并拥有功能是否通过的“一票否决权”。 知识转移与推广作为部门内部的“种子教官”负责编写操作手册培训最终用户并收集上线后的反馈以推动持续优化。 边界红线关键用户不应直接参与系统配置、代码开发或数据库设计也不应越过需求顾问直接向开发人员下达技术指令以免造成系统架构混乱。 2. 需求顾问业务顾问业务与技术的“翻译官” 需求顾问是连接业务与技术的桥梁既懂业务管理方法论又熟悉系统功能边界。其核心职责边界在于“方案可行性”与“逻辑闭环”。 需求分析与抽象建模将关键用户零散、感性的业务诉求抽象为标准化的业务流程模型。利用差距分析Gap Analysis识别现状与系统标准功能的差异提出优化建议。 方案设计与资源协调负责编写详细的需求规格说明书BRD/FRD明确系统逻辑、数据流转规则及权限体系。他们需评估需求的可行性若业务需求超出系统标准能力需协调技术顾问评估定制开发成本。 全流程管控从项目前期的蓝图设计到实施中的配置指导再到上线后的运维支持需求顾问需确保业务目标在系统中不走样地实现。 边界红线需求顾问不应替代关键用户做业务决策如确定财务核算规则也不应直接编写底层代码或进行服务器架构搭建其产出物应为逻辑文档而非程序代码。 3. 技术顾问系统落地的“实现者” 技术顾问含开发顾问、BASIS 顾问等专注于技术架构、代码实现及系统性能。其核心职责边界在于“技术实现”与“系统稳定性”。 技术方案设计与开发根据需求文档设计系统架构、数据接口及算法逻辑。负责二次开发如 ABAP 代码编写、系统配置及非标准功能的实现。 技术难点攻关解决项目实施中的技术瓶颈如高并发下的系统负载优化、跨系统数据集成如 ERP 与 MES 对接的安全性及合规性。 运维支持与文档交付负责系统上线后的技术运维处理报错日志优化数据库性能并移交源代码、技术设计文档等资产。 边界红线技术顾问不应直接决定业务流程的走向如“审批流应该经过谁”也不应跳过需求文档直接响应业务用户的临时修改要求必须严格依据确认后的需求规格书执行。 4. 协同机制如何避免“三不管”地带 为确保职责界限清晰且协作高效建议建立以下协同机制 需求池管理机制所有需求必须经关键用户提出、需求顾问分析筛选并优先级排序后方可进入开发队列杜绝“口头需求”。 联合测试制度测试阶段实行“双签制”关键用户签署业务功能确认书技术顾问签署系统性能确认书缺一不可。 备份与轮岗策略鉴于培养既懂业务又懂技术的人才成本高昂企业应建立关键用户与内部顾问的备份机制如轮岗、内部培训防止因人员离岗导致项目瘫痪。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.coloradmin.cn/o/2410498.html
如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈,一经查实,立即删除!