※ 引述《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