2013年个人工作总结

1 加入东软

2013年的春天加入了东软，当初决定来到东软也是因为一个东软好友的推荐，外加当时一个项目的机会。这些年经历过了对日、欧美以及国内项目，我还是更喜欢国内项目：个人的发挥的空间最大，项目能主导的东西最多。

2 深航机务维修成本

来东软之后的第一个项目是深航机务维修；这也是我决心来到东软的一个项目，首先客户是深航，有机会了解一下航空行业的需求和知识，另外这个项目规模也是百万级别的，比较之前做的项目，这个级别的项目不多。深圳之行不虚此行，因为深航机务维修系统其实是一个集成系统，需要汇集多个系统的财务信息，然后做统计和运算，通过和深航工作人员的沟通，以及项目组内部的讨论，深化的我对于项目在系统级别的认识，并且也是从这个项目开始，基于之前的经验，我开始逐渐形成一套可复用的需求分析模型。

2.1 需求分析三个阶段

首先是头脑风暴阶段，就是在和客户沟通需求的时候先不需要考虑SOW，而是尽可能多的了解客户的需求以及背景知识，在这个过程中是真正进入到业务的过程，不考虑SOW是为了能够更好地描绘业务场景图和理解业务；

其次是梳理需求阶段，对于头脑风暴过程中获取的知识进行梳理和串联，进而形成一幅完成的业务场景图，有了成型的业务场景图之后，再对照SOW，对于业务进行删减，使之符合范围，对于范围之外的内容可以规划二期或者预留接口；对于范围之内内容，需要对业务进行建模（输入 - 处理 - 输出模型），并识别核心业务对象、非核心业务对象以及他们之间的关系；建模之后还需要描绘出场景，对于业务的使用场景有详细的记录会为开发设计阶段提供很大的帮助，因为逻辑完整性很大程度依赖于场景；

最后是需求的校验阶段，在梳理之后的需求，对需求进行论证，比对，看看是否需求遗漏（重点分析各种场景下的需求动作的描述是否可以通过验证），或者业务向冲突的地方，然后和客户进行确认；

2.2 需求分析迅速反馈

对于向深航机务维修这样规模相对较大（需求调研两个多月），对于需求的分析应该做到尽快反馈，如果等到需求调研了一段时间在去汇总和分析，那成本将会非常大，而且因为需求提供者来自于各个部门不同职责的人，确认需求本身也是一个很庞大的工程，而且这个时候知识的遗漏也会非常多。所以尽量做到一个需求头脑风暴完毕之后，立即进行梳理业务（业务建模以及确定业务对象关系）并和相应的客户进行需求确认，这样到了调研的后期，需要做的就是将之前确认过的需求整理融合成一份文档即可；

2.3 需求分析的目的

另外做需求调研需要有一个意识：就是调研的目的是给客户解决方案，这个意识是要需求调研人员一定要站在一个业务实现重构的角度来分析需求，建模需求。因为客户思维大都是基于现有实际业务的惯性思维，所以他们的方案只能是看做对需求的另一个角度的描述；我们需要针对我们掌握的需求，整合知识，甚至重构业务，来给出方案，这样的调研才会比较主动，工作也更有意义；

3 物联家电

之后是在部长的主导下，我来到了物联家电的项目；物联家电项目本身历史比较长，项目也曾经经历一段时间的断档，后来黑水晶的项目才又将这个项目启动起来。吕印负责黑水晶时候建立起来的一套比较完整的文档机制，李志宏加入也对项目做事规范化方面有所加强，这两点使得我再加入这个项目，很多事情有的套路；又因为物联家电新的需求相对较少，更多的对于历史需求的一些修改，这样需求风险比较小；随着进入项目的深入，我发现项目有着比较高的开发/维护成本和风险。

3.1 开发风险

1. 如果增加新功能，需要对于现有代码做大量修改，而且修改是基于已有的代码，这样修改的风险是很高的；

2. 命令服务器的处理类的职责太复杂，升级，推送消息，日志，协议解析转发都实现一个Handler类中（单个类代码行数达到2000多行）；

3. 很多功能测试成本比较高，业务逻辑本身和业务逻辑之外的数据库，命令服务器等关联太过紧密，比如模块升级逻辑，只有在真实命令服务器重启之后，模块连接上了命令服务器才能测试升级逻辑是否正确；

4. 人员风险，当时对于命令服务器的知识，只有一个人掌握，其他人对于命令服务器了解以及工作机制都不了解；

3.2 风险应对

基于以上的问题，和团队成员一起讨论，如何来优化现有的开发机制和模式；

1. 重构命令服务器，使之实现逻辑更加清晰简洁，便于阅读和理解；

2. 实施面向测试开发，通过引入Junit测试机制，使得开发人员进行“可测试性”设计，做到业务逻辑尽量独立，测试可以脱离真实的场景。这样可以通过写测试代码来对业务逻辑进行测试；

3. 人员的风险，则是通过模块分工一揽子化，之前是专人来负责命令服务器，现在是团队成员负责自己的命令服务器的开发，通过这样的方式让团队中的成员都有机会了解命令服务器，开发命令服务器；不过因为项目中途我去了青岛一段时间，有些点没有被严格的执行，这一点说明有些开发的方式和思想还是需要深入下去；

4 海尔小家电

今年11月份的时候，我兼职海尔小家电的项目经理，尽管这个项目开始经历了一段痛苦的时期，但是对我启发意义也比较大。如果说深航的机务维修让我深化了系统角度来看待项目，小家电的项目则使得我深化了从项目的角度来看待项目；之前经历的项目大都是相对顺利，所以，对于比较艰难的情况下，推进项目的经验并不多，通过进入到了小家电项目，和现场的成员沟通项目内容以及历史因素，再到和大家一起讨论制定测试计划；和大连团队远程沟通方案，共同推进项目；使得我开始了从更高的角度：项目的角度，来认识项目。并认识到了作为一个项目经理基本素质和两个角色。

4.1 基本素质

项目经理的一个基本素质，就是一定要在脑海中有完整的业务图以及路线图；所谓业务图，是指对于业务建模以及业务实现、业务间的关系，业务图一定要十分熟悉；路线图则是对于项目在未来各个阶段需要推进、完成事情，所需要资源等，路线图十分清晰；

4.2 两个角色

首先应该是一个主导者，所谓主导，就是主动+引导，主动，要求项目经理必须要对项目信息/情况保持敏感，发现问题主动迅速反应。引导是两方面，一方面引导客户，没有几个客户拥有明确的阶段概念，成果物概念甚至是自己的需求，作为项目经理需要能够引导客户确定自己的需求，引导客户在不同的阶段做不同的事情；另一方面是引导开发团队，引导他们按照既定的计划进行工作。引导的前提有两个，一个路线图，作为一个引导者首先是自己需要有清晰的方向感，第二个则是是各个阶段的成果物必须是合格的，因为推进阶段本质是成果物；

项目经理另外一个角色是布道者，应该“教育”并引导客户沿着既定的路线图进行，告诉他们应该如来看待项目；向客户介绍开发团队，让他们了解开发团队进而认可开发团队；同时还需要向开发团队介绍客户，让他们清楚客户的意图，了解客户；开发团队和客户应该彼此有好感并且认可，这样作为项目经理，在中间主导起来才会比较顺畅；

4.3 海尔小家电的项目干系人

以上很多想法来自于海尔小家电两个项目干系人：李燕燕和陈天明；

对于李燕燕而言，这个人是一个追求安全感的人，她要求结果和她的期望相符，而且她需要你为她提供能够达到这种期望的资源/计划。她希望的项目经理一定是要有明确的路线图，而且拥有满足这个路线图的资源；所以和李燕燕合作，最好要有她认为可行的方案和资源，她才会认可你以及你将要做的事情；

陈天明则是一个业务思维比较重的人，他比较认可那些在业务方面可以引导他的人，或者在沟通业务的时候的言谈要和业务有很好的切合点，这要求相关人员的要有一定的业务背景；所以和陈天明合作，最好是一个有一定业务背景的人，这样他才会有一定程度的认可；

相比于之前的碰到的项目干系人，这两个人对项目经理要求相对比较高，有的时候甚至是苛刻，但是他们的要求其实是合理的，成熟的；很高兴有机会和他们一起合作项目。尤其是到了最后，李燕燕表示了项目在后期无论是交付质量还是沟通质量上面都还满意，大家都很高兴，我们看到了团队共同成长，共同努力的结果。

5 2014年计划

2013年已经过去了，在2014年，有以下计划：

1. 研究物联家电领域技术，跟踪物联家电发展趋势，希望自己在明年一年的学习和实践，能够成为一名在这个行业有咨询能力的项目经理；

2. 希望能够带领团队推出具有一个可扩展性和可移植性物联平台系统，可以迅速应对新的需求以及新的物联架构的项目；年后会有一个扩容的项目，希望能够借助这个机会将物联平台进行重新设计规划，使之能够达到这个目标。

经历了2013年的项目积累，这个过程有很多辛苦，更有很多喜悦，非常感谢部长能够提供这样的平台和成长的机会，我希望伴随着自己成长，可以为我们部门，为公司做出更大的贡献。