技術管理閒聊:刻舟求劍的解問題方法
在軟體開發這個領域作久了,相信一定有遇過以下的狀況:某個同事來問你能不能作到某個功能(或者要花多久時間作),你一看覺得很簡單,於是就幫他做了,結果後來發現這個功能根本沒有被使用,回去一問,才知道他想要解決的問題跟這個功能無關。
這真的是件很浪費時間又沒有成就感的事情。
後來讀到一篇文章,發現這個狀況全世界的軟體開發都一樣,天天發生。通常都是需求單位過早下結論,認為用某個「特定的方法」可以解決問題,但可能這個方法其實不是最佳解,若軟體工程師沒有多問「為什麼」,最後才發現,就會走很多彎路,浪費很多時間。
這就跟刻舟求劍是一樣的。刻舟求劍是《呂氏春秋·察今》中記述的一則寓言,說的是春秋時代,楚國有人坐船渡河時,不慎把劍掉入河中。結果他在舟上刻下記號,說:「這是我把劍掉下的地方。」當然最後在刻下記號的地方是找不到劍的。在船上刻下記號,就好像需求單位提出的功能一樣,如果工程師照著刻,最後當然解決不了問題。
問題背後的問題
那麼,要怎麼解決這個狀況呢?在 John G. Miller 的書《QBQ:問題背後的問題》中提到,藉由提出更好的問題,來做出更好的決定。也就是說,工程師不是單純的接收需求者,而是透過提出問題,釐清需求單位實際想解決的是什麼(以及背後的原因),來討論出有效的解決方案,把問題正確的解決。
舉例來說:
需求方:我想要在 PHP 中取得檔名的最後三個字母
A1:substr($filename, -3)
A2:你想達成的效果是什麼?
需求方:我想知道檔案的副檔名
A1:list(, $ext) = explode(“.”, $filename)
A2:你取得副檔名想要怎麼利用?
需求方:我想知道檔案的類型,如果是圖片檔案的話才讓程式繼續執行
A(更好的解答):你可以查一下mime_content_type()
的用法
從上面的例子可以知道,越簡單的需求,要解決的問題或是後續的利用方式,都不是表面上說的那麼簡單。無論是寫需求的人,或是讀需求的工程師,都需要把原始的需求搞清楚,寫明白,才不會讓團隊落入刻舟求劍的境地。
問「為什麼」的團隊
因此,若軟體開發團隊在問「目標是什麼」,我認為這並不是要質疑需求,而是在釐清需要什麼樣的解決方案才能有效的幫助團隊達成目標。這也是一種以終為始的工作方法。
釐清目標之後,團隊可以根據目標找出最適合的解決方案,而不是錯把手段當成目的,最後在這個手段上投入了很多時間和成本,最後造成大量的浪費,團隊的士氣也因此低落。而為了鼓勵團隊多問「為什麼」,就需要在團隊內提升大家發言的風氣,就算一開始是質疑1,可能會讓團隊領導人覺得不開心,但這樣會比團隊都不提出問題然後大家一路往錯誤的方向走到底好。
我會鼓勵團隊多講的幾句話:
我們現在的目標是什麼?
我們應該如何達成這個目標?
這個方式是最有效率且風險最低的嗎?
以「什麼」或「該如何」這兩個詞來發問,把焦點放在「我們」與「行動」上,工作起來會更開心,也會更有成就感。
接下來,固定每週一會推出一篇文章,如果你對技術管理也有興趣,歡迎按下面的按鈕來訂閱電子報喔!
如果你有興趣跟我聊聊關於技術管理,也歡迎到 calendly 跟我約個時間聊聊!
如何把質疑的語氣轉換成討論或建議,在許多談說話方式的課程有教,後續也會找機會跟大家分享我常用的幾個方法。