文／Johnliutw

各位好，這篇文章想跟大家分享筆者在職場中，時常見到的一個溝通情境。

一般人: 安安工程師，我發現系統中這個表單好像少了 OO 欄位耶，可不可以加上去? 客戶會用到耶。
工程師: 咦咦，這個好像會動到資料庫喔，需要主管評估，但主管這陣子請假說…
一般人(心中): 什麼資料庫，我不太懂，但是就畫面上要多一個欄位，這麼簡單，為什麼還要等主管確認!?@?
一般人: 好吧…那我等你們主管回來再說…

假設你，就是文中所謂的『一般人』，是不是在和工程師的溝通過程中，會有個疑問，明明畫面上多放一個欄位，看起來像是很簡單操作的東西，也沒有所謂的數學公式，用 Google 表單可能甚至 1 分鐘內就完成了，但工程師卻都會面有難色的樣子。

其實工程師會有這樣的想法是很有原因的，這一切都跟軟體開發很重要的一個概念『資料庫』有關。在系統中，你看到所有呈現『有意義』『會動態改變』的資料，都會需要記錄在資料庫裡，而在上述溝通情境中，加在表單上的欄位，通常就需要記錄在資料庫裡。

而針對資料庫的任何變動，在系統開發的領域中，都是很重要的事情，所以在一些比較中大型的公司，做任何的修改變動都需樣工程師對這軟體有一定的熟悉度或能力，才有辦法決定，因此才會有些工程師只能表現很無奈啦！

而我們要怎麼判斷，自己想要提出的修改，是屬於這種，會調整到資料庫的需求呢？更延伸的來說，還會有什麼影響要先考量的呢？這裏來讓筆者介紹一下。

資料庫修改需求判斷分類

新增

新增欄位的判斷很簡單，就像上面提到的情境，就是所謂的新增欄位。
想要多加一張表單、想要表單裡多放幾個欄位、想要多在背景蒐集使用者是屬於手機或電腦的使用者，都可以算是新增的範疇

而新增要注意的點，其實不是『需求本身』要做什麼考量，而是要考量『完整性』的議題。
打個簡單的比方，可能我們網站需要開發優惠代碼功能，在結帳時提供一個框框讓使用者輸入優惠代碼。而可能一開始就這樣跟工程師說了，然後就新增好一個欄位，並放上網站看的到，並可以填寫代碼，但在測試過程，我們可能覺得不對，要再多要求使用者優惠代碼的『獲取管道』，或是確認是否是學生，要打勾『參與學生優惠方案』等等不同的資料判斷，這時對許多工程師來說的心中 OS: 每次都沒想好，然後又要改了，又要加欄位了。

這就是所謂的完整性，在軟體開發領域，比較偏好『完整』的需求，當然在這個變化多的時代，不是不能一直調整，而且我相信有許多人是在老闆或客戶的威壓下，得提出做修改，但如果是所謂應注意而未注意( 很像交通法規XD) 的調整，如果能提前先做出思考並規劃，是可以有效提升和工程師的關係喔～

移除

移除的情境在成熟的商業和軟體情境中，不是說很常遇到，移除比較常在一些更新快速的新網站、App 會看到，但可能我們心中會想: 移除也有問題？這不是應該比新增更簡單嗎？

但其實移除一個資料欄位在軟體思維中，很重要的概念是『連動性』，因為系統的邏輯設計要非常縝密，很有可能畫面中一個不起眼的欄位，會影響另外一個很重要功能的判斷，但卻沒有任何非工程師人員知曉( 甚至可能執行的工程師不曉得，導致移掉 B 卻壞掉 C )，因此如果需要移除一個欄位，最好要先評估思考，這個欄位『有沒有可能』在另外某個地方，被拿來做判斷，甚至先提問工程師，畢竟真的有什麼問題，相信身為使用者的大家也是很痛的。

編輯

編輯欄位的需求並不是很直覺的判斷，他可能需要一些對軟體的熟悉度比較好判斷，或是還是得工程師評估後才能知曉。但這邊筆者可以分享一種最常見的編輯修改調整，假設你的網頁上有像這樣子，可以打勾的方塊:

現在你想要改成，可以選擇的清單:

這其實就是會非常高機率撞到『編輯』欄位這個需求的可能，而這部分造成的改動通常都是大的，所以工程師面有難色的機率又會大幅提高 XD。而最好的解法，其實可以評估是否能將自己的需求調整成，將原本的框框移除，並新增一個欄位『狀態』，然後再提供一個下拉式選單，雖然在工程師實作細節上其實差異並不大，但可以變向指引工程師用調整幅度更不大的方式思考喔！

但在編輯欄位上，技術還是有很多不確定性和可行性，所以還是很有機會遇到和工程師溝通實做可行性的狀況，但相信讀完這篇文後，你可以更清楚工程師煩惱背後的原因囉 ^^

本文由 Johnliutw 授權轉載，原文連結

瀏覽 4,605 次