本人报表分析师,属于某互联网上市公司的BI部门
业务部门很多,提需求总是微信上讲了就过了,难免也会漏了一些....
报表分析完了,走开发,也没办法看到开发处理的进度....
业务问我→我问开发→开发怼我→我又不能怼业务
敢问各位大佬有无好用的需求管理的方法or工具?不然我要被内耗死了
PS:打广告的国恩国恩
本人报表分析师,属于某互联网上市公司的BI部门
业务部门很多,提需求总是微信上讲了就过了,难免也会漏了一些....
报表分析完了,走开发,也没办法看到开发处理的进度....
业务问我→我问开发→开发怼我→我又不能怼业务
敢问各位大佬有无好用的需求管理的方法or工具?不然我要被内耗死了
PS:打广告的国恩国恩
那必然是ONES了,研发项目管理和任务协同都非常方便,前不久听说团队版50 人及以下可以免费使用,特地去注册试了一把,体验还是非常好的。
参考链接:
即日起,ONES 团队版50人以下免费
ONES Project - 研发项目管理和任务协同 | ONES
已参与 「极客观点」 ,欢迎正在阅读的你也加入。
需求管理的三种方法是:1、结构化分析方法;2、面向对象的分析方法;3、卡诺模型;4、3W分析法;5、PSP分析法。其中,结构化的分析方法是传统的分析法,它的好处是在需求阶段可以不需要精确地定义系统,只需要根据业务框架确定系统的功能范围,以及每个功能的处理逻辑和业务规则等。
1、结构化分析方法
结构化的分析方法是传统的分析法,它的好处是在需求阶段可以不需要精确地定义系统,只需要根据业务框架确定系统的功能范围,以及每个功能的处理逻辑和业务规则,功能需求规格书等。因为不需要精确描述,因此描述系统的方式比较灵活多样,可以采用图表、示例图、文字等等方式来描述系统。在系统开发以前,一般还可以采用更为直观的原型系统方式和最终用户进行交流和确认,因此对业务需求的要求会低一些,业务需求阶段的周期相对容易控制;通过业务全景图,最终用户也能了解系统的功能;通过功能活动图和业务规则的描述,也可以相对精确地描述业务系统;因为没有严格的标记语言,可以采用适当的篇幅描述适当的系统。当然,这种方法的缺点也是明显的,分析人员和业务人员之间可能缺乏共同语言,机器不能识别业务需求书,在设计阶段还需要继续和用户确认一部分功能。
2、面向对象的分析方法
面向对象的分析方法的最大好处是在需求阶段,就能够非常精确地描述一个系统,采用程序语言的方式和最终用户交流(最终用户必须要熟悉这种语言),能够在项目一开始就发现很多问题,避免在开发的过程中出现需求的反复,而且在系统设计和开发阶段不需要最终用户参与。在实施上,一般可以采用场景、业务功能等方式来描述,比较适合于业务流程环节多的系统,或者软件产品的开发。
3、卡诺模型
卡诺模型(KANO模型)将用户需求分为基本型需求,期望型需求,兴奋型需求,无差异型需求,反向型需求五类需求,通过对用户需求的分类来对用户的不同需求进行区分处理,从而帮助产品经理找出提高用户满意度的切入点。
(1)基本型需求
又称为必备需求,是指用户觉得产品应该具备的功能或服务。如果不具备,产品的可用性会大大降低,所以用户的满意度会大幅下降。但是,产品满足此类需求时,用户认为这是理所当然的,所以满意度并不会提升。
(2)期望型需求
是指用户期望得到的功能或服务。用户想要得到,但又不是非要不可。如果满足此类需求,用户的满意度会提升。如果不满足此类需求,用户的满意度会下降。
(3)兴奋型需求
又称魅力型需求、亮点型需求,是指提供给用户完全出乎意料的产品功能或服务,使用户产生惊喜感的需求。如果满足了用户对于兴奋型需求的期望,用户满意度会急剧上升。反之,即使产品没有满足用户的兴奋型需求,用户的满意度也不会降低。
(4)无差异型需求
无论产品提供或不提供此类需求,用户满意度都不会有所改变。此类需求,有或没有都不会对用户的满意度产生影响。
(5)反向型需求
是指会引起用户不满的产品功能或特性,用户并不希望其出现,提供后用户满意度反而会下降。此类需求要尽量避免。
4、3W分析法
根据3W分析法,我们列出用户提出这样的需求背后的原因可能是成就感、被激励、收集控、强迫症、利益、好看和新鲜感,这些原因就是用户提出这个需求背后的动机,就是用户的深层需求,找到原因后然后产品经理就可以进行针对性的设计产品解决方案,从而满足用户的需求。
5、PSP分析法
PSP分析法是P(person)、S(scenes)、P(paths)的简写,即“角色-场景-路径”分析法。角色是指对同一个功能,不同角色的需求不一致。产品经理在面对一个需求的时候要搞清楚提这个需求的人的角色是什么。
场景是指每个需求都有一定的应用场景,产品经理在分析需求时需要分析真实发生的场景,考虑实际情况。
路径是指分析满足需求的关键路径。用户提出一个需求,产品经理在设计功能的时候要去考虑能不能够在一条完整的路径上都去满足他,而不是说只满足这个需求中的某一部分。
已参与 「极客观点」 ,欢迎正在阅读的你也加入。
一般来说需求管理都会选择和企业内部的通信软件绑定的软件了。
比如企业微信就是TAPD, 飞书就是自己的那一套,还有钉钉应该也是自己单独的。
禅道这种虽然也很不错,但是太独立了,和这些高频使用的通信软件不太好无缝集成。
已参与 「极客观点」 ,欢迎正在阅读的你也加入。
禅道,维格表...再不济腾讯文档总有一款适合你,向领导请示请示,表明能怎样怎样提升工作效率,协同效率等等好处,推广起来没有那么麻烦。
已参与 「极客观点」 ,欢迎正在阅读的你也加入。
首先,非常不推荐楼主在微信里讲需求。试想一下,大家的微信里,有多少个群,每天有多少条消息?
如果在微信里提,即使是艾特了某一个人,想必也会刷屏或者遗忘吧。
再说说我之前所用的吧,在第一个公司时候,我们有自己的提报平台,但是我们用的最多的是taped和飞书。当然看过其他回答里同学的推荐,包括禅道,思否社区的ones,由于其他工具没用过,因此不作评价。
针对楼主的描述,我觉得仅仅是推荐一两个软件,显然是不行的,毕竟有些事需要人来解决。(因为我在上个公司时候就遇到过类似的问题),因此建议楼主和业务,开发,运营,产品相关一起在一个工作空隙,一起开几个相关会议,能否对某些事情打成约定。比如共同约定一两款软件来记录,共同去遵守。
最后,默默说一句,通常互联网上市公司都有自己健全的业务需求提报平台。楼主不妨问问领导,这个问题之前是怎么做的?
已参与 「极客观点」 ,欢迎正在阅读的你也加入。
这个是一个项目管理的问题
软件开发着重放到时间管理上就好,会议就要确定交付时间节点,按照时间节点检查即可
这种可以利用看板来管理 禅道 jira都有这样的功能
已参与 「极客观点」 ,欢迎正在阅读的你也加入。
上市公司的话你们团队规模应该还是挺大的,开发的管理听起来居然这么粗暴的吗?
建议先把需求管理规范梳理清楚,并且保证各个相关部门和角色都清晰理解。
比如说提了需求之后,需求应该经过评审,厘清,确定是真需求,然后确定优先级,规划迭代,分配负责人和预估工时,然后进入开发阶段。
规范是基础,然后上工具,把规范放在wiki上保证相关人员都了解,最好能把一些规范的流程固化在工具上,比如设置需求要经过产品经理评审后才能继续流转;又比如需求在开发过程中如果业务方突然产生需求变更,需要重新评估,确定变更的话需要将变更信息同步相关人员,且要对变更可能导致的迭代计划影响也同步。
确立规范和固化流程其实就是在提高团队的信息透明度,保证需求价值被理解,提高协作沟通的效率。
研发管理工具可以看看ONES,它们的需求管理能力还是挺强的,需求属性、工作流都支持自定义,还可以关注你创建的需求,看到流转的状态,还可以设置一些关键节点的提醒。
https://www.bilibili.com/vide...
补充一波,看到ONES最近宣布把团队版免费了,50人以下的研发团队可以免费用,赞!