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

隨着數字化轉型在各行各業的深入探索，愈來愈多的業務流程和操作管理，都轉移向使用電子化平台，出現了各式各樣如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出來。

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

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