也许是中国人本身喜欢做远景规划，亦或者是技术背景出身的人还保留着对不确定需求的反感，也有可能是个人太较真，我喜欢在产品的规划阶段就刨根问底。
我通常会不断询问业务部门，产品的定位是啥、关键需求点是啥、目标用户是谁、需求是否可复用、这个市场具体有多大、后续可能增加的功能是啥；然后要求产品团队根据获取到的信息或市场预判，给出明确的RoadMap、每个版本主要的功能点、后续可能的迭代方向，同时还要明确每个版本需要多少个迭代周期才能完成，以保证不错失市场机会；最后还会去跟研发团队强调，预留后续可能的接口，防止在市场快速变化的过程中，由于时间紧迫而积累过多的技术债。
在这一切做完之后，我觉得无比的安心，之后实时获取进度，调节实施过程中可能存在的冲突和问题，心里想着这个产品美好的未来。
可是，在我觉得一切皆在掌握时，事情却往往向着失控的方向发展，这使我感到焦躁。
“变化”措手不及
在产品研发的过程中，时常是伴着市场信息的更新。
由于在规划阶段，为了“方便”产品规划，从业务团队要取了过多的信息。这种过多的信息，通常伴随着一个问题，信息的背后，客观现实的占比较低，判断和猜测所占的比例过高，因此这些过多的信息难免会在随后的一段时间得到确认。这种信息不断确认 的过程，对于产品研发部门，就是不断的需求变更。
也许有人会觉得，使用敏捷开发模式，就可以解决这个问题，接受变化，拥抱变化。但是在敏捷开发中，不会对未知信息付出过多工作量，而对于过多的信息和不确定的信息，若没有做好标注，就会导致资源浪费。
举个例子简单说明，在产品规划阶段，业务部门“看好”付费技能模块，可是在与客户对接过程中，却面临着没有客户愿意对此买单的情况。虽然该需求属于后续版本的需求，但是由于过度规划，整个团队在这个模块上已经付出了一定的工作量。虽然整个团队明白这个模块不属于当前迭代周期的任务，但是由于信息“变更”，产品团队在做本阶段的需求文档时已考虑了该模块的嵌入，还有可能开发团队在账号管理的开发中也埋下了付费相关接口，对此也付出了时间和精力。
这个时候，整个团队的戾气都集中在为何业务团队提供错误的市场信息，更甚者会直接质疑业务团队的能力。
尝试与翻工无法分辨
由于产品的过分规划经常伴随着判断和猜测，这种臆想假装成信息的样子成为产品规划的依据，可是终究经不住时间的考验。
在做产品规划的时候，最好是基于事实的，在通过经济学的思维来判断需求是否应该被采纳。可是往往由于市场竞争，尤其是在饱和市场中，我们往往不是将手机卖给用BP机的用户，而是需要让已经有手机的用户愿意花钱换一个手机，因此产品的规划中往往存在尝试。
但是尝试如果信息沟通存在分歧，即业务部门认为是商业尝试，而研发部门认为是明确的需求，就有可能出现在执行过程中付出比起业务部门想象中更重的成本去完成该需求的问题。对“已知的信息”不断调整，研发团队需要不断的翻工来满足臆想带来的后果。
挫败感无处不在
还有一个潜在的问题，也许不会暴露在表面，但是可能带来的影响更加巨大，就是整个团队在产品的推进过程中一直需要不断的面对并处理挫败感。
在规划阶段，业务团队为了提供长远的“信息”，绞尽脑汁；产品团队利用有限的信息进行无限的意淫。当最终的规划出来的时刻，所有参与人员感受到的不是成就感，而是解放。
在执行交付阶段，业务团队由于产品迟迟无法按时交付，身心俱疲的维护着客户关系，从跟客户讲道理到编各种假话来敷衍客户，看着研发成本的不断上涨，对订单的期待逐渐降低，最后只想尽快结束；研发团队面临着不断变化的需求，对新产品上线的激情不断消磨，由于时间越来越紧迫，原先自己规划的框架上打满了补丁，技术债不断积累，还需要额外找时间进行重构工作，客户验收遥遥无期，从主动变被动，变成了拨一下动一下的棋子。
团队也许变得互不信任，业务部门觉得研发部门没有提供足够的支持帮助自己拿下订单；研发部门也同样觉得产品需求一直变更，产品定位规划不断调整。如果不尽快调整，可能会导致优秀的人选择离开，对团队和整个公司带来不可挽回的损失。
总结
规划在某种意义上一直是一个褒义词，但凡事必有度。有时候将所有真实的信息进行汇总，并以沟通对象可理解的方式进行陈述，往往比有一个“明确”的规划，可下达进行执行，可上达进行汇报，要更加聪明。
当要求业务部门不断提供未来信息的那一刻，我就已经错了，业务团队可以对当前市场形势做分析，表达自己的看法，但是若要将这些看法立刻变为信息，是不现实的。若要业务团队为了自己的看法买单，会更加不现实，这么做，业务团队就会尽量在公司少说话，因为避免自己的看法给公司带来损失。一旦业务团队选择了“闭嘴”，公司就断开了与市场的信息渠道，一个与市场割裂的产品研发部门，最终将沦为外包，只能为已经明确的订单提供明确的服务，赚取低廉的毛利。
虽然我的做法没有太“过分”，造成的影响还属于“可接受”，但是依旧记录下来，引导自己变得更好。