软件工程实践者的思想[3]

软件工程实践者的思想[3]

决定在哪些环节上反复审核和回顾，而在哪些环节上采用较为宽松的方式以加快进度；

习惯于开会、组织更短而有效的会议以及建立激励机制，当然也不要忘记让每一个成员意识到这一项目的风险；不要乐观

即使你做好这一切，可能项目的结果仍然不够理想。但是你应该知道，好的项目经理并不是不犯错误的人，而是以尽可能少的失败来获得成功的那个人。

无论是你的团队成员，还是你的老板，对重复的错误以及可预料的错误都是不会宽容的。在一个团队中，失去了组员的信任比失去老板的信任更为可怕。

所以回顾每一个项目，或者项目中的每一个阶段，以及与每一个团队成员交流的细节，是你的日常工作。

7.BOSS

很多人以为BOSS是给自己发钱的那个人，这其实是错误的。发钱的决策通常是由三个角色来做出的：

部门/团队经理。你的直接上司，他是雇佣你的人，是他用薪金的多少来衡量你的价值，或者反之。

绩效经理。如果你的公司有这个角色的话，那么他总是盯着你的错误以决定从你的薪水里的扣除比例。

财务经理。有钱？没钱？没钱？有钱……

BOSS并不决定你的薪水。

BOSS在公司中解决的是"经营"问题。这其实是在比"组织"更靠外侧的一层。在前面的图例中并没有给出，这也意味着"经营者"与"工程"基本没有关系。

在一个更大规模的组织机构里，你可以会更直接地观察到"经营者"与"组织者"之间的差异。例如公司的大小股东是"经营者",董事会通常是解决经营问题的地方；而总经理、执行经理以及各个部门经理则是各级的"组织者",经理办公会则是解决组织问题的地方。

你应该清楚，真正的BOSS是经营者。这有助于你明确你被雇来的原因，你的工作是面向哪个层面的'，以及你或者你的上司有没有权限来决定一个项目是否应该立项或中止。

BOSS（经营者）决定了一个方向，组织者保证决策与这个方向是同步的，而工程是在这样的一个方向、决策的构架下的一个具体行为。

工程中没有BOSS.

8.上帝之手

从最初的简单编程开始，到现在工程团队的组织开发，实现（一个软件）都是最终的目的。所以可以这样说：实现，是软件开发的本质需求。

我们看到，正是出于实现需要，我们才设计了一些数据结构或逻辑结构来映射物理模型。因此类似于过程、单元、记录（结构）、对象等的出现，其实都是源于编程实现的需要。

而后，基于某种数据结构的编程实践（的不断积累）,决定了软件开发方法理论的产生。

从这一点可以看出：方法，是对既有行为的归纳总结。因而实现方法总是最先出现的，而后才有分析和设计方法。例如面向对象分析（OOA）、设计（OOD）与编程（OOP）的出现顺序，与它们在工程过程中的实作顺序正好相反，而与编程实践行为的顺序则正好相同。

为了实现更大规模的软件系统，逐渐产生了团队组织模式，而团队的协作决定了过程模型的产生，在过程环节中的沟通问题导致了（模型化）语言的出现。

如同编程工具中的编译器和集成开发环境（IDE）一样，开发中的编程语言、过程中的模型语言都只是一种工具。

工具的产生仍旧是出于"（软件）实现"的需要。不可能从软件开发实践中产生出轮子和指南针，因为那不是"软件开发的本质需求"可以推动的。

软件工程体系中，"实现"作为软件开发的本质需求和基本动因，如同上帝之手在推动这几十年来的软件工程理论体系的形成。