反思——原型界面搭建

大约一年半之前的原型界面搭建过程,挑选了ligerui作为搭建工具,当时的想法是够重型,所有的控件都提供好了,所以可以实现快速开发。

但还是花费了大量的时间在处理一些技术细节上,印象最深的是左侧菜单的组织形式,是先按照用户级别分,再按照功能模块分,还是反过来。实际上,在后期需求渐渐明确后,当时的很多考虑都是不合时宜的,大量的时间就被浪费了。

需求获取过程,还是要尽快的接触用户,至于原型界面搭建方式,ligerui在技术层面已经很完善了,但仍然不如拿纸笔画草图来得快和方便。

工作流程描述方法

有人说过,软件工程领域,不严格的说,需求调研过程还不属于“工程”而属于“艺术”,即没有工程化的手段和方法完成此项工作,需要工作人员的创造力,概率性的进行此项工作。本文的目的在于,总结需求向设计转化的思路和方法,力求为将此过程达到标准化提供帮助。

需求调研的直接结果,一般为当场的会议记录,收集到的资料、报表等。对于这些调研成果,归纳的第一步应为整理备忘录,基本要求为涵盖所有细节。而备忘录书写完成后,就要据此进行系统性的整理,将条目分类整合,剔除不必要的细节,对工作进行建模,为后续的设计提供帮助。

报表类的工作,本身的重点在于报表数据的逻辑,归根结底是数学问题,容易处理。而由报表引申出其他工作的方法,可以参考这篇的描述。

流程性的工作掺杂的实际因素较多,不能像报表逻辑能直接转化为数学公式,因此需要一定的建模方法对其进行描述。以下,是实践中对一项工作过程建模的讨论过程。

原始工作描述

考虑如下的工作流程(只考虑正常流程),群众甲办理某证件。经过调研,需求提供放的工作手册一般都为如下的形式:

  1. 群众甲携带相关材料,到某部门作办理某证明1
  2. 工作人员A审核相关材料通过
  3. 工作人员B审核相关材料通过
  4. A开具某证明1
  5. B开具某证明2
  6. 甲携带证明1、证明2,到另一部门办理证件
  7. 工作人员C审核证明1、证明2通过
  8. 工作人员C办理证件
  9. 甲签名
  10. 甲携带证件离开,办理过程结束

这种形式是在工作角度进行描述,同时具有群众办事指南和工作人员办事指南的性质,并且面相的工作人员也是不同部门的人员。因此,这种描述并不能直接反应为功能模块的设计。

划清系统边界,从工作人员或称工作系统的角度描述

为了便于区分,先增加两个假设条件:

本系统为内部办公系统,不提供办事群众直接使用的功能。

该项工作,工作人员A、B所在部门并不属于此次开发最终成品系统的用户。

则系统的唯一用户为C。

从C的角度描述该工作,则1~5步与C并无关系。工作流程变为:

  1. C处于等待状态中
  2. 甲到该部门,办理证件
  3. C查验甲是否携带了真实有效的证明1、证明2
  4. C为甲办理证件
  5. 甲签字
  6. 甲携带证件离开,办理过程结束

这样的描述,可以直接对应设计过程中,系统的一个功能点。涉及到C的每一步,都可以视作系统中的一个表单,通过点击“下一步”按钮,达到下一步骤。

发现问题:遗漏信息

由于当前项目的开发目标除覆盖工作外,还包括力求创新,因此需求调研人员指出,按照以上方法总结的文档,丢掉了步骤1~5,如果以后需要对业务流程进行再造,或扩大系统用户范围,则这种方法则会损失有效信息。

经讨论,对该问题的暂时解决方案确定为:

同时以工作的角度和工作角色的角度总结两份工作流程说明文档。

发现问题:挂起恢复和过于琐碎

去掉以下假设:

该项工作,工作人员A、B所在部门并不属于此次开发最终成品系统的用户。

则系统需要整理A、B、C三个人的工作流程。C见上文描述。A、B二人的工作为穿插进行,有两种整理思路:

  1. 涉及到A、B二人审核材料、开具证明的4个步骤总结为一项工作的4步流程
  2. 4步流程总结为4项工作流程,每项工作流程都类似于:等待;A/B通知B/A作审核/开具证明工作

采用思路1较为简单。但在实际中,A、B二人的工作并不总是单线程的,在A等待B的过程中,可能会去做其他工作。所以据此设计的功能模块中,就无法体现将前一个流程挂起,进入新的工作的思维,会造成在实际中无法使用。

采用思路2,与实际接近,但划分过于琐碎,缺乏概念的完整性。并且,对应的设计方案也会导致功能点膨胀,系统复杂的情况出现。

解决方案:回到多角色描述,增加每个角色的状态描述

参考操作系统中的进程状态模型,将每个参与工作的角色的状态定义如下:

image

此时,工作描述变为:

序号 工作描述 A B C
1 群众甲携带相关材料,到某部门作办理某证明1 进行 未开始 未开始 未开始
2 工作人员A审核相关材料通过 挂起 进行 未开始 未开始
3 工作人员B审核相关材料通过 挂起 挂起 进行 未开始
4 A开具某证明1 挂起 进行 挂起 未开始
5 B开具某证明2 挂起 结束 进行 未开始
6 甲携带证明1、证明2,到另一部门办理证件 进行 结束 结束 未开始
7 工作人员C审核证明1、证明2通过 挂起 结束 结束 进行
8 工作人员C办理证件 挂起 结束 结束 进行
9 甲签名,C审核签名 进行 结束 结束 进行
10 甲携带证件离开,办理过程结束 结束 结束 结束 结束

按照这种方法总结,针对每个角色的一列,都可以设计关于此角色的功能模块,并做到直接对应。

另:这10步工作流程应予细化,一般情况下,每行应只有一个“进行”。如果出现了多个“进行”,则表明出现了并行处理的情况,应与实际工作对应,是否有明确的并行概念和并行关系。如果没有,则尽量简化为单线程工作。

报表调研要点

在需求调研过程中,由于被调研对象一般来说并不具备信息系统实施经验和程序设计基础知识,并不能提供完全符合开发逻辑的工作描述。一个较为常见的情形就是,某工作人员拿出成堆的报表,表示这就是我的日常全部工作。因此,从报表入手进行需求调研,是实际工作中的一个较为无奈的选择。

从另一个角度讲,在需求调研人员的个人能力和场面控制能力没有远高于被调研对象的情况下,很容易在天南海北的聊天中被带离既定的思路。如果能先得到相关报表,再从报表出发逐项进行调研,也不失为一个效果良好的调研工作方式。

就经验来看,报表是衡量工作成效的重要指标。由于政府部门的特点,很难做到岗位职责分明,也很少见有正规有效的工作日志制度,因此对日常工作没有很好的记录,也很难再现。在这种情况下,报表几乎成为了考察工作是否完成、完成得怎么样的唯一指标。更进一步,工作完成情况的体现形式也大多为报表。所以对于报表的调研,应作为需求调研工作的难点和重点看待。

由于当前对一般工作制度的了解还不够深入,不能完全概括报表在工作中的作用。应在需求调研工作中逐步加深对报表的理解。

对于报表的调研,不能只局限于报表数据本身,否则据此设计的系统将会沦为“数据库系统”。应当在调研中获取足够的关于报表所体现的业务流程的信息。在针对报表的提问模板中,为了达到提供足够信息的目的,将要点初步归纳如下:

  • 报表名称
  • 填写人(或填写人所属岗位)
  • 上报去向
  • 原始数据来源
  • 报表数据从原始数据的计算方法
  • 填写频率
  • 触发条件(每n个月填写一次,有xxxx情况发生时填写一次等)
  • 表内、表间逻辑关系
  • 最终存放地点
  • 被引用情况
  • 政策依据

对于以上要点的调研结束后,每张报表都可以归纳出相应的工作流程,大部分情况应为多个流程,如填报工作、上报工作、计算审核工作等。对于每项工作流程,都可以按照工作流程相关的模板进行整理。

采用这种调研方法后,既有了调研起点,又能充分的了解工作,最终有利于信息化方案的提出。