人月神话

用了一个周末时间，把这本项目管理的巨著读完了，虽首版发行距离现在已有40余年， 但其中的某些观点仍然可用，不得不赞叹 Brooks 教授的伟大之处。跟随作者的讲述，自己对接触和管理的项目做了回顾，好多项目出现的问题，在书中早有预言。所以，只能感叹，是问题不可避免？还是现在的项目管理人员是否真的有能力去做好项目的管理工作、以及是否知道什么是重点、什么是无关紧要的东西（现实的体会，领导和客户的要求成为了所有决策的重要依据）。

下述内容观点均来自书中，加以自己的感悟。其中，最大的感受，给某些观点有了强有力的证据。再和其他人员掰扯时，Brooks 教授成为了强有力的论证。

焦油坑

给我很大的启迪：我们选择让一个人完成一个构想的基础功能很容易，但是想让其演化成通用的工具、乃至产品，投入的成本要比想象大的多，且不可一蹴而就，需要不断的衍变，并非一次性设计而来，当然这个过程中，对于文档的投入也是一个重要的部分。（个人比较坚信：好的架构源于不停地衍变，而非设计）

文章提到了编程行业提供了乐趣、苦恼的说明，也印证了自己的一些想法。其中，对我而言：”面对不重复的任务、持续学习的乐趣“最为贴切。这也是推动我内心 — 多学一点、多付出一些，你就比别人更牛一点的潜在动力（个人认为：开发靠的还是硬实力，长久来看，薪资待遇和能力总会成正比！）。然而，痛苦却句句扎心?，都说到心坎里了~~~

• 将做事方式调整到追求完美是学习编程的最困难部分（我更喜欢说：要优雅，说容易，每个环节做到极其困难，这也就是为啥我们有太多的临时方案，太多的 @fixme 的标识，当然，临时方案最终也就成了最终方案了?）；
• 由其他人来设定目标，并且必须依靠自己无法控制的事物（特别是程序，看别人写的代码，感觉就是一个重生过程，无比的煎熬和痛苦，内心万马奔腾）；权威不等同于责任；
• 任何创造性活动都伴随着枯燥艰苦的劳动，编程也不例外；
• 人们通常期望项目在接近结束时能收敛得快一些，然而，情况却是：越接近完成，收敛得越慢（问题总是出现在项目快要结束的节点上）；
• 产品在即将完成时，总面临着陈旧过时的威胁；只有实际需要时，才会用到最新的设想。（想着要造一艘航母，最后发现一只再拧螺丝钉）

聊到这里，瞅瞅「康威第二定律」

There is never enough time to do something right, but there is always enough time to do it over 「时间再多一件事情也不可能做的完美，但总有时间做完一件事情」

技术在不断进步，我们的实现是否落后成为了开发人员内心一直在衡量的问题。判断是否落后应根据其他已有的系统，而不是未实现的概念（太多的精力被这些新的概念分散，看了 — 忘了 — 再看，一直循环着）。因此，我们所面临的挑战和任务是：在实际的进度和有效的资源范围内，寻找解决实际问题的切实可行方案。(这是第一步)

人月神话

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

相信这句话，大家听过无数次，但是为啥每次遇到这种问题时，大家第一直觉还是要加人呢？

缺乏合理的进度安排是造成项目滞后的最主要原因。在项目落后时，简单的增加人手就像汽油灭火一样，会愈加强烈。因为，人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间可以互相替换。

合理的进度安排 — 问题首先出在程序开发人员天数就是”乐观的“。评估时，往往假想：”一切都将运作良好，每一项任务仅花费她所应该花费的时间“。这其中忽略了，开发本身就是创造性的，有时只有在实现过程中，才能发现我们构思的不完整性和不一致性。 当然，程序开发人员也是“狡辩的”，遇到问题，总是责怪物理介质（它们不顺应设定的思路），使得我们的判断带有了主观主义色彩。

所以，整个工时的评估和划分，我们要考虑到独立子任务（人员不需过多的相互交流，否则培训、沟通将使项带来更多的额外工作），这个才是我们可以增加人手和追赶进度的前提。

书中，提及了进度安排的经验法则：

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

整个安排是多么的完美，但是实际中，我们经常会受限于领导或客户的压迫，由于我们对自己的估计技术不确定性，缺少坚持的勇气，导致无法按法则运行。这些我们也许掰不过，但，此时我们必须要做的是，重新安排进度。

外科手术队伍

优秀的专业开发人员的生产率是较差的开发人员的10倍。

这种现象一直在自己身边发生，所以，自己越来越赞同这句话。与此同时，优秀的同学带来的创造力，给整个团队带来的技术氛围和呈现也不是10个较差同学所能做到的。（当然，不得不承认，有一些任务的确就是体力活，大家的产出率几乎相差无几）

太多的项目总结显示：一拥而上的开发方法是高成本、低效的，同时开发出来的产品也无法从概念上集成（贵公司，18年的标品项目沥沥在目！）

Brooks 教授以外科医生为例：外科医生和副手都了解所有设计和全部的代码，确保了工作概念上的完整性。其他成员根据职能的专业划分。（有带头者，其他人只需按照自己的步伐前进、前进即可）

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

概念完整性是系统设计的重要考虑因素。功能与理解上的复杂程度的比值是系统最终测试标准。（外科医生和助理责任重大啊~~~；现实情况中，产品经理就是一个产品的掌舵者）

画蛇添足

尽早的交流和沟通能使大家有较好的成本意识，同时使开发人员获得设计的信心。
书中提及对结构师建议，现在来看，也是对 leader 的最好建议：

• 牢记开发人员承担创造性的实现责任；结构师只能提建议。（只给建议，不要指手画脚）
• 时刻准备着为所指定的说明建议一种实现的方法，准备接受任何其他可行的方法。
• 对上述建议保持低调和平静。（遇事不惊、都可以心平气和，是一种境界?）
• 准备对建议的改进或放弃。（作为 leader 更应该有大局观和气度）

贯彻执行

来源于自己的真实情况：在我们开发中，UI设计往往会对产品原型提供一些交互上的建议，然而产品原型后续不会持续修改，出现了产品和UI不统一的问题（产品经理会毫无遮拦的说，以产品文档为主），这个导致了大量的回溯和沟通成本。所以重现定义的详细程度和体现应该反馈到原型上去，且详细程度应该和原有说明一致。

产品文档精确比生动更重要。

为什么巴比伦塔会失败

巴比伦塔是人类继诺叶方舟之后的第二大工程，它失败了。失败的原因是什么：没有清晰的目标？人力不足？材料不足？时间不够？技术能力不到？其实，缺乏的是 交流 和 组织。交流的缺乏导致了争辩、沮丧和群体猜忌。（作为 leader，要做好团队外部的向上沟通和水平沟通。）这里，不得不提及一下，「康威第一定律」：

Communication dictates design 「组织沟通方式决定系统设计」

我们太多的精力花费在了交流和沟通上面，然而有些东西却没有结论，还是需要领导出来拍脑袋。所以，减少不必要的沟通（或者说，有效的沟通）依然成为了项目成功的必要因素。

书中，提及了：减少交流的方法是人力划分和限定职责范围。对于开发来说，依附的文档和工具（当然，这里需要做到「贯彻执行」中提交的要求），实时更新也可以减少不必要的沟通的很有效途径。

胸有成竹

实践是最好的老师，但智者还能从其他的地方有所收获。

最近有这样一种感觉：在你的圈子里，你认为这是最好的方案了，胸有成竹、沾沾自喜；但是，这是否是整个行业里的最优方案，值得商榷。格局 — 这个东西太重要了，大多数人都过于安逸和自满了（这就是 「卡耐基」 所谓的人的劣根性吧），但这个带来的是瓶颈和思考、认知的高度。一叶以蔽之，太可怕啦?。

跳出安逸和舒适圈是痛苦的过程，但是带来的新事物、新观点会让你的眼界有极大的提升，当然我认为这也是 心智成熟的旅程。浅水喧闹，深潭无波 — 我必须去往深潭！

削足适履

不能让团队成员作为争取小红花的学生，让大家拥有从系统整体出发以及面向用户的态度是开发管理人员重要的职能。这和下述「祸起萧墙」提到的 “进取对于开发团队来说是必不可缺的必要品德”，是良好的印证。争取小红花 — 整体感觉过于自我（外表）了，进取显得就会更加有力（内在）一些！

数据的表现形式是编程的根本。（这句话好像前后不搭，但是极为准确！自己开发过程中，首选要做的工作就是梳理数据流，这是驱动！）

提纲挈领

早期对一系列文档进行规范化。通过遵循文档开展工作，也能更清晰和快速地设定自己的方向。「为什么巴比伦塔会失败」不就是这些东西吗？文档啊~~ 文档啊~~

未雨绸缪

开发人员交付的是用户满意程度，而不仅仅是实际的产品。

特别喜欢这句话！这就要求我们欣然接受合理的变更，因为变化是与生俱来的，不是不合时宜和令人生厌的异常情况。用户的实际需要和用户感觉会随着程序的构建、测试和使用而变化。

程序员不愿意为设计书写文档，不仅仅是因为惰性，更多的是源于设计人员的踌躇 — 要为自己尝试性的设计决策来进行辩解。（产品经理不愿意写的愿意是啥呢？）

干将莫邪

巧匠因为他的工具而出名（工匠精神）。好的开发团队自然要有自己一套比较完好的工具，用来提高生产力以及生产效率。

这是一个春秋神话传说：干将，春秋时吴国人，是楚国最有名的铁匠，他打造的剑锋利无比。楚王知道了，就命令干将为他铸宝剑。后与其妻莫邪奉命为楚王铸成宝剑两把，一曰干将，一曰莫邪。由于知道楚王性格乖戾，特在将雌剑献与楚王之前，将其雄剑托付其妻传给其子，后果真被楚王所杀。其子成人后成功完成父亲遗愿，将楚王杀死，为父报仇。
此一传说赞颂了剑工高超的技艺，宝剑文字的神采和少年的壮烈，批判了统治者的残暴。

整体部分

许许多多的失败完全源于那些产品未精确定义的地方。文档！文档！

祸起萧墙

一天天的进度落后比起重大灾难更难以识别，更不容易防范和更加难以弥补。慢性进度偏离是士气杀手。（如果你错过了一个最终期限，请确保完成下一个最终期限）

深有体会，我也在自己团队提出了：时间观念（评估工时&截止日期）和效率为先（任人宰割，时间长了我们也就这样了）的主张。时间真的会耗尽一切，是一切变得都无意义！！！

里程碑在项目开发中具有重大意义，具体的、特定的、可度量的事件，且能够进行清晰的定义。里程碑定义的非常准确，无法自欺欺人时，很少有人会就里程碑的进展弄虚作假。

这是需要我们加强的，明确任务、明确期限，可度量、够清晰！

进取对于开发团队来说是必不可缺的必要品德。（记录到这里~~）

另外一面

不了解，就无法真正拥有。

文档能在整个生命周期中克服懒惰和进度的压力起促进和激励作用。又是文档！

整体总结一下： 文档是让大家把握概念上的完整性以及认清目的的必要工具（概念完整的重要性，看上面）；许许多多的失败完全源于那些产品文档中未精确定义的地方；好的文档，可以起到克服懒惰和激励的作用！

没有银弹

复杂的软件工程问题无法靠简单的答案来解决。

看过类似这样的一个观点：为啥前端工程师的工资会比后台的薪资高一些？大家都普遍认为前端上手快，但学深也难，整体要接触的东西随着衍生会变得无比庞大。相对于其他开发来说，前端是一个新兴的行业，且面向的是客户（客户的要求往往是变化的），这就导致了我们不能像其他开发一样，沿用一些成型且稳定的解决方案（当然，这里说的是大部分情况，并不是绝对）。变，因而成了前端的主旋律，同时也带来了怎么顺应变化、且契合变化这样的问题 — 这也就是前端技术每年都有重大变化的根源吧~~~。这个过程中，前端工程师的思维、学习能力便可以体现出来了。所以，前端工程师的工资会比后台的薪资高是有前提的，并不是你浑浑噩噩、懒懒散散也会高。高的点在于，你不断折腾、不断接触新的技术、理念、思维，乃至新的工作和开发方式。

题外话

这里特别想说下 — 架构师，这个岗位，以及自己的一些定义。

先自己定义一下：系统架构的目标是解决利益相关者的关注点。 架构系统前，架构师的首要任务是尽最大可能找出所有利益相关者，业务方，产品经理，客户 / 用户，开发经理，工程师，项目经理，测试人员，运维人员，产品运营人员等等都有可能是利益相关者，架构师要充分和利益相关者沟通，深入理解他们的关注点和痛点，并出架构解决这些关注点。且在每个阶段，找到对应该阶段架构所面临的问题，然后在不断解决这些问题，在这个过程中整个架构会一直演进。然后，探索更好的技术架构，对架构进行抽象。总之，好的架构和设计相关，但更重要的是不断演进、变化！