技术评审会议“纪实”

gxp1980

技术评审会议“纪实”

深圳汉捷研发管理咨询有限公司　靖爽

以下情节，如有雷同，纯属正常。
望着满满一屋子的人，张强长长出了一口气——技术评审会议终于可以如期召开了。张强是宏大软件公司[1]的QA，这次评审会由他主持，回想起评审准备工作的艰辛，张强又默默叹了口气。
宏大公司的历史并不长，主要产品是电信设备的资源管理系统和网络管理系统，客户对这类产品功能和质量方面的要求是相当高的——当然了，电信设备影响到千家万户，出了问题可不是好玩的。宏大公司的产品原来还是不错的，当时公司有几个业务、技术的高手，并且在电信行业里摸爬滚打了多年，开发出的产品都会得到客户的认可；但是现在公司来了很多新员工，开发团队一下子“臃肿”起来，但是能力却不敢恭维，要命的是客户现在会提出一些“稀奇古怪”的需求，电信设备也不断的更新换代，所以宏大公司的产品质量一下子成了大问题。公司老板贾至强意识到产品质量问题关系到公司发展，公司特意在研发部门设立了QA的角色——这还是CMM培训的收获，之前大家都不知道“质量保证”为何物。
张强就是在这样的背景下走马上任的，尽管大家已经认识到质量保证活动对产品质量是有益的，但是在进度压力下仍然会超近路——这个项目在计划中本来并没有正规技术评审活动的安排，这次评审还是张强对项目经理王方“软硬兼施”争取来的，其实王方也知道评审的价值——至少书上都这么说；但进度太紧，对开发过程中“非重要非紧急”的活动只能忍痛割爱，要知道产品没有按时发布，挨板子的是他这个项目经理，而不是什么QA。确实是张强的“纠缠”感动了王方，当然王方也想看看评审究竟有什么效果，毕竟正式的评审对于宏大公司来讲还是新鲜事务。
“请大家注意，现在进行网管系统NMS V2.0的技术评审会，评审对象是本项目的概要设计文档，上周三我已经向各位评审专家下发了评审通知，从评审意见的反馈情况看，多数专家还是相当认真的，提出了很多问题，但是有部分专家 … …”
“是这样，我昨天刚刚出差回来，在外地没有收到邮件，今天才知道评审会就赶来了，以后的评审请尽量通知到我。”还没等张强说完，李利抢着解释到。
“我这几天一直在忙着Q3接口的技术预研项目，实在抽不出时间来；不过我还是浏览了一下评审材料，只是没有形成书面的意见。”赵刚也解释着。
“我提个建议啊，在评审初期开个介绍会议，请评审材料的作者给大家简单介绍一下设计思路和要点，毕竟我对这个项目不大了解，熟悉评审材料就花了我三个小时的时间。”
“我觉得也应该增加介绍会议。”有几个人表示赞同。
“大家的意见非常好，我在组织上确实有些问题，以后我会在这些薄弱的环节进行改进的。”张强进行了简短的总结。
其实他也有自己的苦衷，预审前的介绍会是他极力向王方要求的，不过王方认为实在挤不出时间，只能作罢；在评审专家的选择上也是煞费苦心：合格的技术专家目前都很忙，况且技术评审也不是人家“份内”的事情，参加评审现在不记在正常的工作量里面；最令张强担心的是目前邀请的专家中并没有人熟悉接口模块中MIB管理信息库，这是这个版本中新增加的重要功能之一，对此模块精通的专家袁力此时正在北京解决客户现场的问题，没办法参加评审。
王方认为合格的评审专家没有时间，可以发动新员工参加，毕竟他们有热情、肯学习，也许可以弥补业务上的缺欠，而且人多力量大，“三个臭皮匠顶个诸葛亮”——此次评审专家足足有二十人之多。
不过从反馈的评审意见上看却无法乐观，这些新员工尽管很认真，但对评审材料学习的成分大于评审，发现的很多问题是排版错别字、技术或业务的疑问等（当然张强也认为评审材料不太合格，单单错别字就足以说明问题了，但是王方认为“大事不糊涂”就可以了），没有发现材料中关键的问题；倒是几个技术骨干提出了一些中肯的意见——张强认为这还远远不够，根据经验其中应该还隐藏着大量的缺陷没有发现，但是没有以前的记录统计资料，张强也无法用数据指出其中的差距，只能寄希望于评审会上发现问题了。
“赵刚，先来谈谈你发现的问题。小李，你做今天的会议纪要吧。”张强知道赵刚是业务上的高手，而且素来谨慎，所以要求他最先发言。
“我在网管协议的选择有些疑问，在设计中使用SNMP的V1这个版本，估计是考虑重用我们以前的协议模块，虽然减少工作量，但是V1不支持大数据量的传送，只支持一个管理工作站，而且缺乏在开放的公共网络环境下运作的安全特性，这些特性上的限制无法支撑我们这个版本的网管系统；我建议系统支持SNMP的V2这个版本，可以支持大数据量的传送，目前这个版本已经成熟，而且多数新的设备已经提供了对V2的支持，至于V3尽管有加密、鉴权、访问控制等特性，但是设备商对此并未达成共识，所以并不常用，我们可以考虑在后续版本提供。”
“下一个问题，对于告警信息的上传，建议区分不同的优先级，否则容易造成信息风暴… …”
赵刚虽然只是“浏览”了一下材料，所指出的问题却使大家不断点头，也有人就某个问题发表一下自己的看法，这种吸引力也使负责记录的小李沉醉其中，直到张强敲敲本子提醒他做记录。
赵刚发表完了意见，孙旭就开始了。孙旭在公司效力多年，尽管战绩显赫，但他的火爆脾气却令同事敬而远之，就是公司的老大贾至强也对他无可奈何。
“数据配置这个模块是谁设计的？！都是什么年代了，可配置的数据类型还这么少，以前我们给客户配置靠MML（人机命令）就可以搞定，现在人家要自己配置，如果你还不知道客户的要求，到现场挨一顿骂就清醒了！”
“还有，设备类型匹配的算法居然使用逻辑链处理，真是笨了个灵巧！我们需要处理的设备类型比你吃的大米饭粒还多，用你的if、else、case写出来，乱的能让我把前天吃的都吐出来，我估计大学里也没学会啥是表驱动， 这都是大学胡乱扩招惹的祸…….。唉，算了算了，国家大事咱也管不了，对评审我就是这些意见，本来还想在会上共同切磋切磋，你们怎么都像睡着了似的！” 孙旭悻悻道。
实际上大家也都认同孙旭指出的问题，但是这种过于“刺激”的提法着实令人无法接收，所以都盼着他快快结束这种“震撼式的教育”，哪还会有人主动和他探讨问题。
李利和孙旭几乎是同时进公司的，对孙旭的话不以为然，接着孙旭的话题说，“就是你大呼小叫把我吵醒了，都是内部矛盾犯得上吗？昨天小泉又跑到靖国神社去拜鬼，也没见你这么激动过。”
孙旭本来已经坐下了，一下子又站起来，“就为这事，我昨天气得晚饭都没吃，实在饿的不行了就去喝了三瓶雪花。日本人实在太无耻了！”
“当年日本鬼子杀了那么多中国人，现在倒像是我们做错了什么！”
“我就是想不通东史郎这个老鬼子，怎么忽然成了我们的朋友？！”
“要是我能去日本，早就把靖国神社给砸了。”
“… …”
真是一石激起千层浪，本来几个坐在后面打瞌睡的也加入了声讨的行列。
“好了，还是回到我们的评审议题上来吧！” 项目经理王方实在不能容忍时间被这么浪费。
“… …”
“… …”
不知不觉，评审会已经开了三个小时，评审意见已经发表的差不多了，不过张强觉得还是有些意犹未尽，会上基本都是在确认预审时发现的问题，大家的评审意见都没有涉及到MIB管理信息库，通过会上“头脑风暴”所碰撞出来的新问题少之又少——这并没有达到他会前的预期。同时张强也发现这么多人参加的会议，常常是一个人在前面讲，其他人在下面听，经常发言也都是那么几个固定的，坐在后面的人开始的时候还算认真，后来就纷纷开小会了——下次一定不能找这么多人开评审会了， 5个人足以搞定。
张强正在为评审会的总结打着腹稿，会议室的门开了——贾至强匆匆走了进来。他刚刚完成了一个重要的客户会议，就赶来了。本来张强并没有邀请贾至强参加，主要是怕大家无法尽情的发表意见，但是他还是忍不住要过来；其实当年他也是技术方面的高手，产品早期的版本中还能够发现他的痕迹，只是这两年忙于业务和管理，技术也就生疏了。
看到贾至强，大家的表情顷刻凝固了——张强可没说老板要参加，正在侃侃而谈的工程师机械的咽了口吐沫：“我的意见已经讲完了。”
贾至强本来是想听听大家的评审意见，但是坐了五分钟，几乎没有人出声——只有负责记录的小李倒了杯水说“贾总，请喝水”。
贾至强似乎意识到了什么，就抬头问张强评审会效果怎么样。
“大家相当认真，提出了很多宝贵的意见，”
“那么，你认为NMS V2.0的概要设计文档质量怎么样，是否可以顺利进入详细设计阶段？”
大家的目光都聚焦到张强脸上，张强甚至可以感觉到项目经理王方独特的灼人的眼神。
张强用手抹了一下鼻尖上渗出的汗珠，看着王方，一字一板的说着：“我和王经理认为通过此次技术评审，评审材料已经基本达到标准，可以进入下一阶段；但是文档中还存在一些较大的问题和风险。”只是后半句声音太小了，以至坐在旁边的小李都没有听到，也就没有出现在会议纪要中。
贾至强当然也没有听到他的后半句，他点了点头，环视参加会议的人员，然后满意的说：“这次评审会开得非常成功，大家辛苦了，谢谢诸位，散会。”
大家鱼贯而出。
张强感觉有些沮丧和无奈，当然还有些对项目未来的担忧。等大家都走了，他最后起身收拾会议材料，将要关灯的时候，忽然发现赵刚还坐在角落了，没有离开的意思，“怎么还不走？”
“十分钟后，我们项目组还有一个评审会。” 赵刚头也没抬，只是揉了揉太阳穴。

技术评审常见问题及其解决方法
标记问   题后   果解 决 建 议
1.        项目计划中没有包括必要的评审评审仓促进行、或者可有可无，保证产品质量需要过分依赖于测试在项目计划中包括评审和跟踪修改的时间安排
2.        预审之前没有进行介绍会议评审专家需要花过多时间了解评审材料，效率不高评审专家对评审材料不熟悉时需要召开介绍会
3.        评审专家的选择没有覆盖到评审材料部分评审对象无人负责，评审不完整针对评审材料选择评审专家，需要覆盖完整，可以采取“轮查”的方法
4.        评审专家数量不合理容易导致评审专家责任心降低，影响评审效果专家数量一般为3～7人，选择专家时关注质量而不是数量
5.        预审安排不合理或者进行不充分数据显示预审可以发现90％的问题，评审会上只能发现10％的问题，“丢了西瓜拣芝麻”将预审反馈的问题质量作为可否召开正式评审会的重要标志之一
6.        问题没有记录无法对发现问题进行跟踪解决，评审没有起到作用指定专人进行记录、问题解决的跟踪
7.        没有建立评审要素表或者要素不符合公司的实际情况评审时无据可依，无法积累公司的研发资产，评审效果完全依赖专家个人能力建立评审要素表，并及时优化之
8.        缺乏评审的历史数据无法对评审质量、评审改进进行评估和管理搜集历次评审的数据，建立公司过程能力基线
9.        评审会上跑题或者陷入细节，没有及时控制评审效率不高主持人需要进行控制
10.     急欲给出问题的解决思路“在食物和性之后，人类最大的驱动力就是告诉别人如何去做事情”，但是在没有充分思考和了解全部细节时给出的往往不是最佳方案评审注重发现问题，而不是解决问题
11.     评审会时间过长或者评审专家在一天之内安排多次评审评审专家无法长时间集中精力，技术评审对普通人类精神聚焦的作用远远达不到老虎机和麻将一般两小时左右为宜，可以将一个过长的评审分成几个部分
12.     评审材料质量低劣评审专家无法聚焦于关键问题，而耗费在低级错误上，影响评审效果评审材料需要自检，评审组织者需要评估材料是否可以进行评审
13.     领导的不恰当参加领导的意见可以主导其他人员的意见，评审会成了“一言堂”尽量避免高层领导参加技术评审会，即使参加其身份也是技术评审专家


（汉捷研发管理咨询 靖爽）














                                                  




[1] 该公司老板贾至强非常崇拜微软公司，但是觉得Microsoft这个名字没有气魄，所以给自己的公司命名为宏大，意味着宏图大志，好多员工就是冲着这个名字才加盟的。

waterbay

太多问题集中到一个故事里，不够专注，也不利于大家从中受到启发和学习。

chrisgu

没看出什么来，像是在看故事书！