人月神话札记:提纲挈领

前言:所谓提纲挈领,从字面上讲就是抓住渔网的总绳,提起衣服的领子,其含义(度娘说要用含义而不推荐用涵义)就是告诉我们做事情要能够抓住要领。那么本篇告诉我们什么是要领呢,就是书面文档,从一开始就要意识到其重要性,那么就不会对文档产生厌烦。因为作为技术人员来说,包括我,普遍对文档没有好感,尤其是看完了长篇大论后,发现无非就是要表达一两句话,那时候,就会气急败坏。

计算机产品的文档

对于该小节,我读了三遍,发现并没有很好的理解,所谓预测->报价->价格之间相互制约的关系,没有弄出来个所以然。希望在以后再次翻阅的时候能够有很好的理解。

但是有一点,我觉得是个真理,那就是预算是一种制约,会促使产生更好的技术方案,因为如果在预算不能满足当前项目所需的话,我们就会被迫去做出改变,去探索出更具有性价比的产品解决方案,这促使了整个社会的发展。

大学科系的文档

任何管理任务的关注焦点都是时间、地点、人员、项目内容和资金。

Brooks给出的这个观点,我想没什么可说的,当你搬家告诉别人的时候,短信的内容就会是“各位亲爱的伙伴们,我将于4月17日搬家至洛阳牡丹广场,届时欢迎大家光临做客,我们将在老洛阳开吃一顿”。

软件项目的文档

就目前的自己来说,在安排任务的时候,多数是通过口头传达,然后在禅道中加入任务和时间,用来管理进度。而当一个任务结束后,等我再次回头来进行总结的时候,发现我的记忆力不够清晰了,往往这个时候,我非常的怀念有一份文档能够以书面的形式存在。

还有很多很多时候,对于一个开展的迭代,或者说一个关键的任务,或者说一个证明给别人的数据,强有力的文档会让所有的事情变得清晰明朗。

为什么要有正式的文档

这个看似疑问句的标题,其实更像是一个反问句,其答案必须是斩钉截铁的,正式的文档是必须的。

最近在做华夏银行的三方存管平台对接工作,最开始,对这个对接的工作只有几个字的概念,就是“华夏银行对接”。如果华夏银行没有提供给我必要的技术、业务说明文档,我的印象恐怕只能滞留在这六个字上了,虽然拿到他们的文档后,阅读过几次后都感觉到无力,如今都2015年了,文档的做成时间竟然是2011年,我不相信这4年来,业务接口一点没变,凭我的直觉,后来又要到了两份2014年做成的文档。然而,我不应该吐槽这些文档,我知道,正是这些文档,促使我去思考,去讨论,去交流,去分析,去编码,现在我已经把接口的代码工作完成了,
接下来就是测试和上线。

那么这些文档的作用显然是价值连城的,无论它的质量是否满足我的预期。

项目经理的任务就是制定计划,并且实现计划。但是只有书面计划是精确和可以沟通的。通过遵循文档开展工作,项目经理能够更清晰和快速的设定自己的方向。

显然,一次次的任务终结,其最让我能够感到满足除了任务一次次终结,还有那被我折磨的文档。

时间: 2024-10-04 16:24:06

人月神话札记:提纲挈领的相关文章

人月神话札记之人月神话

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

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

前言:在最初的世界,人们只有一种语言,所以大家沟通好说去建立一个通天塔,可以通往天堂的巴比伦塔,然而上帝出现了,他交给人们不同的语言,让大伙最终无法进行交流,最终队伍遣散,巴比伦塔就此失败,那么本章作者想要告诉我们的就是"沟通"对于成功的项目很重要. 编程项目中的交流 书中主要针对的是大型项目的交流,然而同样适合我当前所处的团队: 非正式交流:以前在日企和日方沟通主要是电话会议,那么小型团队的非正式交流就是协作的人员互相凑一起说话就可以了. 会议:站立会,分析讨论会,项目评估会等任何有

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

前言:大教堂的整体设计在基本元素构成上都是一致的.有的教堂偏重于设计师的个人创意,有的教堂舍取设计师的创意而保证设计的纯粹性,在书中提出的观点中,对于计算机系统来说,保持概念的一致性是至关重要的,省略不规则的特性和改进,而反映一系列连贯的设计思路. 获得概念的完整性 一个产品如果其花费在学习使用的时间价值超出了其带给人们的使用价值时,就会难以普及和推广,我觉得产品的易用性是特别重要的.就比如说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的观点,在工作环境中,如果开发人员的工具不够统一的话

《人月神话》笔记

人月神话这个名字对我来说很有吸引力,我以为它会是一本讲述计算机历史神话的故事.当我看到第二章我才知道原来这个“人月“是我们项目工程中估计和进度安排中使用的工作量单位:人月.全书共分为以下几个部分: 焦油坑 人月神话 外科手术队伍 贵族专制.民主政治和系统设计 画蛇添足 贯彻执行 为什么巴比伦塔会失败? 胸有成竹 削足适履 提纲挈领 未雨绸缪 干将莫邪 祸起萧墙 另外一面 没有银弹 焦油坑依然存在 对于所有的程序员来讲,都有乐观主义,总是相信自己的代码是肯定能运行的.所以在安排项目的进度的时候就会

《人月神话》读书笔记之四

本周继续阅读<人月神话>,本周度过的部分是第十章和第十一章("提纲挈领"和"未雨绸缪"),以下是对该两章的感想. 一.提纲挈领 提纲挈领一章描述的是经理与文件的关系.作者一开始便给文件做了定性:文档的某些部分包含和表达了一些管理方面的工作,其准备工作是集中考虑并使各种讨论意见明朗化的时刻,其跟踪维护是项目监督和预警的机制. 作者通过"计算机产品的文档"."大学科系的文档"和"软件项目的文档",来

读&lt;&lt;人月神话&gt;&gt;

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