TomWang的部落格

這文章我以前有寫過，但我想換一種方式描述，讓讀者能更清楚

當交易紀錄出現異常時，系統會對異常的交易紀錄產生對應的警報資料存到別的資料庫table。
有一個功能是要對發出警報的資料進行查詢，有一項查詢條件是合作廠商，原本合作廠商的輸入欄位是輸入文字，但使用者想改成下拉選單。
當時負責轉達與整理使用者需求的QA跟我說，下拉選單的選項數量會到9x個。使用者是傻的嗎？
我認為合作廠商的選項在未來還有增加的可能性，當事人似乎都沒想到這點，但這也不太重要，我想9x個跟幾百個大概差別也不太大了吧，都是太多了。
我後來直接詢問提出需求的使用者，我發現到「使用者想要的選項並不是全部的合作廠商，而是發出警報的資料中，有出現的合作廠商」

這功能如果要做成下拉選單，也只要出現「發出警報的資料中，有出現的合作廠商」就好，就我當時查資料的結果是:「目前情況只有出現4種合作廠商」。也就是下拉選單當時情況應該只要顯示4筆即可，也許未來這數量會增加，但這還是有別的解決方案可以處理，只是細節我這裡就不多說了。至少這個大方向就是只要給使用這看他想看的選項就好了。
我並不認為提需求的是傻的，因為對方是不懂技術與開發的使用者，我們可以說對方對功能畫面缺乏想像力，但不能說對方傻。這就像使用者不該怪技術人員不懂業務邏輯，因為又沒有人教。

至於這功能後來如何了呢？其實還是輸入文字查詢，因為使用最能滿足的需求的方式對開發來說負擔會比較大，管理者對開發者的評估也只是完成一個功能要多久時間而不是使用者對開發結果的滿意度，所以以一個開發者的角度來講，一定是選擇最容易的開發方式而不是最讓使用者滿足的開發方式。最讓使用者滿足的開發方式應該是使用者與窗口提出才對，既然他們提不出來，那就依照開發者的決定囉。

這件事情其實應該是要有一個系統分析師的角色去了解只要出現「發出警報的資料中，有出現的合作廠商」就好。只是公司就找了一個不懂甚麼是系統分析的QA來轉達與整理需求，我也曾經踢出過公司應該找系統分析師這樣的角色，只是我得到的回應是太貴了。如果公司不介意常常開發出不好用的功能，我也只能說那就隨公司喜歡的去做吧XD。

為什麼當初會想寫這文章呢?其實這是想留一個紀錄，因為我認為這是一個可以描述開發有系統分析師會比較好的範例。