软件开发项目管理-如何赶超美国印度软件(编辑修改稿)

软件开发项目管理-如何赶超美国印度软件(编辑修改稿)内容摘要：

把复杂的需求 清晰地表达出来；即使他们能把复杂的需求清晰地表达出来，也不代表接收者能不混乱并且完全明白；即使接收者能不混乱并且完全明白，也不代表双方能在实践设计之前，把全部细节都拟定出来，而这些细节是可以影响需求决定的；即使他们双方能把全部细节都拟定，也不代表他们没有受到脑力发挥的局限，能征服及控制这复杂的过程而令应用软件真正的满足 其 需求。 因此，实体传递和智力传递最大的分别是 :（一）智力成果多数要经过数次的重复过程及反复的交递及接收。 （二）智力成果交递完成之后对相关活动及成果的连带性具有影响力；如果它在成功交递完成以后， 影响到其相关的活动及成果不成功的话，这个传递的成功只是一时表于形式的错觉。 智力工作者的智力传递工作过程难以直接监控，成果难以衡量，使这方面的管理变得具不确定性而复杂；控制这些繁复细节（微细而繁复的相互依赖）的最佳方式是通过相关的智力工作者来完成，而管理智力工作者的人员，只有通过有相称性的承诺管理来间接管理他们，使他们能够在既定的目标和自我管理的心态下 ,自主地完成任务，实现知识转移、包括以各种形态存在的显性知识和存在于人头脑中的隐性知识，这才是对人的有效管理方法。 以上有关于实体传递及智力传递的定义限于 本书并适用于软件管理。 在其它领域如 Roger Schank 的语义网络 （ Semantic Network） 概念里的实体传递及智力传递的定义与我所阐述的观点有所区别，其用途是自然语言识别，非软件管理。 怎样去开始明白 基本不同的管理 20 以下的表格 ，表 21,是 以体力活动、智力活动、 实体 协调 、智力协调、团队管理 （ 动机管理及冲突解决 ） 及生产管理 （ 时间、 资源、 产量及质量的管理 ） 来分析了这八类问题，它主要是以 “ 重要 ” 及 “ 轻微 ” 来 区分 每一类管理问题中体力或智力活动、 实体 或智力协调、团队管理及生产管理的重要性。 空白并不是等于 完全没有，只不过是非常轻微而不值得在此提及有的意思。 以画画为例子，画画是智力活动，但画家也 要把 画纸墨放好才可画画 ，因而 非常轻微的 实体 协调是有的。 此外，成本和期限通常都不用来量度画师的能力，但受人支付报酬的画师也是 要如期交货的，因而在某些情况下， 轻微的生产管理还是有的。 划分维度 案例 体力 活动 智力 活动 实体 协调 智力 协调 团队管理 （动机冲突） 生产管理 （期限成本） 跑步竞赛 : 个人赛 重要 工厂生产 重要 重要 重要 重要 足球竞赛 重要 轻微 重要 轻微 重 要 画画写诗 : 一人 重要 学生软件 : 一人作业 重要 轻微 商用软件 : 一人开发及维护 重要 重要 轻微 重要 重要 商用软件 : 数人需求、一人开发 、 无须维护 重要 轻微 重要 重要 重要 商用软件 : 数人需求、团队开发、长期维护 重要 重要 重要 重要 重要 表 21 于团队管理及生产管理，难点在于人力资源的可替换性 （ 例如工人容易，发明家难 ） 、个别效率的差距 （ 例如体力可 有 几倍 差距 ，脑力可 有 几万倍或更 多 ）还有 活动 成果 的可见程度或可量度程度 （ 例如大 众消费品 高，软件低 ） 在不同情况下差别很大，所需的管理模式都很不同。 但活动成果的可见性也不总是实体成果占高比例而智力成果的比例低。 我专门举一个低可见性实体成果的例子，让读者们理解不同可见性在相同体力活动的管理运作中的差别。 如果你主持一个高尔夫球斗远比赛，规 则 是每人打一球，打得最远者得奖金一千元；规 则 也声明无论天气怎样恶劣，都不可改期，但如果到场的全部参赛者都同意取消 （ 即无人可得奖金 ） ，比赛就可以取消，而且也不会再举行。 如果你是有经验的主持这类比赛的人，你多数一早便 叫人在比赛前把地上的球都清除了，比赛的时候派给每一个参赛者一个可以识别的球， 以在 有争议的时候可在地上找回有 标识 的球来量度距离。 在一般情况下，只要你做妥以上的小小准备功夫，管理这个比赛并不困难，因为每个参赛者发挥的成果的可见性及可量度性都很高，无论谁得奖，都不会有人不服。 但如果比赛那天有浓雾，而规 则 是无论天气怎样也不可改期，你管理这个比赛 的 难度 就 突然提升了许多。 会有人提议你用打球的姿势来 裁定胜负 ，如果你那时不明白由于可见性程度转变而产生出来的新问题，没有立刻做好另一套准备功夫， 那么 你对这个比赛的管理很有可能出 乱子。 因为由姿势来决定球的远近是很不容易的，谁有这个资格及能力来评判是一个问题，如果胜出者是评判的亲友又是一个问题。 如果你明白可见性程度转变会影响管理方法，你会先向参赛者解释上述的困难，让他们明白。 然后和他们商讨以决定 （ 一 ） 取消比赛，无人得奖或（ 二 ） 推举一裁判，接受他的决定。 一般读者读到这里可能会问，在日常生活中，有多少事情会 像 以上 在浓雾中打球一样不容易看到成果。 其实在软件活动或其它 21 智力工作中， 像 以上不容易看到成果的例子，每天都在发生。 怎样去开始明白软件管理与传统管理的分别 画画和写软件虽然都是脑力 活动，但其成果的可见性 、 缺陷的浮现情况及作品完成后所需的维护是很不同的。 首先，当一幅画画完的时候，画家以及懂得这类画的人可以清楚 地 看到这幅画，但软件的可见性与画很不同，即使看者很有经验，甚至是原作者自已，都不容易一目了然。 其次，画画是不可能画了一条看不见的千年虫，暗藏在画中，到若干年后它才跑出来咬人。 画里难看到的瑕疵 是有的 ，但绝不会隔一段时间后会跑出来破坏东西。 软件则很不同，除了简单的程序外，一般软件都有暗藏 着的毛病 （ 英语叫 bugs，是虫的意思 ） ，这些暗藏的毛病有多少、在什么情况下会浮现出来以及浮现的时侯其 破坏程度严不严重 ,这些问题都存在不确定性。 因此，由于两者成果的可见性及缺陷的浮现情况不同，所牵涉的管理 问题包括 如怎样去看进度、怎样去看缺点及怎样去验收等当然也有很大的不同。 在作品完成后， 第四类 和第六类也有一个很重大的区别，那就是作品和作者的关系。 一般情况下，当画家画完画签了名后，便可和作品分开，不再需要维护这幅画。 但商用软件的情况却很不同，有很多商用软件的原作者开始时要自已亲自维护并改进软件，后来即使培训了别人来维护，数年后也有可能收到 咨询 电话问他软件 会不会在这种情况下出现问题或可不可以这样改动而不会有 不良后果。 由于软件需要长期维护，而维护工作也需要原作者的知识，便引出以下 的管理问题 : 1. 软件商如何管理由原作者到维护者的 知识移交，需 要什么及多少文件， 需要的时间及资源是多少，与现时商业的 限制 符不符合，怎样才知道移交成功与否 （ 因为不成功是会严重影响客户的 ）。 2. 原作者及 维护者 的自行管理。 需 要什么及多少文件，需要什么形式及多少的培训， 需要的时间及资源是多少，与现时公司的限制符不符合，怎样才知道移交成功与否 （ 因为不成功是会严重影 响 到 两 人日后的工作 ）。 3. 如果是重要任务系统 ,买家要在选择软件商时确定它有 足够 的知识和 经验去维护以及它过去有一定 的 维护声誉。 如果那 重要任务系统 是特别为顾客而造的 （ 不是大众产品 ） ，在签约 的 时候 要确定原作者会维护 一个时期或起码做维护者的顾问等等。 4. 软件商如何管理客户报告的毛病，怎样才知道客户的报告所指出的东西是否真正是毛病，损害的严重性有多大，什么时侯通知客户及怎样和客户在 22 解决 问题 上达成共识，怎样把问题通知其它有可能遇到相似问题的客户，需要的时间及资源是多少才可把问题解决，怎样把修补软件送到客户手中。 5. 维 护者应在侦查问题、提议解决方案及解诀问题 的时候，都要有一定的自律及自行管理，但在此不 详 述。 第四类 和第六类问题还有一个很重大的差别，就是在完成作品后的改进。 越是成功的软件作品，越有很多不同的用户组加入使用，便越会有很多不同的新需求，因而不断改进是成功软件的重 要一环。 当然，不同产业或不同性质的商业，可能接受的软件改动程度是不同的，如嵌入式软件必须跟随硬件版本的更替；股票交易所的系统需要高度的可靠性，不能每月都接受新软件。 但就算有某些产业或商业能接受的改动较慢、较少，也不等于他们会购买发布后便不再改进的软件。 在很多情况下 ,由于 产品在完成后是需要连 续维护及改进的， 因此 产品同公司维护与改进的财力 、 维 护者及改进者都有一定关系。 这 也引出对购买软件产权或软件公司的不同管理，如果你是购买一批书，你只 要找识货的人验明货便可。 但你如果购买一个软件产权或一间软件公司，你除了找懂得那类软件的人去看软件，你更要看的是那里的工作人员以及留住人才的策略。 有很大部份软件，如果你收购到产品但留不住人才，那软件会变 得无法改进 ，甚至还得不到维护。 怎样去开始明白 培训不足的地方 为什么我在前面比较第四类 和第六类问题而不是 第四类 和第五类呢。 原因很简单，第五类虽与第六类同是写作软件，但从管理角度来说，一个学生写软件交功课给老师所需 要的管理与一个受人支付报酬的画师要如期交货差不多，而与 第六类 （ 个人写商用软件 ） 已有很大不同，与第七及第八类的距离，更不用说了，可谓有天渊之别。 就连上段说的可见性及可量度性，第五类和第四类有些相似，而与第六类则很不相同。 原因是教授在设计作业课题的时候，他必需把课题设计得让学生做 出来的作业成果是 可见 的 及 可 量度的，那样他才可以公平地给学生成绩，不然连他自己由学生交作业至出成绩前也无法看清学生们的作业成果，他又怎能公平地给学生分数呢。 我对美国的大学及研究院比对中国的 清楚 ， 因此 在 这 段所 说 及的是我 25 年在美国所 见 到 的情况。 美国许多大学生，他们 的学期作业要 写一个完整的操作系统或同等复杂的软件。 如果提高 复杂程度，学生是 很 难写完 的。 问题并不是所培训的 特殊 软件 领域 如 人工智能（ Artifical Intelligence） 或操作系统的复杂程度不足，而是 从 个人 纪律 及管理角度来说，第五 类 与第六类 （ 即使是一人写的商用软件 ）已 有很大 差别。 有很多大学让 学生以团队 方式 去写作业，这个 趋势很 有帮助，是值得鼓励 的。 但要明白它的成效不会很大，原因 是 它只是 针对 在明白需求以后及 反复测试 之前的 协调 ，对于 怎样 去 应付 以下的 复杂 情况，在 理论与实践 上 23 是 没有教授 的 : 1. 由于需求的智力传递的复杂 所 带来的管理问题； 2. 由于测试的实体协调的复杂 所 带来的管理问题 （注 :测试也有一定复杂程度的智力协调）； 3. 由于低可见性和低可量度性 所 带来的管理问题； 4. 由于长期维护 所 带来的管理问题； 5. 由于软件的高改进率及高改变性 所 带来的管理问题。 在我以上的分折 中 ，我 也 不需 要用个人及团队来 区分 学生作业软件 与 商用软件，第六类是一 个 人写的商用软件，其 复杂 程度 同学生受的训练是 大大不同 的。 结论 简化的八类管理问题告诉我们， 在不同 情况下， 管理的难度有很大 差别，由此导致 对 管理方式的要求也会不一样。 具备丰富 软件管理经验的人，都知道画画与写软件的区别所在，也能体会协调一队人写软件比起一个人单打独斗增加了多少复杂性。 成果可量度性的困难，需求传递的复杂，及长期的维护工作给大多数软件企业的管理带来了困扰 ， 至今仍深陷其中不知如何改进。 从业多年，我深知这些情况无论在学校还是实践中都是缺乏教授的，“无知”不是最可怕的，关键是能认识到不足，后天弥补，才能在软件战场的拼杀中胜出。 24 第三章 软件战场 如果足球队不是 11 人而是 1100 人，传球不是用脚而是用智力，球也是无形的，那要怎样去管理。 25 明白软件战场的困难 我在美国起初十年的软件 /IT 职业生涯里，在美国最好的软件机构工作，与美国最好的软件科学家及管理人员一起工作，并有机会参与和管理世界上最大型的软件开发顶目。 我那个时候以为自己知道软件战场应该是怎样管理的，因为需要看的书已看过，好的实践机会也已经得到。 由于我懂得争取，还有数位十分有经验而且十分聪明的人肯辅导我，做我的顾问。 但后来我才发觉书本不但没有一套完整的软件战场管理理论，而且错误地引导我把注意力、精力放在比重不是最高的地方。 实际的战场经验才是最有用的，但由于缺乏理论基础，实践者往往各 施其法，得到的也只是混乱的经验 （ 缺乏系统性及可重复性 ）。 肯辅导我的人，由于他们本身受工业时代管理思想的束缚，只能教我一些实体战场的管理再加一点对 智力工作者的人事管理。 在这种情况下，学习当然困难。 不明白软件战场，并没有对我当时在美国的软件 /IT 职业前途 造成 负面的影响。 相反，我在 Perkin Elmer 工作四年被提升三次，每次都被委以更重大的软件管理任务。 在 1990 年，。