需求管理 (Requirement Management)


產品 / 專案進行中,經常會有 新功能需求,有時候是來自老闆的突發奇想、或者市場反饋、或內部發想。這些資訊的流通,在組織內部是很重要的,畢竟大家要了解『需求』的來龍去脈之後,才能設計出有意義的功能,打到重點,否則會有越來越多溝通成本,所以 需求管理 (Requirements Management) 我覺得是件非常重要的事情。

不過現實跟理想總是有差距的。

問題

專案進行到一段時間之後,很多功能往往到最後都為了做而做,但卻不知道為啥要做這個?我覺得 新需求 都要問以下問題:

  • Scenario 是什麼?Story 是啥?
  • 給誰用的? TA 是誰? (TA - Target Audience)
  • 如果你是行銷人員,廣告怎麼拍?有故事嗎?產品功能有亮點嗎?
  • 如果是技術的改變,那改善了什麼?如果跟社群分享,那要怎麼說?

User Story, Scenario, Use Case 差異請參閱:How to be an SQA?

實際上都是:反正先上了再說,快快快,Time to Market … 最後推疊出來的是一個不知所以然的怪物,這幾乎是每家公司的常態了。隨著時間越久,幾次人員異動之後,已經沒人知道當初為啥做那些事 … 更別提 TA

所以常見的問題就是:

  • 不知道做了哪些,無法從 Top-Down 看到整個局。
  • 為什麼做?
  • 需求彼此的關連性,特別是軟體系統本此的關聯性
  • 能動就上了,怎麼維護再說
  • 完成 100 個需求,每個需求時做了 2-5 個功能,所以共有 300 個功能,實際上有在用的只有 20 個

需求分析

需求有幾個面向是每次開會時都會討論的,而 開會的重點 在於尋求共識,根據 Priority 決定資源與時程。

實際上,需求經過討論後,一個需求討論過後可能要作 0..* 個事情 (Task),這些事情從軟體開發角度來看,會有

  • 全新的功能 (Feature):現在沒有的功能
  • 改善既有的 (Improvement):現在已經有的功能,但只要修改某一部份就可以了。

除了這兩個,其他要做的事情 (Task):包含測試、維運、UIUX 等事情,只要需要使用人力資源,都可以拆分,有哪些後面描述。

全新功能相對單純,比較沒有包袱,工程師可以快速開工、甚至導入新的技術與方法,後續的測試以及維運單位都要一起參加。

改善 (Improvement) 就要回去看以前的 Feature (這時候文件就很重要),然後改善的部分會不會影響既有的功能。Improvement 很需要測試團隊一起 Review 原始的需求考量,而且通常除了 功能測試 (Functional Test),回歸測試 (Regression Test) 是必要的。

測試的 Stage 詳細參閱:Stages in Software TestingHow to be an SQA?

Improvement 除了開發、測試團隊要進去,維運團隊也要進來,因為上了線之後可能已經改變既有的程序,要知道如何調整監控系統的程序,Log 蒐集程序、異常通報程序、異常處理程序演練、教育訓練、資訊安全 … 等。

如何監控自動化、通報程序調整等,請參閱:Study Notes - CloudWatch
系統維運相關課題,請參閱:AWS Certified SysOps Administrator - Associate 準備心得

所以,需求管理除了會看到兩個基本的 FeatureImprovement 實作的東西,這兩個東西就是大家對焦的東西,也是未來行銷單位會拿去做講故事的,以軟體開發來看,就是 Release Note 上會寫清單,像是新增了多少個新功能、改善多少、修了多少 Bug … 行銷可以針對 FeatureImprovement 做影片,講故事 …

Priority

每次 開會 都要決定需求的優先權 (Priority)。

實際上 Priority 會隨著公司的資源、市場的需求、執行上的問題 … 等各種因素的改變而改變。

而為什麼改變?理由是什麼?這些都要記下來,不然每次開會一堆人在哪邊想:為啥做這個?上次為啥說 schedule 要 delay?為啥現在 priority 變低了???

這些都要在每次開會時,用固定的 template 寫清楚,所有人都要看會議紀錄,嚴謹一點的都要在會議記錄上簽名,確認共識以及負責。

需求的來源

所有的需求背後都要有故事。

  • 市場:
    • 因為什麼樣的原因,如果可以怎樣,可以達成業績成長 n 倍
    • 改善怎樣的流程,可以提升效率,提升客戶滿意度
  • 老闆
    • 做出業績報表,讓老闆快速掌握狀況 …
  • 內部: 不管是研發、測試、業務、維運 … 單位
    • 因為 oo 技術可以節省成本多少,改善開發流程
    • 來自測試團隊的建議,通常測試團隊 Review Spec 的時候,就可以在當下給出很多建議,最後測試結束後,也可以提供很多想法。這部分在 協同合作系統建制與導入 - 以 Redmine 為例 有說明。

所有的需求,都會帶來新的問題,這些問題怎麼被發現?有辦法解決?跟需求衝突怎麼辦?

Breakdown 需求

一個需求進來,需要經過討論、分析、評估 … 等工作,這些過程都需要被記錄,而且要能夠追蹤管理,我歸納如下圖:

  • 紅色在 Redmine 裡我會建立獨立的 Tracker
  • 其他則都用 Task 代表

這樣做的目的是:

  • 紅色的是專案要聚焦的目的
  • 其他 Task 則是要老闆、PM 了解有哪些事要做,以及資源安排
  • 透過 Redmine ,可以讓所有人清楚專案的狀況。

詳細如何在 Redmine 呈現,會再慢慢整理成系列文章。

速度與品質

『快』的本質是建立在『品質』之上;一千張失焦的照片,不如一張對焦的;速彈是建立在每個清楚的音符演奏技巧。

關於吉他演奏訓練,請參閱我的另一個 Blog: 關於速度

台灣話說:『吃緊弄破碗』、中文又說『愈速則不達』,每個老闆都說快很重要,我也知道 Time to Market,但是往往這種『快』是沒有根據的。如果老闆眼光獨到,每次都很精準,那麼大家一起快我沒意見,但實際上就不是如此。

有一家公司,他的產品在市場上都不快,但往往都是後發制人,看清楚了才出擊,那家是 Microsoft … (雖然他也做了不少爛東西 XD)

商場上的競爭,往往是不成比例,小蝦米對大鯨魚是很常見的,所以如果有資源、有機會出擊,最好是一招斃命!不然就等著被吃掉。所以掌握著需求很重要。

延伸閱讀

參考資料


Comments