项目感想: 为什么巴比伦塔会失败？

有一天随手拿起床头的＜人月神话＞翻看到‘为什么巴比仑塔会失败？’这一章，关联到我现在在做的项目，觉得有非常多的不足。

 

在拥有清晰的目标、足够的资源下，项目失败了。这就是我们看到的‘巴比仑塔’项目结果。原因很简单，引用一下原文：

'为什么项目还会失败呢？他们还缺乏些什么？两个方面——交流，以及交流的结果——组织。‘

 

嗯，‘交流’，每个人都认同这一点非常的重要。

但是，怎么交流才算是交流，或是‘有效的’交流呢？再引用一下原文

1. 非正式途径

清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而达到对所书写文档的共同理解。

2. 会议

常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用，能澄清成百上千的细小误解。

3. 工作手册。

在项目的开始阶段，应该准备正式的项目工作手册。理所应当，我们专门用一节来讨论它。

 

 

对应到目前的项目：

正式/非正式的交流：非常缺乏。连基本的周例会也在进行了几次后取消（即上面所说的第二点‘会议’）。同时，应为项目需要与海外团队的合作，本身有交流上不便，更加上有些事宜没有EPL来确定（拍板），甚至出现了到现在（已经是release阶段）还有各做各的情况（当然，这一般情况下是沟通问题。anyway,在接下来的一段时间，某一方必定需要重写对应的逻辑功能来符合另一方才能使流程运转起来）。

 

关于工作手册：在项目一开始就明确了一点：因为项目紧，所以，一切文档从简或略。

 

软件项目不同于建筑项目，一旦图纸确定下来，找来建筑工人即可以顺利完工，只要不出现‘压力太大’的问题，呵呵。但是，软件项目，特别是没有类似软件的开发经验的项目，希望按照schedule来完成任务，就特别需要团队的合作。从可行性分析、软件架构、模块划分、模块接口定义等等，都需要充分的交流（这个与‘人月’中的另一章‘贵族专制、民主政治和系统设计’是不冲突的），尽量的减少开发过程中某部分人员的‘不爽’的问题。比如：某些模块负担过分的重，有些则过轻;架构设计时，轻视的某一部分，导致此模块开发起来感觉极不‘优雅’等。个人认为，这个问题的解决能力，很大程度上就体现了EPL的管理能力了