摘要：
在项目执行中，团队里面必须有一个知道不断向项目里面累加代码的“摄像头”，扫到项目每个角落，看看加进去，项目
会不会“营养不良”？项目会不会“突然休眠”？你们团队有这样的人吗？我要当这样的角色：哪怕我一行代码也不写，我也要
分析透添加这个字段对我们这个系统整体的影响。
今天突然想起这件事情，几年前自己在跟同事聊一个做的不太好的项目（就是自己认为有可能交付不了的项目）。
我记得食堂在地下一层吧，在楼道里面我清清楚楚的记得那句话“我们项目缺一个整体把控的人”，所谓的整体
把控其实是在说一个能把项目支撑起来的人。
这个人具备的能力是这样的：
1.需求的过滤，需求意义上的过率
2.了解整个系统的业务，并且当遇到团队里面做的不对事情，可以马上解决，尤其是发现需求不明确
3.要有分析需求的能力，尤其是拒绝需求能力
4.因为项目进行到一半，所以数据结构，通俗一点就是数据库添加一个字段，其他地方的影响是怎么样的，不加可以吗
尤其是增加，修改数据库字段，影响的所有点，这个如果不改，是数据上的错误，很难找到
我真的很奇怪，为什么明明知道需要这样的人，而没人喜欢去做？
你去做的话，你就左右这个项目的生命周期，这比写代码更有意义 。
场景1：
上上周吧，去朋友家串门，他告诉我他项目组8个需求（反正很多的意思），他还把他们的需求文档拿给我看，我那朋友也是
程序员（一个胖程序员，很喜欢写代码的那种，经常研究怎么把50行代码变成10行代码的那种）。
“你能看懂吗？一个月能搞定吗？”我笑而不语。然后又从电脑翻出个文档, 这个他之前在的联想的文档，
这个文档我一个月能搞定。
我仔细看了了2个文档区别：
1.一个月能搞定的有张顺序图，数据流的流向很明确，并且图上有表示了每个步骤的标识，在下面有很详细的介绍，虽然页面表
示是简陋，但是开发足矣
2.现在在用的文档描述很简单，直白，可是说是刚采集过来的需求，需要再挖掘（说是刚采集的需求，都感觉有点那个，需求至少
有为什么，为什么，甚至不明白的地方标识呀）
我说“你们8个需求你们怎么玩呀？”
“我只听项目经理的”
”交付呢？“
“项目经理负责”
。。。。。。。。。。
“以后还是架构师？”
“有些东西不是架构师可以解决的，有些东西不是代码能解决的，就像鲁迅，学医救国是不行的。。。。。。。。”
总结：多个需求只会让项目越玩越烂，不管你多个需求人员，肯定有个总负责的人，他是整合，梳理需求的人员，并且是把转化为
功能的人，遇到这种情况，只能先把需求的组织结构好好梳理吧
突然想到之前一个哥们说“需求最多只能要一个，多了，不知道听谁的了”。 我只想对自己说：哪怕我一行代码也不写，
我也要分析透添加这个字段对我们这个系统整体的影响。