项目管理手记：迭代式开发进度控制VIP

? ? ? ? ? 项目管理手记：迭代式开发进度控制 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ???? 02年11月15日刚到公司2个月的我被软件事业部老总T指定负责公司旗舰产品EC网络分销系统开发的管理工作。 　　现在（03年4月1日）根据我的规划，EC产品的1.0版本已经进入测试阶段，目前一切顺利进行，老T对我们的工作成果很满意。 　　回顾5个月的产品项目进展，感受颇多，完完全全是一个困难一个困难解决，一步步走过来的。我以为软件开发实践中的经验教训、感受比抽象的项目管理理论更难得，特于项目空隙做此总结，希望与有志于企业级应用软件产业化的诸位同道共享，交流提高。 　　计划 　　计划定义的是项目的目标是什么，为什么？在这个职能的执行中，项目开发组的任务、目标、具体目标和战略被确定。 　　即使在软件开发领域之外，人们对于事物的处理总有惯用的思路。我的定式是：“我的目标是什么？我的起点是什么（包含拥有的资源）？从起点出发需要经过哪些途径可以达到目标？”这个自觉的思维模式非常有效，无论项目大小，它包含了朴素的管理思想。 　　公司资本雄厚，对于EC产品的战略构想是，1为地域分散（可能是全球）的分销企业提供提高业务管理效率的软件产品；2该产品的应用是基于Internet；3该产品的应用部署问题及安全问题与专业厂商协作解决，产品的核心竞争力在于业务处理。 　　EC项目组组建仅仅3个月，人员背景基本分为两部分：软件开发、视觉设计。软件实现业务以满足下属一IT硬件分销企业为目标，该企业营运总监（MBA出身）负责与软件事业部协调软件开发，事实上该企业业务量暴涨，分销渠道遍布全国，迫切需要一套网络管理软件。 软件工程的“迭代式开发”已经逐渐取代“瀑布式开发”成为主流。所谓“迭代式开发”，根据我的理解说白了就是象爱因斯坦那样做小板凳，终极的理想板凳就是不断修正前面板凳错误的后一个板凳，“最好的是下一个”。“迭代式开发”与“瀑布式开发”存在本质的不同，传统“瀑布式开发”的出发点是务求各个开发阶段的成果都是最优成果，无需变更。而“迭代式开发”则是假设各个阶段的成果都有优化、变更的余地。我们采取了“迭代式开发”，当前工作围绕的核心是如何使未来的变更、优化变得容易。 　　应用“迭代式开发”，公司的产品战略是可以通过N次迭代实现，问题是资本的耐心常常是有限的，产品经过趋向于无穷大的N次迭代肯定会日臻完美，但我们必须使资本在每次迭代中看到利润。换句话说，产品的开发必须结合商业成功的良性循环中。 　　经过以上分析，我确定了项目组的产品目标：5个月完成软件的1.0版本开发，7个月后完成该产品在公司下属企业的上线运行。时刻谨记的核心任务是确保当前开发模式的可复制性和当前版本的可重用性，目前的工作是为了将来修改的简易性。 　　计划上报后获得通过，给项目组和客户（下属企业）都带来了压力，大家开始为共同的7个月的里程碑奋进。 　　7个月的时间内我们又细化为两次迭代，每次的过程分为：需求分析、系统设计、代码实现、系统测试。 　　组织 　　阶段目标确定后，达到目标要完成的工作立即浮出水面，这样依据任务安排工作，人员调配的问题很快迎刃而解。 　　“韩信用兵，多多益善”，根据我的计划，项目组的人员配置应该是足够的，可是经过几次人员安排的反复，我的结论是成功的关键并非兵精将广，而是项目组的每个人都能各司其职，完成份内的工作。 　　项目组最多时参与的人员达到15人之多，但根据项目阶段的需要、公司其他任务的安排以及IT企业员工的正常流动，每个阶段参与项目的人员数目都不相同，但直至项目基本完成，团队仍然保持着强劲的战斗力，保持了正常的动态平衡，项目没有因为人员问题影响进度。 　　项目需求调研、分析阶段，共有9人参加，编为三个小组分别同不同部门就不同业务内容展开交流，并完成业务活动分析。9人中的4人成为项目后续进程中的核心力量，积极参与完成了项目。 　　系统概要设计阶段有6人参与，完成数据库设计及界面风格、功能实现模式设计。详细设计由4人专职进行，主要任务为页面表现及功能逻辑设计，设计成果以WORD文档方式向页面程序员与组件程序员下发。 　　代码实现包括组件代码编写和前端页面编写、组件调用，6名程序员分为3个小组。 　　单元测试由2名测试人员（非专职测试）在项目后期逐步完成，系统联调为项目组9人最终分担测试完成。 　　人员组织中值得强调的经验是，“龙生九子，各不相同”，核心工作必须花大力气安排项目核心人员完成。EC项目中人员分工非常精细，设计人员无须编码，但他们的设计文档极其详尽，使编码工作变得简单、纯粹，大大减轻了工作量。设计人员同时又是功能实现的原始驱动，他常常要牵头主动与页面人员、组件实现程序员协作沟通完成工作。 [Ne