最近看 learnpress 的官网，看了一下他们插件开发进度，发现自己关心的一些Restapi 这些未完成的功能都放在他们的路线图中。突然明白了敏捷开发的路线图的用法是这样的，有些现阶段功能还没有开发，但已经列到未来完善计划的功能，可以放到路线图中进行排期或者作为后续目标。在数据业务可预期的情形下，完全可以做一个这种前期规划过的功能开发计划、项目推进的工作路线图、项目路线图、开发路线图等。
以前我做产品喜欢按照一次性的项目来做，总要把功能列完整，然后把需要用到的功能都列出来搞个工期，如果研发排期把这个需求要砍掉，而我又同意了。那基本上意味着至少在这个项目周期里，这些需求不是必须的，而不是必须的需求，那我就觉得不需要在产品中实现。
如果整个项目规划的开发周期里还实现不了，在后面的产品规划中就不再考虑这些需求，而是针对实际项目部署和实施时用的功能重新完善整个产品的功能规划。
虽然这种产品功能的开发和规划比较适合按照项目性的开发产品，符合项目实际需要，但对整个产品的持续发展来说，也缺少了在功能规划过程后的持久性，总是围绕着需求来做规划，而不是围绕着产品的最终愿景和发展来做规划。现在很多项目因为工期紧张，而在初期的产品评审时只对第一期的产品功能和能实现的功能点做取舍，却不能把舍掉的那部分功能要放到说明时候做，什么周期做说明白和交到出来，导致产品开发就针对现在的需求做架构，以后再提出以前规划的功能做研发时，又需要大改大动，产品与研发和需求冲突逐渐就会越积累越多。
这其实也要求产品研发不但要把产品需求砍掉，还需要明确以后还要不要做，如果要做我们架构怎么设计，如果不再做了我们如何架构设计。
这样项目式的产品研发会越来越多的让项目开发疲于应对客户需求，而无法让产品功能引领客户的需求走。
再做产品和项目的时候，应该是将产品的功能规划和现阶段可以预测到的功能做好路线图，至少要在基础功能支持上把产品的整体路线图定好，路线图可以按照实际的情况进行调整，有路线图的指引可以保证研发计划一直在主要路线上行进，也能让产品、客户、研发、其他需求方能有明确的功能预期，哪些是在路线规划上的功能，哪些是在开发中的，哪些需求还没有列入我们的功能规划的，都能一目了然。
通过路线图，也可以用到自己的规划中，我们的中长期目标是什么。近期目标是什么，都是列入到路线图中的。
只有通过一次次总结和实践，不断的修正路线图，审视当前所做的事情有没偏离路线，如果路线有偏离要不要修正当前的执行，还是修正路线图。根据产品需求和发展的变化形式来合理规划和利用目标看板，让自己的产品目标实现，让逐步完善的功能来带动产品的客户增加和服务能力提升。
产品学习和项目管理的内容很多，但用到了实际项目上，还需要考虑实用性，不断学习和挫折中成长的过程有些慢，有时候还是要多学学别人的方法论，要不然自己闷头做个很多年才能学到别人早就总结的敏捷开发里的经验和模式。