一般委外開發系統時都是分階段付款,前面階段倒沒什爭議,但是到後面階段,舊系統資料轉換到新系統時,因架構差異很大,轉換時還得人工檢查及補登資料,非常耗時.承包廠商認為系統功能都已經過測試符合規格,應可辦理最後驗收.但使用單位認為要等全部資料轉換完畢,並經半年平行作業,驗證無誤才願意辦理最後階段驗收. 因合約裡也沒說清楚,請問大家的經驗是如何處理?
未來如另有委外開發時,合約裡應如何敘述較好?
已邀請的邦友 {{ invite_list.length }}/5
軟體工程是非常抽象的.不像硬體等東西那麼具體.
軟體工程是非常彈性的.有些東西不能用白紙黑字說明的清楚.如果要寫的死,我想專案就不用做了.
軟體工程是一項大學問.他的專業不輸給醫師或律師.但台灣人卻不是那麼重視它.所以專案失敗是必然的.
軟體工程的合約.不是說把專業告訴法務或會計然後成合約你們就一定站在勝的一方.
軟體工程要做好:
1.花錢買經驗,專案失敗幾次後你們就自己會談.
2.花錢買經驗,花多一點錢,請個具經驗的工程師,不要想花2xk,3kx就要把工程完成.
pantc328提到：
軟體工程是非常抽象的.不像硬體等東西那麼具體.
軟體工程是非常彈性的.有些東西不能用白紙黑字說明的清楚.如果要寫的死,我想專案就不用做了.
這兩段話無法認同.....
軟體雖然是抽象的, 但是你們在談案子時, 難道都不先做 POC (Proof of Concept, 概念驗證) 就敢直接簽約下去做嗎?
我不相信 POC 做完之後, 抽象的東西還無法被具體化; 如果真的這樣, 只有三種可能:
在簽約前, 應該先透過 POC 來規避風險, 不論是客戶篩選廠商, 或是廠商篩選客戶...
以前公司的合約都是我跟法務部門共同討論擬定, 還沒遇過有甚麼「合約寫死了專案就不能做」的合約, 通常不想寫進合約裡面的事情, 就代表某一方心裡有鬼, 想要趁對方不注意, 來暗度陳倉, 規避結案責任, 或是趁機占對方便宜.
不如大家來說說, 有甚麼案例是「不能在合約裡面寫清楚」的?
可以預料, 大部分的問題, 都是「不想」寫在合約裡, 而非「不能」寫在合約裡...
我覺得兩位講的都是相對程度的關係: 說是抽象, 但也沒那麼抽象, 要具體, 有時候又很難形容是甚麼樣子......
有時候這跟客戶的關係, 案子大小, 系統複雜度等等都有關係, 一個二十萬純軟體維護案, 很難跟客戶喬到甚麼問題都用合約規範好, 萬一又是一個新客戶, 又沒講清楚, 客戶把二十萬的案子用兩千萬的規格要求, 會死人......
如果是一個兩千萬的案子, 就有可能早點用合約或是會議紀錄的方式來協調好一些風險處理方式, 但不外乎還是有非預期的情形出現, 也許這時候因為金額大, 老闆願意多投入一些資源, 或許還可以解決, 但是二十萬的案子......
raytracy提到：
大部分的問題, 都是「不想」寫在合約裡, 而非「不能」寫在合約裡...
+1
模糊空間、彈性越大，日後的糾紛越多
軟體工程,有時很難說一開始就能預估全部.
在開發時期要不斷的協商跟變化.
頗有同感 實務上 確實會如此 軟體工程只是用來減少犯錯
但絕對無法不犯錯.
+1
驗收方式應該要在當初簽訂合約之前就先談好, 先把合約翻出來, 看看上面怎麼寫的?
如果當初合約沒有定出平行作業的時間, 使用單位只能依照合約走, 不是它們想拖就可以拖, 人家只要依合約提出商務仲裁, 或是直接告上法院, 你們一樣要付款. 除非當初訂的合約裡面有模糊地帶可以協商.
平行作業的時間點應該是在專案進行前就已經談好的, 難道使用單位都沒有參與事前的準備會議嗎? 如果有的話, 當初為何不先提出修正意見? 如果使用單位沒有參與的話, 那就是公司當初決定同意平行作業時間的那個人, 要對此事負起全責.
委外合約的簽訂有層層關卡與流程, 這中間經手審查的人, 也要對此事負責.
至於將來要怎麼定? 就是事先跟廠商談好, 然後請法務, 將你們談的結果, 從白話文翻譯成法律用語, 寫進合約裡面就好了啊, 內容又不用你去傷腦筋. 資訊單位的責任只是把每個查核點和時間點都談清楚罷了.....
補充說明:
1.有經驗的PM, 早就專案初期就應該意識到有這樣的專案風險, 提早先跟User開會討論, 確定風險降低或是規避的作法, 而不是等到後期要做的時候, 由客戶提出要求, 這樣就變成了專案的問題.
2.委外合約的簽訂審查, 一般的執行者若是法務, 會計或是行政人員, 是不太可能看出專案會有這樣的風險, 只有PM或是PM的老闆會意識到可能會有類似的風險問題, 老經驗的業務也有可能會發現, 只能說制度歸制度, 如何找出專案的問題, 還是有一定的技巧與經驗累積才有可能做到阿!
swift 所言甚是, 此案是在「專案管理」方面出了問題, 包括公司自己這邊的主要負責人, 和廠商的 PM 都有責任. 這種問題應該在還沒簽約之前就已經談好了, 不能事到臨頭再來談....
難怪很多軟體公司都結不了案: 開發者怪罪使用者, 使用者也怪開發者, 兩邊推來推去, 一邊收不到錢, 一邊不想給錢; 既然如此, 當初怎麼不先把這些細節都談好, 再來執行呢?...
因合約裡也沒說清楚
認了，應該結案。
一般委外開發系統時都是分階段付款,
前面階段倒沒什爭議,
但是到後面階段,舊系統資料轉換到新系統時,
因架構差異很大,轉換時還得人工檢查及補登資料,非常耗時.
= = = = = = = = = = = = = = = = = = = = = = = = = = =
承包廠商認為系統功能都已經過測試符合規格,應可辦理最後驗收.
但使用單位認為要等全部資料轉換完畢,
並經半年平行作業,驗證無誤才願意辦理最後階段驗收.
因合約裡也沒說清楚,請問大家的經驗是如何處理?
未來如另有委外開發時,合約裡應如何敘述較好?
(恕不刪)
委外開發 :
只是 技術委外
還是 人力委外
還是 技術委外 ＋ 人力委外
委外一定要分清楚
但有人說不是資訊公司所以無法分
技術委外 或 人力委外
因此永遠搞不清楚責任歸屬
＞＞並經半年平行作業,驗證無誤才願意辦理最後階段驗收.
這是驗收標準嗎 ？
計畫異動作業
（Order: SO / PO / MO ....
: Draft/Complete/Void/Reverse....)
庫存異動作業
(PO_Receipt/SO_Delivery/PO_Return/SO_Return....
: Draft/Complete/Void/Reverse....)
是規劃出所有參數給 power-user 去設定
還是要求外包公司設定出所有用得到的單據 ？
買房子附贈 10年 每天來打掃 ？
albertachen提到：
技術委外 還是 人力委外
albertachen提到：
制度設計委外 還是 制度分析委外
albertachen提到：
系統設計委外 還是 系統分析委外
pantc328提到：
軟體工程是非常抽象的.不像硬體等東西那麼具體.
軟體工程是非常彈性的.有些東西不能用白紙黑字說明
軟體工程是非常抽象的::
這是在哪一環節
是在軟體工程成果的使用者滿意度調查！！！！
制度設計：制度分析：系統分析：系統設計：程式設計
都不可能有彈性空間：
例如：
系統設計：
開了出 Table.Column
與承載的結果關係 LineNetAmt = PriceActual * QtyInvoiced
系統分析：
開了
給 OrderLine
在 PriceActual / QtyInvoiced 異動時
在畫面 Client端驗證
CalloutOrder.java
amt()
在後端 Server端驗證
MOrderLine.java
beforeSave()
LineNetAmt = PriceActual * QtyInvoiced
程式設計才會有這些 extend 模組下加上這些 method
系統設計可能不懂程式
但是系統分析師一定要
規範程式流程師
教育程式設計師
albertachen提到：
系統設計可能不懂程式
但是系統分析師一定要
規範程式流程師
教育程式設計師
例如很細節的事也要規範
讓100個程式設計師寫好後看不出是不同人寫的：：
getPriceActual()
getQtyInvoiced()
必需先檢測是否為空值(null) 不為空值
才可以 multiply 和 才可以 setLineNetAmt()
或是
必需先檢測是否為空值(null) 空值先歸零值
都可以 multiply
都可以 setLineNetAmt()
程式設計師
沒有資格寫文件也沒有必要寫文件
但是他要填報是否依照專案標準謝做規範施工
只能說，這些是經驗累積的，有時候簽約的人跟需求的人是不同人馬、派系，有經驗的資訊人員會知道可能的後果、問題點在哪邊，給予簽約時適當的提醒、備註，但是權責劃分還是最重要的關鍵點，很多時候資訊人員完全未參與當初的決策、簽約，最後，只有擦屁股的份
個人的建議是找出當初簽約的人了解清楚，透過雙方高層的溝通來處理，談判破裂才走法律途徑，以小弟個人的經驗，外包商通常還是願意配合的，畢竟生意事得用生意方法解決，留點退路，一切好談
至於以後嘛，一次經驗學一次乖，平行作業是難免不了，至於怎麼定義，還是考驗雙方的智慧，所謂的階段付款、工程保留款(總合約款項的5%或10%，保固完後給付)，都是可以好好的運用的
iThome鐵人賽
看影片追技術