作者BalahBalah (裝忙是很辛苦滴)
看板Soft_Job
標題[討論] 關於合約二三事
時間Mon Jun 25 15:52:33 2007
各位日安
剛巧這兩天整理前公司的文件, 望著手中一大疊的合約書/建議書/SOW 興嘆,軟體資訊業原
也逃不掉商業程序的範疇, 想著就上來跟大家分享關於合約的二三事.
合約是構成雙方買賣行為的規範, 法律上的解釋不討論, 現在討論的是:
合約, 對軟體開發/專案開發的衝擊性以及怎麼辨識合約上的盲點以及可能出問題的地方
本篇討論範圍僅限於 "純軟體開發"及"專案開發",至於硬體或是半軟半硬的產業,請恕我不
懂, 既然不懂也不誤人子弟, 若有能人大德願意另開文章分享, 則為本版之幸
我想大家應當會有疑問, 為什麼軟體版我想跟各位討論合約的相關事宜? Programmer/SA/
SD/PM 要懂合約幹嘛? 跟開發團隊有關係嗎?
大大的有關係!!!
以下幾張圖是前幾年公司委託我做教育訓練寫的.有研究過專案管理 PMP 或熟知專案流程
的高手, 看到如下的圖, 一定不陌生.
http://tinyurl.com/yu3e6k
專案基本三元素, 範圍 (Scope), 時間 (Duration) 以及成本 (Budget), 三者互相緊密
關聯且互相影響, 範圍改變則時間以及成本隨即改變. 上圖為理想中的"標準"金三角
通常, 客戶認知的專案元素, 會是以下的狀態
http://tinyurl.com/3ybtq4
表示什麼? 表示客戶一開始就覺得專案要做很多符合他們期望的東西, 時間不用太多, 成
本也不會花費太大.
那麼, 通常承接的軟體開發或是 SI 公司認知的專案元素, 會是以下狀態
http://tinyurl.com/36embz
又表示什麼? 老子接這個專案是要賺錢的, 當然是少做多賺馬上收錢的好, 這還用問?!!
結果呢, 通常最後的實際專案元素會變成如下的 囧 圖
http://tinyurl.com/2mhl93
每個圖中間的文字, 讓我們發現, 其實客戶以及公司之間, 通常的共識就是沒有共識!
如何讓雙方在開工之前, 凝聚起碼的共識, 將雙方的期望值統一歸納在一定的範圍, 靠的
就是合約. 當合約定義的不明確, 或是有漏洞, 有陷阱的同時, 這個專案的元素三角形,
已經是先天不良的狀態, 那麼專案開發人員又如何能在公司規定的時程內花費超省的資源
來達成客戶期望的超大目標呢? 答案通常都會是專案延後並讓雙方爆發不愉快收場.
以這個出發點, 則, 如何從合約以及相關附件中找尋共識, 或是隱藏陷阱漏洞, 不光是
公司的法務或是業務的事, 有經驗的 PM, 會在專案 Kick off 之前先招開內部的 WBS 討
論會議, 以求讓開發者以及所有的專案成員參予討論, 並對其中的疑點進行更深入的探討
通常型的合約總的分為兩大塊
1. 建議書徵求文件 RFP
( 通常又分為兩小區塊, 分別為
1.1 軟體規格書
1.2 供應條件 )
2. 其餘相關附件要素 ( 保密/廠商規範/SOW等.)
後面要討論的事項還不少, 我怕一篇想太多會讓大家看得眼花, 另開後續篇幅.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.62.23.235
1F：推 MugenPower:專案延後並讓雙方爆發不愉快收場 XDDDD 看過好幾次耶 06/25 15:55
2F：推 alonelife:合約的角度是從buyer還是seller來看呢? 06/25 16:11
3F：→ alonelife:buyer提RFP, seller提proposals 06/25 16:12
4F：→ alonelife:請注意你寫時所看角度哩... 06/25 16:13
5F：→ E04urmom:seller 的 proposal 是依據 buyer 的 RFP 所撰寫 06/25 16:18
6F：→ E04urmom:RFP 隱含的盲點對於雙方都適用, Seller 可發現客戶的期望 06/25 16:19
7F：→ E04urmom:有哪些實現有困難,而 Buyer 則可知道如何避免產出有問題 06/25 16:20
8F：→ E04urmom:的需求, 基本上合約是給雙方看的, 不是給特定一方 ^^ 06/25 16:21
9F：→ E04urmom:哎呀...ID爆 這下囧大 06/25 16:23
10F：推 MugenPower:有時候 BUYER 的RFP期實是SELLER寫的 ╮(﹀_﹀")╭ 06/25 16:26
11F：推 E04urmom:我也常幹這種事, 幫銀行寫過不少 RFP, 綁標用 噓 ~~~~ 06/25 16:29
12F：推 adm123:只能說台灣SI最後的重點都是「如何抓到key Man」。 06/25 16:38
13F：→ MugenPower:噗~ 看來不少SELLER都這樣做 XDDD 06/25 16:40
14F：→ adm123:然後剩下的東西就只做表面。（反正線早就佈好了） 06/25 16:39
15F：→ MugenPower: BUYER @@ 打反了 06/25 16:40
16F：→ smartb:這張好像有點問題.我記得是品質 - 時間 - 成本. 06/25 17:33
17F：→ smartb:通常客戶會希望品質好 時間短 預算少的.. 06/25 17:33
18F：→ smartb:開發者會希望時間長 預算多 品質!@#$%^ 06/25 17:34
19F：→ smartb:的精神 ..... 06/25 17:36
20F：→ smartb:所以 就是範疇的問題啦.....怎麼去訂出雙方合理的 就是訂合 06/25 17:36
21F：→ BalahBalah:事實上以 PMP 的定義, Baseline 有四個, 不過圖只定三 06/25 17:39
22F：→ BalahBalah:個,品質與時間成本的關聯性沒有Scope連動明顯, so ^^ 06/25 17:39
23F：→ BalahBalah:BTW,開發者希望的不是時間長, 而是 ROI 高, 時間長不如 06/25 17:42
24F：→ BalahBalah:時間短金額少, 時間常會有 cash flow 的問題呦 ^^ 06/25 17:42
25F：→ BalahBalah:這又牽涉到合約的供應條件內的付款條件, 很有得聊ccc 06/25 17:43
26F：推 adahsu:圖沒錯，因為品質可以看成是三角型的面積！ 06/25 18:07
27F：→ l1l:面積似乎跟品質無關，規模大時間長成本高的也可能品質很爛 06/25 20:20
28F：→ E04urmom:四種 measure 只是代表量性, 圖形也只是表示互相的連動關 06/25 20:40
29F：→ E04urmom:係, 真實數據當然會隨著狀況產生變異,只是示意圖囉 ^^ 06/25 20:42
30F：→ E04urmom:又忘了換ID...XDDD 06/25 20:44
31F：推 lovelexus:呵 樓上又搞笑了 ^^ 06/25 21:11
32F：→ BalahBalah:那ID是黑特專用..看就知道,不適合這裡的文化也不適合正 06/25 21:12
33F：→ BalahBalah:經的時候用, 感覺不太好, 會被噓ID 囧 06/25 21:13
34F：→ misptt2:好文推!! 06/26 22:57