项目经理要思考项目的成本

文：鼎捷ERP

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

第二节思考项目成本的经理
    因而，除了软件本质力量的推动之外，商业因素也推动着软件工程体系的发展。大公司们的争夺战的较终结果，已经开始把软件工程，从原始的“自身演进”状态，逐渐推进到“他激发展”的状态上了。
    这种他激发展可能会影响到软件工程发展的速度，而不会影响到各个工程层面上的“关注点”。因而对于工程体系的描述来说，EHM应当是一种基本模式。
    但是，这也是一种理想模式。正是在为EHM图标注关注点时，如下的问题引起了我的思考：
    》    项目的管理到底是组织管理还是成本管理?
    》    项目的计划到底是组织规划还是成本计划?
    简单地说：项目管理要不要考虑成本问题?
    现在，让我们从一个细节跳出来，来看看我们的角色。这个细节就是：如何完成今天的工作。
    正如前面所说，如果你是一个工作流软件公司里的项目经理，你今天的工作可能是写一份电子商务项目计划案，或者听测试部的报告，又或者是安排会议来听取和分析一个新的产品需求。然而，我要说的是：
    这是细节。
    细节就是你使用的Project 2003，或者你正在公司内部署和推广的ClearCase。如果它们正好是你今天要完成的工作，或者是你明天要用来工作的工具，那么，作为项目经理的你，现在就要立即跳出来。
    理想状况下， “软件工程=过程+方法+工具”。然而工程成功的真正关键，并不在于你把你的团队“组织”得有多好。即使在团队中他们都表现得有条不紊，你一样会面临失败。
    蚂蚁的团队总是被本能地组织得非常好。然而如果一个蚂蚁的群体中有了流行疾病，蚂蚁在死去，而新生蚂蚁不能跟上其死亡的速度，那么很快，这个团队就溃散了。
    这是因为蚂蚁用于维护团队运作的“资本”在流失。如果资本没有了，就没了运作，团队的存在就没有了必要性和可能性。
    项目就死亡了。
    埋头于画甘特图的项目经理犯下了与挖山不止的愚公类同的错误：忽略了成本。
    如果愚公真的可以成功，那么可能是300年之后。然而如果一个工程要300年才能做成，那么在做成之前，客户就选择了放弃。
    如果有机会，项目经理可以选择向另一家公司购买一个产品来卖给客户，从“为客户开发”变成“为客户定制”，以及“为客户服务”。这样在没有任何开发成本的前提下完成了工程。与另一个同样极端的例子相比，你会发现它与第五章中那个“做过场”的项目全然不同。后者是做完了工程(的全部过程），却没有做成工程。而现在这个项目经理却做成了工程，但是在许多的过程环节上，他根本就没有开始。
    然而现在，除了跃跃欲试的技术经理之外，没有人会不满意这个结果。
    技术经理较常说的话是：我们可以开发出来；开发人员较常说的话是：我可以开发出来；愚公较常说的话是：何苦而不平?
    还记得那句话?——不要栽进蚂蚁洞里!愚公如果停下来，思考的问题可能是碎石的‘‘方法”。而项目经理从细节中跳出来，思考的问题就应当是完成工程的“方法”。评价这个方法的好坏的标准只有一个：节约成本。
    Y公司由K公司过渡而来的时候带来了一个市场前景非常看好的产品。而存在的问题则是两方面的，一是扩大市场占有，二是继续的技术投入。
    于是，Y公司请来了专家D。他做过公司，也在无数家公司做过，是一个在行业中摸爬滚打了多年的顾问型专家。D先生的项目计划可能是无可挑剔的，但其投资规模决定了它无法实施；D先生在一些产品计划上的思考上也是切近市场的，然而他没有办法为团队争取到两名以上的开发人员；D先生在部门管理上的方法也是适当的，然而他却无法训练部门人员以使他们与自己保持一致的步调和方向(组织和管理一个松散的团队比照顾一群蚂蚁难得多)。
于是在Y公司建立到倒掉的四年时间里，D先生三进三出，营销计划一再被否决，而产品的再研发计划也数度搁置。很快，这个并不生动的故事被终结于我跟他的较后一次会谈：三年之后，产品彻底从市场中退出。
——思考成本，这是D先生给我的教训：
》    不计成本的项目计划不会得到经营者的支持；
》    毫无目的地消耗成本是项目中的慢性毒药；
》    较致命的风险是成本的枯竭。
第三节审视AOP
    我读到的第一篇关于AOP(面向方面编程)的文章，居然说它是‘‘新一代的java语言”。OH，正如文章的标题所表现的那样，作者大概是在学习如何向方格子里填写“错误”：其结果当然是每一个格子都是‘‘错误”——如果他像小学生一样勤奋的话。
    AOP不是语言。AOP首先是方法论，这就像OOP是‘‘面向对象的编程方法”这种方法论一样。而Delphi／C++才是语言，是OOP这个方法论的一个实现工具。
    很好，有了这个基础，我们再来讨论相似性的问题。我们提到过开发方法是基于一种供应链管理数据结构的编程实践的结果。很显然，OOP所基于的数据结构是对象(Object)，而AOP所基于的数据结构就是方面(Aspect)。落足到开发工具的实现上，Delphi将Object表现为一组有(继承)关系的“记录”。相对应的，Java则用类(Class)来实现Aspect。人们在争论Aspect到底应该译成“切面”还是“方面”这件事上花了很多功夫。其实，就如同讨论前面的“关注点”究竟是“点”还是“线”的问题一样，他们陷入了细节。如果这些细节被作为问题持续下去，那么可能有一天台海战争将不是发生在军队之间，而是在程序员之间：到底是’物件’，还是“对象”?
    在C中，这个名词是‘结构(Struct)’。很多人不会承认“对象是有继承关系的记录”这样的观点。是的，所有的教科书上都不会这样写。但是从数据结构本身及数据结构在语言中的实现来看，对象终究是记录。记录是平板化的内存存储体系中所能表达的较复杂的单一数据体。
Aspect在定义时没有确定的对象模块，Aspect本身只是对一个“对象模块群体”的观察视角，因此它更易于表现成接121——只有描述而没有实现。
    在Object一层的抽象上，Object关注于“有继承关系的考察对象”的个体特征；而在Aspect一层的抽象上，Aspect关注于‘‘有相似需求的考察对象”的群体特性。其相似性在群体中表现得越广泛，则AOP的优势也就越明显。例如在Delphi的VCL框架中，以下两个需求就可以用AOP的思想来实现。
》    使Delphi中的全部对象具有多线程特性(即线程安全)；
    》    实现助手工具类以观察、控制Delphi对象的运行期特性或表现。
    到现在为止，我们弄清楚了AOP作为“思想、方法、工具”的一些基本知识，以及它的应用范围：至少你要明白，它是用来考察对象(而不是设计对象)的思想方法。
    所以接下来AOP的三个概念我们就明白了。
    》    指示(Advice)/拦截器(Interceptor)：考察这些对象以“达到什么样的目的” (即需求)；
    》    引导(Introduction)：在目标上实现这些需求时，目标所需要表现出来的公共特性，引导特性可能需要配合编译器来实现；
    》    元数据(Metadata)：如果需要，为即有对象实体再补充一些参考数据。
    确切地说，切分点(Pointcut)并不是AOP编程方法所需要的概念，而是AOP作为一个框架去实现时所需要的一个工具：一组辨识Aspects和Objects的索引。
    现在你已经会用Aspect的思想来编程了，而无论它是用Java来实现的，还是用C#、Delphi，乃至于FORTRAN或COBOL来实现的。其实如同这里所表现的那样，学习任何一种新的编程方法，你需要做的仅仅只是回到工程较核心的那个环节：程序=算法+结构+方法。