军人月心得体会范文
推荐第1篇：人月神话读书笔记
人月神话这本书几年前就听别人说是本很经典的软件开发方面的书，这本书的成功之处在于他思想的前卫性，以至于不只是软件行业的人在读。现在终于找到读他的理由了，可以感受一下大师的杰作。在读之前我已经读过了软件工艺和极限编程，为什么留到最后读人月神话呢？主要是因为我觉得一本能够流传30年还被人们津津乐道的书，肯定是本学要好好细读的书，所以留到了最后。按照前两篇读书笔记的惯例，前面几段是一些我读书时的感受和收获，还有一些对内容的评价。
从这本书的内容来看，对于一个项目经理来说肯定会有更大的收获，这本书主要是针对软件开发管理方面的内容，这主要原因可能是因为作者以前就是项目的管理者，他是站在管理者的角度写的。即便这样，对于一个从来没有参与过真实项目开发，更没有领导过团队的我还是有一定的吸引力，这本书中我最喜欢的就是前四章（焦油坑、人月神话、外科手术队伍、贵族专制、民主政治和系统设计）和没有银弹这章。这本书里面为了论证某一观点，会举出许多实际的项目作为证据，这一点非常好，事实胜于雄辩嘛！这些例子也许对于作者那个年代的人来说很好理解，但是放在30年后来看这些例子又有些陈旧和难懂了。另外，从文中我发现作者非常注重文档，一个优质的文档就是项目成功的保证，这一点与传统的软件工程很相似，但是却与极限编程的观点相悖。下面就是一些读书的总结了。
焦油坑 1.编程系统产品开发的工作量是供个人使用的、独立开发的构件程序的九倍。
2.编程行业的一些内在固有苦恼：
l 将做事方式调整到追求完美，是学习编程的最困难部分。
l 由其他人来设定目标，并且必须依靠自己无法控制的事物。
l 真正的权威来自于每次任务的完成。
l 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外
l 人们通常期望项目在接近结束时（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢。
l 产品在即将完成时总面临着陈旧过时的威胁。 人月神话 1.缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。
2.良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。
3.我们的构思是有缺陷的，因此总会有bug。
4.我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。
5.在若干人员中分解任务会引发额外的沟通工作量--培训和相互沟通。
6.关于进度安排，作者的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。
7.因为我们对自己的估计技术不确定，所以在管理和客户的压力下，我们常常缺乏坚持的勇气。
8.brook法则：向进度落后的项目中增加人手，只会使进度更加落后。
9.向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。 外科手术队伍 1.同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是较差程序员的十倍。关于这一条我在极限编程里看到，sackman和humphrey分别做了实验发现优秀程序员工作效率比较差程序员的工作效率最高要高达28倍。
2.小型、精干队伍是最好的。这一点在软件工艺和极限编程里都得到了充分的体现。
3.两个人的团队，其中一个项目经理，常常是最佳的人员使用方法。
4.对于真正意义上的大型系统，小型精干的队伍太慢了。
5.实际上，绝大多数大型编程系统的经验显示出，一拥而上的开发方法是高成本、速度缓慢、不充分的，开发出的产品无法进行概念上的集成。
6.一位首席程序员、类似于外科手术队伍的团队架构提供了一种方法，既能获得由少数头脑产生的产品完整性，又能得到多位协助人员的总体生产率，还彻底地减少了沟通的工作量。图1是10人的程序开发队伍沟通模式。 图1 10人程序开发队伍沟通模式
贵族专制、民主政治和系统设计 1.概念完整性是系统设计中最重要的考虑因素。
2.为了获得概念完整性，设计必须由一个人或者具有共识的小型团队来完成。
3.对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。
4.纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。
5.体系结构、设计实现、物理实现的许多工作可以并发进行。画蛇添足 1.尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工。
2.结构师如何成功地影响实现：
i.牢记是开发人员承担创造性的实现责任；结构师只能提出建议。
ii.听取开发人员在体系结构上改进的建议。
3.第二个系统是人们所设计的最危险的系统，通常的倾向是过分地进行设计。关于这一点也许是正确的，但是这是一个回避不了的问题，如果没有开发第二个系统经验的人，就不可能有开发第三个系统经验的人了。 贯彻执行 1.即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。
2.必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。
3.出于精确性的考虑，我们需要形式化的设计定义，同样，我们需要记叙性定义来加深理解。
4.允许体系结构师对实现人员的询问做出电话应答解释是非常重要的，并且必须进行日志记录和整理发布。
5.项目经理最好的朋友就是他每天要面对的敌人--独立的产品测试机构/小组。为什么巴比伦塔会失败？ 1.巴比伦塔项目的失败是因为缺乏交流，以及交流的结果的组织。
2.因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。由于对其他人的各种假设，团队成员之间的理解开始出现偏差。
3.团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。胸有成竹 1.仅仅通过对编码部分的估计，然后乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的。
2.构建独立小型程序的数据不适用于编程系统项目。
3.程序开发与程序规模成指数增长趋势。
4.当使用适当的高级语言时，程序编制的生产率可以提高5倍。削足适履
这一章主要是要解决项目投资与磁盘空间和内存之间的矛盾，但是这个矛盾在电脑硬件发展到现在的层次已经可以忽略掉了。
提纲挈领 1.软件项目的要求：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。
2.即使是小型项目，项目经理也应该在项目早期规范化上述的一系列文档。这一章强调文档重要性，但并没有将一些教条主义的道理让你相信文档的重要性，而是给项目经理给出了实实在在的操作步骤。
未雨绸缪 1.对于大多数项目，第一个开发的系统并不合用。它可能太慢、太大，而且难以使用，或者三者兼而有之。系统的丢弃和重新设计可以一步完成，也可以一块块地实现。这是个必须完成的步骤，如果将开发的第一个系统丢弃原型发布给用户，可以获得时间，但是它的代价很高。对于用户，使用极度痛苦；对于重新开发的人员，分散了精力；对于产品，影响了声誉，即使最好的再设计也难以挽回名声。
2.用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。
3.软件产品易于掌握的特性和不可见性，导致了它的构建人员面临着永恒的需求变更。
4.目标和开发策略上的一些正常变化无可避免，事先为它们做准备总比假设它们不会出现要好得多。
5.对于一个广泛使用的程序，其维护总成本通常是开发成本的40％或更多。
6.维护成本受用户数目的严重影响。用户越多，所发现的错误也越多。
7.campbell指出了一个显示产品生命期中每月bug数的有趣曲线，它先是下降，然后攀升。
8.缺陷修复总会以（20－50）%的机率引入新的bug。
9.在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。
10.同样，设计实现的人员越少、接口越少，产生的错误也就越少。
11.所有修改都倾向于破坏系统的架构，增加了系统的混乱程度。即使是最熟练的软件维护工作，也只是放缓了系统退化到不可修复混乱的进程。 干将莫邪
项目经理应该制订一套策略，以及为通用工具的开发分配资源，与此同时，他还必须意识到专业工具的需求。
祸起萧墙 1.一天一天的进度落后比起重大灾难，更难以识别，更不容易防范和更加难以弥补。
2.根据一个严格的进度表来控制项目的第一个步骤是制订进度表，进度表由里程碑和日期组成。
3.里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。
4.如果里程碑定义得非常明确，以致于无法自欺欺人时，程序员很少会就里程碑的进展弄虚作假。另外一面 1.对于软件编程产品来说，程序向用户所呈现的面貌与提供给机器识别的内容同样重要。
2.即使对于完全开发给自己使用的程序，描述性文字也是必须的，因为它们会被用户和作者所遗忘。
3.文档能在整个软件开发的生命周期对程序员克服懒惰和进度的压力起促进激励作用，但向编程人员成功地灌输对待文档的积极态度是一件困难的事情。
4.为了使文档易于维护，将它们合并至源程序是至关重要的，而不是作为独立文档进行保存。没有银弹
人狼的传说可能有人听过也可能没听过，人狼是一种具有人和狼两种特征的恐怖生物，而银弹是消灭它的一种最有效的子弹，如果看过《吸血鬼传说》也许就能和容易的理解这一点。作者将软件开发比作人狼，而将提高软件开发效率的方法比作银弹。作者预言未来十年，想要试图通过寻找一种有效地银弹将软件开发效率提高一个甚至几个数量级，这种银弹不可能出现。
没有银弹这篇文章里作者列举出了当时一些非常先进的技术或思想理念，例如ada和其他高级编程语言、面向对象编程、人工智能、专家系统、\"自动\"编程、图形化编程、程序验证、环境和工具、工作站等。虽然这些先进技术在一定程度上提高了软件开发的效率，但是始终没有达到银弹的效果。距离作者的预言已经过去有20多年了，纵观现在的软件开发领域，虽然新技术层出不穷，但是还是没有一种银弹能够让软件开发产生一次革命。
焦油坑依然存在
软件工程的焦油坑在将来很长一段时间内会继续困扰着人们。由于软件系统多变性和错综复杂性，这个行业只能是一步一个台阶的往上爬，而出现银弹的希望在我们可以想象的时间范围内是非常渺茫的。我们将长期与焦油作斗争。
推荐第2篇：《人月神话》读后感
～-7-6 字数：407
1不同的社会经验，不同的思想状态，对读本书的心得也不一样，我在此说说我的读后感，书中有许多非常好的观点，但我只把我感触最深的写下来。这确实是一本很值得多次阅读的好书，每次阅读可能都能从中得到一些提示。
1.外科手术队伍TheSurgicalTeam
项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任。
2.贵族～，民主政治Aristocracy，Democracy，System
要获得概念的完整性，设计必须由一个人或具有共识的小组来完成。
有四个问题：
1。如何得到概念的完整性
2。是否要有一位杰出的精英，或者说是结构设计师的贵族～.....3.如何避免结构设计师产出无法实现或代价高昂的技术规格说明，使大家陷入困境。
4。如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计被正确地理解，并精确地整合到产品中。
对1。2。4的回答基本上都可以找到，但第3个似乎找不到。
3.画蛇添足TheSecond-SystemEffect
讲述的基本都是基于IBM360操作系统以及编译程序等方面的经验，讲述如何避免开发第二个系统的风险，作者认为开发第二个系统的设计师设计出来的系统是最危险的，因此要求他们自律。
4.贯彻执行paingtheword
印象比较深刻的是＂体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但他不应该支配具体的实现过程。＂
5.为什么巴比伦塔会失败WhydidtheTowerofBabelFail？
讲述巴比伦塔会失败的原因是缺乏交流。
6.胸有成竹CallingtheShot
主要讲述如何计算编程时间，以及提出几个人的经验算法。
讲述的各种算法可能都不太适合与现在的高级语言，但portman的观点仍然适合现在，即编程人员实际的编程时间只有50％，其他的时间都花在了无关的琐碎事情上。
7.削足适履TenpoundsinaFive-poundSack
主要讲述程序占用的空间等，在70年代比较突出，但现在好多了。
8.提纲擎领TheDocumentaryHypothesis
说明文档的作用
9.未雨绸缪plantoThrowOneAway
唯一不变的是变化本身。
在大型项目中，项目经理需要有两个和三个顶级程序员作为技术轻骑兵，当工作繁忙最密集的时候，他们能急驰飞奔，解决各种问题。讲述技术人员与项目人员的互换是，对我有一定的提示，但图中IBM的两条职位晋升线，不太理解。
10.干将莫邪SharpTools
主要讲述项目中管理好各种工具的重要性，项目经理首先要制定一种策略，让各种工具成为公用的工具，这样才能使开发、维护和使用这种工具的开发人员的效率更高，这种工具可能是开发人员开发出来的，也可能是使用现有的，可能是通用的，也可能是专用的或个人偏好的。比如：文档编写工具、开发工具（包括各种不同开发平台）、调试工具、测试工具、数据库工具、版本管理、项目管理工具等。
11.整体部分TheWholeandtheparts
一读这一章，就让我感触颇深，特别是这句话＂BELL实验室监控系统项目的V.A.Vyotsky提出，＇关键的工作是产品定义。许许多多的失败完全源于那些产品未精确定义的地方＇，细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的BUG数量＂。虽然这句话的意思只是说明精确定义产品将减少BUG的数量，但我看到了系统分析的最重要的工作——产品定义。现在，许多开发人员嘴里口口声声说也做过需求调研、系统分析、系统设计，但大多数没有涉及到产品定义的深度，严格意义上不能叫做系统分析。这句话对我的以后想从事系统分析工作有很大的帮助。
这一章余下的内容，也值得一看，虽然有些地方有些过时，但剔除BUG的设计以及部分测试/调试方法仍值得一看。
12.祸起萧墙HatchingaCatastrophe
这章节说明使项目进度拖后的最大原因不是重要的事件，如新技术、重组等，而是一些琐碎的小事，每件小事只耽误半天或一天时间，但这种小事多以后，将使项目的进度严重拖后。
项目对于公司就如程序对测试工程师一样，如果不了解它，它就是一个黑盒子，如果不打开这个黑盒子，你可能永远不知道盒子里面有什么。这部分描写项目经理以及小组主管的一些心理，值得一看。
13.另外一面Theotherface
本章说明程序的另一面——文档。
不了解，就无法真正拥有——歌德，作者引用的歌德的话来描述文档对客户的重要性，提出客户需要什么样的文档以及文档的格式和包含的内容，指出当时存在的大多数文档只描述了树木，形容了树叶，但没有整个森林的图案。
想想，这种情况在现在仍然没有改变。于是作者提出了两个观点：
&n
bsp;1.流程图：流程图是被吹捧得最过分的一种程序文档。许多程序甚至不需要流程图，很少程序需要一页以上的流程图
2.自文档化（self-documenting）的程序：提出文档与程序合为一体，能很好的解决文档与程序分开造成的文档过时的问题，并说明了在程序中加入文档的一些方法和技巧。2002年，我看到一位网友关于文档与程序合一的文章，当时就觉得是个好方法，没想到70年代，老美已经提出来了。
14.没有银弹-软件工程中的根本和次要问题(NoSilverBullet-EenceandAccidentinsoftwareEngineering)
这是一篇论文，发表于1986年，我自认为我的理论水平没有上升到可以对他的论点和论据做出怀疑或质疑的结论，我只是说说我的感想。
人狼是传说中的妖怪，只有银弹才能杀死他。作者认为软件项目具有人狼的特性，因为软件项目也可能变成一个怪物，一个落后进度、超出预算、存在大量缺陷的怪物。作者通过软件系统的内在特性复杂性、一致性、可变性和不可见性来分析说明了软件天生就没有银弹。
作者试图通过分析软件问题的本质和很多侯选银弹的特征来探究其中的原因。他行动的第一步是将大块的“巨无霸理论”替换成“微生物理论”。这个变化的过程告诉你，进步是逐步取得的，伴随着辛勤的劳动，对规范化过程应
进行持续不懈的努力，而这个努力的过程相应的就诞生了软件工程。作者对软件工程诞生的原因做出这样的解释，我觉得符合外国思维的特点，这正是国人所缺乏。记得有一位朋友说过，中国妈妈与德国妈妈的区别，他说，如果手里拿的针掉到地上了，中国妈妈的第一反应是估计针掉下去的范围，然后在这个范围里面找，可能很快就找到了，也可能一直都找不到；但德国妈妈不同，她会拿一根粉笔来，把整个屋子画成一个大圈，接着把大圈分成许许多多的小圈，然后再到每个小圈里找，虽然比较慢，但最终肯定可以找到。仔细想象，大多数情况下，中国妈妈都会找到得比较快，这确实符合大多数中国妈妈的思维习惯，每个中国妈妈都这样找，这好象是与生俱来的本事，但为什么德国妈妈没有这个本事呢？是德国妈妈笨吗？为什么中国妈妈也有找不到的情况？而德国妈妈，虽然速度慢了点，却始终能够找得到？如果把这件故事推而广之，多年以后，德国妈妈创建了找针工程，她通过多次找针的实验数据，分析出针掉到整个房间中各个小圈的概率，总结出针在哪个小圈的概率最大，很快就可以找到针，找针速度早已高过中国妈妈，而中国妈妈还在依循与生俱来的本事。你能说德国妈妈笨吗？为什么中国妈妈和德国妈妈会有这么大的区别？是德国妈妈把大块的“巨无霸理论”替换成“微生物理论”吗？我觉得是是，你说呢？作者在后面的论述中用数学和物理的发展为例子也说明了，这种思想的成立。
余下的作者把软件工程按“巨无霸理论”替换成“微生物理论”的过程详细的说明，值得看，我关注的不是具体的内容，具体内容可能有些不合适宜，我关注的是作者的思考方式以及处理方法，这是非常重要的。
在“以往解决次要困难的一些突破”和“银弹的希望”章节，从概念上讲述了软件的发展，其中讲到“专家系统”时，使我想起一部科幻电影，忘了电影名字了，有个情节大致是这样的，一位非常有经验的主管死后，有一名较优秀的下属接任，但这时出现了一位非常厉害的敌人，这位新主管无论如何也战胜不了敌人，这时想起了以前的主管，心想前主管一定有办法对付这个敌人，而前主管的大脑就存放在系统里，
推荐第3篇：《人月神话》读后感
～-6-23 字数：1345当我捧起《人月神话》，马上就被深深的吸引了。书中很多细微之处都对我的思维造成了冲击。上一本给我类似感觉的书是那本四人帮的《设计模式》，已经很久没有看到这么好的书了，郑重推荐。把感触比较深的几点记下来，顺便整理一下自己的思路，与大家分享。1，保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东东（模块，功能，算法），导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。我以前参加过一个15人左右的项目组，就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具体实践经验，希望以后能有机会参与比较大的项目。2，“一个拿2倍工资的人，生产率可能是其他人的10倍。”我和我的同学，一个小公司的技术总监聊起这个，他也是十分的认同。不知道其他公司的程序员们如何看。我的同事中有一个牛人，做出的贡献特别大，应该相当于我们公司普通的十个程序员，不过工资最多也就是普通程序员的二倍。是不是有些不公平呢？我也说不清楚。因为那些普通程序员也十分的努力。不过，我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。组建一个团队，最好的就是那种精英团队，大家都是牛人，效率会特别高。微软就是这种思路吧，把最聪明的人集中在一起，想不成功都难亚。3，进度落后与增加人力。记得当年看《C＋＋编程思想》，Bruce说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的：“向进度落后的项目中增加人手，只会使进度更加落后”。以前，增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话，难道只有“加班”一条路了？但长期加班是对个人的摧残，我更愿意利用业余时间去看书，例如看这本“人月神话”。：）如果不想加班，不想削减功能，不想推迟发布日期，那么。。。。。唯一的方法还是只有….加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有比较强大的设计者）。那么，就当作，新组建了一个团队吧。交流，培训新人，就设计达成一致，继续向者目标前进。感触还有很多，以后如果有机会再写。不过，我决定去买本英文版回来，收藏，以后再多看几次。
推荐第4篇：人月神话观后感
《人月神话》观后感
在软件领域，很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks博士为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。读完本书后， 感触颇深，书中通过介绍在软件项目开发过程中遇到的一系列问题，以及解决的方法，向IT从业者讲述软件开发过程中需要注意的问题，以下将按照本书的顺序一一总结。
第一章 焦油坑
史前时代的焦油坑吞噬了成千上万个力大无穷的巨兽，今天的大型软件项目则令无数庞大的开发团队陷入无从逃脱的窘境。软件程序按其规模和目标的不同，对开放过程的要求也有极大的不同，这给软件开放这一职业带来无穷乐趣，同时也是这一行业苦恼的根源。
第二章 人月神话
软件开发项目常以人月来衡量工作量，这种度量暗示着人手和时间是可以互换的。这种“人多力量大”的想法是一种一厢情愿的虚妄神话，布鲁克斯法则：向滞后的软件项目追加人手会使得进度更迟缓。自本书第一版以来，这一法则在软件业广为传诵。
第三章 外科手术队伍
虽然优秀的程序员的工作效率往往数倍于平庸的程序员，但若是缺乏合理的配置，优秀的成员未必能构成优秀的团队。大型软件开发项目的团队需要和外科手术组一样妥善分工，各司其职协调配合。
第四章 贵族专制、民主制和系统设计
概念完整性是系统设计中最重要的因素，尤其对于大型软件系统，概念完整性是项目顺利完成的必要保障，为获得概念完整性，架构设计由精简的架构设计小组负责，具体实现则围绕核心概念展开，架构设计和具体实现既相分离，又相辅相成。以建筑工程为类比，概念完整性也是软件项目通往成功的保证。
第五章 画蛇添足
人们在第一个系统成功完成后，往往会在开发后续的第二个系统时犯冒进的错误。第二个系统经常成为过度设计或画蛇添足的牺牲品。要避免这种错误，必须在第二个系统开发时审慎地考查技术环境的变化，广泛进行交流和沟通，聆听各方面的建议，确立严谨的估算和规划。
第六章 贯彻执行
架构设计通常由核心设计小组完成，将设计概念传达到整个开发团队是贯彻概念完整性的必然要求。以System 360的开发经验为例，要贯彻概念完整性，需要在团队中保持良好顺畅的沟通和交流，采用形式化定义等技术来确保概念被精确地定义和传达。独立的测试小组是系统质量的良好保证。
第七章 巴比伦塔为何失败
如果缺乏良好有效的沟通和协作，成员间难以有效的配合，团队项目的目标就无法实现。清晰的工作文档，明确的组织结构，合理的职责分配，都是大型软件项目最终成功的保证。
第八章 胸有成竹
对大型软件系统产品的开发所需的时间和资源进行准确的估测，能让我们在项目进度和前景胸有成竹。软件代码的开发效率和代码模块之间所需的交互相关。界面交互复杂的程序需要更多的测试和调试时间，单纯地增加人手并不能有助于开发效率的提高。
第九章 削足适履
最大化资源利用率，减少不必要的资源占用，合理规划，使软件系统在资源有限的情况下依然保证了良好的性能，从而实现良好的可伸缩性和健壮性，这能体现软件开发人员精湛的设计技巧。巧妙的数据结构往往能大幅度地俭省资源耗费，提高系统运行的性能。
第十章 提纲挈领
在软件项目开发过程中，文档是不可或缺的，文档为整个团队规范了概念，以便团队中的沟通协作，以及进度校验。本章阐述了软件系统项目中至关重要的几类文档。这些关键文档应及时地更新，始终作为
项目进展的有效指南。
第十一章 未雨绸缪
变化是永恒的，用户的需求和期望在变化，开发者对用户需求的理解在变化，适用的技术也在变化，故而最佳的解决策略也可随之变化。软件开发团队应灵活地配置人力和资源，适应开发过程中的种种问题。程序的复杂性、用户需求的不确定性、软硬件技术环境的发展等因素导致了软件维护工作并非总是能够百分之百地获得回报。
第十二章 干将莫邪
软件开发项目所选择的技术和工具对保障项目能否令人满意地如期完成至关重要。合适的开发工具、评测技术能有事半功倍之效果，切于项目实用的工具和技术是项目团队的重要财富。本章提供了当年软件开发项目选择技术和工具的重要原则和建议。
第十三章 整体部分
大而无当的笼统见地并不能表现你真正地理解了一个软件系统，应该具体而系统地深入了解各个局部的技术。良好的自顶向下的设计，不仅能保证概念完整性，也能及早消灭许多隐患。及早在软件项目中引入测试， 错误发现得越早，修复错误的代价越小。
第十四章 祸起萧墙
项目进度的滞后经常来自不易察觉的点滴延误的累积。软件项目的经理应该尽量建立可以明确量化的阶段性目标，定期进行严谨而规范的项目阶段性验收，了解项目的进展状况，并及时进行计划、资源和人力的调整。关键路径图等技术有助于观察项目的进度。
第十五章 另外一面
虽然用户直接使用软件系统，但在许多应用领域中，用户不可能仅仅凭借与软件的直接交互就迅速掌握其所有功能。故而提供给用户的使用说明等文档是软件呈现给用户的另外一面，它也能直接影响用户对软件的满意度和可用性评价。文档的用途决定它的形式和内容。
第十六章 没有银弹――软件工程的根本和次要问题
本文最初发表于1985年的IFIP第十届世界计算机大会上，此时距《人月神话》初版发行已有十年，其间计算机技术领域的变化令人振奋，但作者在此提出，由于软件的复杂性，一致性，变化性和不可见性，解决软件危机的银弹并不存在。作者点评了二十世纪80年代前期为业界寄予厚望的一些新技术，讨论了它们在克服软件危机中所具备的优势和缺憾。
第十七章 再论“没有银弹”
相比《人月神话》初版而言，1986年发表的“没有银弹”（第十六章）发表后引发了热烈的争论，本章结合20世纪80年代后期到90年代前期之间软件复用、面向对象程序开发等等新技术的发展状况，回应了对《没有银弹》一文各种主要异议，认为由于《没有银弹》一文归纳的软件的几大特性，人们期待中的重大突破不可能在近期内到来。
第十八章 人月神话的观点：是或非？
在撰写《人月神话》的回顾和更新过程中，作者发现初版中断言的观点甚少被软件工程研究和实践所抨击、证实或证伪，因此在本章中作者提炼了初版中十五个章节中的概要，结合近年来软件技术的发展状况，对这些观点进行强调、修正和反思。
第十九章 二十年后的人月神话
在《人月神话》初版发布二十周年后，计算机技术领域已有很大变化，《人月神话》体现出深远的影响力，初版中的许多观点依然经常被人们谈论和引用，其中有些断言至今仍被软件开放人员奉为圭臬。作者结合当前软件工程领域的发展现状重新梳理了初版中的各核心观点，强调了概念完整性，重新评议了第二个系统效应，反省了瀑布模型的局限性，结合初版中的观点，作者评述了图形桌面系统、信息隐藏、面向对象高级语言等技术的发展，以及近年来软件工程领域的重要成果。
总而言之，《人月神话》是一部IT界的著作，它就像是一颗“银弹”，教会我们如何去消灭软件项目这只“人狼”，值得每个IT从业者认真研读。
推荐第5篇：《人月神话》读后感
《人月神话》读后感
在软件领域中,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks 博士为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践,影响着一代又一代….《人月神话：软件项目管理之道》（英语：The Mythical Man-Month: Eays on Software Engineering）是由IBM System/360系统之父佛瑞德·布鲁克斯所著经典文集，全书讲解软件工程、项目管理相关课题，被誉为软件领域的圣经，内容源于作者布鲁克斯在IBM公司System/360家族和OS/360中的项目管理经验[2]。该书于1975年首次发行（ISBN 0-201-00650-2），并于1995年重新发行纪念版（ISBN 0-201-83595-9），其中新增了对〈没有银弹〉一文的评论和回应，与4个额外的新章节。
书开始就形象有有趣的把软件危机比作：焦油坑 ========== 史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎...让我感觉到，软件开发过程中所遇到困难是多么的多，开发多么艰难。
当我看完《人月神话》突然感觉到这本书比《The Clean Coder: A Code of Conduct for Profeional Programmers 》更完美，是为软件开发经验的天马行空总结。比《Beautiful code》更为有远见，把我从充实代码的清晰简介升华，拓展到软件开发的高层度， 一个周密，准确，明朗的开发需求分析，可行性研究，软件实现是软件开发的完美递进，他们相互辅助，相互促进，如海浪一层的推着前浪奔向远方，而《人月神话》如软件工程开发经济的精华，碧玉。
在《人月神话》面前《设计模式》、《原型设计》、《灵活软件开发》、《面对对象思维》、只不过是冰山一角。正是《人月神话》---软件项目管理的圣经，软件领域的《孙子兵法》。
人月神话（英语：The mythical man-month）：这部分讲述人力（man）和时间（month）并不体现线性关系。指出以大量人员和较短的时间，并不能缩短软件的开发进度。一窝蜂的作业方式无助于软件生产，且会制造麻烦，产生出更差的软件。向进度落后的项目追加人力，只会使进度更加落后。因为新进的人员需要时间了解整个项目，而增加额外的沟通消耗。当有 N 个人必须在这群人之中进行沟通时（无阶级关系），当 N 增加，其输出 M 将抵消其效益，甚至倒退（最后几天所完成的进度，远不如刚开始几天所完成的进度。像是发现了许多错误）。
我的体会：软件开发的多少人参与和完成时间不成正比，过多的人参与并不一定能缩短开发时间。如战争，部队多，人多并不是关键，更多需要武器的先进，战术，兵多后方便的补给就得多。如是参与软件开发的人增加，软件的花费将提高，刚参加这需要时间了解项目，给软件管理带来了不协调。
人月神话的核心法则：概念完整性和架构师。Brooks认为，一个整洁、优雅的变成产
品必须向它的每位用户提供一个条理分明的概念模型，这个模型描述了应用，实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。概念的完整性是易用性中最重要的因素。而架构师，则是负责保证产品所有方面的概念完整性的，架构师设计的是能够让用户理解产品概念的模型，这包括所有的功能的详细说明以及调用和控制的方法。它就像电影的导演一样。
我的体会：概念完整性将软件开发连成了一条钻石项链，每个部分都不可忽视，不可取代。整体的抽象完整时软件管理的灵魂。正因为如此，可见架构师的重要性。因此另一方面 把工作切分给更多人做将造成额外的沟通（communication）代价——训练和相互的交流（intercommunication）。欲增加软件项目的人手，总共必须付出的代价可分为三方面：工作重新切分本身所造成的混乱与额外工作量、新进人员的训练、新增加的相互交流。
书其中有内容提到：外科手术团队。在接受相同的训练、同样都是两年资历的情况下，优秀专业程序员的生产力要比差劲的程序员好上十倍。短小精悍团队是最棒的——尽可能用最少的人。两人团队，其中一人当领导者，这通常是最佳的用人方式。以短小精悍团队开发真正大的系统就太慢了。绝大多数大型软件系统的经验显示，使用一堆人蛮干的方式最耗成本、最慢、最没有效率，做出来的系统在概念上也最不完整。
我的体会：软件编码实现过程中，需要不是人多，而是少而精的优秀程序员，编码员。所以整体程序员的素质很重要，有必要培训提高他们的素质。
《人月神话》的第二系统效应（英语：The second-system effect）就一个人所做过的设计而言，第二个系统是最危险的系统，一般来说，都倾向于过度设计。
当他做第三或之后的系统时，之前的经验会互相印证，以确认出这类系统的一般性特色，而系统彼此之间的不同处，也会帮助他辨别出属于特殊和非通用的部份。除了做些功能上的修饰之外，第二系统效应还有另外一项特征，那就是倾向于将之前已熟悉的技术发挥到淋漓尽致，但却没有留意到，这项技术早就跟目前项目的基本系统假设有冲突而不再适用，OS/360有好多这样的例子。（Windows NT则似乎是1990年代的示例）
对大部份OS/360的设计人员来说，它也是个第二系统，设计成员分别来自1410-7010磁盘操作系统、Stretch操作系统、Project Mercury实时系统、给7090用的IBSYS操作系统等等，几乎没有人拥有两个上述系统的发展经验，所以OS/360可称得上是一个最佳的第二系统效应示例。
我的体会：第二系统效应，不但消耗了巨大花费，而且将没有经验的开发人员拉进开发是一件很囧的事情。并不会给软件管理带来好处。
软件系统可能是人类创造中最错综复杂的事物，往往一个很小的功能，其实也需要开发人员的架构设计方面的完善，对其它模块的影响及扩展,以及代码编写工作。用户在前台可能看到的只是几个文字，实际是中开发人员日夜奋战的结果。很多时候，客户的需求修改，在他们眼里看起来是如此地Easy,可他们却忽视了很多他们看不到的因素---当然，这不是说怪我们的客户。我只是觉得，只有大家彼此沟
通，彼此理解，才会做出精品来。
推荐第6篇：人月神话读后感
3110402157_ 王森_软件11
2《人月神话》读后感
在阅读这本书之前,已经很多次听到关于人月神话这本书以及他的作者Brooks的消息了.在软件领域, 《人月神话》具有深远影响力而且畅销不衰.这一次,正好老师的作业要求我们阅读这本书,我终于使有机会阅读这本经典之作了.在这过去的几个星期里面,一点一滴的阅读这本书,粗略的了解了这本书.
首先,让我印象深刻的是《人月神话》提出的两条著名的法则：
1、人月神话：向一个已经延后的项目中投入更多的人力资源只会让它更延后。人月神话看上去这么浪漫的名字，原来并不是真的说神话故事，作者阐述的主要观点是在软件开发项目上项目进度和增加人员这两个概念是不能互换。虽然已经时隔20多年了，这本书依然给我震撼，一是让我惊讶的是，美国20年前软件项目所面临的问题，在我们现在依然如此，糟糕的情况没有改变，大家仍旧在焦油坑里挣扎，而且看上去没有解决办法.当读到“是当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。这就像使用汽油灭火一样，只会使事情更糟。越来越大的火势需要更多的汽油，从而进入了一场注定会导致灾难的循环。这让我明白了一个重要的道:理项目的进度是不能够光靠人力的增加来推进的.
2、没有银弹:没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步。
虽然现在有不少人对他的观点持反对或不同意见，但我始终觉得他的观点是对的——根本和次要问题的划分以及定义。作者认为软件开发困难的部分是概念的结构，如规格化、设计和测试等概念的结构，而不是概念的表述和实现概念，虽然实现概念可能占用了小于90%的时间，就如现今的软件开发一样，系统分析通常占用的整个项目开发时间不超过20%，而80%的时间花在编程上一样。
这两个原则已经在过去的几十年间得到了验证.我相信在未来,它以依旧是成立的.
另外,在焦油坑那一章里面,有一句话让我难以忘怀:岸上的船,如同海上的灯塔,无法移动.
是呀, 过去几十年的大型 系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。不过，如果我们想解决问题，就必须试图先去理解它。 这就是生活真理。要想解决一件事，首先要了解事情的始末。提出问题就是解决问题的答案。
人月神话还让我了解到, 软件系统可能是人类创造中最错综复杂的事物.往往一个很小的功能，实在也需要开发职员的架构设计方面的完善，对 其它模块的影响及扩展,以及代码编写工作。用户在前台可能看到的只是几个文字，实际是中开发职员昼夜奋战的结果。很多时候，客户的需求修改，在他们眼里看起来是如此地Easy,可他们却忽视了很多他们看不到的因素.
总而言之，《人月神话》是一部IT界的神话，经久不衰.它就像是一颗“银弹”，教会我们如何去消灭软件项目这只“人狼”，指引着每个IT从业者认真开发,开拓进取.人月神话将带领IT界的精英们创造一个又一个IT界的神话.
.
推荐第7篇：人月神话读后感
人月神话读后感
、《人月神话》是预言了未来还是扼制了未来?
事实是：我们目前的许多工程知识，——无论是从书上看到的，还是从实践中经验到的——大多未曾脱离《人月神话》之所言，人月神话读后感。
我在开篇中说《人月神话》“是一本可怕的书”。然而我感受恳挚的可怕之处在于：现今凡是论及工程(且不要让人感受是离经叛道)，那么所解说的定然是Brooks的这么的经验以及由此推出的见解，可能在不违拗这些经验和见解上的一些翔实的实作措施!我们全然不顾书中所言是假象，还是性质的推论，可能只是假象归纳的一个(未必准确的)答案。尽管这些答案大多数时候都好像预期地展目前你的切实工程中：
原文中还有众多相仿的见解、假象和答案，都成为了切实工程中的既存假象。先民们所说的圣人以及通神者，皆因他们多数时候在准确地预言自己的切实。只有当这个“多数时候”变成半点的时候，先民们才会置疑圣人和通神者的力气。其实我们懂得并未曾预言未来的人，大多数时候是两种情形导致的假象：
他做出了准确的推断;
你主观地跟随了他对未来的设定。
后者是风险的。大师们预言了未来也就改换了未来，即便未来未必“该当”好像他所预言的那样。
但万一这种预言的前提不准确，那么未来定然脱离这种波及而回到它该当的事态上去。好像我们看到的另一些事实一样，有许多假象阐明，我们正在归来工程***的道路上摸索前进。我们也觉察，在大多数情形下，先哲们的预言在实践中被检讨着，只是偶尔“不太灵光”。下表则列出一些不同的例子：
注1：我例举了爽利的一些见解，并不阐明我是Ap/Xp的fans。Ap/Xp的问题另论，在这里，我只是解释存在一种不同的信念。
注2：Brooks尔后确认“定然丢弃原型”是一个不太准确的见解。
注3：Brooks在这里未曾犯讹谬，只是他所谈论的是狭义的流程图，而我们例举的时序图则更广义。
我们追忆上一细节，在《人月神话》中的那“31%的答案”的前提——也即便那7%的性质中，如下两项是显明猜忌的(也是重要置疑)：
目标的性质：是大型工程，是系统项目，而不是过程
个体的性质：是私利性的
其实早就有人意识到个体的性质“未必全是私利的”，尊重这些个体就会带来一些收获。例如Ap正是因为更尊重开发人员的禀性与力气，以及互相间的配合而获得了效率的晋级。
再进一步地说，既然Brooks设定了“大型工程或系统项目”这么的目标，并给出了一些答案。那么在“小那么一点点的”工程项目中，是不是这些答案就无须定了呢?例如Brooks的众多提倡，对于某些目标——例如你要用为期三个月的工夫开发一个的产品——就并不是很管用;可能大约无法厉行——例如你的群体总共只有6个人，连“外科手术式的群体”都组织不起来，读后感《人月神话读后感》。
Brooks的答案对于同样的目标，以及在他所述的“性质”未能发生改换时，还是比拟管用(或有厉行的可能性)。因而上述一些例外，总是在上述的“7%的性质”被抵赖或被改换的情形下获得的。因而我们提出的问题是“如何抵赖或改换”这些难以撼动的性质。然而在我看来，Brooks早曾经在最佳位置上，给出了撬动它们的一个支点：
Brooks感受发生“自力更生小型过程”与“编程系统产品”是不同的问题。
Brooks谈论的编程系统产品的规模究竟有多大呢?我想起码该当是以IBM 360为参看的。不过书中在引用Joel Aron(IBM在马里兰州盖兹堡的系统技巧主管)的例子时说，“大型意味着过程员的数目超过25人，将近30,000行的号召”。而按照《人月神话》的数据：人均效率800号召/人年，则这个“大型项目”该当必需1.5年能力告终。另外，还必需大约一倍的人工，来负责除开代码之外的测验、管教、文档和沟通等工作。
好的，万一你有一个“(起码)50人，开发一年半”的项目，那么你能够先接受Brooks的答案去实践一下：起码你能够有工夫来谈论工程问题，也能够组建那样规模的群体。然而，难道只有这么的“大型工程”才算得工程，而“小那么一点点”的就不算吗?切实是，我们一方面在做着“小那么一点点的”工程项目，另一方面在听着全副业界嘈杂着“为更大规模的工程”而准备的工程理论。我们总在实践Brooks的“答案”可能“预言”，而淡忘这些答案的前提：
Brooks的经验源自对IBM 360等大型项目标实践与分析;
Brooks所述的工程是要获得编程系统产品;
Brooks感受编程系统产品的工作量可能是自力更生小型过程的9倍(在告终大约雷同功能的情形下)。
事实上我们目前的软件工程的进展是被驾驶了，而不是被预言了。从性质上来说，Brooks在《人月神话》中只是谈论了大型工程的厉行，以及相应规模下的群体创立。而我们，便按照这么的设定来摆开了全副软件工作的工程化厉行。
促成这种现状的，并不但仅是一本书的能力，还在于商业的能力。因为只有在这么扩展开来的工作环境中，才可能有商业时机。——即便那些工程顾问与厉行专家历来未曾厉行过“50人，开发一年半”这么的项目，凡是他们能报出Brooks的名字，能谈及某些工具在应付“大型项目”中的获胜经验，他们就曾经获胜了一半了。
为什么“爽利”之初颇受争议?为什么爽利对一些中小型的群体显得管用和可厉行?为什么当这些争议被摆在现在的获胜平息尔后，传统工程的理论家们却不忘恨恨地评上一句：那是一种不能(或难以)利用于大型工程的措施呢?!
因为万一大家都很“爽利”，都只做比这些大型工程“小那么一点点”的工程，那么传统工程的专家们就失业了。反到来，只有把工程做大，大到“爽利”错过了含义，而“宏伟”变成了性质的时候，传统工程就可感受任何失利找到借口：看啊，Brooks就说过“未曾银弹”嘛。
推荐第8篇：个人月总结
工作总结
一、万事开头难。从一开始就要有心，有心才能办好事。 俗话说万事开头难，一切事情都要有个很好的开头，工作自然如此，在来公司之前我就已做好充分的心理准备，无论工作是怎样的我都要认真对待，细心完成。工作重，要不气不馁不抱怨，工作轻，要不骄不躁足耐心。只有好心态，才有工作的好心情，进而才有好效率。
二、谦虚使人进步。生活是个大讲台，许多东西都要虚心受教。 在学校学做人，在社会学做事。生活处处有学习。工作自然也是如此，刚来时，我被指派跟着阿姨尝试、学习。在此期间，我越来越懂得谦逊，谦虚使人进步，骄傲使人落后。世界之大，有许多东西是我所不知道的，我只有谦逊，不断学习，不断充实自己，才能有一个更好的自己。
三、众人拾柴火焰高。一定要与人合作，才能快速高效。 自古就有圣人言：众人拾柴火焰高。在工作中，与人合作必不可少，不仅要能合作，还要会合作。在生产部呆的这一个月让我充分认识到了这一点。无论是大家一起倒花还是好几个人一起换盆，我们自然而然会分工合作，几人搬，几人装，几人跟车，合作无间，效率自然高。
四、责任重于泰山。一定要有责任心，事情才能做到位。 爱因斯坦说过：对一个人来说，所期望的不是别的，而仅仅是他能全力以赴和献身于一种美好事业。而一个人要对一件事全力以赴，那他必须要有责任心，心中有责，做事才能负责，才能竭尽全力。而只要做事者竭尽全力，再难的事情也有解决的办法，世上无难事只怕有心人嘛。在我看来生产部是公司的源头，更要做好，管窖人员更要有责任感，才能更好的为公司为自己创造利益。
综上所述，我对接下来的工作做一个初步规划：
首先，我将每天以一个好心态来面对我的工作。将生活情绪撤离工作，不能让私人情绪影响工作。其次，在学习生活中，不骄傲不自满，随时学习，随时充实自己。以一个谦逊的自己面对以后的工作学习。再次，我要做到更好的与人合作，无论是生产部还是行政部都少不了分工合作，在合作中与人形成更好的合作默契，追求更高的效率。最后，在任何时候，做任何事，都要全心全力，认真负责。无论是谁交代的任务、工作，不接则已，接了就要全心全责。以整个心去做事，才能做得更好更优秀。
推荐第9篇：人月神话读后感
人月神话读后感
二十九年前(1975)﹐IBM大型电脑之父──Fred Brooks 出版一本书﹕\"The Mythical Man-Month\"。收集了他在1960年代领导1000多人共同发展OS/360大型软件系统的心得和经验。该书是论文集﹐其中有一篇文章叫\"The Mythical Man-Month\"﹐他就以此作为书名。在1956~1965 之间﹐Brooks实际领导IBM 360 大型电脑的开发计划﹐包括硬体结构及庞大的OS/360作业系统在内﹐因之他具有IBM 大型电脑之父的尊称。由于OS/360是多达1000位程式师共同合作的大型软件开发工作﹐让他深刻了解到大型软件开发的技术和管理上所面临的种种困难和挑战。于是﹐他就将其领导开发OS/360软件系统的经验心得收集在这本书里。人们常拿Man-Month （多少人﹐做多少个月）来计算软件的工作量﹐但是Brooks发现软件的开发工作是需要人与人之间密切沟通的﹐使得设计工作不易分割﹐所以Man-Month 为单位的计算方法是有问题的(mythical)。也就得出著名的Brooks法则── 「对于进度已落后的软件开发计划而言﹐若再增加人力﹐只会让其更加落后。」(Adding manpower to a late software project makes it later)这是该书名称的涵义。
看完此书后，我发现人月神话无处不在，其实在我们做
软件工程来说，此书已经渗透进去了。本书作者为人们管理复杂项目提供了颇具洞察力的见解，既有很多发人深省的观点，也有大量的软件工程实践。 本书对我触动最大的，一是保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。
二是“一个拿2倍工资的人，生产率可能是其他人的10倍。”不知道其他公司的程序员们如何看。我觉得，作为公司，应该给最好的人最好的待遇，或者说给比目前更高的待遇。组建一个团队，最好的就是那种精英团队。微软就是这
种思路吧，把最聪明的人集中在一起，想不成功都难。
三是进度落后与增加人力。记得当年看《C＋＋编程思想》，Bruce说“十个妇女不能在一个月内生下小孩”（大意），于我心有戚戚焉。而本书作者Brooks得出的结论是对我是震撼性的：“向进度落后的项目中增加人手，只会使进度更加落后”。以前，增加人手基本是挽救进度落后项目的主要办法。这个办法行不通的话，难道只有“加班”一条路了？如果不想加班，不想削减功能，不想推迟发布日期，那么。。。。。唯一的方法还是只有….加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见（特别是加入的人中有比较强大的设计者）。那么，就当作，新组建了一个团队吧。交流，培训新人，就设计达成一致，继续向者目标前进。
不同的社会经验，不同的思想状态，对读本书的心得也不一样。在此我说说书中许多非常好的观点。
1.外科手术队伍The Surgical Team
项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任。
2.贵族专制，民主政治Aristocracy,Democracy,System
要获得概念的完整性，设计必须由一个人或具有共识的小组来完成。
3.画蛇添足The Second-System Effect
讲述的基本都是基于IBM 360操作系统以及编译程序等方面的经验，讲述如何避免开发第二个系统的风险，作者认为开发第二个系统的设计师设计出来的系统是最危险的,因此要求他们自律。
4.贯彻执行Paing the word
印象比较深刻的是\"体系结构设计人员必须为自己描述的任何特性准备一种实现方法，但他不应该支配具体的实现过程。\"
5.巴比伦塔会失败Why did the Tower of Babel Fail?讲述巴比伦塔会失败的原因是缺乏交流。
6.胸有成竹Calling the Shot
主要讲述如何计算编程时间，以及提出几个人的经验算法。 讲述的各种算法可能都不太适合与现在的高级语言，但Portman的观点仍然适合现在，即编程人员实际的编程时间只有50%，其他的时间都花在了无关的琐碎事情上。
7.削足适履Ten Pounds in a Five-Pound Sack
主要讲述程序占用的空间等，在70年代比较突出，但现在好多了。
8.提纲擎领The Documentary Hypothesis
说明文档的作用
9.未雨绸缪Plan to Throw One Away
唯一不变的是变化本身。 在大型项目中，项目经理需要有两个和三个顶级程序员作为技术轻骑兵，当工作繁忙最密集的时候，他们能急驰飞奔，解决各种问题。
10.干将莫邪Sharp Tools
主要讲述项目中管理好各种工具的重要性，项目经理首先要制定一种策略，让各种工具成为公用的工具，这样才能使开发、维护和使用这种工具的开发人员的效率更高，这种工具可能是开发人员开发出来的，也可能是使用现有的，可能是通用的，也可能是专用的或个人偏好的。比如：文档编写工具、开发工具（包括各种不同开发平台）、调试工具、测试工具、数据库工具、版本管理、项目管理工具等。
11.整体部分The Whole and the Parts
特别是这句话\"BELL实验室监控系统项目的V.A.Vyotsky提出,“关键的工作是产品定义。许许多多的失败完全源于那些产品未精确定义的地方”,细致的功能定义，详细的规格说明，规范话的功能描述说明以及这些方法的实施，大大减少了系统中必须查找的BUG数量。虽然这句话的意思只是说明精确定义产品将减少BUG的数量，但我看到了系统分析的最重要的工作——产品定义。
12.祸起萧墙Hatching a Catastrophe
这章节说明使项目进度拖后的最大原因不是重要的事件，如新技术、重组等，而是一些琐碎的小事，每件小事只耽误半天或一天时间，但这种小事多以后，将使项目的进度严重拖后。 项目对于公司就如程序对测试工程师一样，如果不了解它，它就是一个黑盒子，如果不打开这个黑盒子，你可能永远不知道盒子里面有什么。
13.另外一面The other face
本章说明程序的另一面——文档。
不了解，就无法真正拥有——歌德，作者引用的歌德的话来描述文档对客户的重要性，提出客户需要什么样的文档以及文档的格式和包含的内容，指出当时存在的大多数文档只描述了树木，形容了树叶，但没有整个森林的图案。想想，这种情况在现在仍然没有改变。于是作者提出了两个观点：
1.流程图：流程图是被吹捧得最过分的一种程序文档。许多程序甚至不需要流程图，很少程序需要一页以上的流程图
2.自动文档化（self-documenting）的程序：提出文档与程序合为一体，能很好的解决文档与程序分开造成的文档过时的问题，并说明了在程序中加入文档的一些方法和技巧。
14.没有银弹-软件工程中的根本和次要问题(No Silver Bullet-Eence and Accident in software Engineering)
人狼是传说中的妖怪，只有银弹才能杀死他。作者认为软件项目具有人狼的特性，因为软件项目也可能变成一个怪物，一个落后进度、超出预算、存在大量缺陷的怪物。作者通过软件系统的内在特性复杂性、一致性、可变性和不可见性来分析说明了软件天生就没有银弹。 作者试图通过分析软件问题的本质和很多侯选银弹的特征来探究其中的原因。他行动的第一步是将大块的“巨无霸理论”替换成“微生物理论”。这个变化的过程告诉你，进步是逐步取得的，伴随着辛勤的劳动，对规范化过程应进行持续不懈的努力，而这个努力的过程相应的就诞生了软件工程。
15.再论《没有银弹》No Silver Bullet Refired
看完再论《没有银弹》后，虽然作者说有不少人对他的观点持反对或不同意见，但我始终觉得他的观点是对的——根本和次要问题的划分以及定义。作者认为软件开发困难的部分是概念的结构，如规格化、设计和测试等概念的结构，而不是概念的表述和实现概念，虽然实现概念可能占用了小于90%的时间，就如现今的软件开发一样，系统分析通常占用的整个项目开发时间不超过20%，而80%的时间花在编程上一样。
推荐第10篇：《人月神话》读后感
学号：0967020449姓名：张小波班级：软件工程专升本3班
《人月神话》读后感
在软件领域中,很少能有像《人月神话》一样具有深远影响力和畅销不衰的著作。Brooks 博士为人们管理复杂项目提供了最具洞察力的见解,既有很多发人深省的观点,又有大量软件工程的实践,影响着一代又一代….
通过阅读《人月神话》，我从中学到了一些东西：
首先，开发一个项目，我们错误的认为用人月这个工作量单位来估计和进行进度安排。成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。 它暗示着人员数量和时间是可以相互替换的。人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流，而在系统编程中近乎不可能。当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。调试、测试的次序特性，许多软件都具有这种特征。因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
对于编程，有其乐趣和苦恼。创建事物的快乐 ，开发对其他人有用的东西的乐趣 ，将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力 ，面对不重复的任务，不间断学习的乐趣 ，工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动，其存在、移动和运转方式完全不同于实际物体。将做事方式调整到追求完美，是学习编程的最困难部分；由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序）；权威不等同于责任实际情况看起来要比这一点好一些；真正的权威来自于每次任务的完成任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外 人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢产品在即将完成时总面临着陈旧过时的威胁。
开发一个软件，我们要有合理的时间进度，开发人员要少而精，概念完整性必须考虑在内，要尽量做到尽早交流和持续沟通。
同时，文档形成了关键的枢纽，每个项目管理的工作都围绕着它们运转，它们是经理们的主要个人工具。对于计算机硬件开发项目，关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格；对于大学科系，关键文档类似：目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教师和研究生助手的分配；对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。即使是一个小型项目，我们都会要求书写相关文档，对每个关键文档的维护提供了状态监督和预警机制并且本身就可以作为检查列表或者数据库。
良好的工作手册和组织架构可以开发出更加符合用户的需求。手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规
定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。
形式化定义是精确的，它们倾向于更加完整；差异得更加明显，可以更快地完成。但是形式化定义的缺点是不易理解。记叙性文字则可以显示结构性的原则，描述阶段上或层次上的结构，以及提供例子。它可以很容易地表达异常和强调对比的关系，最重要的是，它可以解释原因。在表达的精确和简明性上， 目前所提出的形式化定义， 具有了令人惊异的效果， 增强了我们进行准确表达的信心。
通常，开发一个软件我们还会设立规模目标，控制规模，发明一些减少规模的方法——就如同硬件开发人员为减少元器件所做的一样。规模预算必须与分配的功能相关联； 在指明模块大小的同时，确切定义模块的功能。培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。
调试，是一种检验程序中的方法。然而调试是系统编程中很慢和较困难的部分，而漫长的调试周转时间是调试的祸根。它可以持续一个很长的时间，从而可能影响项目的交付日期。
为了更好的控制进度，我们需要制定一个严格的进度表来控制项目的进度表，进度表由里程碑和日期组成。里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。进度表有时可以根据进展情况进行适度的修改。
产品测试时每个产品在提交给用户的一道程序。而这项工作主要由产品测试机构/小组根据规格说明检查机器和程序，充当麻烦的代言人，查明每一个可能的缺陷和相互矛盾的地方。每个开发机构都需要这样一个独立的技术监督部门，来保证其公正性。产品－测试小组则是顾客的代理人，专门寻找缺陷。不时地，细心的产品测试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。出于这方面的原因，设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手，与设计同时实施的重要环节。
一个已开发的项目，我们需要对它进行后期维护。其维护基本上不同于硬件的维护， 它主要由各种变更组成， 如修复设计缺陷、新增功能、或者是使用环境或者配置变换引起的调整而且维护总成本通常是开发成本的40％或更多。维护成本受用户数目的严重影响，用户越多，所发现的错误也越多。在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。其实，对于一个项目，我们要尽量做到完美，减少以后的维护困难和成本。
在计算机技术进步的同时，计算机相关学科知识也在飞速发展。兴趣太多，令人兴奋的学习、研究和思考的机会也太多——多么不可思议的矛盾啊！这个神奇的时代远远没有结束，它依然在飞速发展。更多的乐趣，尽在将来。
第11篇：《人月神话》读书笔记
第1章 焦油坑
这一章分成两个部分：
程序（Program）、程序产品（Programming Product）、编程系统（Programming System）、编程系统产品（Programming Product System）的概念
程序员的工作性质
比较有意思的是第一部分的四个概念。
在作者的眼中，程序就是一堆代码，任何人可以宣称自己会编程，但是编程得到的只是程序，而不是产品。程序要成为程序产品，需要有明确的输入、功能和输出，经过完备的测试，具备合格的文档，使之功能可靠，维护易行。
编程系统是从系统的角度来看待功能完整的程序模块，要求程序要具备语法和语义精确的接口，能够与其他的程序进行流畅的交互。相比程序产品来说，不仅仅要严格测试程序自身的输入、处理、输出，还要测试与不同程序之间的交互，因为很多bug其实是隐含在不同功能模块的交互过程中。另外编程系统还要考虑程序之外的软硬件运行环境。呵呵，只有经过了集成测试之后才能称之为编程系统。
最高级的形式是编程系统产品，从书中的表述来看，就是编程系统+各类文档，文档是为了后续维护和升级方便而准备的。智力产品如果没有说明书真是一场噩梦啊，之前我们经历过的不少系统到了后续维护的时候发现文档补齐，维护人员真是伤透脑筋，最后问题太多了索性就提议推倒重做。可以说如果是文档齐备一点，我们公司很多系统的寿命是可以更长的。
第2章 人月神话
第12篇：人月神话笔记
人月神话读书笔记(一)
第一章 焦油坑
表面上看起来好像没有任何一个单独的问题会导致困难，每个都能被
解决，但是当它们相互纠缠和积累在一起的时候，团队的行动就会变
得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很
难看清问题的本质。不过，如果我们想解决问题，就必须试图先去理
解它。--清楚地解释系统开发的困难所在。
这，就是编程。一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共
存的创造性活动。对于许多人而言，其中的乐趣远大于苦恼。而本书
的剩余部分将试图搭建一些桥梁，为通过这样的焦油坑提供一些指导。
--本书的目的
第二章 人月神话
1.在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来的影响还大。导致灾难的原因是：
首先，我们对估算技术缺乏有效的研究。
第二，我们采用的估算技术隐含地假设人和月可以互换，错误地将进度与工作量相互混淆
第三，由于对自己的估算缺乏信心，软件经理通常不会有耐心持续地进行估算这项工作。 第四，对进度缺少跟踪和监督。
第五，当意识到进度的偏移时，下意识（以及传统）的反应是增加人力。
2.系统开发过程中，乐观主义并不应该是理所应当的。
在单个任务中，“一切都将运转正常”的假设在时间进度上具有可实现性。因为所遇的延迟是一个概率分布曲线，“不会延迟”仅具有有限的概率，所以现实情况可能会像计划安排的那样顺利。然而大型的编程工作，或多或少包含了很多任务，某些任务间还具有前后的次序，从而一切正常的概率变得非常小，甚至接近于无。
3.成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。它暗示着人员数量和时间是可以相互替换的。
因为软件开发本质上是一项系统的工作--错综复杂关系下的一种实践--沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
4.在时间进度中，顺序限制所造成的影响，没有哪个部分比单元测试和系统测试所受到的牵涉更彻底。
对于任务的进度安排，以下是作者使用了很多年的经验法则：
1/3 计划
1/6 编码
1/4 构件测试和早期系统测试（单元测试）
1/4 系统测试
5.如果发现项目的实际进度滞后于预计的进度，项目经理最好的办法是重新安排进度，而不是增加项目人手。
6.项目的时间依赖于顺序上的限制，人员的数量依赖于单个子任务的数量。从这两个数值可以推算出进度时间表，该表安排的人员较少，花费的时间较长（唯一的风险是产品可能过时）。相反，分派较多的人手，计划较短的时间，将无法得到可行的进度表。总之，在众多软件项目中，缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加
起来的影响还要大。
第三章 外科手术队伍
1.对于效率和概念的完整性来说，最好由少数干练的人员来设计和开发，而对于大型 系统，则需要大量的人手，以使产品能在时间上满足要求。如何调和这两方面的矛盾呢？--本章要解决的问题
2.Mills的建议：
外科医生（首席程序员）：定义功能和性能技术说明书，设计程序，编制源代码，测试 以及书写技术文档。
副手：主要作用是作为设计的思考者、讨论者和评估人员。
管理员：控制财务、人员、工作地点安排和机器，充当组织中其他管理机构的接口。 编辑：根据外科医生的草稿或者口述的手稿，进行分析和重新组织，提供各种参考信息 和书目，对多个版本进行维护以及监督文档生成的机制。
两个秘书
程序职员：维护编程产品库中所有团队的技术记录。
工具维护人员：保证所有基本服务的可靠性，以及承担团队成员所需要的特殊工具（特 别是交互式计算机服务）的构建、维护和升级责任。
测试人员：各个功能设计系统测试用例的对头，同时也是日常调试设计测试数据的助手。 负责计划测试的步骤和为测试搭建测试平台。
语言专家：寻找一种简洁、有效的使用语言的方法来解决复杂、晦涩或者棘手的问题。
3.当进行大系统开发时：
要有一个系统结构师从上至下地进行所有的设计。要使工作易于管理，必须清晰地划分体
系结构设计和实现之间的界线，系统结构师必须一丝不苟地专注于体系结构。
第四章 贵族专制、民主政治和系统设计
1.概念一致性
在系统设计中，概念完整性应该是最重要的考虑因素。也就是说为了反映一系列 连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合 的系统，哪怕它们其实包含着许多很好的设计。
2.功能与理解上复杂程度的比值才是系统设计的最终测试标准。但是功能本身 或者易于使用都无法成为一个好的设计评判标准。
3.简洁和直白来自概念的完整性。每个部分必须反映相同的原理、原则和一致 的折衷机制。在语法上，每个部分应使用相同的技巧；在语义上，应具有同样的 相似性。因此，易用性实际上需要设计的一致性和概念上的完整性。
4.概念的完整性要求设计必须由一个人，或者非常少数互有默契的人员来实现。
5.系统的体系结构(architecture)指的是完整和详细的用户接口说明。体系结 构必须同实现仔细地区分开来。
6.作者不认为只有结构师才有好的创意。新的概念经常来自实现者或者用户。 然而系统的概念完整性决定了使用的容易程度。不能与系统基本概念进行整合的 良好想法和特色，最好放到一边，不予考虑。如果出现了很多非常重要但不兼容 的构想，就应该抛弃原来的设计，对不同基本概念进行合并，在合并后的系统上 重新开始。
7.概念的完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来 自少数人的思想。实际工作被划分成体系结构、设计实现和物理实现，但这并不 意味着该开发模式下的系统需要更长的时间来创建。经验显示恰恰相反，整个系
统将会开发得更快，所需要的测试时间将更少。同工作的水平分割相比，垂直划 分从根本上大大减少了劳动量，结果是使交流彻底地简化，概念完整性得到大幅 提高。
第五章 画蛇添足
1.本章的目标：结构设计师要避免向系统中添加很多不实际的功能（避免
画蛇添足）。
2.尽早交流和持续沟通能使结构师有较好的成本意识，以及使开发人员获
得对设计的信心，并且不会混淆各自的责任分工。
3.面对估算过高的难题，结构师有两个选择：削减设计或者建议成本更低
的实现方法--挑战估算的结果。后者是固有的主观感性反应。此时，结构师 是在向开发人员的做事方式提出挑战。想要成功，结构师必须
牢记是开发人员承担创造性和发明性的实现责任，所以结构师只能建议，而 不能支配；
时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能 达到目标的方法；
对上述的建议保持低调和平静；
准备放弃坚持所作的改进建议。
4.一个可以开阔结构师眼界的准则是为每个小功能分配一个值：每次改进， 功能 x 不超过 m 字节的内存和 n 微秒。这些值会在一开始作为决策的向导 ，在物理实现期间指南和对所有人的警示。
5.项目经理必须坚持至少拥有两个系统以上开发经验的结构师的决定。同时 ，保持对特殊诱惑的警觉，他可以不断提出正确的问题，确保原则上的概念和 目标在详细设计中得到完整的体现。
第六章 贯彻执行
1.问题：项目经理如何确保每个人听从、理解并实现结构师的决策？对于有多个结构师
的小组如何保持系统概念上的完整性。
2.手册、或者书面规格说明，是一个非常必要的工具。手册是产品的外部规格说明，它
描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。
手册不但要描述包括所有界面在内的用户可见的一切，它同时还要描述用户看不见的事物。
后者是编程实现人员的工作范畴，而实现人员的设计和创造是不应该被限制的。体系结构
设计人员必须为自己描述的任何特性准备一种实现方法，但是他不应该试图支配具体的实
现过程。
规格说明的风格必须清晰、完整和准确。用户常常会单独提到某个定义，所以每条说明都
必须重复所有的基本要素，所以所有文字都要相互一致。
3.规格说明中，形式化定义是精确的，它们倾向于更加完整；差异得更加明显，可以更
快地完成。但是形式化定义的缺点是不易理解。记叙性文字则可以显示结构性的原则，描
述阶段上或层次上的结构，以及提供例子。应同时包括形式化和记叙性定义两种方式。
4.通过会议的方式，开发人员进行沟通和讨论问题。
5.不同实现之间严格要求相互兼容。如果起初至少有两种以上的实现，那么定义会更加
整洁和规范。
6.对于存有疑问的实现人员，应鼓励他们打电话询问相应的结构师，而不是一边自行猜
测一边工作。
一种有用的机制是由结构师保存电话日志。日志中，他记录了每一个问题和相应的回答。 每周，对若干结构师的日志进行合并，重新整理，并发布给用户和实现人员。这种机制很
不正式，但非常快捷和易于理解。
7.在最后的分析中，用户是独立的监督人员。在残酷的现实使用环境中，每个细微缺陷
都将无从遁形。产品测试小组则是顾客的代理人，专门寻找缺陷。不时地，细心的产品测
试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。出于这方
面的原因，设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手
，与设计同时实现的重要环节。
第七章 为什么巴比伦塔会失败
1.项目人员之间的交流和沟通是项目能否顺利和成功的一个重要因素。
2.缺乏交流引起进度灾难、功能的不合理和系统缺陷纷纷出现。随着工作的进行，许多小组慢慢地修改自己程序的功能、规模和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定。
团队如何进行相互之间的交流沟通：
清晰定义小组内部的相互关系和充分利用电话，能鼓励大量的电话沟通，从而达到对所书写文档的共同理解。
常规项目会议。会议中，团队一个接一个地进行简要的技术陈述。这种方式非常有用，能澄清成百上千的细小误解。
在项目的开始阶段，应该准备正式的项目工作手册。
3.项目工作手册不是独立的一篇文档，它是对项目必须产出的一系列文档进行组织的一种结构。
项目所有的文档都必须是该结构的一部分。这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。
4.使用项目工作手册的原因：
技术说明几乎是必不可少的。如果某人就硬件和软件的某部分，去查看一系列相关的用户手册。他发现的不仅仅是思路，而且还有能追溯到最早备忘录的许多文字和章节，这些备忘录对产品提出建议或者解释设计。
正确的文档结构非常重要。事先将项目工作手册设计好，能保证文档的结构本身是规范的。另外，有了文档结构，后来书写的文字就可以放置在合适的章节中。
控制信息发布，确保信息能到达所有需要它的人的手中。
5.团队组织的目的是减少不必要的交流和合作的数量。减少交流的方法是人力划分和限定职责范围。当使用人力划分和职责限定时，树状管理结构所映出对详细交流的需要会相应减少。
第八章 胸有成竹
1.问题：系统编程需要花费多长时间？需要多少工作量？如何进行估计？
2.工作量是规模的幂函数。
Portman的数据：工作花费的时间大约是估计的两倍。
Aron、Harr、OS/360的数据：生产率会根据任务本身的复杂度和困难程度表现出显著差异。
Carbato的数据：对常用的编程语句而言。生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况。使用适当的高级语言，编程的 生产率可以提高5倍。
第九章 削足适履
1.系统的空间规模：规模是软件系统产品用户成本中如此大的一个组成部分，开发 人员必须设置规模的目标，控制规模，考虑减小规模的方法。同任何开销一样，规模 本身不是坏事，但不必要的规模是不可取的。
2.对项目经理而言，规模控制既是技术工作的一部分，也是管理工作的一部分。必 须研究用户和他们的应用，以设置将开发系统的规模。接着，把这些系统划分成若干 部分，并设定每个部分的规模目标。由于规模--速度权衡方案的结果在很大的范围内 变化，规模目标的设置是一件颇具技巧的事情，需要对每个可用方案有深刻的了解。 聪明的项目经理还会给自己预留一些空间，在工作推行时分配。
仅对核心程序设定规模目标是不够的，必须把所有的方面都编入预算。
在指明模块有多大的同时，确切定义模块的功能。
培养开发人员从系统整体出发，面对用户的态度。
3.在速度不变的情况下，更多的功能意味着需要更多的空间。其中一个技巧是用功 能交换尺寸。设计人员必须决定用户可选项目的精细程度。
4.考虑空间--时间的折衷。对于给定的功能，空间越多，速度越快。
项目经理可以做两件事来帮助他的团队取得良好的空间--时间折衷。一是确保他们在 编程技能上得到培训，而不仅仅是依赖他们自己掌握的知识和先前的经验。特别是使 用新语言或者新机器时，培训显得尤其重要。另一种方法是认识到编程需要技术积累， 需要开发很多公共单元构件。
5.战略上的突破常来自数据或表的重新表达--这是程序的核心所在。数据的表现形 式时编程的根本。
第十章 提纲挈领
1.文档的跟踪维护是项目监督和预警的机制。文档本身可以作为检查
列表、状态控制，也可以作为汇报的数据基础。
2.软件项目文档的内容：
目标。待完成的目标、迫切需要的资源、约束和优先级。 软件开发网
产品技术说明。
进度表。
资金预算。
工作空间分配。
人员组织。
3.为什么要有正式的文档
首先，书面记录决策是必要的。人们能从令人迷惑的现象中得到清晰、确
定的决策。
第二，文档能作为同其他人沟通的渠道。项目经理的基本职责是使每个人
都向着相同的方向前进，所以他的工作主要是沟通，而不是做出决定。文
档能极大地减轻他的负担。
最后，文档可以作为数据基础和检查列表。通过周期性的回顾，他能清楚
项目所处的状态，以及哪些需要重点进行更改和调整。
项目经理的任务是制订计划，并根据计划实现。只有书面计划是精确和可
以沟通的。通过遵循文档开展工作，项目经理能更清晰和快速地设定自己
的方向。
第十一章 未雨绸缪
1.对于大多数项目，第一个开发的系统并不合用。可能太慢、太大，而且难以 使用，或者三者兼而有之。要解决所有的问题，除了重新开始以外，没有其他的 办法--即开发一个更灵巧或者更好的系统。系统的丢弃和重新设计可以一步完成 ，也可以一块块地实现。所有大型系统的经验都显示，这是必须完成的步骤。 -- 构建一个试验性的系统，然后抛弃它。
2.一旦认识到实验性的系统必须被构建和丢弃，具有变更思想的重新设计不可 避免。
3.为变化设计系统，包括细致的模块化、可扩展的函数、精确完整的模块间接 口设计、完备的文档。另外，还可能会采用包括调用队列和表驱动技术。
最重要的措施是使用高级语言和自文档技术，以减少变更引起的错误。采用编译时的操作来整合标准说明，在很大程度上帮助了变化的调整。
变更的阶段化是一种必要的技术。每个产品都应该有数字版本号，每个版本都应 该有自己的日程表和冻结日期。在此之后的变更属于下一个版本的范畴。
4.为变更计划组织架构和团队。
5.程序维护中的一个基本问题是 -- 缺陷修复总会以(20%--50%)的机率引入新 的bug。整个过程是前进两步，后退一步。作为引入新bug的一个后果，程序每条 语句的维护需要的系统测试比其他编程要多，成本非常高。
缺陷不能被彻底修复的原因：
首先，看上去很轻微的错误，似乎仅仅是局部操作上的失败，实际上却是系统级 别的问题。其次，维护人员通常不是编写代码的开发人员。
5.使用能消除、至少是能指明副作用的程序设计方法，会在维护成本上有很大 的回报。设计实现的人员越少、接口越少，产生的错误也就越少。
6.维护工作破坏系统的架构，增加了系统的混乱程度。随着时间的推移，系统 变得越来越无序，无法再成为下一步进展的基础。这时，系统的重新设计完全是 必要的。
系统软件开发是减少混乱度的过程，软件维护是提高混乱度的过程，即使是最熟 练的软件维护工作，也只是放缓了系统退化的进程。
第13篇：《人月神话》读后感
《人月神话》读后感
通过阅读《人月神话》，我从中学到了一些东西：
首先，开发一个项目，我们错误的认为用人月这个工作量单位来估计和进行进度安排。成本的确随开发产品的人数和时间的不同，有着很大的变化，进度却不是如此。因此我认为用人月作为衡量一项工作的规模是一个危险和带有欺骗性的神话。 它暗示着人员数量和时间是可以相互替换的。人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员，并且他们之间不需要相互的交流，而在系统编程中近乎不可能。当任务由于次序上的限制不能分解时，人手的添加对进度没有帮助。调试、测试的次序特性，许多软件都具有这种特征。因为软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，它很快会消耗任务分解所节省下来的个人时间。从而，添加更多的人手，实际上是延长了，而不是缩短了时间进度。
对于编程，有其乐趣和苦恼。创建事物的快乐 ，开发对其他人有用的东西的乐趣 ，将可以活动、相互啮合的零部件组装成类似迷宫的东西，这个过程所体现出令人神魂颠倒的魅力 ，面对不重复的任务，不间断学习的乐趣 ，工作在如此易于驾驭的介质上的乐趣——纯粹的思维活动，其存在、移动和运转方式完全不同于实际物体。将做事方式调整到追求完美，是学习编程的最困难部分；由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序）；权威不等同于责任实际情况看起来要比这一点好一些；真正的权威来自于每次任务的完成任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外 人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快一些，然而软件项目的情况却是越接近完成，收敛得越慢产品在即将完成时总面临着陈旧过时的威胁。
开发一个软件，我们要有合理的时间进度，开发人员要少而精，概念完整性必须考虑在内，要尽量做到尽早交流和持续沟通。
同时，文档形成了关键的枢纽，每个项目管理的工作都围绕着它们运转，它们是经理们的主要个人工具。对于计算机硬件开发项目，关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格；对于大学科系，关键文档类似：目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教师和研究生助手的分配；对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。即使是一个小型项目，我们都会要求书写相关文档，对每个关键文档的维护提供了状态监督和预警机制并且本身就可以作为检查列表或者数据库。
良好的工作手册和组织架构可以开发出更加符合用户的需求。手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。
形式化定义是精确的，它们倾向于更加完整；差异得更加明显，可以更快地完成。但是形式化定义的缺点是不易理解。记叙性文字则可以显示结构性的原则，描述阶段上或层次上的结构，以及提供例子。它可以很容易地表达异常和强调对比的关系，最重要的是，它可以解释原因。在表达的精确和简明性上， 目前所提出的形式化定义， 具有了令人惊异的效果， 增强了我们进行准确表达的信心。
通常，开发一个软件我们还会设立规模目标，控制规模，发明一些减少规模的方法——
就如同硬件开发人员为减少元器件所做的一样。规模预算必须与分配的功能相关联； 在指明模块大小的同时，确切定义模块的功能。培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。
调试，是一种检验程序中的方法。然而调试是系统编程中很慢和较困难的部分，而漫长的调试周转时间是调试的祸根。它可以持续一个很长的时间，从而可能影响项目的交付日期。
为了更好的控制进度，我们需要制定一个严格的进度表来控制项目的进度表，进度表由里程碑和日期组成。里程碑必须是具体的、特定的、可度量的事件，能进行清晰能定义。进度表有时可以根据进展情况进行适度的修改。
产品测试时每个产品在提交给用户的一道程序。而这项工作主要由产品测试机构/小组根据规格说明检查机器和程序，充当麻烦的代言人，查明每一个可能的缺陷和相互矛盾的地方。每个开发机构都需要这样一个独立的技术监督部门，来保证其公正性。产品－测试小组则是顾客的代理人，专门寻找缺陷。不时地，细心的产品测试人员总会发现一些没有贯彻执行、设计决策没有正确理解或准确实现的地方。出于这方面的原因，设立测试小组是使设计决策得以贯彻执行的必要手段，同样也是需要尽早着手，与设计同时实施的重要环节。
一个已开发的项目，我们需要对它进行后期维护。其维护基本上不同于硬件的维护， 它主要由各种变更组成， 如修复设计缺陷、新增功能、或者是使用环境或者配置变换引起的调整而且维护总成本通常是开发成本的40％或更多。维护成本受用户数目的严重影响，用户越多，所发现的错误也越多。在每次修复之后，必须重新运行先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏。其实，对于一个项目，我们要尽量做到完美，减少以后的维护困难和成本。
在计算机技术进步的同时，计算机相关学科知识也在飞速发展。兴趣太多，令人兴奋的学习、研究和思考的机会也太多——多么不可思议的矛盾啊！这个神奇的时代远远没有结束，它依然在飞速发展。更多的乐趣，尽在将来。
第14篇：读《人月神话》有感
读《人月神话》有感
读过《人月神话》，马上就被深深的吸引了。 这确实是一本很值得多次阅读的好书，每次阅读可能都能从中得到一些提示。 因此，把感触比较深的几点记下来。
编程会有很多的乐趣 。首先是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到愉快一样，成年人喜欢创建事物，特别是自己进行设计。我想这种快乐是上帝创造世界的折射，一种呈现在每片独特、崭新的树叶和雪花上的喜悦。其次，快乐来自于开发对其他人有用的东西。内心深处，我们期望其他人使用我们的劳动成果，并能对他们有所帮助。从这个方面，这同小孩用粘土为“爸爸办公室”捏制铅笔盒没有本质的区别。第三是整个过程体现出魔术般的力量——将相互啮合的零部件组装在一起，看到它们精妙地运行，得到预先所希望的结果。比起弹珠游戏或点唱机所具有的迷人魅力，程序化的计算机毫不逊色。第四是学习的乐趣，来自于这项工作的非重复特性。人们所面临的问题，在某个或其它方面总有些不同。因而解决问题的人可以从中学习新的事物：有时是实践上的，有时是理论上的，或者兼而有之。最后，乐趣还来自于工作在如此易于驾驭的介质上。程序员，就像诗人一样，几乎仅 仅工作在单纯的思考中。程序员凭空地运用自己的想象，来建造自己的“城堡”。很少有这样的介质——创造的方式如此得灵活，如此得易于精炼和重建，如此得容易实现概念上的设想。
软件任务的进度安排的经验法则。1/3计划、1/6编码、1/4软件测试和早期系统测试、1/4系统测试，所有构件已完成。在许多重要的方面，它与传统的进度安排方法不同： 分配给计划的时间比寻常的多。即便如此，仍不足以产生详细和稳定的计划规格说明，也不足以容纳对全新技术的研究和摸索。对所完成代码的调试和测试，投入近一半的时间，比平常的安排多很多。 容易估计的部分，即编码，仅仅分配了六分之一的时间。 通过对传统项目进度安排的研究，我发现很少项目允许为测试分配一半的时间，但大多数项目的测试实际上是花费了进度中一半的时间。它们中的许多项目，在系统测试之前还能保持进度。或者说，除了系统测试，进度基本能保证
要保持设计的概念完整。无论对小软件还是大软件，都必须由一个设计师主导，最多两个人讨论来共同完成软件的整体设计。作为一个软件，一个系统，必须有一个清晰明确的概念模型，大家都在这个框架下工作，所有的创新发展都必须与基本的概念相吻合。具体的实现人员可以细化概念，但只有总设计者才有否定与发展基本概念的权力。需要注意的一点是，即使是总设计师一直是同一个人，他脑海中所认为理所当然的规则或者概念，很可能由于没有明确的文档化，而没有成为所有开发者共同的概念。在其他开发者编码的时候，就可能会生成与概念相抵触的东东（模块，功能，算法），导致整体结构的恶化。这个时候总设计师一定要即时发现，做出更正。概念的完整性，对于很多小规模软件，由于开发人员不多，开发经理一般都能控制住所有的代码，概念完整性在组织层面就维持住了。但要注意以后的Bug修改，功能扩展的时候，也要时刻留意与最初的设计是否概念上相容。对于大规模的软件系统，则必须通过树状组织结构，层层控制，总设计师还是一到两人，每一层都有对下层的绝对把握能力。我以前参加过一个
15人左右的项目组，就是分为两层。感觉整体概念完整性的控制效果还不错。我没有更多人数项目的具体实践经验，希望以后能有机会参与比较大的项目。
软件系统可能是人类创造中最错综复杂的事物。往往一个很小的功能，实在也需要开发职员的架构设计方面的完善，对其它模块的影响及扩展,以及代码编写工作。用户在前台可能看到的只是几个文字，实际是中开发职员昼夜奋战的结果。很多时候，客户的需求修改，在他们眼里看起来是如此地Easy,可他们却忽视了很多他们看不到的因素---当然，这不是说怪我们的客户。我只是觉得，只有大家彼此沟通，彼此理解，才会做出精品来。
进行持续不懈的努力，而这个努力的过程相应的就诞生了软件工程。作者对软件工程诞生的原因做出这样的解释，我觉得符合外国思维的特点，这正是国人所缺乏。记得有一位朋友说过，中国妈妈与德国妈妈的区别，他说，如果手里拿的针掉到地上了，中国妈妈的第一反应是估计针掉下去的范围，然后在这个范围里面找，可能很快就找到了，也可能一直都找不到；但德国妈妈不同，她会拿一根粉笔来，把整个屋子画成一个大圈，接着把大圈分成许许多多的小圈，然后再到每个小圈里找，虽然比较慢，但最终肯定可以找到。仔细想象，大多数情况下，中国妈妈都会找到得比较快，这确实符合大多数中国妈妈的思维习惯，每个中国妈妈都这样找，这好象是与生俱来的本事，但为什么德国妈妈没有这个本事呢？是德国妈妈笨吗？为什么中国妈妈也有找不到的情况？而德国妈妈，虽然速度慢了点，却始终能够找得到？如果把这件故事推而广之，多年以后，德国妈妈创建了找针工程，她通过多次找针的实验数据，分析出针掉到整个房间中各个小圈的概率，总结出针在哪个小圈的概率最大，很快就可以找到针，找针速度早已高过中国妈妈，而中国妈妈还在依循与生俱来的本事。你能说德国妈妈笨吗？为什么中国妈妈和德国妈妈会有这么大的区别？是德国妈妈把大块的“巨无霸理论”替换成“微生物理论”吗？我觉得是是，你说呢？作者在后面的论述中用数学和物理的发展为例子也说明了，这种思想的成立。
感触还有很多，以后如果有机会再写。不过，项目成员都是最佳人选很困难，所以第一是处理好人尽其才。第二是做好项目成员的技能评估工作，根据评估情况和项目技能需求及时组织和安排培训。
第15篇：人月神话读后感2000字
读《人与神话》有感
翻开《人月神话》这本书的第一感受，感觉看这本书不像是在看一本和我们学的相关的书，书中用了很多的形象的比喻，来阐述项目管理中的一些问题，让人以很轻松愉悦心态去阅读。书开始就形象有有趣的把软件危机比作：焦油坑。史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎...让我感觉到，软件开发过的过程中，会有很多困难，很多的挑战。
看完此书后，我发现人月神话无处不在，其实在我们做软件工程来说，此书 已经渗透进去了。本书作者为人们管理复杂项目提供了颇具洞察力的见解，既有 很多发人深省的观点，也有大量的软件工程实践。大型编程项目深受由于人力划 分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。 《人月神话》探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。
的在刚刚进入软件工程学习时，老师就和我们说了一些关于“软件项目开发的完成与增加人员的问题”，这句话听起来通俗易懂，道理很简单明了，但实现起来却遇到了相当大的困难，这也是我在阅读完成《人月神话》时最大的感受。全书的第二章说的就是人月神话的关系。“一切都将运转良好”在软件工程中是不适用的；完成工作的人数与时间是不能进行简单的互换的，因为沟通需要额外的成本。我想这种问题的出现主要是就订单项目而言，因为人员的增加主要是因为客户所要求实现的东西并没有在计划的时间内收到满意的答复和应得的功能与效益。所以项目开发人员不断的增加，本书作者布鲁克斯得出的结论是显而易见的：“向进度落后的项目中增加人手，只会使进度更加落后”。如果不想加班，不想削减功能，不想推迟发布日期，那么唯一的方法还是只有加人。加足够的人。而且不要逐步加入，一定要一次性加入。要小心的是，新加入的人可能对原来的组织造成冲击，或者对原来的设计有不同意见，特别是我想如果如果有比较强大的设计者时就要当做新组建了一个团队。重新交流，培训新人，就设计达成一致，继续向者目标前进。这也是造成项目延迟的原因之一。软件开发的多少人参与和完成时间不成正比，过多的人参与并不一定能缩短开发时间。如战争，部队多，人多并不是关键，更多需要武器的先进，战术，兵多后方便的补给就得多。如是参与软件开发的人增加，软件的花费将提高，刚参加这需要时间了解项目，给软件管理带来了不协调。在我们实际进行软件开发的时候，各个成员之间要做好沟通协调，一个人开发软件虽然完整性会很好，但是效率太低；相反，团队开发虽然效率很高速度很快，但是如果各个成员之前没有很好地团结协作，各自为战，那么最后的结果也一定不会尽如人意。
书中主要提到在项目管理方面可以看到项目估算，组织结构和人员角色安排，团队建设和沟通，历史数据积累和建模，软件开发方法论，风险和问题管理等相关的内容；在软件工程方面可以看到架构设计保证概念完整性，整体和部分，空间技能和程序结构的关系，产品集成的方法和消除缺陷的设计思路；在支持过程上我们可以看到文档和流程的建设，软件开发工具对软件开发过程的支持和效率的提升以及工具的选择等相关内容，回过来再看，发现书里面仍然大部分内容
涉及到了团队，人和沟通。对于大型的软件工程项目仍然强调了人的重要性，在开篇就在讲开发人员的职业乐趣，后面又通过巴比伦塔讲沟通的重要性，在外科手术队伍中讲团队的组建和分工。这些都涉及到了团队中的人和交互，只有一个有了积极心态和热情的沟通团队，才可能成就一个伟大的团队。从最后的没有银弹，再次肯定了开发工作是一种高智力的脑力工作。
开发一个软件，我们要有合理的时间进度，开发人员要少而精，概念完整性必须考虑在内，要尽量做到尽早交流和持续沟通。同时，文档形成了关键的枢纽，每个项目管理的工作都围绕着它们运转，它们是经理们的主要个人工具。对于计算机硬件开发项目，关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格；对于大学科系，关键文档类似：目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教师和研究生助手的分配；对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。即使是一个小型项目，我们都会要求书写相关文档，对每个关键文档的维护提供了状态监督和预警机制并且本身就可以作为检查列表或者数据库。良好的工作手册和组织架构可以开发出更加符合用户的需求。手册、或者书面规格说明，是一个非常必要的工具，尽管光有文档是不够的。手册是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。
一个软件的好坏不是说是由一个程序员决定的，往往一个很小的功能，其实也需要开发人员的架构设计方面的完善，对其它模块的影响及扩展,以及代码编写工作。一个小小的bug，也许就需要好几个部门的分工协作。原著中说，软件系统也是人类创造的错综复杂的事物。所以只有在一个团队的沟通了解，通力协作和努力之下，才能做出更加完善的软件作品！
第16篇：人月神话读后感 1067001146
《人月神话》读后感
通过《人月神话》这本书的阅读，对于我的专业:软件工程，和以后开发软件的工作生涯当中有了全新的认识！
在看这本书的过程中我想到了四个问题：
1.外科手术队伍the surgical team 项目经理在项目的初期必须清楚的估计项目的人月运作模式（时间、人力在项目各阶段的分配），例如什么时候需要出什么样成果，决定了什么时候需要什么样的人加入项目，这是项目经理的责任。
2.贵族专制，民主政治aristocracy，democracy，system 要获得概念的完整性，设计必须由一个人或具有共识的小组来完成。如何得到概念的完有整性，是否要有一位杰出的精英，或者说是结构设计师的贵族专制.....
3.如何避免结构设计师产出无法实现或代价高昂的技术规格说明，使大家陷入困境。4 如何才能与实现人员就技术说明的琐碎细节充分沟通，以确保设计被正确地理解，并精确地整合到产品中。
希望这些问题在我以后的职业生涯当中，再结合这本书的概念，慢慢体会！ 人月神话的核心观点：概念完整性和架构师
Brooks认为，一个整洁、优雅的变成产品必须向它的每位用户提供一个条理分明的概念模型，这个模型描述了应用，实现应用的方法以及用来指明操作和各种参数的用户界面使用策略。概念的完整性是易用性中最重要的因素。而架构师，则是负责保证产品所有方面的概念完整性的，架构师设计的是能够让用户理解产品概念的模型，这包括所有的功能的详细说明以及调用和控制的方法。它就像电影的导演一样。
我的理解：这里的概念完整性其实应该说的是这个软件理念上的业务流程的前后连贯，也就是用户在使用产品的过程中，能够按照唯一的一个的最高抽象的思路来使用这整个系统。
开发第二个系统的后果——盲目的功能和频率猜测
所谓第二个系统，指的是产品的第二个实际发布。开发第一个发布的时候会因为各种原因去消减不必须的功能，所以会简化问题，而在第二个版本的时候则常常想其中添加各种各样的功能（也许源于用户的功能建议）但是，却导致了灾难性的后果。
所以，在这种情况下，用户群越大，越不稳定，我们就更加应该明确的定义用户群，以获得概念的完整性。我们必须为整个设计团队定义一个共同的用户图像，记录下用户群的属性：
1.他们是谁
2.他们需要什么
3.他们认为自己需要什么
最后，我希望自己通过对关于《软件工程》这门专业课和对这本一直畅销的《人月神话》
的学习能够让自己在以后的软件开发生涯当中有全面的提高和全面的认识！！！
第17篇：《人月神话》读后感2
《人月神话》读后感
姓名：张立敬班级：电子商务1班学号：100607020101
初读这部书就深深的震撼了我，不仅仅是作者对程序的观点和思想还有就是这些观点和思想在现实生活中也非常实用。我不得不说这部书是一部很值得多次阅读的好书，每次阅读可能都能从中得到一些提示与感悟。
第一、是什么让那么多爱好编程的人对自己的工作孜孜不倦
爱好，对编程的乐趣，当别人使用你做的系统或软件时那种成就感。这就是如书中所言：职业的乐趣所在:创建事物的快乐，开发对他人有用的东西，将零散的文字组装成一个有用的东西，不断学习的乐趣，创造性的工作。 这些也是促使我一直对生活充满希望，并热爱生活的原因。生活就像程序，错综复杂，但在这错综复杂的生活中也有许多乐趣等待我们去采撷，这就需要乐趣。
第二、是什么导致很多项目失败
彼此之间缺乏沟通以及交流的结果。客户的前期需求有很大的不确定
性，可能在开始时大家都以为说的是同一个事儿，但当做出来之后客户发现与自己想像的相差太远。同时，用户在操纵上的习惯题目也会成为一个不能忽视的因素，这也应该算作是需求的一部分吧。用户与开发项目组假如不在需求上认真“较真”，那以后的题目就会不断涌来了。这些需要靠什么往约束呢？靠文档，靠白字黑字的文档。那么对于 生活呢？我认为要想在社会生活的更好，良好的沟通与交流是必不可少的。世上有太多的不确定事情，而个人了力量毕竟有限，这就需要借助朋友的力量。在借助朋友力量时，沟通和交流则是首先必须做到的。怎样沟通，如何沟通，这都是我们应该考虑的。
第三、是什么造成项目滞后
缺乏合理的时间进度。有些时候过于乐观，有些时候过于妥协，经常缺
乏坚持。首先乐观一点固然比较好但要是没有理智的乐观就成了自大，这样往往会影响我们本应该做的事情。因此我们要学会根据具体情况看待事情，
从全局出发，掌握一定的基础，再加上我们乐观的心态，这样才能更好的做好一件事情。其次，妥协也是有原则的，该妥协的时候就妥协，毕竟事情不可能完全按照我们的思想进行，适当的妥协也许会让我们彼此都开心。最后就是坚持。无论做什么事情，都要坚持。没有一定的毅力，半途而废是不可能有所成就的。这就是生活真理。
第四、软件系统可能是人类创造中最错综复杂的事物
往往一个很小的功能，实在也需要开发职员的架构设计方面的完善，对
其它模块的影响及扩展,以及代码编写工作。用户在前台可能看到的只是几个文字，实际是中开发职员昼夜奋战的结果。很多时候，客户的需求修改，在他们眼里看起来是如此地Easy,可他们却忽视了很多他们看不到的因素---当然，这不是说怪我们的客户。我只是觉得，只有大家彼此沟通，彼此理解，才会做出精品来。
第五、岸上的船儿，如同海上的灯塔，无法移动。
这是焦油坑里的一句名言。也是我难忘的一句名言。过去几十年的大型
系统开发就犹如这样一个焦油坑，很多大型和强壮的动物在其中剧烈地挣扎。他们中大多数开发出了可运行的系统——不过，其中只有非常少数的项目满足了目标、时间进度和预算的要求。各种团队，大型的和小型的，庞杂的和精干的，一个接一个淹没在了焦油坑中。表面上看起来好像没有任何一个单独的问题会导致困难每个都能被解决，但是当它们相互纠缠和累积在一起的时候，团队的行动就会变得越来越慢。对问题的麻烦程度，每个人似乎都会感到惊讶，并且很难看清问题的本质。不过，如果我们想解决问题，就必须试图先去理解它。 这就是生活真理。要想解决一件事，首先要了解事情的始末。提出问题就是解决问题的答案。
《人月神话》，创造了编程世界的神话，也创造了人生历史的神话，更创
造了人生哲理的神话。
第18篇：业务员个人月总结
工作总结就是把一个时间段的工作进行一次全面系统的总检查、总评价、总分析、总研究，并分析成绩的不足，下面就是小编给大家带来的业务员个人月总结范文精选，希望能帮助到大家!
业务员个人月总结范文精选一
我认为要展开好一名销售跟单文员的工作，真正的大展拳脚，促进公司订单的顺利完成，应该遵循以下几点逐步进入角色：
一.7天之内了解工厂生产的产品。包括它的外观，质地，特性，优点，缺点，用途。虽然跟单文员不属于工程技术人员，似乎不需要对产品有更多的了解。其实不然。首先，在与客户沟通时，如果你对产品只一知半解，那么客户对你的信任度会大打折扣，甚至会怀疑你的工作能力。当客户向你咨询时，你也只能支支吾吾，或者老是去向技术人员打听，客户不可能放心的把订单交给你去做。也没有任何优势吸引客户向你下单。
跟单人员的虽然不是官，但是他的门禁权限却很广，他可以进出多个部门，这就给我们学习新产品提供了便利的渠道，只要你不怕苦，不怕累，勤下车间，不耻下问，没有学不会的东西。纺粘无纺布，熔喷无纺布等，相信很快会被我熟知并熟练的运用。
二.在最短的时间内弄懂生产过程及工艺。刚开始，一般人会认为跟单文员只需知道生产订单的进度就可以了，好像白领一样，坐在办公室，打着电话，发着email就可以掌控一切。一个优秀的跟单人员，会非常熟悉产品的工艺流程，生产一定数量的产品所需要的生产时间。会亲自进车间察看大货的进度。当积累经验久了，无论是工艺还是货期你都可以直接回复客户。
三.熟悉各部门的工作流程，按照公司的规定来办事。每一个公司都有自己的工作模式。如果每个人都按照自己的流程来进行工作，那么将会导致公司秩序的混乱，各个部门的工作也会受阻。严重的会导致公司蒙受经济及名誉上的损失。比如说，公司规定收到客户订单需要经理部门签名确定。有一天，跟单员张三收到编号为a-001产品的订单，当时经理部门正在讨论产品调价的问题。下面的文员还没得到具体的通知。这时，张三，直接将订单发给生产线，催促生产。没有给经理确认，而此时，a-001的产品因为原材料涨价的问题需要涨价。但大货已经在生产了，张三跟客户多次协商价格都调不上来。如果这时停止生产，那么那些半成品都会变为废品。如果让大货完成而不运送给客户，那你就违了约，且失去了信誉。最后只能亏本卖给了客户。这样就直接造成了公司亏损。
四.了解货物的运输。出国的货物一般通过船和飞机，国内的货物通过公司安排汽车或者安排物流公司运送。在订单完成之前，跟单文员要认真选择运输公司，并考察他的信誉度，是否有能力运送此批货物。**公司货物的运送主要通过物流来完成，我会尽快熟悉这些物流公司。经常与物流工作人员沟通，保证货物安全准时到达目的地。
五.熟悉了解客户。对于客户的订购产品的习性要有足够的了解。当出现异常情况时，可以做出果断的处理。比如说，客户订购的产品，在外观或者包装上有一点微小的瑕疵，新来的跟单员可能会请示上级领导或者跟客户协商是否能接受这种不达标的产品，如果是一位老跟单员，可以自己做出判断。不必劳烦他人。
六.正确对待客户服务。跟单文员实际上是公司和客户之间的一个窗口。首先，你是公司的雇员，你得对公司绝对忠诚，事事站在公司立场上，为公司着想。在客户那边，你必须坚持“客户是上帝”的原则。要让客户感觉到他是客户，正在享受星级的服务。客户不会理会公司其他部门是怎么运作，也不想知道更多，他只会与你联系，了解他的订单，了解他的货期。所以要做一个明亮清晰的窗口，要看清事实，冷静处理。我记得在东莞工作期间有一位同事，她总是盲目的满足客户的一切要求，从来不敢说“no”，根据工厂实际生产情况，订单的货期根本不能按照客户的时间交货，这位同事会说“ok”。后来只好安排订单外包出去，结果货期和质量都达不到要求。有时，客户给她一个新开发项目，所有人都晓得这个产品以我们现在的工艺无法完成，可这位同事总说：no problem!一个新项目来来去去搞了两三个月，既浪费了时间，又得罪了客户，最后又丢给客户自己去找其它厂商。这时客户时常打电话抱怨公司的服务不好，销售人员不好。慢慢的这位客户的订单越来越少，最后换了供应商。
七.加强与生产线的沟通，与车间工作人员保持良好的人际关系。跟单人员最关健的工作是沟通，跟催。如果与车间相关工作人员关系处理不好，那么跟单工作很难展开，根本无法促进生产，保证订单的顺利完成。
八.努力学习《中华人民共和国合同法》相关条款。在以往的工作中，很少接触到法律，因为全是国外订单。公司都会由专业人士起草一份谨密的固定合同格式。所有的销售员都采用统一的格式，只是修改一下客户名，货名，价格，货期，付款方式，备注等等。遇到的经济纠纷较少。遇到不付款的客户，在发电子邮件或打电话催款无效的情况下，有时是派国外公司驻外工作人员上门请款。在跟单过程中，只要重视与客户交流时的书面证据，一般都不会有问题。我记得有一次，一个法国的客户给我下了一张订单，他们的订单是法文，没有其它英文描述。也没有以往的英文货物编号。我通过数量和单价判断是一个装戒指的戒指棉，我查出该客户以往的订货记录，找出当时出货的照片，电邮给了客户，问他是否是需要这个产品。客户在电邮中回答yes。出货后的几个月，收到客户的投诉，说我们做错货，要求我们赔。我立即找出当时的电子邮件，客户只好承认是他们那边没有沟通好。然后重新下了一张订单。当时，生产部门也很高兴，因为上一单的货很容易生产，而且单价高，现在又来一张类似的订单，要知道，产量和销售额是与工人的奖金挂钩的。在国内，如果法律学得好，就可以避免可以很多不必要的麻烦，避免合同有漏洞，别人有机可趁，造成公司受损。
九.主动积极的寻找客源。之前跟国外订单，都是公司指派老客户，有时是从阿里巴巴或一些香港网站来几个询盘的客户，几番寒暄，然后按客要求做样版，收取样版费用。收到大货订单，出货。对于国内客户开发这一块，真是知之甚少。我认为要多留意国内城市对无纺布的需求动向，适时与之联系，展现公司及产品的优势，尽量为公司争取一些客户，拉一些订单。订单是公司的命脉，有了订单工厂才能运转。
十.保持乐观的工作心态。跟单工作是复杂，繁锁的。在订单多的季节，有时，你真的想借一个脑袋来用，连喝水上厕所的时间都没有，晚上做梦也在查货。这时你要保持一个平和的，乐观的心态，合理的有秩序的处理好手头上的事，分清轻重缓急，处理一件就少一件。相信自己的能力，这些棘手的事总会完成。在订单少的季节，也不要灰心，振作起来，趁空档对自己多充电，多学习专业知识。
以上是我根据以往的经验做的一个工作计划，因为没有正式进入**公司学习观摩，所以写得较为粗糙。有不妥之处或不完善的地方敬请指出，谢谢!
业务员个人月总结范文精选二
一，制定详细的工作计划
结合我司当前的资源，充分利用，更具去年的销售报告，我们应该努力发展开拓广告市场，虽然目前有许多问题摆在我的眼前，但是我们要最大限度争取终端广告的投放工作，同时，对还为开发的市场做好坚实的铺垫，争取有更大的投放，长期投放的客户吸纳进来。根据我们公司终端的数量的增长率情况，有针对性的调整我们的工作策略以及工作思路。
二，季度工作安排
1、第一季度，主要也市场培养为主，扩大***公司的影响力和知名度及推进速度告知，因为处于双节的特殊时期，很多公司的宣传计划已经制定完成，节后会有一个广告低潮期，我会充分利用这段时间补充专业知识，同时加紧联络客户感情，适当的寻找小一些的投放客户将广告投放进来，但我预计对方会有要求很低的折扣或者以货抵广告费的情况。
2、第二季度，因为有“五一节劳动节”的影响，广告市场会迎来一个小小的高峰期，并且随着天气变化，气温不断升高，洗浴用品、夏季饮品、防蚊用品等的广告会作为投放重点开发对象。
3、第三季度，“十一”“中秋”双节，广告市场会给后半年带来一个良好的开端，白酒、保健品、礼品等一些产品会加入广告行列。并且，随着我公司终端铺设数量的增加，一些投放量大的、长期的客户就可以逐步渗入进来了，为年底的广告大战做好充分的准备。
4、年底的广告工作是一年当中的顶峰时期，加之我们一年的终端铺设、客户推广，我相信是我们广告部最热火朝天的时间。随着冬季结婚人群的增加婚庆服务、婚庆用品也会加入广告行列，双节的广告气氛也会在这种环境下随之而来。
我会更加一年不同时段，有针对性有计划的开展工作，同时不断调整我的工作思路，加强客户的开发工作，正确把我司广告销售进一步提高到新的台阶。
三、制订学习计划。
市场开拓是需要根据市场不停的变化局面，不断调整经营思路的工作，不断提高知识对于业务人员来说非常重要，因为它直接关系到一个业务人员与时俱进的步伐和业务方面的生命力。我会适时的根据需要调整我的学习方向来补充新的能量。中国教育总网文档频道产品知识、营销知识、投放策略、数据、媒体运作管理等相关广告的知识都是我要掌握的内容，知己知彼，方能百战不殆(在这方面还希望公司给与我们业务人员支持)。
四、加强思想道德建设
一个人成功不算成功，应为我们是一个团队，今年我还要加强思想道德的建设，增强全局意识，增强团队协作意识、同时加强责任感。积极把工作做好。真正做到点子上、落到实处、同时我也将尽到我最大的努力帮助领导减轻工作压力。
业务员个人月总结范文精选三
忙碌的X月已经过去，在X月份当中，我在公司领导的正确领导和指导下，在各位同事的帮助协助下，很好的完成了当月工作和各项任务指标，在此我忠心的感谢，为了更好的做好以后的工作，我在此认真的完成x月工作总结，为自己在下阶段工作找到方向，认准下阶段应该坚持的一些好的方面。
(一)确保完成全年销售任务，平时积极搜集信息并及时汇总;
(二)努力协助业务经理的销售工作，从产品的价格，数量，质量以及自身的服务态度方面，细心的与客户沟通;
(三)销售报表的精确度，仔细审核;
(四)借物还货的及时处理;
(五)客户关系的维系，并不断开发新的客户。
(六)努力做好每一件事情，坚持再坚持!
最后，想对销售过程中出现的问题归纳如下：
(一)仓库的库存量不够。
虽然库存表上标注了每款产品最低库存量，但是实际却不相符，有许多产品甚至已经断货。
在库存不多的情况下，建议仓库及时与生产联系下单，或者与销售联系提醒下单，飞单的情况大多于库存量不足有关。
(二)采购回货不及时。
回货时间总会延迟，对于这种现象，采购人员的态度大多都是事不关已，很少会想着怎么去与供应商解决，而是希望销售人员与客户沟通延缓时间。
这样会让客户对我们的信誉度降低。
(这种现象非常严重)
(三)质检与采购对供应商退货的处理。
很多不合格的产品，由于时间拖延，最后在逼不得已的情况下一挑再挑，并当成合格产品销售，这样对我们“追求高品质”的信念是非常不吻合的。
经常有拿出去的东西因为质量问题让销售人员非常难堪。
(四)财务应定期对销售却未回款的业务进行催款或者提醒。
有许多已经回款的业务，财务在几个月之后才告诉销售人员，期间销售人员以为没回款一直都在催，给客户印象非常不好!
(五)各部门之间不协调。
为了自己的工作方便，往往不会太关心他人，不会考虑给他人带来的麻烦。
有时候因为一句话或者一点小事情就可以解决了，可是却让销售人员走了许多弯路。
(六)发货及派车问题。
(七)新产品开发速度太慢。
总之，今年我将更加努力做好自己份内的事情，并积极帮助他人。也希望公司存在的一些问题能够妥善解决。不断的开发新品，不断开发新的区域，相信公司一定会走得更远，市场占有率更高，楚天人都会洋溢着幸福的笑容.
业务员个人月总结范文精选四
工作总结就是把一个时间段的工作进行一次全面系统的总检查、总评价、总分析、总研究，并分析成绩的不足，从而得出引以为戒的经验。工作总结主要包括这些内容：基本情况、成绩和做法、经验和教训、以及今后打算。工作总结具有自我性、回顾性、客观性、经验性这些特点。
一、写作要点
1、要简洁、清晰、全面
上司在面对下属长篇大论式的工作总结免不了会头痛，尤其当下属不只三两人时，但工作总结通常关系到业绩评估，既要写全面，又不可能一一道来，怎么办?要保证年度工作总结简洁，使用ppt的形式写总结是一个值得提倡的方式。
2、要用数据说话
在上例中也能体现该点，用数据对工作进行汇总，既简单明了，又能清楚地说明总结者的工作能力。但在工作中搜集、汇总、使用数据是一项有一定难度的工作，需要在平时的日常工作中，有心地对工作进行记录。别忘了年度工作总结的数据，来自于每月、每周、每日，甚至每时的工作总结。在向阳生涯，公司每一位员工都进行过时间管理方面的培训，每个人每天都有详细的工作计划表，一天中计划完成几项工作，实际完成情况如何等，都有记录，有备可查，这就是积累数据的好方法之一。
3、要有成绩，也要有不足
成绩肯定是工作总结的重头戏，但人无完人，总不能事事都做得那么圆满，没有一点进步空间也不行。不足该怎么提?既要提出问题，还不能让问题变成自己真正的“问题”或“毛病”，引起上司对自己不好的看法。可以在工作总结中，将问题以挑战的形式表现，尽量表现问题的客观原因，及外部形势发展变化所引起的新挑战。
二、注意事项
1.要坚持实事求是原则
实事求是、一切从实际出发，这是总结写作的基本原则，但在总结写作实践中，违反这一原则的情况却屡见不鲜。有人认为“三分工作七分吹”，在总结中夸大成绩，隐瞒缺点，报喜不报忧。这种弄虚作假、浮夸邀功的坏作风，对单位、对国家、对事业、对个人都没有任何益处，必须坚决防止。
2.要注意共性、把握个性
总结很容易写得千篇一律、缺乏个性。当然，总结不是文学作品，无需刻意追求个性特色， 但千部一腔的文章是不会有独到价值的，因而也是不受人欢迎的。要写出个性，总结就要有 独到的发现、独到的体会、新鲜的角度、新颖的材料。
3.要详略得当，突出重点
有人写总结总想把一切成绩都写进去，不肯舍弃所有的正面材料，结果文章写得臃肿拖沓，没有重点，不能给人留下深刻印象。总结的选材不能求全贪多、主次不分，要根据实际情况和总结的目的，把那些既能显示本单位、本地区特点，又有一定普遍性的材料作为重点选用 ，写得详细、具体。而一般性的材料则要略写或舍弃。
业务员个人月总结范文精选五
一个月过去了，在这一个月中自己又长大了很多，也成熟了很多。其实自己想说的很多很多，但写到这又不知道自己该说什么，该从何说起。有些是自己的感悟，有些是同事教我的，而有些则是自己在为人处事时学到的。在这里我感谢公司的所有人，感谢你们对我的帮助，感谢你们对我耐心的教导，让我很认真的能学到知识和道理。
短短的一个月对于一个人有很大的成就能力，这个月我得到了很多的帮助，不但是在工作上，生活上也得到了很多。这个月自己的身体很是不争气，常常的给我出很大的问题。就在快要结束的月底来了次最大的问题，还好有同事的关照，我很快就好了。这个月的工作自己也有很大的进展，同时自己还第一次尝试了出去跑业务。虽说碰了一鼻子的灰，但是自己还的学会了很多。同时也发现了自己还有很大的不足之处，那就是专业知识和机床资料还不太成熟，就这一点很吃亏。
总的来说自己这个月有失去的也有得到的，得到的总比失去的多，现在自己也开始学会了满足，不像以前的自己做什么都不懂满足这个道理，只是想去奢求别人能给予自己什么，但是从不想自己能给别人什么，这个习惯慢慢的自己必须去更改掉，同时自己在别的方面有所收获，那就是工作态度和勤奋敬业方面。热爱自己的本职工作，能够正确认真的对待每一项工作，工作投入，认真遵守劳动纪律，保证按时出勤，出勤率高，有效利用工作时间，坚守岗位，需要加班完成工作按时加班加点，保证工作能按时完成。这也是来公司这两个月得到学校所学不到的一些重要知识，无论以后到哪里这是一项很强的工作能力。
自己在这个月跑业务的时候明显感觉自己的业务知识很缺少，所以自己必须要求自己尽快的补充业务知识的能力，就算工作再忙也不能放松学习，学习是一种觉悟、一种责任、一种境界、一种能力，工作忙要在干中学，时间紧要在学中干。不仅要学习政治理论和业务知识，还要学习市场经济理论、法律法规等知识，注重知识的更新，拓广知识面，增强各种适应能力。所以大家也应该再工作之余去多学习，那样自己才不会让这个时时在更新的时代所抛弃。
总结这个月的工作，尽管有了一定的进步和成绩，但在一些方面还存在着不足。比如有创造性的工作思路还不是很多，个别工作做的还不够完善，这有待于在今后的工作中加以改进。在新的一个月里，我将认真学习各项政策规章制度，努力使思想觉悟和工作效率全面进入一个新水平，为学院的发展做出更大更多的贡献。同时希望公司的同事经理能继续给予我最大的帮助，我一定不会让大家失望的。
第19篇：实习生个人月工作总结
实习生个人月工作总结
工作总结英文版———附翻译
In October the day flies, as the car sped through the wheel, fleeting.In the twinkling of an eye not to see a half moon to go, who once thought this originally is slow to be like a snail to climb in the summer vacation life.Have something to do is be not of the common sort of feeling.This little emotion half month, the taste is sweet and sour, more bitter and hot, I am said to have a summary, I also live a lot of sweat down from behind the worries.Well, since it is a month or so on, I have this half a month to work under specific reporting.According to the current division of labor, my main task is: (1) the company responsible for training; (2) is responsible for work injury; (3) the office part of the writing and temporary work.Through the completion of the work, made me realize that a competent management personnel should have good language skills, fluent writing skills, strong leadership ability, flexible ability to deal with the problem, effective outreach capacity, large-scale activities planning and preparation ability.In the original company, a lot of work I just tube, most of the work is done, and now personally do, found a lot of seemingly simple work, in fact, there are a lot of skills.I am the first contact property management work, task of the administrator\'s duties do not understand, in order to adapt to the new job and working environment as soon as poible, I should strengthen learning, humbly ask for advice and confusion, to clarify ideas, summarizes the methods of work, has been basically qualified for the job.On the one hand, dry middle school, learn to do, and constantly grasp the method of accumulation of experience.I pay attention to the work of the task for the traction, relying on the work of learning to improve, through observation, exploration, acce to information and practical training, quickly into the work.On the other hand, ask the book, ask a colleague, and constantly enrich the knowledge master skills.At all levels of leadership and colleagues to help guide, never to be, never familiar with the familiar, I gradually find out the basic situation of the work, to find the entry point, grasp the focus and difficulty of the work.In this month\'s time, I will abide by the regulations of the company, dedicated to do the occupation work, never late and leave early this month, with enthusiastic positive, carefully complete each task, earnestly fulfill their duties in life, unity colleagues, and constantly enhance their team spirit.I have a further understanding of their own life, eager to have a breakthrough, I will be in the future work and life to remind myself, so that their future life after the road is more exciting.A review of error and a half years, also, smile, enthusiasm, also have no.Practice is actually a mutual learning proce, the work of the test of me, I have been learning.This internship is a thickening of life experience, a good opportunity to cherish, or do not do, to do it is to do the best I can achieve.So glad to find this internship work itself, although the time is not long, but has made the exercise, in fact the department work summary of how to write, see itself is not enough, in the school things are not used, but a lot of new knowledge to work in the middle school, but also exercise itself in all aspects the ability of
十月份的日子过得飞快，如同马路上疾驶过的车轮子般，转瞬即逝。眨眼间不看就半月去了，谁曾想这原本是慢得如同蜗牛般在爬的暑假生活呢。有事儿做的感觉就是不同凡响。小小感慨下这半来个月，那滋味儿真是又酸又甜，更有苦有辣，咋么说也得总结一个，也不枉我一番汗水下去，免了那抛于脑后之忧。言归正传，既然是月小结麽，那么下面我就具体汇报下这半个月来的工作情况。
根据目前工作分工，我的主要工作任务是:(1)负责公司培训工作;(2)负责工伤工作;(3)办公室部分写作和临时工作。通过完成上述工作，使我认识到一个称职的管理人员应当具有良好的语言表达能力、流畅的文字写作能力、较强的组织领导能力、灵活的处理问题能力、有效的对外联系能力、大型活动的策划及筹备能力。在原来的公司里，很多工作我只是管，大部分工作是手下人在做，现在亲手做，发现很多看似简单的工作，其实里面还有很多技巧。
我是初次接触物业管理工作，对综合管理员的职责任务不甚了解，为了尽快适应新的工作岗位和工作环境，我自觉加强学习，虚心求教释惑，不断理清工作思路，总结工作方法，现已基本胜任本职。一方面，干中学、学中干，不断掌握方法积累经验。我注重以工作任务为牵引，依托工作岗位学习提高，通过观察、摸索、查阅资料和实践锻炼，较快地进入了工作情况。另一方面，问书本、问同事，不断丰富知识掌握技巧。在各级领导和同事的帮助指导下，从不会到会，从不熟悉到熟悉，我逐渐摸清了工作中的基本情况，找到了切入点，把握住了工作重点和难点。在这个月的时间里，我能遵守公司的各项规章制度，兢兢业业做好本职业工作，本月从未迟到早退，用满腔热情积极、认真地完成好每一项任务，认真履行岗位职责，平时生活中团结同事、不断提升自己的团队合作精神。我对自己的人生有了进一步的认识，渴望有所突破的我，将会在以后的工作和生活中时时提醒自己，以便自己以后的人生道路越走越精彩。
回顾半月来，有错误，也有笑容，有热情，也有幸喜。实习其实也就是一个相互学习的过程，工作考验了我，我也得到了学习。这次实习是个加厚人生阅历，值得珍惜的一个好机会.要么就不做，要做就要做到我所能达到的最好。所以很庆幸本身能找到这份实习的工作，固然时间不长，但还是取得了锻炼，事实上部门工作总结怎么写，看清了本身的不够，在学校学的东西都没有用上，不过在工作中学到了不少的新学问，也锻炼了本身的各方面的能力。
第20篇：学生会个人月工作总结
学生会个人月工作总结
学生会三月工作总结
新的一学期，新的开始，本学期我们学院学生会在对上学期工作的总结基础上，吸取过去失败经验，开展本学期的工作。本学期我们学院学生会本着为学生服务的精神，以“顾客第一的服务”理念，从新定位，真正做到“从群众中来，到群众中去”。以下就是我们三月份的工作：
一、从新定位、寻找自身优势，打造自身优势品牌
在3月份开始，我们开始了新一学期的规划及长期规划，通过部长、班级委员会、学生会例会等，对过去的工作进行新的客观评价，进而对本学期的工作进行新的规划。根据各个部门的优势，学院的自身资源，进行资源优化配置。根据学院的自身资源，我们策划了具有管理学院特色的活动，如：管理竞技联盟。
二、班集体制度的修改、制定
学院学生会的工作许多都是在各个班级的配合下完成的，为了进一步加强学风建设，营造优良的育人氛围，促使各班集体之间相互学习、相互竞赛，引导学生以具体行动，满怀激情积极投身到学校学风建设的热潮中，增强班集体的凝聚力，促进良好学风、班风、院风的形成，我们在新的学期开始，在分团委老师的指导下、学生干部的参与、各班班长配合下，完成了《管理学院先进班集体考评制度》的制定。
三、加强学生会内部建设
在3月份，办公室组织各个部门，针对《管理学院学生会工作制度》、《管理学院学生会考评制度》等，进行修改，从而使制度更加人性化。
四、配合学校工作
在学校团委的指导下，本学期我们学院将举办“成都大学首届联合国模拟大赛”，具体负责部门是学习部，他们在本月完成了对该活动策划。学习部在本月还负责了“考研俱乐部”学院的宣传、组织报名。素质拓展中心负责“创业俱乐部”学院的宣传、组织报名。文艺部在本月做了“五四合唱比赛”的准备工作。
五、其他例行活动、工作
本月体育部开始了常例的学院男子、女子联赛，学院的篮球队招新、训练。办公室进行每周的签到常例工作，生活部对寝室进行每月的定期检查。
这就是3月份我们学院的工作，最重要的是学期工作的计划，在这方面，我们是做足了工作，我们相信这一学期我们会走了更好，因为“我们一直在努力”。
学生会干部11月工作总结
时光流逝，不知不觉中进入院学生会这个大家庭已有一个多月了，今年的十一月份特别的寒冷，但我在学生会感受到了家庭的温暖，感受到了大家工作的热情。总结我这一个月的工作，应该是有付出也有收获;有迷惘也有进步。
这个月我主要做了以下工作：参与策划部门内部的干部培训;参与清除校园牛皮癣活动;和xxx来整理了干部诚信档案;与守望者合作张贴关于甲流的爱心小卡片;了解了学生会其他部门的一些情况„„
在这里我特别做出自我检讨，因为没有计划好时间而缺席部门的个系组织部长会议，相信不会再有这样的事情发生.
一个月来我对自己负责的干部培训班的具体相关工作有了一个大致的了解，但在很多方面还不是特别的清楚，在许多细节方面做的还不是很到，比如说组织部长会议就不知道要说些什么，没有充分发挥主观能动性。
在例会和值班方面我觉得做的还可以，每次例会都会准时参加，会用心的听学长学姐的发言，从他们的话语中学习到一些他们工作的方法，为人处事的道理。值班的时候事情不是很多，我很多时候会看看学生会的一些文件，了解以前的学长学姐都做过些什么、怎么做„„
在这一个月里我特别要感谢我的主任xx学姐，谢谢她的指引，她的包容，她的关心，让我更有信心的向前走.运动会送走了活力四射的十一月，希望在接下来的十二月里我可以做的更好.
充实的过好每一天，认真的过好每一天，珍惜在学生会的日子，好好工作，天天向上!
