我寫這個可不是為了傳授或布道哦，我寫過一些投標方案，但是總想聽聽大家是怎麼寫的，都注意些什麼。所以，兄弟我先扔塊磚，大夥兒有玉的砸過來～
前面幾天在寫乙份投標方案。連續幾天搞到晚上10：00以後，週末還搞了個通宵，昨天去投了。總算乙個包袱卸了下來，結果怎麼樣也顧不上了，大家都說：盡人事，聽天命吧。呵呵
這個方案我主要負責技術方案部分，商務部分另乙個同事負責。由於是個沒人做過的東西，所以模型、框架得自己砸破腦袋想。方案的名稱是：中小學學生學習質量監測系統。招標方明確說了，這不是題庫，這是要監測學習質量！！人家還說，關鍵在於對教育理念的理解！
在這個方案投出去了我都有很多覺得不合適的地方，但是時間實在來不及了，也怪自己沒法考慮周全。所以我總覺得，就乙個投標方案製作來說，應該至少有3個人，乙個負責商務，另兩個負責技術方案。乙個人做技術方案總是顧此失彼。兩個人可以相互討論，相互審閱，可以避免很多問題。兩個人還有分工，乙個鑽研使用者需求分析，另乙個負責技術架構。但是要相互討論，這樣起碼雖然某一部分是乙個人來寫用的確實兩個人的腦袋。
從寫的步驟上來說，一般不適宜上來就動筆。這個和寫文章一樣嘛，總得要構思一下。我想這樣應該比較合適：
（1）分析清楚業主真正想要的是什麼。這個如果拿捏不准就慘了。
（2）分清楚這個系統的使用者有哪些角色。這將有助於找出業務內容。
（3）確定這個方案的產品的最終部署結構、網路結構。這是大問題，因為如果開始不考慮這些，後面再考慮會很難；
（4）確定這個方案的重點在**，因為有的重視業務模型，有的重視技術實現（這個有時很難做，而且要看評標人的背景）。
（5）討論確定投標方案的框架，這中間要特別熟讀招標要求，需要注意的地方特別畫出來。
（6）接著就瘋狂的到網上搜尋資料吧，然後根據自己的思維和框架把方案的內容豐滿起來。一般來說，很多方案都是這樣「拼」起來的，不過好的方案還是要自己花功夫在裡面。一分錢一分貨嘛！
（7）相互審閱。這一點很重要，因為這麼短的時間寫這麼多內容（還有很多內容是「拼」來的），很難保證內容「圓潤」。別人看一遍能夠找出很多顯然的毛病和問題；能夠從內容的全面性、通暢性等方面找出問題。這期間最好能再反覆閱讀招標需求。
（8）投標方案各部分合成，審閱。
（9）列印、裝訂、簽字敲章、密封。這個其實有專門的公司做裝訂的，有條件的話可以交給別人去做，因為這個過程其實還是蠻痛苦的。
從內容上看，一般包括（但不限於）：
（1）概論：說一些方案書目的、專案背景等。
（2）使用者需求分析：通常會對業主的相關系統做個業務建模。
（3）系統設計：對業主的狀況做乙個解決方案，可能是乙個系統的功能設計說明，也有可能是一些設計模型。
（4）專案技術方案：對技術平台路線、相關裝置需求（技術引數）、技術架構、關鍵技術等進行說明和設計。
（5）根據需要，通常還有系統的安全解決方案、儲存方案、備份與恢復方案等。
（6）系統專案實施方案：主要包括專案計畫、質量保證計畫、配置管理計畫、售後服務計畫等等。
從技巧或注意點上看，主要有：
（1）所說方案的面上一定要說得通。
（2）多用圖，大段大段的篇文字人家不願意看，圖形能夠非常有效的幫助別人理解你的意思。
（3）排版一定要整齊、美觀。這個似乎與「技術」無關，不過，這相當重要。道理跟我們寫高考作文一樣。
唉，先寫到這樣吧，一下子想不了很多，想到了慢慢添上來，大家多來說說吧。
大家如果願意的話，我們把自己做過的一些方案改一下共享出來大家分享如何？
**：
部落格應該怎麼寫
雖然我們大部分在機房都呆了一年了，但是還是很多人對於部落格還是望而生畏，不能說是應付差事，但是總有一點一些部落格就頭疼的感覺，更有甚者，冥思苦想，最終寫出來的總是不敬人意。今天 大話 基本上都要看完了，其實對於這本書還是深有感觸的，以 大話 為題，說說部落格我們應該怎麼寫。與其抱怨需求總是在變化，不...
標頭檔案應該怎麼寫
因為乙個物件只能定義一次，能夠宣告多次，所以標頭檔案最重要的規則是只宣告，不定義 除少數物件外 而且只宣告其他檔案需要用到的物件，其他檔案不需要用到的物件沒必要在標頭檔案中宣告。當其他檔案需要用到本檔案定義的一些物件時，我們可以將這些物件寫到頭檔案中，其他檔案只要include這個標頭檔案即可使用相...
OO UML應該怎麼寫文件
最近進入乙個軟體專案的二期開發小組，每天都在看一期的需求分析 概要設計 詳細設計等等文件。結果越看越困惑，每個子系統的文件模版都不一樣，而且認認真真的看了幾遍文件，大體輪廓是明白了，可是一些具體的問題寫得非常含混不清，甚至是不知所云，看的次數越多問題越多。為了看懂文件，我決定不再糾纏於文字描述，重點...