如何寫好乙份投標書技術部分的感悟

2021-06-01 18:56:49 字數 1326 閱讀 9265

如何寫好乙份投標書技術部分的感悟

**:標籤:投標書

經驗分享

最近為了寫投標書搞的焦頭爛額,由於自己也是第一次比較深入的參與標書編寫,實在摸不到方向,好在有人指點得到不少經驗教訓,特記錄下來以備後用。

1. 讀懂找標書:如何寫首先要看如何要求

今天又被痛批一頓,原因就是標書根本沒看仔細。我以為自己寫技術標部分就可以了,其他部分只是很粗略的過了一遍,結果寫出來的章節內容就是想當然,孰不知人家前面的要求裡有很明確的說明。人家就是要求對未進行檢測的功能有實質性說明,也就是說主要說明內容就是未檢測功能,說明的方法是具體實現的途徑和相應截圖。

2. 理清方向:想清楚客戶想看到什麼,你要從哪個角度去寫

最近兩份標書在寫,一是專案投標,另乙個是產品選型。看了一下內容很相似,就直接把乙個標書複製到另外乙個標書中了,結果又被一頓教育。其實前者是乙個專案,那標書中要說明的是我們系統有哪些功能,能夠適應專案需要。而後者是乙個選型,並不要具體產品,但要說明它的需求是怎麼實現的。這就應該完全是兩個角度去寫,其實這些要求應該從為什麼招標以及招標的具體內容角度去琢磨。

3. 前後呼應:先從總體上考慮巨集觀設計,再用細節章節描述具體實現

在最近一次寫標書的過程中,幾個人分工協作,章節一列,大家乙份就各自寫去了,等到合併的時候發現前後連貫性極差。參考了別人以前寫的標書發現整篇前後呼應非常好,先是乙個總體設計目標,然後給出相應的架構設計,指出每個子系統怎麼分工協作,實現上有什麼技術難點,後面就是針對每乙個系統一一詳細說明,再用關鍵技術章節說明怎麼解決這些難點的,感覺就是一氣呵成。仔細想一下,我們做的時候應該先大家討論出乙個總體設計和乙個詳細的系統功能圖,再確定每個模組的具體功能,然後才是分工,這樣才能保證整體的連貫性。

4. 響應需求:必須對使用者需求有提煉,形成自己系統的功能

剛開始寫標書,為了響應使用者需求,能做的最簡單辦法就是換成問答題,就是他說要什麼,我就說有什麼,但最後寫完感覺整個標書沒有自己的東西,特別是自己特用的東西往**寫都不知道了。經過指導才認識到需求是要先經過提煉,然後消化成自己系統功能的一部分,這樣給別人看才認為你是理解需求了。其實你很容易發現使用者提的需求是很零散的,有些需求放到乙個並不太相關的子系統需求中去說明,而你實現肯定會在其他地方,這就要根據實際情況去寫,還要寫的有道理。其實這個過程感覺就像是給你乙個新需求,讓你去重新設計一套系統。對於響應的一一對應當然也是要的,這是體現在技術偏差表中,但也不是把使用者招標檔案照搬,還是要有一定的提煉概括,否則20頁的偏差表專家會有心情看嗎?!

總結一下,剛開始寫投標書真是覺得摸不清標準和尺度,但想明白了發現其實沒難。首先要看清楚客戶到底要的是什麼,然後想明白自己怎麼才能給出乙個滿意的答案,最後就是有條理、有針對性、有信服力的把這些內容寫出來。以上是這些標書編寫的一點感悟,希望大家能多提意見,共同提高。

如何寫好乙份技術簡歷?

大部分情況下,寫簡歷是找工作的第一步,考慮到第二步就是面試,那麼簡歷就是敲門磚,為了讓企業認識到你的價值,必須把自己的真實水平描述出來,展現出你有能力應對這份工作。甚至要體現出自己是某方面的傑出人才,因為只有足夠優秀的人,企業才能更看重你,因為你會為企業帶來不一樣的價值,對應的待遇也將更好。所以寫簡...

如何寫好乙份產品需求文件

二 產品概述 三 功能說明 四 其他產品需求 五 風險分析 六 相關文件 版本編號 修訂人修訂日期 修訂描述 1.0.0 2021.1.22 初步確定產品需求 確定產品需求的實現方案 此文件的目的主要是清晰 有條理的說明 平台應具備的相關功能以及開發需求。此文件主要描述 平台中前端頁面涉及到的功能點...

bytedance怎麼讀 教你如何寫好乙份簡歷

你以為簡歷只是面試的第一關 實際上簡歷還是決定是否拿offer的最後一關。因為在發放offer的時候,如果幾個候選人經過面試後,差別並不大,簡歷將成為乙個重要的決定因素。所以,簡歷決定的不止是面試機會,更有可能是你拿到offer的機會。既然簡歷這麼重要,多花點時間正確地寫簡歷,也是值得的。如何正確地...