IT系统的各种需求,都是对甲方现有业务的的改变,这个改变可大可小。所有我们做需求分析的的时候,对于需求也要进行一次归类。

我们假设甲方的业务是一条流水线,从采购开始,到销售为止,有起点有终点,周而复始的不停运转。

流水线在运转过程中,有转移有加工,产生增值,为甲方带来利润。

和这条流水线相关的上有操作工人,有维修人员,有日常管理者,有高级管理者。

相对需求而言,可以分为如下几类:

1、Operation,操作类,涉及到操作工人、维修人员工作的变化。
这一类需求,将会改变流水线,操作不当容易产生工位瓶颈、库存堆积、良品率下降等等问题。操作得当的话,可以降低库存、提升良品率、提升效率、减少人员。
所以对于操作类的需求,务必谨慎仔细,在测试环境中进行完整的测试,并选择适当时机切换。

2、Monitor,监控类,涉及到日常管理者工作的变化。
日常管理者本身并不参与业务流程,但他们需要时时盯着流水线,确保流水线正常运转,并向上支持高级管理者的一些要求。
对于监控类的需求,通常是和Operation类需求进行配套的,但它有一个特点,就是其需求通常会变化,在Operation类需求完成上线逐步调整稳定期间,Monitor类的需求才能比较清晰的冒出来。
所以对于监控类的需求,会比较尴尬在于,Operation的改变已经完成后急需实现Monitor类需求,但在Operation完成前所设想的Monitor类需求很多时候是比较片面的纸上谈兵,需要做大的改动。
时间紧、改动大,Monitor类需求,前期需要业务专家的强力支持,后续需要开发的紧密跟进。

3、Performance,绩效类,涉及到高级管理者工作的变化
高级管理者对于流水线部分,关注的不是日常运转,而是其绩效和利润部分,所以他们需要看的是运行状态、运行结果、达成情况、风险点、未来计划等等。
上述的需求,通常采用Report、Dashboard实现,规模大的公司,通常有自己的DataLake、BI的统一实现方案。
相比Monitor而言,此类需求会更靠后发生,还会时不时改变。
所以对于绩效类需求,建议都让甲方放到其自身的DataLake、BI中统一实现,而不是各自独立实现。

4、Other,其他类,泛指不在上述3类需求范围内的,目前我想到的只有 IT部门对于IT系统自身管理的需求,例如安全、备份等等。

发表评论