与工程有关的问题

文：鼎捷ERP

作者：鼎捷数智 | 发布时间：2012-11-30 14:50:34

第六节工程
较狭义的工程，是描述“做什么”和“做到什么”。
也就是说，是对目标的描述和成果的检测。至于这个工程目标的实现，是
“过程”和“方法”的事；而有效、快速地实现“过程”和“方法”所需的，就是“工具”。
    这种软件工程体系层次(SoftwareEngineeringArchitecturalLayers)被描述成一张图，我很有幸地在第一次画它的时候，将它画成了一堆牛屎。因此我从此都把它叫“牛屎图”：
    过程伴随工程而出现，解决的是工程中“步调一致”的协作问题。那么工程是因为什么而出现的呢?
    很显然，软件规模的不断增大是根本的原因。所以你会看到在几年前，开发一个工具可以不讲工程；或者现在在你的WORD中，为了将半角替换成全角字符而写的那个宏，也不需要工程。
    接下来，即使协同软件规模增大，如果有一个牛人中的超牛人，愿意用20年来写一个任意庞大和复杂的操作系统，他也是能做到的。然而现实中不会有软件公司给他这样的机会。
    项目的“复杂”可能要求不同知识领域的角色参与，而“庞大”则要求更多的(人力、技术与管理)资源。 “团队”作为开发行为的模式，是软件规模和复杂度渐次累积的结果。
    团队必将越来越庞大，因为(与工程对应的)软件规模必将越来越复杂。没有团队意识的软件公司在高度过程化、通晓方法理论、拥有大量工具的集团军面前，必将一触即溃。
第七节组织
    工程理论其实是包含组织学的。然而我在上面的那张图中，将组织与工程分离开来，并在二者之间画下了一道纵向的线。
    即使如图上所表现的那样，工程关心的是“需求”、 “配置”和“文档”等等这样一些要素，那么这样的工程还是停留在技术层面的：关注的还是工程的实现细节，而非目标。从角色的角度来看，这是项目经理和技术经理所共同关注的那一部分。
    作为那个解结的人，你应该知道这个图例上的需求管理决定了你的阶段性目标，配置管理决定了你检测的方法，相关的文档化工作是沟通的渠道，以及协调团队矛盾的手段。 ‘‘需求”、 “配置”和“文档”等等不仅仅是你每日一成不变的、模式化的工作步骤，而且也是解结的工具与方法，或者是你实施管理思想的道具。
    此外，你(项目经理)还必须关注于人力资源、项目资金及多个项目之间的协调等。这些与工程本身并没有直接关系，而是“组织”方面的内容。
    所以在工程环节中，“文档管理”和“配置管理”等中的那个词汇“管理”，是管理的具体技术和方法；而在“组织”这个环节中的这个“管理”，才是真正的管理学上的用词。
    我在这张图上，试图从这个角度上来说明：作为项目经理，你必须有一部分的工作是非技术性的。甚至，你可能绝大部分的工作是非技术性的——因为与技术相关的管理技能(需求、配置、过程管理等)可以由开发经理来做，或者公司对于这一方面有较统一且成熟的规范，因而无须投入过多的精力。
    你必须更关注于对这个(或这些)工程的组织与计划。站在“组织者”这个角色上，你现在要考虑的内容可能会是：
    》    为项目的各个阶段建立计划，并逐渐地细化计划的内容，以及确立项目过程中每一个环节、每一个计划阶段的优先级和复杂度；
    》    确立项目或者产品阶段目标，成果的准确描述、定位，以及整个项目的质量目标及其评核办法；
    》    对团队中的不同角色展开培训，以指导并协调角色间的工作，从而消除因为工作习惯的差异带来的影响；
    》    为每二个人准备他所需要的资源，这不单单是把一套shareware变成正式版或者把512M内存变成2G，还包括准确地评估他的工作量，以及决定是否为他增加一个(能协同工作的)副手；
    》    决定在哪些环节上反复审核和回顾，而在哪些环节上采用较为宽松的方式以加快进度；
    》    习惯于开会、组织更短而有效的会议，以及建立激励机制，当然也刀、要忘记让每一个成员意识到这一项目的风险；
    》不要乐观。
    即使你做好这一切，可能项目的结果仍然不够理想。但是你应该知道，好的项目经理并不是不犯错误的人，而是以尽可能少的失败来获得成功的那个人。
    无论是你的团队成员，还是你的老板，对重复的错误以及可预料的错误都是不会宽容的。——在—个团队中，失去了组员的信任比失去老板的信任更可怕。
所以回顾每一个项目，或者项目中的每一个阶段，以及与每一个团队成员交流的细节，是你的日常工作。
第八节BOSS
    很多人以为BOSS是给自己发钱的那个人，这其实是错误的。发钱的决策通常是由以下三个角色来做出的：
    》    部门／团队经理：你的直接上司，他是雇佣你的人，是他用薪金的多少来衡量你的价值，或者反之。
    》    纪效经理：如果你的公司有这个角色的话，那么他总是盯着你的错误以决定你薪水的扣除比例。
    》    财务经理：有钱?没钱?没钱?有钱?……
    BOSS并不决定你的薪水。
    BOSS在公司中解决的是‘‘经营’’问题。这其实是在比“组织”更靠外侧的一层——在前面的图例中并没有给出，这也意味着“经营者”与“工程”基本没有关系。
    在一个更大规模的组织机构里，你可以更直接地观察到“经营者”与“组织者’’之间的差异。例如公司的大小股东是“经营者”，董事会通常是解决经营问题的地方；而总经理、执行经理及各个部门经理则是各级的“组织者”，经理办公会则是解决组织问题的地方。
    你应该清楚，真正的BOSS是经营者。这有助于你明确你被雇来的原因，你的工作是面向哪一个层面的，以及你或者你的上司有没有权限来决定一个项目是否应该立项，或者中止。
    BOSS(经营者)决定了一个方向，组织者保证决策与这个方向是同步的，而工程是在这样的一个方向、决策的构架下的一个具体行为。
工程中没有BOSS。
第九节上帝之手
    从较初的简单编程开始，到现在工程团队的组织开发，实现(一个软件)都是较终的目的。所以可以这样说：实现，是软件开发的本质需求。
    我们看到，正是出于实现的需要，我们才设计了一些数据结构或逻辑结构来映射物理模型。因此类似于过程、单元、记录(结构)、对象等的出现，其实都是出于编程实现的需要：
    而后，基于某种数据结构的编程实践(的不断积累)，决定了软件开发方法理论的产生。
从这一点可以看出：方法，是对既有行为的归纳总结。
因而实现方法总是较先出现的，而后才有分析和设计方法。
    可以看到面向对象分析(OOA)、设计(OOD)与编程(OOP)的出现顺序，与它们在工程过程中的实作顺序正好相反，而与编程实践行为的顺序则正好相同。

为了实现更大规模的软件供应链管理系统而有了团队组织模式，而团队的协作决定了过程模型的产生，在过程环节中的沟通问题导致了(模型化)语言的出现。如同编程工具中的编译器和集成开发环境(1DE)一样，开发中的编程语言、过程中的建模语言都只是一种工具。
工具的产生仍旧是出于‘‘(软件)实现’’的需要。不可能从工作流软件开发实践中产生出轮子和指南针，因为那不是‘‘软件开发的本质需求’’可以推动的。软件工程的体系中， “实现”作为软件开发的本质需求和基本动因，如同上帝之手在推动这几十年来的软件工程理论体系的形成。

上一页：协同软件工程语言

下一页：项目实施过程中的工具