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

隨着數字化轉型在各行各業的深入探索，愈來愈多的業務流程和操作管理，都轉移向使用電子化平台，出現了各式各樣如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的內容和底細，總之就是先抄過來再說，反正不是自己做。

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

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

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

一個準則是可估算。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

由小CEO到產品團隊的建立，重構企業營運模型

最近在報章上留意到阿里巴巴正在把更多的權力和責任下放，孵化眾多「小CEO」，讓各業務總裁發揮作用，靈活應對業務挑戰。

雖然本人並非阿里巴巴員工，卻也感受到阿里巴巴與很多行業內的巨無霸，都正在進行一系列內部轉型，當中亦採用了最適合現世代的產品思維。

面對業務和行業環境的愈加複雜，即使互聯網公司擁有與生俱來的數字基因，亦難免出現機構老大臃腫的問題，採用傳統由上而下式的管理，實難以應對行業所需的決策速度和對客戶的深度調研。

由小CEO領導產品團隊，以產品思維營運機構內各分支業務和制定產品策略，反而有望可闖出一片新天地。

一般而言，產品團隊具有以下特質：

一、產品團隊內的成員綜合具備所需的業務和技術能力，對產品共享一套價值主張，能夠定位產品的目標客群，制定產品各項發展及推廣策略；

二、產品團隊由前線最貼近客戶的人員擔任，這些人員最熟知和了解客戶的需求，能判斷出最能體現客戶價值的產品功能，把用戶需求轉化為產品需求，憑着對客戶的了解最終交付出客戶需要的產品；

三、產品團隊獲授權決策產品的發展路徑，負起規劃產品發展的責任並落實實施，享受產品創造價值的紅利，也同時負起責任承擔一切其它結果。

另一方面，因為產品團隊是在企業之內搭建，可與其它產品團隊共享企業內的基建配套，但亦受限於機構內的一些現實限制。

一、產品團隊的價值定位，需要符合機構整體的價值要求，或可說是共享一套價值觀。產品團隊亦需要參與機構內定期進行的價值評審，確保產品的價值定位符合機構的整體要求；

二、產品團隊的發展路徑，需要在符合機構整體發展戰略的前提下進行定位，不能過份逾越機構的服務範圍；

三、產品團隊能夠獲分配的資源是有限制的，不能假設機構把所有資源集中在一個產品條線上，投於的資源也應與產品實施的價值成效掛勾。

個人認為，以產品團隊來運營機構業務，是最能符合這個時代的要求的。

時代轉變，在新時代下，社會更講求敏捷反應。以往機構以職能劃分部門，部門以專業知識集中執行某種職能的相關工作。不過，部門竪井問題嚴重，無論是在機構運營、項目或各項流程上，均為傳統企業帶來不少影響，大企業病導致機構難以應對新需求。

另一方面，新時代更講求的是以人為本，着重團隊參與決策過程而非只是接收命令。在產品團隊裏，成員不是要機械式的跟着流程和本子辦事，也不是在挑戰自己極限，看自己在限時之內能交付多少個功能點，而是要學懂去問發現問題，問正確的問題，然後轉化為任務去解決。

故此，產品思維所照顧的除了是外部挑戰和客戶需求，也同時照顧了內部員工的參與和投入。而產品團隊內的小CEO，也不是要指示團隊要做什麼，而是要作為團隊教練，讓團隊成員可與產品共同成長。

不過，機構內整體資源一定是有限制的，也不可能任意給予各個產品團隊的無限資源，故產品團隊都需要憑着成員內部的能力及創意，不停刺激自己的大腦，在有限資源內做最有價值的事，包括是正確的事，應該做的事，值得去做的事。這當然具挑戰性，但也是最振動人心的。

而對企業整體而言，由傳統部門轉化出產品團隊，肯定也是一個挑戰，尤其包括下放決策權力後可能失去控制和重心，員工考核方式要重新制定。而且，傳統部門也在一定程度給予企業共享資源的優勢，不可能一下子完全取替。

企業轉型並沒有所謂一本通書的做法，不過正如過去幾篇文章所論述，轉型一定是這世代所必要的，我們也會見證愈來愈多的成功案例。

別再做流程上的一口螺絲

歷史上，人類的發展普遍奉行的是分工合作，工業時代及全球化更將分工模式發展至極致。數十年發展下來，無論是在地域上還是在機構內，各個領域範疇都出現了精細的分工。

類似的情況亦發生在企業的內部，精細的分工，不同部門負責機構運作的不同環節，掌握不同的專業技能和知識。對較具規模的企業而言，絕少有某個部門完全具備整個機構運作的知識細節，機構也逐漸發展演化出一套基於操作流程的運作模式，進行跨部門協作。

就傳統流程而言，一般設計會以管道作為模型，假設所有節點在收到指令時就會投入資源，將個案由一個狀態轉變為下一個狀態，以便由下一節點操作，最終讓個案通過完成。

不過，對很多創立多年，或有一定規模的企業而言，對於流程的態度可說得上是又愛又恨。

一方面，流程的出現，徹底改善了機構內部管理雜亂無章的狀態，制定操作流程、負責部門、有規則可依，流程可以量度各節點工作時間，制定KPI等，傳統上都被視為具有企業級管治能力的要素。

不過，傳統流程方式又與企業部門架構共生，各部門一般只負責與自身職能相關的流程節點，這種設計模式假設了部門職能不用大範圍改變，當然深受歡迎，也易於建立。但這樣的做法，也產生了不少問題。

當中最常見的問題，是流程牽涉太多節點，中間出現太多交接和等待的時間，構成大量時間浪費。另外也有出現節點之間不能銜接，導致流程去到某狀態後走不下去。更嚴重的是不同部門負責的節點，加起來做了一個閉環，案例困在閉環之內無法逃出。

而其實最核心或最根本的問題，是部門之間互相推搪，流程缺乏整體管理。

曾經見過最極緻的做法，是在設計流程時把所有相關部門叫齊，然後把所有部驟串連在一起，各部門一切現有做法則保持不變，輕鬆完成！

結果當然是問題百出了。流程上各個節點都視自己為參與角色（一口螺絲），只對自身部份負責，整體流程的負責人則欠奉。這種情況下，即使結果是面對大量投訴，機構內亦無從入手去進行優化，只能互相推諉，績效低下。

有些機構選擇退而求其次，成立流程管理部，專門「集中管理」跨部門協作的流程，或借此提高流程的質量保證。這種做法在初期也有一定效果，但結果通常是出現像獨立PM牽頭項目的情況，參與部門更加抽離。

要面對這種情況，可以從兩個切入點嘗試作出改善。

一、把整體流程視為產品，從用戶角度出發

在現今的世代，我們應考慮在建立流程的第一天，就把流程本身視作為產品去經營，並且引用一切產品思維，套用在流程設計和持續優化上。

細心想一下，最根本需要制定流程的原因，從用戶角度出發，解決什麼用戶痛點，流程的價值所在，服務定位，這些都是開始制定流程時的初心。

另外，應用互聯網思維，持續量化和量度流程上各個節點的表現，從數據中找尋優化流程的契機，甚至乎，讓沒有實際作用的流程節點刪除，減少臃腫，保持長青。

二、把流程節點視為產品，對外提供服務

除了是整體流程，流程各節點的負責部門亦應把自身工序視為產品，對外對內提供服務。

最近從阿里巴巴云架構課堂裏學到了domain primitive 的理念。應用這個理念，即使是一口螺絲也應該是一個domain，為這個domain 內的事情建立規範，對外則以參數模式提供服務，保持一定靈活性。

在這種思維模式下，每個流程節點都需要思考自身的存在價值，如何提升效能，或如何更好地提供服務。跟傳統節點做法相比，新的思維更着重自主性和適應性，而不只是「參與」性質。

不過，要推動上述的改變，也並非容易。一方面，有一定規模或年資的企業，都已現存大量流程，要想在現有架構及現有的流程上定出牽頭部門，單是開會討論也已是不少成本，不擇手段下又是推舉一個獨立PM出來。

而以上最重要的改變，其實是人員的思維模式的根本改變，由按本子規則辦事，轉變成以目標價值為本的自主管理。對於很多習慣了現有模式的人來說，這幾近是一種無法跨越的鴻溝！

不過，在新世代的思維，新的一輩似乎傾向更着重工作的自主性，並視傳統跟隨規則做事的方式為守舊。順應時代的轉變，以及舊有產物的替換，我們可以思考如何從規則主導的商業模式，轉變為以原則和價值主導，以人為本的運作模式，建立更優質的工作環境和發展路徑，相信這亦是未來的大趨勢。

傳統項目管理思維為企業管治帶來的硬傷

曾經聽過有這樣一種企業管治的辦法，是把機構內所有的事情都以項目形式進行管理，定項目工作清單，定時間表，找人負責各項工作。

作為一個已出來社會十多年的項目經理，面對這種思維，著實有些感概。

對於一些較為傳統的機構，按照數十年前的企業管治模式，把企業劃分成數十個部門，各司其職。資本主義下，這類型機構一般又會以利潤最大化模式經營，以完善流程及提高運營效率為目標，並發展起一套以KPI 為目標的考核評級制度。

傳統項目管理思維，對傳統機構而言，可算得上是極為吸引。一方面，企業以部門劃分職能的整體架構，在推動項目上可接近完全不受影響，二方面，部門可視參與項目為只會貢獻原來職能的範圍，原有的KPI 制度亦可予以保留。

不過，經驗告訴我們，當出現有方案是讓大家都感覺到十分舒服的時候，通常會有問題隱藏在細節內。

傳統項目管理模式，最常出現問題是在項目目標與部門目標出現衝突的時候。基於部門KPI 考核，容易出現部門先顧KPI 而後顧或不顧項目，甚或不顧整體企業利益的情況。

另外，項目內維持部門界線，各個非牽頭部門視自己為參與角色，各種陽奉陰違的事時有發生。限期內提交未完成的需求有之，把未完成的開發交付到測試有之，見過最過份是未完成測試就簽字通過上線，以為可用生產bug fix 來倒迫開發速度，可謂本末倒置，嚴重違反盡職盡責原則。

這樣的情況，也容易導致部門之間互相推搪，不願承擔牽頭責任，尤其是當出現需要多部門參與的項目，問題更加嚴重，最終通常需要另安排獨立人士出任PM，而本身有關連的則全部作為參與角色，更加抽離項目。

而面對新一代數字化轉型浪潮，傳統部門架構和使用傳統項目管理模式，最大的硬傷就是慢！

以部門做單位管理，各部門需訂立自身的全年計劃和目標，互相爭奪資源幾可說是必然結果。尤其是對於機構內的公共資源，更容易成為樽頸，在不想得失各方下，自然是勉強接受、同步執行。

這樣的安排通常會有兩種結果，一是機構空有大量項目計劃但大多進度緩慢，二是各部門未有正式需求也想先佔有資源，留有一手，但卻更加速資源的虛耗（public bads），讓資源更加分薄，項目行得更慢！

面對以上的狀況，有兩點做法可作為起步。第一點是整體規劃，從頂層設計做起，重新確立機構的重點業務及價值定位，並把資源優先調配到相應位置。資源永遠是有限的，沒有價值的業務，應認真考慮忍痛放手。至少在資源投放排序上，應能與價值相符。

第二點，是創造圍繞客戶價值而建立的產品思維文化，並相應建立產品隊伍，推動產品長遠發展。產品隊伍應盡量做到self-sufficient，減少跨組依賴，這通常會牽涉打破現有部門架構規範，不能一步到位，但可以透過試點團隊摸索最適合機構的做法。

以上兩點，從理論層面上看並不難理解，唯實踐起來必然遇到困難。第一點，難在學會放手，對外要面對股東或其它持份者的質疑，對內亦可能觸碰到一些團體的利益。第二點，涉及企業架構的調整，但業務還是得繼續營運，算得上是動大手術，必須步步為營。

不過，愈來愈多的公司已認識到，轉型已不再只是提升效率的問題，更是企業是否能繼續生存的問題，不能適應的話，就是管理責任的缺失，最終只會讓企業面臨被淘汰。值得慶幸的是，不少公司已踏上了轉型的路上，並且在過程中獲得了不少寶貴經驗，最終能夠在行業內跑嬴對手的，將可浴血重生。

產品思維 vs. 項目思維

上篇提到，不少團隊在使用Agile的過程中，避不開傳統waterfall 式項目管理的問題，甚至為了要走形式上的Agile，導致問題變得更為複雜。要真正面對新世代的挑戰，需要的除了是Agile的方式，更需要思維上的改變，以產品思維推動業務發展。

在分析產品思維和項目思維之前，先回顧一下項目管理，特別指傳統waterfall式項目管理的設定。

首先，傳統waterfall 式項目管理強調的是計劃，指的是詳細的計劃，包括具體範圍，所需時間，所需人力資源，並且會在計劃過程中考慮可能出現的問題，提前做好預防措施。另一方面，waterfall 亦強調過程中按計劃執行的重要性，盡可能防止過程中出現改變，導致影響計劃，務求一次性做好，減少浪費。過程完成後會進行項目檢討，希望將寶貴經驗帶到下次項目上。

源於waterfall 為萬事做好準備的特性，在過去一段大環境相對穩定的時間內，可合理假設大多因素是在自身控制範圍之內，或者風險可以預期並且實施預防措施。在一段頗長的時間內，waterfall 確實整體提升了營運效能。不過，在進入移動互聯網年代，外在環境急劇轉變，waterfall 無論在適應能力或可靠性上均顯得有點乏力。

其中一些waterfall 預到的問題，是縱使不少團隊花費長時間進行計劃，仍然會出現項目初期資料不完整的問題，或需要做不少假設。尤其是當面對較長周期的項目時，假設亦隨着項目範圍和項目周期而擴大，項目初期做的計劃根本難以完全正確，問題就變得更加明顯。結果很多時是在大量假設不符，甚至項目期間根本沒有去證實假設是否正確的情況下，項目就已不停延期，而團隊亦陷入不斷重覆的解釋，並且重覆進行重新計劃，問題則依舊繼續出現。另一方面，項目過程中出現的新機遇，引致項目方向的轉變，對waterfall 團隊而言，也是影響計劃的改變，較難接受及轉身，很多時候不能即時回應。最後，項目完成後雖然有進行檢討，但下一次項目很可能是一個全新的團隊，團隊共享的經驗也難以帶到下個項目上，難以積累經驗。

不過，儘管傳統waterfall 式項目管理有不少問題，但自上世紀七十年代工業發展時代起就一直普及，即使Agile 在二千年代初已出現，但主流仍然是用waterfall，筆者認為其中主要原因有三。一是按waterfall的模式，較方便制定計劃 (先不管計劃是否可靠)，亦較容易訂立易於量度的KPI，例如項目是否按時完成，資源使用有否超出預算等，變相方便進行預算管理及人員能力評核。另一方面，項目本身以臨時形式出現，項目團隊是臨時組合而成，變相毋須破壞機構本身的編制和架構即可建立起項目組，看似較易集合所需資源。第三是項目較適合適合人員按自身工作範圍參與其中，便於建立操作流程，即適合按本子辦事的工作模式。整體而言，waterfall 式的項目管理是從內部管理視覺出發，整體有助制定標準化流程，建立理論，較適合工業時代的發展。

至於近年逐漸普及的Agile，正如上篇提及，不少所謂採用Agile 的團隊，底層仍然採用精準計劃的思維，進行大量前期計劃，建立不少新的KPI 量度成效，歸根究底是思維上仍未能接受沒有具體計劃那種很不確定也很不踏實的感覺。某程度上，不確定感會讓人感到有風險，自然會希望透過計劃來排除風險，這可以算是人的天性，但當我們深刻認識到，在現今世代所謂的計劃或預計，很多時候都來自於假設，即是說這種計劃本身就存在很大的不確定性，以為有計劃就無風險也很可能只是錯覺，而大多因素在自身控制之內的這個假設本身也很有商榷餘地。

故此，在Agile的項目工作模式，着重的是適應性 (Adaptive)，不講求鉅細無遺的範圍或時間計劃，更講求項目過程中適應改變的能力，還有項目朝着正確的方向前進。Agile也會有計劃，但就不會是由上至下的詳細項目計劃書，多數是項目的整體目標和價值定位，以及評估執行優先序的機制，並在推動項目時持續優化。Agile 項目更偏向代表着長期項目，或者是產品的長遠發展，多於一個傳統定義上有限周期的短期項目。

基於Agile 這些特性，Agile 的團隊通常會由相對長期存在的隊伍組成，並且隊伍的整體能力能夠做到self-sufficient，並在項目過程中持續學習，所得經驗亦由團隊維繫。同時，Agile團隊更講求自主性，例如自主決定發展路徑、優先排序、實施方案等。更重要的是團隊有持續改進的精神，在實踐過程中，能夠接受自己的不足和判斷錯誤，並在過程中不斷糾正。

個人認為，應用Agile 的團隊，必然是需要背靠產品思維的，能夠本着產品長遠發展的角度出發，制定產品的願景目標和團隊的核心價值定位，再進一步落實到團隊的執行策略及方針上。產品思維亦提供了讓團隊保持在正確發展路徑上的保障 - 具備產品思維的團隊，能夠聚焦於最有價值的發展項，為產品評估和投放資源在當前最值得做的項目上，確保團隊把重心放在團隊認為正確的發展路徑上。

回到本篇最原先的分析比較上。事實上，本篇最想帶出的是，產品思維和項目思維本身是不存在衝突的，而且在新一代更有機會創造一種有機融合。在新時代下，產品思維着重產品的較長遠發展，評估資源投放和項目的優先序，而項目思維則是應用於具體落實到每個項目時的管理辦法。某程度上，項目管理只是一種手段或一種執行方法，重點反而是，新的業務發展應更着重以小項目形式推動持續優化，減少進行整體替換系統級別的大型項目，減低大型項目管理中的計劃複雜性及遠期不可預見的情況。這樣做一方面可沿用傳統項目管理的優點，落實資源評估和推動產品的持續改進，另一方面則可保持產品團隊整體的靈活性和適應性。

與此同時，在新時代下我們更傾向以具備產品思維及相對長期存在的團隊推動項目，產品思維要求團隊具備自主性，即自發檢討現有機制提出改進需求，並持續提升。對比傳統思維，認為項目團隊是在有需要的時候才設立並屬短期性質，甚至要求一定要先有PM 才能有項目，或者項目是由PM 來驅動，其餘時候則BAU或按本子辦事；產品思維則更強調建立長期存在的隊伍，由團隊自身訂立具體工作的模式和規範，並以實現的價值為衡量的指標，持續優化。換句話說，在新一代的BAU，其定義不再是保持現有流程不變，而是持續訂立優化目標並持續改進；機構或產品亦不會有所謂成熟及已發展的階段，而會是進入持續發展中的狀態。

另一方面，產品團隊的價值定位，會更傾向以外部客戶價值為重心，而非內部的量度標準。事實上，團隊一年完成了多少個項目，項目用了多少支出或人力，或者是否準時完成，雖然也很重要，但這些都可以看成是內部的指標，或者是管控資源使用的手段，對於客戶價值而言，這些是沒有多大意義的。出色的產品團隊將會更多的以客戶為中心定義指標，並把這些指標轉化成可以具體執行的專題和項目需求。在初期的時候，這些價值可能看起來難以量化，或者難以量度，但這是必要經歷的轉變，我們將需要同時學習更多借助科技和數據的力量，實現價值的衡量。

最後，由項目思維轉移至產品思維，這個除了是個別團隊的轉變外，更加會牽涉到機構本身編制和架構的改變，並非一踘而就。事實上，「轉型」本身就可以是一個長期項目，並由產品團隊去推動，過程中按照機構的實際情況進行持續及適當的調整設置。個人認為，流程化和標準化，以至項目管理的理念，均可以說得上是工業時代的成就，但在新時代下，我們更需要的是價值觀和人性化，包括為團隊注入正確的價值導向，讓團隊成員共享產品的價值定位，而產品思維，正正是回應時代所需的新一代管理思維。