為什麼軟體團隊需要制定工作流程?「專案啟動」時可以做這3步驟! |專家論點【林鼎淵】

圖片來源:unsplash

在流程不明確的狀態下,團隊成員只能憑藉自己的直覺做事;如果彼此對一件事的認知不同就容易造成誤會,甚至爆發不必要的衝突。

以筆者過去的工作經驗來說,如果工作流程只靠口頭制定、團隊默契,在沒有明確的文字規範下,大家真的無所適從,當新人加入時還需要更長的磨合期。

而制定團隊的工作流程,能夠讓成員了解自己在各階段要負責的任務;儘管一開始的工作流程可能很粗糙,但只要有了第一版,流程就能在日後的實踐中不斷優化與完善。

由於「為什麼軟體團隊需要制定工作流程」這個議題的涵蓋範圍較廣,所以筆者會拆分成「專案啟動、初始任務專案執行」等幾個主題進行分享,今天這篇文章先介紹「專案啟動」時要做的事。

內文以「Web 開發」為範例,不同行業請酌情參考。

▋STEP 1:需求訪談&初步規劃

這個階段的目標是「初步確認需求、討論需求可行性、讓客戶認可 Wireframe 流程」。

  1. 由「PM」與客戶討論需求,在收集完需求後,將其以心智圖(Mind Map)的方式呈現。
  2. 接著請「UI/UX」依造需求設計 Wireframe。
  3. 待 Wireframe 完成後,「Tech Lead、PM、UI/UX」一起開個會,初步確認流程以及功能的可行性,並討論是否有需要調整的部分。

有些客戶會提出一些會異想天開 or 奇怪的需求,如果在初步規劃就發現這些問題,在反駁的同時請給予對應的建議,比如:

  • 我想要一頁顯示 1000 筆資料方便搜尋:有些人還是習慣用「眼睛」來搜尋,但這樣的效率極差,當資料量大的時候還要翻頁;筆者建議與客戶進一步討論他實務上會搜尋的「欄位」有哪些,也許「篩選」功能更符合期待。
  • 我想要把過去一年的出貨訂單匯出至 Excel 來統計數據:客戶過去可能習慣用 Excel 函數來分析數據,但這個功能實際上可以做成系統的「儀表板」。

▋STEP 2:確認具體需求&完善規劃

這個階段要將「原本模糊的規格具體化、完成 Prototype 設計」。

  1. 在客戶確認完需求及Wireframe 的內容都沒問題後,請「UI/UX」開始設計 Mockup。
  2. 由「Tech Lead」確認 Mockup 上的細節是否都有考慮到(ex:哪些欄位適合拿來搜尋、不同權限看到的畫面、有哪些元件可以設計為共用模組)。
  3. 待 Mockup 上的功能&流程都確認沒問題後,請「UI/UX」開始設計 Prototype。

血淚史提醒
專案初始的設計盡量從 Wireframe 開始,就算專案規模較小也不要直接畫 Mockup;因為在前期客戶的需求會時常變動,就算突然加大投資,小專案變成大專案也是很常見的,若使用 Mockup 會需要花更多的時間在調整上面。

▋STEP 3:向團隊成員說明

在需求與流程相對穩定後,接下來就要與「團隊成員同步資訊」。

  1. 由「PM」向團隊成員說明系統的功能與流程,確保大家理解這個專案要完成的目標(這邊建議先用心智圖說明架構,再用 Prototype 模擬實際流程)。
  2. 由「Tech Lead」向工程師團隊提醒各功能在設計上要注意的細節(ex:哪些欄位要設計 Auto-Complete、是否有特別的 Validation Rules、某些功能需要提前 Survey 避免卡關)。

這個階段主要是讓團隊成員對每個 Feature 都有具體認知,然後評估自己感興趣 or 擅長的 Feaure,若發現有沒碰過的技術也能提前研究。

▋小結

專案啟動時,「Tech Lead、PM、UI/UX」在各階段都要做好把關。

相信有實務經驗的讀者,都很清楚「明確的需求、具體的流程」對工程師來說有多麼重要;如果一切都非常模糊,那後續開發一定會遇到各式各樣的問題。

在團隊成員都了解專案的目標後,為了保證後續開發順利,我們還有一些「初始任務」要做,這部分筆者會在下一篇文章與大家分享。


☛ 如果想更深入認識我,可以 Follow 筆者的技術部落格 。
☛ 如果對工程師的職涯感到迷茫,筆者最近出版的新書 也許能給你帶來不同的觀點。

瀏覽 2,816 次

覺得不錯的話就分享出去吧!

發佈留言

Back to top button