“流程”的割裂导致过程管理流于形式
----王珏
不知您所在的项目组是不是这样的情形,“责任向上游推,任务向下游放” 。
测试就说开发人员烂,程序写的都烂到没法测;----研发是测试的上游
研发人员说需求没做好,需求变更多,开发没方向;----产品需求是研发的上游
需求人员说这个项目根本就不该立项(其实需求人员郁闷,一般立项都是领导立的,他们几乎没有推卸责任的余地);
反过来,
需求人员花完了需求分析时间(不是搞定了需求),就说研发人员你们去开发吧(评审无非就是走过场);----研发是需求的下游
研发人员等花完所有的开发时间,连基本的测试都不做了,就说测试的兄弟们开始行动吧,有问题你们反馈;----测试是研发的下游
测试人员能测出一个毛病算一个,测不出来的就交给维护人员吧。---维护是最下游
维护人员总是最辛苦,他们没有“下游”了。
同样的矛盾也出现在“销售人员”和“研发人员”中。销售人员在销售的时候什么条件都答应客户,给自己人挖一个永远也“填不满的坑”(有单就有提成);研发人员接到这样的任务,就只好“以身填坑”。填不满就宣布项目失败。
我们流程的虽然已经运用在实际生产中了,但是人员不但没有因为流程而整合起来,反而因为流程而分割,结果 责任 推诿,相互踢皮球。导致了效率的下降,效果的丧失。
而“流程”被割裂的主要原因在于“目标丢失”:每一个单个流程的目标已经不是项目的“整体目标”;每一个流程的目标已经演化“为其他流程服务”。
研发人员以实现需求人员的“需求规格说明书”为目标;或者研发又以满足“测试用例”为目标。殊不知,“需求规格说明书”是否正确本身就是未知的,或者由于研发的实际困难也需要“需求”做部分妥协。 当把项目的“整体目标”演化成每一个小目标后,逐步丧失了“整体目标”。
这种丢失项目目标的的事情也不仅仅是“IT项目”所独有的,如果我们仔细观察,我们身边出现的“怪现象”也有很多和这个类似,比如:高校评估本来是为了促进高校的教学质量,最后演变“造假工程”(参见: 从“高校评估丑闻”来看CMM );人行道上的“导盲道”,本来是为了方便盲人,可是人行道上的盲人却不见了( 城市“导盲道 ”的思考--盲人朋友去哪里了? )。为了评估而评估,为了“导盲道”,而“导盲道”,却忘却了目的。
本质解决“流程”被割裂的手段是:重新认准“目标”。目标不能偏移, 无论需求、研发、测试、维护都要把目标直接对准“项目整体目标” (具体的操作方法可以参见: 项目管理:如何紧盯IT项目目标? )。
王珏原创