上篇文章提到, 合约的组成除了相关法律条文以及附件之外, 最重要的两段是 RFP 中的 1. 软体规格书 2. 供应条件 先粗略的解释何谓 RFP 建议书徵求文件 (RFP-Request For Proposal) 常理上来说, 会是为合约的一部分. 依据 "政府资讯作业委外服务实施作业手册" 中的描述, RFP 为 : 主要功能在载明界定委外工作需求及范畴，预先做好委托机关与有意愿之业者间的沟通依 据，避免日後合约执行过程中争议。同时也作为有意愿之业者提出建议书之基础，及提供 执行合约验收之依据。 简单的说, RFP 及为规范该合约标的物的规格, 该做什麽, 什麽时候做完, 做完之後该怎 麽跟客户收钱, 也就是说, 地雷炸弹都在这里面 囧 软体规格书 顾名思义, 及事定义该软体标的物的规格. 内容通常会有下列 : @ 前言 balah balah...好听的开场白 @ 标的物名称 此次开发的软体标的名称, 含代购软体, 如 Database 等相关辅助软体及工具 @ 软体规格 该软体所包含的功能列表以及描述, 专案爆炸的弹药库 @ 其他 其余非功能性的客户需求, 如 "本系统须支援USER端透过IE Browser 介面连结本系统 ，执行相关作业" 等描述 标的物名称常见盲点 : 1. 标的物所指定的代购软体,是否能符合供应条件中所描述的效能范围, 很常看到的例子, 如中大型大量使用者 access AP, 软体使用 MS 平台 + MS SQL Server, 却要求页面 或是反映时间 < N秒, 啧啧...这点在後续作压力测试之後就有得吵罗 建议 : 开发端在 Kick off 之前, 或是专案初期先行找使用者沟通, 最好能提出相关类似案 例或是数据佐证, 慢慢的在过程中洗脑客户, 切忌跳过此问题, 尤其当供应条件或规 格中有明定相关效能的范围, 则这个问题会很严重的影响验收时程, 导致无法验收或 是客户提出减价验收砍尾款! 若是使用者端, 则规画初始最好能多找几间厂商提出 Solution比较, 并请厂商也提出相关佐证资料列入合约附件. 2. 相关辅助软体或是工具适用性与常规工具符合, 我就遇过某银行不同意驻点 工程师开发 Java AP 使用 eclipse 而要求使用 RFP 内定的 WSAD, 每两三天就下来 突击检查, 把工程师差点搞跳楼 建议 : 专案团队成立之前, 请 PM 先与公司主管沟通, 由公司内部寻找相关资源, 起码有一 个能撑场面假装也交代的过去, 客户端也可多考虑市场上众多免费工具, 当然, 还 是请开发端厂商提出资料佐证该工具的授权或是稳定性评比等. 软体规格常见盲点 : 1. 传说中的 "common sense", 很多客户端在撰写或审核 RFP 的同时， 都会陷入业界 常识的迷思中, 基本上, 合约的意义即为规范该买卖交易的所有内容, 请注意, 是 "所有" 内容, 合约范围内无例外,表示未写入的 "常识性" 功能, 开发端并无义务 必须无偿配合, 举例来说, 银行业内对於数字的常规, 有三位一撇的基本惯例, 像是 "1000" 必须於 AP 上呈现 "1,000", 这种功能大部分的 RFP 中不会定义到, 客户会说这是常识嘛, 厂商这麽专业应该要懂, 正常状况确实如此, 那麽, 当专案 遇到时程延後或是与客户端沟通不良火气大的时候, 什麽业界常识都变成延迟以及 互相刁难的的藉口. 建议 : 使用者端尽量的在 RFP 中详细描述可能会用到的功能, 我知道有困难, 不过等使用者 多接触过开发专案, 就会很熟悉常常被厂商推拖的常识性功能为何, 请列入 RFP 内, 当时程赶的时候, 可与开发端签定 MO 或是承诺书, 於不影响功能前提先行验收後补 开发端遇到客户提出非 RFP 规范的常识性功能需求, 如果功能不复杂, 则先行列入待 议事项, 於最後讨论待议事项的同时, 与客户谈判相互让步, 某些功能我吸收, 其他 的请客户吸收, 请一定要先行做出一点的让步才能使客户也让步, 至於复杂的功能, 则回应会请公司的主管再来讨论 (当然是回去请业务来炉加价啥的..), 切忌当场同意 , 否则相关责任会由同意的人扛 2. 一言以蔽之型功能, RFP 常出现这种超级大地雷, 短短的几个字道尽千言万语, 甚至 还有某功能其实是拿着别人的产品来构思,谈需求的时候直接丢一份别的厂商整本系统 说明文件让开发端照做傻眼情况. 建议 : 签订合约之前, 甚至追朔到业务还在跟客户谈案子的时候, 请公司一定要让产品经理 或是 Solution Consultant与客户端针对 RFP内容先行做初步访谈, 此步骤绝不能省 若是已签定才发现, 请保重, 後续就靠专业的专案经理跟业务的临场反应来救命 囧 客户端同上个建议, 尽量撰写 RFP 详细, 或标案之前要求厂商先行过来了解访谈, 开发端跳票不是只有开发端要负责任, 客户端也需同理心看待, 案子出现问题该 年度使用者人员/ 单位 KPI 也不会好看到哪, 不是吗? 3. 外部资源连结需求, 除了很单纯的固定系统之外, 现行的软体几乎都要做整合这个动作 整合啥? 整合资源, 整合单位, 整合使用者, 整合功能, 外部整合相对是容易从 RFP 中规范也容易被 RFP 忽略, 当厂商开发到一半突然某功能必须要跟啥鬼系统连接, 欲 哭无泪 建议 : Kick off 的会议中, 有一张图片必须带到 RFP 关於外部资源整合的列表, 表示各位 都清楚, 往後翻案也有理由让客户让步, 另外需求访谈同时也需要另外撰写外部资源 列表以及防火墙等规划, 以视开发端重视程度. 使用者端请於规划系统之前, 先行内部沟通协调, 某些系统或功能可以统一规划, 则 避免各做一套, 以免管理出现漏洞以及集团或公司整合资料困难. 以上这几种关於软体规格的内容描述,是我遇过出现频率最高的问题, 当然, 事先阅读过 合约相关资料, 配合一定的公司资源 (如产品经理等), 能确实的在专案初期让团队评估 原始风险, 虽然不能完全避免, 却也能让专案团员多了解该专案的目的以及资料, 也让 专案团队有参予的感受, 而不是不受重视的 coding BOT, 相对的, 某些功能可能开发人 员有经验, 亦可提出让大家分享, 一起与专案团队成长才是做专案的成就感. 後续继续整理关於供应条件的部分 ^^ --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 61.62.23.235