本人也是第一份售前工作，以前是做开发和实施工作，刚开始有点掌握不到售前工作的一个“度”，现在把这段时间的售前工作经验记录一下。
售前和售后工作不一样，售后工作是需要了解需求，直到能够进行开发的程度，系统设计、概要设计、详细设计、代码开发、测试、上线、验收一套完成的流程。售前工作对需求到底要了解到什么程度；给客户提供的文档要细化到什么程度；公司允许投入到什么程度；还要避免我们做好了铺垫，结果客户按照我们的方案，找其他公司合作了；我是一个售前的小菜，真的彻底迷茫了。
售前首要的工作就要了解客户的需求，要想项目成功，可离不开项目涉众的支持。在项目一开始，不论是项目涉众还是开发人员，对项目的任务、范围都是模糊不清的。但随着项目的深入，原来模糊的景象会慢慢清晰、立体起来。但是为了不浪费时间，我们有必要在项目射入之前，现在项目涉众中竖立一个共同的愿景。
共同愿景的竖立可没有想象中的那么简单，因为每位涉众都关心自己的利益，都有自己的评判标准。你可以把大家的意见都列在白板上，然后逐项集中讨论，做出修正，直到大家的意见一致的时候为止。在共同远景的竖立过程中，其实有两件事情也已经同时做了，项目范围（scope）和高阶（high-level）需求。
项目范围：项目该做什么，不该做什么，需要在一开始就有明确的定义。对于项目范围内的需求，一个也不要放过，而项目之外的，一个也不要去关心。虽然有的时候，范围的变化会有利于项目本身，例如客户的合理要求或是市场目标客户的变化，但是这种变化应该要在"资源能够支持"和"得到审批"的前提下进行。
项目范围的描述可以通过陈述和图示来进行。我建议大家使用图示。因为陈述语句比较含糊不清。例如常常听到有客户说。"我要建立我公司的电子商务系统。"这句话就是含糊不清的，你的电子商务系统是销售什么产品？面向什么客户？是否要支持在线支付？根据这些疑问，这个陈述句可以做进一步的修改，"建立在线订货系统，针对当前的目标客户销售公司的目前产品。"这样就清楚许多了。不过图示的方法会更好一些，在图的选择上，你可以使用DFD图或是用例图。根据经验，DFD图比较容易为客户所接受。
高阶需求：这个部分我们在下面会详细讨论。既然是高阶需求，就不能讨论过多的细节。在讨论高阶需求的时候，尽量保证快速的讨论出系统的概貌，建立需求模型，得到项目涉众的一致通过。
取得支持：为了保证需求计划的顺利进行，取得项目涉众的支持至关重要。你可以选择在这个时候告诉项目涉众他们的权利和义务，以及开发人员的权利和义务。主要的就是"涉众有改变需求的权利，同时要承担向开发人员讲解需求的义务。"开发人员的权利和义务正好和涉众相反。
业务建模是需求工程中最初始的阶段，也是整个项目的初始阶段。需要指出的是，业务建模时间的跨度在不同的项目中有很大的差别的。在有些项目中，例如大型ERP系统，可能需要几个月的时间。而对于普通的项目，业务建模的时间可能仅仅需要几天的时间。
需求是技术无关（technology independent）的。在需求阶段讨论技术是没有任何意义的。那只会让你的注意力分散。技术的实现细节是在后面的分析、设计阶段才需要考虑的事情。而在业务建模阶段，不但要保证需求的技术无关性，还要保证你的需求不要深入细节。因为在业务建模阶段，最重要的事情就是要了解业务的全貌，深入细节会浪费时间和精力。要知道，讨论一个企业里的业务细节，就算给你一个月的时间也没必能够结束。
在实际中，这两点都是很难做到的。例如企业原先有一个系统，这就不得不由你讨论和新旧系统的兼容问题。这时候就要注意，如果你是讨论就有系统的架构的话，那还是属于技术无关的范畴，如果你一旦进而讨论各具体模块/组件的细节，那就非但不是技术无关，而且也深入细节了。在不深入细节的问题上，往往你很难禁止项目涉众（Stakeholder）不去讨论一些相关的业务细节。这个时候你可以将这些细节记录下来，然后再回到业务建模上。
每个售前项目需要技术人员投入的精力都不一样，这些大部分都是由客户来决定的，公司虽然总在讲控制人力成本，可销售人员为了拿下单子，也不会考虑投入成本问题，所以，人力成本很难得到控制。
本人参与了2个售前项目，在售前工作方面就有明显的差异。第一个项目：只是去客户现场了解了2次需求，在公司把需求整理了一份文档，出了一份解决方案的文档，这个方案介绍了系统大体分为几个模块，解决了需求里面的哪些问题，客户觉得已经OK了，需求范围已经划定，大体功能也已经了解，可以签合同了，当然在这个过程中，销售做的许多工作，都是功不可没啊。
第二个项目：比较痛苦的售前工作，也是去了2次客户现场了解需求，但是文档内容就要求多了，不只是要求整理的需求文档、解决方案，最要命的是还要求带界面的设计文档，客户的原话是“最好做个demo，我们看看”。比较无语，我们是售前啊，还没签合同呢，销售居然毫不犹豫的答应了，我也只好“画图”了。
