产品版本改造中的项目管理

　　近段时间，一直在负责一个产品版本改造（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、有助于产品经理及市场销售人员，更加清晰软件功能点，好针对不同的客户需求选择性的介绍产品功能点。

　　在版本改造中除了覆盖老系统的现有功能，同时也推出了些新的功能模块以及对现有功能模块的设计改进，对于新的功能模块需求变更的控制，采用大众评审的方式进行，会议后确定出最终方案，后续的实际研发中发现了什么问题，重复发起会议评审通过同样的方式确定一套可性的方案。

　　本次产品版本改造我们非常重视设计，包括架构设计和UI设计两方面。系统技术选型为ASP.NET后台 + Silverlight前台，这对于系统前台只需要后台能够提供稳定的通信接口就行，对于系统后台的整体架构可以不关系其如何实现。鉴于多年来这套产品的实施情况来看，不同的客户需求不一致，以及部署麻烦等诸多问题。老系统中采用了插件式架构的方式将不同的功能模块进行系统功能组件化，以便能够通过灵活的配置实现系统功能点的动态组装，并采用了智能客户端实现系统部署和更新。

　　新版本的产品也同样采用了插件式的架构设计，包括系统后台业务组件的插件化，系统前端插件化功能模块组合。研发了一套基于MEF框架的Silverlight插件式架构框架，可以灵活的更具系统配置组合系统功能模块，动态装载模块程序包并托管运行等。

　　对于设计管理工作主要涉及到架构设计管理、功能模块详细设计管理和系统UI设计管理三方面。

　　1）、架构设计管理

　　　　架构设计以安全、稳定、高效、 易维护、扩展等为导向，基于微软MEF设计的插件式开发框架。通过不断的优化更新，最后确定下最终的框架设计方案，输出架构设计文档并提交到配置管理，然后启动框架的开发，测试。在具体的研发过程中出现了相关的变更通过会议评审确定变更后的解决方案，然后更新架构设计文档并修改框架实现完善框架功能，整个过程中都有指派专人负责。

　　2）、功能模块详细设计管理

　　　　需求明确的前提下开展功能模块的详细设计是非常顺利的，基本上和架构设计的管理差不多，首先确定下模块的实现方案，然后编写详细设计文档，文档通过审核后提交到配置管理，然后启动模块开发。如有变更需要从走评审，重复前面的步骤，每个功能模块都有指定直接负责人。

　　3）、UI设计管理

　　　　UI设计管理这块的工作相对比较简单点，基本流程也相差不大，首先确定下设计方案，然后再开展设计工作，如果设计出的UI效果图没有达到预期的效果或者对于前端开发人员来说比较难以实现，就将需求提交给美工进行修改。在设计过程中的步骤大致如下：

　　A：设计出主体界面框架效果图，确定后由研发人员实现系统主体框架界面。

　　B：设计出通用的界面元素，确定后由研发人员将通用界面元素统一开发为通用用户控件或者定义为系统样式资源。

　　C：细化到功能模块的局部，根据不同的模块功能实现设计出大方、直观、简洁的界面，确定后由研发人员实现界面效果。

　　研发管理主要是在研发进度、风险、成本、质量、沟通以及团队管理方面。首先根据系统功能清单划分出WBS工作分解结构，随后制定了研发计划，在研发计划执行过程中根据实际进度情况不断细化WBS工作分解以及更新研发计划。使用了微软TFS做项目配置管理，并基于TFS展开项目管理工作，包括进度计划，进度跟踪，任务分配等，并让团队成员通过配置管理直接将分配给自己的任务同步到本地Project项目计划文件中，一旦项目计划发生变动便立即通知团队成员更新项目计划表。盯紧项目计划，按照计划有效的执行，从而在项目风险和成本上可以得到一定的控制。

　　由于团队成员对于Silverlight技术的掌握程度不够深入，同样也存在着很大的风险和成本投入，技术层面上我采用的是培训的方式来提高团队成员的技术水平，集中培训技术大体范围，私下根据其负责的功能模块对技术的需求情况单独指导，以此来保证不同的人重点学习自己负责的功能模块需要的技术点及某一方面的技术，不用团队成员都将所有的技术点都学习一遍，从而缩短了学习时间，为整个产品研发直接降低了成本的投入。

　　对于研发过程中的产品质量管理也是非常重要的，项目启动后我们项目团队一起制定了一系列标准规范，包括数据库设计规范、编码注释规范以及性能等其他规范。通过这些规范来约束项目团队成员的研发习惯，避免出现个性化的特色模块。其主要体现在数据库表命名、字段命名、注释模板、变量命名、界面元素命名、类，接口命名、代码组织结构、稳定性、程序包大小等多方面。通过每周的代码走查（Code Review）来检查团队人员是否按照规范在执行，没有按照规范执行的要求立马修改，在编程风格上形成一个统一的风格，对于他人接受项目模块或者是后期的维护，都具有非常重要的作用。

　　团队人员流动造成项目进度拖延，同时也会增加项目风险和成本，期间有一个员工离职，幸运的是从别的项目组及时的调配了一个人员补上，避免了因为人力的缺乏对项目的进度带来影响。在整个研发过程中团队成员之间讨论问题也发生口头上的争吵，没能达成一个统一的共识的情况，纳闷的是组里面就有个一位老员工，时常因为讨论问题因为意见不合而和新员工发生争执，明明知道自己的东西存在问题也不承认的陈咬金。虽然作为项目的负责人，也是团队的技术经理，某些时候也很难说话，为了解决问题不得不得罪人，针对不同的情况我主要采用了以下几种方法：

　　1）、综合评估团队成员的方案，分析各自的优缺点，最终让团队成员一起总结出最佳方案。

　　2）、综合评估团队成员的方案，根据自己的经验和对业务的熟练度，给团队成员提出备选方案，最后让大家评估选择确定方案。

　　3）、团队成员的方案都不可行，根据自己的经验给出一套方案，强制项目团队执行。

　　4）、出现沟通解决不了的问题，及时上报给领导，让上层人员出面调解。

　　本篇内容为本人在项目管理工作中的真实记录，以便在项目管理过程中遇到同样的问题的朋友参考。同时欢迎广大从事项目管理的朋友前来指点、交流，大家共同学习，进步。

版权说明

  本文属原创文章，欢迎转载且注明文章出处，其版权归作者和博客园共有。  

  作      者：Beniao

 文章出处：http://beniao.cnblogs.com/  或  http://www.cnblogs.com/