今天剛好跟同事聊到處理需求跟專案的部份，想說就貼之前收藏的這篇上來：
接到一個模糊的需求時，該怎麼處理？ - Evonne Tsai

雖然這篇文章開場是站在 PM 的角度出發，但我覺得在評估目標的部份，以及面對模糊需求的步驟等等，對我等 CRUD 工程師還是很有參考價值。

作者將接到需求之後要進行的項目分成兩個階段，各三個步驟：

  • 分析與探索階段
    • Step 1: 確認提出這個需求的目的或背後動機
    • Step 2: 確認事實與現況
    • Step 3: 清楚的目標以及衡量指標
  • 執行階段
    • Step 4: 找出各種解法
    • Step 5: 排定優先順序和「組合技」
    • Step 6: 制訂與執行專案管理計畫

以上的每個步驟都有更細的說明，例如 Step 3，要訂下具體的目標時就可以使用「SMART 原則」。這邊就不附上，有興趣的朋友可以再進內文看看。

我在看這篇的時候有點小反省：當遇到一個需求，我很常直接跳到 Step 4 開始想各種實作方案，而忽略了前面的分析與探索

但在某些時候，可能這個需求根本不能解決原本的問題（有點像 X-Y 問題 ），又或是我們根本沒想清楚要達成怎樣的效益、怎麼樣評估結果是有效的，掄起槌子就要開幹，然後才發現：啊！我們根本沒搞清楚！就浪費了一堆時間，設計可能也要變來變去

其實我發現，越是會解決問題的人，越會花很多時間在釐清「阿現在到底是發生了什麼事？」「大家眼中的問題到底長怎麼樣？」

而越是菜鳥，越是會直接接受問題以及假設，甚至接受非事實的「他人觀點」（例如顧客說產品太貴就回頭爭取折扣），埋首去解決問題、使命必達，卻不知在瞎忙什麼。

希望自己之後也能先冷靜下來好好分析狀況，共勉之。

那麼，今天的轉貼就到這裡，明天見～