|
联想在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的系统，来完成这个配置工作。该系统的功能简图如下：www.mypm.net
项目管理者联盟
图1 LOIS功能简图项目管理者联盟
图中三条横线(MTM，CTO和Service)分别表示三种产品类型，箭头表示这些产品由PLM系统产生，经过LOIS配置，最终分发给CRM和E-commerce系统。项目管理者联盟
图中三条竖线(“抽取”、“配置”、“分发”)分别表示LOIS的几大功能点，“抽取”就是数据抽取，把相关的产品信息从PLM系统中抽出来，处理数据转换、建立产品的结构关系(BOM)等;“配置”即配置产品附加属性、多语言、记录版本信息等;“分发”则是把配置好的产品根据规则分发给不同的系统。竖线宽度表示工作量大小。项目管理论坛
最初的分工是根据业务特点分成三个小组，分别负责MTM、CTO和Service，三个小组并行开发。但是在做的过程中，我们发现这种分工并不科学，主要问题有：项目管理者联盟
1. 功能重复很大，很多类似的功能三个小组分别都要做一次，窝工现象很严重;项目管理者联盟
2. 不同小组出现相同问题的概率很大;项目管理者联盟
3. 三个小组并行开发，大家进度基本相同，没有办法将其中的任何一个业务模块提前交付用户。项目管理者联盟文章
为了解决这些问题，我们重新检查了分工模式。通过分析得出，这三个业务模块看似独立，其实有很多共性，而之前的分工并没有很好利用这一点。随后我们进行了调整，把原来的横向并行模式，改成纵向流水线模式，还是三个组，但是分别负责 “抽取”、“配置”和“分发”;根据任务量的不同，对各小组人员重新进行了配置;同时选择业务相对简单的Service部分作为突破口，尽快调集资源完成这一部分。调整后的分工使得各个组的开发效率提高很多，很快地完成了一条完整的业务流程，大大缩短了用户交付周期;通过这条业务流程的走通，为其他两个业务流程提供了一个很好的基础;同时还发现，代码质量也较之前有很大的提高。项目管理者联盟
通过这个事情，我有下面一些体会：转自项目管理者联盟
1. 合理的任务分解对团队工作效率的提升举足轻重;talent.mypm.net
2. 达成一个合理的任务分解要求对业务和技术方案有充分理解，要从业务、技术等不同维度去分析，也要从不同的角度、全方位的去看;项目管理者联盟
3. 不能认为第一版的任务分解就一定是正确的，项目经理要随时通过进度、质量、资源使用的实时情况反思其合理性，要能及时调整;service.mypm.net
4. 合理的分工还能为敏捷开发提供基础。项目管理者联盟
故事二， 改进的流程来改善代码Review效果talent.mypm.net
在做Olympus Release的时候，有大概十多个系统同时开发，开发人员来自不同厂商，技术水平、开发习惯各不相同，而且大家都没有经过充分培训就直接投入项目。为了确保开发质量，我们成立了一个方案团队，投入了大量的精力进行代码Review。采用的是会议Review的形式，即要求各个系统的开发人员全部参与。项目管理者联盟
但在实践中，我们发现这种方法执行下来的效果并不是很好，主要表现为下面两个问题：项目经理博客
1. 关键业务点的Review不能保证。存在太多的诸如编码规范，变量命名等初级问题，使得团队的注意力不自觉的转移到这些问题上面，关键业务逻辑的Review没有办法保证;项目管理者联盟
2. Review频度很难平衡，执行效果不理想。太频繁，开发时间没有办法保证;太稀疏，一次Review的结果太多，受限于项目进度和其他方面的压力，很多时候开发人员没有办法进行改正。正是这种矛盾的存在，使得Review也渐渐地流于形式。项目管理者联盟
为了改变这种局面，我们从两个方面进行了改进：第一，从角色上明确了开发人员和方案团队Review的侧重点，具体来说，凡是有明确标准说明的，诸如编码规范，命名规范等都有开发人员负责执行;凡是核心业务逻辑，架构，性能等没有办法用标准量化的东西都由方案团队负责;第二，我们明确了会上会下的工作，所有开发人员负责的内容都在会下完成;只有方案团队关注的内容会在会上讨论。项目管理者联盟
为了确保执行效果，我们引入了一系列工具。这些工具分成三类，第一类是开发人员自查工具，嵌入各自的IDE环境中，提供随时检查;第二类项目组走查工具，整体走查代码情况，提供违规报表等;第三类是Review条目执行跟踪工具，跟踪每个条目的执行情况。通过这些工具的使用，大大增加了代码的透明度，提高了代码Review的效率和效果。项目管理者联盟
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
