付亞麗 2008/08/12

　　在人們的意識中，認為軟件項目的建設比傳統(tǒng)行業(yè)項目的建設要容易的多，所以從根本上就輕視了它的建設，殊不知軟件項目的建設要比傳統(tǒng)行業(yè)項目的建設要復雜的多。軟件項目建設是一個看不到，摸不透的項目，不象蓋一座大樓一樣，我們可以知道他有多高，有多寬等。那么在建設軟件項目之前，我們怎么才能感受到我們所要建設的軟件項目是一個什么樣子。這就需要我們和蓋大樓一樣，在蓋之前要出好我們的設計圖紙。軟件項目叫做建設方案。本文不討論具體的建設方案，只是結合本人的軟件項目建設經驗，談一談在寫聯(lián)絡中心項目建設方案過程中需要注意的幾個問題。
一、項目需求調研
　　多數人認為軟件項目的需求調研工作是在簽訂商務合同后，由技術人員從事的工作，和我無關�？墒遣恢�道大家想過沒有，不能了解客戶的具體需求，我們編寫的方案只能是我們腦子里想的，是我們強加給客戶的，不是客戶的真實反應，和現實的需求。比如：我們不知道客戶要將呼叫中心用在什么地方，那個部門，自然我們就不可能將項目軟件建設需要那些功能給客戶說清楚。只能是經驗的簡單堆積。拿一個風牛馬不相及的方案給客戶。讓客戶看起來很陌生。在比如：在給客戶設計中繼線路的時候，如果不了解客戶日常的電話量，是否有重大訪問量，重大訪問量出現的時間和次數等。就無法給用戶設計聯(lián)絡中心系統(tǒng)的外線數量。也沒有辦法給客戶設計出現重大事故時候的應急方案，同時如果不清楚用戶的財力支持的程度，也就不能夠為用戶設計合理的外線類型。
二、認為客戶不會看
　　跟同行的人士在聊天的時候，大家都認為一個項目的建設方案少則幾十頁，多則幾百頁，同時客戶也不懂技術，所以一般都不看。因此沒有必要那么認真的去寫，找個人隨便的弄一下就可以。但是根據我在和客戶聊天的過程中。感知到，客戶認為我們的方案寫的大話太多，客戶關心的到沒有寫，方案中最多寫的是“我們的系統(tǒng)采用什么什么架構，我們的系統(tǒng)如何如何的強大”，但是從來沒有一個方案說過，這種系統(tǒng)的架構和強大能夠為客戶帶來什么利益。能幫助客戶解決什么問題。所以客戶看到這些就直接的把方案放在垃圾袋里面，認為這個方案只是在應付，沒有一點實際應用的意義。
三、過于空洞
　　聯(lián)絡中心項目的建設方案，本人認為應該和建筑的設計圖紙一樣，沒有什么差別。在建筑的圖紙上都會標有此次項目的具體尺度。但是軟件項目的建設方案上，很少有體現，很少有文字說明，針對目前客戶的需求，系統(tǒng)應該有什么樣的功能，為什么要有這樣的功能，這樣的功能能夠解決客戶的實際什么問題。同時數字太少。其實一個好的建設方案，能給客戶帶來的利益是可以用數字來說明的，數字的說明是更有說服力的。
四、真正關心的問題說不清楚
　　一個項目的建設方案有幾百頁，但是真正客戶關心的問題就沒有幾頁，同時客戶也看不懂，在加上缺少前期的需求調研，深層次的客戶需求沒有挖掘出來。導致客戶認為提交的方案根本就不是他們要的方案。認為我們的方案和其它的沒有什么區(qū)別。
五、功能設計不合理
　　每個項目建設方案中，過多的羅列了中間件的功能，其實用戶真正擔心的是系統(tǒng)是否足夠穩(wěn)定，同時希望能夠用足夠的案例來證明系統(tǒng)的穩(wěn)定性。同時用戶也在擔心系統(tǒng)設計的是否足夠靈活，能不能適應用戶未來的業(yè)務發(fā)展需要等等，都想在方案里面看到相應的說明。而不是只是一句“我們的系統(tǒng)非常的靈活”顯的很蒼白無力。
六、方案人員不了解產品
　　大家一直在討論，寫方案的人員要不要有很深厚的技術功底？本人認為寫方案不一定具備很深的技術功底，但需要對產品和產品周邊的技術有很深的了解。清楚采用技術的風險和產品的缺陷，以及這樣設計的方案的優(yōu)點和缺陷，而不是千篇一律的客套話。同時方案人員需要有很強的設計能力。能將用戶的需求，根據現有產品的功能，為用戶進行設計，能夠說清楚這樣設計的道理，不必說出這個設計是怎么去實現的。
七、項目實際情況和方案出入很大
　　在客戶的眼中認為我們的建設方案就是項目的真實面貌，所以很多客戶在項目建設完畢后，興致勃勃。在使用后一落千丈。原因就在于客戶使用的項目和方案里說明的項目一個是在天上一個是在地下。根本就不著邊。造成客戶認為你們在忽悠我。
　　以上是本人的一點小小經驗，所以甚是淺薄，希望能夠得到同行業(yè)的專家人士指點。將一個“水中月、鏡中花”的項目描述的實實在在。

CTI論壇編輯