Day9 - 敏捷式接案实践 (一) - 拆解需求

以时数评估的方式来报价，最大的好处是可以大幅减少专案从接洽到真正启动之间的时间，这段时间越长，对於接案者现金流的风险越大，因为在等待签约的过程中，你不知道是否该继续谈新案子，万一谈了，有可能会超出自己的工作负荷量，如果没去谈，原本正在谈的案子万一没成交这个月就要喝西北风了。

有接案者为了维持现金流，只要有新案子就一律都去谈，为的就是能够先拿到案子的订金来撑过这个月的开销，然而手上累积一堆案子做不完，只好再外包或是开始请人，於是每个月的开销又变得更高，只好再去接更多案子，这样很容易让开发品质下降。

透过时数评估方法，依照过去的经验平均可以在一周之内决定是否要启动专案，因为当任务被有效拆解後，对决策者来说资讯透明能更快的下决策，因此如何快速的有效拆解客户需求以作出评估是很关键的一环。

拆解的方法首先是区分开发性质，WordPress 外挂开发的工作不外乎前台资料的 Query、後台设定页面、取得或传送资料给外部服务，以及资料的写入，只要掌握这几种性质就能知道该如何列出工作项目，像是以开发金流为例，需要把订单资料传送给金流商，再将金流商回传的资料写入资料库，最後在结帐页显示对应的交易结果。不同的付款方式都会有类似的流程，所以就能根据付款方式详列出需要开发的步骤。

其次，拆解的项目中应该也要包含确认完成标准与测试除错的时间。

确认完成标准指的是对客户来说这个工作怎样算是完成，重点在於站在客户的立场，而非自认为把程序写完就算完成。通常我会用使用者故事 ( User Story ) 来描述客户的需求，描述的基本公式为：身为 ( 某种使用者 )，我可以 ( 进行某种操作 )，以达到 ( 某种目标 )，再以开发金流外挂为例：

• 身为顾客，我可以在结帐时选择 A 金流商的信用卡付款来完成结帐
• 身为顾客，我可以在刷卡完成後看到交易结果，以确保有正确的完成付款
• 身为管理者，我可以在顾客刷卡时收到电子邮件通知，以确保交易过程正常
• 身为管理者，我可以在後台订单管理看到顾客的刷卡方式，以作为後续管理之用

当列出这些故事以後，客户可以完整的看到他的需求的各种面向，尤其是不同使用者之间的操作行为是为了要达成什麽目标，进而思考还有没有什麽情境是没有被考虑到。像是顾客身份有可能会区分为已注册或未注册顾客、VIP 与 VVIP 顾客，或是购买不同类型的商品会对应到不同的金流结帐方式，这些可能都是客户没有想到的地方。

因此在确认完成标准的这个环节，我就会开始计时作为专案正式启动的第一步骤，不管专案大或小，一定要请客户确认完成标准，因为当讨论下去之後，可能会发现原本评估的 A 项目不需执行，反而还多增加了 B 跟 C，这都会影响实际开发的时数。

例外一个必要的工作项目就是测试与除错的时间，我会把这个时间拿来写单元测试，或是把一些外挂的核心功能用自动化脚本定期执行，藉此来确保外挂能正常运作，但要跟客户沟通清楚这边的测试与除错只限於开发中的状况，等到开发完成上线後发生的臭虫，会需要另外花时间处理。

因为使用者总是可以用我们从没想过的方式来进行操作，或是使用的装置以及环境问题导致了某种例外状况，这些问题都是我们要一起与客户学习并经历的过程，尤其是在 WordPress 这种庞大又错综复杂的环境下，可能只要更新某一支外挂就能造成例外错误。

当我们花了很多时间评估时数、确认完成标准，跟客户反覆沟通实际要执行的项目，但永远要记住，真实世界充满了无数的变数。

我遇过实际开工後，执行了三分之一时，发现到这个功能的逻辑并非我想像的这麽单纯，通常 WordPress 只要找对关键字就能得到很多现成的答案，再来东拼西凑就能完成，但找不到解决方案就要自己设计，所以会多很多步骤。

如果距离该项目的剩余可用时数不到一小时，而我预计可能需要再两个小时，那麽就要赶紧回报客户目前手边遇到的困难，并且解释需要这两小时来做哪些项目，让客户理解状况以进行评估，如果客户不能接受，那就要思考出变通的方法或是先搁置这个项目，等之後有预算再来进行。

另一种情况是客户所在的商业环境产生变化，可能昨天讨论的使用者故事需要新增或修改，这时候就需要再回到确认完成验收标准的阶段，整理出使用者故事後再次拆解任务。总之，任务拆解是动态的，不是拆完後就固定在那边了，重点是要能够让客户理解做这件事需要的步骤与时间即可，随时调整是敏捷式接案的常态。

把任务拆解完成之後，接下来进入实作阶段，下一篇我会介绍最重要的计时工具以及看板方法。

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