ICONIX过程之路——愿景 | 如何把握老板需求
本文讲述软件过程中的ICONIX方法,面向企业客户(To B)的需求工程,以及如何把握老板需求。
文章一开始先介绍了ICONIX的相关背景知识,之后紧接着介绍了“ICONIX过程有什么特点”和“ICONIX过程中如何完成需求开发工作”。然后在详细介绍需求工作方法之前,简单地阐述了为什么“需求是软件成功的基础”。既然是面向企业客户的需求工程,那么分析的下一个问题就是“客户为什么要花钱购买软件”。当我们真正步入一家企业做需求时,又需要解决“如何把握以下三类人(老板、中层经理、一线员工)的需求”的棘手问题。最终,我们通过一个案例描述需求分析工作的第一步:定义愿景,也就是如何把握老板需求。
背景知识
ICONIX方法的介绍及相关说明:
ICONIX是一种软件开发方法。提倡尽早进入编码阶段,缩短分析设计周期。ICONIX提供充足的需求和设计文档,但不过度分析设计。 从把需求文档变成可运作的代码过程只需四步,使用四张UML图(下面会有介绍)。
从图中可以看出扩展ICONIX过程可分为:愿景、业务建模、需求分析、健壮性分析、关键设计、最终设计和实现这几步。它又分为两个大的部分,分别是需求阶段和系统的设计和实现阶段,又可分为四个阶段:需求分析阶段、初步设计阶段、详细设计阶段和部署阶段。它基于极限编程和敏捷软件开发的思想,提倡在项目开始阶段构建域模型和用例模型,其中用例模型驱动整个动态模型,而域模型驱动整个静态模型。ICONIX过程是一种以最小步骤实现用例到代码的方法学,覆盖了软件过程中所有关键的环节。
问题列表
- ICONIX过程有什么特点?
- ICONIX过程中如何完成需求开发工作?
- 为什么说“需求是软件成功的基础”?
- 客户为什么要花钱购买软件?
- 思考如何把握以下三类人的需求?
- 如何做好需求分析第一步:定义愿景?
ICONIX过程有什么特点?
在百度百科上对ICONIX的定义中,有这样一段话:“ICONIX提供充足的需求和设计文档,但不过度分析设计。 ICONIX过程从把需求文档变成可运作的代码过程只需四步,使用四张UML图。”总结下来就是上面这张图。其中利用基于UML图表的具体方法本文不予介绍,此内容很重要,以后作者会出专题介绍。
ICONIX过程中如何完成需求开发工作?
想象一下这样的场景:你去企业客户那里进行需求调研,跟老板谈、跟中层经理谈、跟一线员工谈,谈完之后根据记录的内容进行分析,这过程中用到了一系列的方法和工具,最后生成了一个需求规格说明书,上面记录了软件所要具备的功能,这一阶段的任务就算完成了。具体思考点请看上图。
But,do you know why?
很多人都知道如何做需求分析以及做出来的需求长相如何,但我们经常遗忘为何做需求。
为什么说“需求是软件成功的基础”?
从两个维度考虑:一是不做需求产品容易失败,二是因为需求不好做,所以我们做需求。
那么,接下来请考虑——
客户为什么要花钱购买软件?
在真正考虑这个问题的时候,一定不单是站在老板角度考虑(开源节流),还要考虑中层经理和一线员工,这两者同样是企业客户中很重要的组成部分。请看下面。
思考如何把握以下三类人的需求?
假如让你到一家企业去谈需求,你会找谁谈?小白说找老板,因为“老板不出钱,其余都扯淡”;小红说找经理,业务流程只有经理最清楚;小黄说找员工,员工干不出绩效遭吐槽,再费心设计的软件都玩完。此外,还有若干版本的小白、小红和小黄。现在,我们把目光投放到问题根本上来,需求要解决什么问题?假设我们知道系统要改善哪个组织的业务流程,以及该组织中最有权力的是谁,那我们就可以去拜访这位老大,询问他对项目的期望如何,并描述出愿景的度量指标。单说起来会让人感到不解,请看下面。
如何做好需求分析第一步:定义愿景?
案例:某市人才交流中心计划举办线上招聘活动,依托招聘网站开展人才交流活动,让求职者与HR能够随时随地发布和查询招聘信息,从而减少人才交流中心的现场服务人员数量,缩短求职者与HR的等候时间,消除招聘活动的时间和空间限制,等等。
案例至此,我们首先来找到软件项目——招聘网站,其次是软件项目的老大——人才交流中心,并得到人才交流中心对招聘网站的期望——让求职者与HR能够发布和查询招聘信息,最后用可度量的指标描述愿景——减少人员数量、缩短等候时间、消除时空限制。
以上案例仅是抛砖引玉,还希望大家能够举一反三,并付诸实践。
未完待续,敬请期待。欢迎在下方留下您的宝贵意见。
本文由 @巴戈 原创发布于人人都是产品经理。未经许可,禁止转载。
用例分析写的不太准确,需求就是产品对拥有者有价值所必须做的事情,或具有让拥有者接收或者感兴趣的品质,需求之所以存在是因为该类产品要求具有什么功能,或者拥有者希望该需求成为自动化完成工作的一部分;需求的来源是利益相关者包括操作人、运维以及出资人等,但是要了解需求肯定要确认从工作范围上下文,分析数据流找出业务事件,通过一系列工作调研、建模确认业务策略(本质),细化业务用例,业务用例可分解成场景,产品要做的事就是确定业务场景中哪些需要自动化完成就确认了puc。写这么多就是要说明无论利益相关者是谁,归根到底都是业务活动决定的,最好不要对立开来;通过业务事件来划分工作,每次对一个业务用例进行需求收集过程中可能设计不同利益相关者
有幸得到指点!能加微信聊聊吗 我的是TienLeo