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

再牛逼的产品经理也无法一个人完成一款产品 如果我是一个技术大牛，极具产品 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 能找到很多问题，减轻测试工作量