周五,有幸主持一次部门内每周一次的需求评审会议,第一次做这件事情,所以决定还是按照原有的会议流程来。会议需要需求相关方,PD和技术人员参与,主要是产品技术负责人,针对业务方提交的下周需要开发的需求,统一review,决定是否可以进入到开发流程。
这次需求评审,共有8个需求,涉及到认证线实地认证和个人认证,公司库,认证中心等四条产品线,所以技术人员共有5名参与,外加2名测试部门代表。会议从10点30开始,持续到12点左右,平均一个需求讨论10来分钟。说实话有点长的,作为主持人,从现场来看,归纳一下下面几点原因:
1。会议开始,切换屏幕,计算机调试花了一点时间-------- 应该提前准备;
2。会议中,需求讨论时,大部分都在热身,和PD沟通熟悉需求;
3。相关之间讨论实现方案;
现在回想了下,对于这种讨论形式,应该可以缩短点时间的,考虑如下:
1。大部分的时候都花在讨论实现方案上面了。那么会议上面要不要讨论实现方案呢?要的,但不是主要的,也不是随意的,如果要缩短时间,我考虑可以这样子,PD提出需求后,主要技术人员考虑实现方案,能够马上确定的,就直接说出实现方案,并给出时间评估;不能够马上确认,涉及到其他没有来会议的人员或者不确认的逻辑的,线下处理,并回复确认邮件。
2。会议前期,提前发送下周需求通知,技术人员先看下,不过感觉可能看得人很少;可以考虑和每个人5分钟之类的规则结合起来做;
3。会议主持人,要有点主持会议的准备,如果不够熟练,最好提前点时间到达会议现场;