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

来人人都是产品经理【起点学院】，BAT实战派产品总监手把手系统带你学产品、学运营。

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

老大，我缺开发。

找外包。

老大，我缺测试。

自己顶上。

老大，我缺视觉。

协调资源。

老大，我缺项管。

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

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

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

一、需求层面

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

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

二、进度层面

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

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

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

三、质量层面

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

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

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

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

四、规范层面

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

内部方面：

1、规范测试准入标准

（1）阶段性功能提测：确保基本业务流程走通才能提测；

（2）bugfix：

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

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

3、规范代码review机制

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

4、规范产品需求

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

外包方面：

1、加强自测（配合我司的测试准入标准）

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

2、规范外包响应机制

1. 迭代开始，外包侧需要让两端的实际开发人员到场；

3.加强沟通

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

五、沟通真的很重要

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

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

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

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

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

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

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