前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >12月反思 - 组内设计评审会议

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

作者头像
用户1172223
发布2018-01-29 15:44:47
5050
发布2018-01-29 15:44:47
举报
文章被收录于专栏:哲学驱动设计哲学驱动设计

现象

    这个月我的工作任务中,有一项是重构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可以不要,但是对整个会议的计划还是需要的,形式用公司的五环策划表就很不错。

改进

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

本文参与 腾讯云自媒体分享计划,分享自作者个人站点/博客。
原始发表:2010-12-14 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档