关于了解并理解客户需求（二）

对于手机项目，在需求确认的时候尤其要注意的有以下几点:

1. UI: 如果客户提供好design work，那最好。对于没有design work，只是对界面进行简单描述的specs，一定要注意和客户先说好，我们可以先把这个UI design先做出来，等待客户确认，在确认完成后，再进行后面的功能实现。在UI这一块估计时间时，可以把这块的时间估计松一点，记得考虑进项目沟通的时间及成本（当然这是后面要讲的项目时间估计这块了）；

2. 功能：如果客户的specs没有操作流程图，那这份工作最好自己先做好，别以为这样浪费时间，这将为后面麻烦节约很多时间；

3. 测试环境：手机项目与web项目有一点不一样，测试的环境往往不是唯一的，即便同一类手机操作系统下也有多个版本，所以在需求确认环节，一定要问清客户这个项目是想在什么手机平台，基于哪一个或者哪几个OS版本实现，确认好后，最好选定好测试手机的型号，这样，你开发时基于的手机和客户手上的测试机是同一个，后面牵扯的问题也会尽量减少；

提到这点，我想举一个曾经做过的windows mobile项目为例：这个项目的需求文档算是A类，客户对各个方面已经有了明确的说明，我们也和客户开了很多次会议进行了确认，但后面这个项目最失败了。

原因是我们对测试平台理解的误差。了解WM平台的朋友应该都知道windows mobile手机主要分为三大类： standard, professional, classical。Professional和Standard的手机其实都是smart phone,不一样的是Professional手机是触摸机，而Standard则是带键盘的。而classical手机则多是我们说的Pocket PC, 基于Windows Mobile平台的一种PDA。

在我们接到这个项目的时候，市场大部分手机都是触摸式的了。在客户需求文档上已经选定好了一款测试手机，但因为这款手机主要在日本推广并使用而且当时已经停产，在中国非常难找到这款手机做为测试机，于是，我们和客户发了正式邮件要求更改测试手机，并选定好另一款手机等待客户确认。客户方主要负责项目的两个发言人都同意了我们的方案，决定重新采用我们选定的那款手机为测试机。

当我们项目功能已经实现等待客户测试的时候，出现了种问题。后面我们才知道，客户仍然在用那款他们在初始文档中指定的standard WM Phone做测试，问题的关键是：客户初始选择的测试机是Standard版本手机，而我们后面和客户确认好选择的手机是Professional的。

在我们重新选择测试手机时，我方其实当时也怀疑过这个问题，因为客户的选定的测试手机其实是standard的，而我方后面选择的却是一个professional WM phone. 不过，我们当时想当然觉得市场当时主流手机是触摸式手机，客户做这样一个应用当时是要呼应市场要求。加上客户邮件回复同意我们的方案，我们也就没多提这一块。

最后项目的结果是，客户做这个应用是为了一款standard手机定制的功能，后面因为deadline赶不上，我们不得不停止这个项目。幸运的是，我们在邮件中和客户已经确认了测试手机更改问题，而且是经过客户方确认的。所以，客户方也对项目的失败负有责任，给我方支付了成本费用。

但这样的事情谁也不想以后再次发生，所以，在以后的手机项目中，我一般会和客户先把测试手机平台和测试手机型号确认清楚后再开始项目。