现实中，我们见过太多匆忙上马的项目。他们有些存在着先天设计缺陷、有些因为操作过程中执行不力而虎头蛇尾，而有些则是根本没有经过完整的或者有效的测试就立即投入生产。这个林林总总的各种现象，最终导致的结果只有一个，那就是项目的部分或者全部失败。而在坐着看来，这些失败都是可以避免，或者可以在某一程度上避免的。
中国有一句古话叫作“凡事预则立，不预则废”。不知道各位在工作当中是否有遇到过这样的场景：随着上峰一声令下，所有部门全都开足马力，唯恐起跑过慢，被他人抢了先机，公司内部如同赛马场上你争我夺，并辔而行，领导如同骑手一般不断挥鞭，好一派奋勇争先、热血沸腾的动人场面。然而激情退却，热血微凉，一番热闹后所取得的效果却也如同马踏之后的竞技场，满地狼藉。
在《人月神话》中，作者对于这种尚未思虑周全就盲目上马或者只顾及自我团队表现而不考虑项目整体效益的行为嗤之以鼻“在系统设计中，概念完整性应该是最重要的考虑因素。也就是说为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改进，也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计。”也就是说在作者看来，任何一个项目都不应该被看作独立的个体，而应该考虑对于整个大环境的兼容性和整合性。你之所以开发新的系统，并不是为了证明你有多卓越，而是为了整个大环境的需求考虑。
正如在上一篇当中所提到的，要考虑到新系统、新项目相对于此前整体环境和进展的兼容性和整合性，这必然不能采用人多嘴杂式的民主表决，概念的完整性要求项目的整体的架构和思路必须由一个专家或者非常少数互有默契的人员来设计和提出。一旦设计实现人员有了模糊设想，对技术有了相对清晰的构思以及拥有了定义良好的成本和目标时，工作就可以开始了。当然工作的开始并不意味着设计人员的职责已经完成，他还需要尽快地确认良好定义的时间和空间目标、设计指责模块的边界、结构以及所有的工具，此外还需要耗费时间和结构师、副手等等进行沟通。随后通过副手、结构师、编辑等人员的共同努力，将这一思路和架构传达到每一个具体的执行人员来执行实现。诚然在实现的过程当中，执行人员的及时反馈是非常重要的，它有助于设计人员及时根据反馈对于设计思路进行必要的调整，但这并不意味着设计人员可以在一开始并没有思路的情况下瞎马临池，而将实现产品功能的重担全部压在执行人员身上，还美其名曰根据现实状况“随机应变”。
在上一篇中我们曾经提到过，对于工作量和工作时间的估算，对于所有的设计者来说都是一个难题。因此我们也在思考一个问题，对于产品的设计，第一次可能因为经验不足出现各类问题和各种错误，第二次会不会比第一次好一些。毕竟我们默认一个人在某个领域的深耕会获得大量的经验，从而有助于他将工作做好。然而《人月神话》的结论却兜头给我们浇了一盆冷水。作者认为第二个系统恰恰是最危险的一个系统。因为在开发第一个系统过程当中，存在很多设计者初衷认为必须的或者说能够增光添彩的摄像，由于时间人力等等的限制，都没有能够实现。而人的执念往往会要求他在第2个系统当中来弥补第1个系统当中的遗憾。可惜的是时过境迁，新系统的应用和目的相较旧的系统本就不同，执着于旧系统当中未实现或者未尽实现的功能，对新系统来说未必是件好事，甚至可能引发灾难。作者还列举了“OS/360”以及“Windows NT”的例子来详细说明了这种执念会造成怎样可怕的后果。其实类似的案例又何尝只在编程界存在呢？近些年有一句非常流行的话，叫做“原生家庭的创伤，终其一生都在治愈”。而在项目管理当中，有些人便是“这一次的遗憾，一定要在下一次就得到弥补”，对于此前项目中的一些缺憾，在新的项目中，无论是否实质性有效都必须强行实施，从而造成项目管理的悲剧。而对于这一执念的“解药”，作者认为应该是对于所有功能和摄像“赋权”，即在项目的初始阶段，就确认各项功能实现所耗费的资源、人力和时间，一旦确定，不会由于某些微不足道的变故而轻易变更。从而可以避免在无关紧要的功能上浪费资源。
但凡在稍具规模的公司工作过的人都有这样的“痛苦回忆”——明明在项目的开始阶段一切都计划的好好的，各部门也都信誓旦旦地要做出一番成就，为什么到后期就如同建造 “巴别塔”一般，初心尽失、不思进取、彼此积怨，即便不至于拆墙挖脚、自毁长城，也是算计无数，各自为政。诸事所涉，就要说到一个老生常谈的问题——组织内部“沟通”。
关于“沟通”这一话题，其深度广度如同浩瀚之海，各类分析文章犹如恒河之沙，这里也不再拾人牙慧老生常谈。请从两个维度来谈一谈《人月神话》中有关沟通同的陈述以及实现的手段——一是项目理念的贯彻、二是项目进展的交流。
所谓项目理念，包括项目的整体思路、设计架构、执行策略等。在《人月神话》中，将这些理念纵向贯彻，从项目组的顶层一直落实到底层，是通过“手册”这一工具来实现。手册、或者书面规格说明，是一个非常必要的工具，它是产品的外部规格说明，它描述和规定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物。而要使手册做到对于理念的准确传达，则需要使用“形式化”（概念精确、描述完整、区分显著）而非“记叙性”的语言对其进行描述。手册的存在，明确了整个项目的最终呈现状态，确保整个团队在统一的目标下前进。否则就如同“天鹅拉车”一般，整个项目中各部分互相掣肘，导致项目难以存进。
而对于项目的“横向”管理（项目-时间），书中提供了另外一个工具——“会议”。书中将“会议”分成两个级别：周例会和年度大会——这实际上是一种非常有效的分层沟通方式。周例会的目的是各部分的提问和建议，最终由首席结构师拍板定夺。要实现周例会的高效，有几点必须加以贯彻执行，一是所有的建议和观点都必须形成书面意见，在会前就让所有与会者知晓，避免在会上“临时加戏”，争论不休。二是讨论必须充分平等，所有参与者都有权充分发表自身看法，以免因为言犹未竟，影响今后会议决议的实施。三是一旦会议达成一致（无论是讨论一致还是首席结构师决定），都必须在会后按照这一决定执行，不得再生事端。如此的周会制度，项目组的主要成员每周聚首一次，可以保证信息的充分沟通，避免重新培训所耗费的时间。还保证相关意见都被及时提出并讨论，同时在第一时间之内达成一致意见并加以贯彻执行。清晰地授予首席结构师决策的权力，也从根本上避免了妥协和拖延。而当周例会无法解决的问题堆积或者这些问题需要更广泛的内外部人员参与时，年度大会也便应运而生。年度大会往往历时数天甚至一至两周，参与的人员除了项目组成员以外，还有更多相关的内外部人士。所有在大会上需要讨论的问题都会在会前装订成册，而每天都会有人汇总当天讨论出的成果，并体现在次日更新的手册当中。如此集中高效汇聚和讨论就是为了彻底解决在项目当中那些难啃的“硬骨头”以及超广泛的跨部门协作而设。
在《人月神话》的篇首，作者曾经根据他丰富的软件开发经验，告诉我们一个法则：“1/3计划-1/6编码-1/4构件测试和早期系统测试-1/4系统测试”，也就是说在作者看来，构建测试和系统测试需要占用整个项目将近一半的时间。而剩下的这一半时间当中又有2/3是用来做前期计划的，真正用来进行编码（外行人或者初学者认为最为重要的部分）的，仅占整个项目大约1/6的时间。
我们曾经发现大量的项目，在前期的设计和实现方面耗费了大量的人力物力，而对于测试的工作却得过且过，最终上线的系统或者方案带着满身的Bug，需要“边工作边治疗”，甚至有些系统因为过多的各类问题推出了历史的舞台。
既然说到测试，测试的最终目的是为了在日后投入生产以后，相关系统和软件能够正常有效的工作。要实现这一目标，我们不如从以下三个维度来看一看如何更高效地进行测试。首当其冲就是测试平台的搭建。随着信息系统化水平的不断的提高，单一系统能够独立正常高效的运行，已经不足以能够满足对于系统开发的需要。新开发的系统能否完全整合到原有的系统当中，也是非常重要的考量标准，因此在搭建测试平台的过程当中，不单单需要搭建测试单一系统所需要的构件、文件和辅助程序，更应该加之一线运行的日常工作系统，作为一个整体来进行考量。其次，由于未来业务或者数据处理的不确定性，在选择测试样本时，也不应只选择此前已经发生过或日常工作范围以内的样本，更应有一定的非法、超限或者超负荷运转的意识进行压力测试。最后一点则是反馈及时，对于测试当中发现的问题，需要及时向开发执行人员进行反馈，以便按照相关的手册和决议进行修正。