再牛逼的产品经理也无法一个人完成一款产品

起点学院产品经理365成长计划,2天线下闭门集训+1年在线学习,全面掌握BAT产品经理体系。了解详情

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

cpjl

老大,我缺开发。

找外包。

老大,我缺测试。

自己顶上。

老大,我缺视觉。

协调资源。

老大,我缺项管。

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

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

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

一、需求层面

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

产品需求文档是指导开发、测试的基本文档,越明确越好。这里说的明确而不是详细,因为无论是开发、交互,还是测试,都不愿意看大片的文字,在外包项目的第一个迭代中,我的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. 开发同学之间是不是也缺少交流,两端各做各的。

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

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

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

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

 

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

您的赞赏,是对我创作的最大鼓励。

评论( 21

登录后参与评论
  1. 好熟悉的感觉

    回复
    1. 回复

      你也做外包项目?

  2. 产品经理和项目经理在国内大多数是同一个人。

    回复
    1. 回复

      很多小公司都不分。项目型的公司就有分。项目经理级别高于产品。呵呵,我前东家就这样。一家技术型外包大公司。

    2. 回复

      产品经理对技术没有管辖的权利,所以有新功能需求或者需求变动的时候,很容易变成一种技术部门与产品部门之间的博弈。

    3. 回复

      是啊,每次有变更都不是跟技术对接,是跟他老大对接 :arrow:

    4. 回复

      我司有项管,不过我也兼着部分项管工作

    5. 回复

      你们是外包企业吗? :wink:

  3. 产品的沟通能力确实很重要!举个例子,运营没法理解开发的意思,开发无法理解运营的需求,直接对话往往折腾了半天然并卵,所以需要产品在中间起到”翻译”的作用~

    回复
    1. 回复

      同感!!我经常突然插话于旁边热火朝天讨论的技术和运营之间,因为他们真不是一个世界的人,永远不理解彼此的意图 。

  4. :grin:

    回复
  5. 但是好多外行人,就以为请个产品经理就能把这些活都给承包了。特别在一些初创公司,自己根本都不知道产品需求量有多大,就急着找一个产品经理回来,计划用一个月的时间,把整个APP由0到1做起来。UI什么都没到位。只能呵呵了。这样的岗位,真不敢接。坑有多深还不知道,不想从一个坑里爬上来,又掉到另外一个坑。

    回复
    1. 回复

      前东家的boss都是销售出生,策划了一个超级app,秘密开发了2个月,然后市场争取到360首发。呵呵哒,接口居然没通,整个app无数据。在上架应用市场之前,除了CEO和COO,没有人见过那款app!

    2. 回复

      呵呵,前不久,就见了一家初创公司的负责人。一名非互联网的人,但又不停地装自己是很了解互联网的人。后来也跟我说,他是销售出身的。不断的游说我入伙,还说给我配股(但前提是把我的工资压低),十分热情。其实我是一个很理智的人。跟我说什么情怀,配股有多少分红,其实我是不信的。跟我吹了一个多小时,其实我知道很多东西是虚的。一个初创公司的领头人关系到一家公司能不能做得下去。当有一天,东西做出来了,不那么美好,互联网人一般会坚持,迭代优化,但外行人,就会怀疑员工的能力,再换一个产品经理或者换一个项目做。最怕就是外行领导内行,因为不是互联网出身的人,根本没有耐心去做用户培育。

    3. 回复

      互联网公司一定要有技术合伙人,不然很难做起来,很难做活了

    4. 回复

      是啊。

    5. 回复

      非常赞同这个观点“当有一天,东西做出来了,不那么美好,互联网人一般会坚持,迭代优化,但外行人,就会怀疑员工的能力,再换一个产品经理或者换一个项目做。最怕就是外行领导内行,因为不是互联网出身的人,根本没有耐心去做用户培育。”

  6. 这个作者应该是一个开发出身的产品

    回复
    1. 回复

      说出来怕吓着你,我是先搬了几年砖,又打了一年杂,然后做的产品

    2. 回复

      同行,我和你一样,也是搬了两年砖,现在在做产品,我现在也在做外包,方便的话加QQ指点一二?可以否?

    3. 回复

      微信、QQ都是787224927

加载中