微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

嗨!菜鸟~我们来谈谈你的新工作文档与思维篇

写给我的第一任助理

一个菜鸟产品经理写给她的菜鸟产品助理的入职培训教材,教材分为“习惯”“流程”“文档”“产品思维”等几个部分。

文档篇

如果我给你一篇文档,让你按照我的格式来写。而实际上你并不明白为什么要写这些内容?为什么按照这个顺序来写?这个内容是不是真的需要?在这样的情况下,你可能会做一些毫无意义的文字堆砌浪费珍贵的时间,或者总是无法确定自己的文字是不是被需要的。

我希望你避免一种“八股”的做事方式,有些严格的规定会让你失去对做这件事情的原因本质的了解,而失去了一些你可以掌控的随机应变。

当然在一切初学者面前,一个专业规范的文档格式对他们的工作是实用的帮助,所以我还是会从“规范”谈起,稍后与你分享一些“灵活”的原则。

规范

首先我们应该了解,规范的文档撰写源于规范的流程(我已经在流程篇中向你介绍过),因我们在流程中做的大部分事情,都会有相对应的工作“产出”,这些产出可以统一被称为“文档”。

策划前期

BRD商业需求文档

BRD是一个在企业商业战略层面撰写的文档,在文档中分析大环境和市场前景,得出产品的商业目标,并核算投入产出等。对于小团队而言……好吧,我认为这篇文档的实用价值不太大。

1. 市场环境分析

2. 问题分析

3. 我们的优势

4. 结论和商业目标

5. 收益与成本

6. 风险与对策

嘿~你在我的文件夹中找不到这篇文档,它的所有内容都在boss的脑子里。

策划中期(产品目标、用户需求、内容功能需求)

MRD市场需求文档

这篇文档说明“怎么做产品”,以达到(BRD中的)商业目标。它会是未来所有文档的参考源头。

1. 文档说明

a) 文档基本信息(公司名称、产品名称、文档创建日期、创建人和联系方式、部门职务)

b) 文档修改记录

2. 市场说明

a) 市场问题(产品、技术、运营、用户、商业模式等)

b) 针对大市场中的目标市场(市场规模、特征、发展趋势等)

c) 结论(市场定位)

d) 团队目标(我们要从这个产品中得到什么)

3. 用户分析

a) 目标用户群体(年龄、收入、学历、地区等)

b) 目标用户特征分析(特点与共性)

c) 用户角色卡:

假设真实存在的用户Gara,为他设计年龄性别、生日、收入职业、居住地、爱好、性格等

根据他的背景推理他的技能情况(熟练使用电脑办公等)

推理与产品相关的特征(使用微信,单身,喜欢皮肤白长头发的女孩子)

针对用户群可以虚拟多个用户角色

d) 用户使用场景

用户Gara如何使用我们的产品,讲一个完整的故事(时间、地点、人物、任务等)。

周五下班途中,在公交车上,无聊又寂寞的Gara打开了微信看看周围有美女在线,加了对方好友,快乐地聊起来……

a) 用户需求和用户的真实需求

用户需求:在旅途中方便地充电。

用户的真实需求:手机电池更耐用。

b) 可能影响用户的因素(设备、网络、速度、信息等)

不仅要罗列因素,还要详细分析这些因素如何影响用户使用产品的过程。

4. 产品说明

a) 用户定位

简单描述产品的目标用户群体。

b) 产品定位

我们将用什么样的产品满足用户需求。

c) 用户需求、产品核心目标

我们的目标用户要从这个产品中得到什么。

我们的产品帮助目标用户解决什么问题。

d) 产品结构

我们需要哪些类型的内容。

我们需要什么样的功能去支撑这些内容。

5. 产品路线

成功标准:了解我们的开发过程,知道我们什么时候到达终点。

产品路路线经常被误解为方向,实际上,成功的标准不见得是以方向衡量的,我们通常告诉自己“满足哪些条件,我就成功了”而不是“向着哪个方向走,我就成功了”。

因此在规划中,我们设定里程碑(需要完成的任务),制定可追踪的指标(需要满足的条件),来评估我们的工作。

一般会以项目甘特图的形式体现,包含时间、任务、说明等内容(如下图)

放松的小剧场:

BRD:嗨~为了放松心情~我们出去玩吧~

MRD:那我们就来商量下去哪里玩,几个人,完成什么任务,空出多少时间,准备多少钱…

B、M:小P快去干活!

接下来我们一起来了解下这个小P

策划后期(界面交互与设计、信息架构、布局与导航设计)

PRD产品需求文档

有时候也叫做产品说明书,最细致也最繁琐的文档,开工之前一定要深呼吸,摆好姿势。这个文档会是所有项目成员做事的直接依据,描述要低调肤浅简单粗暴,这样大家才能愉快滴继续玩耍。

1. 文档说明(略)

2. 语言说明

a) 沟通语,明确与目标用户沟通的语言风格,使用与用户合拍的沟通方式。这是为了避免一些我们自以为很了解的专业术语妨碍了用户的阅读。

b) 命名,在用户沟通方式的基础上,为前台的主要功能进行命名。

如果可能,我们也可以为后台功能做命名。这样前台语言是给用户看的,后台语言是给我们自己看的,把两者对应起来以防错误。这样程序员的沟通压力就不会太大(设计人员更加喜欢使用用户语言,导致程序员的理解困难)。

c) 解释几个重要功能的命名,它们会在以后的文档中被使用,现在就需要统一概念。

3. 产品说明

a) 产品结构

b) 任务流程图

4. 全局说明

全局是指可以被套用在大部分的页面或操作中的一些通用的规则,如果某个内容或功能与全局情况不同,就在细化中另外说明。

以下举例两种全局说明:

a) 设计规范

i. 布局

ii. 图片

iii. 文字

iv. 色彩

v. 按钮

vi. 控件

vii. 元素……

b) 交互规则

i. 页面和元素的切换

ii. 退出软件

iii. 被打断

iv. 不同网络情况

v. 常用手势

vi. 加载方案

vii. 错误处理

viii. 反馈提示……

(退出软件、打断、切换、手势等内容经常使用在APP产品中)

5. 细化说明

接下来我们就要描述清楚产品细节:

i 页面布局和显示规则

ii 页面元素

iii 交互和操作

iv 错误和反馈

v 网络异常

vi 重复点击

viii 操作中断……

除了描述清楚正常情况下的所有内容,还要考虑到特殊场景。

这里占了PRD文档百分之九十的内容,需要点耐心。

我经常使用和上文中“产品结构”相同的顺序来进行说明,从频道、页面、模块、元素进行描述。这种方式适合对技术不太了解的小伙伴,描述的重点是用户看到的部分。

原型

严格来说原型是为了更形象地说明PRD中所描述的页面布局信息,它在需求传递中扮演了重要的角色,并且我们可以让用户使用原型提早进行可用性测试。

它会随着需求的逐渐明确,变得更加精致:

1.低保真:表达布局和重点

2.中保真:表达动态和细节,

3.高保真:仿真产品。

避免常见的错误

客观

主观:“这里要使用第一人称”

客观:“参考文案规范”

避免使用主观的内容,用客观事物做参照可以避免反复修改

具体

“具体”而不是“详细”。

确保文档中不要出现漏洞,清楚明确。

但是不要追求描述每一个细节。

应该包含设计或开发过程中存在的可能会产生混淆的功能定义。

记录

不是“展望未来”,是“记录”当下的决议。

所以我们要小心文档中出现一些不确定的“想象”。

灵活

你完全可以把文档内容拆分开来,或者合并,或者重组,或者删减。你只要确保以下几点:

1. 你想要的内容没有遗漏

2. 你不需要的内容可以没有

3. 你的文档阅读流畅,逻辑可以被理解

Ps:听说点“很好看”那个方块,天上会掉金砖……

产品思维篇

我坚持认为每一个人都有不同的思维方式,这些思维方式或许看上去不太符合别人的逻辑,但是它们让工作丰富多彩,充满惊喜。本篇文章通篇都是我的私货,带有我的各种性格标(缺)签(陷),和一些真实的职场故事,请抱着警惕心围观这些不明觉厉,实际上未可定论的观点。

关我P事系列

行业又有大动作了

如果某个新闻对于你的工作不会产生影响,那么你如果点进去,就是三八了一回~

在我心目中 “阿里和苹果要合作了!”和“周迅要结婚了!”是一个意思,你们感受下。

Gara涨工资了

有两个同事曾经找到我抱怨:新来的应届生工资比我还高凭什么?那个谁这个月拿了5000块奖金凭什么?

站在一个私营企业boss的角度,每一个员工都是要尽量物尽其用的,不会偏心谁就给谁高薪,所以他们的“凭什么”是不存在的。至于觉得自己的工资少了,就申请加工资,这唯一的解决方案。

不要和同事作比较,对比一下现在的自己和过去的自己,进步了多少?

XX产品把菜单放右边了

那么为什么要把自己的黄金时间花在竞争对手身上,而不是研究自己的用户,优化自己的产品呢?提高自己永远比和别人竞争重要得多。

每个人的精力都是有限的,产品岗位接触的知识面愈广,尤其要注意把精力花在关键任务上。

我今天不想加班

“这么早走被老板看到了影响多不好”

我下班约了人吃饭,吃完饭要做家务,做完家务要弹琴,弹完琴要看书,11点以前要上床睡觉,因为我早上要早起锻炼。你看我人生这么充实这么忙碌,我要安排好每一件事情,实在没工夫研究工作之外老板心里怎么想的。

我了解那些业余生活精彩丰呈的小伙伴们,也拥有有趣的见识、强大的执行力、完成任务的动力、同时关注并安排好多件事情的能力。

当然如果老板看不开,要么他飞了你,要么你飞了他,反正都是要飞了的……

产品汪都认可系列

专注核心

这个也很重要,那个也很关键,我们该如何决策?

我们可以试试把某件东西丢掉,如果依然可以完成任务,那么它就不是最核心的,以此类推,不断丢掉,直到把核心找出来。

记住这个核心,并且把精力都花在它身上。

解决问题

我们最早做产品规划时,就关注帮助用户解决问题。当我们开始做产品时,我们关注如何解决产品问题。

所以让“解决问题”成为你的习惯。

先做了再说

一而再,再而衰,三而竭,没激情啥事都做不了了,所以尽早开始吧。

如果任务太艰难,就拆分成几个小任务,每完成一个都能叠加一层动力(比如这一系列的文就是被拆分任务的结果)。

嘿,如果你现在有一件特别想做的事情,定个轻松点的目标,立刻开始吧~

不是每个汪都这么做系列

和你吵架的都是真爱

和你拍桌子对骂的人,很值得交往……真的……试试就知道了,相信我……

拖延的艺术

那些不是核心的任务,完全可以等到万不得已才开始。

去年我打算骑山地车上下班,我只需要买辆车,然后第二天就开始骑了。骑上之后才在半年内慢慢补齐了所有的装备。这么长的时间足够我形成习惯,一点都不难。

把拖延症放在合适的地方,能帮助我们做减法。

培养自己的爱好与乐趣

大多数情况我们不会把工作当成生活的全部,培养一个终身爱好吧,它将带来巨大的快乐和成就感。一个和工作南辕北辙的爱好也会带给我们一些意外的惊,你将拥有一些同行者所没有的创造力和想象力。

我们非常愿意在产品中保留制作者的个性。

爱好能让人体会到一种因热爱而存在的天赋,让你觉得自己不是凡人~

规划自己的人生,而不是规划职业

(请不要对人力资源说这句话,后果自负……)

我们希望自己成为一个什么样的人,职业只能帮助我们完成这个愿望。

“产品经理”不能成为我的代言词。就好像很多销售人员就是有一种“销售人员”的味道,大家称之为“职业素养”。好友中,有一个名企的一线销售人员,得到多年全国销售冠军,他身上有艺术家的味道,有流浪者的味道,就是没有“销售人员”的味道。

别让职业绑架你,你应该拥有一个精彩又特别的人生。

1.以上观点建立在如下背景:小公司、小项目、菜鸟产品经理。

2.我已经在工作中极为依赖我的助理,她也是我写这系列的直接动力,在这里感谢她的巨大帮助。

3.本系列4篇全部完结,居然还是觉得有好多东西没写,感谢大家2个月来的支持,只希望有稍许帮助。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


迭代器模式(Iterator)迭代器模式(Iterator)[Cursor]意图:提供一种方法顺序访问一个聚合对象中的每个元素,而又不想暴露该对象的内部表示。应用:STL标准库迭代器实现、Java集合类型迭代器等模式结构:心得:迭代器模式的目的是在不获知集合对象内部细节的同时能对集合元素进行遍历操作
高性能IO模型浅析服务器端编程经常需要构造高性能的IO模型,常见的IO模型有四种:(1)同步阻塞IO(BlockingIO):即传统的IO模型。(2)同步非阻塞IO(Non-blockingIO):默认创建的socket都是阻塞的,非阻塞IO要求socket被设置为NONBLOCK。注意这里所说的N
策略模式(Strategy)策略模式(Strategy)[Policy]意图:定义一系列算法,把他们封装起来,并且使他们可以相互替换,使算法可以独立于使用它的客户而变化。应用:排序的比较方法、封装针对类的不同的算法、消除条件判断、寄存器分配算法等。模式结构:心得:对对象(Context)的处理操作可
访问者模式(Visitor)访问者模式(Visitor)意图:表示一个作用于某对象结构中的各元素的操作,它使你在不改变各元素的类的前提下定义作用于这些元素的新操作。应用:作用于编译器语法树的语义分析算法。模式结构:心得:访问者模式是要解决对对象添加新的操作和功能时候,如何尽可能不修改对象的类的一种方
命令模式(Command)命令模式(Command)[Action/Transaction]意图:将一个请求封装为一个对象,从而可用不同的请求对客户参数化。对请求排队或记录请求日志,以及支持可撤消的操作。应用:用户操作日志、撤销恢复操作。模式结构:心得:命令对象的抽象接口(Command)提供的两个
生成器模式(Builder)生成器模式(Builder)意图:将一个对象的构建和它的表示分离,使得同样的构建过程可以创建不同的表示。 应用:编译器词法分析器指导生成抽象语法树、构造迷宫等。模式结构:心得:和工厂模式不同的是,Builder模式需要详细的指导产品的生产。指导者(Director)使用C
设计模式学习心得《设计模式:可复用面向对象软件的基础》一书以更贴近读者思维的角度描述了GOF的23个设计模式。按照书中介绍的每个设计模式的内容,结合网上搜集的资料,我将对设计模式的学习心得总结出来。网络上关于设计模式的资料和文章汗牛充栋,有些文章对设计模式介绍生动形象。但是我相信“一千个读者,一千个
工厂方法模式(Factory Method)工厂方法模式(Factory Method)[Virtual Constructor]意图:定义一个用于创建对象的接口,让子类决定实例化哪一个类,使一个类的实力化延迟到子类。应用:多文档应用管理不同类型的文档。模式结构:心得:面对同一继承体系(Produc
单例模式(Singleton)单例模式(Singleton)意图:保证一个类只有一个实例,并提供一个访问它的全局访问点。应用:Session或者控件的唯一示例等。模式结构:心得:单例模式应该是设计模式中最简单的结构了,它的目的很简单,就是保证自身的实例只有一份。实现这种目的的方式有很多,在Java中
装饰者模式(Decorator)装饰者模式(Decorator)[Wrapper]意图:动态的给一个对象添加一些额外的职责,就增加功能来说,比生成子类更为灵活。应用:给GUI组件添加功能等。模式结构:心得:装饰器(Decorator)和被装饰的对象(ConcreteComponent)拥有统一的接口