人月神话札记之巴比伦塔失败

前言:在最初的世界,人们只有一种语言,所以大家沟通好说去建立一个通天塔,可以通往天堂的巴比伦塔,然而上帝出现了,他交给人们不同的语言,让大伙最终无法进行交流,最终队伍遣散,巴比伦塔就此失败,那么本章作者想要告诉我们的就是“沟通”对于成功的项目很重要。

编程项目中的交流

书中主要针对的是大型项目的交流,然而同样适合我当前所处的团队:

  1. 非正式交流:以前在日企和日方沟通主要是电话会议,那么小型团队的非正式交流就是协作的人员互相凑一起说话就可以了。
  2. 会议:站立会,分析讨论会,项目评估会等任何有形式的会议。
  3. 工作手册:这个目前在我们团队不太可能做的很好。

编程项目的组织架构

树状结构是作为权利和责任的结构出现,那么就是所谓的分层责任制,部门经理下分项目经理,项目经理管理不同的功能模块,这样一层层的。

  1. 产品负责人:组件团队,划分工作及制定进度表。与团队外部进行向上的沟通和水平的沟通,建立团队内部的沟通和报告方式,从而确保进度目标的实现。
  2. 技术主管:指明系统的外部样子,勾画内部结构。当遇到技术难题时,提供技术解决方案。

那么以上两个角色作为组织架构中最重要的部分,该怎么存在呢?

  1. 两个角色为同一个人,队伍为3~6人,显然就是说我的团队,目前3个人,我的理想是5个人。我在这个结构中,感觉穿梭于技术和管理的角色中,有时感觉很累,有时感觉很有存在感,呵呵。
  2. 产品负责人为总指挥,技术主管为左右手。书中说这种组合很少应用,因为技术主管在不负责管理工作时,很难有权威,这就会减弱他在团队中的贡献。
  3. 技术主管为总指挥,产品负责人为左右手。让技术主管潜心解决技术问题,而负责人去打理其他事宜。

总结:建立一套合理的组织,让大家交流的更加顺畅,是保证一个项目成功的关键。

时间: 2024-10-14 23:41:27

人月神话札记之巴比伦塔失败的相关文章

人月神话札记之人月神话

前言:美食的烹饪需要时间,那么稍等片刻,你将享用更多的美味.缺乏合理的进度安排是造成项目滞后的重要原因,因素有以下内容: - 对估算技术缺乏有效的研究 - 进度和工作量混淆,就是说人员和时间可以转换 - 对自己的估算缺乏信心 - 缺乏信心 - 对进度缺少跟踪和监督,所以站立会和燃尽图至关重要 - 意识到进度偏移时,第一个反应是增加人力,而这时大多数情况如同火上浇油,火越来越大,需要的汽油却越来越多 乐观主义 书中说,编程人员都是乐观主义者,我想,在国内,需求者比编程人员更"乐观",他们

人月神话札记:未雨绸缪

前言:软件在设计阶段如果能够多考虑一些后续的维护工作,显然是非常棒的.然而对于现阶段的我,或者很多程序员来说,未雨绸缪有很大难度,我们往往即使已经下雨了,也依然无法把窗户关紧,那么如果你想得到一些指导的话,请随我来,看看我能否品出一些味道来. 没有什么是永恒的,除了变化. 普遍的做法是,选择一个方案,试试看:如果失败了,没关系,再试试别的.不管怎么样,重要的是去尝试. 我觉得书中提供的这两个观点非常的棒,首先,任何事都不可能一成不变,敏捷宣言也提倡我们要拥抱变化.其次,在解决问题的时候,就是要不

人月神话札记之专制、民主和系统设计

前言:大教堂的整体设计在基本元素构成上都是一致的.有的教堂偏重于设计师的个人创意,有的教堂舍取设计师的创意而保证设计的纯粹性,在书中提出的观点中,对于计算机系统来说,保持概念的一致性是至关重要的,省略不规则的特性和改进,而反映一系列连贯的设计思路. 获得概念的完整性 一个产品如果其花费在学习使用的时间价值超出了其带给人们的使用价值时,就会难以普及和推广,我觉得产品的易用性是特别重要的.就比如说CSDN推出的Markdown和xheditor相比较,我觉得Markdown并没有征服我,主要是其用起

人月神话札记之外科手术队伍

前言:研究表明,效率高和效率低的实施者之间个体差异非常大,能够达到数量级的水平.类似我这样年龄段的产品经理来说,我认为我只需要有5个精干的成员组成团队,然而我这样的想法就面对着一个很难回避的问题-这样的小型团队很难在有计划的进度安排时间内创造大型的系统! 问题 大家知道,优秀的程序员和较差的程序员的效率存在巨大差异,书中也指出来最好和最差的效率上平均为10:1,编程速度和空间上具有5:1的惊人差异. 需要协作沟通的人员数量影响开发成本,这就意味着人员数量少的情况下,沟通就会减少.然而这不适合于大

人月神话札记:提纲挈领

前言:所谓提纲挈领,从字面上讲就是抓住渔网的总绳,提起衣服的领子,其含义(度娘说要用含义而不推荐用涵义)就是告诉我们做事情要能够抓住要领.那么本篇告诉我们什么是要领呢,就是书面文档,从一开始就要意识到其重要性,那么就不会对文档产生厌烦.因为作为技术人员来说,包括我,普遍对文档没有好感,尤其是看完了长篇大论后,发现无非就是要表达一两句话,那时候,就会气急败坏. 计算机产品的文档 对于该小节,我读了三遍,发现并没有很好的理解,所谓预测->报价->价格之间相互制约的关系,没有弄出来个所以然.希望在以

人月神话札记:干将莫邪

前言:A good workman is known by his tools.外国谚语如此,我们也有这样的古话,"工欲善其事,必先利其器".好的开发团队自然有自己一套比较完好的工具,用来提高生产力以及生产效率. 在学习编程的某一段岁月,我喜欢尝试用各种Java的开发工具,editplus.eclipse.jcreator.myeclipse.netbeans等等,最后,我决定使用eclipse.这一段探索的岁月,也证明了brooks的观点,在工作环境中,如果开发人员的工具不够统一的话

读<<人月神话>>

这本书在软件领域知名度很高,每次看到年度推荐的文章里面都有这本书且强烈推荐.出版30年了,可谓经典. 但我在读的过程中并没有那么深的体会.书中很多章节都是基于大型项目或者大型系统的经验总结,至今为止我还没有参与大于30人的项目.只能说自己的境界还不够. 第一章,焦油坑 再也找不到一个词比焦油坑更能形容,软件开发的过程了.我们都在挣扎.计划,计划,不断计划,但还是拖延,拖延,拖延.... 职业的乐趣: 创造性,贡献助人为乐,过程的魅力或者解决问题的成就感或写代码的快感,持续学习新事物,驾驭感. 职

《人月神话》阅读笔记02

今天我读了人月神话—外科手术队伍和巴比伦塔的失败.有许多体会. 在开发小组中,最好和最查人员生产率比在10:1,在运行效率和空间上5:1惊人差距.如果一个200人的项目中,有25个最能干和最有开发经验的项目经理,那么开除剩下的175名程序员,让项目经理来编程开发. 对于一个软件项目,适合的项目团队规模在20人左右,这是一个专职的IT项目经理可以管理的最大值.那由于项目进度压力需要增加团队规模到100人的时候,让项目经理来开发实际操作是很困难的方式,在这里推荐的方式是将系统按照高内聚,松耦合分解为

《人月神话》阅读笔记--02

在<人月神话>中提到,如果缺乏良好有效的沟通和协作,团队成员间难以更好的配合,团队项目也就不能很好的实现.一个大的项目并不是能靠 一个人完成的,只有良好的团队配合,才是能够成功的关键.在软件工程这门课上,到目前为止我们已经进行了团队的项目开发已经完成,下一步将进行软件的测试和发布.我们的团队有四个人,每个人都有自己特点和自己特有的角色,并有明确的分工,应该算得上是大型软件项目合作团队的雏形.这次也算是第一次正式的进行软件开发,虽然过程并不是一帆风顺,但是对于大概基本过程进行了基本的了解.巴比伦