但在很多情況下，需求是否有足夠細化清晰並沒有一些容易量化或量度的標準，而且亦因人而異，各個團隊都不同。很常見的情況是用戶部門一直說需求已經很清晰，或者「這個需求就是如此簡單」，但IT團隊卻一直未能動工，指需要更細化的需求，這導致項目中出現很多的爭拗。項目經理需要有能力判斷需求是否有足夠的細化，當中包括提出合適的問題，引導團隊內的用戶和IT人員進行更深入討論，亦需要不偏不倚，一切以推進項目作最終目標，從而定義出合適團隊的細化度。
不過以上的情況也是在一些已經相對上互相合作的團隊內發生，而且團隊也有相當項目經驗。在實際環境中我們更常會遇到的情況，是我們發現很多參與項目的人是從根本上分不清「需求」、「目標」和「口號」的，這也就是今日的題目。
在過去數週的篇章，闡述了系統需求是怎麼一回事。首先，系統需求也是開發的一部份，包括定義系統需要的元素、邏輯、流程，以至於UI、報表等最終呈現的模式。另外，系統需求描述了項目的期望結果，讓用戶與IT團隊在初期就期望結果達成一致而開發落實。理想的系統需求通常能夠很容易計算開發量，亦能夠按需求制定測試計劃，進行驗收。
不過在實際情況，有很多人把「需求」寫得過份簡單，或誤把項目的「目標」當成了「需求」，造成很多我們所謂一句說話就講完的需求，例子有：「系統需要就業務紀錄提供報表」，或例如：「系統在出現問題時需要有通報機制」，甚至乎「我們要做一個跟XXX很相似的平台」，開發人員對這些所謂「需求」的理解，從而作出開發量及項目的預算，就可以跟用戶相差甚遠。
例如就業務提出報表，就可以有很多問題。報表內容是什麼？需要有多少份報表？按什麼維度畫分？最終用戶是誰？多久出一次報表？又例如通報機制。什麼的問題需要通報？通報誰？即時通報還是歸總翌日通報？透過甚麼途徑？通報後的處理是怎樣？這些都是在定義需求時需要考慮，而不是在開發甚至測試時才討論。
而至於「我們要做一個跟XXX很相似的平台」，例如我們要做一個流程平台，或者報表平台。作為項目經理，應該都很常聽到「我們要搭建一個新平台，功能要與舊的一樣」這樣的需求吧。在這種情況下，即使我們是希望以別家平台作為藍本，我們也要將別家平台上的功能元素羅列出來，逐點深化討論具體需求，才能夠更準確地確保大家所想的開發範圍一致，合理評估開發量及項目時間。否則的話，這種「需求」就跟「目標」無異，制成品跟期望可以有很大落差。
我們可以嘗試在生活中訓練一下自己思考系統需求的能力，例如「建一個Instagram App有甚麼功能元素？」，很多時我們會只能列出在自己看到的介面上的功能，例如可以upload 相出post，可以follow 別人，比心心、comment、forward、bookmark 等等。深入一點也會看得出user profile setting、privacy setting、notification 等功能。但其實隱藏在後面的還有大量我們未知的功能，例如演算法、post relevancy。如果以為建起介面就等於建起整個平台，這樣作出的估算可以與實際出現極大距離，項目失敗的風險將是極高。
再舉一個例子，在現時疫情下，很多公司也研究在家工作的方案，並評估相關風險，例如customer data leakage。這類型的項目需求似乎可以一句說完，例如「提供notebook讓同事能在家連結到公司網絡工作」，但其實「工作」本身就可以牽涉很多不同種類。收發電郵是一種類型，需要登入業務系統是另一種類型，有些開發人員則只需要登入開發/測試環境，各種類型就可以牽涉不同的安全需求，以致不同的實施方案。
經常聽有些用戶會說，「我已經提出了需求，接下來的工作就是IT去想怎麼實現」，其實這是很不負責任的，尤其是需求就只一句說話。項目的落實方案本身是需要項目團隊一齊決定，不同的實施方案，牽涉不同的風險，更重要是如果項目的範圍牽涉到其它地方的影響，項目團隊就更有責任去評估並作出相應的對策，這些都絕不能是一句「我已經提出需求」就完事的，更何況開發完成後就到測試階段，沒有具體的需求和實施方案，又試問怎樣安排驗收測試呢？
不過在現實中，太多人只談「目標」，太少人參與深化「需求」，漸漸地「目標」甚至發展成一些「口號」，例如「我們要自動化」，「我們要簡化公司的流程」，或者「我們要建立方便同事使用的軟件平台」等。這些「口號」說出來當然大家也是支持的，但如果機構內出現太多這種只有空談沒有落地的團隊，就可以看出機構內部營運正處於危險的境地。大家若是希望機構能作出一些實則改變，就會明白只談「口號」是沒有意義的，更重要是大家要在自己的崗位/domain上參與制定方案的過程，評估方案的優缺點，細化需求，這樣做才可以提高項目成功的機會。
不過在實際情況，有很多人把「需求」寫得過份簡單，或誤把項目的「目標」當成了「需求」，造成很多我們所謂一句說話就講完的需求，例子有：「系統需要就業務紀錄提供報表」，或例如：「系統在出現問題時需要有通報機制」，甚至乎「我們要做一個跟XXX很相似的平台」，開發人員對這些所謂「需求」的理解，從而作出開發量及項目的預算，就可以跟用戶相差甚遠。
例如就業務提出報表，就可以有很多問題。報表內容是什麼？需要有多少份報表？按什麼維度畫分？最終用戶是誰？多久出一次報表？又例如通報機制。什麼的問題需要通報？通報誰？即時通報還是歸總翌日通報？透過甚麼途徑？通報後的處理是怎樣？這些都是在定義需求時需要考慮，而不是在開發甚至測試時才討論。
而至於「我們要做一個跟XXX很相似的平台」，例如我們要做一個流程平台，或者報表平台。作為項目經理，應該都很常聽到「我們要搭建一個新平台，功能要與舊的一樣」這樣的需求吧。在這種情況下，即使我們是希望以別家平台作為藍本，我們也要將別家平台上的功能元素羅列出來，逐點深化討論具體需求，才能夠更準確地確保大家所想的開發範圍一致，合理評估開發量及項目時間。否則的話，這種「需求」就跟「目標」無異，制成品跟期望可以有很大落差。
我們可以嘗試在生活中訓練一下自己思考系統需求的能力，例如「建一個Instagram App有甚麼功能元素？」，很多時我們會只能列出在自己看到的介面上的功能，例如可以upload 相出post，可以follow 別人，比心心、comment、forward、bookmark 等等。深入一點也會看得出user profile setting、privacy setting、notification 等功能。但其實隱藏在後面的還有大量我們未知的功能，例如演算法、post relevancy。如果以為建起介面就等於建起整個平台，這樣作出的估算可以與實際出現極大距離，項目失敗的風險將是極高。
再舉一個例子，在現時疫情下，很多公司也研究在家工作的方案，並評估相關風險，例如customer data leakage。這類型的項目需求似乎可以一句說完，例如「提供notebook讓同事能在家連結到公司網絡工作」，但其實「工作」本身就可以牽涉很多不同種類。收發電郵是一種類型，需要登入業務系統是另一種類型，有些開發人員則只需要登入開發/測試環境，各種類型就可以牽涉不同的安全需求，以致不同的實施方案。
經常聽有些用戶會說，「我已經提出了需求，接下來的工作就是IT去想怎麼實現」，其實這是很不負責任的，尤其是需求就只一句說話。項目的落實方案本身是需要項目團隊一齊決定，不同的實施方案，牽涉不同的風險，更重要是如果項目的範圍牽涉到其它地方的影響，項目團隊就更有責任去評估並作出相應的對策，這些都絕不能是一句「我已經提出需求」就完事的，更何況開發完成後就到測試階段，沒有具體的需求和實施方案，又試問怎樣安排驗收測試呢？
不過在現實中，太多人只談「目標」，太少人參與深化「需求」，漸漸地「目標」甚至發展成一些「口號」，例如「我們要自動化」，「我們要簡化公司的流程」，或者「我們要建立方便同事使用的軟件平台」等。這些「口號」說出來當然大家也是支持的，但如果機構內出現太多這種只有空談沒有落地的團隊，就可以看出機構內部營運正處於危險的境地。大家若是希望機構能作出一些實則改變，就會明白只談「口號」是沒有意義的，更重要是大家要在自己的崗位/domain上參與制定方案的過程，評估方案的優缺點，細化需求，這樣做才可以提高項目成功的機會。
本篇現已在Medium提供英文版本，有興趣的可按此觀看。
沒有留言:
發佈留言