软件过程：“流程”的割裂导致过程管理流于形式

“流程”的割裂导致过程管理流于形式 

 
----王珏

     不知您所在的项目组是不是这样的情形，“责任向上游推，任务向下游放” 。

    测试就说开发人员烂，程序写的都烂到没法测；----研发是测试的上游
     研发人员说需求没做好，需求变更多，开发没方向；----产品需求是研发的上游
     需求人员说这个项目根本就不该立项（其实需求人员郁闷，一般立项都是领导立的，他们几乎没有推卸责任的余地）；

     反过来，
     需求人员花完了需求分析时间（不是搞定了需求），就说研发人员你们去开发吧（评审无非就是走过场）；----研发是需求的下游
     研发人员等花完所有的开发时间，连基本的测试都不做了，就说测试的兄弟们开始行动吧，有问题你们反馈；----测试是研发的下游
     测试人员能测出一个毛病算一个，测不出来的就交给维护人员吧。---维护是最下游
     维护人员总是最辛苦，他们没有“下游”了。

    同样的矛盾也出现在“销售人员”和“研发人员”中。销售人员在销售的时候什么条件都答应客户，给自己人挖一个永远也“填不满的坑”（有单就有提成）；研发人员接到这样的任务，就只好“以身填坑”。填不满就宣布项目失败。
    我们流程的虽然已经运用在实际生产中了，但是人员不但没有因为流程而整合起来，反而因为流程而分割，结果 责任 推诿，相互踢皮球。导致了效率的下降，效果的丧失。

     而“流程”被割裂的主要原因在于“目标丢失”：每一个单个流程的目标已经不是项目的“整体目标”；每一个流程的目标已经演化“为其他流程服务”。
     研发人员以实现需求人员的“需求规格说明书”为目标；或者研发又以满足“测试用例”为目标。殊不知，“需求规格说明书”是否正确本身就是未知的，或者由于研发的实际困难也需要“需求”做部分妥协。 当把项目的“整体目标”演化成每一个小目标后，逐步丧失了“整体目标”。

    这种丢失项目目标的的事情也不仅仅是“IT项目”所独有的，如果我们仔细观察，我们身边出现的“怪现象”也有很多和这个类似，比如：高校评估本来是为了促进高校的教学质量，最后演变“造假工程”（参见： 从“高校评估丑闻”来看CMM ）；人行道上的“导盲道”，本来是为了方便盲人，可是人行道上的盲人却不见了（ 城市“导盲道 ”的思考--盲人朋友去哪里了？ ）。为了评估而评估，为了“导盲道”，而“导盲道”，却忘却了目的。

    本质解决“流程”被割裂的手段是：重新认准“目标”。目标不能偏移， 无论需求、研发、测试、维护都要把目标直接对准“项目整体目标” （具体的操作方法可以参见： 项目管理：如何紧盯IT项目目标？ ）。

王珏原创