创业小公司产品经理如何规范工作流程?

没有一个为之有效的工作流程,项目开发时,作为产品需要干什么?

公司没有具体的规章制度安排,产品经理也没用实权,无法推动一件事情的进展。

回答 36 排序
卡卡的人生哲学 华康医疗,闺蜜圈 产品主策划(wx:kant-life)

创业公司产品经理,通常初中级产品经理比较辛苦些,没有项目经理,没有交互设计师,一个人常常操心好几个职位的工作。
要说规范产品自己的工作流程,说句废话就是灵活处理,做好时间管理。

每天每周做个计划list,无论事情大小,记录下来,合理安排时间一件件做。
初中级产品经理涉及研发各个方面(见下面之前总结的app研发流程),可见与项目成员的沟通工作占据了产品工作时间70%以上,而且是相当繁杂,其他30%需要静下心做的是需求调研,写需求,数据分析,偶尔思考下战略。

通常来说正常工作时间是没法专注于那30%工作的,所以一般安排早上趁开发没来之前,晚上加班做这部分工作。其他正常时间主要投入做70%的各种沟通工作,也可以在这部分时间内利用番茄工作法15min,25min什么都不让打断内专注于30%的工作。不过不被打断机会应该很少。。

高级产品经理执行方面招个认真负责的小弟小妹来做上面的工作,其他工作做管理小弟小妹。规划版本策略,版本节奏。还有思考产品战略定位,向老板争取资源,和其他部门协作。。

还有这个版本规划很重要,,要保证流水线顺畅,理想情况产品需求文档要领先前端开发2个版本,设计领先前端开发1个版本,后端开发领先前端开发半个版本。即在当前项目启动同时,产品经理已经在调研讨论下下版本需求;设计开始搞下版本的稿子;当前项目进行到一大半时,后端已经完成当前版本的需求,并开始准备下版本的需求预研。

如果不是这样,在开发一个版本时,需求还没写完整,设计稿没到位,开发催,测试催,老板说需求分析不够,定位不好,推倒重来。。。这样的话无论是高级产品,还是初中级都会奔溃。

所以要规范工作流程,得首先和项目成员跑通顺畅的版本流程和节奏。

---app研发流程---搬运工---

一个移动APP项目研发规模可大可小,但都离不开以下几个成员:产品经理、ui设计师、前端开发、后端开发、测试等。如何合理安排项目成员工作、确保项目顺利进行呢?一个清晰合理的项目研发流程控制很重要。

移动APP项目研发流程控制

····1.png


项目研发流程一般来说分3个阶段

第一阶段:需求策划。
在需求阶段产品经理内部进行需求讨论:讨论下版本需求重点是什么,做什么功能,怎么做。通过反复调研、讨论、输出交互方案。

确认需求可行性:产品在输出交互方案后找相应的开发讨论需求方案是否可行,这个讨论阶段产品和开发的思维方式不同,往往会擦出新火花、新惊喜;但讨论控制不好或者会演化为产品和程序员的撕逼大战,呵呵。

UI设计:设计师将产品的交互方案变得更生动精美,不过精美的设计稿不见得都能实现出来。在这个过程中产品经理需要协调设计师和前端人员的沟通,制定设计规范。同时保证设计稿的质量,出稿进度。

需求宣讲:产品经理将交互方案和实现逻辑完善以及将上版本的bug、其他优化需求等整合出完整的版本需求文档后,拉上项目所有成员宣讲。宣讲目的主要让项目成员清楚新版本需求的重点是什么,做什么功能,为什么做(重点讲);简单介绍怎么做,讲解交互方案或设计稿,给大家有一个整体的印象,让大家都了解版本功能的意义。

第二阶段:需求研发。
项目启动:需求宣讲后,开发根据产品需求文档进行需求评审,评估出研发周期、提测时间、预发布时间点、正式发布时间点。产品根据评审结果发送项目启动邮件。

研发:需求研发过程中,产品跟进研发进度,保持与开发沟通确保需求被正确理解,及时解决研发过程中发现的新问题。

测试用例:产品、测试、开发共同确认版本测试用例,并同步研发过程中变更的需求和细节。

提测:产品验收开发输出的功能模块,并输出体验回归文档;测试根据用例验证需求逻辑,提bug、优化给开发。内网环境测试通过后,测试继续验证预发布环境、正式环境。

第三阶段:版本发布。
客服培训:测试验证的过程中,版本发布前,产品提前给客服培训新版本内容。

发布:后端开发、运维人员将代码发布外网环境,前端输出外网正式包。产品运营将正式包上传各大安卓市场或ios -appstore提审。

升级:所有安卓渠道包更新好,或者appsore审核通过,新版本也没有发现什么问题时,后端开发和运营人员打开升级配置,并发送升级通知。

运营报告:版本发布完毕还未算完呢,运营人员在新版本发布后,收集用户反馈,进行数据监测、数据分析;评估新版本功能效果和影响,验证新版本功能以及输出下版本需求开发和优化建议。

2016年04月01日
| 评论 35
匿名
Nicole 智慧停车 产品经理

小公司各方人员基本都在一个办公室,一般的小需求当面说比文档来得更快,因为自己在一个电商B2B平台,产品现在还只有web端,所以更新一个东西很方便,不像app,还要攒到一个版本,基本能做到改了就上。

由于自己又不是很懂技术,所以为了节约时间,我平时都是这样工作的,要实现一个需求,我会先想出大概要怎么实现,把逻辑理清楚,然后拿着逻辑流程去和研发商量,我们要做这么一个东西,为什么做,咱们技术能不能实现,有没有什么坑,大概需要多长时间,如果技术说没有问题,那我就回去画原型,有问题有优化解决方案。

我迅速的画出一个原型图,基本就是一个简版的线框图。如果有特别说明的,我会直接标注在线框图里面,然后直接拿着线框图去找UI,跟他们说这是个什么东西,要实现什么,为什么要做,尽量多给他们描述需求背景,带入场景,讲讲故事这样出来的东西会更好。

讲完之后我又回到自己的位置,这时候UI开始着手做了,我也开始给原型做标注(简版PRD);如果标注的过程中有什么改动一定要告知UI,尽量快速做完标注,发给UI。然后建立一个任务(我们用的是tower),把原型和相关说明全部写上,然后@各方人员,设计、后端、前端、运营、测试,剩下就是要跟进,和各方人员多沟通。

重点:

1、开始之前流程一定要想清楚;

2、根据需求的大小来调整协作方式,保证灵活性和高效性;

3、一定要有记录,在小的改动都要有记录;

匿名
yoyoyoranran 绝顶人峰 - 顶尖游戏交易与服务商 产品部总监

个人非常认同工作的规范化与流程化,但流程是死的,人是活的。

创业型企业,特别是初期,不建议流程过于复杂。毕竟流程牵涉到节点,而每个节点都是需要有人去执行,初创企业大多资金有限,基本不可能配备完善。而且片面追求规范化,很容易拖慢效率,初创企业的大忌啊。

建议流程简化成四个环节:

1. 需求阶段:初期一般没有用户,所以基本上靠老板或产品直觉最强的人提想法提概念,或者通过竞品分析。工作基本就是整理、分析、讨论。

2. 产品环节:将需求、概念实现初步的具象化,直白点就是出框架、流程、原型、文档,然后再讨论、评审。

3. 项目环节:确可后的产品推进设计、研发、测试与上线。一定要记住,工期和质量方面一定要事先进行约定。

4. 调研分析:哪怕出一个产品报告、项目报告啥的都可以,而且一定要广而告之。至于原因嘛,你懂得。

就像古代谋士,基本也没有啥行政权力,靠什么来征服大家?出谋划策,直白点就是说。所以产品经理开始也要不断说,和老板沟通、和设计沟通、和研发沟通,总之,怎么让大家信任你怎么来!当然,说完了还要做好,不然三两次就拜拜了。

另外,妥协是门艺术,而想要获得领导权,适度强势也必不可少,中间的尺度,兄弟自己好好把握吧。

2016年03月31日
| 评论 12
匿名
TD2016 少先队科技 产品总监

创业公司本来就是什么都没有,

从0到1,

很多东西都是摸着石头过河,

受的都是伤。

基于题主说的这种情况,一般创业公司都是1个人当好几个人来用,所以创业公司挺磨人的,快速自学,然后就动手干了。至于如何规范化,说实话,创业的伙伴经验丰富这点极度重要,少走弯路,减少是错成本。公司如果没有这么一号人,要么自己上,要么考量一下下一份工作吧。

可以看这个图来规范流程

  • 产品经理需要沟通的角色关系

9142934_1.jpg

  • 产品部分就不多说,自己的职位应该知道自己要做什么的。简单花了一下。

4.pic.jpg

  • 看看开发的流程,知道开发到那个环节了,及时反映

无标题3.png


自己上的话的话需要了解内容包括:

1.项目开展流程;(可以看看PMBOOK)

2.必要的技术方面知识;

3.工作内容量化成指标,用数据来说话,培养公信力;

4.后面就是产品的东西了,调研,需求立项,评定,排期,阶段性检定,测试,上线,迭代巴拉巴拉的。

5.多请教前辈,度娘。。。

6.多做有价值的事。。。

2016年03月31日
| 评论 10
匿名

一般会优先解决重要且紧急、不重要但紧急的需求,其他需求暂缓。

至于什么样的需求才是重要的呢,可以利用需求分析的KANO模型,来分析,具体是惊喜型、期待型还是必要型,来确定它的重要性和紧急性。

比如:

用户在购买理财产品时,需要提前充值,一般充值,很多时候钱是不能秒到的,这时,用户充好钱,却好几分钟都没到账,急切的想查找充值记录,APP里却没有充值记录这个功能。此时,增加充值记录这个功能就属于期待型需求,需要去立马满足用户的。

又有用户,不喜欢自己的头像,希望APP可以提供更改头像的功能。这个,就属于必要型需求。

做产品设计时,尤其需要注意几点:

  1. 产品框架的可扩展性要好,切勿一有迭代就推翻重来。
  2. 原型图最好使用中性色彩,避免参杂个人的主观喜好。
  3. 页面之间按功能模块合理划分,标注清楚页面内容,确保自己的原型可以让别人一目了然。
  4. 不要为了追求动效交互的炫酷,而耗费大量的时间在原型图上,交互效果用语言描述清楚即可。

最后,做好产品需求文档,把每个功能定义、前置和后置条件、用户提示、交互效果等描述清楚。我个人习惯于将产品需求文档直接以表格形式写在原型中。具体依据公司规模、流程和行事风格来定。

以上工作做好后,需要与各部门负责人开会讨论,沟通技术可行性、运营可行性等,收集各方反馈,改进产品设计。

待确认无误后,进入开发环节。

项目推动、产品测试

做好产品排期,即什么时候开始开发这个产品。然后跟技术人员一起,确定开发周期,知道大概要多长时间开发完成。

开发过程中肯定会碰到各种各样的问题,比如:需求变更、增加新的需求、开发人手不够等,需要及时处理并给出合理的解决方案,推动产品在可控范围内完成。

注意:这里是推动,并非跟进。你必须把控好整个环节,如遇紧急需求要增加,需酌情删减部分优先级不高的需求,保证产品在排期内顺利上线,切不可只做跟进而无限期的延长上线时间。

开发完成后,需要做好测试工作,可号召公司同事一起参与测试,你来把关,验收开发出来的产品确实是符合预期的。

这个过程中,你会发现各种问题需要修复,每发现一个问题,及时做好记录并汇总给技术人员,可能会反反复复好多次,不停的测试,反馈,再测试,再反馈,目的是要保证产品的质量。

这个环节,必须细心、细心、再细心。

快速验证、迭代优化

在用户使用的过程中,收集用户反馈,统计并分析数据,慢慢修正需求,通过一步步的迭代优化,做出另用户满意的产品。

数据分析是我的薄弱环节,我就不做详细的展开,有一种神奇的功能,叫做“搜索”,赶紧用起来吧。

对了,还有一项重要工作,就是沟通。沟通,存在于各个环节中,面对不合理的需求,即使是老板提的,也要懂得说“不”,优雅地拒绝,以理服人。

匿名
飞天海带 上海七维教育 产品经理

先说下背景:目前所在公司传统业务起家,成立四年多,去年将软件产品研发上升到公司战略优先层面。管理层虽说重视但起步并不愿投入太多资源,当下的团队配置是1个产品+1个UI+1个开发,不到两年的时间已开发PMS、官网、两款在售软件以及两款已上架小程序(PS:开发今年3月份才到岗,之前都是外包)。看到问题后比较感慨,想到当下的公司现状很符合题主所说的“创业”“小”公司,正巧前段时间自己也思考过关于如何明确工作流程以提高团队效率的事情,所以在此分享一些个人经历及思考。

创业公司各方面资源紧缺是不争的事实,因此没有足够的人力和时间来走完一个完整的产品流程。所以在如何规范工作流程上,我的结论是:相比于规范,小公司应更强调效率和结果,以推动项目进程、实现项目预期为目的,结合公司的人员配置去不断探索适合当下的工作流程。

下面我会结合一个案例,来阐述自己如何根据实际情况调整工作流程,以及我是如何思考的。

按照时间顺序,案例中的产品项目大致可以分为以下四个阶段:

一、与管理层明确他们想要的结果

立项后,boss希望在2个月时间内,将原本预计耗时4个月的产品做出demo,商业行为先行,供销售们外出演示(我们做的是政府采购,因此会有2-3个月的招标时间供我们完善)。(PS:这里隐含着一个点:除产品demo外,各种营销相关的资料也得同步跟上,先埋个点)

二、根据实际情况规划产品流程

先将完整的流程(网上可以搜到成熟大公司PM分享的经验)在脑中套上该产品走一遍,再结合人员配置和时间节点,从流程中删去或合并非必须的部分。从用户调研,一直到测试完毕可以演示,实际的工作中,为提高效率而导致不规范的点有:

1、前期调研(市场、用户)

尽管这点非常非常之重要,但由于公司所在行业(特殊教育)很特殊,我们的目标用户群是特殊学校里的老师,掏钱购买的是学校,因此这两类用户的心理和需求都需要了解。但实际操作过程中遇到的难点有:

  • A、用户不配合:“上面”没有硬关系,销售去学校拜访的机会都不多,更别说产品经理。
  • B、老师个体经验能力差异巨大,不同区域特教发展水平差异巨大:导致需要非常大量的用研数据才能区分出不同的用户群体,在精确定位的前提下做出足够科学且有说服力的结果。

Boss给不了很多时间去调研,遂退而求其次,在公司内部对销售们做了访谈,再结合boss的经验,简要的总结出了这类群体的画像以及需求痛点

2、各类文档(MRD,PRD,测试用例文档等),取其核心用途即可,不必在意形式。

  • A、MRD:把自己前期调研的要点和boss梳理了一下,后简要讨论了产品战略和运营形式,留下会议记录,即可。
  • B、PRD:核心是让开发明确有哪些功能,做成什么样。由于我本人并非技术出身,因此在技术实现上由开发主导,为减少返工,事先我也会和开发解释每一个功能点存在的意义。而后记录下要点,保证我们二人对功能的理解一致即可。
  • C、测试:开发每做完一个功能都会自己测试一下,然后让我再检查一遍。我会按照记录的功能要点,从用户的使用逻辑出发,挨个验证,期间会考虑90%左右可能会出现的极端情况,确保较高的“性价比”。在demo出来之后,会给公司的每个员工都试用,告诉他们有哪些功能点,过程中再测试出一些bug和不完善的地方。

自己在以上工作“偷懒”的情况下,可以有更多的时间用于和UI、开发的沟通,解决过程中遇到的问题以及准备营销的相关材料(后面会提到),以确保在demo出来的时候,营销材料可以跟得上进度。(诚然,写这些文档也不过就是自己加点班的事情,我在刚接手产品的时候有写过,然而正是这些过往的经验告诉我,它不适合我们当下的产品节奏,因为写出来的文档除了前期沟通外,在后期往往被“堆在角落,灰尘像雪一般冰冻”)

三、开发过程中的沟通

及时且高效的沟通可以省下大量时间!我们的产品团队共三人,我坐中,左开发右UI,有问题扭头就讨论;关于高效沟通,需要产品时刻有一颗清醒的头脑,知道当下讨论的问题关系到哪个功能点的实现,不同的解决方案是否与产品战略相符对用户体验的影响怎样,以及开发所需的时间等等,每次讨论都要有结果,即综合这些因素做出决策,考虑的优先级因产品(项目)而异。做决策时能不问就不问boss,避免延长沟通链,就像楼上某位所答,小公司的产品大部分都是小白(包括我在内),而小公司的boss比产品更“白”,很多小问题反倒会根据boss的个人爱好被瞎指挥。

四、提前做好“善后”的工作

这点主要与我所在公司的业务形态有关,这里的“善后”指的是诸多不在软件产品流程内,但却与公司产品业务息息相关的各种杂事,以营销材料为主,没有相关专职人员就只能自己做。具体有:

  • 1、产品宣传页(传单)
  • 2、产品介绍文档(半宣传性质,供客户进一步了解产品)
  • 3、产品详细功能介绍(供学校客户附在向上申报经费的文档中)
  • 4、产品使用介绍视频
  • 5、给销售的产品培训
  • 6、产品招标参数
  • 7、产品控标文件
  • 8、软件著作权申请
  • 9、软件产品登记
  • 10、官网上产品的宣传页
  • 11、产品的包装盒,售后服务卡设计,软件配套使用素材的采购准备(我们有配套硬件)

所有的文案都得我自己写,设计都是我安排UI去做。

从整个项目的进度看,根据木桶效应,产品demo出来的时间,最主要是取决于开发,因此,在确保开发流程顺利的前提下,在产品开发的时间内需要把其他“杂事”都处理掉,这样产品流程就可以压缩到最简。

 

以上是我个人经验的分享,整个过程中,我能调动的资源就只有1个开发和1个UI(偶尔会把UI当平面用)。各公司的情况都不一样,因此实际做的事情并无参考价值。但我觉得,如何从公司实际出发去调整产品工作的流程和内容,总结出最适合当下的工作经验,这一点是所有小公司产品经理都需要去思考的。

路子相当野,望各路大神轻喷。

匿名

个人觉得什么是规范?就是一种规则能够让员工的效率达到最大化。因为公司的绩效最终来源于员工的效率。围绕如何提高员工效率说几点。

1 产品需求阶段:个人觉得一般的产品经理根本就不可能把所有的细节考虑到,所以很多细节可能是UI、开发、运营提供给你的,而且一个产品也不能简单的站在产品角度去设计,所以产品经理在确定大的需求,确定大的方案后,在后边的细节上自己肯定会有一定的想法,但是最好是能够在开发前与开发、运营、设计一起讨论一些细节性的东西,就算他们不站在他们的岗位讨论,只是一个普通用户的角度,也会给你很多有价值的意见。

2 设计阶段(与UI妹子的配合)。不要让UI妹子提供多套方案,你再去选择,除非时间多得是。不然会引起很不好的后果,比如UI妹子会很烦,从公司角度,这完全是在浪费劳动力。好的解决方法:A 如果你设计感很强就直接给UI妹子定个基调 B设计感一般就给UI妹子一个参照图  C 最好能不时的与UI妹子沟通,不要她设计完了,再去挑三拣四  D 提出意见的时候,切记一定要委婉,而且能够用UI的专业术语去沟通(这个看几本设计书就行了)。

3 开发阶段(与开发小哥的配合)。不要随意更改需求,你以为的一个很简单的功能,可能会使得开发人员把代码推倒重写,针对技术不强的PM,最好在一开始的时候就能把很多功能点给确定下来,如果实在要改,也要与开发沟通如何更改比较合适,推倒重来这种事情,一次两次还可以,多了开发小哥肯定受不了就会严重影响到以后的合作,试想,换做你总是做改动你烦不烦。

4 不要经常让下头加班。有时候加班没有办法,不得不加班,但是不加班的尽量不要加班,没有哪个人喜欢加班,而且加班了效率又差,员工负面情绪大,得不偿失。

5  不要开没有意义的会。有时候开发,TM总是会跑偏,开了一个下午会,回头想想好像也没有啥子收获,开会前,确立具体的目标,特别是讨论一旦跑偏,马上收回。

什么是规范? 效率。

2016年04月01日
| 评论 10
匿名
艾唯斯 Hikvision 高级产品经理

前提是创业公司,也就不要纠结什么流程规范,这是一个极度强调效率和结果的阶段!

一,公司业务定位。公司有产品型,运营型,一般来讲产品型的产品经理话语权要重,而运营型更多是以产品为辅!

二,没有规则的前提是建立信任。创业团队产品经理加入的时间点也很关键,先入的就不说了,再搞不定就没招了...后入的么,同意上面答题兄弟的说法,充分小的迭代,减少失误可能。其次,确实要花些时间研究用户,研究产品,提升同理心,在一两个领域的新颖专业的看法会让其他研发兄弟对你另眼相看!

三,主动,主动,主动!重要的话说三遍!流程规范的目的一般在大公司更有效,通过流程平衡人员能力的差异化,毕竟大公司的发展更强调惯性...小公司就不要分那么清楚了,怎么让研发兄弟更高效的编码就是你要营造的!

四,能力提升。多看书多看报,产品经理要有生活阅历,有点小情怀,有点小闷骚,进可欺身压正太,退能提臀迎众基!

好好体验。腻了,再见!

2016年04月01日
| 评论 8
匿名
隔壁的小黑 贤利智科技有限公司 产品经理

审题,“在项目开发时”,那可能的情况是,题主无奈在开发阶段进度不受控制,进度没有按照自己理想的方向发展,可能出现部门之间工作衔接不够紧密、相互推诿抱怨,比如UI设计完以后没有把成品快速给到前端,前后端对接数据的时候有问题就会把工作放着并不沟通解决问题。

机智的题主想出了一个方法来解决这个创业小公司开发阶段项目管理问题:规范工作流程。方式是有了,但是没有办法推动这个规范的工作流实施。

基于我不成熟的分析。我给一些不成熟的建议。规范的工作流程这个方法太单一,不一定得到团队认可,尝试一些其他方法。

1.招一个项目经理。

2.自己成为一个项目经理,推荐-PMBOOK(软件开发版),一个礼拜可以看完。

3.用明道或者Worektile等项目管理工具,有费用人少的话,并不是非常贵,用好了犹如神器。

4.调整组织架构,各部门要明确的负责人,培养部分人的主人翁精神。

5.自扫门前雪,多张嘴问问开发进度,其他事情少插手。不过看题主这个意思,是个有狼性的人,估计没有定力这么干。

PS:由于题主给出的相关信息太少了,妄断病症,希望有所帮助。

匿名
柳柳要长肉 河马科技 运营经理

流程是建立在团队之上的,对于创业公司来说,越快出效果才是重点。如果需要你来制定一个流程,更多的是你基于你之前的工作经验来设计出一套行之有效的策略。如果你没有过这样的经验,我建议你多和有经验的接触,特别是你们公司的,有经验的开发、管理。

匿名
Mr.二狗 趁早 消防员

首先要学会吃一堑长一智!

在陌生的环境里,从陌生到熟悉需要过程,需要熟悉的是人(团队/同事/领导)、事(业务/产品)、资源配置等!

接下来就是顺瓜摸藤,只有遇到坑才知道如何规避这个坑,通过制度或规范来规避

流程都是扯淡的,划定责权,用以出事“打官司”的!人员不配合制度最后就是昙花一现

产品经理要做的就两条:

1.先“点”-在“面”:产品规划时由点思考,覆盖到可能涉及的面

2.先“面”-在“点”:产品推进时由面的维度,具象到每一个细节关键点的执行/落地/甚至异常情况处理

勤思考、勤沟通、勤咨询(到新环境,最快熟悉环境的方式就是向公司老人(前辈)请教)

必须要磨练性格:

耐心、责任心、包容心(只要与产品相关的流水线上,任何节点出问题,都有可能是产品间接或直接挖坑所致,出了问题,产品要做的不是追责,而是想办法)

情商很重要,学会倾听、主动承担责任才是最本质的!

不论大公司 小公司都是靠人驱动事情,制度规范事情而已,所以人是第一位!

匿名
Aliceyue 保密 产品经理

我个人是从初创公司走过来的,这里也做一下个人经验分享:

项目计划.png


1、项目负责人主要负责安排人员和控制整个开发周期。

2、产品负责人主要对接沟通各部门需求,整理需求,出原型,配合技术部开发。

3、原型初稿完成,开发人员评审后,开发人员给出开发周期,并行进入开发阶段。

4、开发过程中,产品随时解答开发人员提出的疑问。

5、产品在开发过程中,要高度了解互联网产品的风向,随时开发新需求,整理迭代开发的相关文档。


PS:以上项目人员在整个开发期,都共处一间会议室。

匿名
建兰飞白 微云科技 产品

我认为在创业公司不能只按流程处理事务,更不能没有流程,流程是为了明确每人每岗都对某一事物负责,保障工作的顺利交接,但绝不能只按流程处理事务,根据具体的需求项及难易程度等综合 权衡而定,以下是我对产品设计到研上线流程的看法,欢迎沟通。

 产品上线流程图

index.png   

二 、产品方案

2.1 找到需解决的问题

诚然,从来没有一款产品是绝对完美的存在,相对优秀的产品一定是不断的听取用户的建议,一点点打磨优化的产品,发现问题的方式是多种多样的包括但不限于:1.测试产品中的漏洞。2.用户反馈的问题。3.同行产品的新功能。4.市场变动的新方向,等等。

产品需收集来自各方反馈的需求,将明确的需求整理到项目需求管理文档上,汇总之后在一定时间进行分析。

正确的需求记录(问题+方案)如下图:

 

模块:
需求背景:
需求描述:

 

注:不明确的需求,一概不予记录至项目需求管理文档。

 

 

2.2 产品评估需求级别

需求的形式是多种多样的存在,在不同的阶段对需求的对待是不一样的,具体情况根据产品的生命周期而定,如产品早期应更多对业务流程的关注,首先保证日常使用流程的平缓安全,接着才是用户体验。

首先所有的需求整理出来搁置在需求文档上,那么将要对所有需求进行判定,此时可参考四象限法则:紧急且重要,紧急不重要,不紧急但重要,不紧急不重要,进而分析,最后得出产品需求的级别:  

产品需求级别
P1   (高)
P2   (中)
P3   (低)

 

2.3 技术评估成本级别

  当分析得出需求级别之后,需要召开技术部门的初步评估会议,对已有的的需求进行技术角度的评估,涉及的评估维度可参考:开发周期,开发难度,团队技术储备等,最后得出开发成本级别:

开发成本级别
D1   (低)
D2   (中)

D3   (高)

 

2.4 迭代申请确认

到此产品部门已得到版本迭代所需的产品需求级别和开发成本级别,将已获得的信息填至需求评估矩阵模型:

 

    D1D2D3
P1   
P2   
P3   

接着可根据产品的具体情况,参考下图进行需求优先级的确认:

       D1  D2   D3
P1    1    2       5
P2    3   4        7
P3    6   8        9

最后我们可将产品开发的功能列表和开发成本撰写成一份版本优化申请,交至领导确认,如获确认,则进行下一步,否,则暂停。

2.5 产品设计低保真原型

经过上述科学的论证过后,产品方可设计原型,在一遍遍的论证中,产品经理已心有所想,此时在设计产品原型想必条理清晰知所云,切记,不得不知所云就上手设计,原型工具只是表达思维的一种方式,仅此。

设计包含:整体布局,操作逻辑,用户体验等。

原型设计完毕后,召开评估会议,参与人员:UI设计,程序员,部门领导等。

2.6 UI设计高保真原型

产品完成低保真设计且评估合格后交至UI,进行高保真原型的界面美观设计需备注出原型中设计的文字字号,颜色码值,的等等。

设计完成后需召开会议评估:参与人员:产品经理,前端工程师,部门领导等。

2.7 产品撰写PRD文档

到此,已是产品前半部分工作的尾端,已按流程得到:需求获取及整理,需求分析评估,开发评估,版本优化申请确认,低保真原型设计,高保真原型设计,接下来撰写PRD文档作为技术部门的一个参考,撰写的方式多种多样,唯一的检测标准是开发部门阅读流畅减少沟通成本。

 原则上此时不在加入新的需求,新的需求暂缓搁置需求池。

三 、项目管理

3.1 项目管理文档

版本迭代可分为两个部分:1.优化方案。2.项目管理。

前半部分已完成,此时开发部门leader已收到来自产品部门:1.低保原型图。2.UI高保真原型图。3.PRD文档。可根据现有的资料和项目经理共同制定出开发周期,定出每个任务的具体责任人,项目难点,应对措施等。

3.2 开发跟进

    技术团队根据项目管理的文档,明确自身的模块及进度安排,进入开发阶段。

产品负责人根据项目管理文档上的时间周期,进行项目进度的查询,如有较大进度问题及时上报部门leader说明情况。同时产品负责人对技术团队的相关疑问,进行全程解答,保障产品顺利上线。

3.3 产品验收

    产品迭代优化完毕后,内部进行测试,主要针对本次版本迭代功能和基础功能做相应测试,合格,则本版本完成迭代,否则优化至验收合格为止。

匿名

不知道你指的创业公司是什么个情况!我就在一个创业公司,两个后端,一个老板,一个编辑兼销售,我是啥都干,一般开发一个功能,用户调研,定义需求,构建原型,高保真设计图,前端布局,全包,这还需要工作规范流程吗?


思考后补充:上面说了我们自己的情况,一个人身兼多职的情况下,可以忽略掉规范流程,因为这个流程已经变成了个人的工作习惯,完全是可以打破正常的流程的,比如做完原型图后,可以跳过设计阶段,先进行前端布局,前端布局完成再添加设计元素,这在偏平化设计风格下是完全可以的;再比如,产品功能定义好之后,后端也可以跳出来直接工作了,编写功能的核心逻辑,这块不需要前台页面的支撑。

为什么要有工作规范,楼上说了,关键是为了在多人协作的情况下提高效率,使得各环节的联系更紧密。

我们的实际工作情况是这样的:

公司内部QQ群:

产品:我的原型出来了,(截图),大家觉得如何?

老板:嗯,是客户想要的功能

后端:我看看... ... 可以,这个逻辑可以实现,也能和之前的模块进行衔接

销售:不错啊,之前客户说就要这个功能

设计:那你把原型图发我,我搞了,风格还是走简洁的吧?

前端:设计风格不变吗?那我可以直接布局了

产品:好的,一会交互上和逻辑上的细节再跟你们单独确认@前端@后台

... ...

这样的工作方式我想应该不只是我们公司吧?

其中的工作符合标准化的工作流程吗?肯定不符合

但是它高效吗?我们觉得很高效

创业公司大部分情况是任务重,需求急,产品更新迭代快,没有标准流程,根据实际情况随机而变才是最佳实践

-------------------

2017年8月4日 补充

回看自己一年前的回答,只能一笑而过……

在今天来看,小团队创业公司流程混乱的情况依然普遍,简单说下这一年多来的经验:

我理解的创业公司的“流程”的驱动因素,一定不是“规范”,规范相对而言是死的,并不适合灵活多变、快节奏的创业公司,插个题外话,举个例子:
一个销售业务主导的企业客户,想要上一套系统来规范销售报价的审批体系,想法是好的,很多大型公司也确实实施了大型的审批管理系统,但效果却不好,为什么?因为制定规则的人往往会率先打破规则!

总经理制定了审批规范流程:销售报备给部门经理,部门经理报备给总经理!但实际操作中,为了尽快拿下订单完成业绩,销售往往会月越级直接报备总经理审批,总经理也默许!

当打破规则的是制定规则的人时,规则也就没有存在的必要了!

小团队的“流程”驱动因素,在我看来,其实是“目标”,当所有人有一个共同的目标:可以很远 - 给用户提供最好用的产品;可以很近 - 本周五之前要把新的需求迭代上去,这个时候,团队向心力一致,效率自然会大大提升。

但是有一个共同目标有一个前提,就是大量、频繁的沟通,保证每个人对“目标”的理解是一致的!


至于产品经理没有实权,无法推动项目,这就看个人修炼了!

问:没有实权的情况下如何顺利推动团队?

答:人格魅力……

2016年04月01日
| 评论 5
匿名
咸鱼女子 Hopperclouds 产品经理

同意观点:规范是死的,人是活的。

最好的规范是寻找到最适合“国情”的运作方法,一般情况下,这些规范是最初的几个人带领起来的,但是随着公司的发展,规范也需要与时俱进。否则就是坑越挖越大…………

说点实在的,产品经理做为公司运作流程中非常重要的一环,一定要记得透明!事情透明!进度透明!问题透明!要知道,很多事情不是产品经理可以决定的,因此做好自己的事情,并且及时同步,那么事情就变成大家一起的了。

创业公司还有很容易碰到的一个问题就是分工不明确,职能会有交叉。所以还有一种方法是项目管理制,从产品设计到实现,产品推广甚至销售等各个流程都指定负责人,还是一个原则,把自己的事情变成全公司的事情。

最后说一下我们是怎么做的,公司有整个一面墙是用来展现产品进度的,全公司都可以看到某个产品到了哪个环节了,需要哪些部门介入,同时其他部门也在上面进行补充说明,亲测有效,至少到现在不会出现一个产品上线后没有人知道的情况了…………

2016年04月01日
| 评论 5
匿名

实际经历告诉我,这种情况短时间内没法解决,产品在努力也没用,尽力让大家相互理解作出东西最重要,慢慢推动起来,给产品分析需求分析没有任何关系。

2016年03月31日
| 评论 2
匿名
波仔 开言扯空 为产品经理

如果连工作流程都不敢去规范,还谈什么创业?



如果连工作流程都规范不好,还怎么能创业成功?



不要老是拿创业啊,初期啊,做借口

创业就活该乱来?

没想好你创毛业啊



2016年04月03日
| 评论 2
匿名
一人一 天涯 网络工程师

大致的流程就是 需求(包括商业,产品)讨论-技术讨论-画原型-监工UI设计-监工切图-监工技术开发(完全不用考虑技术层面,只需能跟技术沟通需求明白接口即可)-编写产品需求文档-配合测试产品验收-配合运营或客户需求验收-配合市场或运营运营产品-配合运营收集需求反馈 -收集产品数据。

2016年04月01日
| 评论 1
匿名

一提「规范流程」,总是让人不自觉的想到大公司的拖沓冗长和官僚气息

创业阶段尤其是早期,个人觉得所谓的「规范」、「流程」都不那么重要

真正重要的是效率和节奏!

产品经理即便没有管理权,但对推动效率这事儿还是有一定的实际控制权的,个人觉得,如果要想提高效率,产品经理能做的一件事就是将需求拆解开,拆成较小的迭代然后交由研发(我们的经验,单次迭代尽量不要超过2周)

当没有所谓的规范流程时,小迭代绝对是法宝!

2016年04月01日
| 评论 1
匿名
aurorac 阿里 产品总监

尽管实践证明,大多数心得都是行之有效的方法,大都能解决实际的问题,但它们主要还是针对每一条可能犯的错误制定的单点突破的攻略。团队人员规模在扩大,项目越来越多。换一个项目、换一个产品经理、换一个对接人,这些错误就会继续重演。因此,我就一直在琢磨,有没有一种方法,可以:

  • 最大限度地避免产品经理犯一些低级错误?
  • 最大限度地让不同风格、不同背景的产品团队成员保持相同的步调?
  • 让产品经理制定的优先级计划与业务部门的需求尽可能地一致?
  • 尽可能地避免产品经理的项目方案犯方向性的在错误?
  • 最大限度地降低产品、开发与测试之间的沟通不畅?
匿名
查看更多

发表评论,请先 登录 · 注册

合作伙伴

诸葛IO
薪人薪事
拉勾
 阿尔法公社
测试兄弟
Growing IO
BOSS直聘
环信
外包大师
CSDN