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

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

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

※ 引述《BalahBalah (裝忙是很辛苦滴)》之銘言： .... : 合約是構成雙方買賣行為的規範, 法律上的解釋不討論, 現在討論的是: : 合約, 對軟體開發/專案開發的衝擊性以及怎麼辨識合約上的盲點以及可能出問題的地方 : 本篇討論範圍僅限於 "純軟體開發"及"專案開發" .... : 我想大家應當會有疑問, 為什麼軟體版我想跟各位討論合約的相關事宜? 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 : 每個圖中間的文字, 讓我們發現, 其實客戶以及公司之間, 通常的共識就是沒有共識! ====== 買賣雙方在同意交易往前進行時, 是有幾點共識的: 1.雙方同意進行交易, 至少是同意簽約的. 2.預算(Budget), 時程(Duration)及範圍(Scope)會記載在合約內, 應該也是明文確定, 雙方同意的. 3.買賣雙方照商業慣例是按合約為依據做事的, 但合約反而在交付的標的物敘述上, 雙方通常是有刻意模糊的傾向. 換言之, 軟體合約常留下再協商議定的空間. 所謂沒有共識應該是指: 1.客戶與實現系統者(主要就是PM/SA/SD/PG)對將交付的標的物(軟體系統與訓練使用)在認知上是有差距的. 2.在標的物的功能或性能上, 賣方的業務人員經常是過度承諾(over-commit) 甚至是引發客戶不當聯想的, 但實現者對業務人員的承諾是忽略沒體認的. 3.不在合約中載明的口頭承諾, 如果又是需要實作者實現的部份, 經常是在客戶與實作者間不存在著共識. : 如何讓雙方在開工之前, 凝聚起碼的共識, 將雙方的期望值統一歸納在一定的範 : 圍, 靠的就是合約. 當合約定義的不明確, 或是有漏洞, 有陷阱的同時, 這個專 : 案的元素三角形, 已經是先天不良的狀態, 那麼專案開發人員又如何能在公司規 : 定的時程內花費超省的資源來達成客戶期望的超大目標呢? 答案通常都會是專案 : 延後並讓雙方爆發不愉快收場. : 以這個出發點, 則, 如何從合約以及相關附件中找尋共識, 或是隱藏陷阱漏洞, : 不光是公司的法務或是業務的事, 有經驗的 PM, 會在專案 Kick off 之前先招開 : 內部的 WBS 討論會議, 以求讓開發者以及所有的專案成員參予討論, 並對其中的 : 疑點進行更深入的探討 : 通常型的合約總的分為兩大塊 : 1. 建議書徵求文件 RFP : ( 通常又分為兩小區塊, 分別為 : 1.1 軟體規格書 : 1.2 供應條件 ) : 2. 其餘相關附件要素 ( 保密/廠商規範/SOW等.) : 後面要討論的事項還不少, 我怕一篇想太多會讓大家看得眼花, 另開後續篇幅. ======== 使用 RFP (Request For Proposal) 是老式大型系統(含軟硬與服務)的方法. 也就是通稱的系統整合供應服務, 是屬於統包型的. 這種統包的案主要的就是靠提供方便性的服務與取得客戶滿意度, 所索取的代價也都很高. 這種類型的案都發生在公務預算的單位, 其基本性質就是花經費不養常設性人員, 透過委外買整體服務. 當資訊系統是以 PC 硬體為主時, 很多的這類統包案就會面臨困難, 因為統包的優勢是來自 "如何取得與整合的 know-how". 譬如早期進口大型主機, 單買匯保險, 通關與倉儲, 提貨等就很整人, 但也是一大利潤的來源. RFP 方案往例都要對客戶簡報, 每個項目負責人都要出現說明, 聽取客戶意見並做承諾. 當供應項目是以軟體為主時, 這類 RFP 形式是否合宜就值得商確. 當硬體變成買相容 PC 時, 買賣雙方對交付設備的特性越來越清楚, 像現在的中標局購案幾乎跟看單下單郵購是一樣的, 至於交貨安裝也都省了. 已經是典型的套裝形式, 賣場公開標價, 自行付款取貨的形式了. 無法成為套裝形式銷售的, 是越來越像大型建築務的建置使用, 分成建物設計與監驗, 建物營造, 內裝與修整. RFP 的過程只會出現在需求與設計階段, 營造在軟體打造上, 就幾乎跟委外到印度 outsourcing 沒兩樣, 是按規格供貨接受檢驗, 只負責交出軟體碼與文件. 只是印度從營造往前後兩端移動, 胃口越來越大. 需求的變動, 就是設計考量與規格的更動, 在模組化裝配的概念上只是換掉某個設計模組, 沒有不能變動的, 如果從設計到生產是像大型船隻那樣依設計圖分段組件, 從排程上對完成與待完成部份重新查核, 已完成但不符合的模塊需重做的, 就是印度的加人趕上時程的做法, 尚未完成的當然是按新規格造. 實務上, PG 就是軟體生產線坐冷氣房裡的 "白領勞工". -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.1.146