产品工作:何为标准化,怎么标准化?

文/ 何沧 2018-08-27 761阅读 评论(2) 5个赞

产品工作:何为标准化,怎么标准化?

我们在享受越来越便利的现代化生活时,很难想象它们背后的PM及其团队付出过多少汗水,尤其在硝烟弥漫的移动互联网时代,打造MVP版本必须要堪称神速(MVP,即最小可行性产品,下一篇将重点总结)。

  • 怎么做到快而不乱?

  • 怎么让几十上百,甚至数千数万人的团队如指臂使?

  • 怎么让一个天马行空的想法,变成一个可以落地的产品?

“标准化”在这其中起到了非常重要的作用。

如同足球有前锋、中锋、中场、后卫、守门员等位置划分,每人各司其职又不失灵活:

如果,我们拿掉这些标准的话,emmm......

一个产品、一个项目的快速而高质量的诞生,当然不仅仅是PM这一个环节的标准化所能做到的,相当一部分的标准化工作是由项目经理负责,但它是源头,源头不标准,会引起后续一系列的混乱。

我所在的公司地处二线城市长沙,长沙的IT公司对于岗位分工不像一线城市那么有边界,我既是产品经理也是项目经理,既要“想”(产品)也要“做”(项目),所以我对标准化比较敏感,我自己在工作中经历过这些阶段:

  1. 没有标准:最开始我是野路子,方法用对了就赶紧记下来,但更多时候是在捣乱,出错率、返工率太高;

  2. 学习标准:逛社区、找同行要了一堆参考资料,学习如何建立产品/项目标准,在实战中筛选和验证;

  3. 为了标准而标准:阿弥陀佛,着相了;

  4. 按需制定标准:经历了第2条的学习阶段,又跳出第3条的思维桎梏,脑子开始灵活起来,高速地“有效”进步;

  5. 不够标准:“有效”进步过程中最能发现问题,问题越来越多、越来越细,但这是好事;

  6. 统一标准:为了发挥出团队的整体力量,需要舍弃部分个人的习惯、喜好,步调一致,坚决贯彻,形成标准文档及统一的工作习惯;

  7. 迭代标准:发现标准上的问题先不急着马上更改,执行一段时间用于发现更多细节,有规律地、有版本地迭代;

  8. 传授标准:适当的时候向团队传授标准化制定的思路、经验、心得,启发大家一起思考,共同完善现有标准。

以上,唯一的雷区只有第3阶段,很多PM从业多年都跳不出这个雷区,所以在稍后详解“怎么标准化”之前,我们要明确三个原则:

  1. 标准化的目的不是把人变成机器,而是降本增效;

  2. 任何事情都要因时、因地、因人、因事制宜,不要为了做而做;

  3. 没有完全“标准”的标准,他人的标准只能参考,不可照搬;

鉴于第3点及篇幅所限,以下内容类似框架或提纲,用于按图索骥,我自己就是按这个提纲进行梳理和总结的,另外我也会在末尾附上一些以前收集过的资料,数量不多,仅作参考。

先上图(点击图片查看高清大图):

产品规划

一个公司的产品,首要目的是解决用户的需求,然后以这个目的为出发点,通过一系列手段将这个产品产生的价值转化为利润来实现盈利。

盈利模式不一定每次都由产品经理发起规划,目前大部分公司都由更上一级的高管层去构思,所以这一条没有作为标准流程写入上图中,但产品经理一定要准确理解公司的盈利模式、战略规划、战略意图,这是核心,资深的产品经理是有能力设计盈利模式甚至商业模式的。

弄清楚产品的盈利模式,进而就能考虑清楚产品未来大体会是什么样子。为了让产品达到这个样子,进而实现它的盈利模式,PM在考虑这一切时一定会发现其中有很多障碍。按照先后顺序,闯过这些障碍,就能通关达成目的。

为了“闯关”,PM要对每一个“关卡”进行研究,将这些“关卡”分解为几个较为具体的目标,然后按SMART原则,将这些较为具体的目标分解为一个个具体的可执行的工作内容。大家每天就是通过执行这些具体工作内容来解决一个个较为具体的目标,实现“破关”然后走向盈利。

那些具体工作内容就是产品的标准工作流程,以下逐一阐述。(注意是产品工作标准而不是产品设计标准)

需求收集

进行需求分析首先要有需求来进行分析,获得需求的过程叫做需求收集。

我们做的产品,是要以解决用户的需求为基础的,若我们不深入用户、不了解用户、不听取用户的心声,不明白用户真正需要什么,而只是闭门造车孤芳自赏,结局只会适得其反。

需求收集就是让我们听取用户和公司的心声,明白他们需要什么、想要什么,怎样让他们过得更好。同时,通过不断地收集这些信息,可以让我们的决策更加精准,也可修正我们的产品规划。

需求大体上有两类:用户需求业务需求。业务需求通常是规划时确定好的内容,有时也是上级直接指派给你的要求,因此这类需求,要直接通过公司内部进行收集,收集上司的要求、收集运营、商务和技术等队友对产品的看法和实现难度。

这里重点梳理用户需求的收集方式:

1.用户反馈

一般,都会由运营或商务兄弟通过各种方式维护与用户之间的关系,然后收集到用户在各种情况下提的建议与反馈。收集渠道通常有如下几种:

  1. 产品自有反馈体系

  2. 微博

  3. 微信公众号

  4. 运营微信群

  5. 运营QQ群

  6. 贴吧、知乎、行业社区等

  7. 客服、运营、销售

  8. 应用市场评价,如app store

上面大多需要与客户维系好关系,按照重度用户、轻度用户、游客等,对提出的建议进行分类。

2.竞品分析

  • 想要更快的明白这个行业是什么情况,多看看竞品;

  • 想要增加一些新的灵感,多看看竞品;

  • 想要让产品不至于偏离主线,多看看竞品;

  • 不想掉队,看竞品;

  • 想要发展,看竞品。

虽然说了这么多看竞品,但记住,过犹不及,你毕竟不是别人,你的产品毕竟不是别人的产品,主流也并不一定会成为下一个独角兽。

竞品,只是参考。

3.头脑风暴

这是非常简单却也是非常难的方式,很多人都会用,但用好,绝不是那么容易的。头脑风暴是几个人坐一起自由联想思考事情,看似简单而没有成本,但是需要一定的操作才能做好。

头脑风暴人数不能太多,越多的人会导致难以思维过于散乱,并且影响到每个人的表达,难以组织。人数大致在6、7人以内为宜。

头脑风暴需要组织。没有组织,会导致思维过于散乱而难以解决问题。头脑风暴,终究是为了寻找解决问题的办法。首先,收束方向,有方向的使劲,就像脑图一样,一层一层的寻找;同时,每一个点时间都不宜过长,否则你会浪费大量时间,每一点以3到5分钟为宜,当然还是要视情况而定。

不要对脑暴抱有太大期望;也不要抱有“多给点时间万一能脑暴出来一个点子”的想法。脑暴时间不一定能产出好的点子,但有时脑暴会给人带来一些触动的灵感,有了脑暴的这么多想法,很有可能在日常生活和工作中就能有新点子产生。

4.数据分析

通过内在的产品产生的用户行为数据以及外在的各种行业行为数据,通过一定的手段将其提炼出来,来优化产品。现在社会通常是用数据说话。数据分析就是一门比较难掌握的学问。

5.定性定量分析

  • 定量:调查问卷

  • 定性:用户访谈、用户观察、竞品对比、圆桌会议

6.别忘了身边同事,以及老板

需求分析

需求收集到了,我们可以开始分析需求了。我们通过分析这些需求,来确定一个需求做不做、做多少、跟其他需求怎么结合,从而权衡用户需求和业务需求。

需求分析这个过程,就是多去思考:

  1. 这个需求到底解决了什么人在什么情况下的什么问题;

  2. 我们应不应该做能不能做这个需求;

  3. 为什么应该做这个需求、不做有什么影响、有什么好处与坏处?

为什么进行需求分析?

通过需求收集,我们会收集到很多的需求:真需求、伪需求,共性的需求、个性的需求、用户的需求、老板的需求……但是这些需求并不能直接使用。需求有真有假,并且分三六九等,有些需求可能我们做不到……出于这些原因,我们必须要进行分析,分析需求产生的根源;分析具体用户、场景;分析需求真伪;分析可行性;分析产品需求和公司需求……

在这个阶段,谋定而后动。否则,会出现开发出来的东西用户不买账,所有人都会对你有意见,需求改来改去,产品失去威信,一切无法再发展。

怎么进行需求分析?

前阵子专门撰文梳理过这个问题,这里就不重复赘述,传送门:如何洞察用户的真实需求?

优先级确定

上述文章对该问题也有阐述,这里不重复赘述。

实施分析

确定了做什么需求后,我们接着就该确定具体怎么做了——实施分析。

很多时候我们会面临:技术开发时的各种怼,做出来的功能出现各种问题……这之间的酸爽,体会过的都明白,就是这个味!出现这样的问题,很多时候,就是考虑不清,没做好实施分析。这个阶段一定要谋定而后动,做好实施分析的谋,才能做好功能设计的动。实施分析考究的是细节能否考虑清楚,各种状态间的转换,各种异常状态的处理。

怎么分析?

其实就是怎么考虑的更全面,下面这些小经验get一下:

  1. 根据个人知识储备,寻找所有能解决该需求的办法。这时可以通过头脑风暴一起找解决方式。思考解决方式的时候,尽量不要过多思考具体细节;

  2. 从这些解决方式中,按照寻找最可行的解决方案;

  3. 考虑这个功能最完美的样子应该是什么样;

  4. 为了达到这个完美的状态,需要进行哪些设置?需要进行哪些操作?最终展示效果是什么样?这里可以画一些简单的页面布局,帮助思考;

  5. 为了达成上面所述的完美状态,你需要进行哪些操作流程,可以画出流程图;

  6. 可以进行头脑风暴这些流程牵涉哪些功能,可使用脑图软件去画出大体的功能结构图,来理顺思路;

  7. 确定功能的所有入口和出口;

  8. 确定这个功能在流程中每个节点的规则。实际工作中,可能几个小规则的改动会导致你产出不同的功能;

  9. 使用流程图软件,梳理这个功能的功能流程图;

  10. 使用流程图软件,去梳理整个功能的业务流程图,即泳道图,来描绘每个身份的操作内容;

  11. 使用流程图软件,梳理每个身份的操作流程;

  12. 有了9就可以用Axure或手绘简单的页面流程图,做好页面之间的流转关联;

  13. 以上都是主流程的思考,这一步就需要费尽心思,思考更全面的异常状态。确定每一个操作,每一个状态改变,会对哪些状态有影响,会因状态的改变而使得哪些数据跟随改变。每一步的数据从哪来、到哪去。这些内容可记录在脑图中。这一点其实蛮有用的,有些人设计的新功能总是会莫名其妙的缺少状态,或者互相之间产生影响产生BUG,有这部分内容,多少可以避免一部分的BUG存在。这里提一个小技巧,多用反义词:数据有进就有出、有添加就有删除、有来就有往、有这个就没有这个、有填写数据就有不填写数据,有填写多了也有填写少了。有网就有没网、弱网的时候,也就会有打不开的情况……

  14. 尽量多一步考虑,思考数据追踪,为了得到这个功能的第一手数据,分析这功能有没有用、好不好用、怎么改进。就是数据埋点;

  15. 多思多想,反复互相完善上面的内容信息;

  16. 在你觉得没问题的时候,出去走走,散散心,然后再回想一遍所有的状态改变以及异常状态

  17. 从实施分析的时候就叫上UI一起讨论,感性理性一起上,你可能会更有收获。

功能设计

上一步,谋定后,现在则需要动—动——功能设计。

设计哪些内容?

  1. 页面布局:使用Axure进行页面设计,按照上面提到的页面流程图以及功能结构,将每个页面具体有哪些模块、怎么展示进行表现。

  2. 增加用户体验小功能:一个一个进行页面设计时,可能会发现一些能够增加用户体验的周边小功能。因为页面设计针对的是用户操作的部分,所以这里非常注重用户体验。比如增加一个“回到顶部”的小按钮。这种小功能没有很大的流程甚至没有流程,单独看起来很简单,但是零零碎碎的有时候很难说清楚。这里把握一点,不谈用户场景,只谈这个小功能使用时所处什么状态。达到这个状态时,会出现什么、怎么操作、然后出现什么状态。

  3. 动效:有些公司有专门的交互设计师,动效的实质是用户体验的提升。但是也要好好进行分析,有时候过犹不及;也有时候会对开发有影响。比如你是APP,要明白产品技术框架,很多APP是原生+H5的模式,原生部分处理有些动效不需要很高的性能,但是使用H5时则会要求较高的性能,而性能会体现在使用的流畅度。

  4. 与UI结合:公司不同,工作流程可能不同。有些公司在这时就需要UI设计页面,为产品上肤色。有些公司会在真正开发的时候才需要UI参与。如果你注重用户体验,注重页面美观度的话,越早让UI参与,你可能会得到更好的结果。

  5. 少即是多:产品这一行,有一句常用语“少即是多”。在具体设计时,你可能会灵感爆发,有很多想法,不妨都写出来,回归上面需求分析再进行梳理。有些想法,可能暂时你找不出来优点和缺点,或者优缺点并不明显,又或者难以确定,这时,不做比做好,或者先放下、或者放在数据埋点进行数据分析、调查问卷、或者下方的测试验证中进行一些A/B测试。有些东西是平衡的,让用户感觉简单,可能就需要你考虑的更复杂;你做的东西越多,可能用户用起来就会复杂。

  6. PRD文档:将这一切写在产品需求文档中,将你的功能意义、流程图、脑图、大小规则、异常情况、产品原型等写在上面,将所有能考虑到的问题都写清楚,后面其他人的工作都会围绕PRD开展,切记不要出现模棱两可的歧义。写PRD要多写,详细到队友能明白,否则队友会认为你是猪;也要少写,一句话能明白的东西就别两句话,毕竟PRD中文字还是比较多的,谁都不想看,你再啰嗦,就更不想看了。总之,写清楚写明白。可以使用一些模板,网上随便搜一下,大体都差不多。文末的附件分享也有一些PRD模板可供参考。最后,工作文档切忌口语化,一定使用准确的、没有歧义的书面用语。

测试验证

自己设计的功能,不可避免的会站在自己的立场上,会进入一些盲区,或者没有考虑那么全面,就算真的对,你总需要什么来支撑你的观点。这时通过一些测试进行验证,用数据来说话。

这部分,不同公司有不同要求。有些大公司,在需求评审时,就会拿出一些数据为佐证,来说服队友、上司。当然你也是有经历,有资金进行测试验证。有些公司会先进行需求评审,然后确定哪些地方需要进行验证,然后给你钱或者时间去验证。

验证方法有:A/B测试、用户调研等方法。

A/B测试其实可以看成一种实验,将一个页面的两个或多个不同的版本随机呈现给你的目标用户,通过对用户行为的统计分析来确定哪个版本更利于目标转换。这种测试方法我接触得非常早,2008年左右就接触了,但自己从来没用过,印象最深的是当时谷歌为了测试某个功能的两个不同呈现方式哪个更好,就做了一个随机显示,不同用户看到的是不同的呈现方式,然后用数据统计用户行为来判断哪种呈现方式更受欢迎。没经历过暂时没心得,等以后用到学到再补充。

用户调研,目前我所在的公司在用户调研上还比较简单粗暴,只使用了实地考察、回访这两种方式,尽管我知道一些调研方法(很容易百度得到),但毕竟不熟悉,也容后再补充。

需求评审

我们多少都是站在自己的立场上进行设计,可能由于知识面、能力、牛角尖、盲区等原因,这些设计存在这样或那样的问题,甚至于这些问题无法让团队的其他人认同,为此我们要进行需求评审,充分发挥公司里每个人的能力,来评审产品需求。然后改正问题。

各个身份的人,站在自己的立场和公司的立场上评论需求功能,进行可行性的讨论,尽各自所能挑问题,最终形成统一的意见。对,就是撕逼大会,而且要撕的淋漓尽致,还要撕到别人找不到撕下去的理由,真正的勇士的就是要敢于直面被撕的人生,并爱上这种酸爽。

为什么进行需求评审?

以各自的立场,去看待这件事,尽量找出所有问题,来解决它,否则留着问题到用户手里,你的产品会失去信用。

达成统一意见。这点非常重要。我们无法保证每一个人的意见都能被采纳,也无法保证所有的看法都能最终保持一致,实际上经常会遇到谁也无法说服谁的情况。如果保留分歧去执行,结果可想而知。

需要怎么做?

  1. 形成统一的意见很重要!

  2. 跟产品有关的所有人员都要参与。

  3. 最怕撕太淋漓尽致,更怕别人都不撕。

  4. 撕逼的时候,你抛出你的观点,若你有上一步测试验证的数据作为论据,只要你测试手段合理,试问还有谁能撕的动你?还有谁?

  5. 在需求评审大会之前,你一定要进行很多小范围内的需求评审和商议,每个环节的同事都要涉及到。和上司、和技术团队、设计、运营、销售等等进行很多接触。那些大的分歧一定要提前就解决,否则开大会时会浪费很多时间。也就是说开大会之前要让大多数人觉得这个功能有必要,并就功能的规则进行通气;至于具体的按钮啊、布局、流程可放在大会上进行探讨。

  6. 每个身份的人都要对产品进行评论,毕竟具体实施时,每个人都需要解决各自需要解决的问题。讲真,有些人真的不喜欢说话,不喜欢发言,尤其是人多的时候,技术人员尤其明显。这里也体现提前小会的重要性。

  7. 统一意见。统一意见。统一意见。当一些争论好像并不会影响特别重大的情况下,上司要进行最终的拍板(还是之前的小会,要达成尽量的一致)。有意见可以暂时保留,评审会上最终确定的内容要坚决执行,除非你在操作中真的发现影响过于巨大。

  8. 有时候需求评审会可能不止一次,有些问题还需再讨论,有些问题返工后需要再次评审。

协同开发

通过需求评审,我们确定了具体工作内容,即将PRD中要求的功能实现出来。为此,各个工种互相配合,将功能落地实现。

在开发过程中需要多人进行合作开发,这其中最重要的事情是相互之间能否将事情说清楚,让产品做出你想要的样子。为了达成这样的效果,要做好两件事:

  1. PRD写的明白无歧义,所有的开发以PRD为标准;

  2. 无规矩不成方圆,规定好工作流程,每一个人按照流程做事。(其实,需求评审做好了,一般情况下协同开发时大家的目的都是清晰的,然后每个人按部就班做好自己的事情就能顺顺利利的将产品开发出来)

这里大致说一下一个产品流程,会牵涉到哪些人员。对于互联网产品,最基本的要有五个人员,按照流程:由产品人员进行功能设计,接着由UI设计人员进行界面视觉设计,然后交给前端工程师进行前端开发,以及后端工程师进行后台数据搭建,当产品开发完后,需要运营人员开始运营产品。我们公司就是这样的人员配置,人不多,但麻雀虽小五脏俱全。

开发过程中,谁都无法保证产品没问题,所以有测试人员进行系统功能测试。一个产品为了增强用户体验,可能会需要UE设计师多去考虑用户体验效果,设计一些动态效果。产品、UI、UE、前端、后台、测试、运营,这些人构成了一个公司的开发部门。

不同公司会增加或减少这些人员,但无论怎么变,绝对不会缺少产品、UI、前端、后台、运营这五个职位。其中前端指的有Web前端工程师、Android工程师以及IOS工程师。

工作流程上面已经提到了一些。按照产品、UI、前端、后台的顺序进行功能产品的开发。每个环节交接时,上一级要给清楚下一级需要的所有东西,下一级要进行确认。要在限时时间内做好各自对应的工作。产品居中调控。

协同开发的时候,毕竟是多部门的合作,所以在这个过程中一定会出现很多问题。为了让合作更加顺畅,作为产品经理要做到团队管理的角色。但在IT公司上下级关系没有那么明显,推崇扁平化管理,大家都是平等的,所以要从哄、骗、信任感、责任感、打气、画饼、个人魅力等上面花些功夫,尤其非上班时间能跟同事们打成一片,从而推动工作进行下去。当然老何本人完全靠长相服人,这些方面还真没怎么伤过脑筋。

记住,工作中和同事之间工作的交接一定按规则办事,将所有的交接文档做好记录。不是为了出问题的时候好甩锅,而是为了让整个工作更加清晰,不至于混乱。当然,真出问题,有些锅我们不能背,我们是有存档的(血的教训,有段时间我们产品部连录音都用上了,哈哈)。

功能上线

经历了这么多波折,产品/功能终于要上线了。别急,你还有一些事情需要做。

  1. 再进行一遍测试,该下笨功夫的时候就下笨功夫,不要迷信软件化、自动化。

  2. 通知到所有相关部门的人员,所有人各就各位,做好相关准备工作。

  3. 将产品需要的一些数据进行填充。

  4. 写出功能说明和操作说明给相关人员,甚至于进行一些培训。

  5. 仔细检查一遍产品。

  6. 做好随时沟通运营、测试、开发、客服的准备。

接下来,上线吧!

效果评估

产品/功能上线后,通过市场反馈,我们来评估产品的效果,用以发现不足之处,便于纠正。评估效果需要数据来支持,数据就来源于实施分析中提到的数据埋点、用户反馈、第三方数据等,可以用来反馈用户使用的效果。

重复迭代

产品上线了并不意味着我们工作结束了,随着用户的反馈、市场动态,我们不断地收集到信息来优化我们的产品,也就又进入了需求收集、需求分析……这样的一个一个循环,产品的工作,就是在一次次的循环中,走向更好的未来。

总结

以上相当于将产品经理所有的日常标准化工作都做了一次整体梳理,即便每一条都是点到即止没有细讲,但仍然很长很长。梳理这些内容,得益最大的是我自己,并且将这些工作全都梳理到位不可能仅仅写一篇文章这么简单,我可能要花一年、两年甚至三年五载,这些都是基本功,基本功扎实了,才有资格有立场谈更高层次的商业模式、经营策略、行业研究。

总之,先让自己在路上吧。

转载无限欢迎,但请注明作者「何沧」和原文地址「https://hecang.net/info-58-8931.html」。
如需商业转载或刊登,请联系作者获得授权,感谢您对作者版权的尊重。

© 2018 HeCang 湘ICP备16007463号-1作品版权证:M20170706114133022

公安机关备案湘公网安备 43019002000291号