产品规划可以变化，但要把握节奏
有一种忙，叫“瞎忙”！
在产品研发的过程中，我们常常是不是有这样一种感觉，产品战略是清晰的，但是实现产品战略的过程中，或者时快时慢，或者原地打转，或者循环往复，总是感觉每天很忙，却又不知道忙了什么！做了很多东西，但产品好像又无太大进展！当我们有这种感觉的时候，往往是我们只有战略而没有战略分解，即没有产品规划。产品战略说的是WHERE的问题：我们在哪？我们去哪？而产品规划需要明确HOW的问题，更准确点是怎么去？而我们下一篇文章介绍的产品战术的内容也是HOW的问题，侧重具体怎么做？
业务规划画布
产品是业务的某种表现形式，或者其中的一个环节。比如电商业务，电商平台相关的产品或系统只是这个业务的一个重要组成部分，其他的还有市场营销如何做？上游供应链如何建设？下游渠道通路如何开拓？终端触达如何做到？所以我们做产品战略和产品规划都离不开对于业务整体战略及规划的了解和理解。
在和阿里产品经理雨宏沟通交流的过程中，我发现她做的业务规划的画布非常不错，站在业务角度而非仅仅产品角度去描绘某项业务的年度规划，将业务的长远战略，中长期发展面临的问题、机会，以及在当前的重点方向、发展的策略到重大事项的分解等等融为一体。
出自：https://heidixie.lofter.com/post/b8226_12326ce2
如果你不清楚如何做业务规划，不妨试试这个画布，顺着这个思路去制定自己的业务规划吧。
产品路线要清晰
没有计划的目标只是一个愿望！
产品战略源于愿景，并通过里程碑指引着工作流程，产品路线图可帮助产品所有者使开发流程与产品战略保持一致。路线图使您可以计划战略实施路径，它是团队在开发过程中的行动指南。有了它，您就可以知道如果朝错误的方向前进，应该在哪里移动以及何时调整。
一个长期迭代的产品，我们一般会在年底或者年初的产品战略制定的过程中同步发布年度产品路线图，作为全年产品研发的指导，如下图。
当然对于一个新产品或者一个大的里程碑，我们可以通过细化产品规划的方式，制定更短周期的产品规划，如下图。
产品路线图是战略规划的结果，它通常包括以下要点：
产品愿景 - 您希望您的产品在未来成为什么样的产品。
战略 - 执行计划，详细说明贵公司将如何实现愿景。
目标 - 可以通过特定指标衡量的有时限的目标。
倡议 - 广泛的主题，统一必须实现的功能，以实现目标。
功能 - 产品的实际部分，可以是功能的一部分，也可以是第三方应用。
时间范围 -完成特定目标或功能的日期或时间段。通常，产品路线图仅表示近似值。
状态标记 - 用于跟踪工作进度
同时，路线图不仅仅只是产品经理用于产品管理的工具，而是要起到上传下达的作用，成为全公司相关业务协同的指导工具，所以产品路线图的制定和发布需要建立一套贯穿全公司的流程。
迭代开发有节奏
我们在看体育比赛的时候经常会听到“节奏”这个词，“节奏没了，打乱了”，“要控制节奏”，“别进入对方的节奏”等等。其实软件开发也是有节奏的，这就是整个团队的节奏。如果开发团队不知道产品团队啥时候提需求，产品团队不知道开发团队啥时候有空做新需求开发，业务团队不知道研发团队什么时候发布新版本，可以预见团队的协同是一种什么状态？这种不可预见的状态其实是最可怕的，所谓产品开发节奏其实就是团队约定俗成的有规律可循的一致行动。
上图的这个流程是我们做软件开发的一次迭代的各个阶段，如何让每个阶段鱼头咬鱼尾，衔接的无比顺畅，这种顺畅不是取决于上游的什么完成，而是它应该什么时候完成，它有一个固定的周期，这就是团队的节奏。所以确定迭代周期是保持节奏的第一步。
我之前负责一款互联网应用产品，TO C领域的，我给团队的迭代周期一般是两周，即两周发布一个新版本。我有兄弟团队做偏TO B的产品，迭代周期是一个月。其实迭代周期到底多长合适其实没有定论，根据自己团队情况、产品情况自行决定即可，只要让团队成员都知道这个周期即可。当这个周期确定，我们就知道在这个时间里，需求阶段一般是多长时间，开发过程一般多长时间，测试应该什么时候开始，时间久了就形成了生物钟，自然而然的遵守这个时间要求完成相应工作。
一个迭代周期起始于当前版本的规划而结束于当前版本的发布，版本号的变化代表着产品走过的过程，版本号因为只是一个符号而经常被人忽视。版本号的定义和增长其实是有意义的，这个意义既是团队内对产品发展升级的统一沟通语言，对于外部用户和客户来说，也是传达产品升级改进的形象化语言，比如微信版本号的变化其实传递了微信产品升级的范围。下图是我们团队对于版本号的定义，供参考。一般最小迭代影响的是三级版本号的变化。一级和二级的版本号变化没有特别固定的周期，根据自己产品升级的范围确定。
拥抱有节奏的变化
我们做了产品规划，确定了迭代周期，是不是我们就不允许再变化了？当然不是！这个世界唯一不变的就是变化，这句话放在产品研发上也是非常贴切的。不论是新产品的探索还是成熟产品的创新突破，本质上都是不断的捕捉市场中瞬息万变的机遇和机会，用更快的响应去满足它。
既然变化不可避免，如何才能在变化中保持节奏呢？我认为迭代的周期和过程要尽量稳定，从而调整过程中的内容。即建立不破坏节奏的需求池，池满则溢，优先级高的需求替换优先级低的未开始开发的需求，当前需求池无法满足新的需求时，尽量规划到下一个版本进行满足。
不知道大家有没有体会，往往理想很美好，现实却很狗血，有些变化的确可能会打乱既定的规划和节奏，让研发过程变的混乱，比如：
领导（特别是老板）的需求强制加塞或行政命令干涉，打破需求评审的流程机制，提出了不合理的交付要求。当制度的制定者成为制度的破坏者的时候，将是一件可怕的事情。技术债务往往就诞生于这样的不合理的要求中。
当面向交付的项目存在资源不足时，如果项目开发和产品研发人员分工不清楚，职责不清晰时，项目会抢夺研发的资源，从而让研发进度变得不太可控，而导致失去既定的节奏。
我们拥抱变化，但不能接受这些不受制度约束的变化，它们才是破坏节奏的元凶。此部分内容我们将在后续的研发组织和制度制定的内容中详细讨论。
形成产品规划文档
有经验的产品经理或者项目经理会根据战略和运营重心排好优先级，做好取舍，按照里程碑时间点来开发，保持一个顺畅的节奏。所谓不忘初心，方能始终，其实就是要求产品经理把产品规划落实到书面上而不是自己心里，才能让我们时时去回顾，常常去检查。以下图作为本文的总结，希望你找到自己的节奏。
#作者简介#
菜根老谭，微信公众号：CGLT_TAN，人人都是产品经理专栏作家。经历程序员、技术Leader、研发Leader等多种岗位。关注医疗，早教领域，擅长企业IT架构及互联网产品架构。