注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

湖海仙音

我是天边一散仙, 魂游尘世几十年。

 
 
 

日志

 
 

日本小女人远山  

2012-03-17 23:03:05|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

好几次都想写一下关于远山,但总是怕写了什么坏话显得不厚道。不写吧很容易就忘了,近来觉得记忆力大不如前了。最后决定稍微写一点, 反正我的 博客基本上没有人看,中国人没兴趣日本人看不懂,想来怎么也不会让远山知道我写了她什么。话又说回来,即使知道了又怎么样,她还特地跑回公司骂我一顿不 成。

远山被公司裁掉的时候我有点吃惊,因为她已经在公司呆了大约十五年了,被裁前是中台系统唯一的业务分析员。以前裁员都是精简,裁掉后马上有别人可以代替。远山被裁后中台系统就没有业务分析员了。看来公司裁员终于开始动真格了,即使可能因此对业务 造成暂时的不便。后来仔细一想,她的被裁完全是自找的,怨不得谁。这几年来裁员不断,抓住自己所管的业务就是抓住救命稻草,管的越多救命稻草就越多。 但是远山的所作所为完全就是把一根根的救命稻草扔掉,有主动扔掉的也有被动扔掉的,终于在最后一根救命稻草被扔掉后淹没在裁员的浪潮中了。

远山扔掉的第一根稻草:文档。

务分析员最重要的工作应该就是写文档。项目无非就是业务流程的新建或者改变,最先接触这些项目的总是业务分析员。把这些项目以文档的形式固定下来,不但能 把项目解释得更加清楚,而且在今后也能有据可查。更重要的是,能给上司看自己的劳动成果,是晋升的资本。优秀的业务分析员肯定也是优秀的文档作者,我看到过凯丽,托尼和希莱西写的文档,缜密严谨,条理清晰,一目了然。我和希莱西合作过一个很小的项目,作为OASYS实时流程的应急备用,需要把实时消息存成的文件,转换成系统 可以识别的分配指令。希莱西写的文档除了包括详细的文件格式说明,还包括完整的流程图,用箭头表示所有可能遇到的情况。基本上这就是一篇不用计算机语言写 的程序,我所要做的只是把它们用IFELSE等来代替而已。希莱西进公司时和远山一样是底层的业务分析员,短短四年就成为亚太地区业务分析员的头,管理日本 和香港两个业务分析小组,这不是偶然的,我认识的印度人里面她是最值得尊敬的人。

我没有看到过远山写的文档,因为她根本不写。去年的CTM项目是OASYS的升级,我做开发,远山做业务分析。历时半年的项目,所有的业务分析材料只有一个JIRA页面,简短写着“用CTM实现OASYS所能实现的所有功能”。那时候克里斯特开始管中台,有一次问我为什么CTM要做一个新的程序, 难道不能用原来的OASYS程序加一个MQ接口吗?我就跟他解释CTMOASYS是完全不同的系统,原来的单向流程变成了双向的,交易双方都可以上传交易 数据,都可以修补,取消或者拒绝,都从CTM事件中取得当前交易状态,然后决定本方的下一个动作。克里斯特大吃一惊,说没有想到是这么复杂的一个项目,光看JIRA根本不知道。

宫岛从业务部门转来做前台的业务分析员后意识到了文档的问题,写了一篇前台系统用户手册,前台系统投入使用十多年后终于有了第一篇用户手册,而远山呆了十多年也没有想到为中台系统,仓位系统或者报表系统写一篇文档。

远山扔掉的第二根稻草:测试。

我刚进公司的时候系统的测试全部由业务分析员做,我觉得这很合理,因为业务分析员知道确切的需求,由业务分析员来为系统把关是再合适不过了。后来在印度组建了独 立的质量保证测试小组,小组刚成立而且人员变动非常大,很长时间内处在对系统的熟悉状态中,所测试小组做回归测试,业务分析员做新功能测试。这样的组合也挺好,既保证了系统原有的功能没有被破坏,也保证了新功能满足用户的需求。可是随着测试小组逐渐成熟,业务分析员慢慢地主动退出了测试,到最后就根本不参与测试了。

当然做测试是非常枯燥的活,有些自命不凡的程序员如科里斯连单元测试都不一定做。测试中最无聊的莫过于回归测试,新功能测试应该要好多了。要是连新功能测试也不愿意做,那就只能归于懒了。如果我是业务分析员,我会觉得不做新功能测试是一种罪过:接受用户需求说明的是我,承诺实现这些功能的也是我,不做测试的话我怎么保证这些功能确实实现了?如果系统的实现和当初的承诺有不同,我该如何面对用户可能的质疑?

不做测试带了的后果是对系统开始生疏,如今的业务分析小组对业务的熟悉程度已经远远不如以前了。若干年前程序员对系统有什么疑问可以问业务分析员,若干年后的今天业务分析员有疑问就问程序员,程序员翻看代码来寻找答案。若干年前业务分析员领导技术部,凯丽和西尾都领导整个中台开发小组,若干年后的今天技术部可以没有业务分析员。

远山扔掉的第三根稻草:报表模板

日本的客户对于报表有近乎变态的苛求。在美国欧洲基本上一个标准报表可以打发所有客户,但是日本有近千个不同的报表,客户甚至对字体颜色大小格式都有严格的要求。为此我们开发了独特的报表系统,用户可以很方便地定义报表的模板。但是使用这个系统需要一些EXCEL的知识,尤其是其中的公式非常灵活,需要一些数学能力。譬如在一个含有买和卖的报表中统计买的股票种类,使用这样一个公式:CountDistinct ( If ( Order : Side = "B", "B" + Instrument : Name , "S" ) ) - If ( CountIf ( Order : Side = "S" ) > 0, 1, 0),没有一定的数学能力是没有办法写出来的。我们原来希望业务分析员能够帮助用户一起学习怎么使用这个系统,但是怎么也没有人能够熟练掌握公式的用法。最后当时的领导西尾决定聘用契约社员来帮助用户做报表的模板。去年下半年,由于公司不景气,决定停止契约社员,谁来帮助用户管理报表的模板未有定论。随着远山的被裁,这个任务显然又到了开发队伍的肩上。要是远山能够自告奋勇担当这个任务,不知道她的命运是否会有不同?

远山扔掉的第四根稻草:版本发布

 一年多前,在新加坡成立了版本管理小组,主要做新版本,补丁的编译,以及测试环境的管理,汇集版本发布指令等。这只是把程序员的工作分一部分出去,由业务分析员管理的版本说明并不包括在内,因为版本说明包括很多业务知识,只有熟悉业务的业务分析员才能完成。

版本管理小组的头利西和他的两个手下显然从一开始就感到了危机,因为他们的工作和公司的主要业务毫无关系,而且比较机械化,容易用程序来实现。一旦版本管理全部程序化,还需要这个小组干什么?于是他们想方设法和业务挂钩,除了和支持小组定期讨论系统的问题外,他们主动要求管理版本说明,因为版本说明能够从JIRA制作出来,而他们也能够通过制作版本说明来学习业务知识。

业务分析小组没有对此提出异议,版本说明顺利转移到版本管理小组手中。短浅的目光看不出这将造成一种灾难性的后果,那就是很可能某个需求从产生到完成发布,当中完全不需要业务分析员的介入。即使勤快的业务分析员能够研究版本说明中的每一个项目,也完全很可能漏掉某一项,更何况远山怎么也不是勤快的人。

今年一月的某一天,远山忽然又发加急邮件给开发小组:为什么交易还未完成系统就给客户发OASYS消息?原来的限制哪里去了?一调查原来是新加坡的一个程序员把限制取消了,其根据是一项JIRA项目,标题赫然写着:允许未完成交易发送到OASYS。再一查,原来是支持小组输入JIRA时搞错了用户的原意,应该是只在某个特定条件下允许发送。阿伦立刻让新加坡的程序员把代码改回去,让版本管理小组做紧急补丁,让支持小组发布补丁。

远山的邮件依然加急:用户想知道为什么会出现这种情况?你们能给出一个解释吗?阿伦终于从忙乱中缓过神来了:业务分析员处于回答这个问题的最合理位置,他们管理用户的需求;我们也很想知道为什么他们会允许某个不反应用户实际需求的改动进入到系统中。远山沉默了,当然她是无法搞明白其中的根本原因的。

作为业务分析员,可以放弃写文档,因为那只是锦上添花之举;可以放弃测试,因为出了问题尽可以怪罪程序员;可以放弃报表模板,因为还有程序员可以完成这个工作;但是放弃了版本控制,也就是放弃了管理用户需求的根本责任,让自己成为可有可无的摆设。

铃...我的电话响了,是业务部的国枝。我们想要报表系统增加一个新的功能来对应客户的要求,但是没有业务分析员,我们不知道应该打给谁...”我大喜过望:你打对电话了!我就是你要找的人!”

  评论这张
 
阅读(15)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018