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

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

問題

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

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

• User Story, Scenario, Use Case 差異請參閱：Software QA 的職能條件

• Working Backwards 是 AWS 新產品的作業流程，先寫新聞稿 (Press Release)、FAQ、定義客戶體驗、寫使用手冊。概念上跟我的想法很像，都是從使用者出發。我的心得與實際作法參閱 一個人的 Working Backwards

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

所以常見的問題就是：

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

需求描述

需求一定有前因後果，每次溝通的時候，都要能夠讓所有人快速知道：

• 為什麼要做這件事情？
• 沒做會怎樣？做了又怎樣？有啥好處？
• 什麼東西跟這需求有關係？

確立這些之後，再來談技術性的問題才有意義。

底下是我建議的 Template:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

## 原因

* 因為 ooo, 所以 xxx
* 因為常常要 xxx, 造成人力空轉, 溝通成本

## 目標

* 達到 xxx, 帶來效益 ooo
* 達到 yyy, 帶來效益 rrr

<最好有數字、可量化、指標化>


## 預計工作項目

* 項目 A
* 項目 B
* 項目 C

需求分析

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

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

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

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

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

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

測試的 Stage 詳細參閱：淺談軟體測試的階段與策略、Software QA 的職能條件

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

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

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

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)

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

延伸閱讀

系列文章

• 概念篇：
  • 協同合作系統建制與導入 - 以 Redmine 為例
  • Issue Tracking in Redmine
  • 寫在介紹 Redmine 之前
  • 需求管理 (Requirement Management)
  • Software Development Lifecycle
• 系統篇：
  • Redmine 安裝篇：Redmine 4.0.x on Ubuntu 16.04
  • 系統整合：Integrate GIT in Redmine
  • 如何透過 Email 建立 Issue
  • 系統整合：Redmine Plugins and Themes

站內延伸

• 寫在介紹 Redmine 之前
• 開會的原則
• 溝通成本
• 為什麼寫文件？
• Software QA 的職能條件
• 淺談軟體測試的階段與策略
• Study Notes - CloudWatch
• AWS Certified SysOps Administrator - Associate 準備心得
• 一個人的 Working Backwards

參考資料

• Requirements Management, 中文
• Working Backwards