iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 11
0
Software Development

軟體開發隨筆談系列 第 11

暸解目的去實作,而不是暸解要去實作什麼

〈為程式碼變動做出解釋〉時,有引用了 fx777一句 的話,這句話再借我用一次:

工程師的工作是解決問題,其次才是寫程式。

是的,身為程式設計師的我們,應該是要解決問題,而不是當一個生產線上的製造工人,別人說要什麼,我們就給什麼。如果只會針對別人提出要什麼,並且寫程式把他實作出來,雖然偶爾的確解決的問題,但有時候卻會變成寫出來了,對方卻說這不是他要的,又開始提別的需求。這到底是為什麼呢?

因為有時候客戶(或是產品負責人、主管等)提的只是他想解決問題的做法,而不是他想解決什麼問題。然而他提出的做法,卻不一定真的能解決他的問題。所以比較好的作法應該是,透過客戶提的做法作為起始點,與客戶一起追朔到他是為了什麼目的而提出這個做法的,結合程式設計師的專業,是否有更好的做法或建議可以提供,讓彼此能夠直接接中要害,解決問題。

舉一個簡單的情境,在 UI 上,客戶可能會常常跟我們說,想要一個漢堡的選單按鈕(hamburger menu),背後隱含的可能是只想要 RWD 的設計,去解決跨裝置瀏覽的問題,但因為客戶對於網站設計這部分不懂,甚至不知道 RWD 的這個術語,所以才用片面的說詞、一部份的做法,去解決他想解決的問題。這時候我們就應該詢問他是不是想要讓網頁都可以跨裝置瀏覽,那除了漢堡外是不是有其他方案可以在現在的網站上解決這個問題。或是除了漢堡包外,我們是不是也應該增加那些需求。

身為一個專業程式設計師,除了透過程式編寫提供實作能力以外,也要能給予對這個領域知識不熟的客戶諮詢。承前述,有時候客戶甚至不清楚自己要的是什麼,而只是就對這領域的一隻半解,嘗試用他暸解的話語和我們溝通。我們這時候不該去嬉笑或是不耐對方的不理解或是錯誤的認知,畢竟這不是他們的領域,他們也努力地表達過了。相對的,我們應該要用他能理解的溝通方式,陪他們找出他們想解決的問題,協助將這些問題寫成需求,以及建議的實作方式。這樣才是最節省雙方的時間,而不是把珍貴的時間浪費在需求修修改改、做了又砍、砍了又做這種無意義的過程中

在完成一個可用的軟體之前,其實耗費最多的時間通常不是寫程式,而是在溝通。因為只要我們能把需求溝通明確,並且透過定期的展示確認問題有沒有被解決,實際實作的時間是不會有太多浪費的,而且也能獲得成就感。最怕的就是好不容易寫好的軟體,被客戶說不符合需求,導致胎死腹中,或是造成兩方爭執。因此,開發軟體時,身為程式設計師的我們應該要暸解目的去實作,而不是暸解要什麼去實作。


上一篇
程式碼風格要點在於一致,而不是優劣
下一篇
確認好要驗收項目與規格的滿足條件
系列文
軟體開發隨筆談31

1 則留言

1
csyo
iT邦新手 5 級 ‧ 2018-12-02 19:31:21

標題反而一直看不懂:「瞭解目的去實作,而不是瞭解要什麼去實作」,感覺語法怪怪的 XD

從文章大致上瞭解的意思是,不要只看到客戶表面的需求,而是以此去理解客戶真正想要解決的問題。

可以多闡述一下標題的這句話的意思嗎?

沒事了 XD 下一篇有提到正確的版本:「暸解目的去實作,而不是單純暸解要去實作什麼」

若虛 iT邦新手 5 級‧ 2018-12-03 10:19:02 檢舉

感謝指正,應該是在打字是游標錯位了。
校稿時竟然沒發現,果然漢字可以顛倒閱讀,哈哈。(掩面)

我要留言

立即登入留言