系统1.0版上线的前前后后

　　有段时间没上博客了，原因挺多，最主要的应该是最近一段时间的工作让自己没多大感觉，没什么新东西可写。今天是我的系统1.1版上线要求的时间，大家可能会奇怪，怎么突然跳到1.1了，以前说的都是1.0嘛，呵呵，别着急，这就是所谓“前前后后”由来。

　　1.0版上线的前前后后主要有这么几个事：

　　一、迭代周期被定下后，每个迭代周期的实现范围（后来被证明过于模糊）和时间就确定了，共分为三个版本。6月20日即1.0版的上线时间。1.1版的诞生就是因为迭代周期实现范围的不明确造成的。5月中下旬都是合作商的开发时间，5月下旬的一次项目双周会上，当我结合系统讲解第一版的实现目标时，需求部门提出了异议，需求部门认为已经应该在第1版安排实现的需求，在我的理解却是在第2版安排的，当时时间已经比较紧了，最后大家讨论的解决办法是加一个修正版本1.1，在1.0和2.0之间给出一周多的时间，在6月30日实现，也就是今天。

　　二、我检讨一下，我对合作商还是太放心了...。我高估了开发商的能力，认为把业务范围圈定，形成方案交给他们，他们就可以按步就班的实现。这里我也确实有些偷懒了。5月下旬当开双周会的时间，我看到了一个雏形版本，我很震惊，完全可以说是很烂，很多1.0版功能的完成度相当低，就别说成熟度了，完全达不到项目计划的要求。其实在此期间，我就对最初的原型提出过异议，但我提出的很多意见没有得到落实。后来总结了下，主要原因就是没有签发确认，虽然都有纪要，但没有引起合作商足够的重视，当时的解决办法是，我就把雏形版本当作最初的设计，我要求合作商于6月1日进驻开发，这样做的目标是解决沟通成本和问题改正得不到及时落实的问题，毕竟距离6月20日也仅三周的时间。对于我以后工作的借鉴就是绝不要相信开发商所谓的实力，需求、分析和设计一步也不能少，要全程跟进，并讨论审核各个交付物。

　　三、经过三周的紧张现场开发，我的很多想法和意见大部分得到了落实，这其中和合作商也起过几次冲突，闹过几次矛盾，不过还好都一一化解了，也算对自己的一个锻炼。合作商已经很辛苦，天天加班，但距离1.0版的目标还是有些差距，但我作为甲方，这个里程碑的时间点是不能改的，为什么不能改呢？因为关注度太高，轻易变动的话对我们IT部门是很不好的。不能改就只有裁减功能，经过对一些不太重要的功能进行了调整，总算有惊无险的准时完成了1.0版的上线。

　　四、1.1版范围内需要实现的重要功能在合作商的配合下，也于上周实现了个大概，但还是漏了一小部分，我现在就在等合作商过来，看看他们周末加班实现的成果，我想问题应该不大，等这块搞定了，我下午就可以发1.1版的上线通知了，需求方的满意度应该就可以照顾到了，相关业务测试工作也就可以正式开始了。

　　总结以上几点，分别就是重新定义目标、优化设计、裁减需求和满意度达成。定义目标和优化设计是我在前期工作中做的不够或者没有做好的，裁减需求是在时间不能变不得以而为之的，实际上项目进度还是拖延了的，这是一个隐患，要在后续工作中慢慢解决。满意度的问题则是贯穿整个项目的，必须时时刻刻注意，毕竟项目管理的最高境界就是“和谐”，利害相关方都和谐了，项目就成功了。

　　最后说一点的还是迭代，迭代真是好东西，只要你坚持迭代，不管你第一次的迭代目标是否得以实现，但只要你做了，你就会发现项目问题。你要意识到发现项目问题不是坏事，它给了你解决项目问题的机会，每一次迭代就象一个子项目，出了问题你还可以在后续子项目（迭代）去解决，你还有回旋的余地。如果就是一锤子买卖的话，你就只有两条路了，一是延期，二是失败。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/1673/viewspace-366382/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/1673/viewspace-366382/