医疗实施-项目管理04-需求调研

1.调研前

1.1 规划干系人参与与沟通

根据《医疗实施-项目管理03-项目启动会》,了解了客户参与人员与层级关系,那么针对不同的干系人要让他们进行不同程度的参与、沟通。根据我的项目经验,主要把干系人分为以下几种类型、参与场景与沟通模式。我将按照从小往上的层级进行介绍

操作用户-普通用户

以医疗系统为例子,操作用户一般是医生、护士和操作员。他们比较关注的系统的便利性和易用性。对业务流程的单个节点的操作是否方便比较重视。他们比较关注具体的功能与流程的实现方式。对系统的易用性关注比较高。因此我们简单列举一下他们对我们的机会与要求
机会

  1. 提供某个场景具体的业务流程描述与功能需求。
  2. 是我们系统在实际使用的主要参与人,积极参与系统调研与测试,能给出我们有效和全面的反馈。
  3. 正确的关键底层用户的积极参与有利于构建客户对我们的信任,针对客户来说的项目亮点,从而加强客户与我们的沟通。

要求

  1. 对系统的易用性较高,界面和操作尽量有助于他们实际工作。
  2. 系统的操作方式尽量符合他们习惯,如果之前用过别的系统,需要重点关注自己系统与老系统差异点,提前核对有没有老系统能解决,但自己系统解决不了的情况,提前设计解决方案。
  3. 由于底层用户多且每个人风格,往往期望希望在有助工作的情况下能进行一些自定义配置。

主要事项

基于以上三方面,我觉得应该按一下要求设计对底层用户的参与与沟通模式
参与方面
1、引导其积极参与需求调研,并在需求调研中使用场景描述,让他们具体描述他们的日常工作的业务场景。可用的方法有问卷调查、场景模拟,如果有老系统的话,可以他们进行老系统的模拟演示,以方便对比和设计。
2、调研后针对需要重点实现的需求,在实现后最好提前在某些关键用户面前介绍使用,获得认可之后再进行推广,以免大范围的推广后发现问题影响客户信任。
沟通方面
1、与底层用户沟通的时候,最好不要采取私下一对一沟通,而是要将实施方、用户与业务领导一起沟通,这样避免用户提出一些低质量和垃圾需求。
2、用户往往会会根据自身情况通过表层的语言去提出一些原始的业务场景,如果用户直接提出的原始需求,我们应该进一步去联系相关业务领导去核实和提炼用户需求。

操作用户管理层-业务部门与信息部门领导

用户的直属领导,由他们制定用户每个流程的各个节点,他们既要用户便利使用,又要保证整个流程的稳定性和安全性。同时他们又是跟客户高层管理对接的桥梁,负责协调和参与管理层与乙方的对话。
机会

  1. 能够抓住系统在实现某些业务场景出现的核心问题,以及提出业务场景的核心关注点。
  2. 是决定我们系统验收的负责人,系统针对业务场景所提供的交付物能否满足医院要求。
  3. 一般会与我们长期合作,需要建立长久良好的合作机会。

要求
1、对业务流程的整体把控要严格,对下满足用户使用,对上方便管理层管理,并为管理层运营提供数据支撑。
2、要求系统必须满足自己的基本需求,尽可能满足自己的亮点需求。

主要事项

基于以上三方面,我觉得应该按一下要求设计对业务部门领导的参与与沟通模式
参与方面
1、及时汇报项目进度,分享解决问题的思路与方案。大多数业务部门领导都想了解自己部门业务信息化程度,知道自己部门复杂的场景如何通过信息化实现管理,从而提高部门办事效率。最重要的是信息部门,项目前期他们往往也需要向高层进行成果汇报,因此需要我们去及时的把项目情况以及相关风险进行告知,让他们协助处理。在项目后期移交运维的时候需要保证信息部门自己能处理系统日常问题,以及系统的功能范围,所以要重视在项目参与过程中随时进行知识移交。
2、要随时进行信息共享,某些复杂的业务场景要让所有业务部门与信息部门参与讨论,从而达成共识。业务部门之前的需求往往相互冲突,矛盾,我们要结合实际项目情况,各个业务部门领导的权利、利益、期望与职能进行讨论,帮助他们达成共识,保证在实施过程中各个部门领导能够提供帮助。

沟通方面
1、建议使用正式沟通与非正式沟通,与普通用户不同,适当使用私下沟通的方式,从而拉进与业务领导人的关系,从而获得领导支持。
2、针对正式沟通如书面需求确认单、会议纪要确认的需求等,及时做好备份,如果后期有变化及时通知相关方。

领导管理层-领导

管理层所具有的特点是相关人员日常繁忙,希望通过便利的数据展示,方便他们快速了解自身经营情况,方便他们快速针对现状的问题与现象提供解决方案。他们所关注的是系统更高层次的抽象关系的联系。简单来说,就是想通过企业的经营业务场景所涉及的关键指标的具体数据,来快速针对经营情况给出评价,并对自己改进猜想提供数据支撑。他们关注的管理指标的统计方法是否合理,指标如何实时展示。
机会

  1. 管理层是我们项目推动的最大助力,得到他们的认同与帮助,是项目成功的必然条件之一。
  2. 管理层只追求宏观的需求,可以灵活完成他们的需求。

要求
1、他们一般对系统自身的数据统计,流程管理较为关心,希望系统能够提供便利的管理与统计方案
2、他们的定制化需求和重点需求必须完成

主要事项

基于以上三方面,我觉得应该按一下要求设计对管理层的参与与沟通模式
参与方面
1、在调研阶段对他们的需求要重点管理,由于他们往往提出的是宏观的需求,因此需要和业务管理层一起配合,调研出详细的需求描述和可交付成果标准。让他们重点参与关键会议,对于过程中他们提出的意见和反馈要迅速与相关干系人沟通确定,尽早处理。
2、可以和甲方项目经理一起调研,从而获得一致同意的需求说明。

沟通方面
1、与甲方项目经理确定沟通方式,根据管理层需要,定制他们的沟通方式,及时尽早配合甲方项目经理与管理层沟通。
2、对于管理层提出的需求和问题及时解答与反馈(尤其是医院指标的口径与统计方式),确保整个项目获得管理层支持。

1.2 预估需求导致的风险

我们可以根据启动会和项目章程的去预估调研过程中可能出现的风险,提前应对措施,常见的风险分类如下:
系统功能风险

  1. 提出合同范围外功能
  2. 现有系统无法实现的功能
  3. 客户认为功能实现的模式与系统实际功能不符合

干系人风险

  1. 干系人不支持不参与项目调研
  2. 干系人需求调研时,干系人内部对同一个流程的观点与设计存在冲突
  3. 干系人对系统期望超出合同范围
    这些相关风险,我将到下一篇<医疗实施-项目管理05-实施阶段-风险应对>中详细去讲。大家可以提前在调研前列出这些风险,在调研前设计好应对方案,从而保证风险发生从而产生问题时,能及时的去解决和纠正问题。

2.调研中

2.1 常见的调研方法

这里简单介绍一下常见的调研方法与内容

  1. 问卷调查:可以将项目中普遍需要要调研的内容写到一份文件中,根据文件内容让客户填写,或者向客户提问。特点是能够快速完成,受众多样化。
  2. 访谈:针对关键干系人,进行一对一访谈,打消他的顾虑和担忧,让其畅所欲言,充分收集干系人的需求与想法。
  3. 焦点小组:有同职能,相似背景的干系人或者主体专家互相交流,让主持人进行引导互动,帮助大家确定某问题的最优解决方案。
  4. 标杆对照:可以找到同行业或者不同行业,具有最佳实践方法,参考进行调研。

2.2 常见的调研内容

大体可以分为5个部分

  1. 用户部门组织结构及人员分工
  2. 用户业务流程调研(根据产品设计,一般分为门诊和住院流程,然后根据处方、费用、病历等层层细分各个流程)
  3. 打印模板调研
  4. 接口调研
  5. 定制需求调研

3.调研后

调研后,根据收集的需求文档,需求跟踪矩阵与范围说明说。

  1. 需求跟踪矩阵:包括需求描述、目标、可交付成果、需求相关方、设计开发人员是谁
  2. 范围说明书(有时称方案蓝图):包括项目范围,可交付成果标准,假设条件与制约因素。
    其中范围说明书需要由相关业务部门对里面各自的系统实现范围与功能清楚了解,并签字确认,从而保证后期实施不会超出此范围,进而能保证项目人员整体把握进度。为后期的进度规划和成本规划做基础。

最近更新

  1. TCP协议是安全的吗?

    2024-06-08 16:54:03       18 阅读
  2. 阿里云服务器执行yum,一直下载docker-ce-stable失败

    2024-06-08 16:54:03       19 阅读
  3. 【Python教程】压缩PDF文件大小

    2024-06-08 16:54:03       18 阅读
  4. 通过文章id递归查询所有评论(xml)

    2024-06-08 16:54:03       20 阅读

热门阅读

  1. c#通过sqlsugar查询信息并日期排序

    2024-06-08 16:54:03       8 阅读
  2. 什么是Redis?|介绍与使用及特点浅记

    2024-06-08 16:54:03       7 阅读
  3. VFS:8.fd管理-fs/file.c源码阅读

    2024-06-08 16:54:03       8 阅读
  4. src&href,fetch&ajax,cookie&session

    2024-06-08 16:54:03       8 阅读
  5. 设计模式之原型模式

    2024-06-08 16:54:03       5 阅读
  6. 计算机网络时延计算的单位换算问题

    2024-06-08 16:54:03       8 阅读
  7. 基于MBD开发汽车软件

    2024-06-08 16:54:03       8 阅读