※ 引述《BalahBalah (装忙是很辛苦滴)》之铭言： : 上篇文章提到, 合约的组成除了相关法律条文以及附件之外, 最重要的两段是 RFP : 中的 : 1. 软体规格书 : 2. 供应条件 : : 先粗略的解释何谓 RFP : 建议书徵求文件 (RFP-Request For Proposal) 常理上来说, 会是为合约的一部分. : 依据 "政府资讯作业委外服务实施作业手册" 中的描述, RFP 为 : : 主要功能在载明界定委外工作需求及范畴，预先做好委托机关与有意愿之业者间的 : 沟通依据，避免日後合约执行过程中争议。同时也作为有意愿之业者提出建议书之 : 基础，及提供执行合约验收之依据。 : ====== RFP 的基本原则是供应方提供建议(Proposal), 所以买方只有需求想做甚麽, 想要 有甚麽性能, 想解决甚麽问题, 细节项目应该是由供应方提供的. 也就是针对需求 做答案, 提供建议的规格/规范与交付品的数量品名与性能, 如获采纳就是列入为合 约的一部份, 是验收项目的依据. 供应方必需说了算数, 要额外收费也要讲清楚. 不过, 真正 RFP 的做法是要有审查会, 就技术规范与费效比来评选. 但这种做法, 审计与预算核发(立院)单位都有 价位 的意见在, 基本上就是往低价竞标走, 性质 就是单一规格开标. 但规范/规格(这相当於建物的建筑设计图), 需求单位又根本 定不出来, 就形成指定一堆基本元件方块的现象(譬如 XX牌 磁砖这种表面看得到 的). : 简单的说, RFP 及为规范该合约标的物的规格, 该做什麽, 什麽时候做完, 做完之 : 後该怎麽跟客户收钱, 也就是说, 地雷炸弹都在这里面 囧 : : 软体规格书 : : 顾名思义, 即是 定义该软体标的物的规格. : 内容通常会有下列 : : @ 前言 : balah balah...好听的开场白 : @ 标的物名称 : 此次开发的软体标的名称, 含代购软体, 如 Database 等相关辅助软体及工具 : @ 软体规格 : 该软体所包含的功能列表以及描述, 专案爆炸的弹药库 : @ 其他 : 其余非功能性的客户需求, 如 "本系统须支援USER端透过IE Browser 介面连结 : 本系统，执行相关作业" 等描述 : : 标的物名称常见盲点 : : 1. 标的物所指定的代购软体,是否能符合供应条件中所描述的效能范围, 很常看到 : 的例子, 如中大型大量使用者 access AP, 软体使用 MS 平台 + MS SQL Server, : 却要求页面或是反映时间 < N秒, 啧啧...这点在後续作压力测试之後就有得吵罗 : 这就是一个指定某牌元件的例子. 这种事就会发生要把 BMW 的车壳装 丰田引擎 硬套 坦克履带的现象. : 建议 : : 开发端在 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, 相对的, 某些 : 功能可能开发人员有经验, 亦可提出让大家分享, 一起与专案团队成长才是做专案的 : 成就感. : : 後续继续整理关於供应条件的部分 ^^ : ============= 最根本关键的两个问题就是: 1.政府不应该把钱发给公务预算单位, 要求其执行软体委外购案. 2.全世界的公务员都是一样的, 要公务员涉及规划, 他是不知怎麽做但可很会要求的. 而验收或妥协谈判, 要基层公务员负责那真是与虎谋皮. 如果, 把钱拿出来找缴税最多的厂商, 用无偿配合款请厂商拿钱出来对其公司业务 做电脑化委外, 或融资低利贷款给大公司成立独立的软体公司来包这些软体案, 这 些商业公司为了能拿到退税款又能改善公司体质一定会尽力想完成, 此时她会要求 其公司内部的 IT 人员全力配合外包厂商(也可能是投资分设出去的)完成系统, 等 商业公司都完成运作了, 再要求政府机关照抄规格引进, 此时规格与价位都有例可 循, 公务员在商业公司都能使用下就没有藉口做一堆有的没有的要求了. 此时, 这 些新增的软体公司除了这些雷同的政府机关包案暂缓一口气外, 就应力争扩大市场 机会, 拿成功的软体到国外争取机会. --

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