联想在2005年收购了IBM的PC业务后，为了能提供同时支持全球业务和中国业务运行的IT系统，当时做了一个决定，就是首先和IBM签署了TSA(Transition Service Agreement)过渡期服务协议，继续租用IBM内部IT系统，维持联想国际业务的持续运营，接下来分步骤、分阶段地建立联想自有的全球IT系统，逐步脱离IBM系统(TSA的介绍，可见参考资料[1])。这一任务从05年开始到13年结束。本文作者从10年开始参加了Olympus和Victory两个大Release，完成了美国和欧洲系统迁移。期间遇到过很多艰难和挑战，有很多教训和经验总结，本文选取其中的三个小故事，来记录在项目管理方面的学习实践。第一个故事是关于任务分解的体会;第二个故事关于代码Review的流程改进;第三个故事谈谈在提高估算准确度方面的实践。
任何一种实践的有效性都离不开它赖以存在的场景，因此，本文在介绍各个故事的时候，会首先描述项目的内容和大概背景，希望能方便大家了解这些故事。故事一， 合理的任务分解会显著影响项目的进度和质量 产品生命周期管理系统(PLM)、客户关系管理系统(CRM)和销售类的电子商务系统(ecommerce)是任何一个生产制造企业的几个最重要的IT系统;在联想，PLM定义的产品工程数据，在被销售系统使用前，得先完成一系列配置工作。在Olympus Release中，为了支持美国业务，引入了一个称作LOIS的系统，来完成这个配置工作。该系统的功能简图如下：项目管理论坛 图1 LOIS功能简图 图中三条横线(MTM，CTO和Service)分别表示三种产品类型，箭头表示这些产品由PLM系统产生，经过LOIS配置，最终分发给CRM和E-commerce系统。图中三条竖线(“抽取”、“配置”、“分发”)分别表示LOIS的几大功能点，“抽取”就是数据抽取，把相关的产品信息从PLM系统中抽出来，处理数据转换、建立产品的结构关系(BOM)等;“配置”即配置产品附加属性、多语言、记录版本信息等;“分发”则是把配置好的产品根据规则分发给不同的系统。竖线宽度表示工作量大小。 最初的分工是根据业务特点分成三个小组，分别负责MTM、CTO和Service，三个小组并行开发。但是在做的过程中，我们发现这种分工并不科学，主要问题有： 1. 功能重复很大，很多类似的功能三个小组分别都要做一次，窝工现象很严重; 2. 不同小组出现相同问题的概率很大; 3. 三个小组并行开发，大家进度基本相同，没有办法将其中的任何一个业务模块提前交付用户。 为了解决这些问题，我们重新检查了分工模式。通过分析得出，这三个业务模块看似独立，其实有很多共性，而之前的分工并没有很好利用这一点。随后我们进行了调整，把原来的横向并行模式，改成纵向流水线模式，还是三个组，但是分别负责 “抽取”、“配置”和“分发”;根据任务量的不同，对各小组人员重新进行了配置;同时选择业务相对简单的Service部分作为突破口，尽快调集资源完成这一部分。调整后的分工使得各个组的开发效率提高很多，很快地完成了一条完整的业务流程，大大缩短了用户交付周期;通过这条业务流程的走通，为其他两个业务流程提供了一个很好的基础;同时还发现，代码质量也较之前有很大的提高。 通过这个事情，我有下面一些体会： 1. 合理的任务分解对团队工作效率的提升举足轻重; 2. 达成一个合理的任务分解要求对业务和技术方案有充分理解，要从业务、技术等不同维度去分析，也要从不同的角度、全方位的去看; 3. 不能认为第一版的任务分解就一定是正确的，项目经理要随时通过进度、质量、资源使用的实时情况反思其合理性，要能及时调整;项目管理论坛 4. 合理的分工还能为敏捷开发提供基础。 故事二， 改进的流程来改善代码Review效果 在做Olympus Release的时候，有大概十多个系统同时开发，开发人员来自不同厂商，技术水平、开发习惯各不相同，而且大家都没有经过充分培训就直接投入项目。为了确保开发质量，我们成立了一个方案团队，投入了大量的精力进行代码Review。采用的是会议Review的形式，即要求各个系统的开发人员全部参与。项目管理论坛 但在实践中，我们发现这种方法执行下来的效果并不是很好，主要表现为下面两个问题： 1. 关键业务点的Review不能保证。存在太多的诸如编码规范，变量命名等初级问题，使得团队的注意力不自觉的转移到这些问题上面，关键业务逻辑的Review没有办法保证; 2. Review频度很难平衡，执行效果不理想。太频繁，开发时间没有办法保证;太稀疏，一次Review的结果太多，受限于项目进度和其他方面的压力，很多时候开发人员没有办法进行改正。正是这种矛盾的存在，使得Review也渐渐地流于形式。 为了改变这种局面，我们从两个方面进行了改进：第一，从角色上明确了开发人员和方案团队Review的侧重点，具体来说，凡是有明确标准说明的，诸如编码规范，命名规范等都有开发人员负责执行;凡是核心业务逻辑，架构，性能等没有办法用标准量化的东西都由方案团队负责;第二，我们明确了会上会下的工作，所有开发人员负责的内容都在会下完成;只有方案团队关注的内容会在会上讨论。 为了确保执行效果，我们引入了一系列工具。这些工具分成三类，第一类是开发人员自查工具，嵌入各自的IDE环境中，提供随时检查;第二类项目组走查工具，整体走查代码情况，提供违规报表等;第三类是Review条目执行跟踪工具，跟踪每个条目的执行情况。通过这些工具的使用，大大增加了代码的透明度，提高了代码Review的效率和效果。 通过这个故事，我的体会是，作为一个项目“管理”者，既要“管”，更要“理”。“管理”这个词其实应该调过来叫“理管”，即项目经理要能首先找出问题，先把事情理顺，让每个人都明确自己的位置和方向;接着，就是要管，而且要高效的管。有道是“欲善其事，先利其器”，“管”作为一种器，项目经理要思想开放，用于创新，尽可能的使其“利”起来。当然，在管的过程中，又会发现新问题，从而再理，如此反复，最终把事情做好。 故事三： 通过积累并分析历史数据来提高估算准确度 在TSA后期，特别是Victory Release中，很多需求都是基于现有系统的增强工作。这类需求的特点是单个需求的工作量不是很大，但是很多、很杂。因为没有一个成熟的估算模型可以套用，这给项目工作量估算带来了难度;还有一点是，PMO会在需求还不明确的情况下要求大家给出估算，目的是利用每个系统的估算排出主计划。为了很快给出估算，大家完全凭借经验。根据我们的统计，单纯凭经验做出来的估算，有大约84%的需求估算误差都在50%以上。 为了解决该问题，我们引入了一种基于经验矩阵的类比估计，把它称为ETF(Estimate-Track-Feedback)方法。这个方法可以用图2表示： 图2 基于经验矩阵的类比估计 这个方法分成三个步骤： 第一步是估算(Estimate)，首先要确定需求的分类，然后根据分类与经验矩阵进行对比，找到以往类似需求的工作量作为参考;如果在经验矩阵中没有记录，则引入其他专家进行集体会审，把会审后的结果作为初步估算; 第二步是跟踪(Track)，在项目执行过程中，设有一个估算执行记录库，记录每个实际需求的最初估算量，一旦录入，该指标不能随意更改，同时， 在日常工作中，会要求开发人员随时更新在该需求上投入的时间，并对这些时间进行分类，比如，是沟通相关的，文档整理相关的，开发相关的等等。这是这个模型的关键点，因为这些数据的准确性将会影响在经验矩阵中的数据可靠性。我们做了两件事情来保证，第一提高开发人员的积极性，跟大家进行深入沟通，阐明这样做的目的是为了积累工程数据，并不是作为考勤，不是用来监督大家的工作;第二，要求每个系统的负责人按时检查这些数据的完整性和准确性，并将其作为考核指标。 第三步是反馈(Feedback)，在项目后期，会根据估算执行记录库中的内容进行分析总结，首先会统计估算偏差，然后对于偏差较大的项目分析原因，基于这些结果，将一些有价值的指标反馈到经验矩阵中。 通过这个模型的建立和使用，估算的准确度得到了很大的提高，而且更加迅速，更为重要的是，因为有了工程数据方面的积累，在和业务人员的沟通上有了更多的数据方面的支持，表现的也更加自信。 |
| 思步组织：思步科技|思步网|火花学堂|思步文库|思步问答|思步英才|天下心 |
| © 2007 思步网 浙ICP备10212573号-4(首次备案号:浙ICP备07035264号)|邮箱：service#step365.com(将#换成@)|服务热线：0571-28827450 |
| 在线培训课程|求职招聘|思步文库|官方微信|手机APP|思步问答|微博平台|官方QQ群|交流论坛|软件工程透析|关于我们|申请友链| |
| 思步 step365 过程改进 CMMI中文 质量保证 质量管理 流程体系 需求跟踪矩阵 敏捷开发 Scrum 软件度量 项目评审 全员改进 流程管理 人力资源 6sigma 信息安全 ISO27001认证 IT服务管理 ISO20000认证 ISO9000认证 软件测试 SQA 配置管理 IPD 软件工程 PMP认证 PMP试题 PMBOK中文 精益研发 agile 顾问式管理培训 |
service@step365.com
0571-87357690
