QA Review - A Risky Project

    A公司进行W项目已有数月。项目的内容是要对公司现有几个系统的功能作整合，向客户提供统一的访问界面。此外，整合后的系统还要向公司新购进的一套自动化系统提供监控接口。项目计划在2个月后向客户交付可用的系统。
    A公司向该项目投入了3个人力：1个PM加2个工程师，另外考虑到工期及成本的因素，还找了3名在校实习生参与开发——这跟业界的普遍状况也差不多。

检查项目目前进行的状况，把发现的问题抽一些列出来：
1.RISK: 使用AJAX，改变开发方式，增大了项目风险。

目前AJAX技术大热，该项目又有部分UI的需求比较复杂，所以负责项目开发的工程师决定导入AJAX来实现。以公司现有的状况，工程师大都习惯于传统的JSP编程，而引入AJAX将改变其熟悉的开发方式，此外，AJAX引入后对于系统原有架构所具备的诸多特性倒底会有哪些影响还未可知。在未作过原型验证的前提下即匆匆上马，将给项目带来不可预知的影响。

2.RISK: 使用在校学生开发，毫无经验，增大了项目风险。

一群懵懵懂懂的在校学生来公司实习，培训2周后交出的测试答卷惨不忍睹。这种情况下老板还是留下了大部分人来“补充兵力”。其中有3人加入了该项目的开发，从该项目的人力结构来看，这3名学生才是开发代码的主力军。以这样的开发队伍来作系统开发，不禁要为系统质量跟项目工期捏一把汗。

3.Bad Practise：项目策划及系统设计时间相对过长，迟迟未进入开发阶段。

项目进行数月，大量人力耗费在跟客户及自动化系统提供商的确认会议中。需求一再改变，这本身应是正常状况，然而项目组却在需求问题上跟客户及第三方厂商过多纠缠，并在系统架构确定上踟躇再三，又未实际作出架构原型进行验证，以至耽误了项目工期，至今未进入实质开发阶段。2月后即需向客户交付可用的系统，却至今未交付一版可运行的系统，哪怕是初版。以上是不符合系统迭代开发的原则的。

    如果说一个成功的项目是要在给定的时间及资源的条件下向客户交付合乎功能与质量要求的应用的话，那么依该项目目前的状况来看，不能成功的风险是比较大的。2个月后该项目的进展究竟如何？QA拭目以待。