产品经理具备的开发知识.docVIP

吹膜机/ ，品牌整合传播/ ??? ??? 运营——产品——技术，产品经理就是个人格分裂的角色，呵呵。一会要站在产品角度考虑这个产品，一会要站在技术开发角度去谈。有时候真觉得自己很错乱。尤其是在这个过程中去平衡双方的关系，保障产品整体完整时，更是如此。最近遇到了很多这样的沟通，每次运营会问，为什么不能这么做呢？我觉得这个很简单啊，等等。技术会说这么做很重复啊，关系不是这样的应该是什么什么……对接的久了，觉得自己在中间夹杂的好混乱。 ? 问过很多人怎么让自己在这个过程中能全身而退，得到的答案基本一致，就是要产品人员具备运营和技术的相关知识，产品经理，牛。百事通。哈哈 今天在网上看到这样的文章顺便摘要下与大家一起分享下。 产品经理应该具备的开发知识首先了解开发人员的工作流程。这样在沟通、协调起???会更加顺畅。一般当工程师接到产品开发需求的时候，最直接想知道的几个问题是：这个是一款什么产品？产品是怎么样的一个产品，这个产品的背景的由来是什么。什么时候确定下来的？谁确定下来的？我们为什么要做这做个产品，做与不做对目前有什么区别。这个产品在整个体系中扮演的角色是？—-这个直接让工程师知道要做的对象是什么，进而才会有很清晰的概念存在。 ? 这个产品的意义是什么？ 产品的意义在于哪里，通过开放这个产品能产生什么？又改变什么？帮助用户方面做什么样的提升？帮助我们商业层面又有多少的帮助?—这个直接决定了工程师是不是认可做这个事情的价值，能不能让他们很兴奋、全身心的投入进来做这件事情。 这个产品到底要做哪些事情？ 这个产品到底要做哪些事情，几个关键的应用场景、关键的应用业务是什么？哪些事情是最主要预先要解决的？哪些事情是相对不重要的？–这个直接决定了工程师是否觉得业务是不是很具体，是不是可以很好从系统的角度去抽象业务，进行系统设计。 这个产品具体的实现逻辑是什么？ 具体实现的逻辑，就是在开发产品的时候，把关键业务、主场景、关键业务逻辑梳理出来，希望通过什么样的方式去实现。—这个直接决定了工程师可以初步的评估你这个产品方案的可行性，现有框架的对实现逻辑是不是支持，也决定了要支撑这个逻辑的实现成本。 这个产品的产品经理是谁？ 这个产品经理是谁也是很重要的，产品经理是不是OK？是不是可以好配合？好沟通？产品技术的专业技能怎么样？是不是有激情？–这个直接决定了工程师是不是喜欢和你打交道，是不是认可你，认可你的产品的一个重要因子。 这个产品需要我们多长时间做出来? 资源总是有限的、大产品分项目做，小产品一个项目开发周期搞定。但是多少时间要做出来，还是非常客观的一个评估条件。—这个直接决定了工程师在评估完开发成本后决定是不是缺人要加人进来，是不是需要非常规，敏捷开发等等。 以上这些问题，都是你在给工程师提交需求之前一定要想明白的。第一：如果你自己都想不明白，描述清楚这个产品到底是什么样的产品，要做什么不做什么，意义在哪里，具体怎么做？那势必给别人的感觉是你没有想明白，那别人怎么会相信你，信服你。继而开足马力的支持你配合你。 第二、这些问题也是你换位思考的一个方式。产品经理如果一直站在产品经理的视角看问题，那肯定会忽视了很多事情的细节、很简单的工程师也是一群需要尊重需要肯定，喜欢做有挑战事情的人，你如果都不重视工程师对项目开发的感受，人家凭什么要重视你对产品的感受，一样的道理。 第三、大家的目标都是要完成目标、有成就感，那么产品经理就得要多走一步，因为整个事情是围绕你始终的，你要让你自己兴奋起来，全身心的投入带动所有工程师全身心的投入。大家使命一致，这也是很重要的一个方面，绝对不能忽视。 曾经在《产品经理怎么样和工程师打交道》一文中有写过一些相关的跟工程师的理解，大家有兴趣的再回顾一下。接下来步入正题，讲一讲产品开发人员的相关知识。 产品开发流程，实质上大公司也好、小公司也好大同小异，但是在具体的人员角色的分工上不一样。一般一个产品需求对接过去了，技术部会评估分析需求和工程师的情况，以及项目需要交付的情况，首先会得出需求开发方式、项目参与人员角色。 1、这个产品需求开发量很小，是不是走小需求流程就可以了？ 2、这个产品需求开发量很大，是不是得走项目流程才可以？ 在项目流程角色里面：还会根据你项目实现的复杂度、困难度的情况，评估需要不需要： 项目经理 需求分析师 构架师 如果不需要，不需要重构，不需要改变环境，只需要做一些应用的开发、调整，那可能就需要几个开发的工程师就可以了。 ? 其次，工程师队列确定下来以后，就开始评估项目的目标和范围，看一下是不是需要把产品需求按照优先级拆分成几个项目来做。 很简单的道理，从无到有的产品，一般的开发量都不小，如果一下子上，大家累死累活搞个半年，还不如3个月一个周期上个雏形，然后1个月1个月慢慢迭代，这也是小步快活的一种灵