資源總是不足，如何推動數字化轉型？

面對數字化的浪潮，不少企業都重新思考自身定位，進行不同程度的數字化轉型。

不過，不少機構在決定推動數字化轉型的過程，都會有力不從心的感覺。看着同業同行成功地透過數字化轉型帶來業務上的突破，客戶對企業品牌更有黏性，內部員工也對工作更加上心，更令一些仍然落後的機構焦慮，如何收窄與領先同業的差距。

很多機構在遇到這種情況，都會歸咎於自身資源不足。無疑，數字化的過程需要能帶動轉型的前瞻性人員，另一方面轉型所帶來的一系列改動和項目，客觀上也需要資源執行落實。

不過，當我們經常說資源不足，卻很少能說得出多少資源才算足夠。甚至乎，有些機構對於現有資源的安排分配，以至各項投入資源所實現的價值，都難以明確表達。如果連回顧過去的能力也未有，實在難以談得上規劃未來。

早前閱讀了《EDGE：價值驅動的數字化轉型》一書，深深受到書中概念的啟發。數字化轉型的核心並不單單是資源問題，更多是思維模式的改變。本篇是看完之後對數字化轉型的一些個人看法，未必完全正確，寫出來分享一下，也歡迎留言交流。

第一，數字化轉型着重向內求變。

當談到數字化轉型時，很多機構和團隊第一時間想起的都是一些新技術平台，由人工智能到大數據，又或是金融業會提到區塊鏈，好像是只要外購引入這些平台，就等於是數字化了。

這種思維模式，就跟以前說數字化等於做一個手機APP，或者引入數據倉庫，都是片面而且膚淺的。而且用這種思維，某程度上是在轉型上加上了一個外在前設，即要先有這個平台，才可帶來改變，不符合數字化轉型的本質。

個人認為，數字化轉型更着重的是機構內部的改變，例如是自身現有的管理流程，有多少已通過系統方式實現業務邏輯判斷的自動化，多少仍然停留為紙張傳遞流程；又例如在決策過程，是否用數據來說法，又有多少數據是已收集、可獲取或可分析。

了解願景和當前實際情況的差距，訂立目標，對齊業務和技術，然後一步一步實現，把重心放在自身可執行的戰略而非外部依賴，並評估需要其它部門的配合，都是數字化轉型所着重的思維。

第二，數字化轉型是持續進行的。

很多時，在機構執行數字化轉型的過程中，都會有意無意的把數字化轉型看成一獨立項目，尤其是當要用到外部咨詢服務來推動轉型，就更容易會把轉型定性為項目，訂立目標、項目範圍、時間表、咨詢費用等。

但是，要推動內生而持久的數字化轉型，我們是不能把轉型看成一單獨項目進行，更不能把轉型項目組看成一獨立團隊的。

需知道，數字化轉型是一個持續的過程，它當然會有一個主幹的計劃和方向，但就未必會像傳統項目一般有具體限定的範圍和完成日期。

如果要做一個形象化的比喻的話，我們可以想像把一件物件由一處移到另一處。傳統項目的方式就像是搬動磚塊，磚塊移到新一處後就會靜止，就像項目是由一種靜態轉變為另一種靜態。

數字化轉型則應該想像成推動飛輪 (flywheel) 轉動，推動飛輪起動可能會很花力氣，但滾動的過程會儲能，到原計劃的地點後，還會帶着轉動能繼續向前。

第三，數字化轉型要宣揚選擇的美德

讓我們重新回到前面所提關於資源不足的問題。

事實上，不論是否數字化轉型，任何企業都會遇到有太多計劃想做，而又沒有足夠資源的情況，我們實際上應該關注的並不是資源多少才算充足，而是應該關注如何利用現有資源，集中投放在最有價值的領域上面。

例如，我們應該關注的是，客戶想要什麼，我們的能力又可以做什麼，做哪些事可以最大化地創造價值。客戶的需求是多方面的，而我們當前的能力會限制了自身能提供的服務，故我們需要考慮，應作出哪些投資才可有效提升能力，更好的配對客戶需求。

《EDGE》一書中，特別強調了投資組合的管理。對於擁有多個業務領域，多條線發展的企業，更應關注如何整體管理分配各個業務領域的投資，強調要進行選擇並且集中資源，而非要求多點併發，方方面面都想達到。

不過，當去到要進行全局化評估，或者需要到要進行選擇時，過程通常都是艱辛的，而且通常結果都是絕大部份項目都難以放棄，最後花了很大力氣都沒法達成共釋。

《EDGE》一書強調了項目按價值排序的必要性。一方面整體資源能夠劃分成各個業務領域並進行分配，另方面各個領域的團隊亦可在獲分配的資源（不論多少）內，訂出自身統一的價值目標，並按項目產出價值來規劃資源投放和項目排序。同時，定期進行價值回檢，合理修正團隊內資源的安排和整體的分配，都可有助對齊業務重心和資源投放。

到最後，能夠產生出多少價值，當然還是與資源投放的幅度相關，但可以相信的是，無論資源多少，企業都一定能夠集中資源投放在最有價值的地方上，並且持續提升分配的準確性。

認真處理流程制度「管生不管養」問題

生活上，我們總會預到過使用一些服務時，結果不如理想，想去反映意見，但提出後不是杳無音訊，就是意見接受，態度照舊。

負責運營的人，很多時喜歡用「既定流程」來做標準答案，錯誤的是流程，我們只是跟隨流程指示去辦，故出現事故的責任不在我。但當要問到「既定流程」是由誰來定，則只會找出很多的參與人，卻沒有主事人。

換個角度，在機構內部的運營裏，有時也會出現有法不依，有法不循的狀況。流程制度確是寫下來了，但沒有執行辦法，負責編制流程制度的部門也不會定期檢視流程是否有落實到位，甚至有些流程慢慢變成無主孤兒，竟然不清楚流程的最終責任人。

有些流程則是有清晰責任人的，但就從沒有照顧前線人員使用的習慣或操作時遇到什麼困難，也不提供途徑供前線反饋意見，任由流程走樣或失去效率。

以上列舉的種種情況，都可以歸納為流程制度「管生不管養」的問題。

我們這一代，可說是出生於後工業時代的。在我們出世的時候，社會已經建立起各式各樣的流程和制度，有些建立得比較新，有些則比較久遠，三四十年前甚至更早的也有。

對比起現在，工業時代的一個特點，是社會經濟相對穩定，資訊也相對不流通，各行各業可透過掌握梳理業務的重點，實施一次性的流程建造後，較長時間內毋須經常改變，或只需要少修少補。

不過，長期沒有大規模重檢改造的流程，也存在不少問題。

最常見的問題，是隨着年月，流程的框架和步驟是流傳了下來，但背後的精神和假設則沒有，後人只知道要跟隨「既定流程」，卻不知道當初流程如此設計的原因。

更甚者，是隨着一代又一代人退休後，流程變成無主孤兒，後人即使想改變，也很多時礙於風險不可控而難以着手。不過隨着數字化浪潮的來臨，也為治理流程「管生不管養」的問題帶來了契機。

正在經歷數字化轉型的機構應該能明白，流程數字化絕不單單是指流程電子化或無紙化，而是一次徹底的思維模式和流程制度的重塑。

透過這種規模的改造，不單可以達到破舊立新的效果，更重要是過程中可以重新思考流程制度背後的原因，重新定義流程的架構、重點，並且在核心嵌入產品長遠發展和持續迭代優化的思維，保證流程長青。

在這個過程當中，重新梳理現有流程的主責部門是必不可少，而且亦需要有責任到人的基本共識，不得容許互相推諉。過往隨心而行的業務邏輯，亦應透過系統固化，減低業務操作過程的隨機性。

更重要的當然是本欄一直強調的產品思維，根本性地從用戶角度出發，清晰定位流程存在的目的意義，解決什麼問題，在構建制度之餘保持能夠持續改造，避免再產生新一代的legacy，遭後人唾罵。

管理「等、靠、要」思維

很久以前曾經在Medium上寫了一篇文章，講述一些項目經理如何巧妙地為項目加入自身不能控制的外部依賴關係，將項目不能如期完成的責任推諉得無影無縱。

後來在產品思維的文章亦提過，產品思維着重建立自充足 (self-sufficient) 的團隊，目的就是要讓業務發展上預到的問題能盡可能在團隊內解決。而「等、靠、要」的思維，故意及非故意地為產品設下外在依賴，絕對是不符產品思維的。

要理解「等、靠、要」思維是如何為產品加入外在依賴，我們需要先理解這種思維是如何運作。具體而言，機構內的「等、靠、要」思維可分為三個層級。

第一個層級是「向上等」。等上級指示、等分配資源，或等安排預算，這些幾乎是一般傳統機構內，經常都會出現的表述。

談到要做項目，未有上級指示前按兵不動，項目起動之後也是點到即止，或是把項目無限拆分，然後只完成第一階段。一旦預到資源不足或其它任何問題，統統向上匯報請示，等待上級決策或等下一步安排。

這種思維，政府部門非常普遍，大型機構內也是極之盛行，統統可歸類為「向上等」。

第二個層級是「向左右靠」。無論被指派什麼任務，第一時間提出需要依靠旁邊其它部門支持，合規也好，技術也好，人力資源也好，總之就是「群策群力」。

「向左右靠」思維，是無論面對什麼事情，首先要讓事情看起來不能單獨以自身團隊能力內部完成，制定任何計劃也要加入外部依賴關係，其完美表現，甚至是把外部依賴視為前設 (pre-requisite)，變相讓自身負責部份處於不能啟動的狀態。

如此下來，無論項目一整年也沒有啟動，或啟動了的項目一旦出現任何延誤，統統可歸類為外部不能控制的範圍，自身則不負起責任。

第三個層級是「向下要」。要求下級更加努力的工作，要求下級自行解決問題，甚至要下級一人分飾多角，承擔起更多責任，都是「向下要」的常見例子。

另外，「向下要」也表現在上級下達的任務，直接向下級傳達或分配，亦是自身完全不負起責任，也不向下級解釋任務的目標和願景。

「向下要」的完美示範，是就算問題在下層已無法有效解決，亦不會提供途徑讓問題向上提級處理，任由問題陷入無法解決的局面。

整體而言，「等、靠、要」的思維，都是導致機構內血液難以暢通運行的重大阻力。凡事都要等一會，凡事都要拉多幾個部門一齊參與，或重大問題也不準上報，不單是拖慢決策，更是讓項目寸步難行，絕對是機構需要正視處理的問題。

不過，「等、靠、要」思維之所以在機構內特別盛行，也是與人的天性有關，特別是與個別一些「拖延症候群」有關。要管理這種「等、靠、要」思維，有幾個方向是機構可以着手的。

第一是定期檢視內部管理流程的制定機制，或檢視部門架構和職能，務必讓跨部門協作的複雜性減至最低，以自充足的產品團隊為目標，減少相互依賴。

很多時，流程都是在機構的營運過程中逐步建立起來的，並且在不知不覺間構築得愈來愈複雜，日常工作中也會逐漸適應，即使是績效低下，也難以發現問題或作出改善。故此，定期的檢視，可有助活血化瘀，把多餘或重覆造成的複雜性減低。

另一方面，「等、靠、要」某程度上是一種怕出錯要承擔責任的自然反應。有些機構也會考慮在可控範圍內，建立起「容許犯錯」的價值觀，鼓勵部門之間嘗試突破，勇敢創新。

當然，這種做法的前設，是犯錯的後果真的是可控，或者已有後備準備計劃會較為穩妥。對於一些合規要求的行業，如金融業，執行起來也要特別小心。

當然，賦權和賦能也是必不可少的。要把責任到位之餘，決策的自主權是需要同步安排。就像是產品思維中強調，自充足的團隊，一般都是獲賦予制定產品路徑的權限，並且可以在機構特定的框架內安排產品發展的優先序的。

配合輕量級的決策，定期的價值回檢，以及由自充足的核心融合團隊執行產品戰略，是管理「等、靠、要」思維的有效方法。

組織的本質邏輯 - 願景、使命和價值

最近在微信裏看了一篇文章，介紹組織管理的本質邏輯和常識，文章很長，超過了2.6萬字，分開了六個部份，不過看完感覺很實在，本篇嘗試用自己的語言整理分享其中一小部份。

商業組織成立的基本原則，是1+1 > 2，或1+1+1+…+n > N，即通過組織，實現個人不能獨立實現的目標。

一般人會認為，商業機構創立的本身就是為了賺錢，這話倒也沒錯，不過這話只是說對了一部份。對於為什麼要設立組織，還有一個更深層的意義，就是組織創立的願景和使命。

事實上，「願景」和「使命」這些詞語初初聽起來很虛，也好像很離地，不過對組織來說又是極其重要。近來因為經常看「產品思維」的文章和研究，看到愈來愈多文章論述產品（尤其是數字產品）的願景、目標和價值。當我們把組織和產品團隊的理念融會貫通，就更能了解這些詞語的意義。

「願景」在組織內之所以重要，其作用是在於協助組織內形成上下一致的價值共釋，組織定位，以及邊界問題。實務的看，共同的願景可以讓組織建立起共同的價值觀，為組織日常的決策提供了基礎，以一致的方向推動發展，並且定位出組織的業務邊界，集中資源在最有價值的業務上。

不過在絕大多數的組織，或者是平常的工作環境，則很少談到「願景」，也很少談到「價值觀」。大多的時候是直接跳到去制定具體計劃，然後就用簡單的財務指標例如收益或利潤來做「目標」。

這樣做的問題是，以財務指標來做的「目標」，一般都是可以有多種途徑達到的。機構如以財務指標為單一標準，更容易多線競爭發展，分薄資源。條線之間亦更會有誘因壓抑成本，以求達到利潤最大化，漸漸形成了商業機構都是為了賺錢而存在的錯覺，亦同時為機構埋下只會追求短期財務利益而缺乏長遠規劃的隱患。

新一代營運數字產品的企業，則比較信奉以「願景」、「使命」、「價值觀」等主題，向投資者、客戶和員工講述企業的經營理念，並且不斷反覆強調其重要性。

就以ATM為例。阿里巴巴的願景是讓天下沒有難做的生意；騰訊的願景是以用戶為本，科技向善，美團的願景則是把世界送到消費者手中。願景是存在於組織內部的核心源動力，指引着組織前進的基本方向和原則。它雖然未必可以完全解決機構內的所有問題，但卻是機構可持續發展的正面動力來源。

當價值觀是像空氣一般的存在於組織內，價值觀相近的人會自然的走在一起，達到真正意義上的合作，推動共同的目標，亦即是真正的1+1>2。

當然，「價值觀」這種東西，是必須要在機構內持續宣導的，而且公司內不同的管理階級，更加要以身作則，示範符合價值觀的舉措，絕不能講一套做一套，以免失信於人。

而同時，價值不像財務指標，很多時也不是輕易能夠量化的，也不能用一條又一條的規則，列出清單來規範，更多的時候，價值比較像是人文藝術，需要由心來感受。

故此在組織內，適宜推動開放融合的氛圍，鼓勵內部互相之間的坦誠溝通，正面交流。這對傳統機構而言當然是很不容易，但卻深受年輕一輩歡迎，也是數字化轉型中重要的一環。

必須要提的一點，當我們提到「價值」的時候，更多的時候是會強調以社會整體價值為依歸，強調社會責任。這一點需要特別留神，因為在很多時，我們會有意無意的把效益、收入等都歸類為價值。

當企業能夠真正把重心放在長遠的整體社會利益而非滿足短期的財務指標，並且訂立真正意義上的願景、使命和共同價值，這類型的企業將會受到大眾包括客戶和員工的擁戴，亦將會深深受惠於數字時代帶來的機遇。

微信原文

建立融合業務與技術的產品團隊

隨着數字化轉型在各行各業的深入探索，愈來愈多的業務流程和操作管理，都轉移向使用電子化平台，出現了各式各樣如FinTech、InsurTech、WealthTech、RegTech、EdTech等名詞，軟件逐漸替代大量手工線下流程，成為業務運營的核心。

在傳統的企業架構，軟件開發一般被視為一項專業技能，就有如風險管理、法律合規等，由專門部門負責管理，但隨着數字化轉型而帶來的業務與技術深度綁定，業務與技術的融合協作程度，成為了影響機構運營效率的主要因素，因此也出現了建立融合型團隊的契機。

所謂的融合型團隊，就是把業務或產品單元中的業務和技術人員，混合編制在一個團隊內工作，在團隊內盡可能移除原有的部門界線，加強協作。融合型團隊的建立有幾個好處：

一、集合業務發展所需的核心業務及技術能力

早前提過的產品思維中強調，產品（尤其是數字產品）應盡可能由自充足(self-sufficient)團隊營運，以便團隊內利用自身能力推展業務，減低外在的限制，進行快速迭代優化。

透過建立融合性團隊，把相對應業務和技術人員編排在一起工作，縮短溝通和原有項目管理流程內的所需時間，可有助提升整體效率。

二、統一制定願景目標

在傳統的部門架構上，業務部門與技術部門的分開，較容易出現部門竪井的問題，各自制定的目標亦可能相互抵觸，造成內耗。

透過應用產品思維，融合團隊可以統一創造平衡業務和技術發展的願景目標，制定長遠合適的產品發展方向，有助減低部門之間的摩擦。

三、合理制定優化產品優先次序和具體工作計劃

在融合團隊，其中一項原則是強調資源統籌調配。工作如何分配，應該是按團隊內人員的能力而定，而不單單是按部門職能決定。故此，技術人員可以參與制定產品發展路徑，業務人員亦同樣可以參與設計系統應用。

而更為重要的是，融合團隊能夠按照業務願景目標或客戶價值，合作統籌所獲分配的資源安排，制定優化產品優先次序和具體工作計劃。

隨着融合型團隊的實施，團隊內亦可以探索合署辦公，或按自身情況建立合適的協作機制，例如透過適合的協作軟件和建立協作流程等，而毋須完全受限於部門原有設定的機制，提高自主性。

不過，要實施融合型團隊，以下有幾點是需要注意的。

一、避免一人同時投身在多個融合團隊內

必須強調，融合型團隊是需要專職專任的。一人分身在多個團隊，必然容易造成資源瓶頸，或因此而造成團隊分工不均的情況，長遠會影響團隊士氣。

故此在實施上，應盡可能安排能夠全身投入團隊的成員作為核心隊伍，盡量減少負擔團隊外的職務，並盡可能避免安排一人身兼多個團隊，以免出現free-rider / 參與角色，難以真正發揮融合團隊的作用。

二、融合團隊不代表要把業務的所有相關人等集合在一起

另一個重點，融合團隊的建立，是把核心的業務和技術人員拉在一起，以聯合隊伍形式運營業務，但其意義並不是等於要把所有業務相關人等集合在一起。

機構內一般也會有些支援部門，例如財務、合規、人力資源管理等，視乎情況，這些部門有時也會需要參加在項目內，但大多情況都不會是主要角色。

對於非核心成員，我們是不應與核心團隊混合隊型的。這種做法不單會造成大量閒置，不符合善用人力資源的原則，更重要的是製造出龐大隊伍，讓團隊難以進行有效溝通決策。

機構可以在實踐過程中，建立合適的核心團隊定義，並按實際情況進行微調。

三、改變績效管理的機制

提到團隊轉型，我們不得不面對的是績效管理的改變。傳統以部門編制的機構，都會按照部門所需制定KPI。

在混合型團隊的實施上，我們需要對績效管理上進行調整，以鼓勵團隊人員投入。其中一個做法，是在績效計分卡上加入混合型團隊的KPI，並與所屬部門原有的KPI形成比例（例如70/30）。

這樣做的好處，是可以提高人員關注混合型團隊內KPI的動機，進而影響其日常工作上的決策。團隊的KPI，可以考慮把原有部門的一些重點KPI 放入，變成共同承擔的KPI。

最後要特別提一點是，跨部門建立混合型團隊雖有助處理部門界線的問題，但也不一定代表就能解決所有問題，仍需要機構內部的持續探索及按實際需求修訂。

另一方面，混合型團隊也可能會造成一些意想不到的壞處，例如跨產品條線的不協調，或發展速度不均，以致造成客戶體驗上的不一致等。另外，一些開發標準和項目管理標準也可能因為建立混合團隊而出現落差，這些都需要在實踐過程中有所注意。

六個工具協助做好用戶需求

上篇提到了那些一句話的「需求」，如何帶來破壞並限制了產品的長遠發展，並舉出了兩個原則判斷是否好需求。本篇會介紹一些好用的工具，協助產品團隊做好需求。

對不少新手（甚或老手）而言，當需要到要做用戶需求，我們很自然的都會認為，要把心中所想用文字表達出來，並且加入很多描述，以規則來表達。

這種想法倒是沒錯，不過總結了多年團隊協作經驗，別說文字了，就算是進行會議面談，也不及加入圖像所能達到的效果。本篇介紹幾個非常有用的圖像工具，可協助補足單純文字的不足。

一、功能流程圖

眾多工具中，筆者最先推薦的是功能流程圖，它是最基礎的工具，尤其適合一些需要跨部門或跨組織進行業務協作，也適合一些多步驟的流程。

一般而言，功能流程圖能夠表現出業務協作的整體流程，可以較易看出流程步驟之間的關連，通常亦會包含操作人員／團隊的信息。有些進階版的流程圖，又會加入各節點的其它前設，或各功能在哪些系統上執行等，盡量豐富內容，減少含糊。

二、狀態圖

另一個很有用的是狀態圖，能夠顯示出一個案例在流程生命周期內可以出現的各種狀態，並用圖表示出互相之間的關連。通常情況下，圖上還會標示出由一個狀態到另一個狀態的觸發事件，操作團隊等。

有時候，我們也會在功能流程圖上為各節點標示對應的狀態名稱，並與狀態圖一併使用，也是視乎實際情況而決定選擇哪種方法較優。

三、時序圖

時序圖經常應用於牽涉多個系統或多個部門的流程，可協助顯示出各個體之間的交互和時序。

時序圖通常會以Swim Lane形式表示，例如不同個體是在不同的Swim Lane，時序圖上則會順着時序顯示個體與個體之間如何交互，以及觸發點等。

如果選擇系統來做個體，亦有助於評估各系統需要提供哪些接口供哪些周邊系統使用。

四、頁面流程

頁面流程是一種很適合面向客戶應用，注重客戶體驗的工具，例如官方網頁或手機應用。流程上會標示出各個頁面和上面的主要元素，而在與用戶的交互後，邏輯根據用戶的不同反應而跳轉到下一個不同的頁面。

頁面流程在手機應用設計上是非常有用，尤其是在眾多資料分配在不同頁面的情況，可協助團隊設計用戶旅程，保證用戶操作的流暢性和合理性。

五、交互原型

交互原型是另一種很適合面向客戶的工具，較為全面的提供頁面上的資訊細節。

舉例就一個填單頁面而言，交互原型就顯示了整個填單頁面的所有欄位位置，甚至一個欄位的需求就包括了名稱，預期輸入的資料，客戶未輸入時的提示，報錯信息等，還有各種各樣的訊息如何向客戶展示。

六、功能特性地圖

功能特性地圖通常會與功能流程圖一併使用。其用法是在功能流程圖的每個節點下，具體例出各個節點的特性描述，當中包括操作邏輯、前設、預期結果等。

對比起直接提出單點的功能開發項，功能特性地圖可以確保各開發項是配合整體流程而定，協助團隊從整體產品角度評估開發優先次序，制定產品的發展路徑。

用功能流程圖配合功能特性地圖來準備需求，實際上也是一個非常好的練習。團隊一方面可以從頂層設計上規劃整體流程，而仔細的需求要點則可以在各個特性上清晰表達。

============

以上的可算得上都是新手學習編寫需求的常用工具。讀者可以自行在網上搜尋，應能找到相對應的圖表示例，大部份都應該是在平時有接觸過的。而實際上，任何以產品發展為目標，可以協助團隊內有效溝通的工具，都可以視為很好的需求工具。

而除了上篇提到好的需求需要是「可估算」和「可測試」，我們亦同時強調，需求在能夠明確時應盡量明確，盡量少做假設或含糊表達，和盡量用小項目迭代形式提需求，都是較理想的做法。

面對一句話的需求，該如何開展項目？

自大學畢業後，出來基本上都是做項目管理的工作，有做過只有3個人做的小型項目，也有做過整個機構動員超過200人參與，橫跨數年的項目。不過，項目大與小本身不是問題，問題是那些需求不清不楚的項目。而隨着項目變大，這種情況更是經常出現。

很多時在大型項目上，尤其牽涉跨團隊跨部門那種，都會出現需求良莠不齊的情況。有些需求寫得很仔細，也有些寫得很粗淺。最粗淺的做法，是用一句說話概括一個開發項。 

例如說，需要一個報表，但沒有提邏輯，也沒有明細，甚至乎給誰看，報表有些什麼主要內容也不定義。又例如說，要一個審批流程，不定義流程內有什麼節點角色，如何啟動流程，更不提流程的目的和定位。

通常遇到這些情況，都會說是因為時間所限，或者不希望需求書太長，或容後再談，實際上是沒有做好範圍管理，到要正式開發時就出現大量修改，更差的是到測試驗收時才說與需求不符。

遇到這種情況，如果開發項是不太重要且能夠拆出來容後上線的倒還好，如果是重點項或必要項，即必須要在上線第一天就要完成的，項目周期也會因而大失預算。 

故此，需求質量絕對是項目管理上的一個重要課題。對於那些只粗淺提出一句話的，我們或者可以先稱之為「訴求」，而不是「需求」。

一般來說，「訴求」會有幾種特徵。

有的是沒有主體，例如看完也不理解服務的目標和價值。有些會寫參考XXX的，雖不清楚XXX的內容和底細，總之就是先抄過來再說，反正不是自己做。

大多的則是沒有內容，例如缺乏業務邏輯、公式運算、流程，或與用戶之間的互動等。而最經典的「訴求」例子，是更換一個系統，所有流程保持不變。

實際上，只有一句話的所謂「需求」，是真的不可能開展項目的。只有一句話的，可以視為「目標」，但這也是不可能達到的目標。就連需求也未能清晰定義的話，項目內出現差錯的機會實在太大，重新做的成本也太高，不如稱之為「喊口號」算了。

那麼，如何可以從本質上判斷出一段話是屬於「訴求」還是「需求」? 以下有兩個基本準則可作為參考。

一個準則是可估算。

就以家居裝修工程為例，我們向裝修工程公司提出需求後，一般會期望工程公司給出報價單。理想的情況，是報價單上能單點列出各個裝修項目的費用，所需材料及費用亦分項列出。

按照報價單上的明細，我們可以大致判斷出工程範圍是否有遺漏，或者有沒有一些地方需要釐清，動工前互相簽字作實，成為有法律效力的文件。

不過，基於經驗的不足，很多首次做裝修的用家，也會提出一些類近「目標」的訴求，例如要一個全白色的廚房，不提廚櫃間隔，不提是否要熱水裝置，就連生火煮食打算用電磁爐或煤氣爐也不定義，哪些家電放入廚房又不知。對工程公司來說，這種客戶的真正「需求」真的是難以想像。

當然，正常的工程公司遇到這種客戶，一般會先按經驗提出一些問題，嘗試引導客戶給多一點明細資訊。但如果客戶仍然只打算以回答問題形式打發，而不重新詳細考慮的話，有良心的公司應會寧願不接項目，也不會冒法律或聲譽風險去接手。

至於沒有良心的，則可能會先開一個大數，到用盡預算後就說是需求沒有提，當做項目變更項處理並另行收費。這種情形，項目大失預算，超時超支和重做，都是可以預期的事。

至於另一個準則是可測試。

作為提交「需求」的用家，可在制定需求時就開始制定測試計劃。因為，優質的「需求」，應該都是可測試的。

事實上，在制定需求時就制定測試計劃，最主要是協助團隊去想清楚開發項可如何驗收，如何才可稱之為完成。

套用以上的裝修工程做例子，除非閣下真的只需要一個白色的廚房，例如用來做拍攝場地佈景，正常來說也應該會想出一系列確認完工的標準，或者說得出哪些事情希望在廚房內完成。把這些標準和場景也同時向工程公司提出的話，絕對有助於工程公司理解真正的用戶需求。

以上的兩個原則其實不難理解，不過在真實的辦公環境，則還是經常會出現偏差。 

眾多因素中，時間限制往往是一個主要因素。趕期、不夠時間、以後再算，辦公環境內經常都會出現類似的表述。而問題的根源，還是在於團隊以舊式部門思維，而非真正的產品思維去營運業務。

舊式部門思維配以流程形式，把項目各個階段當做流程般管理。從需求到開發，到測試到上線，各個階段由不同部門負責。如果各部門都以「交功課」心態處理，就很容易出現「我只是負責提需求」的心態，和那種「要一個全白色的廚房」的訴求。

從長遠產品角度出發，我們應可以清晰地認識，今日走偏門省下的時間，將來有朝一日還是要還的，從來也沒有例外。需求階段的馬虎了事，多數是在開發或測試階段原本奉還。

只不過，在傳統機構的部門架構下，把問題送了去另一個部門，有時真的是可以省下自身的時間的，也讓不少人會禁不住誘惑去嘗試。不過，這真的絕對不是可長遠維持的，也會造成團隊之間失去信任，只適合短視之徒。 

要做好需求，我們實際上要做的是回歸基本、實幹，和做正確的事，用一部一腳印的方式去做好產品開發的每一步。最難的是下地幹活，最簡單的也是。真正把產品作為團隊的核心，減少在項目裹仍然以部門作為界線，是較可行的做法。