目录
1. 明确分工，知其表亦知其里
2. 别让测试等着开发，也别让开发等着测试
3. 串行和并行：合理的穿针引线
4. 不确定性始终存在：小步快跑！
5. 明确产品经理的定位，再来说说高效运转
6. 产品经理应该是精英：少即是多
1. 明确分工，知其表亦知其里
做排期之前一定要明确产品开发必须的生产要素，即设计、测试、前端开发、后端开发等。
设计
交互设计与UI设计，当原型图设计完成后第一时间要和设计沟通并做出相应设计图，根据以往的UI基调设计出相应的设计图并交付给前端。UI设计的一致性很重要，在产品之初就要想清楚并定义好，就算后期涉及到某些人事变更，也需要保证UI/UX风格的统一性，或者能够保证修改后的UI/UX风格一致性地实现落地。不止一次看到一个产品里面的UI/UX风格元素有好几套，这样是很伤体验的，之于这点，做无论是做产品还是设计都要有所考虑。
测试
测试就是保证产品的质量即可用性，通俗而言就是提bug给技术开发，做bug排期，跟进bug以确保至少没有重大bug以发布当前版本产品。很多人提倡开发自测，这点很不靠谱，就像一个技术如果不丢掉自己技术思维去做产品一样，做出来的产品刻板可笑，测试思维和技术思维是两码事，必须要有一个能够为产品质量负责的角色。（PS. 如果一个技术拥有测试的思维，那他也可以做自测，问题是这样的人很少，这也是为什么TDD即测试驱动开发不火的原因，确实是对dev的要求很高啊）
前端开发
包括Android、iOS、Web前端开发等等，即实现view且会涉及到一部分view所包含功能逻辑的角色。关于web前端开发，web app的概念日盛，web开发可做的事情也越来越多，H5大行其道、方兴未艾，native app大有被其扬弃之势，混合开发亦早已是常态。产品经理在设计view时也需要考虑到这些，并且在对具体item定义和设计时关注其可复用性，并且时时刻刻关注产品功能设计的可延展性也要想清楚，在设计和前端开发的合理排期中这点也十分重要。
后端开发
包括架构、数据、接口、后台管理、（运维）等，后端开发需要搭建web框架以满足前端web或者app的接口访问需求以提供数据，合理定义并搭建数据结构以满足无论是后台管理还是web框架的CRUD（增删改查）需求。后端重业务逻辑和数据处理，一方面后端开发要对前端产品的接口可用性负责，而在数据和业务方面，则无论是在数据挖掘、爬虫、数据匹配推荐、搜索、标签系统、anti-spam等方面都可能有所涉猎。这些的大前提都是在产品提供一个合理的产品结构和业务需求的基础上实现的。如果是技术出身的产品经理，最好能把产品数据结构图实现，如果不是那也需要尽力去配合后端开发并与之在此处达成一致以保证对后端整体数据有一个清晰的脉络认识。对数据有感知的产品经理必然会反过来加深其对业务的剖析和理解，并优化其对产品业务需求的整体把控。
2. 别让测试等着开发，也别让开发等着测试
提倡边做边测，在合理的功能模块（开发需求模块）划分的粒度内进行做完就测、测完就改、然后再回归继而再反复，这样的好处有以下：
开发者本身对代码的熟悉度一定是随着时长而减弱的，能够快速地反馈问题并处理问题，其在效率上的表现一定是更好的且具备一定的连贯性；
质量把控是一个长期持续的过程，是一个发现问题、解决和优化的过程，保证这个过程的动态可持续性（弹性）也要求需要边做边测而不是等开发完成；
测试是划分单元进行的，在某种程度上也可以验证当前迭代排期的合理性，以完善优化整体排期。
3. 串行和并行：合理的穿针引线
正如上文提到的：别让测试等着开发，也别让开发等着测试。合理的排期一定是串行和并行任务合理交织安排的，串行即人与人之间的协作以一个人完成交付物后交付给另一个人就方可可执行的；并行即人与人之间互不干扰就可以执行的。
常见串行：
UI交付：当UI完成设计图后前端实现；
功能测试：一个功能模块开发完交付给测试（无论前端后端）；
bug提交：测提交bug并交付给开发解bug；
接口交付：（不提倡假接口），真实的接口准备好之后做相应的功能开发；
数据访问： 数据库表结构创建、数据访问层等搭建完成，可CURD，进行后台管理和接口的开发；
等等...
所有串行之外的任务都是可并行的。
首先要考虑功能闭环或者模块的完整性，这样提供给测试形成一个开发测试质量ok的周期闭环，其次要在后台能够保证提供前端可用接口的基础上进行前后端并行，依据这些原则进行view的实现即UI/UX的设计和实现落地。（这也是我目前的做法，可能每个人的做法各有不同，因人而异，仅代表个人观点）
总之，我认为排期要遵循：“串行优先满足，并行合理安排，最终要交付一个需求开发完成的可用的产品！”
4. 不确定性始终存在：小步快跑！
曾读《反脆弱》，记忆深刻，不确定性的环境会带来的进步巨大且不可忽略，不要过分强调预测和长远规划。一个好产品的诞生也是如此，必然也是在不确定性中生存发育成长出来的。这个不确定性来自于人、环境等等要素，不断收集这些要素，产品经理要保持一定的敏锐度，合理调整产品排期和需求以满足产品以及各位参与的小伙伴和它最终要达到的目标。
关注合理的分模块的排期，按照串行并行的原则合理排期，并且定好目标，在动态中调整，确保每个小伙伴对自己现在要做的、马上要做的和要做到什么结果，目标是什么要很清晰。产品经理在排期过程中一定要肩负起“让大家明白”这个角色，排期一定不是一劳永逸的，其讲求动态发展和进步，在不确定性中小步快跑！（对于feature的priority的排序也是类似的道理）
5. 明确产品经理的定位，再来说说高效运转
很多时候，产品经理都会在如何协调资源、RD不大配合、为什么遭受质疑等等问题上的犯嘀咕，其实有可能还是对之间的定位不够清晰或者产品规划本身存在问题。（或许也有可能是自己low，要好好思考如何提高自己。我有个口头禅“just 干！”，别想那么多有的没的，发现问题就特么想办法解决它！就是干！）。
产品经理必须要明确自己的定位！（基本素质哪些就不谈了，比如沟通能力、同理性等等的）
产品经理必须要明确自己的定位！产品经理必须要明确自己的定位！（重事三）：
需求创建者：需求的调研与创建（对业务的理解、对运营的理解等）、继而输出原型图；
资源调度协调者：合理的对资源的调度和安排，不要出现因为需求和规划不合理导致的效率低下、资源浪费以及返工的现象；
任务管理者：task的大管家，合理安排任务以及排期，通过洽淡个的协作方式，比如用project、omniplan或者一些在线协作工具，保证每个人对于任务的时间性和产品整体进度的感知；
对产品负责的角色：很多产品经理缺乏对产品的责任心注定无法level up或者眼界被局限，有时候就是靠那股心气儿；
倾听者和思考者：多听听大家的意见和想法并多思考，始终保持和大家想法上的同步，确保能够达成一致，这很重要。
等等...
通过以上建立大家对产品经理的信任，信任感这件事情非常重要，体会一下，不赘述。其中资源调度协调和任务管理很大程度上就取决于：合理的排期以及合理地安排每个角色在合理的时间完成合理的事情，在某种程度上群策群力地高效运转并完成。高效是对于企业成本的考量，合理的排期则是对产品能够顺利交付的保证，产品经理必须体会到这些，理解其并使自己不断level up。
6. 产品经理应该是精英：少即是多
说点关于关于产品经理的想法：
产品经理应该尽可能少，我一直这么觉得。产品经理一定不是想想idea、调调研、琢磨琢磨需求这么简单（要知道人人都是产品经理，非得产品经理想idea嘛，能不能学会调动大家思考的积极性？），或者以梳理业务逻辑、需求的调研等等任务量太大需要很多产品经理，纯粹扯淡！产品经理不够自信要以量取胜？其实坦白讲，我做过好几款产品，从需求到原型到落地排期到最后开发出来，包括我现在在做的也是，大部分时间就我1个产品经理即我自己，在2、3个月内一个产品就最终实现出来了，而且功能不弱于很多4、5个甚至更多产品经理团队做出来的产品，这个问题值得深思。
最好产品经理和技术的比例是1：6~8、产品经理和运营的比例是1：5左右，这个并不是我一个人的观点，正如快刀青衣在《请开掉一半的产品经理！！》表达的，请开掉多余的产品经理吧。如果作为产品经理看看自己所处的team如果不是这样的配比，那自己的成长速度够吗？或者自己做的足够多吗？（这一点对创业公司尤为重要）如果真的要招产品，那通过产品专员或者产品实习生搞定的事情，就不要招多余的产品经理！
产品经理对自己的要求应该是精英式的，多学习、多了解其他人的角色，多了解自己能做的事情，以及多看到自己做的事情的不足。一个好的产品不仅仅就是找一个做过类似产品的或者同行业中做产品的人就能做出来的，他携带的只是基于以前旧有的静态的知识，在不确定性的环境中，我只讲反脆弱能力，即动态不确定性环境中进步的能力！产品经理需要成为精英，也必须对自己高要求，要独当多面。未来的产品经理门槛必然会越来越高，学习多多益善，并理解少即是多。
以上即我个人对于排期和产品经理的一些拙见，基本上是个人的所识所感，整理成文字并分享予诸君，望与切磋交流，学习进步。
本内容来自于王懿Lucien的公众号「类猿汪」，搜索jishugou即可订阅。若无特别注明，均属于个人原创，转载必须保留作者及公众号的信息。
关于作者：王懿Lucien，技术出身的产品狗，个人微信号minisky911，加好友请备注来自类猿汪，并描述基本信息。