OCS项目总结

    历时三个月的测试项目总算是完了，这算得上是我独自负责的第一个项目，也是做的最痛苦的一个项目，连续一个月的加班，没有周末，没有停顿，有个组员到最后一天终于病倒了，这让我更深刻地认识到，对于搞IT的人来说身体真是革命的本钱。写下这篇文章，一方面是对前段工作的一个总结，同时也是对自己以后的一个激励，这么困难都过来了还有什么难关是不能克服呢。

 

    首先简单介绍一下项目的基本情况，关于Office Communicator Server (OCS)协议的测试，相当于是实现一个类似QQ的客户端，用最原始的方式，组包通过TCP/TLS发送给服务器，测试Server的行为。测试周期是三个月，人员配备初期是两个人（说是锻炼我们，其实是人员被上面的人分走了，没有resource给我们了），我一个，另外一个是从别的项目组调过来的，有8-9年工作经验的样子。也就是说初期阶段能供我支配的人就只有一个，后来在项目中期的时候又加入了3个。项目组的总的搭配大概是：1个Owner（我），1个Dev（8-9年开发经验），一个Requirement（研一的实习生），一个Document (2-3年测试经验)，后来加入一个Stack Dev（研二的实习生）。

 

    项目的风险主要有两个，一个是schedule太紧，二是项目组成员缺乏Domain Knowledge，以前基本都没接触过这方面的东西（现在才后悔网络没学好啊，什么TCP，路由，忘精光了）。刚开始对项目的成败很难估计，对自己的技术更是完全没有信心，所幸那Dev技术很强，8/9年开发经验真不是盖得，基本上技术问题都是他解决的，到现在项目完了我回头看他写的代码都有很多看不懂。下面我主要介绍一下项目组的成员，他们每个人都有各自的优缺点，透过他们我们能学到很多。

 

    首先要说的是我们组的Dev，在方正做了几年，然后在微软一个项目组做了几年ERP开发，具备丰富的开发测试经验，从他身上我看到了一个典型的技术人员具备的特征：扎实的编码基本功，丰富的测试经验。然而从他身上我看不到激情，每天准时下班，不管事有没有做完，第二天按时上班，不温不火，我在想是不是工作几年以后人都会这样。能做事，但是做事的速度有点慢，他承担了项目组核心的coding工作，技术问题基本都抛给他。如果说他有什么缺点，我觉得最主要的就是做事缺乏激情，没有全局观，只是自顾自的在写代码，不去考虑项目的整体情况，这可能也是为什么做了8/9年还没有到管理层的原因吧。

 

       Requirement, 一个研一的女生，做事很踏实，很负责，但是能力一般，技术太差。前半个月基本都在training她，手把手教都教不会，稍微难一点就不会了，可能女生真不适合搞技术。分配个事，我估摸应该1天做完的，她硬是拖个把礼拜都完不成，每天能问你很多问题，很多小问题都不能独自解决，让我很抓狂，但是人家女生话又不能说重了。不过值得一提的是，工作态度确实很好，每晚主动加班到10点才走，周末两天都待公司学习，很上进，这类人虽然能力一般但是足够勤奋，以后肯定也会成功的。

 

       Document, 2-3年工作经验，活最少人最懒的一个，一个组的人都在加班他可以心安理得的离开。就能力来说，还是很不错的，学习能力快，做事效率高。但就前面几个缺点就注定了这个人不可能有什么成就，做事慢没关系，能力差没关系，只要上进，都可以提高，最怕人懒没有团队观念，这种人我想换哪个leader都不会喜欢。

 

       Stack，一个研二的实习生，技术还不错，做事很踏实，很上进，有团队观念，好相处，如果没有后面一个缺点我想这种人到哪都能很快脱颖而出，要说他的缺点就是做事效率低，不是一般的低，你给他个技术问题他能给你解决，但是速度太慢，等个几天才能给你结果，然而通常项目都是不等人的，schedule是死的，花太长时间即便作出来也是得不偿失。给他强调过几次，如果碰到问题几个小时还没有头绪，就去找其他人解决或者干脆放弃，但是可能是习惯问题，效率一直不见提高。

 

    到了这基本上每个人的特点都很明显了，对于第一个Dev来说，很靠谱，我能很放心的把高难度的事交给他去做，但是同时我会不断给他施压，因为他做事没有激情，没有时间观念，不催的话可能一天的事他两天才完成。另外我会适当授权给他，让他管理其他几个人，一方面让他有个全局观，不会一心只知道沉在自己的coding里面，另一方面其他人有问题的时候就不会全找我，他也能帮着解决部分问题。对于第三个Document，我也还能把一部分重要的事交给他处理，但我不敢相信他，他做事高效且能力不错，但是他通常不会给你好好做事，马虎偷懒，我需要不断地去检查他的工作，达不到要求就打回去重做。对于第二个Requirement，能力太差，基本上稍微有点难度的事我都不会交给她做，做了最后肯定也达不到要求，到时返工浪费的时间更多，通常我都是把最容易但是很麻烦的事分给他，比如处理文档，找资料等，这种事她能办的很好，我也很放心。对于第四个Stack, 很无奈，能力虽然有但是不敢把重要的事交给他，只能把一些形同鸡肋的活分给他，什么叫形同鸡肋的活呢？就是我基本上觉得做不出来也无所谓做出来的更好的事，最后废了也不影响整个schedule，另外就是帮着requirement处理一些问题。

 

    他们四个各有优点，如果综合一下，他们在任何一个企业都可以成为核心的骨干，但是永远成为不了管理层，因为他们每个人都缺乏最重要的全局观，总是顾着自己手上这点事，不会从全局去看待问题解决问题。很多人说，等我做到管理层了自然就会了，这个我同意，但是难道不做到管理层就不能有全局观吗，处在低层难道就只能低着头走而不能抬起头往上看看吗？未必吧。

 

    回顾整个项目，我也看到了自己的不足。首先是过度高估自己的能力，没有预料到项目中可能出现的风险，以为小宇宙爆发就能搞定，结果导致后期schedule紧张，一边面临PM的施压，一边面临项目压力，所幸通过一个月的加班把东西给搞出来了。一定要记住，任务事情，你可以刚开始就说你搞不定，没人会笑你，大家都清楚你的能力；你也可以做到一半然后跟PM说，项目出现风险，我需要更多的resource才能搞定；但是千万别开始说没问题包在我身上，结果到了最后你跟PM说：废了，我搞不定了，那样结果会很惨。其次是沟通能力，对于Owner来说，需要跟项目成员沟通，需要跟PM沟通，需要跟Reviewer沟通，需要跟Product Group沟通，沟通能力重要，这点是我需要努力提高的，又是英语啊，痛苦。至于技术，就没啥说的了，既没天赋又没兴趣，稍尽人事不让它拖后腿就行了。