思步网

标题: 项目经理成长记-14：联想TSA项目往事 [打印本页]

作者: 总是一个人忙 时间: 2013-7-10 12:55
标题: 项目经理成长记-14：联想TSA项目往事
本帖最后由总是一个人忙于 2013-7-10 12:58 编辑

项目经理成长记-14：联想TSA项目往事

联想在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)，在项目后期，会根据估算执行记录库中的内容进行分析总结，首先会统计估算偏差，然后对于偏差较大的项目分析原因，基于这些结果，将一些有价值的指标反馈到经验矩阵中。　　
         通过这个模型的建立和使用，估算的准确度得到了很大的提高，而且更加迅速，更为重要的是，因为有了工程数据方面的积累，在和业务人员的沟通上有了更多的数据方面的支持，表现的也更加自信。

作者: minnie 时间: 2013-7-13 12:57
众里寻他千百度，蓦然回首在这里！

作者: mickey 时间: 2013-7-13 15:34
还不错哦，如果再能多分享一些就perfect了！

作者: alfonse 时间: 2013-7-13 17:12
还不错哦，如果再能多分享一些就perfect了！

作者: 背光，世界 时间: 2014-6-23 10:37
前排支持下了哦~

作者: 情比纸薄 时间: 2014-10-7 19:25
以我的经验来看，楼主的想法是可以执行的~

作者: 橙子女 时间: 2015-3-25 14:24
顶不错支持下

作者: 笑淡了就罢@ 时间: 2015-5-4 07:11
我了个去，顶了

作者: 无边雨丝 时间: 2017-9-3 08:36
好帖是需要鼓励的~

作者: 独恋ヽ花尽散 时间: 2018-3-16 08:40
这么强,支持楼主，佩服

作者: 夏天 时间: 2018-10-21 08:50
看帖要回，回帖才健康，在踩踩，楼主辛苦了！

作者: 矫情什么！ 时间: 2018-11-29 14:31
打酱油的人拉，顺便赚点金币

作者: 时光暖心i 时间: 2019-9-14 12:30
好帖是需要鼓励的~

作者: 悲魂曲＠ 时间: 2019-10-26 09:08
向楼主学习

作者: 狼少° 时间: 2020-5-8 21:36
支持，赞一个

作者: 大嘴巴@ 时间: 2020-10-9 15:01
看了LZ的帖子，我只想说一句很好很强大！

作者: 留不住的对白 时间: 2020-10-30 12:08
不错支持一个了

作者: ぶ牛仔↘酷 时间: 2021-1-31 09:43
我了个去，顶了

作者: 少年不知 时间: 2021-6-7 07:27
路过帮顶嘿嘿

作者: 执酒笑白衣 时间: 2021-7-30 15:49
我了个去，顶了

欢迎光临思步网 (http://www.step365.com/)