巴比伦塔的管理教训
巴比伦塔是人类继诺亚方舟之后的第二大工程壮举，但巴比伦塔同时也是第一个彻底失败的工程。
现在，其实也是这样的情况。因为左手不知道右手在做什么，所以进度灾难、功能的
不合理和系统缺陷纷纷出现。随着工作的进行，许多小组慢慢地修改自己程序的功能、规模
和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定。
确实有啊，最明显的感觉就是和别人合成各自做的功能模块的时候，会出现这样那儿样的各种各样的问题
命名规则就不说了，这本来各人就不一样，最难受的是版本，编程工具，gradle就不一样，简直
能让人一个脑袋两个大。
而造成这样问题的恰恰是前期沟通没有做好，或者说就没想到这样的问题，说到底还是第一次合作
做项目，没有经验，如果有下一次，这些问题一定会第一时间解决的
减少交流的方法是人力划分（di vi si on of l abor）和限定职责范围（speci al i zat i on
of f unct i on）。当使用人力划分和职责限定时，树状管理结构所映出对详细交流的需要会相
应减少。
事实上，树状组织架构是作为权力和责任的结构出现。其基本原理——管理角色的非
重复性——导致了管理结构是树状的。但是交流的结构并未限制得如此严格，树状结构几乎
不能用来描述交流沟通，因为交流是通过网状结构进行的。在很多工程活动领域，树状模拟
结构不能很精确地用于描述一般团队、特别工作组、委员会，甚至是矩阵结构组织。
人力的分配目前来看并没有太大问题，毕竟就4个人，但是这点确实是一个很重要的点
在以后的项目中好好分配吧