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可以不要,但是对整个会议的计划还是需要的,形式用公司的五环策划表就很不错。

改进

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

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏BestSDK

3分钟让你分清,数据管理与数据治理的区别

 数据管理和数据治理有很多地方是互相重叠的,它们都围绕数据这个领域展开,因此这两个术语经常被混为一谈。   此外,每当人们提起数据管理和数据治理的时候,还有一...

3285
来自专栏PPV课数据科学社区

微信官方数据披露:什么样的文章更受欢迎

PPV课大数据 拥有4.68亿月活跃用户的微信,早已成为媒体和自媒体信息传播的重点社交渠道之一。但你知道用户喜欢在微信上阅读哪些文章,又喜欢如何阅读吗?今天为你...

2855
来自专栏数据的力量

微信官方数据披露:什么样的文章更受欢迎

2354
来自专栏镁客网

爆料称亚马逊将发布新设备,与自家投资的智能家庭对讲机公司对打

1293
来自专栏BestSDK

再好的代码没有场景感受和用户痛点,都是一堆垃圾

在浩大的软件世界里,作为一名普通程序员,显得十分渺小,甚至会感到迷茫。我们内心崇拜技术,却也对日新月异的技术抱有深深的恐惧。有时候我会思考难道在技术领域内不断紧...

29010
来自专栏腾讯大讲堂的专栏

微信官方数据披露:哪些文章更受朋友圈欢迎

拥有4.68亿月活跃用户的微信,早已成为国内媒体和自媒体信息传播的重点社交渠道之一。但你知道用户喜欢在微信上阅读哪些文章,又喜欢如何阅读吗?今天为你揭开几个关键...

2168
来自专栏程序员的知识天地

大牛告诉你,只有突破程序员思维,才不会沦为码农!

过去我曾一直认为程序员是依靠他们的技术在编程,也是因为技术使得程序员的水平有高低之分,但随着我写代码的时间越来越长,也接触到更多的程序员,我渐渐发现程序员们其实...

941
来自专栏Android 研究

PMI-ACP 敏捷项目管理2——敏捷12原则

在软件项目或者其他类型的有高变更比率的项目而言,严格的变更管理流程会带来很多问题。相比而言,敏捷项目管理允许变更的发生,比如极限变成(XP)提倡"拥抱变化"。敏...

5573
来自专栏程序员笔记

团队合作

1814
来自专栏CSDN技术头条

对于机器学习,到底该选择哪种编程语言?

开发者到底应该学习哪种编程语言才能获得机器学习或数据科学这类工作呢?这是一个非常重要的问题。我们在许多论坛上都讨论过这个问题。今天,我将给出我自己的答案并解释其...

3728

扫码关注云+社区

领取腾讯云代金券