“敏捷开发的四个价值观应该是沟通、简单、反馈、勇气。现在沟通成本倒是越来越高，而简单和勇气又去了哪里了呢？做互联网不应该怕犯错，怕的是不够及时高效。”
不够及时高效的根本原因是不合理、考虑不成熟、不系统的产品需求太多，而需求的描述又含混不清。不合格的需求文档，造成大量误解和沟通成本。
新业务要尝试要试错这个没错。但是基本功课没做，没有用研和数据支持，不考虑业务逻辑自洽，拍脑袋式的模仿式的枝节需求就会导致用户和研发的双重迷惑。高效的前提是专注。
需求方总是在埋怨为什么做得这么慢，为什么出现偏差，为什么总砍掉很必要的需求，为什么上线后出了这样那样的问题。其实这恰恰是对敏捷理解不够导致的。敏捷的核心是需求方和实现方的充分交流，之所以鄙视文档是因为文档往往是一方闭门造车让另一方接受的结果，充满了大量另一方难以认同的假设和臆想。
需求方不能自恋地认为白板流就是敏捷，转而埋怨实现方的效率低下。实现方需要流程和时间在这个现实的世界中把东西做出来，把质量做到位。之所以罗马不是一天建成，是因为它凝聚无数码农的血汗。常常见到始乱终弃的需求，经不起挑战和细化，美好的蓝图只做出一个鸡肋。
需求方常常在交互上可以精确到一个像素，在业务流程上却粗枝大叶，经不起推敲，场景用例覆盖不全，优先级不清。这是不可取的。到了项目后期，逐渐成型和确定的需求没有沉淀为文档，口头沟通确定的事情，后面却被需求方遗忘否定。目前需求和研发的敏捷，使得很多时候到了测试组编写用例的时候，才把需求积淀为文档，在这方面，测试组替需求方做出了杰出的贡献。
时至今日，我已经常常做需求方，常常发现，自己在提需求时，缺少多少功课造成项目资源的浪费，造成团队走了弯路。在我看来，需求是一个很重要的环节，所有的反思，都要从需求这个根源开始。因为需求方的需求质量，决定着整个团队是否白费，最终的产品能否为用户创造价值。
实现方应该理解需求方完善一个需求需要试错和实践检验的过程，需求方也应当充分考虑到实现方的所需要做的工作。敏捷的核心在于需求方和实现方的充分交流，而且在交流中，各自坚持各自的立场，把自己的工作做到位。需求方和实现方不是理想和现实的对立，而是理想的实现路途，你中有我，我中有你。