有一些产品经理,不管发生什么问题,总能够按时上线版本,偶尔一个插入任务甚至能安排隔日发布,这种产品经理是有着超高能力水准的。这篇文章带来一套方法,希望能让你也能成为需求如期上线的产品经理。 在某一个夜深人静的夜晚,你是否有过那么一次,灵机一现,脑海里闪现一个超级完美需求,然后迫不及待第二天早上与团队沟通,恨不得立马上线让用户为你鼓掌? 然而… 经过设计师、技术经理的几番撕X下来,上线之日已遥遥无期,在开发的过程中又遭遇到了种种不幸,最后不了了之? 或者明明与UI设计师、技术经理协商好的版本上线时间,总是因为某些不可抗力频频延期? 一问原因,要么回答你当初预估工时不准,要么中间有插入任务,要么觉得你的需求不太重要,人为的把它调整到后面了… 俗话说的好:同人不同命,同伞不同柄。 总有那么一些"平平无奇"的产品经理,不管发生什么问题,总能够按时上线版本,偶尔一个插入任务甚至能安排隔日发布? 这种产品经理,丽莎阿姨称之为能打型产品经理。这些能打型产品经理到底有多牛X? 丽莎阿姨一直说产品经理是一门工程科学,我们是以最终的结果来衡量产品工程师的水平高低的,如果工程没办法如期开工、高质量交付、按时发布、那几乎是一个毫无用处的产品经理。 所以,接下来跟着丽莎阿姨一起来练习这套超能打拳法吧~ 第一式:弄清楚产品经理做项目管理的目的是啥? 其实在很多互联网公司,产品经理与项目经理是两个不同的岗位,例如YY、华为等,产品经理只需要给需求,项目经理负责管控进度与交付。产品经理无需耗费精力来管控执行,看起来好像交付能力提高的了,但其实丽莎阿姨是非常不赞同这种分工的。 Why??? 我们知道项目管理的目的就是使尽浑身解数、千方百计去实现需求和期望。而一个无法感同身受的项目经理是无法帮你"千方百计"去实现需求和期望的。 并且,产品经理去负责项目执行还能带来非常多的自我效能: 1. 提高你的团队的掌控力 如果一个产品经理,仅仅负责出需求,那你仅仅是团队工作流程的一个环节,你对团队的掌控力基本为0,你最多是个螺丝……而如果你参与到项目管理中,每一个环节的进度都由你来把控,这条船你控制、你指挥,你的角色就是船长、舵手。 2. 提高你自身的组织影响力 只有当你对团队的情况了如指掌,那你的影响力也一定会极大地提升。 丽莎阿姨告诉你:如何判断一个产品经理是否真的出色?就看他离职的时候能带走多少人。 这句话你品,你细品。 3. 了解实现的苦,让你的需求更简洁、直接 你在项目管理中深刻体会到开发过程的曲折与实现难度,你才能充分理解你的技术经理头上的Jennifer是怎么掉的,才会迫使你在出需求时,极致地追求简洁的逻辑和页面功能。而清晰的需求逻辑、简约的产品功能往往可以一刀致胜。 所以,不管你的团队是如何分工的,你如果想做一个对未来有期许的产品经理,请从头到尾负责你的项目。 第二式:如何做好项目管理呢? 我们可以将项目管理划分为:启动阶段、规划阶段、执行阶段、结束阶段、监控和控制五大流程。 1. 启动阶段 在启动阶段最重要事情是给团队内的所有人(包括老板、研发、设计师等)描述项目的星辰大海,用讲故事的方式告诉小伙伴们接下来要干一件什么大事,让大家听完,直拍大腿:"对!我们就要这么干!立马干!"所以,有仪式感的项目启动会非常重要。 2. 规划阶段 这个阶段的意义在于给项目划定范围和分工排期。 划定范围就是告诉大家"哪些是我们这次要做的",除此之外一律不需要实现,清晰的范围会让项目可控,而不至于项目的需求不断膨胀,导致项目无法收尾; 分工就是庖丁解牛,分好牛肉各自领回去,这一步建议由技术经理负责; 排期的含义是定下本次项目的关键事件和对应的时间,例如产品迭代中的"联调"、"验收"、"送测"、"发布"是关键事件,每个关键事件的具体交付日期。 3. 执行阶段 项目终于要开干了,对于开发工程师他们在本阶段就是埋头苦干,但对于产品经理,在这个阶段更像一个机动人员,需要随时沟通、协调资源以解决项目中遇到的种种问题,推送项目正常进行下去。 4. 结束阶段 产品对外发布,在本阶段产品经理需要将成果对外同步给需要知道的人,例如B端产品告诉前端销售,C端产品告诉用户,理论上你的项目管理工作就结束了。 如果你是一个执行力非常强的人,看到这里你一定想兴致勃勃准备大展拳脚,但是阿姨告诉你,你的项目管理大概率还是会一团糟。因为项目管理五大流程中,最最重要的"监控和控制"环节,才是保证项目不扑街的核心关键。 5. 监控和控制 监控的到底是什么?是不是弄个项目流程表,定期跟催督促大家如期交付就是监控了? NO!! 作为一个能打的老练产品经理,你一定要记住:你监控的是风险、管理的是变化、节约的是时间!所以并不是跟催人就能了事的。OK? 如何监控风险? 对于产品新人,我介绍一个识别风险点简单粗暴的方法:只要涉及到项目外的人/事,都是风险点。当你对风险识别的意识越强,你的项目管理能力也就越强。 举个例子,某产品经理A想做一个小程序,需要与运维部门对接服务器需求,而运维部门不在A的项目组内,他既对项目不上心,也不需要对你负责,这个运维部门就是A的风险点。 那么知道风险点,如何监控呢?只有苦办法,多费心,拉个群日常问候,时不时跟催问进度细节。 如何管理变化? 变化是常态,一颗平常心是最重要的。项目管理中可能的变化有:项目延期上线,投入成本需要增加等等,总之,出现了变化,最需要做的就是沟通!请务必将变化及时同步给项目组内所有人。 最大限度的保证进度? 保证进度的最好工具就是项目组日报、周报。用简洁清晰的语言描述当前项目的进展,让各负责人以每日、每周的频度汇报当前进度。 按照阿姨交给你的第一式与第二式,步骤严格实施,你也可以很快入门成为能打的产品经理,但是如果你想成为武林高手,那还得跟着阿姨一起来深入理解项目管理的高端操作。 第三式:应对各种变化的心法是什么? 经过多年项目管理的摸爬滚打,在这里给大家奉献一个非常棒的项目管理思考工具:项目管理三角模型,项目管理其实是由时间、范围、成本共同决定的。 时间:既项目投入的时间,对应产品迭代中, 既你要什么时候上线。 范围:代表本次产品迭代的需求量,要做哪些需求。 成本:项目投入的总成本,一般指开发、设计、测试人员和服务器成本。 如果你想保证产出质量不变的前提下,压缩时间尽快上线,要不缩小范围砍需求、要不加大投入成本投入,三个因素互相影响,处理项目变化就是在三者之间找到平衡点。 一个真实的不能再真实的故事: 产品经理小林:在1月份给老板拍胸脯,2月14日一定上线新版本;风云突变,2月8日技术经理小木跑来说道:"恐怕是不能上线,得延4天"。 作为小林的你如何思考这个问题? 哈哈~看过前面文章的小林马上就想到,那我使用项目管理三角模型的原则来思考一下这个问题: 思考一:是否可以延期?大部分情况下老板和你的客户是不愿意的~ 思考二:是否可以砍掉部分需求?无数次的问自己这个真的是最简版本了吗?如果不是,请砍掉哪些不能一剑封喉的功能。 思考三:是否可以增加版本投入?如果加人可以解决问题,那就想尽一切办法加人。 从上面的例子可以看到,武林高手小林从时间、范围、成本三个方面考虑,最终找到处理变化的突破点。 需要特别说明的是:作为项目管理,不到非不得已,都不要砍产出质量。当然对于如何协调资源,这又是一个全新的命题了,阿姨将在今后的文字中再介绍。 记住一句话:会哭的孩子才有奶喝。如果产品经理都不为你自己的产品发声,那更不要指望任何人来主动帮你。期待这套拳法+心法学会后,你也可以能抗能打,做个李小龙呀。