数极客首页

产品经理成长日记-从需求到产品

产品经理生长日记-从需求到产品

本篇原本

打算写怎样
跟技术中止

沟通,其实跟技术的沟通,是贯串
于整个从需求文档到产品上线、产品跟踪、迭代的过程之中的。本篇更多的是讲作者工作半年来,从需求文档到产品上线的过程,也希望与同行朋友多交流。

需求文档看不看

当你辛辛劳
苦写出来一堆需求文档,跟UED的同窗
定好交互、视觉、重构;满以为技术会认真看待

,但是你会发现,技术同窗
基本

不会看你准备的一堆东西,基本

是依照

自己

的了解

来开发,当开发不下去,第一时间也不是看文档,而是看测试用例,或者直接跟产品沟通;基本

文档只是QA同窗
对着写用例。

刚刚开端
工作的时分
,关于
技术不依照

文档开发,是比较

着急

上火的,阅历
一段时间后,发现重点就好了。产品的实质

是保证产品中心
功用
的质量,保证
用户体验,用户端和商户端的功用
不能含糊

;运营后台、客服后台之类的,保证
功用
完好
和业务流利
的基础

上,能够

给技术恰当
的自由

发挥;就算是前台页面,多听听技术的意见,让技术同窗
参与进来;开发过程中,坚持
沟通,关于
技术提出的问题,最快速度的响应。

什么样的需求要写文档?关于
功用
性、触及
业务流转,状态切换,边境
条件灰常多的需求,流程图、交互、PRD一个都不能少;关于
非功用
性的需求,提升用户体验的部分

,文档能够

不准备,准备好原型图,然后在上面标注出重点,托付
的时分
讲分明

todolist与优先级

产品在迭代过程中,不时
有新的需求,不时
有需求被完成,经过
list来管理这些需求,整理的过程也是对产品思索

的过程,不停问自己

,这个需求用户是谁,处置

什么问题,能否
必要,以及能否
必要往常

就做?

list的益处

就是,能够

尽量多的记载
一切
需求,固然
有些天生就是被砍的命,但是list一堆需求
完成的事情,对整个项目组都会有紧迫感;一句话讲分明

每个需求,标明优先级,担任
人,对应的开发,开端
时间,完成时间,完成状态,让项目组一切
人(包括老板),都知道

我们往常

有多少事情在做,已完成来多少,接下来做什么。

需求永远做不完,关于
优先级布置
,平常
工作中最常用的就是四象限法,重要又紧急,重要不紧急,紧急不重要,不紧急也不重要,依据

项目理论

来做判别

需求会议

12年都是一周一次迭代,每周都会有下次迭代的需求会议,并不是真正意义上的需求评审,产品驱动的公司,基本

就是需求解说

,托付
,以及相关时间点确认

需求准备要充沛

在需求会议上,面对技术和QA,致使

老大们的应战
,这是正常的,他们会问为啥要这么做,为啥不那么做,致使

直接对你的需求提出应战
:这个东西不靠谱,不可能;拍桌子打板凳的事情也时有发作
;独一
避免

发作
的状况

,就是关于
需求的准备要充沛

;不论

面对何种应战
,讲分明

数据、用户需求
、和竞争对手怎样
做的,基本

就能压服
;普通
只需
坚持
平和的心态,不会有大问题。

真有自己

无法立刻

解答的,快速招认

错误:不好意义
,这个是我没有准备好,会后我再去做细致
调研和准备,快速跳过这个问题,继续下面有把握的内容;会后再去完好
论证,并把问题描画

分明

,邮件给大家;既能够

避免

抵触
,会后大家平和心态来看待

,也便于处置

讲好我的故事

这里应该是讲好用户的故事,为啥叫讲好我的故事,由于
产品需求
把自己

代入到各个角色中;做过几次用户访谈,很多用户描画

这样一个场景,我快下班了,拿出点评App搜索左近
找吃的;运营说这个这个很烦,我需求
这么这么做,其实能够

这样就处置

了;

客服说,这个信息在这里查,那个信息在另外一个页面,每条记载
处置
的时间增加多少分钟;

最有意义
的是商户端,商户那边有签合同的、店长、担任
人、前台、收银,会计,每个人都有可能来用我们的后台,去商户端做访谈的时分
,察看

他们怎样
运用
点评的产品;

讲需求的时分
,先描画

用户遇到的困境

,绘声绘色

,动人心弦;怎样
做到,代入自己

的角色,不要伪装

用过,而是自己

真正运用
过程中的痛点,放大再放大,感情方式来感动

技术。

描画

痛点只是第一步,能够

分明

描画

,假定

这个需求做来,运营效率能够

提升多少,节约多少本钱
,最终转化率估量

进步
多少,以及ROI(投入产出比),一切
功用
点的改进

,最终
都能够

结算为Money,由于
钱,会让一切
人兴奋,并集中肉体

来处置

问题。

让更多的人参与需求讨论

需求被应战
,会有点不温馨

;但是若一切
人都表现出对你的需求漠不关怀

,那才是最难受的。怎样
让技术更多的参与需求讨论:第一
能够

挖掘

对业务有兴味
的人,多跟他们聊,他们会主动告知他们的想法。普通
工作几年的技术比刚刚工作的童鞋更关怀

;第二
让技术有存在感,定时告知他们相关的产品数据,月用户数,月增长量,收入等,依据

技术所开发的功用
点,细化到此功用
带来的数据,以及同比环比数据;最终
在Scrum中,计划

扑克能够

让一切
人都参与到需求当中,由于
每个人都要评价
task的工作量,目前来看,效果还不错。

肯定
好时间点和相关义务

Scrum的确

是一个好的方式,能够

预算
收工
作量,并且技术自发领取任务,直至每个人工作内容都填充溢
整个sprint。
在未开端
Scrum之前,每周一次需求会议,只是托付
好相关需求,由开发主管来指派任务,并定好工作计划

表,然后QA同窗
补充相关测试布置
,最终
敲定上线时间。

其实不论

何种方式,最终的结果导向就是,产品尽快上线,且以最有效、风险最小的方式。

恰当
地砍需求

产品是不需求
懂技术,但是假定

能依据

需求大致预估工作量,排期更简单;每次我都会提早
多准备一些,连交互和重构都准备好,摆出一副不做此需求是誓不罢休的架势;资源充沛

时,技术童鞋会主动领取需求的,但是当工作都排的比较

满的时分
,就很难了;所以需求评审时,每个需求的优先级都排的高高的,将用户痛点描画

的栩栩如生,假定

技术真实
埋怨

太多,那就意味
性地砍掉部分

,前提是保证中心
必需
完成,其实当砍掉一部分

,不会不时

砍下去,而且心里也会有满足感;第二
给技术紧迫感,赶紧完成,后面还有一堆事情呢,即便

这次迭代不做,下次迭代也需求
完成

产品开发过程中

坚持
沟通

在产品开发过程中,技术都是十分

有义务
心的,会帮你思索
边境
条件,作为产品积极响应技术提出来的各种疑问,是维系技术与产品之间很有效的方式。固然
有一些问题,可能是技术对需求的了解

并没有产品那么深化

,讲分明

就好了,没有必要上纲上线,由于
最终大家的目的都是为了产品,另外公司开端
理论
的Scrum也对整个团队坚持
沟通,既是央求

,更要成为一种习气

认真看待

测试用例

测试用例,又是一个保证产质量
量的利器;刚开端
工作的时分
,以为
测试用例只是QA同窗
的工作,第一版本App上线做UAT的时分
,发现对着需求文档并不能完好
考证
完一切
需求,但是对着测试用例,一切
的主流程,辅助流程,边境
条件,非功用
性需求,明晰
明了,觉得
太有用了。所以每次都提早
完成需求文档托付
QA,QA在技术正式进入研发完成用例文档;在过测试用例时,产品同时参与,避免

一些需求了解

上的倾向

,此外技术同窗
对着case开发,比需求文档描画

更明晰
,另外技术同窗
能够

参与部分

自测;UAT的时分
,也是产品的参考。

需求变卦
与delay

需求变卦
是永世

的话题,Scrum中普通
是不接受

需求变卦
,其实不允许变卦
的实质

不是需求定板不动,而是对产品提出了更好的央求

,从需求调研、准备、设计、托付
每一步都需求
思索
周全和分明

;即便

在央求

严厉
的Scrum中,需求真的不能变卦
么?假定

暂时
线上bug构成

用户无法访问,技术同窗
是不是要停下手中工作,来排查线上缺陷

呢。作为一个产品,不是神,尽量保证一切
的需求都是合理且必要,并且将一切
的需求准备工作做到位;假定

还不能避免

,就要影响致使

压服
整个团队来拥抱变化。

正确处置
需求变卦

需求变卦
曾经
发作
,那就赶紧处置
吧。假定

是产品没思索
分明

,用户调研或者数据支持出错,果断向团队招认

自己

的错误,没有人会责怪一个真心诚意负疚

的人;并在第一时间托付
变卦
后的需求文档、交互、视觉、重构等,并跟技术沟通怎样
以最小的代价,完成此次完成
;若技术的工作在本次迭代曾经
布置
很满,那思索
需求的紧急水平

,恰当
状况

下,能够

放到下个迭代去完成。

若是由于
行业或者市场变动,产品转型等缘由
,直接向团队传达变卦
的缘由
,以及接下来的产品规划,让一切
人都看到一个明晰
明白
的目的
,技术会有疑问和应战
,耐烦
解答,经过
行业数据、竞品等角度去论述

;遇到老板变卦
需求,那比较

简单,由于
老板的需求优先级永远是最高的,但是作为跟技术直接沟通的产品,要认真看待

老板变卦
的部分

,若老板频繁变卦
需求,烦的是技术,会不会以后协作
留下影响呢。

关于产品delay

不论

产品还是技术,没有人愿意看到delay的;面对delay,怎样
处置
?换个思绪
:就算delay了,只需
用户还能用,效劳
照样跑,地球还照样转。假定

真的招致
用户不能访问,整个技术团队肯定加班加点,不吃不喝也会搞好的。一旦呈现
delay,整个团队一同
来排查delay缘由
,是需求变卦
,还是资源没到位,还是项目之间的耦合关系,前面小的改动,招致
后面项目的延期,做好每次的总结会议,并在下一个迭代中避免

此问题。

目前团队中正慢慢

引入Scrum矫捷
开发,而本篇总结,大部分

是基于小瀑布方式

的迭代;需求
学习的还有很多,一转眼又过了两个月,正式工作曾经
八个月,需求
走的路还有很多,跟随整个team一同
生长

本文作者系大众

点评产品经理@手忙脚乱
裸奔地小石头
。来源:leiphone.com

给大家举荐

我国新一代大数据用户行为剖析

与数据智能平台:数极客(https://www.shujike.com),是支持无埋点、前端埋点、后端埋点、API导入四种混合数据采集方式,整合剖析

用户行为数据和业务数据,能够

自动监测网站、APP、小程序等多种渠道推行
效果剖析

,是增长黑客们必备的互联网数据剖析

软件。数极客支持实时多维剖析

、漏斗剖析

、留存剖析

、途径
剖析

等十大数据剖析

办法

以及APP数据剖析

网站统计网站剖析

小程序数据统计用户画像等应用场景,业内首创了六种提升转化率的数据剖析

模型,是用户行为剖析

范畴
首款应用定量剖析

与定性剖析

办法

数据剖析

产品

发表评论

评论已关闭。

相关文章