对于新手来说，学习经验是很有帮助的－我的程序员生涯4

发信人: kaemio (旅行者--漫步人生路), 信区: WorkLife
标 题: 响应号召发原创，我的程序员生涯4
发信站: 水木社区 (Sat Jul 8 18:55:27 2006), 站内

这是一家对日本外包企业，公司规模很小，项目也并不大，主要工作是从日本那边拿项目照着式样书实现。因为公司的规模很小，所以同事们很容易就都认识了，加上我原来就有两个朋友，同事间互相引见加上中午都要一起吃饭。几顿饭过后大家都熟了。这家公司成立不久，人员方面也没有什么技术牛人，大家都是初级水平，好在日本人的项目都是些简单项目，更重要的是日本人会把详细设计写好了拿来做。可以说，对于新手来说，学习经验是很有帮助的。

我要做的第一个项目是一个在linux上面跑的应用程序，主要是用电脑去控制一些设备的。我对linux非常感兴趣，一直以来都憧憬作unix相关系统的开发，终于有一天可以实践了，于是买了一大堆书学习，我要做的其实很简单，只是去实现一个串口通讯的模块，因为没有任何人明白这一块，所以我只能自己去学习和摸索，幸运的是我在深圳时曾经读过相关的书籍，所以很容易就搞定了那个模块。在这里容我再碎碎念一次，工作中学习也是一个必须的活动，好多时候这些学习可能会对你的工作很有帮助，并且帮助你获得其他人的认可和信任。

因为有了这个项目的成功，我的能力被领导和其他同事认可了。在接下来的下一个项目我成为小组的领导，这个项目和上一个非常类似，只不过这一次是在windows系统上的实现，这一回我除了负责自己的模块之外还要协调所有的团队成员一块完成整个项目。这是我第一次充当一个项目管理者，这次的项目经历也给我留下深刻的记忆。之所以有很深刻的印象是因为这个项目我自己完全是个管理新兵，中间犯了很多常见的错误，每次回想起来都觉得很汗颜，对于同事们和公司来说，我们虽然最后成功提交了项目可是中间付出的代价太大了些。犯的错误也太多了些。

这个项目的管理可以说是很粗放，很糟糕的管理，那个时候我还没有听说过敏捷编程这个概念，如果我那时候知道这个，我一定会去努力实践一下。根据我的判断，这个项目其实是非常典型的适用敏捷编程方法的。而那个时候，我对项目管理太陌生了，完全不了解管理方面需要注意些什么。和同事之间的沟通出现了很多问题，以至于项目进行的不顺利，团队的士气也不高。其实这个项目的难度是很低的，如果我更有经验些完全可以做的很漂亮。我要总结的几点失误是：
1）沟通太不够专业，太没有技巧，很容易就会打击成员，导致士气低落，典型的例子就是团队中的一个女孩子负责oricle数据库的sql包的开发，在分派任务的时候大家对于进度方面有些争执，其实这个是很常见的问题，我当时的处理方法是，完全按照自己的想法强加给成员一个进度，这绝对是一个致命的沟通问题，那个女孩子在跟我几次争论后哭了。虽然最后我做了妥协，但是团队的士气已经被打击了，导致了很不好的气氛。
2）团队建设上做的太少，只顾着赶工，赶进度，而忽视了人性化，没有做过任何team的活动（主要指非工作的团队活动，比如一起吃饭，游玩等等），导致成员们没有荣誉感，没有归属感。
3）在遇到协调问题时候处理生硬，没有起到管理者应该起到的协调上下的作用。典型例子是一个团队成员的代码写的质量很差，导致我们公司日本方面的一个经理来信怒斥，我当时昏了头，居然把信转给这个成员，事后想想真是太草率了。结果这个成员和那个经理都很不高兴。
4）流程控制太差，在项目进行过程中，本来是个典型的瀑布模型，但流程控制及其糟糕，没有code review, unit test,也没有很好的进度控制，测试流程也少了很多东西，比如测试用例的设计，测试用例的review，回归测试等等。
总之就是漏洞百出。直接导致项目的质量问题。若干年后，我每次回忆起来都会脸红，这个项目应该是我做过最不成功的了。

之后的一个项目是一个公司内部的项目，由于不涉及到客户，并且有了第一个项目的经验，这一次我首先制定了若干项目规范，并且在沟通方面也始终注意自己的方式方法，相对来说，这次的项目难度虽然大了，可是比上一次的要成功，可惜因为完全是公司内部的开发，而且第一期的功能并不完善，最后也并没有投入使用。但是有了这一次的经验，我对管理方面的底气也稍稍多了一些。特别是，我的一些团队成员对我的正面评价让我感觉到我做的很多工作是很有价值的，我帮助团队成员们成长自己也会很欣慰。直到好几年后的今天，当初的团队成员依然在msn上很谦虚地向我请教问题，其实他们都已经独当一面了。

之后的我又继续在那里做了一些其他项目小的模块，在那家公司呆了差不多两年后我离开了那里，因为感觉那里发展前景还是不明朗。我希望能够寻求更好的发展，于是我来到了一家稍大一些规模的国有软件公司。