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

隨着數字化轉型在各行各業的深入探索，愈來愈多的業務流程和操作管理，都轉移向使用電子化平台，出現了各式各樣如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，其定義不再是保持現有流程不變，而是持續訂立優化目標並持續改進；機構或產品亦不會有所謂成熟及已發展的階段，而會是進入持續發展中的狀態。

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

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

Agile 方式項目管理名不符實？

面對新一代的技術發展，各行各業都在經歷不同程度的轉型變化。不少公司在進行數字化轉型的過程中，均會嘗試引入各種更為敏捷的方法，代替傳統 waterfall 的項目管理，希望讓項目執行變得更快捷。但在不少的實踐上，也預到不少難題。

例如在早些年不少公司嘗試引入Agile，就有不少意見認為，Agile 的理論只適合完成能自成一角，沒有與周邊系統有太多關連的系統開發項目，當中較多人認為可行的包括前端應用，或是最後端的報表，但一談到中層的product system，尤其是以前在mainframe 上建的那些legacy，就很少人認同可透過agile 方式推動項目。

Agile 在前端系統或末端報表較容易成功，在中層legacy system 則很難推動，有人把這歸咎於系統技術的分別，尤其是legacy system 很多時由較為年長的一輩維護，未必容易接受新思維。有人則認為是中層系統對接大量周邊系統，難以推動Agile。個人對前者說法甚有保留，並認為真正的原因肯定不在於技術人員或歸類為前端後端。是否能推動Agile，更多的是在於團隊是否具有產品思維，以及團隊有多大程度做到self-sufficient。

對於近年不少公司加大投入資源開發網上電子平台，項目就是從零到一把電子平台這個「產品」建立起來。在這個初始階段，項目管理和產品管理表面上看似沒有很大不同，都是希望用最短的時間，把產品最必要的功能在第一階段做出來，只不過用waterfall 的人會開宗明義把這個叫Project Phase 1，而有些公司聲稱自己在用agile 的，就稱這個是MVP。

很多初次試驗Agile的團隊容易在這裏踏入誤區，以為只要把一個項目分開成幾個phase，第一個叫MVP，試着做些stand-up meeting，或兩個星期做一次review進度，定義下兩個星期工作範圍，就等於是在用Agile。有些機構甚至以為這樣就已具備Agile 的能力，準備廣泛推廣，結果大多都以失敗告終。箇中的原因，正是這種所謂行Agile 的模式，只不過是waterfall 的一次重新包裝，把一個大瀑布變成了很多個小瀑布。這樣不但毋助解決waterfall 的問題，反而讓問題變得更糾結複雜。

要知道，Agile 的核心理念，肯定不是那些儀式上的事，或限制團隊會議多少人參加，最重要是adaptive，不要求一次性投產所有features，也不着重第一次做出來就完全正確，反而是透過小規模形式的持續投產，對產品進行持續優化。而這裏的投產是必要的，如果只是把元件開發了出來，或放在UAT等待測試，實際上是難以有效獲取生產環境的真實數據。

透過持續投產及建立持續反饋改錯的機制，團隊可以在產品發展過程中不斷優化改進，這種模式的運作，背後正正需要較為長遠的產品管理思維，一方面整體規劃產品的長遠發展路徑，另一方面在實際操作上不斷改進適應市場需求。更重要是，應用產品思維，定位產品目標和量度成效的標準，並按客戶價值訂立項目開發項的優先序，把資源聚焦在產品最有價值的發展上。

對於用Agile 思維做開發的團隊，如果能夠明白Adaptive 的意思，就能了解定義MVP 範圍其實是一個偽命題。真正要關注的，應該是thin slicing 做的有多充份，是否已真正界定出最逼切做的feature，團隊是否保持專注於最有價值的事項上。MVP 並不一定要在一開始就落實確定，更重要是在過程中，團隊透過不斷學習，定義出達致什麼標準才將產品第一版推出市場。

（註：讓筆者記起的是，數年前見過有團隊在行Agile 的時候弄了個MMVP 出來（即mini-MVP），也可謂相當創新。團隊一方面為了盡快上線，訂立了MVP的範圍，但在過程中亦發現，部份原先定義為MVP的features，也不是必須的，故此MMVP 才是後來判斷為真正必須的範圍。）

本着背靠產品思維的Agile 運作，即使是在出名監管嚴厲的金融業，在風險可控的情況下，例如是過程中加入適當程度的過程檢測，以上描述的方式亦都適用。產品團隊站於一致的目光思路，就能具體分辨出產品哪些元素屬於重要，哪些屬於相對不重要，哪些是真正投產必要，並且按統一價值定位進行有效排序，優先實現最有價值的backlog 並進行持續優化。

不過話雖如此，Agile 即使在真正具產品思維的團隊上實際操作，也還是預到不少困難，尤其是在現今世界，大多傳統企業都以功能對齊 (functional align)，部門各自管理，並且各自有自己的專業所長。在這種按功能對齊的企業，團隊除核心成員外還有大量利益相關者，各自站於自身功能立場上出發，這樣的設定下要去對齊產品目標願景，行動力一定大打折扣。

就以金融業為例，行內就經常有說法指金融業難以推行Agile。箇中原因，是對不少產品團隊而言，監管合規要求就是屬於合規部門的工作，也是一個並非自己本業的專業知識（當然筆者並不認為是這樣）。這種傳統上的思維模式，導致產品團隊對監管合規要求缺少基礎知識，亦未能在項目初段已能基本評估產品必要配合的合規安全要求，並定義出優先序。結果很多時是要等到項目大致完成UAT後，才通過內部或外部第三方審計獲知相關要求，導致大失預算，或最終要走回waterfall 的老路，即透過項目形式集齊項目的利益相關者，然後在既定時間內完成項目，並且一整批投產。

只是，多年的實驗基本上已可證明，在waterfall的世界，強調的是一次性做好，認為犯錯會造成re-work 浪費，但卻花費長時間進行計劃，最終在大量假設不符的時候，跌入不斷重覆的re-plan 上，最終不斷出現無限delay，產品即使最後成功投產，也沒有實現預期的value。

故此，筆者認為Agile在新世代仍是一個必要的轉型思路，關鍵是在於團隊的產品思維，持續交付價值，及在過程中不斷試錯改錯。對產品團隊而言，self-sufficient 也絕對是一個重要的指標，這還很視乎管理層是否相信這種模式，企業整體是否能下大決心重組轉型。

當然，要想一步到位轉型成為Agile，對很多企業而言都是難以踏出第一步的，或者只會是個別項目團隊在形式上進行一些小規模的轉變，難以廣泛推廣。對於一些正在踏出轉型的企業，傳統waterfall 式的項目管理辦法，還是有其重要地位，至少可在機構內未完全轉型的過程中發揮作用。而且，即使是對於產品團隊而言，真正落地做的時候還是需要以項目形式推出各個已排序的features的，分別只是把項目變得更少更容易管理，可預測性更高而已，所以傳統項目經理也確實不應擔心傳統waterfall 會因此沒有出路。

而對很多企業而言，進行Agile 轉型本身也是一件很Adaptive 的事情，甚至乎我們是應該可以把產品思維的轉型看成它本身就是一種產品，不是一步到位，而是需要按企業內部用戶實際情況而調整策略，選擇最大價值的優先推廣，這也是很多企業除了選擇某些項目行Agile，還會建立所謂Agile CoE 的原因。

新一代項目管理

近月在朋友介紹下，非常有幸閱讀了曾參與撰寫敏捷宣言的 Jim Highsmith 的著作，書名是【EDGE: Value-Driven Digital Transformation】。作者曾經參與協助無數企業的數字化轉型，並且把經驗結集成書，希望推廣相關理論能夠協助更多企業，當中不少建議甚為落地，也確實是經驗之談。

當前，全球各行各業甚至包括政府機關及非牟利團體，在科技發展成熟的基礎和助力下，都正在進行不同程度的數字化轉型，整個世界正經歷着百年來未見的深刻變化。而在疫情出現之後，相關的變化更加快速，不少企業更面對不轉型即面臨滅頂的危機。

以往，當談到要為企業機構帶來改變，一般也會以項目作為工具載體，把改變的目標，改變的範圍，納入以項目形式推動，一方面可以有效評估項目範圍及周邊影響，二方面可按項目範圍評估資源所需及規劃時間線，循序落實推動改變，對此筆者在以往篇章已有不少介紹。

在傳統的項目管理上，組織着重項目的目標、範圍、功能點、時間、開發成本等，項目與項目之間則透過上層的program 或portfolio 關連管理。這種模式的運作，在以往相對長的時間廣泛為企業採納，建立了很多應用框架（如PMP, PRINCE2），過去算是行之有效。但面對新一輪的數字化浪潮，傳統的項目管理方式也遇到了不少挑戰。固化的流程，不能因時制宜，過份着重是否按時完成或完成多少功能點，而非着重於項目產出價值；過長的項目周期，過程中亦不歡迎改動，難以適應市場變化，都讓傳統項目管理方式面對不少批評。即使是早幾年不少企業提出引入Agile，當去到要全局規模化應用時，很多時亦走不出最終着重跟流程的困局，sprint planning 或 daily stand-up 等都變成形式主義。在此情況下，企業更需要用新的方法帶動改變。

作者在書中介紹的，是一種基於價值而驅動的數字化轉型，無論是哪個行業，都可以根據自身業務性質，進行價值定位，並基於此價值及一系列思維和實際操作上的改變進行轉型。

一是建立以價值為主導的排序機制。一般企業都會遇到有太多計劃想做，而又沒有足夠資源的情況，傳統方法是透過成本效益 (ROI) 進行計算，但這種方法需要大量數據輸入，最終因數據根本上難以精準，即使花費不少時間收集，最終仍需建基於不少假設，而且在不少情況下，價值亦難以多維量化，導致不少企業最終逃不出變成是表面科學化實則是領導說了算的排序方式，亦經常出現組織內互相爭奪資源的情況。

新型以價值為主導的模式，是透過建立機構上下統一的價值觀，建立由整體戰略願景到具體目標再到倡議計劃和專題的可視關連及統一排序標準，並透過定期進行的Value Realization 檢討，讓機構上下對齊投資方向，並讓資源集中投放到合乎目標及最能體現價值的計劃上。

書中介紹的排序方式，主要是透過相對優先級排序，依賴執行團隊對價值高低而作出的判斷，不講求標準化或表面上看似精準的數字公式計算出absolute value，更講求快捷及適應，並且從不斷嘗試中獲取經驗持續優化團隊的判斷能力，是較為人性化及實務的做法。而在各條線團隊之上，則透過對不同團隊進行適當投資，控制「注碼」，確保整個機構不會過量啟動新項目，讓資源集中在重點業務上。

二是建立產品思維 (Product Mindset) 。傳統項目管理思維較着重項目如期完成指定目標範圍，不歡迎項目過程中一切與原定計劃不同的改變（不論是範圍，時間或人手）。坦白說，這種做法在新型的世界是較難生存的，一方面市場訊息萬變，新機遇時有出現，而這種做法的壞處，是即使項目團隊中發現更有價值的initiative，也可能迫於要趕及時間完成計劃內的事，有價值的也要放到phase 2 才做。在一些機構還為項目設定了cost variance 及schedule variance 等KPI，就會更易出現這種情況。

另一方面，項目按範圍訂立明確的開始和結束日期，並以暫時性形式出現，也會變相鼓勵項目團隊採用可能犧牲長遠考慮的短期方案以能在限期內完成項目，無形中製造不少tech debt。而且基於項目的暫時特性，完成項目還需要伴隨不少向BAU 團隊進行的交接和Knowledge Transfer (KT) 工作，這時候就更有機會把問題留給了後人。

產品思維跟項目管理思維最大的不同，在於產品思維更着重產品的長遠和持續發展。一般而言，產品思維會較傾向着重整體的發展路徑，較少着重單個項目是否如期完成及是否完成所有原定範圍，着重價值結果而非完成多少功能點，對於回應市場或業務改變也更具適應性。同時，具有產品思維及營運模式的機構，一般都會建立較為長期存在的產品團隊，有時按業務需要，更可能會建立跨職能團隊，自身包括產品設計，用戶體驗，流程設計，技術開發等技能。這樣，無論是phase 1 還是BAU 都是同一個團隊，可鼓勵團隊以產品長遠發展思路進行決策，將有助平衡短期利益和長期目標。

而回應以上第一點，產品團隊一般亦需獲賦權規劃決策產品發展路徑。這樣的產品團隊對產品發展具有很大程度的自主權，並為產品負責。這樣的團隊適合由具有自主思維的人擔任，團隊可以通過持續優化，對外不斷收集用戶反饋，持續提升產品質素，對內則不斷優化操作及決策，建立對產品的專業性，並為產品創造價值。

要特別一提的是，推動產品思維的轉變並不是代表完全取代項目管理，反之，項目管理在落實專案上仍然有其重要地位，並且更適合應用在拆細後的短周期項目上，詳細會在另一篇文章上描述。

從《Error 自肥企画》看新世代項目管理

踏入2021年5月，娛樂圈最紅熱話，相信除了Mirror 開演唱會，應該要到《Error 自肥企画》了。

在互聯網媒體的出現和廣泛流行下，現在真的已經甚少看電視節目，會看的通常也是用App看重溫，但今次卻是"Live" 看了一次電視綜藝節目。看《自肥企画》，欣賞的除了是Error的賣力演出，更欣賞制作團隊善用資源和創意，創造價值的能力，正正符合新世代項目管理的必備條件。

無疑，制作《自肥企画》絕對是一個項目。制作範圍為15集的節目 (Scope)，有限的制作時間 (Schedule)，有限的Budget和團隊人力資源 (Resources)，即要面對傳統項目管理的所謂鐵三角，互為制限。制作團隊自稱為「無制限OT編集団」，可能也是有這個願景，努力尋求突破限制。

欣賞制作團隊有很多原因，以創意突破資源限制絕對是一大原因。一般人會簡單以為，要想項目團隊做得更好，只要給多點資源 (Budget) 就行，例如網上也有不少留言會想李澤楷給多點預算ViuTV，或想金生、魯生給預算給制作組。但現實是，無論身處任何一個企業，資源有限本身是必然存在，就算不計營運成本或要向股東交代，企業本身每天也會有不同的機會出現，需要向不同項目押注。如果把預算過份投入單一項目，結果反而會是拖累其它項目的機會，不利企業整體發展。

面對資源限制，團隊並沒有因此退縮，反而努力善用獲分配資源，以創意 (或OT?) 搭救，「死亡恆星」就是一例，創意及視覺效果十足，卻肯定是低成本投入。反觀一些在社會工作十多年，卻已習慣使用傳統項目管理工具的團隊，一遇到資源瓶頸，立即就以此作為原因Cut Scope，或者拖長項目時間，或者以「等、靠、要」的思維，set 個task dependency 在自己不能控制的地方以求開脫，處處為項目設限。究竟這些是真正的依賴，還是給自己不能做得更好的理由，值得每個項目團隊反思。

另一點欣賞團隊，是團隊發現及創造價值的能力。真正的價值不容易被發現，尤其是在工業革命後，明明技術能力上未有條件收集足夠的數據，卻又勉強想用共通指標為各種不同的業務評價，造成了很多膚淺的數字比較遊戲，或設定沒有實際意義的KPI，而社會卻已普遍接納這種生態。不說學校教育中求學是求分數，社會上KOL 也是求Like 數 (或follower 數)，投資習慣用公司股價去評判公司價值，企業內部也用ROI 看業務是否值得投資，因此而埋沒了不少機遇。

在同一個可說是十分荒謬的計分制度下，《自肥企画》要面對收視壓力是必然的，但團隊憑藉想造好節目的信念，開僻新的路徑，線上線下的宣傳攻勢，吸引香港觀眾重新追看電視節目，並且加入討論，正正也是新世代項目管理或產品策略中所強調的反饋迴路 (Feedback Loop)。觀眾欣賞節目，社交媒體上的討論，希望參與其中讓節目變得更好，喝啤酒會想喝藍妹，食薯片會想食熱浪，主持人的人氣提升，團隊的工作能力得到讚賞，吸引更多廣告客戶，這些能不能用舊有的計分標準去評價？當然可以，但肯定不足，技術上也收集不到足夠的數據可進行比較。但不管現時收視點的計算是否仍然有效，節目是否已達完美，毋需置疑的是，公司管理層一定會對團隊有信心，願意投資在團隊下次的節目/項目上。

能夠有下個phase，代表團隊可以有進一步發展的機會，這在任何時代的世界都很重要。新世代的項目管理思維，除要求項目在一般情況下遵照一些規條(如不要隨便加Scope，或要在預算內完成計劃)，更需要團隊有長線發展的產品思維，那即便項目過程中發現有些願景不能在一時間實現，也可望在條件成熟機會出現時再發展。例如「掘洞」的整人環節，原來是3年前已經有的想法，但當時項目擁有的資源不容許該想法付諸實行，到今次在《自肥企画》中以「鳳凰不死鳥」的包裝出現，對觀眾來說肯定是一個驚喜，「笑到停唔倒」。

以產品思維作為項目管理的核心，也可以幫助項目團隊進行決策，度過一些難關。例如在項目過程中，如何選擇在同樣的資源和時間限制下，採納優先處理最有價值的需求 (炸生bear?) 或解決哪些問題，並且隨機應變。反觀傳統的項目管理，明明知道現實世界是充滿變數，也持續會有新的機遇出現，卻仍然妄想項目可以預先制定周詳計劃，寧願花費龐大時間進行規劃，然後一切按計劃進行，並且在中途禁止作出任何改變，或一有改變即延長項目時間。這樣的項目管理模式，項目一定也是可以做完的，也可交付原計劃中的deliverables，是否在預算時間和budget下交付則是另一回事，最後交付的也不一定還有價值。

在節目最終回中，制作團隊提出了產品發展更遠大的願景，在現時的社會氣氛下可說是非常大膽。最終回末段的對話提到，「片段化嘅零碎娛樂，令大家習慣覺得任何意念可以喺幾分鐘或者幾十秒之內表達」，「慢慢所有人都唔能夠再有專注力，承載重大意念」，而制作團隊的願景，是要「用節目凝聚同埋補完專注力」，「對抗零碎娛樂」。零碎娛樂指的是什麼？是那些「缺乏前文後理，了無意義」的娛樂片段 (「邊度多左個噴水池」?)。看清楚哪些網媒是在炒作新聞吸睛，讓人沉迷，或借此逃避現實，制作團隊更宏大的願景，是要借「娛樂」本身讓人恢復體力，「可以不按牌理咁歡笑」，對未來恢復希望，特別是要「張開眼睛活著」。

欣賞制作團隊，不得不提的也是非常欣賞Mike導 (Project Manager?) 。鏡頭上，無論是他建立團隊的能力，重視團隊精神，或是勇於為團隊的作品承擔壓力和責任 (e.g. 花姐Error遊雪地一幕)，團隊是互相指責卸責還是齊心合力，都是判斷是否優秀 Project Manager 的差異因素。當然還有Mike導本身的domain knowledge，思考和自我反省的個人能力。如果還有人以為整張task list，每個task 旁邊放上人名、加個時間，然後定期望一下是否在進行中有沒有delay，就算是在做Project Manager，就真的請「張開眼睛」，看一看真正的 Project Manager 需具備什麼特質。

回想自己最初寫這個blog，原意是希望讓更多人接觸項目管理的理論，可以建立團隊去處理和解決問題，或者至少不要在參與做項目時製造新的問題也是好的。但是，現實的問題錯踪複雜，而且受不少利益團體左右，很容易令人困惑、失望、心灰意冷，繼而用了錯誤的方式去「解決」。特別想提的是節目最終回末段的對話，「世界其實唔係有咁多制肘」，「世界其實唔係有咁多痛楚」，對於那些經常控訴社會或上一代的人，請想一想自己是不是也在用「等、靠、要」的思維，把問題推給別人，為自己不想努力解決問題而找藉口開脫。正如對話也提到，「只要一日仲留喺呢片土地上，每一個人都用自己嘅方式，喺自己嘅崗位戰鬥」，每個人都努力，就有望可以成功。