The Mythical Man-Month

《人月神话》是七八年前就被推荐要看的书,但是那个时候对这种月亮啊、神话、科幻类的书籍不是很感兴趣,所以一直没有翻阅(好吧,我只能说这本书的书名太容易误导人了)。很惋惜初做管理时就应该读的书,现在才拜读第一遍,读后意犹未尽,所以又看了《人件》,这篇文章对书的内容和自己的理解做个总结。

人月神话

焦油坑

编程就像是一个许多大型系统和开发人员在其中痛苦挣扎的焦油坑。

但无数人进入这个行业也是因为它还存在着乐趣,这些乐趣包括:创造新事物、创造对他人有用的东西、持续学习、将想象创造为现实,作为领导者可以根据员工的乐趣偏好进行激励。

人月神话

项目滞后的主要原因:

  • 乐观主义。估算出的时间多为假设一切运作良好的情况下的完成时间,但是总有一些意外或者没有想到的事情会发生。
  • 人月。误认为估算的人和月可以互换,将进度与工作量相互混淆。在任务不可分解的情况下,以及需要沟通才能完成的任务中,时间不会随着人员的增多而减少。
  • 软件经理通常不会有耐心持续的估算这项工作。
  • 对进度缺少跟踪和监督。
  • 当意识到进度有偏差时,错误的认为增加人力就能解决问题。

软件进度安排的经验法则:

  • 1/3 计划
  • 1/6 编码
  • 1/4 构件测试和早期系统测试
  • 1/4 系统测试,所有的构件已完成

之前也做过编码两倍的时间来做计划的项目,基本上在计划的时候要做的事情非常细,包括框架的设计、类之间的关系、函数名,甚至连函数的参数和参数名称都定义好。对设计进行评审后才开始变吗,写代码时基本不需要思考,除非出现一些意外设计时没有考虑完全的情况。但是这种开发模式是之前使用 C 语言编程的时候了,后来进入移动时代再没有可能这样开发。

最后,任务不应该由顾客对完成时间紧迫程度来决定,为了在顾客要求的紧迫时间内完成任务,必定会影响质量。开发并推行生产率图表、缺陷率图表、估算规则可以有助于项目经理根据可靠数据来说明强行上线可能带来的风险。

Brooks 法则:向进度落后的项目中增加人手,只会使进度更加落后

外科手术队伍

编程队伍可以借鉴外科手术队伍的人员配置

            外科医生
管理员及其文秘        副手
编辑及其文秘          程序员    
                    工具维护人员
                    测试人员
                    语言专家

贵族专制、民主政治和系统设计

要保证概念的完整性要求设计必须由一个人,或者非常少数互有默契的人员来实现。

公司的一个领导,曾经总是喜欢让所有人参与需求设计,殊不知团队里的很多人觉得自己没有设计的能力,一来能力不够得不到好的效果,大家还觉得觉得劳心劳神,二来参与设计的人太多交流浪费很多时间,并不是所有人需要这种“民主”。

第二个系统的效果

架构师“完美”的设计完一个项目后,估算出的完成时间一般是无法被接受的,这个时候如果要求架构师压缩时间,他们一般会选择采用成本更低的实现方式,更好的选择是让其削减设计。选择削减设计完成第一个版本后,进行第二个版本时,架构师应当注意不要过度设计、画蛇添足。

顺畅沟通

架构师的决策要确保每个人都理解,需要说明文档、会议等。独立的产品测试小组要按照说明文档检查程序,并寻找出软件缺陷。

为什么巴别塔会失败

在实践中得到成功的项目组织架构:

  • 产品负责人和技术主管是同一个人。
  • 产品负责人作为总指挥,技术主管充当其左右手。
  • 技术主管作为总指挥,产品责任人充当其左右手。

清晰的文档,明确的组织架构、合理的职责分配是大型项目成功的保证。

文档假设

软件项目的文档可以记录决策、作为沟通渠道、可以作为数据基础和检查列表
软件项目的文档可以包括

  • 内容:目标
  • 内容:产品技术说明
  • 时间:进度
  • 地点:工作空间分配
  • 人员:组织图

未雨绸缪

唯一不变的只有变化,需求会不断变化,系统架构要适应变化,组织结构也要能适应变化。

磨刀不误砍柴工

作者提供了适合当年的实用工具

整体和部分

开发可用的系统,要尽早引入测试,编写代码之前就应当确认测试规格说明,编码过程中要构建单元测试。

潜在祸患

项目经理应在制定进度时确认里程碑,并定期确认项目进展,及时调整计划、资源

另外一面

程序应该有一份使用说明文档,包括

  • 目的
  • 环境
  • 范围
  • 实现功能和使用的算法
  • “输入-输出”格式
  • 操作指令
  • 选项
  • 运行时间
  • 精度和校验

程序代码可以书写成自文档化的

人件

管理人力资源

技术管理者大多因为良好绩效而被提拔,但是对自己合适的管理方式未必适合他人。

大多数管理者管理的重点是技术的因素而非人的因素,因为管理技术比管理人更简单。

脑力工作和体力工作不同,所以管理方式通常也截然相反。作为管理者应不时问问大家遇到了什么死胡同,并让大家知道最佳答案不是“没有”,应当鼓励他们说出困难,并且鼓励大家犯错;向人施压只能增加短期产出,长远看是无效的。

领导者应当尽力避免让员工加班,为了一个项目让员工不停加班,项目作为基本上所有人都会离职。此外,时间压力只能会降低产品质量。

管理者的作用不是让大家去工作,而是创造环境,让大家可以顺利开展工作。

办公环境

独立且空间较大、安静、较少被打扰的工作环境能使人更好、更快的完成工作

开放式办公环境并不利于工作效率的提高,即使是一起工作的员工也应该将格子间改为共同的小套间。办公环境中应划分出工作去、讨论区、社交区。

正确的人

人们在短时间内很难做出改变,所以一开始就要找到合适的人。

团队成员的离开换用新人要付出很高的成本。

高效团队养成

“团队自毁”的清单

  • 防御式管理
  • 官僚主义
  • 物理分割
  • 时间碎片
  • 牺牲产品质量
  • 伪造截止日期
  • 团伙控制
  • 加班
  • 年度薪酬评审
  • 目标管理法
  • 表彰个别员工的突出成就
  • 任何形式的绩效考核
请我喝汽水儿