Day8 - 程序设计报价 (三) - 常见问题

上一篇文章中介绍的报价方法，在我这一年多来的实验结果，碰过很多无法接受或是仍旧希望要有报价单、合约书的客户，面对这类的状况，我会持续沟通这样合作的好处，进而先尝试合作一些小案子看看，让他们实际感受到这样的模式对双方都有益处，另一方面可以让自己站在客户角度来思考他们的问题，提供真正对他们有帮助的建议，这样才能建立信任并保持长久的合作关系。

当然，任何方法用在真实世界总是会遇到很多挑战，下面整理出一些我常被问到的问题：

Q1. 没订金、没报价单、没合约会不会没保障？

就算有订金、报价单、合约书也常常有做到一半人不见或是因为各种理由收不回尾款的案子，所谓的保障，对双方来说就是时间到了看得到成果并且拿得到酬劳，一堆文件作业也都是为了要确保双方能信守承诺、当其中一方背信时有求偿损失的备案而已。

对接案者来说，时薪计价最大的风险就是在於一个月的款项请不到，也就是白做工一个月，相较於以往好几个月才能请一次款，只损失一个月的工作小时数已经是不幸中的大幸，而且只花一个月甚至几周的时间就可以认识一间公司或一个人，不用花上好几个月或好几年的时间才知道，已经算是少走很多冤枉路了。

当然，如果要上法院，每周定期回报记录 Email 都能拿来作为证据，但还是要衡量官司打下去的成本是否会让自己深陷泥沼，毕竟一般有规模的公司都会有法务部门来专责处理法律纠纷，程序接案者或是小型工作室这方面就会比较吃亏。

对发案方来说，合作一个月的过程中就能知道对方的工作方式，像是有没有定期回报进度、是否有固定产出，如果发现苗头不对，不用等到一个月，可能只要几周的时间就能知道是否要提早结清工作时数并寻找下一间合作厂商，如果有合约在，片面解约都是需要付出成本的，所以为了避免罚则，纵使知道合作对象有问题，还是必须要硬撑下去走完合约，通常最後的结果都不会太好。

Q2. 预估工作项目跟实际执行时间有落差？

在客户需求还没有完成需求确认、操作流程等等的功能细节前，所有的估时都是凭着过去经验来做预测的，就像要做一个购物网站，基本会有的功能像是购物车、结帐、金流、物流串接等等，这些都有过去的时数可以参考，但每家公司的商业情境不同，管理需求也不同，因此实际执行上一定会跟当初预估的工作项目有所落差。

但透过每周的定期回顾，就会慢慢厘清整个专案到底有多大，以及目前的完成进度百分比，所以重点应该是放在持续的追踪与沟通，只要能透明化专案的资讯，客户就不会觉得计时是黑箱作业而产生不信任感。

Q3. 开会也要计时？

一个专案最花时间的地方不是坐在电脑前面写程序，而是厘清客户的需求以及确认成品是否有达到客户的商业目标，初期的需求沟通的越明确，就越能减少後期修改的时间，但要能协助没有网站专业知识的客户厘清需求是一门学问，而且很多时候懂得这些专业知识的客户也会把功能变得错综复杂。

这是人之常情，在一个专案被发起时，公司内部会有许多的声音需要整合，好的整合是可以排出优先顺序，但大部分情况是所有需求都要实现，因此会产生矛盾与冲突，譬如说客服部希望在每页的页首可以放上明显的客服信箱连结，以减少客服电话的量，但业务部希望放上联络电话，就能跟客户进行直接销售。

没有整合好的需求就会变成 Email 跟联络电话同时以巨大的字级显示在页首，什麽都要显眼最後就会变成什麽都不显眼，这时候厘清客户的需求後就能提供相对应的作法，譬如说在电脑版显示 Email、手机版显示电话号码，或是采取 A/B test 来实验怎麽放会比较好，这些都是接案者的经验，这些经验没有办法 Google 得到，因为这是根据客户的情境所设计的。

问出正确的问题、提出有效的作法、帮助客户厘清真正重要的目标，这就是开会时接案者所提供的价值，就像美剧上常看到的心理医生谘询一样，开会计时才能把沟通成本具体化，进而改善沟通效率。

Q4. 为何这个工作项目要花这麽多时间？

有些客户会质疑某些工作项目应该不会太复杂，花这麽多时间不太合理，这样的情况有两种，一种是任务没有被正确的拆解，像是要做购物网站，购物功能只被当作是一个工作项目，购物功能包含有前台页面的建置、商品管理、订单管理、金物流串接、会员功能等等的细项，如果只列了一个购物功能可能就要会花费数十个小时来开发，从总小时数来看就会觉得这个单一工作项目花了太多时间。

另一种情况是客户懂技术，他们以自己过去的经验来判断，所以会觉得某些时间的花费不合理。当然，工程师程度有高有低，做事的方式也会有所不同，这时候版本控管就是很好的沟通管道，因为程序码的透明，客户可以看到专案的原始码，进而提出改善建议，也能判断承接的工程师是否有办法胜任这个工作。

所以当客户质疑某工作项目的时数过多，根据拆解後的任务来进行讨论就是很具体的作法，让客户可以明白每个待办事项的目的，让客户知道这功能不是按下 Enter 就能搞定的，也或者是经过讨论後我们会发现某些环节是不需实作的，藉此能降低整体开发时数。

Q5. 程序的保固期间该如何计算？

不用计算。

通常保固指的是当专案已经过了约定结案日期後，如果还有发生程序上的臭虫需要被修复的维护期间，在保固期间内的 Bug 修改，接案方有责任协助处理，这时候问题就来了，到底什麽是「臭虫」？网站开不了？功能无法正常使用？实际用起来应该这样改比较好？

关於臭虫的定义也是一个吵不完的话题，常常客户觉得是 Bug 的地方也许是某个逻辑没有实作，但对於接案方来说这个逻辑并没有在当初开发时接收到客户的需求，而且结案时不都已经验收过了，怎麽会现在才发现有这样的问题？或是更多时候是使用者发现的 Bug，这些都让臭虫的定义很难有一个客观的标准，除非在合约书里面列出所有关於臭虫的定义。

回到保固的定义，指的是过了「约定结案日期」後的维护，以敏捷式接案的定义来看，并没有所谓的结案日期，因此也就没有保固这样的概念。网站上线後有问题，持续的以时薪计价进行修改臭虫或是根据使用者回馈进行调整，就不用为了保固范围而牺牲能让网站变得更好的改进措施，而接案方也能提供更多实务上的建议让网站达成商业目标。

Q6. 时薪计价对动作快的工程师很吃亏？

很常听到不建议接案者采用时薪报价的理由是因为动作越快能赚到的时数薪水越少，所以会很吃亏，但我的经验是能把事情用最快的方法解决，藉此取得客户的信任，才会有接不完的工作机会。

要知道，一个持续在经营的网站每天都会有各种大大小小的状况需要排除，或是根据顾客的使用回馈进行调整，如果客户信任你，你完全不用担心会没时数可以赚，反而会觉得好想赶快把功能完成让客户可以去拼业绩，然後客户业绩因为你的协助有所提升，进而会再开更多需求来请你处理，达成一种正向循环。

Q7. 时薪计价接不到大公司的案子？

只要你有能力可以解决客户头痛已久的问题，那麽公司就不会在意要用什麽方式跟你合作，然而可能还是需要一些文件来完成形式，尤其是请款流程，但因为你的价值，客户会自己想办法去设计出一套适合这样合作模式的流程，你就不用再花时间去处理这些行政事务，进而专注在解决客户的问题。

Q8. 这样接案真的赚得到钱吗？

绝对赚得到。

以往专案的计价方式会分三期付款，头款订金，做到某个程度收二期款，客户验收完成後收尾款，更大一点的案子可能会分更多期，但除了头款以外，剩下的款项都是要看客户脸色，有个万一的话，可能会长达好几个月没有收入，只能靠着头款来过活，更不用说接一些二包或 N 包的政府标案，这是要等大包结案才有得拿的。

很多案子看似金额很高，但扣除掉实际执行的天数後，换算下来的月薪常常比上班族还要可怜，因此用时薪计价的月结方式，才能保持稳定现金流，每个月的工作有拿到酬劳事情做起来才会愉快。

当然，以上的说法不可能百分之百让每一位客户都能买单，公司有各种的行政流程与企业文化，有些还是坚持要有报价单合约书，并且采用专案方式计价，遇到这种也没关系，就果断的放弃这个机会吧，世界上一定还有其他的客户值得你跟他合作，要记住，我们自己接案就是要获得心目中理想的工作方式！

搞定报价後，下一篇我会介绍敏捷式接案该如何启动专案，以及如何确认需求并且拆解成明确的执行项目。

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