困扰我的问题
我相信大多数程序员都遇到过这种经历，比如我们需要做某个项目，产品经理在需求讨论会议上对这个项目的需求做了介绍，然后我们也都知道了要做什么。但是在实际的开发过程中，总是会遇到各种各样的问题。
比如：开发到一半的时候，突然发现这里的业务逻辑根本就不是那么回事儿，或者说某个功能做了一半，突然发现这个功能需要另外一个功能才能实现。
最近一段时间，我一直在思考这个问题，为什么我们开发过程中总是会遇到各种坎儿呢?每次一遇到问题，大家就又重新聚集到一起，重新讨论技术方案，从新梳理业务流程，那我们之前的需求讨论会还有什么意义呢?
难道就是为了告诉大家：大家都听好了啊，接下来我们要做这个事儿了啊。
当然没有这么简单。
出现坎儿的原因
有过一段这样的经历。一个需求的评审需要经过至少三轮评审：需求评审，技术评审，UI评审。这个三次评审有一个前提是：UI稿已经完成，并且标注了业务流程。
第一轮的需求评审，大家讲一下大致的需求，讨论哪里有不合适的地方，然后指出来改正。
第二轮的技术评审，主要是研发同学发言，讨论以哪种技术方案实现，是否有实现不了的功能，如何修正。
第三轮的UI评审，其实是对前两次的总结，综合考虑业务逻辑和技术方案，同时对UI中的文案进行定论。
在上面的这些个经历中，我的角色只是一个写业务代码的研发，并不参与讨论，业务流程，技术方案，UI设计稿，都是有他们定好以后，主要的业务负责人交给我，然后我只负责实现。
这段经历中，似乎也没有遇到过卡壳的地方，从提出需求到研发落地一切看起来都很顺畅。
但是最近的工作中，没有了上面的标准流程。虽然也有需求评审的会议，也有技术评审的会议，而且每次都参加了，似乎也都知道具体要做什么东西，但是总是会遇到各种各样的问题。
比如：从PC端分享出来的链接在客户端无法打开，查了半天才知道需要重新写一个接口才能实现这个功能。从A应用里跳到B应用没办法返回A应用，需要B应用进行支持才行。
于是又得和服务端沟通，又去找负责B应用开发的同学进行支持。
为什么我也参加了需求评审，我也参加了技术评审，但是开发中还是会出现各种各样的问题呢？
我想原因很简单，因为我根本没有理解真正的需求，不知道我们要做的到底是什么东西，或者我们具体在做什么产品。
我只是参加了会议，听了听产品经理说有这么个事情要做，但是对我们要做的产品并没有去进行思考，业务流程是什么，业务流程为什么要这么走，业务流程这么走有什么好处，业务流程这么走是不是不太合适，技术上有什么难点，是否需要其他应用的研发同学进行支持？
没有这些思考，说白了，对于我们接下来要做的事情是什么，怎么做，为什么要做，我都一无所知。所以，在开发过程中，总是会出现各种各样的问题，一次又一次，周而复始。
解决方法
提升眼光，不在局限于某些功能的实现，而是把眼光放到全局，综合考虑产品的层面。这其实是一种思维的转变。
我今天看到这样一句话：
做产品，绕不开「需求」二字。很多产品从0到1需要团队付出很多努力，但如果在把握用户需求的时候出了错误，再好的团队、再牛的执行力、再牛逼的技术也阻止不了项目的失败，所以，分辨用户需求就成了产品的关键。
在以往的开发中，我们往往只注重某些模块儿，某些功能的实现。对于这些功能某块儿服务哪些用户，是否对用户真的能起到作用并不关注。
我想在以后的工作中，我也许会更加的关注需求本身，而不是只关注功能的实现。积极的去思考每一个需求，它到底是真需求、伪需求或许这其中还有别的隐藏的需求?
这是我接下来要去思考的另外一个问题。
