管的有多复杂,被管的就有多简化

12年在某城商行做卡系统,凑巧的是,项目被拿来做管理改革的试点。我们是实施方,项目不大,一个项目经理三个开发,行里为项目组额外分配了一个QA,负责所有流程方面的问题。我的项目经理是个传统的项目经理,面对行里强压下来的流程、需要学习成本的工具和四十篇文档的文档矩阵,他只是无奈的笑笑,因为知道被做标杆了就没有反驳的余地。当我们同意这么做后,管理层的目光便齐齐盯向了我们。

项目给我的印象,领导其实很好对付。

举个例子,当时行里要求每个人必须用一个很笨重的版本管理工具,安装调试就要好多时间、空间,加上一堆看不懂的选项和莫名其妙的概念,三天后问题就已经升级至顶峰。项目经理说这样不行,这样吧,我这装一个客户端就好,你们自己搭一个svn,每天打一个包给我传上去就可以了。

就这样,一周以后,QA来找说,你们这样不行,上面必须得有代码,我是要出更新报表的。

好,那就把方法升级一下,拉一个版本的代码传上去,写一个批量改文件的脚本,加个注释行什么的都可以,下班前刷一部分文件,然后传到统一的工具上。而我们更新的代码还是在svn上,统一的版本管理工具只和我们的svn同步了一个版本号,并没有什么实际内容更新。

文档就更是这样了,传统项目中的实施文档大致有两需求三开发四测试一上线一运维外加用户手册,好家伙,要分40个方方面面,就把上面文档使劲拆就行了,反正所有东西是都有的,拆出来的文档肯定不堪入目,但是肯定有那个意思。文档好不好这东西,双方都不好硬性评价,毕竟事情做了才是第一位。

流程,项目结束我都没用过那东西,我的项目经理每天上去随机点几个任务的流程,在结束时候把所有的都点完。

后来,因为那个项目的上线,卡部门以我们项目管理试点成功为名去邀了功。当然,我的职业生涯中,这件事可能是个黑点。

14年,有幸做两个较大银行A、B的管理流程参观。当时很流行集成开发的建设,据说大行A已经做了3年,从数十台编译机,最终做成了4台编译机,搭建能满足当时一部分重点系统的编译环境,而且专人操作维护,版本管理工具是行里统一的svn。我当时看到了他们提的生产单,除了时间窗口必填,没有对生产的任何描述了(我们当时受某公司的培训,对于流程的描述生产应该是最细致的),什么都没有了。当时问了一个准备打包的开发人员,我说你们不填写版本号什么的吗,他说以前也写,后来发现写了也没人去校验包对不对,大家也觉得很麻烦,行里就取消了。

显然,行里问题是我本来用它来保证一致性,但是没办法去验证,所以就干脆不做了吧,出事拿项目经理开工就可以了。

这个问题其实也很好解决,属于工具集成就可以做的事情。A行当时还没有做,因为从一个完整的线上流程与诸多项目相适应,就用了很久。这期间从方法论出发,做一个完整的东西,然后逐步调整为所有适用,再根据民意逐渐简化让大家接受。

而各项目组在用的情况恰好相反,最开始的那个东西觉得没法用,他要什么我对付上去什么就行了,适应自己后觉得对了胃口那就迁移上去试一试,后来做到所有人都适用了,那么大家都开始用了。

B行由于行业保密性,也是没有见到直接领导,接待的是一个组长,他大致介绍了他们的管理流程,一直在努力做开发平台和流程平台的一体化建设,但是现在都到了做报表系统的阶段,平台还是推的不太理想,项目组总是变着法子逃避我们的规定。后来听在B行做项目的同事说,如果都按流程走,项目根本做不完。

16年,我在岗PMO,开始着手公司内的流程简化,12年的故事就成了我重要的经验。因为当时流程已经被全公司形式化了,和我以前做卡项目时如出一辙,致使我们PMO拿不出任何有意义的报表。当时和开发人员谈,和测试经理谈,和生产运维谈,当第一版需求做出来之后,我感觉到,东西还是没法用,因为还是有那么多的子流程,还是有那么多的退回操作,还是有那么多的字段。

我发现他们是典型的顾客心理,我什么都想要,但是拿到手用不用是我的事情。

而以前各大银行的期望是我是为你们做的流程,你们什么都不用我很失望啊。

好比炒了一盆饭,顾客只需要一碗,你埋怨顾客问什么不把一盆都吃光,顾客说我吃不了啊,你问那你要一盆干什么,顾客说万一吃不饱呢。

有人也会补充一句,因为不要钱啊!还真是。

那么怎么识别哪些是他们要但是吃不了的东西呢?我当时遵循了三点:

1.只保留相关的指标字段。意思就是除了时间和人的字段都要考虑好是不是必要的,举一例说一个项目经理告诉我,他们需要记录是否做数据库改动,我建议他写到备注里,如果对其他系统有影响就为其他系统派单。

2.能线下动嘴,别线上推诿。举一例说还是测试,他们提给开发缺陷,然后开发退回给测试,测试不合理又分给开发……在开发人员觉得不合理流程给测试人员之后,我不建议测试再能退回给开发了,此时问题应该是线下解决阶段,可以将缺陷挂起,等待问题解决后重新由开发提给测试或者测试将缺陷废除。

3.能自动写入的就不要让人填。好比之前说的版本号,这种用工具的集成都可以解决,就不多说了。

遗憾的是,在版本工具方面,由于工具的高学习成本及项目组的习惯,我无法迫使所有项目统一版本工具,最后折中了办法,开放测试环境的自动化构建接口,可接入他们自己的版本工具中,然后统一生产代码版本工具,生产环境代码版本必须交至集中的版本工具中。我觉得也不失为一种选择,因为强迫其用不愿接受的东西,最后的结果可能什么都得不到。

以上为一家之言,仅供参考。

你可能感兴趣的:(管的有多复杂,被管的就有多简化)