快好知 kuaihz

产品经理工作概述:谈谈我眼中的7个产品工作环节(二)

前文已经和大家提及到了产品经理工作的前三个阶段,名为接受任务,分析,产品设计,这篇文章则和大家聊聊我们工作中的后四个阶段,即交付产物,跟进进度,验收发布,结果分析。

交付产物

我一直信奉团队至上的观点,个人的力量无论多么强大,也需要团队的支撑。

我们在工作中,常常感叹,有一位助理多好,那就能帮我们分担许多工作了。

我们希望有位助理,或者有人协助,本质上是对个人能力的一种危险预警,潜意识在告诉我们,你不行了,你需要团队

正确处理团队关系,高质量提供交付产物,是我们获得团队帮助所必须要付出的代价。

与不同角色合作,需要交付不同的产物,需要记住的是,没有谁是谁肚子里的蛔虫,也不要寄希望和谁心意相通,正如我们无法揣测BOSS的想法,放之他人,也是相同的。

在我们与团队合作的过程中,90%以上的分歧,不愉快都是因为产品经理没有严谨的对待自己交付的产物。

原型图和需求文档是我们最基础的两份输出产物,可直到现在,仍然有许多产品经理以思维,思考的名誉,剥削产物的意义。产品经理确实是一个强思考的行业,但这不代表我们不需要执行,不需要输出。不需要将我们的思考过程交付给团队。

我把我应该做的做完,我就成功了,置于对方有没有做完,抱歉,这不是我的责任,可我们真的知道自己应该做哪些事情吗?

绝大部分的时候,我们是不知道自己要做哪些事情的,这是这类角色的一个特性,似乎没有人为我们安排明确的任务,于是,我们出现了各种问题,各种花式秀矛盾,如果我们是开发人员,我大概会这么说。

你不是来写代码的,你是来写bug的。

我们来简单罗列一下要交付的产物

原型图

原型全景图

需求文档

变更记录

业务流程图

数据流向图

迭代故事

材料准备

沟通,调整

并没有完全列举完,我并不想去堆砌交付产物,这似乎没有价值。

交付产物并不是越多越好,而是越有效越好。

需求文档举例,我们可以看看自己写的需求文档,是否方便研发阅读,是否有歧义,是否已经将功能大部分都覆盖了,一份好的需求文档可以极大的增加团队效率,减少低效时间的耗损。

我曾关注过一个现象,相同的团队,相同量级的需求,实际开发中所消耗时间的差异高达 60% 期间,发生变化的只是需求文档更为精致,交付产物质量更高。仔细想想,平时耽误团队时间的,不恰恰是因为需求描述不清晰产生的沟通成本,调整成本,以及由于需求颗粒度不够导致的变更成本吗?

而这些问题,只是需要提高我们交付产物的质量,就能有效解决。

所谓的交付产物是指接力的介质,产品经理所需要做的事情做好了,然后慎重的将我们的努力交给我们的团队。这是一个很庄重的仪式,很严肃,是对团队的尊重,也是对自己的尊重。

在野外,我们猎杀了一头野猪,大概有100kg,我们嫌弃搬运太重了,就只切了一条猪腿,带回部落,大概只有10kg

当我们再回到狩猎地时,被猎杀的野猪已经被其他野兽吃完了。

野兽就是我们所接受的任务,由于嫌弃麻烦,我们很粗暴的对待自己的原型图,很粗暴的对待需求文档,对待我们的交付产物。似乎是没有时间,实际上只是因为我们偷懒,而且还是很不聪明的一种偷懒。

如果用正确的方法画原型图,写需求文档,你会发现,这样才是最大限度的偷懒。

现在你知道如何面对交付产物了吗? 他并不难,只是需要我们额外的细心,额外的认真,同时,也需要我们尊重团队,尊重自己。切忌将产品经理等同于思考者,我们除了强思考以外,也是团队中的一份子,思维固然重要,团队力量却远胜于个人的思维。

想的再多,做不出来,有什么作用呢?

跟进进度

产品经理需要跟进版本进度,毫无疑问,我需要再强调一下,只有思想,只有想法,是无法做好产品经理的,我们不缺少想法,每一天我们都有许多想法,成出不穷。

2011年,在我第一次创业时,认识了一位灰色产业的朋友,他告诉了我一个很棒的想法,他想要消灭钱包,消灭现金。

人们每天买东西要带钱包,多么麻烦,还要找零,现在手机那么方便,做个软件出来,直接扫一下就能付钱,多方便。

光是手机付费还不够,金额太高,用手机也不方便,我们还得带个手机,最好还是刷身份证,刷脸,这样什么都不用带,要付钱的时候,扫一下脸就好了。

很遗憾,他不是马云,也不是马化腾,他只是一位不那么普通的普通人,现在,人们手机支付已经非常方便了,平时的生活中,我也很少再用现金了。移动支付产品经理的想法与我这位朋友的想法并没有什么不同,但将想法实现出来却是截然不同的两个概念。

想法固然重要,但也只是重要,真正起到决定因素的,还看我们的做法。

当我们把产物交付给团队以后,我们的事情并没有结束,你需要留意一下,此时你的身份已经变化了。

你的产品从交付的时候开始,出现了变化, 此时,团队就是你的产品,团队效率就是你的产品质量。

如果一个团队中没有更高的角色,那产品经理就是这个团队的leader,产品负责人就要对这个产品负起责任,还要对这个团队负起责任。

早会,需求卡片,周会,进度跟踪,风险报警,日报,周报,需求调整,需求管理,资源协调。

这些是我们最常看见的在交付后的任务,尽管我们在交付产物之前,有做技术调研和需求评审,但这并不能保证在开发过程中出现需求障碍。

实际上,无论我们的技术调研和需求评审做的多么细致,总会出现意料之外的问题,这是因为我们的开发同学,在技术调研和评审时,只能根据大概情况进行预测,而在执行时,却会考虑的更深更全面。

在研发阶段,开发会遇到一些较为复杂的需求,会消耗较多的时间,此时,我们就需要根据开发的反馈进行再评估。

慎用技术强攻关,大部分的产品并不是以技术决定胜负的,超过80%的团队,并不需要过于强硬的技术,尤其是小团队,初创团队。(技术性项目例外)。

在我接触的许多项目中,再也没有任何一个方法比修改产品方案更快捷了,当出现研发障碍时,修改需求方案,能够节省 1 天至 1 个月以上的时间,这需要我们每天跟进跟进研发进度

仔细想想,我们真的有必要花费这么大的成本去实现某个功能吗?

当我们参与到进度跟进时,会收获许多的调整,为了避免出现需求不统一,也是为了提高交付给测试同学的产物,我们还需要对需求进行有效管理。

需求管理

目的:统一需求,提高需求溯源性,也是为了测试时能依据最新的,正确的需求进行测试,减少我们的沟通成本,也减少需求的不确定性

需求本身首先要能被管理,我并不提倡word版本的需求,也不提倡原型图上写需求,两者皆因为 需求无法被管理

其次,当需求评审以后,不再对已评审的需求进行编辑和删除操作,原则上,我们将以 取消和新增的状态进行标示。

同时,我们还要维护变更记录,让变更原因,变更内容清晰可见。

这并不是一件简单的事情,需要我们掌握一些方法,比如尝试用excel来编写需求文档,并且在需求文档的撰写过程中,遵守一些规范。

资源协调

产品开发过程中,其实需要用到很多资源,包括内部的和外部的。

当我们需要使用第三方系统时,需要为开发同学准备好第三方系统的账号,key或者其他什么,比如第三方统计,第三方图片处理,第三方登录,第三方地图

而内部的资源集中体现在接口API 和设计图输出上,许多时候,我们都是由前端驱动的,我们设计的多数是前端的产品,比如APP, H5 ,WEB, PC ,但前端的功能需要依赖后端的接口,以及UI的效果图。

等接口,等设计图,这两种时间的耗损虽然很可惜,但却是我们经常遇见的问题,如何妥善的安排资源,如何取舍,便是我们要做的资源协调,尽量的减少等待,这需要我们知晓各个功能的优先级,复杂度,尽快进入并行轨道,避免等待。

验收发布

我带产品团队时,会经历两次验收,这里提到的验收是整体验收,我并不是很提倡在开发过程中频繁打包,但我也很理解许多团队,都会频繁的打包验收。

当开发阶段结束后,测试介入前,产品经理有义务进行一次验收,目的是确保主要功能逻辑与需求符合,没有遗漏需求功能,可以称之为需求验收。

当测试结束后,产品经理还需要再进行一次验收,目的是确保产品无明显Bug,能够正常使用,此时,才是真的产品验收。

需求验收

有时,我们需要做好心理准备,也许开发实现的功能与我们的想象的有所区别,甚至南辕北辙。

我们首先需要确认一下,有没有需求遗漏的,通常情况下,会有开发漏做了部分功能,此时,我们就要判断这部分功能是否可放到下个版本迭代,还是当前版本非常重要的功能。

面对一些实现效果与预期效果不一致的功能,我们还要冷静的分析判断,开发这样的调整,能否接受,如果能接受,那就要根据调整结果,来修订我们的交付产物。

原则上,我们希望尽快的切换轨道,需求验收是一个阶段,更多的却是一个节点,我们要把关,但也要灵活,尽量避免过多时间的反复调整

如何判断哪些需求调整是可被允许的,哪些需求遗漏是可悲允许的,便是我们在这个阶段所需要锻炼提升的技能,MVP原则在这个环节也是适用的。

产品验收

确保产品上线没有明显BUG,不只是测试同学的职责,也是产品经理的职责,当然,我们无法像测试同学一样细致,成体系,成规范的进行模拟操作。

但我们却可以从自己的角色出发,确保主要路径不出明显bug,我们需要保证业务是正常的,核心功能是能被使用的,大部分使用场景是没有明显Bug的。

同时,产品验收阶段也是我们对需求逻辑的最后审核阶段,我们的业务逻辑,功能逻辑这样做是否正确。

这需要我们站在用户的角色,真实的进行体验,可以说产品验收时,我们便是这个新功能的第一位真实用户。

当我们已经完成产品验收了,此时,我们就会通知开发同学。

没有问题,可以打包了。

打包的意思是将已经验收的程序独立生成安装包,在android 平台,我们往往需要打多个渠道包,每个渠道一个唯一的标示,这样我们就能知道我们的用户都是从哪里下载的。

当然,发布一个版本可不是这么简单的。

产品发布

从硬性角度来讲,我们要为产品发布准备一些材料,比如更新文案,上传安装包以供审核,特别是IOS平台,要预算3-7天的时间进行审核,且可能审核被拒绝。

从软性角度来讲,当我们发布一些特殊的版本时,还需要配合运营的规划拟定发布策略,必要时,可以封包待发布。

即,我们将可发布的版本准备好,但却不真的发布,等待机会成熟,再进行发布。

为什么在一些重要节庆日,成熟的产品都能准时准点的上线特殊版本呢?比如圣诞节版本,如果延期一两天,是否表示这个版本的时间完全浪费了,毕竟圣诞节可不会等你两天。

特殊的版本,我们往往会提前将安装包准备好,进入封包待发布的状态,只要等待某个特定的时间,便可以直接发布版本。

结果分析

这是最后一个环节了,也是最容易被大家忽视的环节,我们习惯性的将希望寄托在下个版本,寄托在下个功能,却很少对结果进行分析。

当我们产品已经发布了,此时要注意观察相应,观察数据,通过实际市场结果,我们再来思考和评估。

这个功能是否被用户所喜欢,用户使用情况怎么样?有没有提高的方法?

我们知道一个页面,不同的位置,人们的点击欲望是不一样的,相同的发布功能,以点击次数来判断,右上角的发布只占底部菜单的发布的1/10。

我们需要通过产品发布后的结果来持续的去改进,去分析,为下一个版本提供总结性材料。

作为产品经理而言,我们所设计的功能,应该是越来越有效的,而不是越来越多的,我至今仍然记得一个案例。

某网站,进行了一次改版,改动内容是将注册 的按钮做的比以前更突出了一些,新版本的网站,注册率比老版本的提高了30%。

这里提升的是注册率而不是绝对值,因此我们可以忽略运营或者市场情况带来的影响。

如果我们每次发布后,不对结果进行分析,我想一年经验和两年经验,区别真的不大,甚至再做到第三年,第四年也是相同的。

我们在入门的时候,是以能做出产品为目的的,但当我们能做出来以后,就要学会去分析,去改进,而不是一层不变。

相关阅读

本站资源来自互联网,仅供学习,如有侵权,请通知删除,敬请谅解!
搜索建议:工作  工作词条  产品  产品词条  概述  概述词条  谈谈  谈谈词条  环节  环节词条  
产品

 何谓好产品?

“何谓好产品”这个问题相信很多产品经理都曾细想过,但不知心中已有答案否。本文将从三个角度出发,再来对这个问题进行深入探讨。好产品要同时满足公司目标与用户目标。好...(展开)

产品

 需求变化与IoC

需求又变了,怎么办?最近微博上流行一个段子:程序员XX遭遇车祸成植物人,医生说活下来的希望只有万分之一,唤醒更为渺茫。可他的Lead和亲人没有放弃,他们根据XX...(展开)