饭饭TXT >
学习管理 >
《第八个管理》作者：罗叶明【完结】 >
第八个管理.txt
16结论
------------
知识时代的管理学盲点
------------
知识时代的管理学盲点
不是行为科学、心理学及人事管理学没有随着环境的转变而提升，它们或多或少也涉及到了一些如何管理智力工作者的问题。但上述学说都存在一个根本缺陷，即没有一套完整的管理理念来衔接智力成果与实体限制(如时间和成本的限制)。如果不把实体限制加插在内，管理智力工作者的方法(如智力工作者的自行时间管理以增加效率；智力工作者的情绪管理以增加EQ)是有的。但在很多智力工作环境中，实体限制确实经常出现，比如在一个分工明确的IT团队中，每个队员都需要在某个特定的时间递交某项智力成果，否则就会影响整个团队的项目进度，进而影响最终成果。我曾与上百个智力工作管理人员讨论过管理蓝领与管理智力工作者的区别，发现他们差不多全都明白两者的区别，也有不少人已经采用了一些特别为智力工作者而设的人事管理方法。但当他们要控制时间和成本的时候，他们却只懂得一个解决办法，就是工业时代的控制模式。究其原因，现时全球管理学的著作，在不受实体限制的范围内，不乏以人为本的理论(如行为理论、人际关系理论、团队动态，工业心理学等等)，但若要满足实体限制的范畴，则仅有工业时代的基于“物”假设的控制模式。
史蒂芬·柯维（Stephen R. Covey）是国际知名的领导学权威，他在他的《高效能人士的第八个习惯》中指出，一个时代的发展取决于它的思维模式，当前人类社会已由工业时代逐步过渡到知识时代，然而工业时代所形成的以“物”为中心的思维套路至今依然根深蒂固。在工业社会，工人遵循严谨的工序去工作，他们可以轻易地被替换，甚至被机器代替。在这种环境下，因为被利用的主要是人的体力或手脚的分工，拥有智慧的人也被降低到如机器般“物”的层级。由于工业时代主要的资产以及经济繁荣的主要推动力是机器和资本，使得我们迄今的会计制度仍是“人是支出，机器是资产”。但是对智力产业如软件产业来说，人才是最大的资产。柯维指出，最大的问题是今天的智力工作管理人员至今仍不能摆脱工业时代的管理思维模式，还是以工业时代的“物”化管理方式来对待智力工作者。
作家约翰·加德纳（John Gardner）曾经说过:“大多数有问题的组织是因为滋生了一种功能性的盲目，看不到自己的缺点。它们的症结并不在于无法解决问题，而是根本看不见问题。” 在我职业生涯的早期，由于受到工业时代管理思想的束缚，我一直以实体时间、实体传递以及实体成果来管理软件活动，却不明白这些与脑力时间、智力传递以及智力成果之间的关系。我很侥幸在后来能够分辨出管理学上的这个盲点。但现今全球数以百万计的智力工作者，仍然看不到这个盲点，还是走入如史蒂芬·柯维说的“由上到下的共同依赖的螺旋”。
------------
盲点对软件管理发展的影响
------------
盲点对软件管理发展的影响
工业时代的管理思想，深深地影响了全球的文明国家，我在这里只谈及美日两个国家的软件管理，主要是因为这两个国家与软件管理的发展史有密切关系。我并不是说其他国家没有用工业生产管理模式来管理他们的软件生产。
目前全球先进国家的管理人才，受的都是工业时代管理的训练。而在20世纪六七十年代，在软件产业的初期，许多软件机构的高层本来出身于硬件业，因而他们着重实体管理，甚至工厂式管理。在60年代，美国软件科学家大多认可NATO研究小组提议的软件工程概念，即认为软件开发规律同工程一样。而日本的软件科学家多认可软件管理如同工厂的概念。但美国软件科学家及工作者对软件工程的概念其实十分含糊，不但有很不同的理解和方法，执行时纸上规律和实际行动也大大脱节。但日本的软件工厂的概念则比较清晰和明确，执行也比较严格。其主要理念就是运用管理工厂的方式来管理软件生产。日本在工业上有质量管理的优良传统，当软件业成为日本计算机的主要产业时，他们就尝试把质量技术与软件工程联系起来，这两者结合的结果就产生了软件工厂。它曾经给日本带来了一些优势，尤其是在软件再用及成本控制方面。但是其问题（以对实体的方式管理智力工作者）也逐渐暴露出来，这导致日本至今关于软件业发展的论文在世界主流杂志上几乎沉寂。
而美国的情况则与日本有些不同，美国在软件工程上没有日本软件工厂那样规范化和纪律化。有不少美国人称软件开发者为“牛仔”，并称软件开发是“黑法术”。在没有真正明白应怎样规范软件生产之前，由于不严格执行纪律却能够减少无谓的压抑，这令美国软件业在创造能力及新科技的采纳能力上都比日本有一定的优势。但由于美国还没有系统性地解决智力协调及智力成果的管理问题，美国的软件开发成本仍然很高，而大型软件开发的失败率在这25年间也居高不下。
------------
盲点对软件工程科技发展的影响
------------
盲点对软件工程科技发展的影响
错误的管理学，也导致美国这20多年的软件工程研究走错了方向。例如Halstead与McCabe开始了软件质与量的量度，但根本上，软件是与创造能力（活的）有关的，故美国在这方面发展了20多年，所产生出来的技术不但没有被广泛采用，相反那些已采用的技术也慢慢停用。在需求工程研究方面，美国发明过100多个需求语言，但至今最常用的仍然是英文，其他的几乎被完全淘汰。美国管理学说:“不能量度，便不能管理”。在实践中，如果你问十个有经验的软件主管: “写需求是一页纸好或一千页纸好?”你会得到很不同的答案，可见理论和实践是严重脱节的。总括来说，在这20多年间，由于走错方向，美国软件工程科技实验的多，但成功的少，突破更近乎于零。
要想知道怎样克服这个错误，就必须先明白走错方向与没有走错方向的软件工程研究的分别及美国为什么迟迟不能改正这个错误。在软件工程科技的发展史上，很多软件科学家如Halstead与McCabe用很多心思去研究，都得不到成功的结果。相反，Fagan在1975年发明了软件检视（software inspection）方法，该方法简单到不能再简单，只是减低人为的错误；30年后的今天，这种方法仍为人采用。其主要分别是Fagan对“人”，而Halstead与McCabe是对“物”。如果你翻看Halstead的原著《软件科学的要素——1977》（Elements of Software Science—1977）及Fagan 1976年在IBM系统杂志上的软件检视的文章，你会发现两人所费的时间和心思有天渊之别。但Halstead的研究走错了方向，越做越复杂，最后得不到成功的结果。对“物”可以凭理论，但对“人”必须凭经验。美国大部分软件工程科学家，只有极少的实践经验，即使有部分从事研究的科学家出身于软件/IT工业，但由于他们的实际经验缺乏深度和广度，所以提出的理论也不切合实际和不具代表性。像Frederic Brooks 那样能够先集科技及管理于一身，继而在极少有的大型项目 （OS360） 中广泛地吸取实践经验，然后将经验的心得上升为理论的软件工程科学家，在美国是绝无仅有的。如果在20年前美国有计划地培养一批像Frederic Brooks 那样的科学家，情况可能会和今天不一样，但美国政府当年没有这样做。
------------
简化的八类管理问题
------------
简化的八类管理问题
美国每年出版超过1000本有关管理学的书，但是真有那么多新的理念和新的实践报告发表吗？问题在于不同的管理方法在不同的环境下适应程度不同，而效率也不同。要辨析为何现时的管理学对智力团队（如软件开发团队）的管理是低效率的，就必须从我们所熟知的管理问题开始，逐步分析我们不理解的管理问题。因此，我特别选择了八类管理问题，有助于读者更容易地理解。
由于一般人只熟悉实体之间的相互依赖，却不熟悉智力活动的输出连带性，而绝大部分的问题，是集合了实体和智力活动，人们却把问题全部当作实体问题来解决，令解决智力活动问题的意识不足。为了能让读者更清晰地了解智力活动问题的独特性，我特别简化了以下问题，尽量减少它与实体的大数量等问题的混淆，以使读者更容易理解:
1. 跑步竞赛，一个人跑得快，主要是个人的意志及体力的成果。个人的纪律和自行管理是有的，但团队和生产管理则近乎于零。
2. 工厂生产线管理，带领工人准时、不超过预算支出并保证质量地完成生产，主要是团队和生产管理的成果，个人的纪律和自行管理是有的，但是比较轻微。
3. 足球竞赛，打得好是队员个人意志、体力及技巧的成果，也是团队集体意志及体能协调的成果，个人自行管理及团队管理同样重要，但生产管理则近乎于零。
4. 一个人画画或写诗，作品好主要是个人的意志及脑力的成果，成本及期限通常都不用来量度画师或诗人的能力，个人的纪律和自行管理是有的，但十分轻微，团队及生产管理则近乎于零。
5. 一个学生为完成作业写软件，需求简单，一般学生都能明白。如果能及时交功课并且得高分，主要是个人意志及脑力的成果，个人的纪律和自行管理是有的，但团队及生产管理则近乎于零。
6. 一软件开发员有足够的专业知识，可自己决定需求来写软件，但这个软件写成后必须由他在不同环境来测试，完成后更必须长期维护及继续开发下一个版本。成功地完成此事，个人自行管理及生产管理同样重要，但团队管理则近乎于零。
7. 一软件开发员没有足够的专业知识，要由另一个有足够专业知识的分析员来写需求，而那个分析员也要明白三个不同工作范畴的用户的需求才可写总需求。但这个软件只是为一次商业操作而写，写成后只需在一个环境来测试，完成后无需长期维护及继续开发下一个版本。成功地完成这件事，个人自行管理及团队管理是同样重要的，而团队管理一定要包括智力传递、智力协调以及智力成果的管理；生产管理是有的，但比重不及前两者高。
8. 一软件开发团队包括分析人员和开发人员，他们要根据不同工作范畴的用户组的需求来写软件，这些软件写成后还要由另一班人在不同环境来测试，完成后这个软件还必须长期维护并继续开发下一个版本。这个问题与第6及第7个问题的不同在于它对智力团队管理和生产管理的要求很高，若不借助后面将要描述的第8个管理（8thManage）来解决，其可预测性及可扩大性便达不到预期效果。这类问题，最典型的是当团队的人数达到20人左右时就开始出乱子。
以上第1至第5个问题，我称之为传统管理学问题，因为跑步竞赛、工厂生产、足球竞赛、画画写诗都已有很久的历史，一般人对它们也颇有认识。至于第6至第8个问题，我将其列入商用软件带来的新管理问题。至于我为什么把第5个（学生写软件）问题加入传统管理学问题，而不是商用软件带来的新管理问题，随后有详细的解释。
------------
明白这八类问题的重要性
------------
明白这八类问题的重要性
在学习的过程中，不论聪明人还是普通人，起初都会通过模仿来学习，但学习的结果却并不相同： （1） 有些人能青出于蓝，甚至完全创新理论； （2）有些人学的技巧娴熟，能在不同情况下把技能施展出来，但不能完全创新； （3）有些人学到最后也只会死记死跟，根本无法领悟其中的道理，当环境转变了就不能变通，技能也施展不出来。
在美国的大企业，你通常会看到想升职的人首先是模仿他们的上司。事实上，以自己的上司来做学习对象是聪明的选择，因为上司一般来说是成功的例子，下属也比较容易观察到他的行为及成果。但最大的差别是有些人看问题看得不深，只能学到上司表面上的东西，而学不到他最重要的东西——解决问题的技能。只学到表面上的东西，在比较简单的情况下（如各人或各小队已经一起运作了一段时间，他们已能各守各的岗位，而团队中没有什么大的利益冲突，整个项目的时间和资源也不是十分紧张），大家只是需要一个形式上的协调者或领导者，这是可以的。但如果情况有大的转变（如主要的合并、大型的商业流程整理或时间与资源都极度紧张的项目），只懂得在表面上做功夫而管理智慧并不高的领导者，便没有办法带领下属解决问题而被别人视为无能。最好笑的是有些人在大企业中通过模仿他们的上司得到上司的欢心而升职，当他们升到上司的位置，仍继续以同样的方式进行管理。因为情况同上述一样比较简单而固定，这些人便错误地认为自己有管理天赋，也有足够的经验。但当他们换到另一种环境，问题便陆续浮现而无法解决了。因此不知道自己不懂什么，即使有时间，有学习机会，都难以进步。
为了便于读者理解，本章采用了简化的方式来形容这八类问题，但它们是极具代表性的。从中读者可以领悟到在不同的情况下，不同的管理方法有不同的比重。最重要的是开始明白到，成果的可见性和产品在完成后的连续性及改变性 （长期维护及继续改进）对管理的重大影响。
------------
体力/实体与智力的定义
------------
体力/实体与智力（Physical vs. Mental）的定义
一般读者都知道体力活动和智力活动的分别。我唯一想指出的是两者有互相包含的关系，一般说来，体力活动中包含智力活动，而智力活动也包含体力活动，所以，我们说“体力活动”是以体力为主导的活动，而“智力活动”是以智力为主导的活动。
一项智力活动可以只有智力成果（智力工作者的构思），也可以有一个智力成果及一个实体成果（把智力工作者的构思写在纸上）。举个例子，Ａ君为甲企业构思一个收购乙企业的计划，这个活动会有一个智力成果（Ａ的构思）及一个实体成果（Ａ君写的计划书），在简单情况下，取得Ａ君所写的计划书，已经可以执行，因为缺少的细节及变通可以猜测出来。在复杂情况下，取得Ａ君所写的计划书是无法执行的，因为许多细节及变通是无法猜测的，但它们会影响执行结果的成败。这就是智力成果及其传递隐性的一面，而这隐性知识只存在于智力工作者的头脑中。
事实上，智力传递的困难程度远比实体传递高数倍、十倍、百倍、千倍，甚至万倍。以传递商业应用软件需求为例子，除非在很简单的情况下，一般用家都不会完全清楚自己要的是什么及所要的东西是否有真正的成本效益；即使他们能清楚自己要的是什么及所需要的东西有真正的成本效益，也不代表他们有能力把复杂的需求清晰地表达出来；即使他们能把复杂的需求清晰地表达出来，也不代表接收者能不混乱并且完全明白；即使接收者能不混乱并且完全明白，也不代表双方能在实际设计之前，把全部细节都拟定出来，而这些细节是可以影响需求决定的；即使他们双方能把全部细节都拟定，也不代表他们没有受到脑力发挥的局限，能征服及控制这复杂的过程而令应用软件真正地满足其需求。因此，实体传递和智力传递最大的区别是: （1）智力成果多数要经过数次的重复过程及反复的交递及接收。（2）智力成果交递完成之后对相关活动及成果的连带性具有影响力；如果它在成功交递完成以后，影响到其相关的活动及成果不成功的话，这个传递的成功只是一时表于形式的错觉。
智力工作者的智力传递工作过程难以直接监控，成果难以衡量，使这方面的管理变得具有不确定性；控制这些繁复细节的最佳方式是通过相关的智力工作者来完成，而管理智力工作者的人员，只有通过有相称性的承诺管理来间接管理他们，使他们能够在既定的目标和自我管理的心态下,自主地完成任务，实现知识转移，包括以各种形态存在的显性知识和存在于人头脑中的隐性知识，这才是对人的有效管理方法。
以上有关实体传递及智力传递的定义仅限于本书并适用于软件管理。在其他领域如Roger Schank的语义网络（Semantic Network）概念里的实体传递及智力传递的定义，与我所阐述的观点有所区别，其用途是自然语言识别，而非软件管理。
------------
八类管理的基本不同之处(图)
------------
八类管理的基本不同之处
表2-1是以体力活动、智力活动、实体协调、智力协调、团队管理（动机管理及冲突解决）及生产管理（时间、资源、产量及质量的管理）来分析这八类问题，它主要是以“重要”及“轻微”来区分每一类管理问题中的体力或智力活动、实体或智力协调、团队管理及生产管理的重要性。空白并等于完全没有，只不过是非常轻微而不值得在此提及的意思。以画画为例子，画画是智力活动，但画家也要把纸墨放好才可画画，因而非常轻微的实体协调是有的。此外，成本和期限通常都不用来量度画师的能力，但接受报酬的画师是要如期交货的，因而在某些情况下，轻微的生产管理还是有的。
表2-1八类问题的分析划分维度
划分维度
案例
体力
活动
智力
活动
实体
协调
智力
协调
团队管理
（动机冲突）
生产管理
（期限成本）
跑步竞赛: 个人赛
重要
工厂生产
重要
重要
重要
重要
足球竞赛
重要
轻微
重要
轻微
重要
画画写诗: 一人
重要
学生软件: 一人作业
重要
轻微
商用软件: 一人开发及维护
重要
重要
轻微
重要
重要
商用软件: 数人需求、一人开发、无须维护
重要
轻微
重要
重要
重要
商用软件: 数人需求、团队开发、长期维护
重要
重要
重要
重要
重要
------------
软件管理与传统管理的区别
------------
软件管理与传统管理的区别
画画和写软件虽然都是脑力活动，但其成果的可见性、缺陷的浮现情况及作品完成后所需的维护是很不同的。首先，当一幅画画完的时候，画家以及懂得这类画的人可以清楚地看到这幅画，但软件的可见性与画很不同，即使看者很有经验，甚至是原作者自己，都不容易一目了然。其次，画画是不可能画了一条看不见的千年虫，暗藏在画中，到若干年后它才跑出来咬人。画里难看到的瑕疵是有的，但绝不会隔一段时间后会跑出来搞破坏。软件则很不同，除了简单的程序外，一般软件都有暗藏着的毛病（英语叫bugs，是虫的意思），这些暗藏的毛病有多少、在什么情况下会浮现出来以及浮现的时候其破坏程度是否严重,这些问题都存在不确定性。因此，由于两者成果的可见性及缺陷的显现情况不同，所牵涉的管理问题，包括怎样去看进度、怎样去看缺点及怎样去验收等，当然也有很大的不同。
在作品完成后，第四类问题和第六类问题也有一个很重大的区别，那就是作品和作者的关系。一般情况下，当画家画完画签了名后，便可和作品分开，不再需要维护这幅画。但商用软件的情况却很不同，有很多商用软件的原作者开始时要自己亲自维护并改进软件，后来即使培训了别人来维护，数年后也有可能接到咨询电话，问他软件是否会在这种情况下出现问题或可否这样改动而不会有不良后果。由于软件需要长期维护，而维护工作也需要原作者的知识，便引出以下的管理问题:
1. 软件商如何管理由原作者到维护者的知识移交，需要什么及多少文件，需要的时间及资源是多少，与现时商业的限制是否符合，怎样才能知道移交成功与否（因为不成功是会严重影响客户的）。
2. 原作者及维护者的自行管理。需要什么及多少文件，需要什么形式及多少的培训，需要的时间及资源是多少，与现时公司的限制是否符合，怎样才知道移交成功与否（因为不成功会严重影响到两人日后的工作）。
3. 如果是重要的任务系统,买家要在选择软件商时确定它有足够的知识和经验去维护以及它过去有一定的维护声誉。如果该重要任务系统是特别为顾客而造的（不是大众产品），在签约的时候要确定原作者会维护一个时期或起码做维护者的顾问等等。
4. 软件商如何管理客户报告的毛病（bug），怎样才知道客户的报告所指出的东西是否真正是毛病，损害的严重性有多大，什么时候通知客户及怎样和客户在解决问题上达成共识，怎样把问题通知其他有可能遇到相似问题的客户，需要多少时间及资源才可把问题解决，怎样把修补软件送到客户手中。
5. 维护者应在考查问题、提议解决方案及解决问题的时候，都要有一定的自律及自行管理，但在此不详述。
第四类和第六类问题还有一个很大的差别，就是在完成作品后的改进。越是成功的软件作品，越有很多不同的用户组加入使用，便越会有很多不同的新需求，因而不断改进是成功软件的重要一环。当然，不同产业或不同性质的企业，可能接受的软件改动程度是不同的，如嵌入式软件必须跟随硬件版本的更替；股票交易所的系统需要高度的可靠性，不能每月都接受新软件。但就算有某些产业或企业能接受改动较慢、较少，也不等于他们购买发布后便不再改进软件。在很多情况下,由于产品在完成后是需要连续维护及改进的，因此产品同公司维护与改进的财力、维护者及改进者都有一定关系。这也引出对购买软件产权或软件公司的不同管理，如果你购买一批书，你只要找识货的人验货便可。但你如果购买一个软件产权或一家软件公司，你除了找懂得那类软件的人去看软件，你更要看那里的工作人员以及留住人才的策略。有很多软件，如果你收购到产品但留不住人才，那软件会变得无法改进，甚至得不到维护。
------------
软件培训不足的地方
------------
软件培训不足的地方
为什么我在前面比较第四类问题和第六类问题而不是第四类问题和第五类问题呢？原因很简单，第五类虽与第六类同是写作软件，但从管理角度来看，一个学生写软件交功课给老师所需要的管理与一个接受报酬的画师要如期交货差不多，而与第六类（个人写商用软件）已有很大不同，与第七类及第八类的距离，就更不用说了，可谓有天渊之别。对于前面提到的可见性及可量度性，第五类和第四类有些相似，而与第六类则很不相同。原因是教授在设计作业课题的时候，他必须把课题设计得让学生做出来的作业成果是可见的及可量度的，那样他才可以公平地给学生成绩，不然连他自己由学生交作业至出成绩前也无法看清学生们的作业成果，他又怎能公平地给学生分数呢？
我对美国的大学及研究院比较熟悉，因此在这里所说的是我25年在美国所见到的情况。美国许多大学生，他们的学期作业要写一个完整的操作系统或同等复杂的软件。如果提高复杂程度，学生是很难写完的。问题并不是所培训的特殊软件领域如人工智能（Artifical Intelligence）或操作系统的复杂程度不足，而是从个人纪律及管理角度来说，第五类与第六类（即使是一人写的商用软件）已有很大差别。有很多大学让学生以团队方式去写作业，这个趋势是值得鼓励的。但要明白它的成效不会很大，原因是它只针对在明白需求以后及反复测试之前的协调，对于怎样去应付以下的复杂情况，在理论与实践上并没有教授:
1. 由于需求的智力传递的复杂性所带来的管理问题；
2. 由于测试的实体协调的复杂性所带来的管理问题（测试也有一定复杂程度的智力协调）；
3. 由于低可见性和低可量度性所带来的管理问题；
4. 由于长期维护所带来的管理问题；
5. 由于软件的高改进率及高改变性所带来的管理问题。
在以上的分析中，我也不需要用个人及团队来区分学生作业软件与商用软件，第六类是一个人写的商用软件，其复杂程度与学生受的训练是大不相同的。
------------
了解软件战场的困难
------------
了解软件战场的困难
在起初十年的软件/IT职业生涯里，我在美国最好的软件机构，与美国最好的软件科学家及管理人员一起工作，并有机会参与和管理世界上最大型的软件开发项目。那个时候以为自己知道软件战场应该是怎样管理的，因为需要看的书已看过，好的实践机会也已经得到。由于我懂得争取，还有数位十分有经验而且十分聪明的人肯辅导我，做我的顾问。但后来我才发觉，书本中不但没有一套完整的软件战场管理理论，而且错误地引导我把注意力、精力放在比重不是最高的地方。实际的战场经验才是最有用的，但由于缺乏理论基础，实践者往往各施其法，得到的也只是混乱的经验（缺乏系统性及可重复性）。肯辅导我的人，由于他们本身受工业时代管理思想的束缚，只能教我一些实体战场的管理，再加一点对智力工作者的人事管理。在这种情况下，学习当然困难。
不了解软件战场，并没有给我在美国的软件/IT职业前途造成负面的影响。相反，我在Perkin Elmer工作四年被提升了三次，每次都被委以更重大的软件管理任务。1990年，我更以九年半的经验出任当时全球第二大计算机公司（DEC）最重要的项目（OSF/1）的主管。我后来苦苦思索原因，其实道理十分简单，由于管理学的盲点及软件工程缺乏相应的理论，我遇到的困难别人也会遇到，但他们中的绝大部分都没有我所争取到的大型项目实践以及被极有经验的人辅导的机会，因此他们一般比我更不了解软件战场的困难。
------------
战事行军或工厂生产与软件战场有什么区别
------------
战事行军或工厂生产与软件战场有什么区别
战事行军，保证粮草用完之前带领数百士兵准时且不走失地到达目的地，主要是团队、资源及时间管理的成果。工厂管理，带领数百工人准时、不超过预算支出以及保证质量地完成生产，也是团队、资源及时间管理的成果。表面看来，由于行军并没有生产出什么，有些人会认为行军并没有生产管理的成分。但从另一个角度去看，行军要生产里数，而在质量方面，起码要注意走失士兵的数目，而他们的可见性及可量度性也与工厂生产相似。
至于软件战场和以上两种战场比较，除了上一章所说的目标明确性（需求传递十分复杂）及完成之后的连续性（长期维护及改进）很不同外，它们还有以下的主要差别：
（1） 人的管理--大型软件团队，可由数百到数千人一起同为一个项目工作，因而在人数上与行军打仗或工厂生产相似。但工人的生产率差异及可替换性与前者却有天壤之别。最重要的差别是软件/IT活动有些时候需要个别工作者创新或自由发挥，而有些时候只需要工作者遵循步骤去做；但战事行军或工厂管理，所有对创造力的要求只集中于领导者或设计流程步骤的人，工人则不需要自由发挥，只要求跟着严谨的步骤去做即可。
（2） 活动的管理--软件的生产要求准时、不超过预算并能达到预期的质量要求，这些与战事行军及工厂生产没有区别。但软件活动管理必须包括实体传递及成果管理和智力传递及成果管理，它的活动管理与战事行军及工厂生产只需实体传递及成果管理很不同。如果错误地把战事行军及工厂生产管理用于软件开发上（这是今天的实际情形），最大的问题并不是少了一半以上的管理，而是错误地把实体管理等同于全部管理，从而导致进度幻觉。在软件项目开发中我们常常碰到这样的情况，起初我们的软件开发完成了70％或者80％，甚至是90％，但突然有一天我们会发现，需要增加一倍的钱和时间才能完成。
------------
足球赛场与软件战场有什么区别
------------
足球赛场与软件战场有什么区别
从人的管理角度来说，与软件战场最相似的不是工厂生产线, 不是军队战场，也不是一群人写诗或作画，而是一队七人或十一人的足球比赛。看到这里，有些人会觉得大的软件/IT项目或机构的人数有时是成百上千的,这与工厂及军队的人数相似，但足球队的人数太少了，应该不太相似。也有人会认为写软件主要是脑力活动，与一群人写诗或作画相似，其他的是体力活动，不太相似。为什么我说软件战场会和足球队的比赛相似呢? 这是因为两者都有较强的“自由发挥”、“输出连带”及“整体成败的影响”。一家工厂的工人，他们一般是跟着已定好的工序去做，需要自由发挥的机会很少；一个工人做错了会影响到他所工作的生产线，但多数情况下不会影响到全部生产线，所以因为一个工人做错而导致整个生产失败的机率非常之小。一个士兵在战场上，要在个人冲刺、战斗及逃生的时候自由发挥，他的行动会影响到其他士兵的行动，但不致影响到整个军队中所有士兵的行动，他的个人成败也极少会影响到整个战役的成败。一个足球运动员在比赛的时候，要根据他的角色及当时的情况而自由发挥。因为他要与人配合，因此他的行动（尤其是在控制球时）往住会影响到整队的行动，而他个人的成败也会直接影响到整队的成败。在一个软件开发战场，绝大部分的工作，如写需求、设计及编码，都可以自由发挥。而一个表面看来简单的需求，可使整个设计及编码改变。一个人看不准或不小心所写出来的软件，可使整个系统变慢、停顿甚至崩溃。
我用球队比赛来形容软件战场，用意并不是教人用管理球队的方式来管理软件/IT团队。只是因为我知道一般人都不明白软件战场，因此我用它来举一个一般人较容易引发联想的例子。
写软件主要是脑力工作，为什么它又不十分像一群人作诗画画呢？作诗画画的确都是脑力工作，但多数作者是各做自己的作品，输出连带性不高，需要团队工作的程度很轻微；但软件开发既是脑力工作也是团队工作，而且这两者同等重要。从个人纪律及自行管理的角度来看，接受报酬的画师当然也要如期交货，但一般来说，作诗画画对时间并不十分敏感（对时间的要求不是很严格）。但这情况对软件开发员或足球队员来说却很不同，他们在软件开发或足球竞赛中都要求对时间非常敏感。
------------
软件战场与其他智力工作战场的共同之处
------------
软件战场与其他智力工作战场的共同之处
由于工作者的实体时间（如在办公室时间）会影响其脑力时间，管理软件工作者或其他的智力工作者（如律师、投资银行家）都要管理他们的实体时间，而他们工资的多少，也多数是依照他们的实体时间来计算的。由于一个工作者的实体时间和他的脑力时间可有很大的差距，管理软件工作者或其他智力工作者也都要管理他们的智力成果。如果单看实体时间，人可以装得很忙碌地在工作，但其实是在想其他东西，他做私人工作，甚至玩游戏。需要指出的是： 在大部分情况之下，软件工作者或其他的智力工作者的实体时间是要管理的，不管理或不适当管理智力工作者的实体时间会对他们的智力成果有负面影响。举一个例子，软件工作和很多的智力工作都需要人与人的沟通，而人与人的沟通是需要实体时间的。如果一个软件工作者或其他的智力工作者是毫无实体时间纪律的，别人就难以和他有足够的沟通。另一方面, 由于有些软件工作或其他的智力工作的确可以不在办公室里完成，对自律性好的工作者的实体时间管理，可以不像工厂里那样严格；但对自律性差的工作者的实体时间管理，还是严格一点好，因为人的纪律（指实体时间纪律）是会影响他的脑力时间的。
在智力成果没有完成之前，管理软件工作者或其他的智力工作者的同时也应管理智力传递（交付和接收）。智力工作的传递与实体工作很不同，举一个例子，交付和接收一件家具，一般都可以一次完成，交付和接收都很清楚。但在软件/IT及其他的智力工作环境中，智力工作者把某事（特别是某些复杂的内容，如需求、设计、战略等）传递给另一位智力工作者时，这种传递包括了实体传递和智力传递两方面的传达。这一动作经常需要数次的相互作用和更改才可完成。管理这类复杂的智力传递，（由于当今管理学的基础是实体管理） 现时最通行的办法是管理一次实体传递及交付和接收的确认。但问题是一般智力工作者通常不具有足够的知识在一次传递中便能清楚交付和接收（当然也不敢说他们没有这个能力），因而常常接收了复杂的需求或复杂的外包计划而到后来说需求或计划不清楚，没法执行。
软件开发及其他很多的智力工作都需要准时并且不超过预算（受实体时间及成本的限制）, 而智力工作的成果是受智力工作者的个人动机及脑力时间和团队的沟通协调能力所支配的，因此智力工作的时间及资源的估计，必须有智力工作者的参与，甚至由智力工作者自己决定。但当智力工作者对所需的时间和资源作出了满意估计后，他必须作出承诺要准时并且在预算内完成。因此软件开发或其他的智力工作行业需要严谨的承诺管理，还需要一个长期的承诺成果记忆系统（corporate memory），以分辨出有的智力工作者能对自己的能力作出准确的评估，在执行时也懂得自行管理，令自己的承诺常常能兑现；而另一些智力工作者不能对自己的能力作出准确的评估，在执行时也不懂得自行管理，从而使承诺常常不能兑现。
------------
软件战场的独特之处
------------
软件战场的独特之处
如果把软件战场所有的特性（如以上所说的实体传递、智力传递、输出的连带性、产品可见性、产品的继续维护及改进）分开来逐个看，那么，没有一个特性是其他战场完全不具备的。但如果将软件战场和其他战场来做比较，软件战场最独特的地方是在创造力及团体协调的需求方面差别很大，因而导致纯实体的管理办法时而完全不发挥作用，时而则运作得很成功。有些软件战场，是研发下一代的新科技和产品，对创造的需求极高，而对智力成果管理的需求也高，故这类战场如果用纯智力成果管理办法来管理，获胜的机会则大。有些战场，是做政府或商业的自动化工作，对创造的需求主要是在流程改进的部分，其他工作是以翻译为主（由一种知识的表示法变成另一种知识的表示法），虽然也包括创造能力，但要求不高。这类战场如果用纯实体管理的办法来管理，有时可以，有时则不可以。有一些战场是做系统或软件集成的，其集成需求可以很简单，但也可以很复杂；集成设计当然有其可创造的地方，但其他绝大部分的活动所需要的创造能力不会很高。这类战场如果用纯实体的管理办法来管理，时而适宜，有时却不适宜。还有一些战场，如数据中心及网络中心的运作管理，有些人错误地把它们当作软件战场，其实它们的运作只需要工作者跟着严谨的步骤去做即可，并不需要工作者创新或自由发挥。这类战场的管理应以实体成果管理为主，甚至可以说，这类战场已经十分接近工厂管理了。
在同一类软件战场中，由于对创造及团体协调的需求不同，管理也大相径庭。以软件开发为例，开发一个能取替Windows及UNIX/Linux的下一代操作系统与开发一个医院病人挂号及离退系统对创造及团体协调的需求是有很大分别的，其偏向实体成果管理的程度也很不同。开发一个下一代的操作系统，由于复杂程度极高，需求及设计的可预测性差不多全要依赖人的承诺管理，因此，整个战场的管理，是以智力协调、智力成果管理为主。但医院病人挂号及离退系统不同，由于复杂程度不高，先例也多，工作者也易替换，故只使用纯实体成果来管理这项目，成功率也会很高。举一个例子--建立一个呼叫中心。虽然建立一个呼叫中心也包括开发呼叫中心软件，但一般建立一个呼叫中心的项目差不多全是实体管理。如果有些人由于建立一个呼叫中心与软件开发或软件管理有关，因而认为大体上不能用实体成果管理方法来处理，这就错了。
在同一个软件项目里，不同的活动对创造及团体协调的需求，亦可以有很大差别。以开发一个大型交易系统为例，它的需求及设计活动的管理，由于复杂程度高，其管理应以智力成果管理为主（但不要忘记智力成果管理也包括实体成果管理），而它的测试活动（尤其是最后期的市场测试），则偏重实体成果的管理。
由于软件战场内部有以上所述的各种不同之处，使受实体成果训练出来的管理人员，有时见到加强实体成果管理很具实效，就更相信实体成果管理可行于软件管理，却完全忽略了寻找新的方法来管理软件战场。
------------
解决问题的能力
------------
解决问题的能力
人的高矮肥瘦不会相差数十倍，人在工厂的劳动能力，也不容易相差数十倍，但人解决问题的能力，是可以相差很大的，甚至可有天壤之别。有些人有经验、才智、信心和毅力，他们可以促使一些似乎不可能实现的事情发生。有些人有经验和才智，却没有信心和毅力，亦可能贪图安逸，既怕辛苦又怕失败，往往只是看着事情发生或改变。有些人没有相应的知识、经验和才智，当复杂的事情发生时，他们会茫然不知。当然，怎样看待问题亦会大大地影响人解决问题的能力。如果一个人只看见很多很多的问题而不懂得把问题进行分析和组织，那么在他的脑海里只会存在很多问题并且感觉困难重重，甚至觉得问题会越来越多，越来越复杂，永远也解决不完。如果一个人能有层次地分析问题，便有机会指出重点并归纳其解决办法，再加上他的执行能力，便可以集合不同的人，有秩序地解决问题。
