快生活 - 生活常识大全

创业公司的产品新人怎么搞活新项目


  作为一个产品新人,一开始往往满腔热心投入产品工作中,然而在项目流程中,还是会因为出错而被团队、被老板质疑。笔者结合这样的疑问,向我们分析了如何应对这样的状况。
  不久前,老同学说自己最近转行做产品了,由入行时的信心满满到现在的满脸疲惫,也不过几个月的光景。
  比如最近在跟的一个项目,光是需求评审就过了不下五遭,哪怕线下准备很充分了,但依然每次都被开发测试怼得无地自容。现在一提起过需求,就很紧张。
  于是我问了下她的项目流程,她说:接到需求后,她大概了解了情况,就开始画原型图,画的时候有疑问,再去找甲方沟通确认,然后反复更改原型图。
  画完后,就拉着老板和项目组同学开始一页页过原型,然后再回去改。于是,这样的故事每天在不停地上演着,直至自己心力憔悴,团队不信任你,老板对你质疑……
  的确,刚入坑产品经理时,很多人都曾想象自己是来指点江山挥斥方遒的,但事实上除了一地鸡毛还是一地鸡毛。
  这种现象更多地出现在创业公司,或是没有前人引路的产品,俗称"野路子产品经理"。
  这些人只能凭着自己的直觉去闯去试去摸索,不停地在挖坑填坑中让自己成长。极少数幸运的同学从坑里爬出来了,但更多的都是被坑给埋了。
  所以,想通过这篇文章跟大家聊聊,刚接手一个项目时该怎么下手,能让自己更加游刃有余,能让开发测试更加信服。文章将从业务意向沟通、业务梳理、方案设计、交付产出四个产品核心技能方面进行阐述。(本篇仅局限于接手项目的讨论,不包含自主探索类产品)
  Step1:业务意向
  业务意向沟通,主要是了解项目的背景、目的和价值。
  所谓背景,就是要了解这个项目是由谁提出来的,是基于什么场景什么考虑提出的这个业务意向?提出的意向是想解决哪些用户群体的哪些问题?解决之后能带来什么样的价值?这个项目涉及到哪些干系方?如果延期或者不做,又会怎么样?
  这个时候,趁着手干事儿前,尽可能多问几个为什么,通过为什么来了解这个项目更多的信息,尤其是业务方(或其他项目提出者)未告诉你或者不想告诉你的事儿。
  要知道,为了让你尽快推动实施项目,业务方也会想方设法找出不得不做的理由/借口;这时候就要你擦亮眼睛,辨别这确是客观的理由,还是主观的借口。这对你接下来每一步的判断,至关重要。
  Step2:业务分析梳理
  在沟通确认完业务意向后,就要开始对业务意向抽丝剥茧,一层一层剥洋葱式的对业务进行拆解、梳理,最终组装成产品语言,交付至项目团队。
  本章节,我们将会从用户故事、产品业务形态、状态流程图、业务流程图、页面流程图等维度展开。
  1. 用户故事
  产品设计最核心的三个要素,分别是:用户、场景、需求。产品设计,就是不断地解决用户在特定的场景下的需求。
  用户:用户是谁,有哪些角色,也就是涉及到哪些干系方;
  需求:核心需求是什么,即不同的用户,分别在什么场景下会使用;
  场景:产品满足了用户的哪些需求。
  而用户故事,就是这三要素的组成。理清用户故事后,也就明确了不同的用户角色需要系统支持哪些功能了。以网点充值为例:
  因此,当开始接触一个项目的时候,首先需要梳理的就是这个项目里涉及到了哪些用户,分别在什么样的场景下有什么样的需求。而在这里面,最核心的用户、场景、需求是什么,辅助核心元素打造整个业务生态的又是什么。分清主次之后,产品的规划节奏随之就很明朗了。
  (注意:增加、减少功能并不是关键,关键在于能不能解决用户的问题。而很多产品新人也最容易在功能点上纠结,这时候就需要考虑下产品设计的三要素了。
  2. 产品业务形态
  产品业务形态,主要是用来描述产品的基本框架,简述业务的整体面貌。
  这个环节更关注用户角色、信息和渠道,以及各自之间的流转关系。简单来说,就是通过这样一张简单的图,能够让人快速理解这个业务是怎么运作的。
  比如,站点在系统里的关系,就是发起充值;站点发起之后,其他参与系统又分别在其中担任了怎样核心的角色。
  或者可以再看下抖音的业务形态:只是简单提到了内容生产者和内容消费者,当然这期间还有平台运营者在运筹帷幄,如果加上那会更加完整。
  3. 状态流程图
  状态流程图,顾名思义,就是以"状态"为对象的流程图,描述的是状态的正常、异常分支的流向,前置后置条件。
  要注意的是,状态流程图不是每个项目必须的,而是要取决于实际的项目,根据项目实际来判断。比如抖音没有状态也就不会有状态流程图。
  对于状态流程图来说,建议按下述三个步骤进行:
  梳理主流程,明确主流的状态
  拆解各个环节的异常分支,对各类异常情况分析完成后进行整合
  完成整个业务生命周期里的状态流转图
  4. 业务流程图
  业务流程图,这个大家应该都很熟悉了。不管是toC还是toB,都会有业务流的概念,比如APP注册/登录的流程,淘宝购物的流程,天猫退货的流程等等。这块的技能已经有太多人讲了,这里就不详细展开了。注意以下两点就行:
  涉及到多个业务方或者多个系统时,泳道图一定要"切图"。横向,相关系统;纵向,拆解的阶段。
  根据状态流程图梳理的业务,绘制业务流程图,梳理流程的前置、后置条件和异常分支等。
  以充值的为例,看下大概的框架:
  5. 页面流程图
  需要交互的系统较多,在原型评审前,帮助组内同学快速建立产品的页面概貌。那页面流程图和原型图有什么差别呢?
  页面流程图,只要把涉及到的页面整理出来,然后把每个界面参与到的核心事件(核心操作按钮)表述出来即可。这个地方一定要克制,要克制,要克制。
  Step3:方案设计
  经过上述的业务拆解之后,这时候原型该是怎么样的:会有哪些界面,每个界面分别做些什么事,有哪些按钮,哪些字段,这些按钮字段的定义分别是什么。这些应该都在你心里了对不对?
  然后就是绘制原型图的时候,注意细节,不要有遗漏,那就很棒啦。
  1. 页面交互图
  2.相关注释
  ①权限说明:数据权限、菜单权限
  ②数据内容:
  筛选条件的范围、规则和交互
  列表数据的排序规则
  列表字段的定义、来源、限制、规则等描述
  ③操作说明:
  操作的前置条件、后置结果
  异常逻辑
  交互样式
  Step4:交付产出物
  走到这一步的话,恭喜你,再把资料整理整理,然后就愉快地去约你的项目组同学去评审吧。相信我,这个时候,开发小哥哥们肯定会很喜欢你咯。
  不过更建议在业务梳理完成的时候,就先找开发测试同学先沟通一遍,剔除无法实现、实现复杂的,甚至可能在沟通中会有更好的方案哦。当然啦,这个阶段可以只约核心同学哈。
  结语
  好啦,关于项目分析的分享就到这里啦~~在最后,预祝各位野路子的产品新人,能够在产品之路上越走越远,与开发测试的小哥哥小姐姐们都能和睦相处哦。
网站目录投稿:语秋