0.前言
“你无法衡量的东西，就无法有效管理”——管理大师彼得德鲁克如是说。一个产品从设计、开发、测试到最后上线，必须有严格的规划，并有相关的标准去衡量它，不然整个项目将会像一盘散沙无法管理。对于一款互联网产品来说，一个生命周期包含从0到1或者从1到无限优化都要做细致的规划，毫不夸张的说，一个好的规划可以让整个团队有条不紊的运转，规划不合理让团队怨声四起甚至引起项目的正常推进而导致延期。
根据我个人的经验，我把产品的规划分为：项目整体规划和产品的版本迭代规划。
1.项目整体规划
项目整体规划指的是项目从立项到首个版本的规划，即从0到1的过程。这一过程需要确立整个产品的架构，然后模块化，再模块下面进行再一次细分，如下图所示：
一般来说，一个项目整体上分为如下几个流程节点：
里程碑：里程碑为一个项目的整体目标，产品达到上线标准的总和。比如一个商场APP，想要达成的目标是：商品展示、搜索、购物车、支付、退货等一整个购买流程，这些目标的集合构成了这个项目的里程碑。
跟踪项：跟踪项是只单个的目标，跟踪项的集合就是一个里程碑。比如把购物车作为一个跟踪项。
任务：任务作为跟踪项的子集，比如购物车作为一个大的模块，里面包含很多功能模块，可以把任务当做一个功能模块。
功能：功能指的是一个个具体的功能，而且必须是可用的功能。比如购物车里面一个删除商品功能、或者选择优惠的功能，他们都是一个单独的功能。做出来的功能必须要是可用的，即要进行功能测试。
整个项目的任务结构大致是这个样子的，但是必须指出的是，里程碑、跟踪项、任务、功能必须要有截止时间，而且需要有衡量的标准。比如支付可以作为一个任务，包括货到付款、微信支付、支付宝支付等第三方支付，可以把微信支付作为功能1，规定完成的时间，完成的时间包含测试时间，衡量的标准就是可用，功能能够走通。同理，支付宝支付也可按照这一标准执行下去。总之，每个节点对应相应的责任人以及完成的时间节点，加上衡量的标准，这样就可以按计划执行下去了。
2.产品版本迭代规划
一款产品正常上线后，各方面的反馈和业务需要必然会推动着产品向前迭代。我个人总结的一套迭代的流程，如下：
产品的版本迭代需要对各个版本更新的内容以及完成的时间点做出严格的规划，即，在下个版本发布的时间截点需要完成哪些功能。比如目前的版本是v1.0，月底要v2.0上线，v2.0需要更新的内容必然是事先规划好了的，作为产品经理，在团队开发2.0的时候，就需要开始规划3.0的需求或功能了。我一般这样规划一个版本的流程：首先确定这个版本需求完成哪些功能或者解决哪些bug；其次，如果是新的需求，先做进行需求分析，根据需求的场景与开发沟通原型及流程，适当的做一些修改，确认后，和UI设计师进行沟通，设计师产出设计稿，然后自己产出需求文档；最后，规划好了，接下去就是执行了，关于执行的话，可以把这个版本当成一个里程碑，具体的执行步骤就按照上面说的“整体项目规划”啦，一切就绪之后，版本就可以发布了。
说个题外话，很惭愧，有时看到其他产品经理写上厚厚一大摞的需求文档，佩服的五体投地，我的需求文档相比之下就显得有些单薄，我一般就在原型里面做一些注释，就算是需求文档了。以前确实写过那种洋洋洒洒上万字的文档，现在觉得原型+注释+流程图的文档会显得相对简洁一点，当然，这是个人之见。
3.小结
世上没有完美的流程，在走流程的过程中，一定会有异常情况发生，这就需要产品经理有能力去处理。比如，在一个版本的规划完成后，临时有需求出现，如何处理？这就需要我们对需求进行评估，确定优先级，同时规划的时候预留一点时间。另外，一个功能在做的时候发现流程走不下去，都是坑，该怎么处理？这绝对是产品经理的锅，一个功能从用户操作到完结，所有状况每个步骤，产品经理一定要实现想清楚，不然会妥妥的把开发带到坑里。当然，规划好了，接下来最重要的就是执行了，这里不讨论了。
总之，项目的整体规划外加产品的迭代大体上会让项目在一个正常的轨道上运行。当然，理想总归是理想。
