2.4 Web站点项目的途径
理论上，Web站点工程很有道理，但在实践中，它是否奏效呢？答案是完全奏效。然而，由于Web是一个新兴的领域，站点开发很少一致，如显著的时间限制以及项目不断改变的特性。开发者应该小心地继续。为了指导开发，在项目之初，就应该采用某个进程模型。如果站点是崭新的或增加起来非常困难，就应该采用瀑布模型或带有涡旋的修正瀑布模型。如果项目是有关维护的，比较简单并有很多未知的因素，那么联合应用开发方法就比较适合。不考虑项目本身，第一步通常都是相同的：那就是确定项目的整体目标。
2.5 目标和问题
很多站点因为缺少清晰的目标而最终失败。在Web开发的前几年，很多公司创建站点的目的很单纯，就是为了显示公司有站点。不知何故，没有站点的公司会被认为缺乏改革精神，不能作为市场领导者。有站点的竞争者会被认为危险。很多时候，站点很少赢利，而建设的原因仅是为了显示公司的存在。随着Web站点的盛行，创建站点的原因越来越明显。今天，站点的目标变得更重要，而且显示的方式越来越清晰。然而并不能因此主观地认为理念统治了站点—很多的站点项目开发纯属出于乐趣或因为察觉受到了危险，而不是为了解决真实的问题。为Web站点提出一个目标并不很困难；问题在于提炼目标。警惕诸如“为用户提供更好的服务”或“通过开发在线市场而赚更多的钱”这样非常模糊的目标。这些可以作为项目的合理想法或一般目标，但目标需要更详细的陈述。好的目标陈述可能有以下的内容：
建立支持用户的站点，通过提供全天候的用户问题答复，提高用户满意程度，从而降低 2 5 %的电话技术支持。
创建一个在线的汽车零部件商店，每个月直接向用户销售一万美元的零部件。
建立一个日本餐馆站点，通知用户有关时间、菜单、氛围以及价格等信息，以鼓励用户通过电话预定或访问站点。记住，以上三个目标的陈述中，有两个目标是可度量的。这在做实际的财政预算时，非常便于确认项目的成功与失败。第三个站点目标的陈述无法度量。这么做非常冒风险，因为不能让别人确信站点是成功的，或以某种方式度量站点。在餐馆信息站点中，站点访问者的预定数目或用优待券来度量站点访问人数会很有帮助。考虑以下修正的目标：
建立一个日本餐馆站点，每个月通知3 0 0个潜在用户有关时间、菜单、氛围以及价格的信息，以鼓励用户通过电话预定或访问站点。简单的增加特定的访问人数会让目标更起作用。通过规定期待的访问人数，餐馆拥有者可以在效率相同的调查速度下比较通过印刷品或收音机做广告和运营站点之间的优劣。
2.5.1 集体讨论
一般来说，提出目标是非常简单的事情。最重要的问题是让目标的陈述简明和可现实。在很多Web项目中，有在站点中包容一切的倾向。记住，一个站点不可能满足所有人的所有需求；在心里一定要有特定的用户和特定的任务。为了确定目标，集体讨论是必要的。集体讨论的目的是尽可能提出有关站点的想法。在集体讨论时，一张黑板是非常有用的，可以用来快速记下和修改有关站点的想法。
通常，集体会议会偏题，因为参与者离题太远或讨论了太多的关于站点的哲学问题。在这种情况下，最好集中于大家一致感兴趣的问题。通过让大家讨论在站点中不希望见到的特性，以确定关于站点的一般设计哲学。让参与讨论者意识到他们不希望站点太慢，或难于使用，这些通常很容易。一旦集体统一了一致目标，哪怕这些只不过是一些关于站点不应该太慢的看法，未来的探讨以及关于站点应该做些什么的陈述都会更加顺利。
注意在指导重做某个站点的项目时，一定要注意不要召开集体会议来斥责既存站点中出现的问题，除非项目中的参与者与站点没有任何关系。一个万无一失的防止项目偏离的方法是让站点的原来设计者来为自己遭到的批评进行辩护。记住，人们不得不设计站点，所以组织一支积极的设计队伍是非常重要的。
2.5.2 缩小目标
在集体会议中，所有想法都是很了不起的。会议的要点是挖掘各种各样的被称为“愿望清单”的想法。“愿望清单”就是描述各种不考虑价格、可行性、可应用性的有关站点的想法的文档。然而，最终的“愿望清单”会缩小为有关站点的合理和合适的部分。这对有着各种各样可能目标的站点来说非常具有挑战性。例如，考虑某个公司的站点，包括产品信息、投资者信息、新闻稿、职位申请以及技术支持等部分。每一个负责相关部分的人都会认为他们的那部分是最重要的。每个人都希望把他们的那部分的链接体放在主页上。在那么多方案中权衡确实是非常困难的。
另外一种缩小目标的方法是使用小的纸片或3×5的卡片。把每一个想法写在卡片上并堆起来。接着再让每一个人依据重要性，每次从卡片堆里抽出一张。当然，一定要限制从卡片堆里抽出的卡片数量。以这种方式非常有希望挑出重要的想法。不幸的是，依靠集体，这种运作很可能失败—尤其是当参与者在各自的领域扮演着很重要的作用时。
