本文可以任意转载或分发,但请注明作者和出处。

   面临的困难很多，如何能够在两个月时间内完成这么一个项目？我们还是一步一步的来看看把。

   项目组在项目启动之日（2005年7月4日）成立，当时的项目组的组成有PM、QC、 TM和QA各1名，高级程序员（其中一名从公司其他部门借调过来，时间到8月底）2名，中级程序员3名，初级程序员2名，还有一个mm（需求人员/集成测试人员/文档编写人员）。幸好，项目组中有多名团队成员参与过第一个项目（国库集中支付）的开发，积累了不少的经验。

   项目采用跌代的开发方式，其中一期beta版本在7月底发布（以提交给客户做评审为标志），release版本在8月15日发布；二期beta版本在8月15日发布（同样，以提交给客户做评审为标志），release版本在9月5日发布。从最后的结果来看，当时错误的估算了二期的beta发布时间，直到8月22日（其实这个时间发布beta版本客户也应该是接受的）才发布，延期一周。

   为了规避需求风险和技术风险，7月4日－7月8日，需求开发人员天天缠着客户（mm就有这样的好处了，换成个大男人天天缠人就不太好了）确认需求，同时组织技术评审，定好大体的开发和技术框架。

    由于不熟悉业务，只得采用驻客户现场开发的方式，但有些团队成员（1高级程序员，2中级程序员）有其他任务在身，不能在客户现场开发。迫不得已，安排他们在广州开发一期，项目组主力驻客户现场开发二期，分为两条开发主线并行开发。当时错误的估算了一期的工作量和高估了广州开发人员的能力，在Week1结束后（7月15日）发现广州开发小组只是做了几个还没有完善的jsp页面，其他什么都没有，进度已经严重滞后。当时分析的原因有那么几点：

i.    广州那边的开发人员没有参与第一个项目的开发，技术积累不够，业务知识积累不够。

ii.    由于需求是在客户现场捕获的，通过msn等交流工具存在很多的沟通问题。

iii.    开发人员的能力确实不够，短时间要求他们的生产效率大幅提高不太现实。

iv.    迫于时间的压力，没有做技术框架的Demo和完善的架构文档以及技术说明，直接导致了代码的不规范和实现方式的不统一，直接影响了一期的开发效率和进度的滞后，因为一期的开发人员大多是新手，希望他们几天时间了解struts、dao等等确实是勉为其难。

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