Re: [討論] 關於合約二三事 (二)

看板Soft_Job (軟體人)作者ggg12345 (ggg)時間17年前 (2007/10/13 14:12)推噓0(0推 0噓 0→)

留言0則, 0人參與討論串2/2 (看更多)

※ 引述《BalahBalah (裝忙是很辛苦滴)》之銘言： : 上篇文章提到, 合約的組成除了相關法律條文以及附件之外, 最重要的兩段是 RFP : 中的 : 1. 軟體規格書 : 2. 供應條件 : : 先粗略的解釋何謂 RFP : 建議書徵求文件 (RFP-Request For Proposal) 常理上來說, 會是為合約的一部分. : 依據 "政府資訊作業委外服務實施作業手冊" 中的描述, RFP 為 : : 主要功能在載明界定委外工作需求及範疇，預先做好委託機關與有意願之業者間的 : 溝通依據，避免日後合約執行過程中爭議。同時也作為有意願之業者提出建議書之 : 基礎，及提供執行合約驗收之依據。 : ====== RFP 的基本原則是供應方提供建議(Proposal), 所以買方只有需求想做甚麼, 想要有甚麼性能, 想解決甚麼問題, 細節項目應該是由供應方提供的. 也就是針對需求做答案, 提供建議的規格/規範與交付品的數量品名與性能, 如獲採納就是列入為合約的一部份, 是驗收項目的依據. 供應方必需說了算數, 要額外收費也要講清楚. 不過, 真正 RFP 的做法是要有審查會, 就技術規範與費效比來評選. 但這種做法, 審計與預算核發(立院)單位都有價位的意見在, 基本上就是往低價競標走, 性質就是單一規格開標. 但規範/規格(這相當於建物的建築設計圖), 需求單位又根本定不出來, 就形成指定一堆基本元件方塊的現象(譬如 XX牌磁磚這種表面看得到的). : 簡單的說, RFP 及為規範該合約標的物的規格, 該做什麼, 什麼時候做完, 做完之 : 後該怎麼跟客戶收錢, 也就是說, 地雷炸彈都在這裡面囧 : : 軟體規格書 : : 顧名思義, 即是定義該軟體標的物的規格. : 內容通常會有下列 : : @ 前言 : balah balah...好聽的開場白 : @ 標的物名稱 : 此次開發的軟體標的名稱, 含代購軟體, 如 Database 等相關輔助軟體及工具 : @ 軟體規格 : 該軟體所包含的功能列表以及描述, 專案爆炸的彈藥庫 : @ 其他 : 其餘非功能性的客戶需求, 如 "本系統須支援USER端透過IE Browser 介面連結 : 本系統，執行相關作業" 等描述 : : 標的物名稱常見盲點 : : 1. 標的物所指定的代購軟體,是否能符合供應條件中所描述的效能範圍, 很常看到 : 的例子, 如中大型大量使用者 access AP, 軟體使用 MS 平台 + MS SQL Server, : 卻要求頁面或是反映時間 < N秒, 嘖嘖...這點在後續作壓力測試之後就有得吵囉 : 這就是一個指定某牌元件的例子. 這種事就會發生要把 BMW 的車殼裝豐田引擎硬套坦克履帶的現象. : 建議 : : 開發端在 Kick off 之前, 或是專案初期先行找使用者溝通, 最好能提出相關類 : 似案例或是數據佐證, 慢慢的在過程中洗腦客戶, 切忌跳過此問題, 尤其當供應 : 條件或規格中有明定相關效能的範圍, 則這個問題會很嚴重的影響驗收時程, 導 : 致無法驗收或是客戶提出減價驗收砍尾款! 若是使用者端, 則規畫初始最好能多 : 找幾間廠商提出Solution比較, 並請廠商也提出相關佐證資料列入合約附件. : : 2. 相關輔助軟體或是工具適用性與常規工具符合, 我就遇過某銀行不同意駐點 : 工程師開發 Java AP 使用 eclipse 而要求使用 RFP 內定的 WSAD, 每兩三天就 : 下來突擊檢查, 把工程師差點搞跳樓 : : 建議 : : 專案團隊成立之前, 請 PM 先與公司主管溝通, 由公司內部尋找相關資源, 起碼 : 有一個能撐場面假裝也交代的過去, 客戶端也可多考慮市場上眾多免費工具, 當 : 然, 還是請開發端廠商提出資料佐證該工具的授權或是穩定性評比等. : : : 軟體規格常見盲點 : : 1. 傳說中的 "common sense", 很多客戶端在撰寫或審核 RFP 的同時，都會陷入 : 業界常識的迷思中, 基本上, 合約的意義即為規範該買賣交易的所有內容, 請 : 注意, 是 "所有" 內容, 合約範圍內無例外,表示未寫入的 "常識性" 功能, 開 : 發端並無義務必須無償配合, 舉例來說, 銀行業內對於數字的常規, 有三位一 : 撇的基本慣例, 像是 "1000" 必須於 AP 上呈現 "1,000", 這種功能大部分的 : RFP 中不會定義到, 客戶會說這是常識嘛, 廠商這麼專業應該要懂, 正常狀況 : 確實如此, 那麼, 當專案遇到時程延後或是與客戶端溝通不良火氣大的時候, : 什麼業界常識都變成延遲以及互相刁難的的藉口. : : 建議 : : 使用者端盡量的在 RFP 中詳細描述可能會用到的功能, 我知道有困難, 不過等 : 使用者多接觸過開發專案, 就會很熟悉常常被廠商推拖的常識性功能為何, 請列 : 入 RFP 內, 當時程趕的時候, 可與開發端簽定 MO 或是承諾書, 於不影響功能 : 前提先行驗收後補開發端遇到客戶提出非 RFP 規範的常識性功能需求, 如果功 : 能不複雜, 則先行列入待議事項, 於最後討論待議事項的同時, 與客戶談判相互 : 讓步, 某些功能我吸收, 其他的請客戶吸收, 請一定要先行做出一點的讓步才能 : 使客戶也讓步, 至於複雜的功能, 則回應會請公司的主管再來討論 (當然是回去 : 請業務來爐加價啥的..), 切忌當場同意, 否則相關責任會由同意的人扛 : : 2. 一言以蔽之型功能, RFP 常出現這種超級大地雷, 短短的幾個字道盡千言萬語, : 甚至還有某功能其實是拿著別人的產品來構思,談需求的時候直接丟一份別的廠 : 商整本系統說明文件讓開發端照做傻眼情況. : : 建議 : : 簽訂合約之前, 甚至追朔到業務還在跟客戶談案子的時候, 請公司一定要讓產品 : 經理或是 Solution Consultant與客戶端針對 RFP內容先行做初步訪談, 此步驟 : 絕不能省若是已簽定才發現, 請保重, 後續就靠專業的專案經理跟業務的臨場反 : 應來救命囧 : 客戶端同上個建議, 盡量撰寫 RFP 詳細, 或標案之前要求廠商先行過來了解訪 : 談, 開發端跳票不是只有開發端要負責任, 客戶端也需同理心看待, 案子出現問 : 題該年度使用者人員/ 單位 KPI 也不會好看到哪, 不是嗎? : : 3. 外部資源連結需求, 除了很單純的固定系統之外, 現行的軟體幾乎都要做整合這 : 個動作整合啥? 整合資源, 整合單位, 整合使用者, 整合功能, 外部整合相對是 : 容易從 RFP 中規範也容易被 RFP 忽略, 當廠商開發到一半突然某功能必須要跟 : 啥鬼系統連接, 欲哭無淚 : : 建議 : : Kick off 的會議中, 有一張圖片必須帶到 RFP 關於外部資源整合的列表, 表示 : 各位都清楚, 往後翻案也有理由讓客戶讓步, 另外需求訪談同時也需要另外撰寫 : 外部資源列表以及防火牆等規劃, 以視開發端重視程度. : 使用者端請於規劃系統之前, 先行內部溝通協調, 某些系統或功能可以統一規劃, : 則避免各做一套, 以免管理出現漏洞以及集團或公司整合資料困難. : : 以上這幾種關於軟體規格的內容描述,是我遇過出現頻率最高的問題, 當然, 事先閱 : 讀過合約相關資料, 配合一定的公司資源 (如產品經理等), 能確實的在專案初期讓 : 團隊評估原始風險, 雖然不能完全避免, 卻也能讓專案團員多了解該專案的目的以及 : 資料, 也讓專案團隊有參予的感受, 而不是不受重視的 coding BOT, 相對的, 某些 : 功能可能開發人員有經驗, 亦可提出讓大家分享, 一起與專案團隊成長才是做專案的 : 成就感. : : 後續繼續整理關於供應條件的部分 ^^ : ============= 最根本關鍵的兩個問題就是: 1.政府不應該把錢發給公務預算單位, 要求其執行軟體委外購案. 2.全世界的公務員都是一樣的, 要公務員涉及規劃, 他是不知怎麼做但可很會要求的. 而驗收或妥協談判, 要基層公務員負責那真是與虎謀皮. 如果, 把錢拿出來找繳稅最多的廠商, 用無償配合款請廠商拿錢出來對其公司業務做電腦化委外, 或融資低利貸款給大公司成立獨立的軟體公司來包這些軟體案, 這些商業公司為了能拿到退稅款又能改善公司體質一定會盡力想完成, 此時她會要求其公司內部的 IT 人員全力配合外包廠商(也可能是投資分設出去的)完成系統, 等商業公司都完成運作了, 再要求政府機關照抄規格引進, 此時規格與價位都有例可循, 公務員在商業公司都能使用下就沒有藉口做一堆有的沒有的要求了. 此時, 這些新增的軟體公司除了這些雷同的政府機關包案暫緩一口氣外, 就應力爭擴大市場機會, 拿成功的軟體到國外爭取機會. -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.1.146