作者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