产品经理应该具备的开发知识

　　博友一根弦留言，说讲讲《产品经理应该具备的开发知识》了解开发人员的工作流程，沟通、协调起来会更加顺畅，这回就定制一下这个话题。一般当工程师接到产品开发需求的时候，最直接想知道的几个问题是：
　　这个是一款什么产品？
　　产品是怎么样的一个产品，这个产品的背景的由来是什么。什么时候确定下来的？谁确定下来的？我们为什么要做这做个产品，做与不做对目前有什么区别。这个产品在整个体系中扮演的角色是？这个直接让工程师知道要做的对象是什么，进而才会有很清晰的概念存在。
　　这个产品的意义是什么？
　　产品的意义在于哪里，通过开放这个产品能产生什么？又改变什么？帮助用户方面做什么样的提升？帮助我们商业层面又有多少的帮助？这个直接决定了工程师是不是认可做这个事情的价值，能不能让他们很兴奋、全身心的投入进来做这件事情。
　　这个产品到底要做哪些事情？
　　这个产品到底要做哪些事情，几个关键的应用场景、关键的应用业务是什么？哪些事情是最主要预先要解决的？哪些事情是相对不重要的？这个直接决定了工程师是否觉得业务是不是很具体，是不是可以很好从系统的角度去抽象业务，进行系统设计。
　　这个产品具体的实现逻辑是什么？
　　具体实现的逻辑，就是在开发产品的时候，把关键业务、主场景、关键业务逻辑梳理出来，希望通过什么样的方式去实现。这个直接决定了工程师可以初步的评估你这个产品方案的可行性，现有框架的对实现逻辑是不是支持，也决定了要支撑这个逻辑的实现成本。
　　这个产品的产品经理是谁？
　　这个产品经理是谁也是很重要的，产品经理是不是OK？是不是可以好配合？好沟通？产品技术的专业技能怎么样？是不是有激情？这个直接决定了工程师是不是喜欢和你打交道，是不是认可你，认可你的产品的一个重要因子。
　　这个产品需要我们多长时间做出来？
　　资源总是有限的、大产品分项目做，小产品一个项目开发周期搞定。但是多少时间要做出来，还是非常客观的一个评估条件。这个直接决定了工程师在评估完开发成本后决定是不是缺人要加人进来，是不是需要非常规，敏捷开发等等。
　　以上这些问题，都是你在给工程师提交需求之前一定要想明白的。第一：如果你自己都想不明白，描述清楚这个产品到底是什么样的产品，要做什么不做什么，意义在哪里，具体怎么做？那势必给别人的感觉是你没有想明白，那别人怎么会相信你，信服你。继而开足马力的支持你配合你。
　　第二、这些问题也是你换位思考的一个方式。产品经理如果一直站在产品经理的视角看问题，那肯定会忽视了很多事情的细节、很简单的工程师也是一群需要尊重需要肯定，喜欢做有挑战事情的人，你如果都不重视工程师对项目开发的感受，人家凭什么要重视你对产品的感受，一样的道理。
　　第三、大家的目标都是要完成目标、有成就感，那么产品经理就得要多走一步，因为整个事情是围绕你始终的，你要让你自己兴奋起来，全身心的投入带动所有工程师全身心的投入。大家使命一致，这也是很重要的一个方面，绝对不能忽视。
　　曾经在《产品经理怎么样和工程师打交道》一文中有写过一些相关的跟工程师的理解，大家有兴趣的再回顾一下。接下来步入正题，讲一讲产品开发人员的相关知识。
　　产品开发流程，实质上大公司也好、小公司也好大同小异，但是在具体的人员角色的分工上不一样。一般一个产品需求对接过去了，技术部会评估分析需求和工程师的情况，以及项目需要交付的情况，首先会得出需求开发方式、项目参与人员角色。
　　1、这个产品需求开发量很小，是不是走小需求流程就可以了？
　　2、这个产品需求开发量很大，是不是得走项目流程才可以？
　　在项目流程角色里面：还会根据你项目实现的复杂度、困难度的情况，评估需要不需要：
　　项目经理
　　需求分析师
　　构架师
　　如果不需要，不需要重构，不需要改变环境，只需要做一些应用的开发、调整，那可能就需要几个开发的工程师就可以了。
　　其次，工程师队列确定下来以后，就开始评估项目的目标和范围，看一下是不是需要把产品需求按照优先级拆分成几个项目来做。
　　很简单的道理，从无到有的产品，一般的开发量都不小，如果一下子上，大家累死累活搞个半年，还不如3个月一个周期上个雏形，然后1个月1个月慢慢迭代，这也是小步快活的一种灵活策略，也可以允许中途有些需求的变更和调整。
　　最后评估所需要的测试资源，需要多少测试人员进行测试。
　　如果说流程的话：需求提交需求评估项目立项项目的项目开发测试上线。这些具体的去苏杰的书《人人都是产品经理》去看好了，不具体围绕展开了。反正有一点就是说一说敏捷开发。开发有2种模式一种是非并行的开发模式，就是说：A环节好了，然后给B进入下一个环节，B好了然后又给C，然后C好了又进入下一个环节给D
　　这种模式是流程式开发的模式，反正工程师永远会说：“产品的需求还没有全部完善，老子死活没法往下做。“然后测试的又说，前面的你们都没定呢，我们怎么可能跑到你们前面去。
　　这样的开发模式，你想嘛，想快就快不了了，大家扯皮的时候比较多。
　　那另外一种就是并行的开发模式，就是说ABCD不是站在1根轨道上，站在4根轨道上，大家充分通好气以后，只要有一方把一部分东西明确下来以后，下面的人就可以按照这种预定线性往下了。这样的方式非常灵活高效，特别是需要非常着急的去完成一个项目开发的时候。我画了一下流程示意图，大家可以和上面的比对一下时间（横轴为时间）。
　　不得不说并行开发的模式，现在很多人都喜欢口口声声叫他敏捷开发，敏捷开发确实是一个好东西，但是现在大多数情况绝对成了被逼出来的产物了。时间就这么多，人就这么几个，东西一定要出来。所以大家没办法了，不能按照流程出牌了，都往前走多了一步，于是有了协同。
　　大公司和小公司从本质上没有啥区别，但是有一点，组织结构不太健全的公司是产品经理就当策划、又当UED、又当测试。程序员又当项目经理、又当需求分析师、又当构架师、又当测试。所以项目风险很大的程度上取决于核心程序员的个人修为，反正测试也没有太多的性能测试，大家都是使用一下，点拨点拨给你功能使用没问题就行了。因为请求比较少很多时候靠服务器增量还是扛得住。
　　最后一根弦：
　　跟开发沟通、协调的一点我个人的建议是：
　　1、怎么让很多想不明白的问题，让开发帮你想，帮你得到答案，我觉得是需要考虑一下的。
　　2、还是要多沟通女产品经理沟通起来，一般都OK的，工程师怕磨，这一点我是身有体会。
　　3、沟通、协调的最本质的是：要站在对方的角度考虑问题，流程都是死的，人是活的。
　　4、只有知道对方在想什么？想做什么？不想做什么？大家对待这件事情上到底想要什么？不要什么？你的操作空间才会更大。
　　以上仅仅是站在执行层面的一点个人观点，也欢迎大家更正补充。大家想了解什么，我也可以根据大家的需求定制哈哈，貌似很伟大。装了。