职场故事 （4） 悉心学习

工作了一个月左右，我对这个组的成员有了更多的了解。这个组开发了这个管理系统，当初是十几个程序员加上BA/QA/DBA 做了将近两年，把原先老的DOS系统升级成Java分布式系统。我来的时候这个系统上production已有四年。原来的程序员走了不少，留下来的很多都升了职。我的manager就是从senior程序员几年内连升两级做到了manager。两个lead的也是从刚毕业的程序员连升两级做到了lead。QA manager 更是从普通程序员连升了三级。Director是从business调过来领导这个系统的开发，因为之前这个系统做不出来，在她的领导下才完成。

我本来被招进来是因为组里接了一个大项目，是要把另一个BU的管理系统并入到我们这个系统里，因为上面领导分析认为我们的系统更有前途。其实那个BU的business process 跟我们大不相同，等于是要把我们现有的系统再开发出一个规模类似的，难度和工作量之大可想而知。我们组从director，manager， BA，到lead程序员都投入到前期的需求分析工作中。

看着没我什么事，我有点着急，找到我的manager说我要参加需求分析会议，因为只有了解用户需求，才能设计出好的流程，写出好的程序。我的manager说这样的会议一般是不让非tech lead程序员参加的，因为怕他们问太多不相干的问题，影响进度。我说我只是旁听，实在要问问题也肯定是相关的问题。他说会帮我争取一下。过了一两天，他告诉我他们同意了，我非常高兴。

开始参加会议，才发现他们对这个系统真是了解，因为他们就是当初的开发成员。他们对待工作也非常认真，就连工作非常繁忙的director和manager都在开会之前就把资料都读了，开会就直接讨论问题。（这跟我以前工作的大公司非常不同，那些manager和director都把开会当成了听报告，反正事情都是底下人在做。）我心里暗暗叫好，这才是我喜欢的领导的工作态度。

话说我参加这些会议确实了解了很多这个系统的business process，又通过和另一个系统的对比，大致了解了新的系统应该做什么。每次会后我会把我的理解画成流程图，以便方便大家讨论。我没有参与写用户需求，因为总觉得英文不是我的母语，怕犯些愚蠢的语法错误。这个一直是我的短板。

还有一个小插曲，就是参加会议不久之后，我告诉QA manager我早上8：00以后才能到， 因为要先送孩子上学。而会议是每天7：30 –9：30。（这些领导为了不影响他们的其它工作，会议开始得很早。）我原以为反正我不是关键人物，晚到一会儿不会影响会议进程。可没想到他们把会议分成了两个，我只参加8：30-9：30的。我非常感动，他们会为我一个不重要的人物改变他们的会议安排，我觉得有了被尊重的感觉。

几个月之后，我们几个程序员开始对新的系统进行技术设计。就在我们觉得工作进展顺利的时候，意想不到的事情发生了。