新闻动态
NEWS CENTER
NEWS CENTER
2020-11-11
之前都是各团队的零散的沟通,是时候把大家拉到一起做一个正式的立项大会了。有些读者可能会问,不会吧,现在才立项嘛?
因为根据之前的拆解需求,和各团队的反复沟通,才能确认各端是否需要参与、以及最终的方案是什么,甚至因为实现成本等问题,最初的需求都会发生一些变化。
否则在不了解各端的情况下,先拉上20个团队一起立项要做A需求,最后聊完发现只需要4个团队的参与做B需求,会极大的降低团队可靠程度。
那么,立项大会需要跟大家聊啥呢?
理论上,会议上不应该有特别复杂的讨论,只是公布方案,拉齐认知,更不要临时发现缺少某个关键部门的参与,这些都应该是上一环节没有讨论清楚,请反思总结。
当会上大家都默认没有意见后,此时项目就已经成了60%以上。那我们就接着推进吧!
有立项大会还是否需要进行项目整体的需求评审呢?根据笔者的个人经验是需要的。立项大会后,给各团队一些思考的时间,消化需求,确认风险,人力安排,项目优先级调整等。
一般就安排在立项大会的第二天或者第三天,拉齐之前各部门的对接人进行需求评审。
评审主要是快速把整体产品方案再过一次,作为主产品,要给最终解释;以及各端遇到的新问题,比如测试数据,配置规则等,收集好后,再单独跟各端进行反馈。
项目需求评审后,各端就要正式进入到各自的研发阶段。此阶段如果有PMO参与,则需要由他们来保证项目的推进,如果没有则主产品也可以来做以下事项:
由主研发和主测试同学去确认之后的项目联调方案:
最后需要和主研发一起,制定多端上线顺序。这是跨端项目与独立项目最大的不同,独立项目所有上线流程都是部闭环,上线依赖发生在项目内部。跨端项目则需要核心团队根据团队之间的依赖关系,设计好上线顺序。
举个简单的例子:商品的付费购买功能与商品的使用功能,谁先上线?如果付费功能上线的一瞬间,有用户下单,但功能还无法使用就可能造成重大的线上事故。
当这个顺序拓展到十几个部门的上线后,将会产生更多的连锁反应。
到此,项目90%的工作基本完成。只是项目上线交付给业务去使用,真正给到更广大的用户使用时,会有更多的问题暴露出来。作为项目的主产品经理,以及最了解项目的人,遇到问题可以最高效的分发到对应团队,避免问题扩大化。
笔者之前遇到过主产品离职的大型项目,一个工单扭转十几个部门不知道谁来承接的情况,错失了解决问题了良机。
其次主产品需要对各团队项目数据的进行验收,这是量化各团队和最终项目收益的主要指标,要保证大家的劳动成果。如果有问题,找到相应的团队及时修正。
及时复盘项目,梳理各部门的职能,并对项目中的方案进行评估,提出改进方案。比如临时方案迭代成持久化的方案,手工方案改自动化方案,写表方案改管理后台方案等。
最终,需要确认收益,和大家共享成果。
1)问题一:因为边界的模糊,同样一个功能,A和B都可以做,那么谁来做?
笔者这里给出一个参考答案:
首先,需要跟主研发进行讨论这个项目未来可能的项目架构,即此功能谁最适合长期维护;其次,谁能够不耽误项目进度,在当前的情况下,选择效率更高,成本更低的方案;最后,通过此功能,未来谁的收益更大。如果依旧不服,向上反馈。
2)问题二:很多业务需求未必与需要配合团队的业绩产出所匹配,如何给大家一个信服的收益?
首先确认需求拆分到的团队是否匹配,是否有分配错误的情况,这一点在沟通需求的环节就要消除;其次,拿项目的测试数据说话,拿之前的历史数据说话,保证项目收益,以提高优先级;最后,如果对方还不满意,找到对方的领导进行沟通,将项目上线写入相应同学的业绩考核指标中。
3)问题三:如果项目反复进行,还是否需要如此繁琐的沟通?