我們用 SMART——Specific(具體)、Measurable(可衡量)、Achievable(可達成)、Relevant(具關聯)、Time-bound(有時限)——把每個故事拆成五天,作為每次動手造輪子前的五個檢查問題。
本篇是回顧總結的「回顧」篇:五個故事背後,各自是哪一種造輪起手式,錯位又發生在哪一層?
本篇定位:回顧前面五個故事,整理它們背後不同的失控模式。
最後那個故事的結論是:怕客戶不會用輪子,結果先替他做了一台沒人保固、沒有說明書、也不知道誰維修的車。於是我把五次的結論寫在同一頁上,一條一條重看了一遍。
五個故事橫跨韌體、硬體選型、介面設計、協定整合與客戶支援,登場的技術名詞沒有一個重複,攤開來卻像同一個人在五個現場輪流犯同一種病。而且我必須誠實:那個人常常包括我。更難堪的是,五個現場裡沒有一個人在敷衍——每個人都在查規範、畫圖、寫程式,非常認真地,解一個沒有人提出過的問題。
所以這次回顧不打算再說一次「他們錯了」。把五張收尾排在一起,新資訊其實只有一件:它們錯的位置不在同一層,付帳的也不是同一個人。
把五個收尾翻回工程語言,五種起手式各自有名字,也各自有一個錯位發生的位置,與一位收到帳單的人。
差異列到這裡就結束了,剩下的全是共同點,而共同點只有一句:開場白。沒有任何一個故事的第一句話是「我想浪費三個月」,每一個的第一句話都是某種版本的「這樣做我比較有把握」。不熟悉、不安心、不夠漂亮,在會議室裡都不好意思直說,於是被翻譯成技術語言:「這程式要先整理」「這條線規格沒問題」「應用端不該碰暫存器」「底層比較單純」「客戶一定看不懂文件」。每一句都披著工程判斷的外衣,共同點是沒有一句出示過證據。
公道話要先說在前面:這幾個技術都不是被告。AT Command 在跨裝置整合是成熟做法,V4L2 在本機擷取是正確工具,範例 App 在有明確邊界與支援聲明時是好交付,CMSIS 與倉庫裡的既有零件也各有站得住的位置。這次回顧要追究的是它們被叫上場的理由。
把五種模式讀成五種人格缺陷,前面那些故事就只剩五場公開處刑;把診斷對象從人換成決策,它們才變得可以治療——因為每一種模式,都擋不住一個當時沒有人問出口的具體問題。這五個問題,我叫它們五把證據問句:
五把問句有同一個性質:它們都不徵求意見,只徵求證據。這就是解方的核心——用證據取代熟悉感。注意,不是消滅熟悉感。熟悉感是有用的訊號,它誠實地標示出「我不懂」「我不安」「這裡有風險」的位置;要改的只有一件事:熟悉感可以提名方案,但不能簽核方案。提名之後,得拿驗收表、實測結果、使用者的實際卡點來定案。
手擀破輪子的起點,通常不是「我要浪費時間」,而是「這樣做我比較有把握」。想通這一點之後,我沒辦法再把五個故事當成別人的笑話——對把握感的需求人人都有,我只是剛好在五個現場都扮演過那個跟著點頭的人。要練的也就不再是識破別人,而是在自己伸手拿擀麵棍之前,認出那股熟悉感,然後要求它出示證據。
不過,認出模式只是診斷,離治療還有距離。當證據真的顯示現有方案有缺口時,下一步是什麼?「用現成的」和「自己做」之間其實隔著好幾級樓梯,大部分的破輪子都是跳級摔出來的。那座樓梯有幾級、每往下一級要多付什麼,是接下來得先排清楚的事。