刚开始从事软件开发工作的时候，
我认为编程活动是一种对特定问题寻求解答的过程。
例如，如果我们计划在页面上实现一个列表，显示用户查询的数据，
那么，我们就得编写后端接口，查询数据库，返回当前所查询的数据，
最后在前端展示在列表中。
这会涉及到很多方面的知识，
例如，我们首先需要掌握前后端所用的编程语言，
了解如何使用它们进行数据库查询操作，
此外，我们还要知道前端如何向后端发起请求，
还有，拿到数据后如何在页面中进行展示，等等。
只要能实现这些功能，我们就完成了工作。
我一直以来就是这样认为的。
这会促使我自己努力的钻研技术，
由点及面，举一反三的掌握各种有用的技术细节，
从而在实现的过程中，游刃有余。
这当然不能说是一件坏事。
且不谈商业价值，(因为做的事情有没有价值，不同的判断标准会有所不同)
我们就只说谈论一个开发团队。
我认识到，只从事编码工作的人员，
并没有解决团队中所面临的关键问题。
识别瓶颈
和解决技术问题一样，在寻找解决方案之前，我们都习惯抬起头来先看看问题本身。
以团队为单位交付产品，
关于如何实现一个功能，这真的是团队所遇到的瓶颈问题吗？
是人们都束手无策，导致其他工作都无法进展的环节吗？
我想大多数团队并不是这样的吧。
除非一些科研机构，或者探索性的项目之外，
我们要实现的功能，大多数别人都已经做过了，只需要整合一下就行了。
因此，实现一个给定的功能，并不是团队所遇到的瓶颈问题。
那么团队的瓶颈到底是什么呢？
很可惜，我不能一言以蔽之，
但我想向大家展示一个软件行业的秘密。
那就是，和其他工作一样，
软件开发工作所处理的主要问题，仍然是与人相关的问题。
我们会考虑如何合作，如何分工，
也会考虑如何沟通，如何做计划，
每天工作的大部分时间，都不是在编码，而是在讨论和交流。
我们开发的软件，一般也是由人来使用它，
即使是提供程序接口，那也是由人来调用它。
我们必须告诉别人如何正确的使用它，还要了解用户的感受。
这一切都离不开人。
所以，与人相关的问题才是瓶颈问题。
信息流动
项目中涉及到的所有人员，他们肯定都不是独立的，
每个人至少在某个方面，会与其他人会产生关联。
人们会把自己知道的事情，传达给其他人，
像这种从已知到未知的知识传达过程，我们可以称之为“信息流动”。
信息流动不畅，是生产效率低下的主要原因之一。
因为在给定的问题上下文中，人们都有能力去解决它。
所以，关键就在于上下文是否清晰，是否准确。
我想我们都有过返工的经历，
我们可以迅速的完成一个功能，但是这一定不是该功能的最终版本，
经常性地改动待实现的功能本身，是一件很容易令人崩溃的事情。
正是因为这种原因，程序员们都厌恶需求变更。
但是从整个项目的角度来看，
需求其实并没有经历过多的变更，变更的只是每个人对需求的理解。
用户的需求就在那里，是我们没有做好沟通，
产品经理的认识就在那里，是大家没有进行更充分的交流。
这就是信息流动的一个例子。
此外，当出现了一个故障的时候，
我们会经常性的发现，故障的原因不是因为粗心大意造成的，
而是因为理解不一致，编写代码的程序员对真实的系统做了不正确的假设。
相信我，没有人会做那些明知道会出错的事情。
这是信息流动的另外一个例子。
总而言之，信息流动不畅造成了很多系统层面的问题。
为什么不知道
要解决信息流动不畅，最直接办法就是找出人们“为什么不知道”的原因，
然后想办法让必要的信息传递到他们那里。
寄希望于人们去主动询问，是不起作用的。
因为人们不知道他自己“不知道什么”。
如果是整个项目组，经常性的对需求理解产生变更，
那么就应该从增强信息流动的角度出发，促进更多的沟通，
而不是应该是从软件工程的角度，控制需求不让它变更。
采取的办法，可以是请产品经理多做一些宣讲，
将客户请到开发团队中，大声的说出自己的看法。
而寄希望于开发团队自己去询问用户，这从根本上就无法达成。
信息流动应该从掌握信息的一方，主动传递到没有掌握信息的一方，
而不是反之。
如果整个项目组的产品质量低下，且其主要原因不在于大家的态度上面，
那就应该请系统的设计者，或者架构师，多做一些分享。
如果大家对整个软件的全貌没有统一的认识，就会进行各式各样的假设，
直到出现故障的时候，才知道自己进行了错误的假设。
邀请掌握全貌的人员，帮大家进行梳理，是个好办法，
盲人摸象，很容易造成不一致的理解。
结语
促进信息流动是一件重要但是很难做好的事情，
团队中的每个成员，都应该有责任避免，让整个团队在信息缺失的情况下疲于奔命。
我甚至觉得，在技术实现不成问题的情况下，
整个团队本来就应该将最大化信息流动视为第一要务。
只有这样，团队才有战斗力，看起来像是凝聚成了一个人那样。
民齐者强。