2404_87526689的博客

摘要：《理想办公环境设计》探讨如何构建舒适高效的工作空间，指出传统模块化隔间和总体规划的弊端。借鉴Christopher Alexander的"有机秩序"理念，提出通过渐进式发展、设计模式和使用者参与来打造人性化办公环境。文章强调四个关键模式：定制化团队空间、合理窗景设计、适度私密性以及避免单调布局。这些原则旨在平衡个人专注与团队协作，同时创造视觉愉悦的空间，最终提升员工满意度和工作效率。

在创建一个合理的办公环境时，有一些普遍的成功和失败的象征。最明显的成功象征是门。当有足够的门时，员工可以根据不断变化的需求控制噪音和可中断性。而最明显的失败象征则是广播系统。那些为了找到一个人而频繁打断所有人的组织，显示出他们对工作环境的要求完全缺乏敏感度。通过操纵这些象征，你不仅会吸引人们对改善办公环境的关注，还会立即获得相关的好处：人们可以继续他们的工作。但是，要摆脱广播系统并恢复门的存在听起来像是个艰巨的任务。我们是否有能力实施这些改变？

当你开始收集有关工作时间质量的数据时，你的注意力自然会集中在主要的干扰源之一——打进来的电话。一天内接15个电话并不罕见。虽然这看似平常，但由于重新沉浸所需的时间，它可能会耗尽你几乎一整天的时间。当一天结束时，你会纳闷时间都去哪儿了，甚至记不起谁打来电话或为什么。即便有些电话确实重要，它们是否值得打断你的流状态也值得商榷。但是谁能有勇气等待电话铃声响起呢？仅仅是想到这一点就会让你感到紧张。

一个记录流时间而非身体在场时间的任务统计方案可以带来两大显著好处：首先，它使人们的注意力集中在流时间的重要性上。其次，它创建了一个关于有意义时间如何应用于工作的记录。

在专注工作的过程中，人们理想上处于心理学家所谓的“流”状态。“流”是一种深度、几乎冥想式的参与状态。在这种状态下，有一种温和的松驰感，而且个人基本上意识不到时间的流逝：“我开始工作，抬头一看，已经过了三个小时。”

文章探讨了在智力型工作环境中测量生产力的复杂性和挑战。与流水线工作不同，智力工作的生产力难以直接量化，且测量方法需要大量的本地数据收集和内部专业知识。尽管存在困难，文章引用了“吉尔布定律”，强调任何需要量化的东西都可以以某种方式测量，且这种方式优于不测量。文章还讨论了测量生产力对组织的重要性，以及如何通过自我评估和同行评审机制来改进工作表现。最后，文章指出，为了有效利用测量数据，管理层需要确保数据的私密性，避免将其用于对抗员工，从而保持数据收集计划的持续性和有效性。

文章探讨了工作环境质量，特别是噪音水平，对员工工作效率和产品质量的影响。研究表明，认为工作场所足够安静的员工更有可能完成无缺陷的工作。随着噪音水平的增加，这种趋势变得更加明显。例如，在一家噪音评级比平均水平高出22%的公司中，66%的零缺陷工作者报告噪音水平可以接受，而存在缺陷的工作者中只有8%的人持相同观点。此外，文章还提到了人员密度与每人专用面积之间的反比关系，以及噪音与密度的正比关系，强调了在办公环境中为员工提供足够空间以降低噪音和提高工作效率的重要性。最后，文章指出，当办公环境不理想时，员工会寻找躲

近年来，许多组织为了降低成本，倾向于减少办公空间的隐私性和专用性，同时增加噪音水平。这种趋势虽然表面上节省了成本，但实际上可能对员工的工作效率产生负面影响。研究表明，开发人员的工作空间成本仅占其工资的一小部分，而降低办公成本可能会牺牲员工的生产力，这种风险远超过可能的节省。例如，IBM在规划新设施时，通过详细研究员工的工作习惯，确定了每位员工至少需要100平方英尺的专用空间和噪音保护，以确保工作效率。然而，全球范围内，许多员工的工作空间远未达到这一标准，导致大多数员工对工作环境的安静性和隐私性表示不满。因此

他们在相同的物理环境中工作，并共享相同的企业文化。两人表现几乎一致的事实表明，在整个样本中观察到的能力广泛分布可能不适用于单个组织内部：同一组织的两个人往往表现相似。这正是软件先驱哈伦·米尔斯（Harlan Mills）在1981年预测的效果：“尽管程序员之间的生产力差异可以理解，但在软件组织之间也存在10倍的生产力差异。在整个样本中，最佳组织（其代表的平均表现最佳的组织）的工作速度比最差的组织快十倍以上。只需要设计一套固定的基准任务，类似于开发者日常工作中的任务，并观察他们在不同环境下的表现即可。

编程语言：使用COBOL和Fortran等旧语言编码的人与使用Pascal和C等语言的人表现基本相同。高于中位数的一半胜过低于中位数的一半的比例为1.9:1。薪资：样本中的薪资水平差异很大。高于中位数的一半薪资仅比低于中位数的一半多出不到10%，但他们的表现几乎高出了两倍。在任何给定的薪资水平上，表现的差异几乎和整个样本一样广泛。经验年限：拥有十年经验的人并没有比只有两年经验的人表现得更好。因此，例如，样本中较好的一半完成特定工作所需的时间少于另一半的一半；最优秀的人员的表现是最差者的约10倍。

在我们经济的各个领域中，有一个广为流传的观点：“加班是生活的一部分。”这意味着工作量永远无法仅靠正常工作时间来完成。对我们来说，这似乎是一个值得怀疑的说法。确实，在软件行业里，加班是一种常见现象，但该行业能够经历如此繁荣的时期，也表明了软件产品总体上带来的价值远超其成本。那么，为什么不仅是软件行业的从业者，还有其他需要高强度思维工作的专业人士也需要投入大量的额外工作时间呢？一个令人不安的可能性是，加班的目的并非单纯为了增加工作时长，而是试图提升工作的平均质量。

假设除了你当前的职责外，你还被赋予了为你的团队提供空间和服务的责任。这意味着你需要决定每个人的工作环境类型、分配的空间大小以及预算安排。你会如何着手进行呢？你可能会想要研究人们使用空间的方式、所需的桌面空间大小、每天单独工作的时间、与另一人协作的时间等。同时，你也会调查噪音对工作效率的影响，毕竟你的团队成员都是知识型员工——他们需要高度集中精力才能完成工作，而噪音会影响他们的专注度。针对每一种观察到的干扰因素，你都会寻找简单且机械的方法来保护你的员工。

莱特瑞尔（Laetrile）是一种从杏仁核内部的苦杏仁中提取出来的无色液体。在瑞典，这种物质可以在杂货店买到，价格与杏仁提取物相近，并且可以像其他提取物一样用于烘焙。然而，在墨西哥，它被当作能够“治愈”致命癌症的药物出售，每滴售价高达五十美元。当然，它并不能治愈任何疾病。所有证据都表明这是一种残忍的骗局。但是，由于没有其他人提供任何选择，一些晚期患者会选择相信莱特瑞尔推销者的主张，不论这些主张多么荒谬。对于那些绝望的人来说，他们并不会仔细审视证据。莱特瑞尔类似国内当年的中华鳖精。

结果是，你的团队成员有很大的机会获得工作带来的满足感。在一个健康的职场环境中，人们不表现的原因可能是缺乏能力、缺乏自信、以及与项目和其他同事的目标缺乏联系。当一名员工似乎无法完成工作，并且对工作的质量毫不在意时，这是明确的信号表明该员工被工作的难度所压倒。糟糕的估算、无法实现的紧逼工期，会耗尽建设者的精力。即使在罕见的情况下，施加压力是唯一的选项，管理者也不应该是那个施压的人。每个管理者，在他们的职业生涯中至少有一次，不得不处理一个似乎在逃避工作、或似乎没有任何质量标准、或者根本无法完成工作的员工。

20世纪的心理学理论认为，人类的性格主要由少数几个基本本能所主导：生存、自尊、繁衍、领地等。这些本能直接嵌入大脑的“固件”中。我们可以在没有强烈情感的情况下理智地考虑这些本能（就像你现在正在做的那样），但当我们感受到它们时，总会伴随着激情。即使是对这些内在价值的轻微挑战，也可能令人感到不安。每当强烈的情感被激起时，这通常意味着大脑中的某个本能价值受到了威胁。一个缺乏经验的管理者可能会认为工作可以完全不涉及人们的情绪而完成，但如果你有一定的管理经验，你就会知道情况恰恰相反。

理论上讲，生产力意味着在一个小时内完成更多的工作，但在现实中，它往往被误解为在一个小时的工资内榨取更多的产出。这些管理者会用各种手段逼迫和哄骗员工进行长时间工作，强调交付日期的重要性（即使这个日期可能是随意设定的），诱使员工接受几乎不可能完成的时间表，并迫使他们为了达到最后期限而牺牲一切，做任何事情来让员工工作得更长、更辛苦。就像未支付的加班时间对西班牙理论的管理者来说几乎是看不见的一样（他们总是将每周视为40小时，无论人们实际投入了多少时间），欠班时间也是看不见的。然而，不同时讨论这两个方面是说不通的。

管理是一个复杂到难以简单定义的事物，但一位高级管理者曾在伦敦的一次专业会议上用一句话概括了他的全部观点：“管理就是踢屁股。”这等同于认为管理者提供所有的思考，而下属只需执行命令。这样的观念或许适用于汉堡生产，但对于那些依赖大脑而非双手工作的任务来说则不然。每个人都必须保持头脑清醒。虽然踢屁股可以在短期内提高生产力，但从长远来看可能并无益处：没有什么比感觉自己的动机不足，需要老板补充动力更让人沮丧了。

答案可能在于“高科技幻觉”（High-Tech Illusion）的影响：一种普遍存在于科技行业中的信念，即认为自己所处的是一个高度技术化的领域，需要不断追求最新的技术创新。包括在“政治”下的事物如沟通问题、人员配置问题、对老板或客户的不满、缺乏动力和高流动率等，实际上都与工作的人际关系方面有关，有另一个更加精确的术语来描述这些问题即：项目的社会学。如果你发现自己专注于技术而非社会学，那你就像一个滑稽剧角色，在黑暗的街道上丢失了他的钥匙，却在旁边的街道上寻找，因为他解释说：“那里的光线更好。

如果说艺术通过色彩、线条和旋律将人类内心深处的梦想具象化，使之成为可以感知的视觉或听觉作品，那么计算机程序则是在数字世界中以逻辑和算法为画笔，描绘着创作者的构思与愿望。编程是实现这一过程的语言和工具，它让那些抽象的概念得以在电子设备上运行，转化为实际的应用和服务。程序=算法+数据结构，这一公式，是由计算机科学家尼古拉斯·沃思（Niklaus Wirth）在其著作中提出的经典观点。它简洁而深刻地概括了编程的核心要素，即程序的本质是算法与数据结构的结合。

人件》（Peopleware）是由Tom DeMarco和Timothy Lister合著的一部经典作品，自1987年初次出版以来，便在软件管理和项目管理领域树立了标杆。该书以独特的视角探讨了团队协作、工作环境以及企业文化对软件开发效率的影响，强调了“人”这一因素在科技项目中的核心地位。与Frederick P. Brooks Jr.的《人月神话》一起，《人件》被誉为软件管理领域的“双子星”，两者均对行业实践产生了不可磨灭的影响。

他虽然能够维持表面的秩序和程序，却未能深入理解业务的本质，未能激发团队的潜力，未能推动真正的改进与创新。结果证明，我的选择既是正确的，也是错误的。的确，一个优秀的管理者确实可以在任何环境中进行管理，他在管理方面表现得相当不错：严格执行规章制度，确保人们遵守流程，进行绩效评估，制定发展计划，跟踪结果——他无疑胜任这个角色。我需要的是一个对我们现有生产力感到不满的人，一个对我们的质量水平感到不悦的人，一个对车间员工很少被晋升到更高职位感到困扰的人。（伟大的领导者大多是后天造就的，而不是天生的。

重读章节链接概要半个世纪以来，《人月神话》经久不衰，在面对大型软件项目管理中的挑战，特别是如何解决概念完整性以及管理复杂性等问题，Brooks博士通过本书提供了具有洞察力的见解，既有很多发人深省的观点，也有软件工程的实践。《人月神话》作为软件领域的传奇经典，值得每一位软件人员仔细阅读研究品味，本章作为总结的篇章，读者试着对书中的知识点进行归纳总结。

没有银弹》("No Silver Bullet")在这篇文章中，Brooks探讨了为什么在当时看来并没有一个单一的方法或技术（即所谓的“银弹”）可以解决所有软件开发中的问题，并且他预测在未来十年内也不会出现这样的方法。再论《没有银弹》提醒我们，面对软件开发中的难题时应保持谨慎乐观的态度，认识到没有任何一种解决方案能适用于所有情况。相反，我们应该继续探索多方面的小幅改进，并结合具体场景选择最合适的方法来应对挑战。存在着银弹－就在这里？《人月神话》一文因其深刻的见解而广受认可，几乎无人质疑其核心论点。

软件开发的核心挑战在于构建一个由复杂的抽象概念组成的结构，这要求开发者不仅能够准确捕捉和表达这些抽象的逻辑实体，而且还需要在现实的物理和技术限制内将它们转换成计算机可以执行的指令。

给出所有输入/输出的具体格式标准。

此外，还有不可预见的天气变化、紧急任务的插入、个人突发事件、与客户的紧急沟通需求以及管理层的临时审查——这些因素无一不在悄悄消耗着宝贵的时间资源。尽管每次看起来只是半天或一天的小耽误，但日积月累之下，整个项目的推进速度开始逐渐放缓，直到落后于最初的计划安排。同样，在软件开发中，进取心也是不可或缺的。尽管PERT技术要求对每个事件进行三次估计，以考虑不同可能性下的完成时间，但这额外的工作量是为了获得更加精确的计划。然而，这种做法却隐藏了一个潜在的问题：所有的问题都被掩盖在地毯之下，而没有得到及时的曝光。

实际上，有效的调试实践建议，每两小时的终端调试应配以相同时间的桌面工作，包括整理日志、分析异常和准备下一阶段的测试计划。通过这种方式，自顶向下的设计帮助保持了设计的清晰度和模块的独立性，从而降低了系统级别的bug风险。，一个复杂的软件系统不仅仅是其各个部分的简单叠加，系统的行为和性能受到各个部分之间交互的影响，这些交互往往是非线性的，难以预测的。测试规格说明的实践也至关重要。系统集成调试是软件开发过程中一个关键且复杂的环节，它不仅考验开发者的技能，还需要一套完备的系统化方法来确保调试过程的有效性和效率。

首先，个性化工具阻碍了团队内部的沟通与协作，因为每个成员使用的工具不同，难以实现标准化的工作流程。项目经理应当制定相应的策略，为通用工具的开发分配资源，同时也要认识到专业工具的重要性，不应对此类工具的投资过于吝啬。通过早期的性能测试，团队可以及时调整设计，确保最终产品的质量和稳定性。在过去的十年里，虽然高级语言和交互式编程这两种系统编程工具并未得到广泛的应用，但它们的重要性日益凸显。：尽管有人认为高级语言无法完成复杂的任务，但实际上，只要投入足够的时间和精力，几乎所有的任务都可以用高级语言实现。

因此，随着时间的推移，系统需要经历彻底的重新设计，以适应不断变化的环境和需求。作者提到了社会性的障碍，比如管理层对高级人员的过度保护，以及管理职位带来的额外威信，这些都会阻碍团队的有效协作。另一方面，“不可见性”指的是软件不像硬件那样有形，它的结构、逻辑和工作原理对于非专业人士来说难以直观理解，这也增加了沟通和管理上的难度。阶段化的变更管理同样至关重要，每个软件产品都应具有明确的版本编号，每个版本应设定具体的时间表和变更冻结日期，以此来界定哪些变更是当前版本范围内的，哪些则应留待下一版本处理。

只有从一开始就充分认识到这些文档的重要性和普遍适用性，便能够将其作为一种有用的工具来运用，而非视作一项枯燥乏味的任务。正因为项目经理的基本职责是使每个人都向 着相同的方向前进，所以他的主要工作是沟通，而不是做出决定。不论项目的规模如何小，项目经理聪明的做法都是：立刻正式生成若干文档作为自己的数据基础，哪怕这些迷你文档非常简单。书写 这项活动需要上百次的细小决定，正是由于它们的存在，人们才能从令人迷惑的现象中得到 清晰、确定的策略。通过周期性的回顾，他能清楚 项目所处的状态，以及哪些需要重点进行更改和调整。

因此，程序设计人员需要精心策划用户可选功能的颗粒度，以便既能满足个性化需求，又能有效控制软件的体积与成本。例如， IBM APL 交互式软件系统，它的租金为每月 400 美金，在使用时，它至少占用 160K 字节的内存。技艺改进的结果往往是战略上的突破，而不仅仅是技巧上的提高。这种战略上突破有时是一种新的算法，如快速傅立叶变换，或者是将比较算法的复杂度从 n^2降低到 n log n。程序的空间开销，即其占用的内存大小，是衡量软件成本的重要因素之一。程序的大小，包括代码大小和内存占用的大小。

使用高级语言可以显著提高生产力，但无论使用何种语言，系统编程的生产率都相对较低，尤其是在涉及大量交互和复杂控制逻辑的情况下。因此，在进行项目估计时，需要全面考虑各个阶段的工作量，并留有足够的缓冲时间以应对不可预见的问题。在复杂程度这片“沼泽”上的指导原则是：编译器的复杂度是批处理程序的三倍，操作系统复杂度是编译器的三倍。在 Bell 实验室，Harr 发现控制程序的生产率为 600 指令/人年，而语言翻译程序的生产率为 2200 指令/人年。将程序员的生产效率量化到指令/年，是一个过时的好方法吗？

团队组织的目的是减少不必要交流和合作的数量，因此良好的团队组织是解决上述交流问题的关键措施。实际上，树状结构反映了权力和责任的分配，但沟通结构更加网状，不受此限制。在小型团队中，一人身兼多职较为常见，但在大型项目中，这几乎不可能实现，因为同时具备管理和技术能力的人才稀缺，且每个角色都需要全职投入。工作手册的本质并未改变，仍是项目文档的集合，但分发机制和查询方法的改进有助于提升工作效率。沟通和由此产生的组织是成功的关键，管理者必须重视沟通和组织技能的培养，正如重视软件技术的发展一样。

正如《System360 Principles of Operation》中的附录所示，它精确地规定了System/360的兼容性边界，定义了兼容性的标准，描述了预期目标，并列举了由于不同模型间的差异而导致的变化点以及不变项，甚至包括了因工程变更而引起的细微差别。年度大会则是在手册定稿前举行的为期两周的会议，涵盖了所有关键人员，旨在审查并解决长期积累的问题，通过每日更新的手册来反映会议成果，确保每个人都参与到决策过程中，从而加深对决策背后复杂考量的理解。敏捷开发中每天的站会，恰是此种场景的最新发展与应用。

此时，我们很容易因为对已有成果的信心而陷入过度自信的陷阱，从而忽视了最初的设计理念和目标。：为每个小功能分配一个具体的值，例如每次改进的功能 X 不得超过 M 字节的内存和 N 微秒的时间消耗。第二个系统：这是最危险的阶段，结构师倾向于过度设计，加入许多在第一个系统中被推迟的功能和想法，结果往往成为一个臃肿的“大馅饼”。第三个及后续系统：随着经验积累，结构师能够更好地识别出通用特性以及经验中的不足之处，从而做出更合理的设计。709：作为 704 的升级版，设计上过于丰富，导致仅一半的操作被实际使用。

对于不同的系统类型（如编程环境、编译器或控制系统），这些文档的形式会有所不同，但其目的都是为了让用户能够顺利完成自己的工作。例如，虽然某些语言如 Mooers 的 TRAC 或 Algol 68 可以通过较少的基本概念达到简洁的效果，但由于其组合规则过于复杂，使得实际使用变得困难。然而，与大教堂不同的是，大多数软件系统在构建时并未花费如此长时间，但其内部的概念差异和不一致性却往往超出预期。因此，为了实现概念完整性，即使某些特性可能带来功能上的改进，但如果它们破坏了整体的一致性，也应慎重考虑是否纳入系统。

在软件工程项目管理中，经常面临这样一个两难选择：一方面，小型且精干的团队被认为能够更有效地协同工作，从而实现更高的生产力与更好的成果质量；相比之下，在外科手术团队中，成员间的角色定位更为清晰。一方面，原有的开发队伍不是理想的小型强有力的团队，因为通常的共识是不超过 10 个人，而该团队规模如此之大，至少需要两层的管理，或者说大约 5 名管理人员。需要协作沟通的人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流，以及更正沟通不当所引起的不良结果（系统调试）。首先，分解技术依然是必不可少的。

理想情况下人员数量与时间消耗之间的关系，即随着投入人力的增加，项目所需时间呈现递减趋势，这在割小麦或收获棉花的工作中是可行的；在本章中作者揭示了这种想法的误区。随着项目的推进，外部环境的变化可能会要求计划进行相应的调整，这就需要管理者具备灵活应变的能力，及时作出必要的修正以保证项目顺利进行。在单纯的数字上，这个等式是成立的，但有点软件开发常识的人都知道这个等式是不成立的，因为有太多不确定的因素在公式的背后。当发现进度落后时，通常的做法是增加更多的人力，然而，如前所述，这并不总是最有效的解决方案。

编程系统是多个能够相互协作的程序集合。要将一个简单的程序转变为编程产品，需要付出更多努力——包括详尽的测试和完备的文档。根据经验数据，相同功能的编程产品的成本至少是已经过测试的程序的三倍。在整个的软件开发过程中，“编程系统产品”才是真正的目标，也是最具价值的产品形态。当你将一个个看似无关紧要的小模块拼凑起来，见证它们如何巧妙地协同运作，达到预期的效果时，那份惊喜与激动丝毫不亚于观看一场精彩的魔术表演。编程系统产品的开发不仅涉及编码，还包括全面的设计、严格的测试以及详尽的文档，确保最终产品既可靠又易于维护。

半个世纪以来，《人月神话》经久不衰，Brooks博士为人们管理复杂项目提供了最具洞察力的见解，既有很多发人深省的观点，又有大量软件工程的实践。今天，让我们再次翻开这本书，结合自身在实际项目中的经历，重新审视那些曾经让我们眼前一亮的观点，看看它们是如何在现实世界中落地生根的。即便计算机领域已飞速发展了几十年，硬件越来越快、网络愈发迅捷、计算与存储资源日益丰富，再加上无数优秀的重用库、完善的框架、便捷的语言以及先进的思想等，这些都远超我们的想象。很多时候，辛辛苦苦开发出来的软件并不能真正打动用户的心。