思考的出发点:
1> 固定的流程和规范,可以保证事情可以完整地执行,但是人的创造性、激情等就会慢慢被消磨;而随着需求的不一样的,并不是每一次的需求会议都应该是千篇一律的。
2> 减少线下主持人整理需求、跟进需求的时间;
用PM敏捷的思想来考虑下:
1> 少做就是多做;比如有些操作在场景的不同下,可以做些调整,运行主持人根据情况自由调整环节是否需要进行;
2> 每次需求评审会议,有些人员所有需求都需要参与,可以说是瓶颈资源,要让他们不在关键路径上;
3> 充分调动集中参与会议人员的时间与注意力,考虑多线程迭代、并行进行;
敏捷开发中有个快速沟通的方式,就是通过看板的方式,通过这种方式了解每个单元需求的进展和完成情况,提前发现项目中问题;那么会议过程中,其实也可以提取准备一个简单的看板,在一定的时间内,需求和资源人数都是固定的,考虑如下问题:
1> 那些业务线已经有多少需求进行中,业务指标如何?
2> 有多少资源可以投入进去,优先级怎么样?
3> 评估时间多少,业务方期望发布时间怎样?
以上问题,期望参加需求会议的人员可以直观的获取,了解需求价值,并对自身负责的事情做一个评估。而主持人就相当于PM的角色,每次需求评审,都能够达到业务和技术对于产品有交流和碰撞,而加深双方合作。
会议过程中,每条线或者产品,可以并行进行,比如A需求讲解后,A技术人员进行线下评估;B需求进行讲解,B技术人员进行评估;分批次和架构师确认后,自行写出评估时间,并讲述实现方案。相关方确认后,会议即可结束,下次会议再对上次需求情况进行跟踪确认。