到底有哪些优势,产品专员工作实录

一个人对业务比较熟悉,他在工作中会尽可能完善的考虑到可能出现的异常情况,提前做好各种逻辑判断以及相应的反馈处理,这样就避免了产品上线后因异常遇到更大的麻烦。

然后,在此调研的基础上与管理业务人员的管理层进行对话,主要想获取的信息是从他们角度系统需要满足他们的哪些需求,以及他们怎样能更方便地通过系统管理业务人员,实现业务的分配和高效地完成相关工作。

产品原型设计过关后,通知UI做图,组织评审会议。研发评审会上产品讲解需求,讲解需求也是门学问,自己做的原型一定要信心满满,最好在讲解一个模块后留给开发反馈的时间,答疑。会议最后确定可行的需求模块。项目经理根据需求内容预估开发周期,无异议后就可以进入研发阶段了。评审后产品需求可能会稍作修改,通知UI修改效果图(若需要),之后上传至项目管理软件上,整个产品准备阶段告一段落,后面会比较轻松。我们现在在做一款微信公众号的产品,开发周期基本是小功能一周一迭代,功能稍微复杂的两周一迭,保持着小步快跑的节奏。我们的开发人员,都是90后,相处起来也比较融洽。

对业务的熟悉程度和其做产品的能力是对产品经理是否优秀的考量。除此之外,沟通能力和处理事情的能力也很重要,别小瞧这方面的能力,很多时候都关系到事情的成败。

大家有了共同的奋斗目标后,项目的开发进度会按照之前绘制的甘特图顺利进行。然而在实际的项目开发中,产品往往会因为各种原因延期。其中一个最大的因素就是业务部门的需求产生变动。这时候需要产品经理具有强大的沟通能力以及产品规划能力去协调开发与业务需求之间的矛盾。

研发的差不多的时候,开发人员会提测,测试同事会在本地测试。产品需要辅助测试,测前端可以让测试将测试地址生成二维码发给你,后台可以让测试直接发测试地址,打开他的本地服务器。及时跟进测试,避免最后与原型出现较大偏差。我们在本地上测试没有问题后直接上生产环境。一些公司会把版本先发布在一个准生产环境上,产品进行验收。这里需要强调产品一定要在测试阶段辅助跟测,因为最后负责验收的是产品人员。

我们从调研中一般能明白正常的流程,假设一个流程从充值到支付完成,如果只是充值成功的话这个逻辑可能没什么。但要是过程中出现什么意外,就难以料到了,而在实际工作中一个好的产品经理与一个差的产品经理的能力差别往往就体现在这方面。再拿APP版本兼容性来说,如果一个产品经理做了多年移动端产品,可能在他脑海中已经形成了一个思维定式,每当做新功能的时候,他会很自然的考虑到旧版本跟新版本的兼容问题。但如果一个产品经理没有这方面的经验,就比较容易忽略这个问题。

PRD撰写完成后,就需要进行PRD的评审会议。PRD评审会议需要参与该项目的各个团队的核心人员。包括设计部门的Leader,前端的Leader,后端的Leader,测试部门的Leader,项目的发起人,项目的审核人,以及和此项目相关的其它产品负责人。如果有Leader无法参与会议时需要该Leader指定人员代替参加。

我的领导是一名有着8年产品经验的大牛,丰富的带人经验,在他手下,每次写的需求,他会过一遍,就相当于产品评审了,批注标出你页面设计、逻辑上的不足,甚至会自己写一份同样的需求,让你和他对比,看自己逻辑、思路上有哪些没想到的地方,思维严谨全面,语言言简意赅,开发问问题时能够立即反馈并找到解决方案,非常熟悉产品的各个流程。来到这里一年的时间,虽然开始很有压力,但是自己进步神速,建议产品新人在选择公司时,一定要问清楚公司现有产品的人员结构,有个老司机带真的是站在巨人的肩膀上。好的产品一定是个说话、做事条理清晰的人。遇到事情首先在脑袋里会把事情分类。包括记录的笔记,不是杂乱无章的记录,而是将事情想清楚并归纳分类。新增临时需求或其他要求,不是只告诉你怎么做,而会告诉你为什么要这么做,这么做的原因是什么,这是优秀产品的共同点,告知更改原因会增添开发对你的认同感,以德服人。产品在平时一定要注重自己对工作的态度,要严谨,认真,负责,找到最佳解决方案。时刻传达给开发:我很靠谱,我的每一个需求都是可以走通的,尽管按照需求走。你在做,开发在看。产品经理的职责其实是协调上下级,能将上级的任务准确传达给下级,并让下级执行完成,产品经理起到中介的作用。所以和开发搞好关系,给开发留下好印象,能让开发相信你很重要。

本来以为工作久了,经验多是一种优势,但是在产品经理这一行,好像经验多了,年龄大了,在某些公司的招聘中反而成为了一种劣势,身边朋友也不乏有跟我一样有此种焦虑的。这篇文章我就想帮那些大龄产品经理辩解一下,看看大龄产品经理到底有哪些优势。

短期的工作中,对产品设计、需求、团队管理和自我都有了新的认知。

随着互联网行业的快速增长,衍生了众多互联网职业,产品,开发,运营,测试,运维。今天要说的是产品,在我身边,好多开发同事都表示有想转产品的意向,越来越多的人开始转行做产品,那么大家知道产品每天需要做什么吗,今天分享几点关于产品的日常工作,希望能为产品新手或准备转行的预产品经理提供参考,能够帮助大家初步了解互联网产品经理这个职业。

云瑞,微信公众号:马虎眼,人人都是产品经理专栏作家。原片刻产品经理,6年产品人,走在内容社交产品路上,死磕产品设计,喜欢玩各种APP,玩桌球,打羽毛球,欢迎与大家交流。

2.对需求的认知

测试阶段

富有经验的产品经理在行业内工作多年,做过的、了解的产品也比较多。有些产品即使自己没做过,也看过或听别人说过,对很多产品形态和逻辑规则有所了解,所以他们懂的更多的产品实现方案。

团队管理时,要让每一个人意识到自己和自己所做的事情是有价值的。

需求的主要来源一是产品自身功能新增,优化,二是老板和其他部门的需求,某种程度上说,老板、市场、渠道的需求反馈也可以理解为是对市场调研的结果反馈。公司每周一进行一次周例会,参会人员主要是各部门的主管,老板,产品,风控,财务,渠道,市场。主要内容是研发进度汇报,收集老板、各个部门的新需求,分享前方最新的业务方向,战略调整,商讨下期需求,产品立项一般都是在例会上就确定好了。

拿我最近遇到的案例来说,我们公司最近想做一个内容开放平台,目的是把我们的内容分发给不同的流量渠道。因为之前我们的内容只面向一个渠道,有些问题压根不存在,但是后续随着渠道数量的增多,很多问题就要考虑的更全面。当时负责这个事情的产品经理很快就找到了方案,让运营人员在内容上架的时候勾选渠道,已勾选的则意味着上架。当时来看这个方案的确可以满足需求,但是很快就遇到了更大的问题,后续如果内容在不同的平台定价不同、上架时间不同,这样的做法显然就不合适了。所以后来不得已又返工,开发了新的功能。

同时,在调研过程中更加重要的一点是产品需要和公司的战略规划同步。而公司的战略规划与业务息息相关。传统企业都是业务催生需求,然后将需求传递给开发部门,开发部门进行研发以支持业务部门。

来到一家新公司,首先要观察该公司现有的产品工作流程是怎么样的,可以利用熟悉业务的这段时间大概了解公司的整体工作流程。就说我们的产品技术部门,总体流程为需求收集、产品设计、研发评审、研发阶段、测试阶段、产品验收、生产环境。

题图来自 Pexels,基于 CC0 协议返回搜狐,查看更多

PRD一定要详细和完备。如果有开发人员看了PRD还是不知道该如何做,那么就是产品自己撰写文档和设计上出的问题了。当然,并不是所有问题都能通过文档和原型解决,口头上的交流也是有必要的。

研发过程中开发人员可能会遇到一些业务、逻辑上的问题,这时候你要做好随时解惑的准备,开发会为你解释技术上走不通的地方,你需要提供另外一个可行的方案或者提供思路。开发会可能还会问一些细节上的东西,比如和第三方合作的时候,这个地方的放款是实时放款还是需要等待回调结果。你要想清楚,并说明为什么这么做。解决问题有很多种,你要做的就是确认一种,不要让开发选择,让开发去执行。要听懂开发真正问的问题,因为大多数程序员表达问题的语句都比较简洁,你要学着去理解他表达的意思。

  1. 画原型、写文档效率更高

我们也讨论了很久,如何在现有流程解决这些需求,技术难点有哪些。

都说产品行业门槛低,看招聘要求就知道,具备良好的沟通能力,逻辑思维能力,乍一看,这不就是说的自己吗,有的甚至没有经验要求,好像每个人都可以做产品。但是作为一名有8年产品经验大牛带的产品亲身告诉你,做产品一点也不简单。

图片 1

MRD评审后,就要开始进行详细的PRD撰写,与产品原型的设计。产品原型的设计需要查阅很多相关的资料。查阅的资料都和自己要设计的产品相关。下面是产品设计的一些个人总结(之前另一篇文章中提到过:三个步骤做好后台产品)。

产品经理负责的事情比较杂,合理规划自己时间,平时多培养自己的逻辑反应能力,立即反馈、归纳总结能力,多跟几个项目,认识自己的不足,多反思,日积月累,相信你一定能成为一名优秀的产品经理。

要想对功能考虑的更长远,也是基于产品经理对业务的熟悉和积累的做同类产品的经验。有些是自己踩过的坑,再次遇到肯定要避免历史重演。

有了这一点,之后的开发大家的积极性和心态都会发生变化。而这仅仅是因为一个人半个小时的产品讲解。

研发评审

责任编辑:

1.长时间观察并记录业务人员操作系统的过程,并在业务人员进行工作的时候与之交流,找出产品还不尽人意的地方。

需求收集

  1. 对产品模式了解的比较清楚

每个公司对产品的认识都不一样。每个人对产品的认识也不一样。产品的作用除了在于产品的策划与设计外,更重要的是要充分调动团队成员,发挥团队最大的作用,并推动项目顺利前进,解决项目开发过程中遇到的问题。

产品设计

  1. 懂得更多的解决方案

图片 2

还有一些每天要做的,比如上班第一件事打开公司前、后台网站,看是否具有异常,查看公司数据,尤其是支付类型的数据,比如我们接入了第三方支付公司,每天要关注支付、代扣订单的支付结果,逾期订单。处理、解答随时可能出现的各部门发来的问题,解决市场反馈的用户操作过程中出现的bug,解答开发的问题,规划下期需求,有的产品可能还需要外出,跨公司沟通。

#专栏作家#

产品最好快速进行迭代开发,一是在迭代过程中,对需求有更好的理解,二是减少产品维护的成本。除了产品本身外,市场变化的速度实在太快了,也许只要慢一步原有的市场就会被其它产品占领。

版本上完要看生产环境上有没有问题,由于我们每天有业务需求,为了避免更新版本影响用户办理业务,我们一般是每周四晚上上线,线上能试的模块没有问题后,剩下的就是等待其他部门第二天反馈(比如后台审核权限,产只能由风控部门审核),这样出了什么问题可以第二天解决,尽量避免周五上线。版本运行正常后开始准备下一期需求,重复流程,一个产品迭代周期算是结束。

当要做一个新产品的时候,只要产品终端相同,面对需求,有经验的产品经理能更快速的想到该用何种产品形态。当产品遇到问题的时候也知道该使用哪种方案去解决。

很多时候,业务部门觉得技术部门永远无法满足他们的需求,导致很多客户因此丧失或者影响正常工作。而技术部门又会觉得业务部门提出的很多需求都是无理取闹。两者站在不同的角度去看待对方是产生矛盾的根源。矛盾是否具有可协调性,就是产品经理需要深度考虑的问题。

研发阶段

忘记了是谁曾说过,人每走的一步都算数。此话用来概括本文主题“产品经理的经验有什么用?”亦是可以的。

我所在的公司,熊叔是第一个让开发与产品在产品立项时,同时主动鼓掌的一个人。

有些功能是所有产品标配的,这样的话彼此间有互相借鉴性。即使产品类型不同,但有些功能也是通用的,例如登录、注册,基本各个产品都有。如果你之前做过类似的功能,在做新产品的时候就会有更熟悉的应用,即使有些许不同也能更快的上手。

经历过才明白,需求万变,努力不变。随着需求的不停变更,产品的形态也在不停的变化。

如果当时负责这个事情的产品经理能够考虑的更长远一些,最开始就采用一种为以后可持续,扩展性更好的方案,那么后续再有新需求基于之前的功能加即可,完全不需要再把之前的推倒,重新再来了。

产品设计的过程当中分了三大步骤。

本文原创发布于人人都是产品经理。未经许可,禁止转载。

一个新型的互联网公司,做产品的思路与方法与传统的企业有些不同。先确认公司的战略规划,依据公司的战略规划与得到的需求调研结果着手进行产品设计与开发。

对业务的熟悉程度就完全要依靠时间的积累了,很多产品经理可能连续几年都会做同一类产品,这样的话他们对这类产品的业务就会比别人更熟悉。例如一个做过金融类产品的产品经理,他们对于充值、支付、提现这些方面的业务逻辑就会更了解。有的人可能会觉得这没什么,即使一个人不熟悉,但是经过一番调研后也会明白的。且不说有些信息是很难从调研中获得的,即使可调研也没法保证调研的结果就一定真实。况且调研还需要花费不少时间,这对某些公司来说是不愿接受的。

社会在不断地发展,时代在不断地进步,尤其是走在社会最前沿的互联网行业更是瞬息万变。不论是市场的变化还是相关技术的变更都对产品的从业之路有着深深地影响。

我们列举一种工作中的实际情况,一件事情可能别人答应你交付工作成果的时间是周五,如果你严格按照这个时间点来执行的话,最后会发现项目没有完成。有一些不确定因素,一两个人不靠谱,一、两个环节延迟,就会造成多个环节延迟,项目完不成就是必然的结果。

产品设计完成的产出物为PRD。PRD更像是一个产品字典,独立于原型外,而又包括原型。PRD的作用就是为了能够让产品开发人员能够正确地理解产品然后进行正确的开发。

分享画原型、写文档的技能一直是产品经理圈内长久存在的话题,但不知道大家有没有这样的感触,工作时间久了以后,你画原型,写文档的效率自然会更高。之所以产生这样的结果,客观因素上讲有三因素,第一是熟能生巧,工作经验久,画过的原型,写过的文档多了,自然就更熟练;第二有些产品可能跟你之前做过的产品有些类似,把自己做过的东西再做一遍肯定会更快了;第三点要说的就是对工具的熟练使用了。

任何一个职业的入门都不是那么容易。庆幸的是,这条道路只要你找到了方向,并坚持不懈,你就会离它越来越近。

  1. 对工作中的不确定性早有预估

2.产品梳理

时间过得很快,一转眼我入行做产品已经有7年的时间,在公司里已不能被称之为“小王”。不知什么时候开始,发现很多公司招人的时候都会写上对年龄的要求,类似于90后优先考虑这样的字眼,因此也让我因为年龄有了一种危机感。

3.对自团队管理的认知

  • 一是因为经验,之前做过类似的工作,对于技术的开发时间心理大概会有预估;
  • 二是工作时间久了,接触的人多了,看人更准,对于合作同事的做事风格有一定了解。虽然别人跟你说的是一个样子,但自己心里也有一杆秤,对于过程中的不确定性提前做好防范会更靠谱一些。

在PRD评审会议中,由产品经理对PRD进行讲解。在产品经理讲解的过程中,与会人员有任何疑问都可以提出。PRD评审会议上的主要目的是让大家对产品达成共同的认知。如果与会人员没有任何异议,即表示PRD审核通过。之后再有任何问题需要直接寻找产品经理沟通。评审会议中,各个Leader就需要进行资源的分配。各个部门的资源由各个部门的Leader进行分派。资源分配完成后,产品经理特别需要注意的地方就是定下产品开发各个阶段完成的时间,以保证产品开发的进度。各个Leader确认好资源分配与定下产品开发节点的时间后,PRD的评审会议就算告一段落。

要做到这一点,背后也是有长时间积累的。原因主要有两个:一是因为对方平时对互联网比较关注,经常了解一些互联网资讯或者看一些相关书籍,对于互联网的一些商业模式,一些玩法都比较清楚;第二跟其工作关系肯定也是分不开的,不仅是自己工作的经验,也时常体验一下其它产品。看到的、使用的多了,没吃过猪肉,也见过猪跑。

微信产品经理Kant将需求的本质理解为“动机”。和最近看的《精益创业》中提高的“五个为什么”会议非常一致,比找到问题和解决问题更加重要的是探索问题发生的原因。追根溯源,直到触碰本质。

有时候我们在工作中会经常遇到这样的情况,为了能够尽快交差匆匆忙忙的把产品的功能做好了,做了一个临时方案,虽然很快,但是会留下很多隐患。临时抱佛脚,虽然一时交差了,但是却给后面的长期发展造成了很大的麻烦,有些事情甚至是无法弥补的。一个有经验的产品经理考虑问题的方面会比较多,更大程度上避免犯这种错误。

第一,限制别人思维与影响别人工作。自己不是交互也不是前端,也就是说并不是专业的,会对团队其它成员的开发和设计造成影响。

  1. 对产品业务更熟悉

2.自己亲自操作系统,完成相关的业务,记录下自己在操作过程中的体会。

原标题:大龄产品经理,到底有哪些优势?

需求调研结束后就需要产出一份MRD来对之前收集的信息整理。MRD里主要陈述三个内容。要做什么?为什么做?怎么做?MRD内的所有内容都是围绕着这三点而展开。项目的立项需要MRD经过上级的同意后才可以进行。一般花一周左右时间做MRD,然后进行MRD的评审会议。

  1. 对产品功能考虑的更长远

每一个人都有一个定位,这个定位来源于对于自我的认识。有的人深谋远虑,擅长指点江山,站在战略的层面对产品的全局进行规划。有的人心思缜密,更加适合在既定的目标之下对每一个细微的模块进行布局。

如果跟团队磨合久了,很多事情我们只看中结果对过程反而不那么在意。我们不再拘泥于形式,也不注重文档形式,重要的是把话说清楚,把事说明白即可。不过话说的容易,做起来到不一定。想要做到这一点,也还是有几个注意事项的:第一是重点内容不能遗漏,重点的产品需求说明不能缺失;第二是交付给技术人员的产出物要更具可读性,让别人更轻松的了解需求。

每一次成功的起步常常看起来都很微不足道。别人眼中流露的不屑与轻视并不会阻碍你前进,而那些爱你的人给予你的力量将支撑着你走过整个风雨飘摇的旅程。

有经验的产品经理会对项目周期有更准确的评估,把计划制定的更靠谱一些:

工作已经将近半年了,一直想做一个总结。于是有了这篇文章,记录了我作为产品专员的经历。其中包含了一个产品从0到1的工作内容和自己的个人总结。

如果你跟一个从业多年的产品经理聊天或许会发现,即使他从未做过你所做的产品,但是只要你跟他聊上几句,他就能明白你说的是什么。跟这样的人交流,沟通过程中会觉得特别省事,你一说他就明白。

3.原型设计

不畏惧自己一无所有。不因自己一无所有而陷入迷惘。认识到产品的整体,让自己知道自己懂的真的很少。虚心若愚,求知若渴。如此,我们才能每天都不一样。

终于到等到产品开发完成了。但是实际的产品开发还远远没有结束,产品的生命周期才刚刚开始,第一版本的上线产品会存在很多不足的地方。还要根据之前的产品规划不断地进行迭代以优化产品与跟战略规划和业务线同步。

第二,耽误自己时间,色彩与交互的应用会使工作成本加倍,占用自己大量的时间。而实际上起到的作用并不大,甚至是负面影响。如Axure有自带的button,就不要自己用矩形做。做出来的效果不一定好,也容易使其它人产生误解。按钮用按钮,文本用文本。原型重要的是简单明了,逻辑清晰。

先梳理清楚线下的业务流程。将线下的业务流程梳理清楚以后,然后才是对产品的思考。在进行业务逻辑梳理的时候我使用了三种工具。状态图,流程图,泳道图。为了理清业务逻辑我花了很多时间去画流程图。

产品梳理好以后,就要开始搭建原型了。原型就是将之前分析的结果通过具体的视觉展现向别人描述自己思考的过程与内容。绘制原型,先确定通过的模块,页头、页尾、一级导航、二级导航……根据不同的产品选择合适的布局。再讲产品架构图中的内容填充到页面内,并加入文字说明操作。最后对产品的细节加以说明,相关的文案、页面寄到、反馈提醒、交互方式……细节内容可以直接在产品原型页面旁边进行注释。

4.对自我的认知

其原因在于熊叔将业务需求与产品需求进行了很好的融合,让大家认识到自己所做的不是枯燥无味的写完一段代码,而是在不断地贴近我们要实现的最终目标。

仔细回头看一看,最开始设计的原型与上线的产品差了很远。

什么才是用户真正的需求?

      最可怕的事情是全身心地投入到一件毫无意义的事情而且自我感觉良好。

产品工作的收获与体会

需求调研:

后台产品/B端产品,与C端产品有着非常大的差异性。C端产品因为面向对象是用户,所以非常注重用户体验、交互设计以及视觉设计。C端产品需要在细节上进行不断打磨,并且需要对用户的心理进行精确的捕捉。除了产品本身以外,还需要考虑许多外部因素,如竞品、政策、技术等。C端产品中另一个重要的角色——运营,在后台产品中也得不到体现。往往只需要产品经理一个人就可以代替相关的工作。后台产品更加看重的是产品能够清晰地体现业务逻辑,功能能够满足使用者的需求,首先强调的是产品的可用性,其次是产品的易用性。

我知道自己还有很多欠缺的地方。我会在今后的工作中更加努力,不断地完善自我。

产品经理要需要管理好团队就需要具备一定的无授权领导能力。

看一个人在工作上取得的成就,除了能力还有态度。

而应对这种变化的方式,只有让自己不断地学习从而跟上每一次变化的步伐,站在时代的浪潮之巅。不断地提高自己思考的广度与深度,寻找到自己能够适应、跟随、引领时代的方式。

这种无授权领导能力来自于多方面。言表达能力、产品规划能力、逻辑思维能力、思想高度等多种因素让一个人具有人格魅力。

虽然工作不久,但我对产品这一职位有了更加深刻的认识,也对产品开发流程有了较为清晰的认知。

其次不同阶段,产出的原型图也是不同的。MRD只需要产品的大概框架,产品业务上的细节信息不需要在这时体现出来。而PRD产出时,需要在原有原型上进行迭代。

项目管理:

用户往往不能明确的表达自己的需求,传递给我们时也许我们理解上会有偏差。所以我们要多想一下,看清楚用户真正需要的东西和要解决的问题是什么。

用心去触摸产品,用心去传递产品。才会让一个团队更加高效地发挥价值。

PRD结束后,就正式进入产品的开发阶段了。

经手产品的第一步就是进行需求调研,一般会花近一个月的时间在业务部门对业务进行深度的了解与分析。

对于产品而言,时间是非常宝贵的东西。原型越简洁,修改起来,成本就越低,越能提升团队的工作效率。同样在原型迭代的时候也能节省不少的时间。

乔布斯说过大概这样的话,人生是许许多多的点,有一天这些点会连成一条线,这就是你成功的原因。所以我要做到的是将线上的每一点进行拆分,尽力去做好每一点。

在产品开发阶段中,产品经理要承担一个重要的职责,即是项目管理。项目管理是产品开发中非常重要的一部分,它影响到的是产品开发的进度、产品开发的质量、团队成员的精神状态。

需求评审的时候,团队其它成员提到了很多的需求。

最后牢记。

等到最后总结时才发现,很多需求其实都只是伪需求。反而还将产品功能砍掉了一些。

产品设计的内容需要囊括在PRD中,为产品的开发提供详细而明确的信息。更像是一份产品阶段就暂时结束了。之后就是与开发沟通,推动产品一步一步往前走了。这个过程中,可能会有许多需求变更和返工。要有充足的耐心慢慢解决问题。

不忘初心,方得始终。

需求调研与分析完成后,就是自己对内容的消化和吸收。要想设计一个产品首先要做的事情是自己先清晰地理解一个产品。只有自己理解了,才能更好地推进产品进行开发。

如果是产品重新开发,那么首先做得是对现有系统进行调研。针对当前系统中存在的缺陷与不足进行优化,并提出解决方案。(如果没有现有系统,取而代之的就是竞品分析)对现有系统调研主要采取了一下几种方式:

梳理好线下的业务逻辑以后,要将它抽离搬到线上。这个过程,可能会删除掉某些线下的环节。所以要针对产品重新书写流程图。依据产出的流程图基本上就可以大致确认产品的功能点,确认好所有功能点产出功能列表后就需要引入角色,将每个角色与功能进行对应。接下来就是搭建页面架构。先搭页面,再确定页面内的功能,最后细化页面内的信息。在原型出来以前,可以拿产品架构图先和别人进行一下交流。产品架构图相较于原型图,与数据库的设计思想比较一致。而原型视图化后,对于数据库设计却反而变得抽象了。另外,产品架构图修改较快捷,返工成本相对较小。

所以项目管理其实分了两个部分,第一个就是团队管理,第二个是项目进度管理。而这两者又相互影响。

产品管理文档 自己搭建的,欢迎浏览、交流。
 

1.对产品设计的认知

在众多纷繁的任务中保持清醒的头脑是一件十分不易的事情,并且在高强度的精神压力下同时准确无误的把握每一个产品的进程更是一件不易的事情。

Last Words

这一步是对直接需要操作系统的业务人员进行调研,找出他们在使用现有系统过程中体验不好的地方。

很多产品的开发都采用的敏捷开发流程。在敏捷开发流程中特别注重的是对团队的管理。这个过程中,要让每一个参与开发的人员理解了他们参与开发的产品具有什么价值,让他们知道,这并不是单纯的码代码,而是为了解决实际的问题而进行的工作。他们在键盘上敲出的每一个字母、数字与符号都存在意义。

有点忘记了最初的战略规划与解决的主要问题。

产品设计:

有些人觉得花这么多时间画图会浪费很多时间。我觉得仁者见仁智者见智了。对于我个人而言,每天捣弄这些图,会很快加深我对产品的理解。特别是在业务比较复杂,而且之前又完全没有接触过相关方面知识的时候,仅靠大脑很难有清楚的思维,但是图形化后却能很好地理解。在业务整理上多花点时间整理,我觉得是很有必要的。

不要在原型设计上主观地加入自己的UI设计。

在MRD中还有一个很重要的内容,即是该产品开发需要投入的资源到底有哪些。在MRD中一定要明确地提出自己所需要的资源。公司的资源都是有限的,不论是人力资源还是硬件资源,永远都是不够的。所以要为自己的产品争取资源。要正确地评估产品开发的工作量,然后索取对应的资源。不能在资源不足的情况下进行产品开发,如果因资源问题,产品延期或者产品质量不过关,那么上级看到得只会是因为自己的能力不够而没有完成产品的开发。

原型不是目的,只是过程。只要能将自己的意思传达清楚,手绘图也能解决问题

所以需要多次与管理层对话。如果需要闭门会议也必不可少,旨在会议结束后能确定明确的产品方案与战略规划同步。除此之外,也是为了产品需求调研的顺利进行以及大家能够更好地对产品进行认知。定期的跨部门会议也是需求调研的一种方案。多次的会议才能让需求调研落幕,确认大致的产品方案。

其实,很多时候我们都在做无效需求,只是自己并没有意识到。需求分析时要透过表面,看到用户真正需要的东西到底是什么,再去提出解决方案。

觉得一个产品的从0到1就像建立一栋大厦,一砖一瓦都是这个大厦的一部分。产品也一样,有许许多多细小繁琐的工作。

3.与业务人员在不操作系统的环境下进行对话,记录他们自己对系统提出的需求以及自己的其它想法。

在不停聆听需求的同时,有点变得为了做产品而做产品。

1.业务逻辑梳理

只要产品的周期没有达到终点,产品经理就不能有一时的懈怠。

PRD中除了产品设计的内容,还需要有的内容是产品的规划。产品的总体目标是什么?为了完成这个总目标需要分几步,每一步骤完成的标志是什么?这和之后的项目排期息息相关。项目开发的进度、人员分配以及项目的优先级定义都会依据产品规划进行。