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

AI时代,如何更快入行抢占红利得高薪?前阿里巴巴产品专家带你15天入门AI产品经理。了解一下>

作为一个产品新人,一开始往往满腔热心投入产品工作中,然而在项目流程中,还是会因为出错而被团队、被老板质疑。笔者结合这样的疑问,向我们分析了如何应对这样的状况。

不久前,老同学说自己最近转行做产品了,由入行时的信心满满到现在的满脸疲惫,也不过几个月的光景。

比如最近在跟的一个项目,光是需求评审就过了不下五遭,哪怕线下准备很充分了,但依然每次都被开发测试怼得无地自容。现在一提起过需求,就很紧张。

于是我问了下她的项目流程,她说:接到需求后,她大概了解了情况,就开始画原型图,画的时候有疑问,再去找甲方沟通确认,然后反复更改原型图。

画完后,就拉着老板和项目组同学开始一页页过原型,然后再回去改。于是,这样的故事每天在不停地上演着,直至自己心力憔悴,团队不信任你,老板对你质疑……

的确,刚入坑产品经理时,很多人都曾想象自己是来指点江山挥斥方遒的,但事实上除了一地鸡毛还是一地鸡毛。

这种现象更多地出现在创业公司,或是没有前人引路的产品,俗称“野路子产品经理”。

这些人只能凭着自己的直觉去闯去试去摸索,不停地在挖坑填坑中让自己成长。极少数幸运的同学从坑里爬出来了,但更多的都是被坑给埋了。

所以,想通过这篇文章跟大家聊聊,刚接手一个项目时该怎么下手,能让自己更加游刃有余,能让开发测试更加信服。文章将从业务意向沟通、业务梳理、方案设计、交付产出四个产品核心技能方面进行阐述。(本篇仅局限于接手项目的讨论,不包含自主探索类产品)

Step1:业务意向

业务意向沟通,主要是了解项目的背景、目的和价值。

所谓背景,就是要了解这个项目是由谁提出来的,是基于什么场景什么考虑提出的这个业务意向?提出的意向是想解决哪些用户群体的哪些问题?解决之后能带来什么样的价值?这个项目涉及到哪些干系方?如果延期或者不做,又会怎么样?

这个时候,趁着手干事儿前,尽可能多问几个为什么,通过为什么来了解这个项目更多的信息,尤其是业务方(或其他项目提出者)未告诉你或者不想告诉你的事儿。

要知道,为了让你尽快推动实施项目,业务方也会想方设法找出不得不做的理由/借口;这时候就要你擦亮眼睛,辨别这确是客观的理由,还是主观的借口。这对你接下来每一步的判断,至关重要。

Step2:业务分析梳理

在沟通确认完业务意向后,就要开始对业务意向抽丝剥茧,一层一层剥洋葱式的对业务进行拆解、梳理,最终组装成产品语言,交付至项目团队。

本章节,我们将会从用户故事、产品业务形态、状态流程图、业务流程图、页面流程图等维度展开。

1. 用户故事

产品设计最核心的三个要素,分别是:用户、场景、需求。产品设计,就是不断地解决用户在特定的场景下的需求。

  • 用户:用户是谁,有哪些角色,也就是涉及到哪些干系方;
  • 需求:核心需求是什么,即不同的用户,分别在什么场景下会使用;
  • 场景:产品满足了用户的哪些需求。

而用户故事,就是这三要素的组成。理清用户故事后,也就明确了不同的用户角色需要系统支持哪些功能了。以网点充值为例:

因此,当开始接触一个项目的时候,首先需要梳理的就是这个项目里涉及到了哪些用户,分别在什么样的场景下有什么样的需求。而在这里面,最核心的用户、场景、需求是什么,辅助核心元素打造整个业务生态的又是什么。分清主次之后,产品的规划节奏随之就很明朗了。

(注意:增加、减少功能并不是关键,关键在于能不能解决用户的问题。而很多产品新人也最容易在功能点上纠结,这时候就需要考虑下产品设计的三要素了。

2. 产品业务形态

产品业务形态,主要是用来描述产品的基本框架,简述业务的整体面貌。

这个环节更关注用户角色、信息和渠道,以及各自之间的流转关系。简单来说,就是通过这样一张简单的图,能够让人快速理解这个业务是怎么运作的。

比如,站点在系统里的关系,就是发起充值;站点发起之后,其他参与系统又分别在其中担任了怎样核心的角色。

或者可以再看下抖音的业务形态:只是简单提到了内容生产者和内容消费者,当然这期间还有平台运营者在运筹帷幄,如果加上那会更加完整。

3. 状态流程图

状态流程图,顾名思义,就是以“状态”为对象的流程图,描述的是状态的正常、异常分支的流向,前置后置条件。

要注意的是,状态流程图不是每个项目必须的,而是要取决于实际的项目,根据项目实际来判断。比如抖音没有状态也就不会有状态流程图。

对于状态流程图来说,建议按下述三个步骤进行:

  1. 梳理主流程,明确主流的状态
  2. 拆解各个环节的异常分支,对各类异常情况分析完成后进行整合
  3. 完成整个业务生命周期里的状态流转图

4. 业务流程图

业务流程图,这个大家应该都很熟悉了。不管是toC还是toB,都会有业务流的概念,比如APP注册/登录的流程,淘宝购物的流程,天猫退货的流程等等。这块的技能已经有太多人讲了,这里就不详细展开了。注意以下两点就行:

  • 涉及到多个业务方或者多个系统时,泳道图一定要“切图”。横向,相关系统;纵向,拆解的阶段。
  • 根据状态流程图梳理的业务,绘制业务流程图,梳理流程的前置、后置条件和异常分支等。

以充值的为例,看下大概的框架:

5. 页面流程图

需要交互的系统较多,在原型评审前,帮助组内同学快速建立产品的页面概貌。那页面流程图和原型图有什么差别呢?

页面流程图,只要把涉及到的页面整理出来,然后把每个界面参与到的核心事件(核心操作按钮)表述出来即可。这个地方一定要克制,要克制,要克制。

Step3:方案设计

经过上述的业务拆解之后,这时候原型该是怎么样的:会有哪些界面,每个界面分别做些什么事,有哪些按钮,哪些字段,这些按钮字段的定义分别是什么。这些应该都在你心里了对不对?

然后就是绘制原型图的时候,注意细节,不要有遗漏,那就很棒啦。

1. 页面交互图

2. 相关注释

① 权限说明:数据权限、菜单权限

② 数据内容:

  • 筛选条件的范围、规则和交互
  • 列表数据的排序规则
  • 列表字段的定义、来源、限制、规则等描述

③ 操作说明:

  • 操作的前置条件、后置结果
  • 异常逻辑
  • 交互样式

Step4:交付产出物

走到这一步的话,恭喜你,再把资料整理整理,然后就愉快地去约你的项目组同学去评审吧。相信我,这个时候,开发小哥哥们肯定会很喜欢你咯。

不过更建议在业务梳理完成的时候,就先找开发测试同学先沟通一遍,剔除无法实现、实现复杂的,甚至可能在沟通中会有更好的方案哦。当然啦,这个阶段可以只约核心同学哈。

结语

好啦,关于项目分析的分享就到这里啦~~在最后,预祝各位野路子的产品新人,能够在产品之路上越走越远,与开发测试的小哥哥小姐姐们都能和睦相处哦。

 

本文由 @泡泡 原创发布于人人都是产品经理,未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
1人打赏
评论
欢迎留言讨论~!
  1. 碰到那种不看流程图也是很无奈啊 :arrow:

    回复
    1. 哈哈哈,如果山不就我,那只能我去就山咯。流程图不仅是为了开发能看明白,也是为了自己思路更清晰啦。对于不看流程图不看原型图的开发,个人觉得产品的思路清晰逻辑有调理尤为重要!

      回复
  2. 上述页面、流程图全部都做的话会耗费大量时间精力,还是要根据公司实际情况来确定一套更合适的产品流程。

    回复
    1. 是的,没有什么流程是固化的,能高效解决问题的就是好流程。实际使用中,不仅需要根据公司情况来取舍,也需要根据项目情况、产品所在的生命周期、团队成员等多种因素来判断。

      回复
  3. 写得不错,貌似是快递行业同行啊,可以交流下啊,哈哈。

    回复
    1. 嘿嘿,不是快递行业的同行,也可以多多交流哇 :smile:

      回复
  4. 写的还不错

    回复
    1. 谢谢哦 :oops:

      回复