假设项目已经过商业论证并立项…
通常的项目阶段
互联网项目经理，和传统行业的项目经理很不一样。一般互联网项目经理都是生活在弱矩阵下，无权，意味着更多扮演的是协调者的角色，不用对最终质量负责，只要不是流程的问题。相对来说，工作内容少些，分工也算比较细。当然，不同的人对项目把控能力和影响力都不一样，弱矩阵下的项目经理同样可以有超强的团队影响力。本文重点分享我所在公司的项目管理流程，对影响力涉及较少。
我所在的互联网公司，有正式Title的项目经理分为两类：一类是深耕某条产品线的，一类是大项目管理部的，负责跨产品线的大小项目。有些产品线没有单独的项目经理，启动自管理模式，有些经理会直接兼任，其实这个效果还是不错的。
项目立项：一个大项目启动前，一般前期高层都会深入讨论的，决定做某个项目，实现公司战略。一般产品老大会安排某个领域的产品对接作为主产品经理，项目管理部核心领导组会根据项目的实际情况，安排改动较大的产品线所在领域的某位项目经理作为主项目经理。立项后的启动会自然是邀请相关干系人一起沟通，战略意义越高的项目，邀请的干系人级别越高，介绍项目的背景。此时一般对应的主要干系人都比较明确，包括各业务方（业务需求对接）、项目负责人（对项目的成败负责）、职能部门对接人（符合法律法规、财务结算等）、主产品（负责产品需求和验收）、架构师（负责系统架构和边界）、主技术（负责技术对接和协调）、主测试（负责整个测试联调）、主PMO（负责项目按期和整体按流程交付）等都确认下来。
需求评审：各产品线负责产品输出需求文档供小组评审。一般主产品会优先评估哪些领域有改动，联系对接领域的产品，一起评估对各产品线的影响。主产品（一般来自系统改动最大的领域）输出产品整体方案，这里要做的就是各产品线梳理系统改动点，确认主要依赖，有些产品线会依赖于技术介入，此时架构师一般也会介入，搞架构方案，评估改动点，包括通用组件，系统监控告警等。可以搞个各产品线改动点评估会议，毕竟改动点梳理不会太重量级，怕漏点而不怕多考虑，宁可错杀，不可放过。通过多人讨论（对系统了解深刻的人）有助于了解更多，尤其是影响大的项目。在梳理和对接完成改动点后，就到了各产品线出正式PRD阶段了。这中间可能有数次产品线专题对接，项目经理负责串联各干系人，组织会议，建立邮件组，微信群，不同领域工作组等，留意跟进事项进展，关注潜在风险，勾勒出里程碑，准备周报，商业需求和产品需求工具使用等。
项目排期：各系统完成需求评审后，就入产品线需求排期阶段。这个时候的大里程碑就非常重要了，让大家有方向对齐。当然大里程碑是基于关键路径的事件和领导期望的时间来的。一般大项目的发布都要跟App版本，App版本有相对固定的节奏，项目排期和里程碑会参考App版本，其实时间也就差不多固定下来了。只是改动小的产品线可能可以晚点，但改动大的产品线确需要严格执行，分批提测。用于指导各线排期的里程碑一般包括需求完成时间、开发完成时间、测试完成时间、联调完成时间、上线时间等，一些紧急的项目对应的应急计划也会随之出来，甚至立项前就出来。这里给出的时间是关键路径上的最晚完成时间，非关键路径产品线可以做微调，但以不影响整体节奏为基础。此时，产品线内的具体开发和测试才会比较清晰，识别干系人是一个逐步完善的过程。
开发阶段：有些团队还是走概要设计和详细设计，因为此时需求比较确定。技术负责人需要出整体技术方案，确定系统交互接口，用接口还是走消息队列，项目上会要求各系统的接口对接明确化，系统间有依赖的地方要确认接口提供时间，这也会影响到整体上线时间。这里开始前会有技术评审，架构师和各团队讲解下相关技术设计，确保上下游对齐，面对面沟通非常重要，明确输入和输出。对于紧急项目，一般都是分批提测，确保测试有足够的时间。有上下游接口的还会协同好进行开发联调，确保开发阶段接口能够按预期工作。一般架构评审也会安排在开发阶段进行。
测试阶段：开发阶段测试也在同步设计，并完成测试用例评审。甚至开始部分自动化用例撰写，保证测试正式开始时可以直接执行测试。功能测试在开发测试完成后冒烟测试通过后正式开始，有团队内测试报告，一般产品线内自己负责。一般功能测试进入到晚期，各系统联调就会开始，两两联调为主，需要的时候再进行超级大联调，保证各系统联调环境能够正常使用。如果有跨团队的问题不好解决，就会逐步上升，项目经理负责整体协调解决。大联调阶段一般会有测试报告，关注测试进展和问题，就是项目经理的本质工作了。一般安全评审也会安排在测试阶段进行，验收测试场景和运营场景也会在此时准备。
上线阶段：一些独立的产品线可以单独上线，而互相依赖的产品线，主要的产品线一般都会按火车头发布，会集中在某个上线周。上线周前会有上线评审，确保各系统依赖、环境变量准备、数据变更和上线顺序都提前准备到位，一些新系统还需要申请新机器。上线周初会把代码合并到主分支，有紧密联系的系统严格按照顺序进行。上线后产品经理组织验收，保证主要流程和关键场景在业务使用时功能正常。
运营阶段：按照运营计划，准备数据，观察运营效果，确保系统在线上运转正常。有时也会按照小规模试运营，一些重要功能会按照比例或者白名单等逐步放量，灰度过程中有问题需要紧急修复，快速上线。等运营一段时间后，分析运营数据，得到运营效果，证明项目的价值。不少拍脑袋或者使劲推的项目，可能上线后都不运营，或者业务价值远远低于预期，这无疑是失败的项目。当然，运营会反哺到需求，形成新的需求，迭代优化提升，形成业务闭环。
这就是我所在公司项目管理的全流程，估计不少公司都是这样，偏瀑布多一些，挑战性主要在于产品线多，干系人多，怎样在纷繁复杂的系统间全面分析，确保不遗漏主要场景和干系人，这对项目上线成功运营非常重要。当然，合法合规、客服安全等层面也需要考虑到。自然风险管理是贯穿始终的，问题大表、问题跟进、同步干系人、识别技术风险都会存在。至于上线后能否实现预期价值确实比较难说，涉及到很多因素，通常也脱离了项目经理的管辖范畴。一开始要求ROI和业务价值，到运营后衡量项目价值，其实是蛮有意义的一件事情，优先做高价值事情，也未尝不是一种变相的施压，让“所做的事情一开始就有价值”。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。