《软件管理沉思录》读书笔记

要点

1. 管理你的项目：质量改进是永无终点的旅程，为了交付高质量的产品，我们需要制订和维护计划。
2. 管理你的团队：团队合作会比个人独立表现更出色，我们应该知道如何更好地成为高效团队的一份子，以及如何构建和管理一支高效团队。
3. 管理你的领导：学会和管理者进行商谈，说服你的管理者采用更好的实践。
4. 管理你自己：学会在工作中管理自己的时间，避免拖延，信守承诺，同时作为一名领导者应该以身作则，为团队树立榜样。

书摘

第一部分 管理你的项目

第 1 章 交付高质量的产品

1. 在软件开发过程中，为了保证质量始终如一，必须遵循以下 8 个步骤：
   1. 确立质量控制的策略、目标和计划
   2. 正确训练、指导和支持开发人员及其团队
   3. 确立和维护软件需求的质量管理过程
   4. 确立和维护软件工程过程的统计控制
   5. 审查、检查并评估所有的产品制品
   6. 评估所有缺陷，加以更正并用以识别、纠正和预防其他类似问题
   7. 确立和维护配置管理和变更控制系统
   8. 持续改进开发过程。
2. 软件产品的质量应当被定义为产品对用户的可用性。只有得到了清晰的需求，才可能开发出高质量的程序。
3. 质量是永无终点的旅程，这段质量旅程中的阶段有以下几个：
   • 测试并更正
   • 检查
   • 局部测评
   • 质量到人
   • 个人测评
   • 设计
   • 缺陷预防
   • 基于用户的测评。
4. 目标之所以重要，主要是基于以下两条原因：
   • 提供了努力的焦点
   • 建立了一种优先次序。

第 2 章 为高质量项目制订计划

1. 最难以制订计划的时候，也是最需要计划的时候。当项目团队面临巨大交付压力时，他们一定不能让步，要坚持制订一份计划。
2. 计划分为两种类型：阶段计划和产品计划。由于你的工作将以产品的形式呈现，同时你的生活是以阶段来划分，所以产品计划和阶段计划对你同样重要。
3. 你所有的项目或重要的工作都要制订产品计划，它会帮助你判断完成工作将需要多长时间，以及你会在什么时候完成，还可以帮助你在工作期间追踪过程。一份合格的产品计划应当包括三项内容：
   • 将要生产的产品规格和重要的性能指标
   • 估算工作所需的时间
   • 进度预测。
4. 制订一份详细的计划，并和管理者共同审查它。
5. 计划必须满足的五条基本要求：易于理解、清晰明白、详细具体、精确缜密、准确无误。
6. 若你不能使计划准确无误，那就常作计划。通过动态的计划过程，项目团队可以评估每一项需求变更对项目带来的影响，并且只有在管理者理解并且同意对进度和资源进行必要调整时才进行变更。动态的计划还可以防止需求蔓延。

第二部分 管理你的团队

第 3 章 高效团队的基本要素

1. 团队遇到的七个常见问题：无效的领导、缺乏妥协或合作、缺少参与、拖延和缺乏信心、低劣的质量、功能蔓延、无效的对等评估。
2. 高效团队必备的四个条件：凝聚力、目标、反馈、共同的工作架构。
3. 团队交流的三要素：透明、倾听、协商。
4. 团队的生命周期：
   1. 组建：没有清晰的功能描述和计划，新团队成员比较被动
   2. 动荡：一个十分情绪化的时期，团队通常对于如何展开工作茫无头绪，并且由于面对许多未知因素而感到十分棘手
   3. 规范：团队开始解决问题，他们定下目标、明确角色、决定策略和制订计划
   4. 执行：团队向上级介绍计划，管理者接受后便开始展开工作
5. 三种群体：工作型群体专心于工作，过程型群体专注于内部的动力学，对抗型群体则与外部威胁作斗争。当一支团队的行为像一个过程型群体或对抗型群体时，它是无法有效进行工作的，这时需要仔细检查团队的行为并与成员谈话，试着理解究竟是什么让他们感到烦恼，继而与团队领导者一起直接处理他们的担扰。
6. 自主指导型团队的典型特征：
   • 具有团队感和归属感
   • 共同对团队目标作出承诺
   • 对过程和计划的主人翁意识
   • 具有制定计划的技巧和执行计划的纪律
   • 追求卓越

o 这类团队通常自己设计开发策略、制订计划，并且主动去完成高质量的工作。

第 4 章 做一位高效的团队成员

1. 你是否愿意积极履行承诺，很大程度上取决于做出承诺时的方式。首先，承诺必须是自愿做出的；其次，承诺是公开的；再次，为了做出负责任的承诺，你必须做好准备。
2. 所有的新思想都始自仅有一人的少数派。如果你就是这个人，那么你要对这新思想和项目团队负责。很多情况下，只要你转而要求团队成员解释他们的逻辑，一些全新的观点就可能涌现出来，项目团队可能因此会走向一个完全出乎意料的不同方向。这种现象被称为增效。
3. 要想让团队运行顺畅，每一位成员都应该奉献出他所知道的一切，这一点至关重要。
   • 清楚地表明自己的看法，并且引起工作团队的关注
   • 要注意他人的意见并接受帮助。
4. 团队创建的义务：
   • 作为团队的一员接受责任，并尽你最大能力扮演好你的角色
   • 参与确定团队目标和计划，并努力实现这些目标和计划
   • 建立并维护一支高效和合作的团队
5. 原则式谈判：
   • 参与者——参与者是问题解决者
   • 目标——有效率并友好地达成一个明智的结果
   • 方法——把人和事分开
   • 信任——不谈信任
   • 焦点——关注利益而非立场，探讨利益
   • 底线——避免划定底线
   • 选项——为共赢创造条件
   • 决定——准备多个选项以便从中挑选，稍晚再作决定
   • 标准——坚持客观的标准
   • 意志——试图基于无关意愿的标准达成一个结果
   • 压力——开放辩论，服从原则而非压力
6. 原则式谈判有效的原因：避免了立场的两级分化。原则式谈判的基础：认识到立场只是满足利益的一种方式。

第 5 章 领导和指导你的团队

1. 对于工作团队，有三条最重要的激励因素：恐惧、贪婪、承诺。对开发工作来说，贪婪和恐惧都不是恰当的激励因素。
2. 可信的团队承诺有四条要求：
   • 自愿——请求，而不是命令
   • 可见——公开地协商
   • 可信——用计划来支持
   • 得到承认——团队作出自己的计划
3. 用短期目标制造紧迫感。领导力的挑战之一就是帮助团队成员设置中间目标。
4. 让所有团队成员都参与的技巧：
   • 提问，先别主动说
   • 装聋作哑
   • 频繁地检查约定
   • 感受没有说出口的疑虑或不同意见
   • 不要让某个人完全控制讨论
   • 管理专家
   • 指导团队领导者
   • 关注事实和数据
   • 不允许有旁观者。
5. 让管理人员参与制订决策，鼓励管理团队成员共同工作。
6. 理性管理的四要素：
   • 在确定产品或行动目标时，要检查当前的工作情况，并且根据业务目的确立行动目标
   • 为短期目标制订计划
   • 评估和跟踪计划完成情况，并且监督工作中的纪律执行状况
   • 持续监督业务执行情况

第三部分 管理你的领导

第 6 章 讨论项目并捍卫你的计划

1. 应当首先对工作抱着一种积极的态度，并且真正为了得到一个更加合理的交付日期而努力。
2. 让团队聚焦于优先级最高的事，优先级最高的事就是当前的工作任务。在作任何改变之前，一定要弄清楚这种改变可能会对工作产生什么样的影响。
3. 独断专行的行为效率很低甚至有时会起反作用。单边计划也是一种专制的管理，它很少甚至没有团队的贡献，应该让团队真正参与制订他们自己的计划。
4. 当你的管理者陷身于当前的短期问题时，你必须转而关注一些注重实效的、符合当前实际的措施。

第四部分 管理你自己

第 7 章 控制你的工作

1. 改变工作方式所需的步骤：
   1. 确定质量目标
   2. 衡量产品质量
   3. 理解过程
   4. 调整过程
   5. 应用调整后的过程
   6. 衡量结果
   7. 把结果与目标进行比较
   8. 循环并不断改进
2. 你需要跟踪你的工作时间，养成使用时间日志进行记录的习惯。
3. 软件项目失败的主要原因通常是团队合作问题而不是技术问题，一个严重的“人祸”是软件团队不会处理压力。通过在策略和计划过程中指导项目团队，TSP 展示了团队应当如何处理压力。他们分析工作、研究完成工作的策略、估算他们将要生产的产品的规模，在此基础上制定出计划。
4. 管理承诺：
   • 在同意承诺之前要分析工作
   • 用计划来支持承诺
   • 用书面形式记录下约定
   • 如果出现了不能履行承诺的情况，马上告诉对方并努力把造成的影响最小化

第 8 章 学会领导

1. 领导者要为团队树立榜样。你不可能指望团队成员比你更有责任心、工作更努力或更仔细。
2. 领导力低下的症状：
   • 高层管理者在思考问题时以自我为中心、眼界短视狭隘
   • “官僚惰性”，目前存在的都被认为是合理的，任何的增加或改变想要得到批准都需要付出艰苦的努力
   • 管理者没有能力及时做出有效的决策
   • 某些领导风格太执著于改变，而导致组织永远处于动荡之中
3. 内在激励/变革型领导：设法让员工对目标产生热情，并说服他们跟随你一同去实现它。它与常见的所谓外在激励/交易型领导形成了对比。你的目标必须是成为变革型领导。
4. 作为一名领导者，你的确有一些有限的权力，而你必须决定在哪些地方使用它。尽管你看到的很多问题的确让人厌烦，但要把精力集中在那些真正会影响工作的事项上，而不是抱怨其他人。

作者介绍

Watts S. Humphrey（沃茨·汉弗莱）
ACM 会士，IEEE 终身会士，卡内基—梅隆大学软件工程研究所（SEI）的资深研究员，SEI 软件过程研究奠基人，SEI 软件过程成熟度模型发明人。2005 年被授予由美国总统颁发的美国国家技术奖。他曾在 IBM 工作了长达 27 年，担任技术研发部门副总裁，掌管 IBM 所有软件产品的研发工作。他还是 PSP 和 TSP 先驱。除本书外，汉弗莱还著有包括《TSP：领导开发团队》、《TSP：培训开发团队》在内的 12 本书，这些书在软件管理和过程改进领域非常具有影响力。

William R. Thomas（威廉·托马斯）
SEI 技术交流团队主管，拥有近 30 年的传播、公关以及新闻从业经历，并负责过俄亥俄州扬斯敦和得克萨斯州加尔维斯敦多家报纸的商业和技术版面。