近段时间，一直在负责一个产品版本改造（C/S系统进行B/S改造）的研发项目管理，在任务紧、时间短、团队成员又没有相关技术（Silverlight）背景的恶劣情况下，我带领包含我在内只有6个人员（5个研发人员，1个产品经理，产品经理在系统版本改造中主要精力投入到辅助市场部进行产品推广去了）的超小型项目团队，终于在公司给定的时间范围内完成了整个产品的版本改造。这其中经历了需求变更、技术风险、人员变动等诸多问题，项目任然取得了成功，这种使用新技术的试验项目能够取得成功不得不说有几分侥幸，更多的还是团队兄弟之间的互相帮助、团队协作。
在历时3个月的产品版本改造过程中，经历了大大小小的诸多问题，积累了一些经验和教训可以和大家分享。其中主要包括：需求、设计、研发、测试、实施、进度、风险、沟通、团队管理等。由于刚涉入研发项目管理，很多方面都做得不到位，于此记录下本次产品版本改造中的点点滴滴，在以后的工作开展中以此为戒，希望可以将项目管理做得更好。
大家都知道，无论什么项目都应该以需求为核心，分析、理解清楚所有的目标需求以及潜在的需求，以研发出一套能够得到客户满意的软件产品，那么项目就可以算是成功了。不同的项目环境的需求也是不一致的，就我这边的项目情况，其需求主要体现在：成本需求、软件环境需求、软件功能需求等。
1）、成本需求
成本需求主要是在人力、物力、财力、时间等方面，项目团队由6个人组成，在公司内部研发，给定三个月的时间完成整个产品版本改造，这对于人力、物力、时间的需求是明确了，研发过程中需要的项目成本公司全部支出，也没有财力需求上的不足，在成本需求上公司提供了条件，以使整个产品版本改造工作能够正常、顺利的完成。
2）、软件环境需求
软件环境需求实际上也是属于成本需求的一部分，只不过这里主要想说明的是站在研发侧的软件环境，包括研发场地、会议室、研发计算机、配置管理以及常用硬件设备和工具软件。在项目启动后对于产品版本改造的技术选型，公告技术对比，专家评比等多种方式确定下了最终的软件环境，后续项目开发完全按照确定的软件环境方案执行。这样可以可以团队组织上直接避免软件环境的变更，唯一存在的风险就是对于研发所使用的技术熟练度，这可归根为技术风险。本次产品版本改造所采用的研发软件环境为：VS2010 + TFS + Office 2007 + ASP.NET + Silverlight + Oracle + PL/SQL。
3）、软件功能需求
业界许多专家都说，一个项目能否取得成功，对于功能需求的准确掌控应该占项目工时的60%左右。不管架构设计、团队建设做得多成功，对于需求的把控不准确，最终或许都会化为乌有。幸运的是本项目研发是从老C/S版本的稳定产品进行B/S版本改造，且该产品已经推出多年并在多个客户现场实施，取得客户的认可。对于需求的精确把控上不会出太大的问题，我采取了系统功能清单的方式，针对老系统现有的功能点进行逐个的列出，最后输出产品功能清单表，具有如下几个主要作用：
A、有助于团队成员清楚知道产品功能点，避免需求偏差。
B、有助于技术经理制定WBS和研发计划。
C、有助于测试人员进行功能点测试，确定测试是否覆盖了产品所有功能点。
D、有助于产品经理及市场销售人员，更加清晰软件功能点，好针对不同的客户需求选择性的介绍产品功能点。
在版本改造中除了覆盖老系统的现有功能，同时也推出了些新的功能模块以及对现有功能模块的设计改进，对于新的功能模块需求变更的控制，采用大众评审的方式进行，会议后确定出最终方案，后续的实际研发中发现了什么问题，重复发起会议评审通过同样的