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

现象

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

反思

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

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

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

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

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

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

改进