Day 28 - Clean Coder 时程与承诺

前言

今天会接续着昨天的主题,来聊聊 The Clean Coder 的另一个主题。

在我过去的工作经验中,写过的程序性质各有不同,有充满前端互动UI逻辑的(着重在 DOM 操作),有透过资料、状态驱动的(着重在管理状态),也写过後端,一点画面都没有的(?),因此我的技能树也一直乱长。

但其中不管哪一份工作,都会有一个灵魂人物 - PM,会不断帮助我锻链,一个到哪都用得上的技能。

预估时程

对於很多 developer (以下简称 RD)来说,经常都会有被 PM 要求预估时程的经验。

因为公司只要开着,每天都在烧钱,晚一天交出程序,公司就晚一天从客户手上赚到钱,意味着多烧一天钱。

尤其是新创公司,不像大公司可能有其它产品线,可以来养这个 team,新创完全就是只能靠自己。

而做为一个 PM,一定是被上层第一个追问状况的人,所以当然就再往下询问 RD 时程罗!

真相先行

不是所有 PM 都是从工程背景出身,甚至可以说满大多数都不是,若真的遇上能沟通又是工程起家的 PM,请好好珍惜。

因此,最了解程序的 RD,是有责任要在预估时程的时候,跟 PM 报告「真相」的。

「真相」就是:「客观中立的时程预估」、「预估背後的原因」

不乐观、不悲观,预估一个以目前的能力,最有可能的完成时间,以及为什麽需要这麽多时间,背後有哪些困难与阻碍

尤其当 deadline 愈紧,PM 会愈着急,毕竟如果没有如期交付,要直接面对客户,被喷一嘴口水的人不是 RD,而是 PM。

所以在沟通时程的时候,往往会带一丝紧张,但需要切记,愈是紧急,就愈是要将真相说清楚,踩住立场

==== Round 1 ====

PM: 明天就是 deadline 要交付给客户了,你的程序还要多久!?
RD: 我预估还要 2 天的时间,因为现在这个 bug 牵涉到系统底层的架构,也就是说,如果没处理好,很有可能会造成其它本来正常的东西坏掉,所以我需要时间谨慎处理。

==== Round 2 ====

PM: (瞪大眼睛)两天!客户当初说明天就要看到成果,我们也答应过他了,你知道这个客户对我们来说非常重要吗!? 我们真的丢不起这个客户欸!有机会一天吗拜托!
RD: 我理解,但如果因此赶工,很有可能会导致其它客户受到影响,到时候我们反而要花更多心力去弥补,我想这也不是我们要的结果。

==== Round 3 ====

PM: 唉!真的没办法?(用眼角余光偷瞄你)
RD: 真的没办法。(坚定)

==== FINAL ====

PM: 好吧,那我打通电话跟明天的客户说一声,麻烦你立刻开始开发吧!

你的 PM 不一定这麽快就结束,可能还会来回个 4、5 round

PM 的视角

但要再次声明,不是 PM 天生爱压榨人,所以才逼 RD 加班挤出来,而是因为 PM 负责将产品交付给客户,因此对於客户而言,PM 就相当於是这间公司的代表

若是晚一天交付,透露出这间公司不重视承诺
若是交付有瑕疵的产品,透露出这间公司没有品质把关

因此当我们也站在 PM 的视角去看这件事,一切就非常合理了,甚至 PM 是非常为公司着想的。

总之可以从上面的对话中看到,由於 PM 通常不会了解程序的细节,因此要预估出时程的话,当然就是 RD 的责任罗!如果 RD 没有坚守住立场,强行将时程「乐观化」,很容易就踏入「一坑补完再一坑,柳暗花明又一坑」的轮回中。

常见的「承诺系」辞汇

  • 今天主要执行 A 任务,希望下班前能完成
  • 嗯嗯你这个提议很不错欸,我们下次可以来做
  • 试试看

先声明,这个小节没有贬意,而是单纯要来点出真相(?)

是不是觉得上述的语句很常见?即便你没有说过,应该也看其它人说过。

希望、下次、试试看,这些辞汇不是不能用,只是呈现出来的 「肯定度」不高,相对地给人的信赖感就不会高

如果是在不那麽急的专案,PM 只是想大概了解一下 RD 没有在偷懒,这些说法都没什麽问题。

但如果是火在头上烧的那种专案,明天一早要上线,如果 PM 听 RD 说「希望下班前能完成」,你看 PM 会不会先跟你要电话号码XD

尤其,「试试看」这三个字特别容易出现在 RD 口中,原因也很单纯,因为程序的东西,常常不是想怎样就怎样的,如果夸下海口说「今天会完成」,到时候如果第三方服务断线,或者官方技术文件有缺漏,不就开天窗了!

真正的承诺

我将在 {某个时间} 之前,完成 {某个任务}。

看到这里很多人会想:「那麽厉害!? 啊如果第三方服务不给力,或者同事之前留下的隐藏 bug 炸开怎麽办?」

你觉得呢? (( 起码想一个答案再往下看吧!

如果你假日跟朋友约在公园见面,结果公车迟迟不来,你意识到「自己的承诺快要无法兑现了」...

你会怎麽做?

思考 3 秒

2 秒

1 秒

你可以有几种选择:

  • 付出金钱,改搭计程车
  • 询问住附近的朋友载你
  • 提早打电话跟你朋友说会迟到
  • 继续等待

因此,回到写程序的场景,如果跟 PM 说好的承诺快要无法兑现了,你可以怎麽做?

  • 付出时间,加班
  • 询问有空档的同事帮忙
  • 提早跟 PM 说
  • 继续埋头写程序

你会发现当承诺无法如期兑现时,是需要付出代价的,付出更多时间,或者欠同事人情,甚至挨一顿骂。

蛤?听起来太不划算了吧!那我一开始就说试试看就没那麽多问题啦!

承诺带来的好处

三个面向可以看:

如果从自己的观点出发,因为我承诺给 PM 了,我说什麽都要完成!会有更多动力从心底涌出,比较不会遇到一些障碍就放弃,也更容易激发自己,尝试各种方式来完成任务。

如果从 PM 或主管的角度出发,他们会看到这个 RD 是值得信赖的,说到做到的,即便可能有些任务没办法如期完成,起码是做过各种努力,并提前告知有心理准备的,未来有更重要的案子,才比较可能给这样的人。

如果从团队的角度出发,当团队中有一个人,每次预估时程的时候,都愿意宣告与承诺,久而久之,大家都会更看重时程的预估。

整体来说,愿意下承诺并落实的人,通常都是值得信赖的人

成为值得信赖的人不是免费的,但好处绝对是有的

结语

今天整篇下来有点长,所以总结一下:

  • 预估时程要基於「真相」,不乐观不悲观
  • 当你觉得快要跟 PM 吵起来了,请站在 PM 的视角来看事情
  • 「承诺系」的语汇保有更多弹性,但也少了信赖感
  • 承诺不是免费的,但好处绝对是有的

其实写完才发现,书中的东西其实讲得有点少,大部分变成我自己的经验谈XD" 所以如果可以,还是尽量去买书来看啦~

小小的烛火
在愈深的夜里
愈有力量

参考资料

The Clean Coder


<<:  Day28 实作todoList(三)新增事项到State

>>:  Day 28:合并排序法 Merge Sort

Proxmox VE 虚拟机防火墙管理 (二)

当我们已经开始使用防火墙规则管理连出入的网路传输时,随着制订规则数目越来越多,在管理上就会遇到开始...

sed - 5 Replace command

前篇回顾 sed - 简介 读取编辑文字档的好工具 sed - 2 Pattern sed - 3 ...

全域

全域变数 = 全域物件的属性 var deposit =500; //全域变数 console.lo...

Day19:Flow 准备好输出了吗?使用 Terminal operators 产生结果吧。

Flow 经过 Intermediate operators 将资料经过处理之後,最後一步则是要把资...

[Day12]加密方式

Hi~今天要介绍加密方式,如果有兴趣的话,就继续看下去吧! 在这个方面其实加密做得十分缜密!很多学...