DDD案例(1):从需求分析到领域分析(1)

简介: DDD案例(1):从需求分析到领域分析(1)

20.3.1EAS案例背景

企业应用套件[1]是一款根据软件集团应用信息化的要求开发的企业级应用软件。该软件集团为各行各业提供软件交付服务,以在岸、近岸、离岸等多种模式交付软件。EAS系统提供了大量简单、快捷的操作界面,使得集团相关部门能够更快捷、更方便、更高效地处理日常事务工作,并为管理者提供决策参考、流程简化,建立集团与各部门、员工之间交流的通道,有效地提高工作效率,实现整个集团的信息化管理。

EAS系统为企业搭建了一个数据共享与业务协同平台,实现了人力资源客户资源项目资源的整合。系统包括人力资源管理、客户关系管理和项目过程管理等主要模块。系统用户为集团的所有员工,但角色的不同,决定了他们关注点之间的区别。


20.3.2EAS的全局分析

在全局分析阶段,需要针对目标系统进行价值需求分析。

1.价值需求分析

根据参考过程模型的描述,一种有效方法是通过商业模式画布来帮我们确定目标系统的客户、愿景和范围。EAS是一款面向B端的产品,它的客户实际上都是软件集团的员工。员工的角色不同,所属部门不同,职责也不相同,因而对其做客户细分非常有必要。实际上,我们在为EAS进行价值需求分析之前,重点调研了人力资源部、市场部与项目管理部的相关人员。作为支持者(提供部门的业务知识)与受益者(使用EAS的最终用户),他们各自提出了切合自身需要的业务功能,包括:

q市场部对客户和需求的管理,对合同的跟踪;

q项目管理部对项目和项目人员的管理,对项目进度的跟踪;

q人力资源部负责招聘人才,管理员工的日常工作包括工作日志、考勤等。

在对EAS的客户进行细分并确定各自的价值主张时,团队发现遗漏了最重要的利益相关者:集团管理层。作为集团业务的决策者,他们对业务目标的认识有利于更加准确地确定系统愿景。


作为一家提供软件交付服务的集团公司,核心生产力是从事软件开发的人力资源。各个业务部门的主要工作都是围绕着人力资源的供需进行的。决策者的痛点就是无法快速直观地了解公司人力资源的供需情况。例如,客户需要集团提供20名各个层次的Java开发人员,市场部门在确定是否签订该合同之前,需要通过EAS查询集团的人力资源库,了解现有的人力资源是否匹配客户需求。如果匹配,还需要各个参与部门审核人力成本,决定合同标的。如果集团当前的人力资源无法满足客户需求,就需要人力资源部提早启动招聘流程,或从人才储备库中寻找满足需求的候选人。通过EAS,管理人员还能够及时了解开发人员的闲置率,跟踪项目的进展情况,明确开发人员在项目中承担的职责和任务完成质量。


获得商业模式画布的渠道通路比较简单。这是因为EAS与其他创新产品不同,并不需要寻找各种渠道通路对产品进行宣传,只需利用行政力量要求相关部门使用即可。由此推导出来的客户关系实际上就是对参与EAS系统的各种角色做进一步梳理,了解这些角色在什么时候会使用EAS,又该怎样使用EAS


EAS是集团的内部系统,不牵涉具体的营收业务,因此它的收益来源更多地体现在对成本的控制和削减上,同时也包含该如何为集团的软件交付业务提供更好的服务与支持。虽然EAS的收益来源并不明显,但对它的思考有利于驱动我们对核心资源和关键业务的发掘。

为了保证EAS的顺利交付,需要哪些核心资源?交付的EAS能够提供哪些关键业务?在确定了EAS的客户、价值主张、收益来源等内容后,参与到商业模式画布头脑风暴的人员能够轻易回答这些问题。由于EAS主要解决人力资源问题,它需要的重要合作也应该与人力资源的招聘、培训有关。最后,EAS是企业内部系统,在考虑实现该系统之前,了解开发该系统需要的成本结构也就显得理所应当。由此,就可以获得图20-4所示的商业模式画布。



[1]    本例的详细需求、设计和代码请在GitHub中搜索“agiledon/eas-ddd”获取


image.png


虽然EAS并非一个创新产品,但在全局分析阶段通过它探索价值需求,会更容易引导客户描绘出心中的设想,并通过这种可视化的形式将其真实地传递出来,形成对问题空间一致理解的,就价值需求达成共识。

一旦确定了商业模式画布的内容,就可以根据商业模式画布各个板块与价值需求之间的关系,获得EAS的价值需求,作为全局分析规格说明书的一部分。组成EAS全局分析规格说明书的价值需求如下所示。

 

1  利益相关者

q  集团决策者

q  子公司

q  人力资源部

q  市场部

q  项目管理部

q  项目管理办公室

q  财务

q  员工

q  服务中心

2  系统愿景

  避免信息孤岛,实现人力资源的可控,从而达到人力资源的供需平衡。

3  系统范围

3.1  当前状态

q  创建了由项目经理、业务分析师、开发人员和测试人员构成的特性团队

q  集团项目管理部负责项目的流程管理

q  集团已有OA系统作为部门之间的流程协作与消息通知

q  集团已制订了人才招聘管理办法、项目过程管理办法

q  软件学院和招聘网站的简历作为集团的人才储备库

q  员工培训已有合作的培训公司

q  市场部提供客户和潜在客户名单

q  由集团下达行政命令在集团内部相关职能部门推广EAS系统

3.2  未来状态

q  EAS系统在×年×月×日通过用户验收

q  EAS系统在×年×月×日上线运行

q  EAS系统负责客户关系管理、项目管理、人力资源管理

q  通过客户满意度评估EAS系统的价值

3.3  目标列表

q  通过可视化方式体现人力资源的供需状况

q  管理集团与客户和潜在客户之间的关系,管理市场需求,对合同进行跟踪

q  管理项目和项目人员,跟踪项目进度

q  实时调整用人需求,制订招聘和培训计划

q  管理员工考勤、工作日志等日常工作

 

2.业务需求分析

在完成价值需求分析后,就可以在价值需求的引导与约束下开始业务需求分析。

业务需求分析起始于业务流程,能让目标系统的业务功能起来,执行一系列的活动来满足参与角色的业务价值。为了快速把握EAS的需求全景,可以抓住体现业务愿景核心价值的主流程。既然EAS人力资源的供需平衡为关注核心,那么所有参与角色需要执行的主要业务功能都与该核心价值有关。在价值需求的指引下,可以结合供需平衡将所有参与角色抽象为需求方与供应方,然后站在供需双方的角度思考各个参与角色之间的协作方式与协作过程,如图20-5所示.


image.png


20-5清晰地体现了需求与供应之间的关系,展现了核心业务流程的关键环节。注意,该协作示意图并非项目开始之前的当前状态,而是期望解决供需平衡问题的未来状态。这种协作关系也体现了打破部门之间信息壁垒的系统愿景。根据这一协作示意图,我们可以以泳道图形式的业务流程图表达整个系统的核心流程,如图20-6所示。


这个核心流程体现了业务流程的总体运行过程,属于更为宏观的业务流程表达。许多更为细致的协作细节并没有清晰地表现出来,项目管理流程和招聘流程更是作为子流程被封装起来了。为了更为详尽地探索问题空间,这些业务流程也需要进一步得到呈现。从目标系统为参与角色提供服务的角度,我们通过服务蓝图结合业务流程图呈现了EAS的以下业务流程。[1]


q面向市场人员:客户合作的业务流程。


q面向项目管理人员:项目管理流程。


q面向培训专员:培训流程(培训需求是后续提出的需求变更)。



[1]    限于篇幅,本章只提供几个典型的业务流程。

相关文章
|
小程序 前端开发 Java
DDD实战之三:整体工作框架和全局需求分析(上)
DDD实战之三:整体工作框架和全局需求分析(上)
DDD实战之三:整体工作框架和全局需求分析(上)
|
供应链 小程序 安全
DDD实战之三:整体工作框架和全局需求分析(下)
DDD实战之三:整体工作框架和全局需求分析(下)
DDD实战之三:整体工作框架和全局需求分析(下)
|
项目管理
DDD案例(1):从需求分析到领域分析(4)
DDD案例(1):从需求分析到领域分析(4)
426 0
DDD案例(1):从需求分析到领域分析(4)
|
供应链 安全 领域建模
DDD案例(1):从需求分析到领域分析(6)
DDD案例(1):从需求分析到领域分析(6)
328 0
DDD案例(1):从需求分析到领域分析(6)
|
数据可视化 Java 程序员
DDD案例(1):从需求分析到领域分析(3)
DDD案例(1):从需求分析到领域分析(3)
292 0
DDD案例(1):从需求分析到领域分析(3)
|
项目管理
DDD案例(1):从需求分析到领域分析(2)
DDD案例(1):从需求分析到领域分析(2)
317 0
DDD案例(1):从需求分析到领域分析(2)
DDD案例(1):从需求分析到领域分析(5)
DDD案例(1):从需求分析到领域分析(5)
234 0
DDD案例(1):从需求分析到领域分析(5)
DDD案例(2):从领域分析到代码实现(2)
DDD案例(2):从领域分析到代码实现(2)
309 0
DDD案例(2):从领域分析到代码实现(2)
|
领域建模
DDD案例(2):从领域分析到代码实现(6)
DDD案例(2):从领域分析到代码实现(6)
235 0
DDD案例(2):从领域分析到代码实现(6)
|
安全 数据安全/隐私保护
DDD案例(2):从领域分析到代码实现(7)
DDD案例(2):从领域分析到代码实现(7)
254 0
DDD案例(2):从领域分析到代码实现(7)