欢迎光临
我们一直在努力

产品经理是怎样完成一款产品的?

如果我是一个技术大牛,极具产品sense,还凑巧精通Origami、AI、PS,我完全可以一个人做款APP,并持续 迭代!我做过技术,是建筑行业的技术;我会画图,都是用CAD和SkechUp;我很认真的做产品,但刚满一年而已。答案显而易见,我一个人是无法做产品 的!

老大,我缺开发。

找外包。

老大,我缺测试。

自己顶上。

老大,我缺视觉。

协调资源。

老大,我缺项管。

一阵可怕的安静之后,老大笑着对我说“产品经理是什么?产品经理就是发现问题,解决问题。优秀的产品经理必须在缺少测试、设计、项管情况下自己承担起来。”

我眨了眨眼,对老大说“那我是不是还要学编程?”然后在老大还没来得及发火之前逃离了办公室。

一个字形容我的项目——真的很缺人。说是一个人做有些夸张,但是在技术外包,交互、视觉、测试、项管全都兼职的情况下,我真的有些无力,项目也曾经 历了上线延期,崩溃率过高,用户差评无数的情况,好在这些都成为过去。现在跟大家分享一下外包项目的注意事项,希望对同行们有所帮助。

一、需求层面

需求不明确,这是产品经理的大忌,在这种情况下即便外包把下载做成上传你都没什么好说的,谁叫你需求不明确呢。

产品需求文档是指导开发、测试的基本文档,越明确越好。这里说的明确而不是详细,因为无论是开发、交互,还是测试,都不愿意看大片的文字,在外包项 目的第一个迭代中,我的PRD写了23页,封面、目录、修订记录、产品介绍、功能性需求、非功能性需求外,还加上了其他和特别说明,一个需求评审走下来要 一两个小时,当我讲完后看到开发经理满脸茫然的表情,我知道这是一次失败的评审会。

为了让开发更好的理解产品需求,为了让交互更好进行设计,为了让测试的test case更加完整,我司逐渐推广“story+线框图+标注”模式的PRD,story务必条理清晰,线框图和标注务必简单明了,几个迭代走下来,明显感觉到外包对需求的理解准确了不少。

二、进度层面

没有deadline是万万不行的,项目可能无限制延期。而我的第一个版本就吃了这样的亏,由于我司一个模块在开发中,release版本事件待定,就将产品交付事件拟定在8月中,可是最后延期了两周,期间还有各种撕逼,好不难受。

可是仅有deadline也是不够的,毕竟功能的开发存在不确定性,联调时间、测试时间、debug时间无法保障,如果仅有deadline,很容易将全部风险往后堆积,最后的结果只能是项目延期,产品经理被批!

你需要设置项目节点,阶段性交付、阶段性提测,把风险分散并提前。当前在进行的迭代我们设置了四个节点,两个模块化提测节点,两个全功能提测节点,一个上线节点;虽然目前只进行到首次全功能提测,但是按照节点走的感觉真的不赖。

三、质量层面

外包项目开发中最怕的不是进度,而是质量。因为他们可能会早早的打包给你,可是你能测出100个bug。

要想在把控这一块,必须加强开发自测和代码review。在上一个版本出现过“冒烟测试不通过”的情况,你知道那种外包如期把包给你,你开心的测试,可是居然无法下手的痛苦和无奈吗?那一刻简直想把刚买的iPhone 6砸在他们脸上,这也提测,让我怎么测!

要保证质量,首先是开发的自测。当然如果你是技术大牛,对自己写的代码极其有自信,不自测也罢。可是大多数外包人员水平其实并没有那么高,那么自测是必要的,自测阶段可以发现不少问题,至少避免出现功能未实现便提测的情况。

其次是内部技术人员的代码review,我们的iOS开发主管跟我说“代码review必须阶段性进行,放在功能性测试之前,我们通过代码就能 review能找到很多问题,减轻测试工作量”,直到那一刻我才知道原来这么重要,代码review不仅仅是看代码是否合乎规范,更重要是看代码的分层、 封装、碎片化是否足够,是否有隐藏的bug,是否需要重构等。

我对自己产品的期望是在功能性提测之前完成代码review给到的建议,将功能性bug压缩至10个以内。

四、规范层面

前面提到了进度,提到了质量,但是这些都需要相应的规范来保障,不然还是水中月梦里花。下面是我在项目迭代中整理了部分规范,虽然不是很完善,但项目相对于之前确顺了很多。

内部方面:

1、规范测试准入标准

(1)阶段性功能提测:确保基本业务流程走通才能提测;

(2)bugfix:

  • a、开发根据jira中的优先级修改bug。
  • b、开发打包提测前必须充分自测,验证所有bug,确保老bug改完、无衍生出的新bug。如测试人员验证下来bugfix失败率>=30%可直接打回。
  • c、开发打包节奏,常规:一天打包一次,如一天内所有bug都改完,改完就打包体测;如有特殊情况,由测试决定开发的打包节奏。

2、外包合同中规定测试轮数

根据1的打回机制,从测试轮数(5轮)和时间(规定的项目总时间)上制约外包。

3、规范代码review机制

阶段性的review外包代码,如果老代码不符合要求,预估时间和优先级,根据紧急程度在开发中或后期维护期里修改掉。

4、规范产品需求

在PRD的story下面添加功能逻辑关系图,以便其他人员更好理解需求

外包方面:

1、加强自测(配合我司的测试准入标准)

根据测试用例,加强自测减少打回和项目延期的风险。

2、规范外包响应机制

  1. 迭代开始,外包侧需要让两端的实际开发人员到场;
  2. 代码审核、紧急bug修复等关键时间节点,需要开发人员到场。(预计:2-3天)

3.加强沟通

避免出现安卓、iOS两端对需求理解不一致的情况

五、沟通真的很重要

无论是PRD,还是项目节点;无论是代码review,还是功能测试;都只是保障项目顺利开展,如期上线的手段。最重要的还是项目人员的相互协作,沟通在这里至关重要。

我的项目曾出现过同一个需求和交互视觉,安卓和iOS做出了完全不同的功能。当时有好几个疑问飘在脑海里:

  1. 需求是否不够明确,以致开发同学理解有偏差;
  2. 需求评审会是不是不够细致,遗漏了这块;
  3. 开发同学是不是过于内向,有疑问时不敢找我沟通;
  4. 开发同学之间是不是也缺少交流,两端各做各的。

几个疑问都直指一个方向——缺少沟通,开发之间缺少沟通,开发和产品之间缺少沟通,开发和交互之间缺少沟通!

如果对需求有疑问,过程中应该及时提出,需求评审时应提出,两端同学交流时更应该提出,可是他们都没有来找我,而我也理所应该的以为他们理解了,会严格按照需求和交互实现。如果我在过程中主动对容易产生疑问的点进行沟通确认,也能避免这个问题。可是我们都没有!

上面仅是缺乏沟通导致的一个案例,类似的问题还有太多太多。各位同仁,关于产品经理最核心竞争力有太多讨论,我这里也不妄下结论,但是沟通一定是非常重要的!

愿大家都成为一个能沟通,会沟通,善沟通的产品经理!

未经允许不得转载:发现未来 » 产品经理是怎样完成一款产品的?

分享到:更多 ()

评论 抢沙发

评论前必须登录!

 

发现网服务 更专业 更方便

广告联系联系我们