自从改变自己的工作模式後,现在平均的案量是每天有计时的工作时数大概是三个小时,并且同时有三位长期配合的客户,周休三日,礼拜三强制自己排休,维持做二休一的节奏。
「每天只做三小时却能同时接案三位客户!?」
如果在我还没转型前有人跟我这样说,我会觉得这人一定是在唬烂。以前我的极限是一个月两个案子,然後每天工时至少八小时,常常做到晚上加班加到十、十二小时也是家常便饭,为了要让专案赶在某个约定好的日期完成,就是只能一直拼命的做做做。
现在回过头来看待以前的自己觉得好不可思议,每天忙得跟狗一样却没什麽成就感,心情又很容易受到客户意见的影响,尤其是做好的功能又说要改,规格一变动工时的爆增就无法避免,这篇文章就是要来跟大家分享我是如何转型成 333 工作法。
常遇到客户来信说他需要一个网站,然後接下来的问题就是多少钱以及要做多久,有时候也会在 FB 的接案社团里面的看到业主的发案文,简略描述了案件需求後就希望徵求报价与开发时程,然後就会看到留言区盖起私讯墙,其中还不乏说已私讯报价与制作时间。
我每次看到心里都会有一个大问号:「在根本还不了解客户需求的具体工作事项前,这个价格与时间都是怎麽评估出来的?」但事实上我知道答案,因为我以前也是这样报价的:假设客户要一个购物网站,根据过去专案的经验大概需要两个月,如果时间是两个月,我就把我的生活成本以及想要赚的部分加好後作为报价。
所以接下来为了要在两个月完成这个案子,一定要花上所有的时间把它做完,因为没做完我就赔钱了,案子多拖一个月,就等於多赔一个月的生活费,而且最重要的是我想努力把案子结掉,所以根本没有心思或时间再去接洽新的案子,因为只要接了另外一个案,原本的案件能执行的时间就会被压缩。
所以一个月同时进行两个案子就已经是我的极限,光是要厘清客户需求、规划程序架构、功能开发、测试,就让我精疲力尽,而且这样的时间规划完全没考量到客户的商业情境,因为当功能真正实作出来之後,老板看到後会觉得好像应该再加些什麽,老板的老板也会有想法,所以当做好後要再加东西总是会让我火冒三丈,心里总是有 OS 说为何不一开始提出来?但冒完後就还是往肚里吞,为了结案继续默默的修改。
这样造成的结果就是每天工时拉长,两个月内要完成的话,每一周都会有必须要完成的进度,如果稍微延迟了,加班把进度追回来是一定要的,但如果是客户需求变动而造成工作量增加,还是要想办法把在时程内完成。喔,对了,等待客户回覆确认需求的时间也是算在时程内喔~
现在,如果客户希望某项专案可以在某个日期前完成我绝对不会立刻答应,我会先估算开发小时数,然後根据最近手边工作量来确认该功能在一个工作天之内我能分配多少时间来处理,譬如说如果总工时我评估需要 10 个小时,而我现在每天可以分配两个小时来做它,那麽至少需要五个工作天。
所以关键在「工作事项」,特别是规模稍大一点的开发专案,在初期的评估根本无法预料到底会花多久时间,因为从想法到具体实作之间还存在着大量的空白需要被填补,很多细节是客户甚至是我都没想到的状况,因此在专案初期就要能订出准确的开发时程,这基本上就只是在瞎猜,猜完後让客户安心而已,实作後发现时程超出预期,就必须要花更多心力争取时间与预算。
因此我通常会回覆客户说等专案进行了几周後,再来确认是否有可能在他们希望的时间内完成,当开始执行後就会知道需要实作的细节以及可能会花比较多时间的工作项目在哪里,进而讨论这些工作项目是否要在该阶段开发,如果这些项目都要完成,以小时数换算成工作天,再来估算最後完成日才是有依据的时程规划。
但在实务经验上,就我接触过的公司来说,会严格遵守「预定上线时间」的客户少之又少,大部分都是开案时讲得十万火急,然後开始执行後才发现到有许多不可控因素在影响专案时程,因此控制「工作事项」比控制「时间」来得重要。具体的说:
把焦点放在「解决客户关键问题」的工作事项上。
理解客户的期待是在於「解决问题」而非一定要把所有工作做完後,就能让自己从被时程追杀的压力中释放出来,但偶尔还是会接到客户的紧急电话说这个东西今天一定要处理好,会有这样的状况有两种可能性:
第一种是公司有重要的商业决策需要执行,而这决策因为外在环境的变动所以来得非常临时且突然,接到这种需求下我会把目前手上正在进行的工作事项提醒客户,说明本周预计执行的项目是否要延後,同时评估新功能需要的工作时数,先把具体的待办清单列出来,就可以让客户清楚的了解开发这功能的步骤与项目。
因此客户就会开始思考如果今天就要完成的话可以先做哪些他真正需要的,或是根据工作时数来推迟下决策的时间,譬如从一天变三天,也可以评估是否需要寻找其他外包厂商进行协助。
第二种可能性是公司内部在忙其他专案,很多功能已经开发完成但还没验收,然後某天老板想到这个专案,就开始追 PM 专案进度,而 PM 可能当下也在忙别的专案,被老板追杀後再来追杀外包厂商,这种情况下就会出现所谓的「紧急会议」。
每次参与这种会议压力都很大,因为 PM 会在会议前把累积的待测试项目一口气测完,然後一口气把所有问题丢出来,看起来接案者好像没做事一样,通常这样的下场就是压时间,并要求在期限内全部修改完毕。
遇到这种情况我会择期再约,一来当天手上都有既定的工作要完成,二来在会议前的这段时间,透过专案管理工具来提醒 PM 该验收的项目,并请他们提出修改需求,让专案可以重新动起来,动起来後召开的会议就比较能聚焦在解决问题上。
这半年来我尝试了很多,发现到不是所有类型的案子都适合自己的工作方法,像是一页式需要快速完成切版或是大型专案要配合其他人员时程的案子我就无法承接,相反的,既有网站的功能修改、新创平台或是刚起步的网站开发比较适合我,而且看到因为我的协助而让客户的业绩蒸蒸日上可以让我从中得到成就感。
虽然工作方法很明确,但有时候还是会破了戒,像是晚上加班、一天工作十小时,所以我帮自己订了以下的原则:
要维持这样的工作型态,要有不害怕失去客户的勇气,这勇气有些人可能是天生的,但也可以後天训练得来的,像我就是後者,有时候下班後会不小心喵到需要修改的急件通知,或是明明是放假日,但有些功能还没收尾,心里都还是会很想开电脑去把它改完。
归根就底,我很害怕因为客户不满意我的工作效率而不再与我合作,後来我告诉自己,如果客户真的这麽在意专案进度,那麽他们应该是直接聘请工程师才能有效掌控时程,客户选择外包主要的目的还是在於解决问题,那麽只要在预计时间内解决,那些无法立即处理的急件就是公司本身的问题而非在我身上了。
最後就算真的因此失去客户了,我反而能把时间花在创造其他收入来源的工作上,在下一篇文章中,我会介绍工程师接案的收入管理,该如何决定自己的价值,取决於你如何看待自己。
本文同步发表於:https://oberonlai.blog/tw/wordpress-freelance-practice-3/
>>: [Day03] swift & kotlin 入门篇!(1) 基础语法-变数与常数宣告
日志的写入 相信很多人会在程序内埋log以便问题的追查,尤其是线上的问题不能像开发时期可以设定中断点...
今天的内容为导览列显示之触发,当滑鼠移入导览列,会显示对应内容。 <body> <...
二、特性 匿名函数 (没有名字的函数) package main import ( "fm...
前言 利用前几天的篇幅,简单的讨论敏捷与 Scrum,也传达了我觉得团队需要注意的地方。今天再让我们...
先前介绍了很多关於 Git 的常用指令以及使用情况,但目前我们都只是在本地端操作而已,如果需要跟别人...