实战:我是怎么做互联网项目管理的?(如何做好互联网项目管理)

假设项目已经过商业论证并立项…

实战:我是怎么做互联网项目管理的?(如何做好互联网项目管理)

通常的项目阶段

互联网项目经理,和传统行业的项目经理很不一样。一般互联网项目经理都是生活在弱矩阵下,无权,意味着更多扮演的是协调者的角色,不用对最终质量负责,只要不是流程的问题。相对来说,工作内容少些,分工也算比较细。当然,不同的人对项目把控能力和影响力都不一样,弱矩阵下的项目经理同样可以有超强的团队影响力。本文重点分享我所在公司的项目管理流程,对影响力涉及较少。

我所在的互联网公司,有正式Title的项目经理分为两类:一类是深耕某条产品线的,一类是大项目管理部的,负责跨产品线的大小项目。有些产品线没有单独的项目经理,启动自管理模式,有些经理会直接兼任,其实这个效果还是不错的。

项目立项:一个大项目启动前,一般前期高层都会深入讨论的,决定做某个项目,实现公司战略。一般产品老大会安排某个领域的产品对接作为主产品经理,项目管理部核心领导组会根据项目的实际情况,安排改动较大的产品线所在领域的某位项目经理作为主项目经理。立项后的启动会自然是邀请相关干系人一起沟通,战略意义越高的项目,邀请的干系人级别越高,介绍项目的背景。此时一般对应的主要干系人都比较明确,包括各业务方(业务需求对接)、项目负责人(对项目的成败负责)、职能部门对接人(符合法律法规、财务结算等)、主产品(负责产品需求和验收)、架构师(负责系统架构和边界)、主技术(负责技术对接和协调)、主测试(负责整个测试联调)、主PMO(负责项目按期和整体按流程交付)等都确认下来。

需求评审:各产品线负责产品输出需求文档供小组评审。一般主产品会优先评估哪些领域有改动,联系对接领域的产品,一起评估对各产品线的影响。主产品(一般来自系统改动最大的领域)输出产品整体方案,这里要做的就是各产品线梳理系统改动点,确认主要依赖,有些产品线会依赖于技术介入,此时架构师一般也会介入,搞架构方案,评估改动点,包括通用组件,系统监控告警等。可以搞个各产品线改动点评估会议,毕竟改动点梳理不会太重量级,怕漏点而不怕多考虑,宁可错杀,不可放过。通过多人讨论(对系统了解深刻的人)有助于了解更多,尤其是影响大的项目。在梳理和对接完成改动点后,就到了各产品线出正式PRD阶段了。这中间可能有数次产品线专题对接,项目经理负责串联各干系人,组织会议,建立邮件组,微信群,不同领域工作组等,留意跟进事项进展,关注潜在风险,勾勒出里程碑,准备周报,商业需求和产品需求工具使用等。

项目排期:各系统完成需求评审后,就入产品线需求排期阶段。这个时候的大里程碑就非常重要了,让大家有方向对齐。当然大里程碑是基于关键路径的事件和领导期望的时间来的。一般大项目的发布都要跟App版本,App版本有相对固定的节奏,项目排期和里程碑会参考App版本,其实时间也就差不多固定下来了。只是改动小的产品线可能可以晚点,但改动大的产品线确需要严格执行,分批提测。用于指导各线排期的里程碑一般包括需求完成时间、开发完成时间、测试完成时间、联调完成时间、上线时间等,一些紧急的项目对应的应急计划也会随之出来,甚至立项前就出来。这里给出的时间是关键路径上的最晚完成时间,非关键路径产品线可以做微调,但以不影响整体节奏为基础。此时,产品线内的具体开发和测试才会比较清晰,识别干系人是一个逐步完善的过程。

开发阶段:有些团队还是走概要设计和详细设计,因为此时需求比较确定。技术负责人需要出整体技术方案,确定系统交互接口,用接口还是走消息队列,项目上会要求各系统的接口对接明确化,系统间有依赖的地方要确认接口提供时间,这也会影响到整体上线时间。这里开始前会有技术评审,架构师和各团队讲解下相关技术设计,确保上下游对齐,面对面沟通非常重要,明确输入和输出。对于紧急项目,一般都是分批提测,确保测试有足够的时间。有上下游接口的还会协同好进行开发联调,确保开发阶段接口能够按预期工作。一般架构评审也会安排在开发阶段进行。

测试阶段:开发阶段测试也在同步设计,并完成测试用例评审。甚至开始部分自动化用例撰写,保证测试正式开始时可以直接执行测试。功能测试在开发测试完成后冒烟测试通过后正式开始,有团队内测试报告,一般产品线内自己负责。一般功能测试进入到晚期,各系统联调就会开始,两两联调为主,需要的时候再进行超级大联调,保证各系统联调环境能够正常使用。如果有跨团队的问题不好解决,就会逐步上升,项目经理负责整体协调解决。大联调阶段一般会有测试报告,关注测试进展和问题,就是项目经理的本质工作了。一般安全评审也会安排在测试阶段进行,验收测试场景和运营场景也会在此时准备。

上线阶段:一些独立的产品线可以单独上线,而互相依赖的产品线,主要的产品线一般都会按火车头发布,会集中在某个上线周。上线周前会有上线评审,确保各系统依赖、环境变量准备、数据变更和上线顺序都提前准备到位,一些新系统还需要申请新机器。上线周初会把代码合并到主分支,有紧密联系的系统严格按照顺序进行。上线后产品经理组织验收,保证主要流程和关键场景在业务使用时功能正常。

运营阶段:按照运营计划,准备数据,观察运营效果,确保系统在线上运转正常。有时也会按照小规模试运营,一些重要功能会按照比例或者白名单等逐步放量,灰度过程中有问题需要紧急修复,快速上线。等运营一段时间后,分析运营数据,得到运营效果,证明项目的价值。不少拍脑袋或者使劲推的项目,可能上线后都不运营,或者业务价值远远低于预期,这无疑是失败的项目。当然,运营会反哺到需求,形成新的需求,迭代优化提升,形成业务闭环。

这就是我所在公司项目管理的全流程,估计不少公司都是这样,偏瀑布多一些,挑战性主要在于产品线多,干系人多,怎样在纷繁复杂的系统间全面分析,确保不遗漏主要场景和干系人,这对项目上线成功运营非常重要。当然,合法合规、客服安全等层面也需要考虑到。自然风险管理是贯穿始终的,问题大表、问题跟进、同步干系人、识别技术风险都会存在。至于上线后能否实现预期价值确实比较难说,涉及到很多因素,通常也脱离了项目经理的管辖范畴。一开始要求ROI和业务价值,到运营后衡量项目价值,其实是蛮有意义的一件事情,优先做高价值事情,也未尝不是一种变相的施压,让“所做的事情一开始就有价值”。

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

(0)
上一篇 2022年5月25日 上午9:57
下一篇 2022年5月25日 上午9:59

相关推荐