以前看《提问的智慧》，不长，一两千的字，把问题说得相当明白，又觉得其实3000字足够描述任何一个问题，哪来那么多的长篇论文啊，完全在瞎BB。
最近在看老大写的一个项目的时候，才知道，事情其实很简单，如果做复杂了，那是需求在捣蛋，砍死产品经理，呜呜呜。
具体的项目不好说，做个类比吧。
现在想了解一个小区内的情况，很简单，直接进去调查呗。偏偏这个小区是军属区，一搬人进不去，so，我们得去派间谍混进去。事情到这里貌似解决了，不，还早。
我们需要了解小区的卫生、公共设备、居民友善度等很多情况，好吧，老老实实给每种任务编个号吧；
又来了新的需求，我们有时候想了解一二三栋楼的情况，有时候想了解一三五栋楼的情况，麻痹，劳资给你建个分组，成了吧。
产品说以后可能会有新的任务种类，你提前给那些谍子说说，给他们培训培训，行，不就是不写死么，咱从配置文件里读不行么。
到这里需求已经完事了，可是，你忘了，谍子精力有限啊，一个谍子撑死只能打听到他附近的两栋楼的消息。很多时候你需要尽快地获取消息，怎么办，多放几个谍子呗。唉，有多了个任务，管理这些谍子，还多了个任务，怎么给这些谍子合理地分配任务。
当你绞尽脑汁写出还算合理的算法来让每个谍子高效的配合工作时，问题又来了，你怎么和谍子沟通呢？
好吧，你们得约定时间，约定地点，谍子固定的从你这里获取任务，完了，这又是一个单独的线程。谍子从你这边获取到的肯定不能是搜集一二三号楼卫生这么直白语句，可能只是一块颜色比较怪异的石头，你们双方得有一套暗号。。。这个好办，百度一下你就知道。
看，原本很简单的任务，因为各种需求和条件的限制，让问题变得复杂。这个例子里涉及到的技术其实都能比较容易地找到，你需要的只是合理地运用这些技术，让程序能够高效地跑起来，并且少出错。
为什么世界辣么复杂，因为坑爹的需求
