需求管理是项目管理的基石,根据我的经验,项目失败或者延期的原因十之八九都源于需求管理没做好。 需求划分方法因项目不同而不同,以软件类项目为例,需求分为9类: 流程性需求、 数据性需求、 接口性需求、 界面性需求、 权限性需求、 表单性需求、 报表性需求、 功能性需求、 非功能性需求。 第一个检查点为第一周结束, 第二个检查点为第三周结束, 第三个检查点为第四周结束前2天。 需求变更控制最简单的方法,就是提高变更的代价,比如通过制定需求变更的模板及很长的审批链条来控制变更的频率。如果需求变更没有代价,那么用户提需求的时候就容易草率,对项目管理百害而无一利。 项目内审查 一般来说,需求文档是很重要的交付物之一,为了确保需求文档的质量,就需要建立互查机制:项目组内互查、项目组间互查。该任务发生在最后一个检查点结束之后。
项目管理——需求收集与管理 VS 需求收集对于产品经理来说,都已经属于老生常谈了。在产品的立项和设计前需要先做需求调研,在这里我们就来谈谈如何进行需求收集和管理。 1.深刻理解市场需求、用户需求、准确把控行业发展趋势,保持高度的市场敏感度; 2.保证产品研发是围绕客户需求来展开,真正实现产品研发“以市场为导向,以客户为中心”,而不是闭门造车; 3.实现产品创新。 内部来源 1)公司产品战略; 2)项目发起人:并不是项目发起人那来得来的需求就是完善的,或者是合理的,但项目发起人关注产品中的点,而这些点恰恰是产品的核心所在,也是赢利所在; 3)客服人员:包括呼叫中心 四、需求收集流程 1.建立收集机制 明确每个需求手机活动参与者的岗位职责; 建立需求预处理流程; 周期性的重复需求收集活动; 2.使用统一收集系统 大部分的项目团队都使用表格来记录收集的需求信息,少数采用需求收集系统 有效的需求管理在于维护清晰明确的需求阐述、每种需求类型所适用的属性,以及与其他需求和其他项目工作之间的可追踪性。
我们的项目需求管理1.0 时代,就是用excel 列表的方式来轻量化去管理需求,通过项目群来同步版本需求规划。 [1499393465904_7859_1499393466807.png] 项目需求管理2.0时代 --- TAPD集中管理+需求评审 1、 需求的工具化管理:变excel的人工维护,为TAPD集中管理方式 2、需求评审机制:设立产品版本规划管理委员会。建立需求评审机制,由这个专门的需求决策者来对每个版本规划的需求质量和范围进行评审确认。 2、 我们将产品管理委员会对需求的评审时间,延后到合流阶段,建立了合流评审的机制。 当然,敏捷项目需求管理的方法,我们仍在不断总结和迭代优化中,希望大家也一起来多探讨更好的管理模式,期待更优的需求管理4.0 时代的到来!
然而,分布式团队在需求管理中面临协同效率低、信息同步滞后、资产复用难、变更管控弱等问题,严重制约项目质量与进度。 VisualRM需求数智化平台,以“线上化协同、结构化管理、资产化复用、智能化提效”为核心,构建适配分布式团队协作的银行核心项目需求管理方案,破解协作难题,助力项目高效落地。 一、分布式团队协作下核心项目的需求管理痛点核心项目涉及账户管理、支付结算、信贷审批等关键业务模块,需求复杂度高、关联度强,分布式团队(如异地业务部门、远程研发团队、外包测试团队)协作时,需求管理痛点尤为突出 二、适配分布式团队协作的需求管理核心能力针对上述痛点,VisualRM需求数智化平台从“协同、质量、资产、变更”四大维度发力,打造适配分布式团队协作的核心能力,确保银行核心项目需求管理高效、可控。 三、分布式团队协作需求管理方案实施方法为确保方案在银行核心项目中落地见效,结合VisualRM平台功能,制定“四步实施法”,适配分布式团队协作特点:(一)项目启动与系统配置(1-2个月)1.跨团队需求调研
2)是否有大量的需求处于等待开发状态? 3)是否有很高比例的需求在最初定义好之后需要重复再修改? 4)开发出来的需求是否有很高比例其实没有被最终用户所使用? 如果你的企业存在这样的情况,请继续阅读。 我们来看一个典型的项目开发声明周期模型: ? 虽然很多项目已经在采用Agile/Scrum的方法进行开发,但在一头(从业务想法到开发团队可执行的需求)一尾(从代码完成到上线)还是典型的瀑布式。 但对企业管理而言,IT又不能把所有的计划都推后,不作出任何承诺。 这里的重点是针对长期战略性、中期提供附加值、和短期不可预测的需求采取不同的计划策略。 对于这部分需求,维护一个粗粒度的估计列表,并赋予优先级,而且保证占用工程师团队的工作量不能超过30%。 此种类型的工作也应包含一些必要的重构,增加 短期(3个月以内)临时出现、紧急或计划外(UNPLANNED)的工作:对于这种类型的工作,只做短期计划,比如1~2个迭代的需求,并且控制工作量占总工作量的20%
一、需求分组 系统路径 后勤 -> 项目系统 -> 物料 -> 计划->需求分组 事务代码 GRM4 第一步:点击“GRM4”或者直接在快速命令输入栏 输入“GRM4”进入主记录维护界面。 二、分配MRP组 系统路径 后勤 -> 项目系统 -> 物料 -> 计划->分配MRP组 事务代码 GRM5 第一步:输入“GRM5”输入WBS元素 第二步:点击新的条目 第三步:选择工厂、MRP 三、创建物料需求 第一步:点击“CJ20N”或者直接在快速命令输入栏 输入“CJ20N”进入主记录维护界面。 输入项目号,进入结构图; 第二步:点击售后活动,点击创建按钮,点击物料组件; 第三步:填写物料名称、需求数量、需求日期,选择库存地点,点击保存; 四、创建项目外向交货单 第一步:点击“CNS0” 第二步:填写项目定义和网络号 第三步:填写对应的装运点、发货时间、送达方,选择对应的销售组织、分销渠道、产品组; 第四步:填写交货数量、交付日期、发货日期;点击保存,产生交货单号。
第三课需求管理 1需求管理是什么 1.1需求挖掘:看四块,自己行业,总体趋势,未来方向,商业模式。最直接的需求一定来源于用户,用户访谈,用户反馈,调查问卷,社交平台。 1.2需求匹配:需求挖掘解决发现和确认需求问题,需求匹配解决要不要做的问题。 知彼:了解市场,了解用户,了解需求 知己:知道公司的资源是什么,公司的资源以及经济能不能够完成个人对业务的设计,公司处于什么样的一个阶段,身处所在的行业处于什么样的一个阶段 1.3需求排序 2行业阶段 3.需求收集的原则和方法 标签墙 用户意见渠道 奖励机制 原始需求的管理 归类 统计 用户反馈分类 需求列表–原始表格 意识:时间管理四象限 GTD工具 4.需求评估 4.1:KANO法
多年前有次面试,被问到产品需求跟项目需求有什么区别,由于也确实没做过像样的产品,多以交付项目为主,简短回复了下,也深知是片面甚至是错误的。 明确 项目需求有明确的需求提出方,需求内容多是经过业务人员或使用者的确认,但产品这方面是缺失的。 演化 项目需求的变化性很小,这一点产品需求也同样具备。 目标 项目需求的目标就是项目建设的目标,目标达成,项目结束。有新需要时,再开启新项目去达成。 驱动 产品需求的产生是自发的,项目需求是被动接受的。
前言 MOMO云敏捷项目管理,融合了敏捷、DevOps思想,打通了整个从需求、研发、测试、运维、运营的端到端敏捷。 数据分析 MOMO云针对研发系统进行了应用级和功能级的埋点工作,提供研发过程度量系统,方便管理人员通过观察数据分析数据来定位问题、分析问题、和做结论提供数据支持。 准备阶段 选择一款合适的敏捷项目管理工具。我们使用JIRA做项目管理,创建Scrum流程项目,加入项目成员和创建好面板和泳道配置。 会议重点在于分析问题根因,并识别出管理、流程、技术、工具上可落地的改进点。而且这些问题都要求最近的一个迭代中,执行落地,以避免问题再次出现。 总结 敏捷需求管理是一种文化,在敏捷实践中,每一个团队都有自己的特质,可以根据实际情况选择适合自己的敏捷流程和实践,才能够达到高质高效开发协作模式。
怎么让大家对需求的理解一致?如何既保证开发效率又保证质量?项目管理是「把事情做对」的重要能力之一。知识型工作者包括程序员,在工作中都不知不觉中扮演着「非职业项目经理」的角色。 看目录 1 为什么开发者需要懂项目管理 1.1 项目管理是“通过别人做成事情”的能力 1.2 项目管理能输出个人影响力 1.3 项目管理对个人生活也有价值 2 开发者在项目管理中会遇到哪些问题 2. 高优需求插入 在业务的开发过程中,可能存在被高优需求插入的情况,如果被高优需求插入,直接带来的影响是延后当前的工作完成时间。 处理方式: 评估高优需求的工作量,以及影响当前项目的程度。 具体到研发团队介入一般可分为需求评审、方案设计、需求开发、测试验收、发布上线、项目复盘六个步骤。这里提供之前所在前端研发团队的研发流程图用以参考: 2. 2. 性能风险 性能是非常容易被忽视的风险。研发人员可能忙碌于功能的实现,保障项目正常上线,往往非常容易忽视项目中可能存在的性能问题。
2.Spinner下拉框中的布局,也就是我点了Spinner后,出现的让你选择的界面的每个item的样式很简单,也就是Spinner.setAdapter中的adapter的布局设置为我们自己的布局就可以了 比如说Material Design 之 TabLayout 使用 同样也会提到一个比较好的需求: 需求1:比如菜单只有3个,那我们肯定是希望在一个屏幕中就能显示,并且是平分的方式,呈现: 需求2:比如恰好菜单有 8个之多,我们肯定就希望是滚动的,不是挤在一个屏幕: 大家都知道,让TabLayout实现需求1和需求2,我们只要设置TabLayout的Mode分比为:TabLayout.MODE_FIXED 和TabLayout.MODE_SCROLLABLE 有些需求是要JS回调我们这边JAVA的方法,这个项目中,我们用户登录界面等都是在网页处的,但是要求我们这个原生App的外壳本身要有自动登录功能,登录一次后就不需要在网页上再次登录。
01 概述 本文是梳理需求分析与需求管理方法-产品经理工作职责&工作核心技能之一,笔者写本文的目的一是把自己的知识体系做个输出,包含来自己的经验总结和最近学习到的知识总结,其二顺便分享。 交付物:BRD需求文档。(或类似的相关的文档,如需求调研报告、市场调研报告等) 2. 产品设计开发期 这个阶段的需求分析,目的是要设计一个可落地的解决用户痛点,满足用户需求的产品。 还要明确该需求带来的价值。需求最终是要交换成价值的。 正确的问题VS错误的问题: ? 明确需求的价值: ? 2. 06 需求管理 需求管理指的是如何安排已经明确产生的需求,工作中我们通常会遇到四面八方包括产品经理自己给的需求,但是资源和精力无法让做到有求必应,我们需要去把需求做一个分类和排序,尽可能的去做性价比高的需求开发 2. 时间管理四象限法 ? 本方法可以快速帮助我们评估需求开发的时间优先级。从紧急重要程度两个维度比较合理的帮助产品有条理的安排开发秩序,避免盲目排序。 3.
指项目团队不能控制的,将对项目产生影响、限制或指令作用的各种条件。 什么是组织过程资产OPA? 组织过程资产是执行组织所特有并使用的计划、过程、政策、程序和知识库,会影响对具体项目的管理。 系统型或简单型,职能(集中式),多部门,强矩阵,弱矩阵,均衡矩阵,项目导向(复合、混合),虚拟,混合,项目管理办公室PMO 什么是项目管理办公室PMO? 是对与项目相关的治理过程进行标准化,并促进资源、方法论、工具和技术共享的一个组织结构。 主要职责是什么? 从提供项目管理支持服务,到直接管理一个或多个项目。 支持型 担当顾问的角色; 控制型 而且通过各种手段要求项目服从; 指令型 直接管理和控制项目,项目经理由 PMO 指定并向其报告。
产品经理每天都在和各种需求打交道,但产品需求管理绝非易事,市面上大约60%的产品都是因需求管理失误而走向失败。 本文将从产品需求管理核心概念切入,深入拆解产品需求管理流程,推荐一些实用的工具,并展望当前AI赋能需求管理的前沿趋势,助力企业实现需求价值最大化,打造爆款产品。 敏捷迭代管理:采用敏捷开发模式,以2-4周为一个迭代周期。每个迭代确定核心目标,集中资源完成部分需求,快速上线验证效果,根据反馈及时调整后续计划。实时监控进度:定期召开项目例会,同步需求进展。 这里可以使用项目管理工具来监控任务进度,如果发现某个需求的开发进度延迟,及时分析原因,调整计划或增加资源投入,确保需求顺利落地。 适用场景:复杂软件开发项目;跨部门敏协作;需要深度集成开发工具的技术团队。
2.需求在线编写:智能化协同提升效率 在编写环节,Visual RM 聚焦 “多人协同” 与 “AI 赋能”,解决传统线下编写的低效问题: 多人在线协同编写:支持多人同时在线编辑,实时显示编辑状态与修订痕迹 ,例如将 “电商平台会员体系搭建” 拆分为 “会员等级设定”“会员权益配置”“会员数据统计” 等子需求,便于分步落地; 需求转移:支持将需求在不同项目、不同模块间、不同负责人之间转移,满足业务调整需求; ; 进度实时跟踪:借助平台的项目管理模块,实时查看各任务完成进度,当出现延迟时,系统自动提醒负责人,并支持团队召开线上例会同步进展,及时调整资源或计划; 效果初步验证:需求开发完成后,可在平台关联测试报告与用户反馈数据 (2).发布基线:锁定需求版本 为入库需求发布版本基线,记录需求的当前状态与版本信息(如需求编号、版本号、落地时间、关联项目)。 入库后的需求资产可通过关键词检索、分类筛选等方式快速查找,后续项目需类似需求时,可直接调用资产并根据实际场景调整,大幅减少重复开发成本,实现需求资产的循环利用。
在GitHub上,需求或者说问题(issue)的管理通常是开放和透明的,这样做是为了鼓励社区参与和贡献。 之前博主考虑过一个问题:一个需求会不会被许多人同时领取,都做了开发导致重复劳动,如果不会,项目通过什么机制避免,理论上可能出现这种情况。 经了解确认, github项目有一系列的社区管理实践和工具的辅助,这种情况很少发生。下面是几种常见的避免重复劳动的机制: 1. 2. 使用标签(Labels)管理状态 项目维护者和贡献者可以使用GitHub的标签系统来标记issue和PR的状态。 项目维护者的角色 项目维护者会监控issue和PR的状态,他们有责任管理任务的分配和进度,避免重复工作的发生。在某些情况下,维护者会直接指派任务给特定的贡献者,这样可以直接避免重复劳动。 4.
业务需求协作管理贯穿于整个软件产品版本周期,涉及与业务软件交付相关的所有角色,包括 业务人员、产品及运营人员、开发人员、测试人员、运维人员 等。 同时,还可以灵活应对临时的需求更改,响应市场的快速变化。利于持续交付的需求拆分总原则就是:“坚持以业务视角 对需求进行分解”。 它就像金融债务一样,如果没有恰当管理,累计的利息可能就会把你压垮。 关于需求的拆分还需要了解: 需求拆分的受益; 需求拆分的成本; 需求拆分的方法; 需求分析与管理工具集; 团队协作 当多人共同完成一项任务时,如何高效协调团队中每个人的时间,是一个非常大的挑战。 共享日历 是一种有效的团队时间管理方法。共享日历可以分为两种:一是团队时间表,二是个人非工作时间表。
经历了这些项目之后,我认为,站在开发团队的角度,评判一个软件项目成败的因素,最关键的就是两个点:需求管理和可行性分析。 评估需求的优先级,可以使用“紧急重要四象限法”来区分,在项目中要优先做紧急重要的事情,再做不紧急但是重要的事情,这个理论同样可以用于个人的工作内容管理。 ? 需求变更的管理,作者提出了三个解决方案 提升需求确定性,减少需求的变更。 这种方案的优势是可以立马起到效果,缺点是过于繁琐的流程不利于项目协作。 降低响应需求变更的成本,积极响应需求变更。这种方案的缺点是对软件架构和项目管理要求比较高。 你们是怎么管理需求变更的?文中提到的三种方式,我们主要使用的方案1+方案2,目标是使用方案3。
【实现效果:】业务同学使用多维表管理客户需求,和产品团队经过评审之后,一键把多维表里对应的需求生成TAPD需求/缺陷单【准备工作】准备一个多维表,比如维格表、金山轻维表等可以参考这两个模版:金山轻维表: 产品需求- 客户成功维格表:产品需求- 客户成功设置好TAPD对应的需求管理字段,参考如图【流程配置】以维格表为例,打开腾讯云HiFlow模版中心,搜索打开“维格表需求管理表符合条件的自动创建TAPD新需求 + | HiFlow 场景连接器 | 模板详情”:触发应用:维格表配置【触发条件】新增或修改的内容满足指定条件【配置账号】点击添加账号 然后来到维格表,点击维格表左下角【头像】- 【个人设置】2. 比如这里,我们选择“填写完成”等于“是”,然后保存执行应用:TAPD配置【执行操作】选择【创建需求】【配置账号】需要管理员登陆tapd账号之后授权【配置参数】然后把表格里对应的变量一一填写到TAPD【优先级 】、【模版】、【处理人】、【需求分类】如果选择默认值就可以直接从列表选取;如果选择变量数据,左边先改成自定义,右边再选择变量。
三、管理工具在线化 起初我们是用文档、表格来记录商家反馈的需求,交给产品经理来评估方案、更新需求的研发进度。 而需求进入研发过程是在效能平台进行流转(自研项目管理工具),这样一来会有很多弊端,例如,人工维护多个需求列表的信息,会造成进度更新不及时,从而造成信息不对称,答复商家错误的进度,引起商家不满。 管理者想知道商家提的需求集中在哪几个功能模块?某个商家今年总共提了多少需求?我们解决了多少,多少没有满足?这些过程数据都需要手动梳理,耗费人力。 基于以上诉求,我们把商家需求前期收集的过程也做进了效能平台,让需求从商家提出一直到研发上线在同一个平台流转,便于管理需求全生命周期(如下图)。 ? ? (提交需求时要怎么做、产品经理在收到需求时要怎么做、想查看进度时怎么做) 管理工具在线化带来的好处显而易见: 降低培训成本,对于新人来说,不清楚需求的如何流转,可以按照工具的引导来完成。