【2013年总结】 向着IT前进

各位朋友，请将手机调整到飞行模式，我们将乘时光机回到2013年元月，一起见证作者Mr Chen在过去这一年里的“丰功伟绩”，现在开始闭上眼睛，进入倒计时10, 9, 8, 7, 6, 5, 4, 3, 2, 1...

2013年元月 上线前的冲刺

“兄弟们，辛苦一下，今晚把这几个Bug搞定，明天我们就不用过来加班了。大家也都饿了吧，我去给大家搞点外卖。”尽管已经到了凌晨12点钟，项目开发团队的所有人员仍兢兢业业的奋斗在前线上，项目负责人在安慰大家的同时，还不忘给大家搞点外卖，彰显了负责人的“大爱”。在项目上线期间，加班基本上就是常事，大家也都习惯了这种节奏。况且，这种状态已经持续了半年多，没有哪一个人觉得这是例外。

在项目上线阶段，几乎所有的项目都要加班，这已经成了行业内的常见现象。尽管除了老板之外的人之外，没有一个人喜欢加班，但是IT行业在上线期间，却经常加班，很多人觉得项目在管理上出了问题，也有觉得是因为公司想要表达能够最快处理现场问题的能力，其实，导致这种现象的最大的原因，是关键的需求往往在上线的前不久才确定或者发生了更改。客户不是开发人员，也不是设计人员，他们不懂技术，我们不能以对技术人员的要求来要求他们，所以，出现项目上线期间加班的时候，大家要淡定，要理解。

2013年二月 甜蜜的春节假期

因为春节前项目组的疯狂表现，客户对我们的系统还算满意，项目负责人便很“大方”的在春节假期的基础上，又额外放了一周的假期。对于项目负责人的大慈大悲，我和我的小伙伴们非常开心。毕竟大家对于春节这个传统的节日，都希望能够在家里多体验一下年味。而且，对于一些小伙伴而言，也只有春节，才是他们与家人团聚的日子。

除去两周长假，二月份也就仅仅只有两周的时间。如此一来，项目组便没有什么大动作了。大家在二月份剩下的两周里，调整一下工作状态，修改项目中出现的一些Bug，等待3月份迎接项目的上线。

2013年三月 上线时的彷徨

在无数次“上线”的呐喊声中，我们的项目终于上线了。对于项目的整体推进进度，我感觉项目的开发速度真是很快，尤其是比社会主义快很多。社会主义的口号喊了那么多年，现在以后仍然并将长期处于社会主义初期阶段。而我们的项目“上线”上了不到一年的时间，就完成了“上线”的过程。

尽管项目已经上线，但是项目上仍然有很多问题，比如一些新增的需求，一些潜在的Bug。因为项目的站点多，难度大等问题，尽管项目已经上线，在修复上线项目Bug的过程中，仍然出现了一些问题。最重要的表现是各站点的版本不一致，这给维护造成了很大的麻烦。

上线对于一个项目来说，是一种结束，也是一种开始。对项目组的人员来说也是一样。尽管项目还没有正式结束，但是对于项目组的大部分人来说，都已经开始考虑项目结束后的归宿。大家在等待着，筹划着，期盼着...

2013年四月 对项目的成功与延期的因为分析

我感觉我快离开项目了，具体哪一天我还不知道，也许明天，也许下周，也许下个月。项目组裁人总是那么的毫无征兆，当一个人在一个项目组上创造的价值少他在项目组的消费时，便是他离开项目组的日子。项目上已经有人陆陆续续的离开了，我在等待我离开的那一天。

对于任何一个项目，我们都不能随意的用一句成功或者失败来草率的为它下定义。我认为任何一个项目都有它的成功之处，也有它的失误之处。我不知道我分析的是否完整，但是我依然为我的项目总结了项目成功的⑤大因素和项目延期的⑦大因素。

2013年五月 客户就是客户，总有你想不到的需求在后面

我以为我们的文档管理系统已经非常智能了，它不仅涵盖了部门库与公司库之间文档的流转，而且还有各个站点之间文档的流转，再加上权限，组织树等功能，我认为我们的系统应该是文档管理系统中最复杂的一套系统了，几乎能够适应公司的文档办公需求。但是我没有想到，后来客户又新增了一个承包商库的功能。这些客户，真是能有多懒，便有多懒啊。

以前，我总是以为自己能够替用户想到很多可以简化他们操作的功能，但是当看到用户这个承包商库的需求后，我才发现：客户就是客户，总有你想不到的需求在后面。

2013年六月 终验前的忙碌

尽管我没有等到项目终验的那一天就离开了项目，但是那个骄热的六月，我一直在为项目的终验而不停的修改Bug。在奋斗了一年零八个月之后，我们终于看到了项目的曙光，我们感到很兴奋，这份成果真的来之不易。但与此同时，也有一种落寞感降临在我们身边，终于要结束了，下一个起点会在哪里呢？

那个六月，没有了对项目的抱怨，有的只是对项目的回忆。

2013年七月 项目穿越

有人说，每当离开一个项目都是一次穿越，每当进入一个项目都是一次重生。在经历了无数次的的假设与猜想之后，我终于从项目上穿越了。项目穿越前最重要的工作就是工作交接。看到几乎为0的文档和那些杂七乱八的代码，尽管我很没有心情写文档，但是还不得不硬着头皮把文档写完，尽管我知道写完这些文档也没人看（新人看也看不懂，老人根本不需要，因为系统的结构比较复杂）。

穿越后的新项目与原来的项目大不相同，一点没有拖沓的节奏。每天早晨都要9点前到公司，每天下午都要有例会，这应该就是敏捷开发中的Scrum会议吧。让每个人都参与到会议当中，这是我比较喜欢的开发管理方式，我有点喜欢这个新项目。

2013年八月 爱上SMMC

也许是之前厌倦了CNNC式的工作环境，SMMC的工作环境让我着实喜欢。一个中小型的敏捷团队 + 现代化敏捷工具 + 现代化敏捷管理方法，这是很多管理者一直提倡却很少有团队做到的一套管理体系，我加入这样的团队自然是非常开心的，这种轻松、愉快的工作状态，我甚至有种想到网上晒幸福的感觉。

不过话说回来，这两个项目也没有太多的可比性，无论是从项目的大小，还是团队的规模，或者用户的数量，以及开发的周期来说，这两个项目不可同日而语。其实，开发者能够进入什么样的项目，主要还是看运气。毕竟，一个人刚进入一个新项目时，对项目的情况不是非常了解，总不能看到一个不爽的项目就离职。

2013年九月Hello，Demo

因为我们所属的部门是研究院，所以我们开发的项目不一定都是采用原来的成功的成熟框架，也有可能是一些新技术。比如，我们这次新开发的项目就使用了非关系型数据MongoDB。尽管我们可以将数据保存在关系型数据库中，但是为了迎接大数据与NoSQL的到来，再加上在某些数据的存储上，使用NoSQL确实能够给我们带来很多便利，我们就使用了MongoDB作为了我们的数据库。

为了让大家能够更快的熟悉系统的架构和框架，我们做一个Demo，实现了系统中某个模块的功能。这样一来，大家有了参照模型，就大大降低了开发难度，提高了团队的开发速度。由于一个Demo并不能覆盖所有的用例，每当出现一个新的技术性需求时，我们就将新的Demo补充道Demo用例中去，这样以来，即使团队更换了人员，新来的人员也能够很快的加入到团队的开发当中。

2013年十月 幸福的开发生活

每个项目都有这样一段平稳期，在这个阶段，需求基本稳定，开发框架也已经成型，开发人员仅需按照需求去完成相应的功能即可。这是大部分开发工程师所向往的开发生活，他们不必向需求人员抱怨需求不够细化，也不用担心测试人员会在盯着一个小小的Bug在那里喋喋不休，一遍遍的唠叨，他们所做的工作就是用心和代码沟通，写出自己认为最完美的代码。

2013年十一月 再谈软件开发过程

需求，设计，开发，这些都是软件行业里永远也谈不完的话题。一千个项目，就有一千个项目原型，我们不可能找到两个完全一模一样的项目（即使同一个项目，也有一期工程、二期工程之分），但是我们总能在这些项目中找到一些共同点。当我们把所有的项目拿出来比对之后，我们可能会发现，原来软件的需求采集过程也就那么几种，软件的设计方法常用的也就那么几种，软件的界面原型也就那么几种，项目的管理过程也就那么几种，我们在不知不觉中对软件的认识越来越深，在不知不觉中，一步步走向项目经理。

2013年十二月 收租

读了几本好书(《项目管理修炼之道》、《硝烟中的Scrum与XP》、《PMBOK项目管理知识体系》等)，看了几场电影(《惊天魔盗团》、《毒战》、《致青春》、《地心引力》等),去了几个景点旅游(《长城》、《颐和园》、《北海》、《恭王府》、《XX滑雪场》等)，做了两个项目：CNNP和SMMC。

　　各位朋友，由于时光机故障，时光大门将在１０秒后自行关闭，现在大家准备好降落伞，开始跳伞，具体降落到什么位置，就看大家的运气了，倒计时开始10,9,8,7,6,5,4,3,2,1,0...