前言
《软件管理沉思录》是一本介绍SEI项目管理、人际沟通和团队协作的要诀。不论读者是软件开发者抑或是管理者，都能够从这本书中挖掘到价值。笔者是一位软件开工作新人，初读此书惊讶地发现，很多观点笔者早已意识到，却没有形成系统和完整的认知，这本书作了很好的总结，可以帮助形成自己的工作风格和开发习惯。
第1章 交付高质量的产品
软件质量对开发成本、发布日期和用户满意度都有影响。软件质量是如此重要，因此我们需要首先讨论质量究竟是指什么，软件产品的质量应当被定义为产品对用户的有用性。因此，如果一件产品提供了对用户而言是最重要的功能，那么这就是高质量的产品。
笔者认为，软件质量不仅仅可以定义为产品对用户的有用性，也是被定义为是对开发者的价值评判。虽然笔者没有参与过很多实际项目开发，但是课程设计倒是不少，深感程序的质量对开发者的重要性。如果这是一次投入了时间与精力、设计精良、开发有序的编程，最终经过课程老师或者助教的验收，被评为质量优秀的作品，那么笔者会觉得十分欣慰，相反，若一款漏洞百出、不服标准的产品是出自自己之手，或者出于自己团队之手，那么笔者会倍感失落，自信心也会被打击。
有一些人错误地把软件缺陷当作漏洞。当我们提到bug时，脑子里想到的是一些拍拍打打就能除去的、让人讨厌的小东西，有时甚至是可以被忽略的。这会让人们把一个危急的问题视为无足轻重，并助长了一种错误的对待态度......与漏洞相比，缺陷更像是定时炸弹，尽管不是所有的缺陷都会带来爆炸性影响，但是有一些缺陷的确会。
bug可能只是程序上的漏洞，经过测试和评审的重重检查就能被定位和修复，然而软件的缺陷却不是无足轻重的东西，软件缺陷可能是程序上的问题，可能是设计时的不足，甚至有可能是需求时就犯下的错误，软件缺陷是真真切切影响到用户体验的方面，而用户体验则又是软件质量的重要评判手段之一，所以为了交付更高质量的软件产品，我们不能够无视缺陷，应该在需求开发、体系架构设计、程序设计等各个阶段做好缺陷分析，评测可能的缺陷。
第2章 为高质量项目制定计划
本书的第二章着重强调计划的重要性，其实制定合理有效的计划这一观念贯穿了本书始终，不论是开发人员个人在进行软件开发之前需要做详细的计划安排，团队合作之前也需要制定成员们都认可的计划，这是形成高效团队的条件之一。
目标对个人来说十分有用。有一点几乎勿庸置疑：没有目标就不可能去努力。没有目标，所有的努力似乎都是没有意义的，是在浪费时间。毕竟，如果努力不能让你达到任何目的，为什么还要费力呢？因此，目标与最终目的有关，并且这个目的一定是你真正想要达到的某个位置或某种状态。目标可以是减肥、得到更高的分数或者交付产品，但它们都明确地提供了努力的目的。
目标之所以重要，主要是基于以下两条原因：他们提供了努力的焦点，而且建立了一种优先次序。如果没有一个清晰的、得到一致认可的目标，开发人员很难能高标准地完成工作。而如果有了一个明确的目标，你就知道了什么是要做的，同时还有了清晰的工作方向。
计划分为两种类型。第一种是基于时间段的计划，这个时间段可以是日历上的任何一个片段，阶段计划关心这一段时间内你真被如何利用时间。第二种是基于行动的计划，比如开发一个程序或撰写一份报告，产品可能是有形的，也可能是无形的。
你所有的项目或重要的工作都要制定产品计划，如写一个程序、阅读一本教科书或者准备一份报告，产品计划会帮助你判断完成工作将需要多长时间，以及你会在什么时候完成，计划还可以帮助你在工作期间追踪过程。
在本章中，作者先是介绍了目标的重要性，目标可以作为我们工作的驱动，有助于我们更高效地完成任务，并提出了目标的两种模式；此外作者还提出了我们可以为重要的工作都制定计划，产品计划可以作为之后日程计划的标准，划分为阶段性的任务和计划，此外还能有效地帮助我们跟进任务，对比预计与实际进程的差别，为之后的计划调准做好准备。
第3章 高效团队的基本要素
凝胶型团队是指紧密联系在一起的一个群体，其密切程度使他们作为一个整体时迸发的力量超过了其组成部分之和。这种团队的效率要比人员构成相同、但没有形成凝胶型团队的群体大得多。同样重要的是，凝胶型团队的成员从他们工作中获得的快乐，要比一般想象中工作本身赋予的快乐更多。
对于凝胶型团队来说，目标同样是不可或缺的一个元素，首先，这些目标必须是明确的和可量化的。研究表明，具有量化目标的团队总是要比没有量化目标的团队有效率的多。可量化的目标包括详细的计划、功能目标、质量要求、进程里程碑。同时，团队中的每一个成员都必须把这些目标当作他自己的目标。其次，团队的目标必须代表一种意义重大的挑战。这种挑战对于团队的每个人都要意义非凡。
第4章 做一位高效的团队成员
这一章对笔者的启发最大，也为日后正式步入IT公司、成为团队成员作出了提示。
这支团队会去做任何需要做的事情而不用要求和指示......每个人都进入阴冷黑暗的地下室把笨重的设备搬到安全的地方。所有人都满身泥浆，但设备无一受损......由于必须有人在那里全时值守，这是一件很艰巨的任务，然而每个人都争着去。
作者在这一篇文章中描述了自己所在的团队十分团结，哪怕团队的工作环境特别恶劣，但是团队成员都恪尽职守。笔者认为，以后的工作生涯不可能存在单人完成某个项目开发的情况，我们会被融入到大大小小的各种团队中，想要融入团队，就需要把自己奉献给团队，将自己视为团队的一分子，团队的责任就是自己的责任，这才能将自己真正融入到团队中去，整个团队才是融洽而高效的。
其实如果你的观点有说服力，并且你认为团队并没有那么认真考虑它，那么就别轻易屈从了，记住，所有的新思想都始自仅有一人的少数派。如果你就是这个人，那么你要对这新思想和项目团队负责，只要你转而要求团队成员解释他们的逻辑，一些全新的观点就可能涌现出来，项目团队可能因此会走向一个完全出乎意料的不同方向。
在顺利融入团队之后，团队开发逐步稳定，然而团队开发中的创新可能要比个人开发的创新困难不少。若是个人开发，或者以自己为主导的小规模团队中，自己有了某些创新的观念，可以迅速加以验证并实现，然而在人数有规模、管理有层次的团队开发中，你的创新观念可能会受到其他成员或者管理者的反对，因为采用保守的观念总是符合管理者们都可控的理解，他们不想因为实践新方法而造成工期延后等问题，然而，若你并不是空泛地谈创新观念，而是加以实践，并详细地解释自己的逻辑，更容易被大家接受。
实际上，破坏性或不合作的行为通常都是做给团队的其余成员看的，因此团队本身也许就是唯一能处理这个问题的人。 经验证明，团队中如果有一个人不务正业的话，就会影响其他所有人的表现。事实上，剔除不履行职责的团队成员通常会提升团队的整体变现。
笔者对于团队破坏者的危害深有体会，在某一次的课程设计中，笔者担任团队队长，不同于之前课设中的功能需求开发，这次我们面临的需求是全新的非功能需求实现，本次大作业中使用的框架和技术是全新的，大家都颇有兴趣，然而团队中一位比我们更有经验的学长却表现出了低迷的态度，不愿配合、不愿开会、不愿完成分配的任务等等一度将组队气氛降至冰点，团队开发停滞不前，在我们与他积极沟通无果后，将他剔除了开发组，将剩余的开发任务细致地落实到个人，并详细安排了开发计划，最后交付了高质量的产品。
第5章 领导和指导你的团队
另外一个有用的技巧就是注意观察不同意见。虽然有些员工在他们有不同意见时会直言不讳，但也有一些人是通过表情或非言语的信号暗示他们有异议，如皱眉、远离桌子或者举止紧张不安等。虽然这些信号通常十分隐蔽，不过如果你仔细观察的话，差不多总是能察觉到。毕竟，它们是真实的信号，且本意就是让他人察觉到，因此仅仅通过安静成员的举止你就可以辨别什么时候他们有不同意见。
这一点，笔者作为学生深有体会。老师这个职业应该是最具备这种技巧的。老师在为同学讲解难题时，经常会出现这种情况，某些同学有自己的思路或者独特的解决方案，但碍于羞涩，不敢直接举手发言，但这是老师往往能发现这类同学的一些细节，比如眼睛会紧紧盯着老师、嘴唇张开想说话等等，之后就会请这些同学发表自己的观点。管理者也需要掌握老师的这种观察团队成员的技巧，有效的判别安静的成员是否想要表达自己的意见。
第6章 讨论项目并捍卫你的计划
这一章主要讨论了软件开发人员应该如何与管理者交流。可以指导我们日后与管理者、领导者的沟通交流。作者认为，如果管理者作出了不合乎常理的决策(例如过早的交付日期、削减日常管理开支)，开发人员应该据理力争；如果软件开发人员发现了某些问题，与其直接向管理者汇报问题，不如自己先尝试解决这个问题，管理者希望听到的是解决方案而不是问题本身。
如果你认为日程进度将会比管理者预期的要长，不要在此时就与他发生争辩。你还没有充分的事实和论据来帮助你赢得这场争论，这只会向管理者表明你没有一个端正的工作态度。如果管理者认为你意在证明他们的时间是错误的，他们将不会让你制定计划。记住，他们不相信你能给他们一个符合实际的日期，毕竟大家都知道，没有人能在项目完成之前就制订出符合实际的日期进度，凭什么你会是例外？所以应当首先对工作抱着一种积极的态度，并且真正为了得到一个更佳的交付日期而努力。首先，要付出真诚的努力，然后，为得到的日期据理力争。
通过削减日常管理开支，管理者同时也会取消支持人员，因为用于这些支持人员的资金正是管理经费预算之中。或许代价最大同时也是最令人头痛的就是，在这种既精干又吝啬的组织中，所有工程师不得不建立和维护他们的个人开发环境。如果支持不足的话，工程师就只能花费一小半的时间和精力用于完成工作任务，而完成任务才是培训和雇佣他们的目的。
管理者想得到的是解决办法，而不是问题。管理者通常都会很忙，他们有很多问题要处理。如果你带给管理者的是又一桩问题，可以想象，他们会避之唯恐不及。相反，如果你表示可以提供帮助，那么迎接你的可能就是热情的双臂。
第7章 控制你的工作
成功者赢得胜利，他们决不抱怨。正是那些永远失败的人才会抱怨人生的不公以及别人该如何为自己的失败负责。虽然软件开发的确是一个富有挑战性的行业，总是要面对紧迫的日程进度、不断更改的需求，但这些问题都是能够管理的。
单纯的衡量不会产生改进，单纯的努力也不会，你的工作方式在很大程度上决定了你所得到的结果。如果依然沿用旧的工作方式，你无疑将得到和以前一样的结果。确定质量目标；衡量产品质量；理解过程；调整过程；应用调整后的过程；衡量结果；将结果与目标进行比较；循环并不断改进
不妨提前考虑一下，当你最终退休时，什么样的人生才是你满意的，我的建议是，做过什么会比当过什么给人更多满足感。例如你打算投身工程事业，你很可能具有当建造者的天分。你或许会建构系统或组件，乃至创立方法或过程，不过，无论你建立的是什么，质量都是关键，从粗心大意的工作中你几乎得不到什么满足感，即使没有别人发现，你自己也知道你的工作是粗陋的，这会摧毁你的工作自豪感，也会减少你的人生满意度。
