“最困难的Web开发经历”之三

我下功夫创建了一个比较智能的搜索引擎。要查邮政编码的话它就会去查找邮政编码，而不会去找电话号码。要查电话号码的话，它也不会去查找邮政编码。我对这个脚本相当满意，但是我的客户却不满意。例如，当你输入“Knot Garden”的时候，你得到了一个“Knot Garden”的列表，以及做这样一件事的公司——Knot Garden导游。我的客户认为这太模糊了。他要的是Knot Garden的列表，而不是与之相近的旅游指南。他对搜索的结果过于挑剔——他希望结果能够有意地忽略掉一些非常接近的匹配结果。他说他在自己的数据库里就是这么做的，但是他却不愿意给我看，这样我就只有照抄原来的。我再次向他屈服，复制了他原来的东西。

面对面的交流是个噩梦。当我问一个问题的时候，我的客户就转到计算机上，去做他那些深奥的数据库查询去了。他有时候花的时间太长了，以至于我都忘了要问什么。有一次我要问一下旧列表自动过期的日期时，我花了90分钟才得到答案。

他的门户网站里有2,500个列表。有一地区可能有6,000个潜在的列表，这是值得称赞的。他的竞争对手只有大概200或者300个列表。我担心的是，任何严重的迁移错误都会让他失掉这2,500个客户以及上万美元。由于这个潜在的风险，我催促他指定一个迁移计划以及切换到新系统的时间，这样我们就能够向他的很多客户发送提示信息。

然后，出现了一个小细节。这2,500个客户中只有6个是付费客户。而其他的人之所以被列出来，是因为我的客户太希望拥有一个完整的列表了，以至于他免费列出了一些人，而当事人并不知道。他把自己逼到了死角里。既然他们已经被列出来了，他们为什么要付这25美元？为什么其他99％的成员都不付费，而剩下的1％却要付费？如果他取消掉未付费的列表，那么他的网站看起来就会和他只有几十个列表的糟糕竞争者一样。

这个网站还有1,800分类来追踪这2,500个列表。当官的太多，而当兵的太少了。就像Yahoo一样，这里所有的分类都按照子类来分层。当用户碰到分类的时候，他很快就转晕了。一个典型的例子是：“餐馆：桌餐和外卖：外卖：汉堡包。”我想，如果将“桌餐和外卖”作为一个子类，那么其他类型的餐厅都该放到哪里去呢？（可能有什么“门口”进餐的经历，让他们在门口摆张桌子，在那个地方吃快餐。）更糟糕的是，还有600个空的分类——完全都是空的——而另外700多个里面只有一个条目。这又是另一个致命之处。

最终，他得到了我所许诺的网站，加上一个电子商务的组件和很多额外的工作。完成它所花的时间要比预计的长，但是这要算上得到每个答案所要花去的90分钟，以及他为了防止我照搬原来功能而扣留的脚本，还有我必须通过“请神会”才创建的数据库，再加上对（稳定）运行10个月的契约保证。他得到了他想要的。

我们应该吸取什么教训？

Mike的经历是一个很好的例子，它道出了百般刁难的客户的自相矛盾的要求所造成的挫折。你有合适的计划或者系统来处理由客户导致的特性上的折衷或者中途对设计规范的更改吗？将你的经验技巧同我们来分享，以帮助其他人避免Mike所经历的挫折。