哲学驱动设计

12月反思 - 组内设计评审会议

现象


    这个月我的工作任务中,有一项是重构OEA框架中的AutoUI部分。这个任务在月初时计划在一个月内完成,包括问题分析、设计新的结构、编写设计文档、开展设计评审、代码实现。原计划半天到一天的评审会议,最后花费了大概一天半的时间。接下来,我就评审会议中出现的问题进行一下总结。

    本次AutoUI设计是我到公司以来,觉得最有挑战的一次工作。
    会议之前,我和组内的人员进行了多次沟通,了解他们的需求:我们的AutoUI框架当前有些什么问题?当界面需求被提出后,我们对它的完成情况怎么样?开发人员对AutoUI有什么期望?测试、需求人员对AutoUI有什么期望?布局有什么问题?期望的GIX4界面是什么?
    接下来的几天时间就是不停的对系统进行设计,好几个问题都是在睡觉的时候想明白的。:)
    然后,我们召开了设计评审会议。
    参加会议的人不多,但是其间出了许多问题,最显著的有以下几个:
1.没有把要解决的问题讲清楚。
    *开始设计审查后,发现原来还有人不明白之前的问题。所以又倒退回去解释要解决的问题。
    *有人得出对审核的问题不清晰,并提出每个问题都直接进入技术主题,脱离业务,无法直观地联想到GIX4相应的业务细节。
    *有人得出一次审核的问题不要太多。
2.有人得出应该给在之前就对评审成功后接下来任务进行计划、估时等。
3.我没有把我自己设定的假设标记出来。
4.大概只有15%的时间是花在设计的审查上。
5.给大家讲清楚设计的过程较为困难。

 

 

反思

 


 

1. 听众对问题的理解程度不一。
    评审之前,我的想法是,由于之前已经做过几次现有问题的沟通,大家对问题已经比较理解了,评审的主要目的是评审我的设计。内容应该是:检查它是否能达到大家的期望,检查是否有遗漏、不足、错误,讨论一下是否有更好的设计方案。另外,我非常想在这个月内完成这次重构,而要完成从分析到实现、测试的整个过程,一个月的时间是非常短的。所以我在设计完成之后,立刻召开了评审会议。我并没有对评审会议进行计划,PPT也没有写,没有分析与会人员的期望,冒冒失失地就召开了评审会议。
    主观上我认为“之前这些问题已经讨论过了,没必要再重复”,所以我很快地把问题都过了,尽快开始设计的审查。但是由于之前讨论问题的人员和现在参加评审的人,并不是完全相同,所以导致过程中不断地被提问:“这个问题是为什么出现的?”、“它的业务场景是什么?”、“问题不要太多,最好一个一个讨论。”……
    出现这种情况的本质原因就是我把解释问题的环节过得太快了!之前我应该想到,评审开始时,最重要的评审人员是哪些,他们对这些问题是否和我已经达成了共误,如果没有,我应该如何给他们解释。换句话说,由于没有分析与会的人员,所以就武断地忽略了解释问题的必要性。

2. 问题确实可以分解。
    本次重构中其实还包含别一个较小关系的模块重构(MVVM模式)。把它加进来一起讨论的原因也简单:该模块比较小,没必要专门开一次设计评审;我想在AutoUI重构时把这个问题也解决了,毕竟,MVVM模式解决了,AutoUI做起来也会更流畅一些。

3. 没有解释清楚自己的设计。
    这也是一个很严重的问题。我之前粗浅地认为,到时只要对着设计稿先讲一下总体的结构,然后一个子模块一个子模块地讲解,就可以解释清楚了。但是还是没有达到预期的效果。主要原因是:还是因为内容分解得太快,这次再加上一个更抽象的结构图,效果可能会更好。(限于篇幅,具体方案我会另起一篇文章来分析如何讲解自己的软件设计稿。)

4. 对评审会议的认识问题。
    我对问题已经达成共识的假设、对评审会议内容的理解错误,都造成了沟通不便。引用周哥的话说,“评审也是沟通的过程”、“你清楚的别人不一定清楚”、“设计过程也需要给我们说清楚”。只有结果是不够的。

5. 没有做评审通过后的任务计划。
    这个其实也算是对评审会议的理解有误。评审会议不只是评审!应该还包括其后具体的任务计划。而不应该认为,“如果评审不通过,这步就浪费了。”其实这一步需要的时间不多,完全可以抽出时间来完成它。这个步骤应该放在评审之前就完成,以方便大家对未来要做的任务有一个清晰的认识,也反过来更好地理解整个设计。

6. 没有对评审做准备工作。
    就算按照我之前的想法,大家进行进入设计评审环节。我同样没有在评审之前就想清楚:如何给大家解释清楚我的设计方案。
    这一点单独提出来再说一遍,是想对自己强调一件事:时间再紧,也必须要抽出时间来为会议进行准备工作;PPT可以不要,但是对整个会议的计划还是需要的,形式用公司的五环策划表就很不错。

 

 

改进


. 如果是第一次做某件事,最好向有经验的人先请教,了解整个流程。
. 在时间允许的前提下,一次只做一件事。
. 按照易理解的分解程度来分解你的内容。
. 谨记:急于求成可能会浪费更多的时间。
. 对重要的会议始终要进行策划。
. 分析你的参会人员。
. 设计评审会议不只是评审设计结果,还需要评审:问题、设计过程、之后的任务计划。
. 沟通的时候,要指明哪些是假设。

 

转载自 胡庆访http://zgynhqf.cnblogs.com/ ]

你可能感兴趣的:(哲学驱动设计)