按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
很显然，软件规模的不断增大是根本的原因。所以你
会看到在几年前的时候，开发一个小工具可以不讲工程；
或者现在在你的 WORD 中，为了将半角替换成全角字符
而写的那个宏，也不需要工程。
接下来，即使软件规模增大，如果有一个牛人中的超
牛人，愿意用 20 年来写一个任意庞大和复杂的操作系统，
他也是能做到的。然而现实中不会有软件公司给他这样的
机会。
项目的“复杂”可能要求不同的知识领域的角色参与，
而“庞大”则要求更多的（人力、技术与管理） 资源。“团
队”作为开发行为的模式，是软件规模和复杂度渐次累积
的结果。
…75
…………………………………………………………Page 80……………………………………………………………
第 6 章 从编程到工程
团队必将越来越庞大，因为（与工程对应的）软件规模
必将越来越复杂。没有团队意识的软件公司将在高度过程
化、通晓方法理论① 、拥有大量工具的集团军面前必将一
②
触即溃 。
6。 组织
工程理论其实是包含组织学的。然而我在上面的那张
图中，将组织与工程分离开来，并在二者之间画下了一道
纵向的线。
① 《三十六计》更多的时候是被当成方法论来读的。其根源在于
“计谋”本身只是方法，而不是战略。
② 如今这样的战役正在国外软件与国内软件之间进行着。而战局，
并不是民族热情或者政府保护可以扭转的。
…76
…………………………………………………………Page 81……………………………………………………………
『大道至简』
如果说工程关心的是“需求”、“配置”和“文档”等
等这样一些要素，那么这样的工程还是停留在技术层面
的：关注的还是工程的实现细节，而非目标。从角色的角
度来看，这是项目经理和技术经理所共同关注的那一部
分。
然而项目经理还必须关注于人力资源、项目资金以及
多个项目之间的协调等等。这些与工程本身并没有直接关
系，而是“组织”方面的内容。
所以在工程环节中“文档管理”和“配置管理”等等
中的那个词汇“管理”，是管理的具体技术和方法；而在
“组织”这个环节中的这个“管理”，才是真正的管理学
上的用词。
我在这张图上，试图从这个角度上来说明：作为项目
经理，你必须有一部分的工作是非技术性的。甚至，你可
能绝大部分的工作是非技术性的。——因为与技术相关的
管理技能（ 需求、配置、过程管理等）可以由开发经理来做，
或者公司对于这一方面有较统一且成熟的规范，因而无需
投入过多的精力。
你必须更关注于对这个（或这些）工程的组织与计划。
站在“组织者”这个角色上，你现在要考虑的内容可能会
是：
） 为项目的各个阶段建立计划，并逐渐地细化计划
的内容，以及确立项目过程中每一个环节、每一
个计划阶段的优先级和复杂度；
） 确立项目或者产品阶段目标，成果的准确描述、
…77
…………………………………………………………Page 82……………………………………………………………
第 6 章 从编程到工程
定位，以及整个项目的质量目标及其评核办法；
） 对团队中的不同角色展开培训，以指导并协调角
色间的工作，从而消除因为工作习惯的差异带来
的影响；
） 为每一个人准备他所需要的资源，这不单单是把
一套 shareware 变成正式版或者把 512M 内存变
成 2G ，还包括准确地评估他的工作量，以及决
定是否为他增加一个（ 能协同工作的） 副手；
） 决定在哪些环节上反复审核和回顾，而在哪些环
节上采用较为宽松的方式以加快进度；
） 习惯于开会、组织更短而有效的会议以及建立激
励机制，当然也不要忘记让每一个成员意识到这
一项目的风险；
） 不要乐观。
即使你做好这一切，可能项目的结果仍然不够理想。
但是你应该知道，好的项目经理并不是不犯错误的人，而
是以尽可能少的失败来获得成功的那个人。
无论是你的团队成员，还是你的老板，对重复的错误
以及可预料的错误都是不会宽容的。——在一个团队中，
失去了组员的信任比失去老板的信任更为可怕。
所以回顾每一个项目，或者项目中的每一个阶段，以
及与每一个团队成员交流的细节，是你的日常工作。
7。 BOSS
很多人以为 BOSS 是给自己发钱的那个人，这其实是
…78
…………………………………………………………Page 83……………………………………………………………
『大道至简』
错误的。发钱的决策通常是由三个角色来做出的：
） 部门／团队经理。你的直接上司，他是雇佣你的
人，是他用薪金的多少来衡量你的价值，或者反
之。
） 纪效经理。如果你的公司有这个角色的话，那么
他总是盯着你的错误以决定从你的薪水里的扣
除比例① 。
） 财务经理。有钱？没钱？没钱？有钱？……
BOSS 并不决定你的薪水。
BOSS 在公司中解决的是“经营”问题。这其实是在
比“组织”更靠外侧的一层。——在前面的图例中并没有
给出，这也意味着“经营者”与“工程”基本没有关系。
在一个更大规模的组织机构里，你可以会更直接地观
察到“经营者”与“组织者”之间的差异。例如公司的大
小股东是“经营者”，董事会通常是解决经营问题的地方；
而总经理、执行经理以及各个部门经理则是各级的“组织
者”，经理办公会则是解决组织问题的地方。
②
你应该清楚，真正的BOSS 是经营者 。
这有助于你明确你被雇来的原因，你的工作是面向哪
一个层面的，以及你或者你的上司有没有权限来决定是一
个项目是否应该立项，或中止。
① 顺便告诉你一个秘密，给予你奖励的决定通常是你的上司，而
不是纪效经理作出的。
② 不过，可能你仅受雇于你的上司，你习惯于把他叫作BOOOOSS
则是另外一回事。
…79
…………………………………………………………Page 84……………………………………………………………
第 6 章 从编程到工程
BOSS（ 经营者） 决定了一个方向，组织者保证决策与
这个方向是同步的，而工程是在这样的一个方向、决策的
构架下的一个具体行为。
工程中没有 BOSS 。
8。 上帝之手
从最初的简单编程开始，到现在工程团队的组织开
发，实现（一个软件）都是最终的目的。所以可以这样说：
实现，是软件开发的本质需求。
我们看到，正是出于实现的需要，我们才设计了一些
数据结构或逻辑结构来映射物理模型。因此类似于过程、
单元、记录（结构） 、对象等的出现，其实都是出于编程实
现的需要：
程序 = 算法 ＋ 结构
过程与单元的出现 记录与对象的出现
而后，基于某种数据结构的编程实践（ 的不断积累） ，
决定了软件开发方法理论的产生。
从这一点可以看出：方法，是对既有行为的归纳总结。
因而实现方法总是最先出现的，而后才有分析和设计
…80
…………………………………………………………Page 85……………………………………………………………
『大道至简』
方法。
可以看到面向对象分析（OOA） 、设计（OOD） 与编程
（OOP） 的出现顺序，与它们在工程过程中的实作顺序正好
相反，而与编程实践行为的顺序则正好相同。
为了实现更大规模的软件系统而有了团队组织模式，
而团队的协作决定了过程模型的产生，在过程环节中的沟
（ ）
通问题导致了 模型化 语言的出现。
如同编程工具中的编译器和集成开发环境（IDE） 一
样，开发中的编程语言、过程中的模型语言都只是一种工
具。
甲骨文 象棋 石头
：
符号语言 文字
：
最自然的沟通方式 语言
项目案其实是可以用甲骨文来写
的
图图形形也也是是一一种种符符号号文文字字
模模型型也也是是一一种种符符号号文文字字
）
工具的产生仍旧是出于 “（软件 实现”的需要。不可
能从软件开发实践中产生出轮子和指南针，因为那不是
“软件开发的本质需求”可以推动的。
软件工程的体系中，“实现”作为软件开发的本质需
…81
………………………………………………………