Day7 - 程序设计报价 (二) - 重新定义甲乙关系

从传统的接案甲乙方关系我们发现,因为利益的冲突,甲方也不可能得到乙方 100% 的专业协助,因为乙方要的是结案,没有在报价单里面的项目乙方没有义务提供,但甲方花了钱就是希望为了获得这些专业建议,所以造成彼此双输的局面。

所以我对於结案的认知,并非是收到尾款或是过了约定结案时间後就算结案,而是乙方可以满足甲方的商业目标而提供持续性的专业建议,当甲方决定暂停该专案或是结束与乙方的合作关系时,这才是所谓的「结案」,当甲乙方的关系不再是短期的专案性质,而是持续性的互惠合作,这样的接案方式我称之为「敏捷式接案」。

敏捷式接案的核心精神是舍弃传统的报价单、合约书,改用时薪估价、Email 约定合作细节,并透明化开发过程,像是分享时间记录、开放版本控管权限、每周固定回报进度等等,再根据实际花费时数来计算费用,以月结的方式来减少发案方的一次性大额开销以及维持接案方的固定现金流。

很多案件刚开始时甲乙双方都不熟悉,谈的时候很愉快,结果实际做起跟彼此的想像落差很大,在敏捷式接案中发生这样的状况也没关系,就直接终止合作,随时都能「结案」,不需要为了硬撑合约书上的条文而折磨彼此,更不用吵已经做的进度占专案总金额的多少比例来退费。

在这样的合作模式下,报价就再也不是固定的金额,而是在专案初期针对已经知道的部分进行开发时数预估,同时也能把需求访谈的时间估算进去,然後把总小时数乘以单位时薪,就能让客户大概知道要准备多少预算来执行这件事,重点是要让客户明白这个金额不是案件的总金额,一切都只是预估,是会有变动的。

如果客户已经很明确的知道他要做的功能,那我就会把要做这个功能的每一个流程拆解成小单位来进行估时,譬如说以评估串接金流时数为例:

(一) 前置作业 - 2 小时

  • 金流串接相关资料交付确认 - 1h
  • 开发环境与程序码部署配置 - 1h

(二) WooCommerce 设定介面开发 - 4 小时

  • 设定页面需求确认 - 1h
  • 新增金流设定栏位 - 1h
  • 前台结帐页金流选择介面 - 2h

(三) 信用卡金流串接 - 12 小时

  • 串接需求确认 - 2h
  • 金流商授权验证加密机制- 2h
  • 传送订资料栏位处理 - 3h
  • 金流商回传资料写入 - 3h
  • 交易失败处理 - 2h

(四) 测试&资料移转 - 3 小时

  • 测试&正式环境信用卡金流测试 - 2h
  • 外挂程序移转至正式机作业 - 1h

这份列表的重点是我把沟通成本的时数也一并评估进去,像是客户提供功能开发所需资料的时间、需求确认的时间、测试的时间等等,这些以往都没办法放进报价单里面的项目,如果是用估算的话就能很让客户具体的看到做这件事情所有的预估成本,这样比只列出空洞的大项目更能让客户把焦点放在要执行的具体细节上而非只是在意专案总价。

每个项目的估时我是参照 Scrum 的故事点所设计的,虽然 Scrum 强调的是以相对的时间单位来预估开发复杂度,但我从经验得知用绝对单位才能让客户感受到实际的花费,我的时间预估有四种单位:

评估 1 小时的项目:通常是我十分钟就可以解决的事,也就是完全不复杂、可以快速搞定的功能,但也不是没有评估错误的时候,万一估错的话我就还有 50 分钟的时间可以来把问题厘清,并且检讨自己为何会错估的原因。

评估 2 小时的项目:做过类似的功能、可以在脑海中想像开发这个功能需要哪些步骤,虽然可能会有点复杂,但脑袋很清楚该如何实作出来,或是需要跟客户一起合作讨论的项目,这让会议时间也能收费。

评估 3 小时的项目:需要打很多字的功能,像是上面例子中的要处理传送给金流商的一堆栏位,以及拿到回传资料後的处理,或是需要处理前端 UI 的部分,我都会估三个小时。

评估 4 小时的项目:自己从没做过项目、脑海中无法想像会有哪些步骤、需要花时间先进行研究的功能,随着经验与能力的提升,需要 4 小时的项目会越来越少,大部分都能拆解成多个 2 小时的项目。

我的评估项目不会有超过 4 个小时以上的,如果超过 4 个小时,就代表这个项目太大了
,还没有被拆解成能被执行的最小单元,把每项功能拆解足够细的任务後,就能把所有项目的小时数进行加总乘以时薪,就可以估算出开发这个平台至少要准备多少预算,万一超出客户预算太多,就直接从清单中去删减,留下真正需要的功能,或是请客户排出优先顺序,把资源用在真正重要的事情上。

随着开发的经验越来越多,写一份评估表可以越来越快,可以省下整理报价单的宝贵时间,也能采取更弹性的作法,像是客户希望设定每月预算,就能以不超过这个时数为前提,优先开发客户在意的功能。

待预算经过客户确认後,就能开工了。对,不用订金、报价单、合约书,彼此合作的约定只需要透过 Email 保存即可,这时候只要在收信软件开一个专案的资料夹,然後把关於这个案件的信件全都往里面丢即可。

这样的方式听起来好像很梦幻但又觉得抖抖的,心里会怀疑真的有客户会接受这样的合作模式吗?没有先拿到订金、审过报价单、合约书,之後发生任何纠纷该如何是好?下一篇文章我会整理出这种接案模式面临的挑战,以及实际运作之後遇过的问题。

本文同步发表於:https://oberonlai.blog/tw/wordpress-freelance-quotation-2/


<<:  [CSS] Flex/Grid Layout Modules, part 2

>>:  Day 2 AWS 是什麽?又为何企业这麽需要 AWS 人才?

JavaScript内建标准物件:日期

JavaScript 除了原始资料型别例如数字、字串、布林等等以外,所有的资料类型都是物件。日期与时...

[今晚我想来点 Express 佐 MVC 分层架构] DAY 28 - node.js 与线程 (上)

node.js 之所以能够运行 JavaScript 程序码,是因为底层依赖 google 在 ch...

calc()

calc() 是一个 CSS 的函数,功能如 function 字面上的意思,在设定属性的时候可以进...

【Day27】线性收敛除法器实作

在加减乘除四个基本运算中,其中除法最为困难及复杂,因此除法也是最耗时的运算。 对於一个被除数为 N...

[Day28] 沟通之术 - 测试工程师篇

这是铁人赛接近尾声的倒数第 3 篇~今天就来讲讲跟测试工程师的沟通之术吧! 前言 原本是个坐在位置上...