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

[BalahBalah (裝忙是很辛苦滴)]

上篇文章提到, 合約的組成除了相關法律條文以及附件之外, 最重要的兩段是 RFP 中的
1. 軟體規格書
2. 供應條件

先粗略的解釋何謂 RFP
建議書徵求文件 (RFP-Request For Proposal) 常理上來說, 會是為合約的一部分.
依據 "政府資訊作業委外服務實施作業手冊" 中的描述, RFP 為 :
主要功能在載明界定委外工作需求及範疇，預先做好委託機關與有意願之業者間的溝通依
據，避免日後合約執行過程中爭議。同時也作為有意願之業者提出建議書之基礎，及提供
執行合約驗收之依據。

簡單的說, RFP 及為規範該合約標的物的規格, 該做什麼, 什麼時候做完, 做完之後該怎
麼跟客戶收錢, 也就是說, 地雷炸彈都在這裡面 囧

軟體規格書

顧名思義, 及事定義該軟體標的物的規格.
內容通常會有下列 :
@ 前言
  balah balah...好聽的開場白
@ 標的物名稱
  此次開發的軟體標的名稱, 含代購軟體, 如 Database 等相關輔助軟體及工具
@ 軟體規格
  該軟體所包含的功能列表以及描述, 專案爆炸的彈藥庫
@ 其他
  其餘非功能性的客戶需求, 如 "本系統須支援USER端透過IE Browser 介面連結本系統
 ，執行相關作業" 等描述

標的物名稱常見盲點 :
1. 標的物所指定的代購軟體,是否能符合供應條件中所描述的效能範圍, 很常看到的例子,
   如中大型大量使用者 access AP, 軟體使用 MS 平台 + MS SQL Server, 卻要求頁面
   或是反映時間 < N秒, 嘖嘖...這點在後續作壓力測試之後就有得吵囉

   建議 :
   開發端在 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, 相對的, 某些功能可能開發人
員有經驗, 亦可提出讓大家分享, 一起與專案團隊成長才是做專案的成就感.

後續繼續整理關於供應條件的部分 ^^

--
※ 發信站: 批踢踢實業坊(ptt.cc) 
◆ From: 61.62.23.235
推 envia:推~ 好文
→ E04urmom:很有股衝動把各種狀況的合約都放上來, 怕給自己找麻煩 XD
推 adm123:真的不錯。軟協那邊也有些範例文件，雖不一定合用但可參考꘠
→ lovelexus:2樓又忘了換ID XD
→ BalahBalah:供應條件篇要等一會, 今天去動個小手術,不能打字太久
→ BalahBalah:手術的胸口會痛, 還看的到好粗的縫線..嘖嘖
→ BalahBalah:沒辦法隨便打就 po 上來, 對各位高手不尊敬 ^^
推 chihyi1980:這一連串的文章希望發完了, 板主能收進精華區呢.
推 lovelexus:板主說會收文摘 小板主上任後會做總整理