小明与老王的日常：学会做这4件事，让你的产品提前上线（2）.docxVIP

小明与老王的日常：学会做这4件事，让你的产品提前上线（2） PAGE 1 小明与老王的日常：学会做这4件事，让你的产品提前上线（2） 太多的产品新人，甚至于工作1两年的产品汪，在开发阶段往往出现很多对接问题，影响上线进度。在此，我将程序开发阶段总结为一下4个流程，并会用故事的形式，分流程介绍我们该如何与开发对接。因内容较多，且需要与实际工作结合进行考虑，所以建议大家收藏下来，慢慢看。下图为此系列内容的大纲（此系列内容的大纲）今天我们聊聊第2部分，制定开发流程与关键节点。如果没有看过第1篇文章的，请点击下面的传送门：《小明与老王的日常：学会做这4件事，让你的产品提前上线（1）》第二天，小明按照老王的吩咐，召集了技术部的同事们进行了项目评估会议，会议中，小明从项目背景介绍、功能流程介绍、关键目标确定三个方面，向程序猿们描述了接下来要开发的产品。会后，老王将小明叫到了会议室，习惯性的点了一根烟，深吸了一口说道：小明，还不错，该讲清楚的都讲清楚了，就是在讲的时候，需要再自信点。你要对自己的产品有自信，别人才会认可你的产品。您说是吧。小明：嗯，都是王总教的好，以后我会记住的。对了王总，那接下来我该做什么呢？老王：别急，这次叫你过来，就是跟你说接下来的事情的。开会前，你是不是把产品原型、产品说明文档、设计稿、交互稿都交给程序猿了？小明：嗯，是的，都发给他们了。老王：好，那接下来，你需要做的就是协调项目经理、程序猿们一起确定项目的工作量、开发顺序与关键节点。当然了，我们公司没有专职的项目经理，这个你可以直接找孙总。（孙总是公司的技术总监）确定项目开发工作量老王抽了口烟，继续说道：首先呢，你先去找项目经理沟通一下，看项目经理能否在近期（一周左右）对项目的开发量进行一个评估。至于这个评估时间，你不要卡的太死，给他们充足的时间去仔细研究。这个阶段是程序猿了解需求的时候，我们需要给他们充足的时间去研究需求，只有需求研究透了，才不会出那么多bug嘛。老王：那在这个阶段，你可能会遇到下面这几种种情况：程序猿需要你帮忙解释需求。程序猿给产品提修改建议。程序猿要求砍掉部分需求。提交的PRD、设计稿、交互稿缺少部分内容。反馈回来的工作量评估表很粗糙。小明：王总，上面这几种种情况，第4个我会处理，缺少的内容我回去找一下，看看是不是我提交的时候遗漏了，如果确实是没有做的话，到时候再从新做一下，补给他们就好了。那剩下的几个问题呢？通常我们都是怎么处理的？老王：别急，让我慢慢跟你说。这第1个问题呢，是我们肯定会遇到且必须要做的事情。不过在做的时候，一定注意不能太急躁，不能一上来就说：需求里面说的很清楚啊，就是这这样···那样····。如果你这样做的话，程序猿肯定给你一个大大的白眼，心里想：我TM能看懂我还让你解释什么？这个时候正确的姿势应该是，从场景出发，解释用户在日常工作中是怎么使用这个功能的。如果是问到一些数据调用的问题，需要说明数据是在哪里产生的，这样程序猿们会清楚哪些数据是需要从新建立数据表，哪些是已经有现成的数据。当然了，如果你短期内也解释不清楚的话，就诚实的跟程序说，我先回去看看，等等给你答复。不要在自己不清楚的时候下结论。老王：第2个问题呢，当程序猿给你提修改建议的时候，一定不要直接否定了，很多好的创意，都是程序猿想出来的。如果程序猿提出来的建议是你之前思考过的，你可以把你之前考虑的思路跟他沟通一下，如果能说服他最好，如果说不不了他，而且此功能对用户没有太大影响的话，可以适当的进行修改。那如果程序猿提出的建议是之前没有考虑过的，这时候你要仔细听一下程序猿是怎么说的，不要当场回复，回来再考虑一下，整理一下方案是否可行，再去沟通确认。这个时候记住一点，所有的建议，必须以方案的形式进行落地。这才有执行价值。老王停顿了一下，看看若有所思的小明，缓缓道：那我们说说第3个问题，就是程序猿砍需求的情况。这个问题在每个项目的开发过程中，都是经常遇到的，而且还是产品经理与程序猿产生矛盾的集中点。所以在遇到这种情况之前，你首先需要弄清楚你的产品的核心功能（不可缺少的功能）是什么，辅助功能（存在会有更好的体验，没有也不影响正常使用）是什么、意淫需求（没有使用场景或者说使用场景不实际的需求）是什么，模棱两可的需求（这样也行，那样也行）。当程序猿要求砍掉意淫需求与模棱两可的需求时，应果断砍掉。甚至于在他们没提出来之前，就应该砍掉这里面的部分需求。当提出要砍辅助功能的时候，我们就需要进行合理且善意的引导，尽量让程序员接受这个功能，可以通过场景进行引导，让程序猿觉得这是个有用的功能，能带来价值的功能。如果程序猿坚决要砍掉，我们就需要适当的做妥协，可以将这个功能放在最后开发，甚至于下一期来进