如何描述好一个问题。
本周在几个不同的会议上,和不同的同事过问题清单,发现大家很少把问题描述的非常清楚。导致在复盘问题的时候,还需要不断的找到提问的同事询问,到底是什么问题。有些时候,我们能得到具体的答案,有的时候,因为时间太久,他自己也记不清楚了。
那么,如何描述好一个问题,才能够减少沟通?
就像我们上学的时候写记叙文,有六要素,时间,地点,人物,事情的起因,经过,结果。对于描述问题,其实也是大概这么个套路。
- 问题发生的时间,记录时间的用途在于可以用于追溯在那个时间范围,是否有相同的问题发生。
- 问题发生的地点,可以是所在的办公室,具体操作的电脑,使用的哪套系统。
- 与问题有关的人物:操作人员,操作账号
- 事情的起因:就是我们要有什么样的业务,准备开始在系统里面做什么操作。
- 事情的经过:这一部分是需要重点描述的。在做PPT的时候我们知道,一图胜千言,在描述问题的时候,如果用图来描述,也有同样的效果,如果有相关的视频,可能会更加直观。用SAP系统举例,事情的经过包含以下几个重点内容:
a) Tcode:操作的tcode是什么
b) 单据编号:比如采购订单号、销售订单号、凭证号等等
c) 录入内容:在哪个字段,需要录入什么样的信息。
d) 错误信息:这个最好是有全面的截图,以及对应的操作,比如是鼠标点击,回车,或者其他的操作。 - 事情的结果:这个是留着要给后续问题关闭的时候用的。如何解决的问题,是改了开发,还是改了配置,还是用户操作顺序问题等等。
我想,这样记录下来的问题,多半是不需要再找提出人去确认的。如果可能的话,接到这个问题的人自己会找相类似的环境,去测试,或者去复现,看同样的数据和操作,是否会出现同样的结果。
最好,后面还有个“反思”或者延伸思考,如何避免这个问题。
这样记录问题,虽然繁琐,但是能够将问题完整的记录下来,对于其他人也会有比较好的借鉴意义。
一个好的知识库,就是通过一个一个问题,不断的积累,才能够最终构建起来。
网友评论