接手新项目,产品经理如何高效开展工作?

7 评论 17001 浏览 64 收藏 9 分钟

编辑导读:在接手一个新的项目时,一些经验不足的产品经理有时会手足无措,无法上手。本文作者根据自身工作经验,分享在接手新项目之后,产品经理如何高效开展工作,希望对你有帮助。

常驻公司或跳槽到新公司后,难免会被安排接手或自主申请新的项目。由于自己对刚接手的项目并不熟悉,因此常常感觉无法快速上手。

虽说是正常现象,但为体现自己专业的能力和经验,就需要在变更或接手新项目后快速融入项目团队。

以下是一些总结和思路,通过运用项目管理的思路,来快速熟悉和上手新的项目,希望对你有用。

一个项目正常实施开发到结束,整个项目管控的流程是:启动、规划、执行、监控、收尾。

在整个项目管理流程中,在每个阶段做相应的事情,来快速熟悉项目内容和把控项目风险。

  • 启动:了解项目背景、立项原因、目标以及范围,形成项目文档或产品创新章程;
  • 规划:基于对项目文档或章程的理解,根据当前人力、项目资源进行规划;
  • 执行:具体根据规划执行,拆分实现项目目标的关键点,同时通过把控产品开发流程来控制执行效果;
  • 监控:通过项目管理的方式来管理监控项目进度,平衡项目的三重约束(范围、进度和预算)及时降低风险;
  • 收尾:根据项目标准和预期验收执行成果,查漏补缺;项目交付后进行复盘,思考哪些地方有问题,为什么有问题,哪些地方还能再进行优化,如果有机会再做一次,可以如何避免。

了解了整体的思路,具体就是执行落地了。

一、启动

主要了解和熟悉项目背景,明确立项工作的内容和背景,以及项目的短期和长期目标;知道了原因和目标,才能根据现有资源灵活规划项目,否则就会出现资源有限,却规划了很宏大的计划,导致团队成员有心无力,项目规划不落地。

二、规划

这个阶段可以运用项目管控的三重约束,即范围、进度和预算,概念上理解,如果能平衡好这三重约束,那么项目的风险就能降到最低。

明确范围:跟项目相关人明确项目范围,需要具体完成的工作内容和时间节点;确定产品边界范围,结构化产品需要提供或交付的功能服务,可使用思维导图绘制产品功能和信息结构图。

明确进度:与团队成员同步实现项目目标所需要的关键路径与里程碑,方便后续项目管理出现延迟风险时,可及时进行进度压缩,如添加资源(加班加点和成本)、并行的执行任务等赶工方式。

了解预算:了解项目预算,便于合理控制项目资源,人力设备等,如果没有权限,可及时向上面的资源反馈现状并获得建议;兵马未动粮草先行,再精益的产品项目,也需要相匹配的开发资源,不然就是画饼。

三、执行

具体在执行项目时,需要从两个流程去入手。

熟悉工作流程:是指在公司内部或所在部门的工作方式,如一个需求从诞生到开发需要经过收集需求、需求管理、规划排期、需求策划、需求评审、工时计算、项目管理、上线跟进等步骤。

熟悉协作流程:是指在做好工作流程的同时,需要跨部门跟哪些职能角色或项目角色来沟通协作,具体表现为事务/邮件的发送方式,谁发、怎么发、发给谁、相关人都有谁,信息同步的内容和规范、汇报节奏以及需要的时间节点。

如涉及到人力资源配置,还需要分清楚公共资源和项目小组内部资源。公共资源不属于自己可直接安排,需要借助对应职能领导的协助;内部资源则可由产品经理直接规划和安排。

在项目团队成员工作安排方面,需要搞清楚大家手头现有的工作,并行的任务分清主次优先级,做好职能团队和项目团队的协调;同时,需掌握项目的关键技术难度,然后评估时长进行版本规划。

规划的任务内容尽量要有优先级,且在短期可实现,即利用最少的资源去实现成果,不要给自己挖坑,如拿捏不定,就多咨询反馈以便同步信息。

四、监控

大小项目的监控,很多时候并不是可凭产品经理一己之力就可以完成,毕竟“产品经理是没有实权的经理”,因此需要借助项目相关角色资源来协助自己完成。

项目协作需要借助的资源角色,如运营中心负责人、研发中心负责人、技术组长等,哪些是对项目的走向有决定性作用的角色,哪些又负责承上启下。

在监控阶段,如发现项目风险,如产品故障或产品逻辑缺失,就需要产品经理去评估修复工作的工作量和项目延时的后果,并且通过向上反馈快速决策。

五、收尾

收尾阶段,需要做好项目的跟进,保证项目周期顺利结束。做好数据记录并及时向上反馈成果。

汇报时,可清晰描述当前项目总耗时、成本、进度,以及与预期相比,是提前完成还是delay,并说明原因。

项目顺利完成后,并不需要立刻复盘,而是可以等一段时间,比如一周、半个月之后再进行。

项目结束后如产品版本上线,需要新的数据沉淀,才能发现问题,如在项目结束后就立刻复盘,此时项目的遗留问题并没有暴露太多,因此复盘的结果也并不完整和客观;

因此要等数据沉淀后,通过观察和分析自己之前定义的关键指标和数据趋势来进行分析和总结。

同时,复盘时还要记得回忆是否有常识性的错误,如产品发版忘记提前准备应用商店图片、需求策划没有做好新旧版本兼容等,不以误小而不为。

六、最后的话

产品经理在平时的工作中,虽说不应急于求成,但也要注意执行速度,有些东西可提前做准备,否则到截止时间时才匆忙赶工,难免会犯常识性的错误,而影响自己在团队中的专业形象。

还有一点,作为团队小组组长或负责人,除了保证项目的顺利完成外,还需要时刻惦记团队成员的利益,要有“跟着你有肉吃”的意识,因此也就要求产品经理们要有点“功利性”,能通过正确的方式方法为团队谋福利、争绩效,帮助自己快速成员团队中受欢迎的人。

#专栏作家#

王曙,微信公众号:独鼠一只,人人都是产品经理专栏作家。通俗产品人,分享独树一帜的产品思维、职业经验。

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于CC0协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 需求评审评审啥?

    回复
  2. 你这不就是把产品流程说了一遍么?就是产品定的换成了跟项目同学商量?

    来自浙江 回复
  3. 万变不离其宗,项目管理

    回复
  4. PMP大纲里都比这里全

    来自北京 回复
  5. 规划排期怎么会在需求评审前面?需求被拒了怎么办?

    回复
  6. 这几个概念搬过来就成了个文章?

    回复
    1. 确实 看起来虎头蛇尾的

      来自广东 回复