本人也是第一份售前工作，以前是做開發和實施工作，剛開始有點掌握不到售前工作的一個“度”，現在把這段時間的售前工作經驗記錄一下。
售前和售后工作不一樣，售后工作是需要了解需求，直到能夠進行開發的程度，系統設計、概要設計、詳細設計、代碼開發、測試、上線、驗收一套完成的流程。售前工作對需求到底要了解到什么程度；給客戶提供的文檔要細化到什么程度；公司允許投入到什么程度；還要避免我們做好了鋪墊，結果客戶按照我們的方案，找其他公司合作了；我是一個售前的小菜，真的徹底迷茫了。
售前首要的工作就要了解客戶的需求，要想項目成功，可離不開項目涉眾的支持。在項目一開始，不論是項目涉眾還是開發人員，對項目的任務、范圍都是模糊不清的。但隨着項目的深入，原來模糊的景象會慢慢清晰、立體起來。但是為了不浪費時間，我們有必要在項目射入之前，現在項目涉眾中豎立一個共同的願景。
共同願景的豎立可沒有想象中的那么簡單，因為每位涉眾都關心自己的利益，都有自己的評判標准。你可以把大家的意見都列在白板上，然后逐項集中討論，做出修正，直到大家的意見一致的時候為止。在共同遠景的豎立過程中，其實有兩件事情也已經同時做了，項目范圍（scope）和高階（high-level）需求。
項目范圍：項目該做什么，不該做什么，需要在一開始就有明確的定義。對於項目范圍內的需求，一個也不要放過，而項目之外的，一個也不要去關心。雖然有的時候，范圍的變化會有利於項目本身，例如客戶的合理要求或是市場目標客戶的變化，但是這種變化應該要在"資源能夠支持"和"得到審批"的前提下進行。
項目范圍的描述可以通過陳述和圖示來進行。我建議大家使用圖示。因為陳述語句比較含糊不清。例如常常聽到有客戶說。"我要建立我公司的電子商務系統。"這句話就是含糊不清的，你的電子商務系統是銷售什么產品？面向什么客戶？是否要支持在線支付？根據這些疑問，這個陳述句可以做進一步的修改，"建立在線訂貨系統，針對當前的目標客戶銷售公司的目前產品。"這樣就清楚許多了。不過圖示的方法會更好一些，在圖的選擇上，你可以使用DFD圖或是用例圖。根據經驗，DFD圖比較容易為客戶所接受。
高階需求：這個部分我們在下面會詳細討論。既然是高階需求，就不能討論過多的細節。在討論高階需求的時候，盡量保證快速的討論出系統的概貌，建立需求模型，得到項目涉眾的一致通過。
取得支持：為了保證需求計划的順利進行，取得項目涉眾的支持至關重要。你可以選擇在這個時候告訴項目涉眾他們的權利和義務，以及開發人員的權利和義務。主要的就是"涉眾有改變需求的權利，同時要承擔向開發人員講解需求的義務。"開發人員的權利和義務正好和涉眾相反。
業務建模是需求工程中最初始的階段，也是整個項目的初始階段。需要指出的是，業務建模時間的跨度在不同的項目中有很大的差別的。在有些項目中，例如大型ERP系統，可能需要幾個月的時間。而對於普通的項目，業務建模的時間可能僅僅需要幾天的時間。
需求是技術無關（technology independent）的。在需求階段討論技術是沒有任何意義的。那只會讓你的注意力分散。技術的實現細節是在后面的分析、設計階段才需要考慮的事情。而在業務建模階段，不但要保證需求的技術無關性，還要保證你的需求不要深入細節。因為在業務建模階段，最重要的事情就是要了解業務的全貌，深入細節會浪費時間和精力。要知道，討論一個企業里的業務細節，就算給你一個月的時間也沒必能夠結束。
在實際中，這兩點都是很難做到的。例如企業原先有一個系統，這就不得不由你討論和新舊系統的兼容問題。這時候就要注意，如果你是討論就有系統的架構的話，那還是屬於技術無關的范疇，如果你一旦進而討論各具體模塊/組件的細節，那就非但不是技術無關，而且也深入細節了。在不深入細節的問題上，往往你很難禁止項目涉眾（Stakeholder）不去討論一些相關的業務細節。這個時候你可以將這些細節記錄下來，然后再回到業務建模上。
每個售前項目需要技術人員投入的精力都不一樣，這些大部分都是由客戶來決定的，公司雖然總在講控制人力成本，可銷售人員為了拿下單子，也不會考慮投入成本問題，所以，人力成本很難得到控制。
本人參與了2個售前項目，在售前工作方面就有明顯的差異。第一個項目：只是去客戶現場了解了2次需求，在公司把需求整理了一份文檔，出了一份解決方案的文檔，這個方案介紹了系統大體分為幾個模塊，解決了需求里面的哪些問題，客戶覺得已經OK了，需求范圍已經划定，大體功能也已經了解，可以簽合同了，當然在這個過程中，銷售做的許多工作，都是功不可沒啊。
第二個項目：比較痛苦的售前工作，也是去了2次客戶現場了解需求，但是文檔內容就要求多了，不只是要求整理的需求文檔、解決方案，最要命的是還要求帶界面的設計文檔，客戶的原話是“最好做個demo，我們看看”。比較無語，我們是售前啊，還沒簽合同呢，銷售居然毫不猶豫的答應了，我也只好“畫圖”了。