阅人月神话有感——巴比伦塔的失败

人月神话读书心得

——为什么巴比伦塔会失败

 

12330230

 

         在整本书中，让我印象最深刻的是巴比伦塔失败的那一章。

       为什么要选择这一章呢。原因其实很简单，巴比伦塔看似有很多完美的先决条件，然而最后却失败了，这确实值得我们深思。

       巴比伦塔失败的原因在于两个方面——交流，以及交流的结果——组织。他们无法相互交谈， 从而无法合作。 当合作无法进行时， 工作陷入了停顿。

         在文中，团队通过如下的解决方案进行相互之间的交流沟通

l  非正式途径

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

l  会议

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

l  工作手册

在项目的开始阶段，应该准备正式的项目工作手册。

 

       从现在的互联网行业看来，作者在当时提出的这些解决方案在现在也是有用的。不过当下的软件行业与几十年前已经全然不同了。几十年前可能电脑的内存有2M就已经很了不起了，而现在随随便便一个小软件大小都会超过2M。现在的软件的特点是大（动不动就是几百MB）和快（运行速度要求要快）。而要做出这种大型软件，对与团队的挑战也远非几十年前能够想比的。也就是说现在的团队面临着更大的挑战。

       几十年前一个团队中可能全部都是程序员，但是放在现在肯定行不通了。现在的软件行业一个团队中分工很明确，有项目经理、产品经理、架构师、web前端工程师、后台工程师、ios工程师、安卓工程师、数据分析师、交互设计师、美术设计师、数据挖掘工程师、运维工程师、测试工程师、营销推广人员等等。每个人各司其职，负责自己的那个部分。一个大型的软件一般是把它模块化，各个部门约定好接口API和数据传输格式等等。然后每个人把分配给自己的那个模块给做好，并设计好API以供其他部门使用。这样就降低了沟通的成本，出了问题也能够很快的知道是哪个部门的bug。

       当然，会议也是必不可少的。就我所知，阿里巴巴的某部门每周都会有个分享会，部门老大和“新生”们做一块讨论技术，老大分享自己在行业接触到的一些前沿技术，并讨论移植到新项目中的可行性。大家也会讨论在团队开发中出现的问题，并提出解决方案。同时，员工之间互相也有交流。

      

       我自己也参与过不少的项目。令我印象最深的也就是IGEM比赛的那个项目，团队很大并且分工明确，有数学模型组、前端组、后端组、美工组、生物组等等。我当时是负责WIKI的建设，属于前端组。在提交截至的Deadline前期，我们团队的核心成员就一块到微软的实验室进行集中开发。真心觉得讨论交流挺重要的。我做的那个网站前前后后一共重构了4、5次，需求时刻都在变，因为谁也不知道能“最好”的极限是如何的，我们会跟其他的软件队伍去比较，然后发现自己的主页不够新颖，设计不够用户友好。大家会一起讨论，提出自己的解决方案，然后投票选取最合适的方案。虽说重构的过程代码量确实压力山大，不过所有的付出都是有回报的。最后我们团队赴美参赛，获得了国际基因工程大赛的金奖和最佳软件奖，这也算是对我们团队的一种肯定吧。

       总的来说，沟通交流是一个团队持续发展必不可少的，不论是软件行业还是其他行业，放之四海而皆准。