數位發展部22日於「2025 Meet Taipei 創新創業嘉年華」舉辦「從Project到Product：臺灣軟體企業的全球競爭力之路」未來座談，由數發部長林宜敬親自主持，邀請趨勢科技CEO陳怡樺、玩美移動CEO張華禎及訊連科技CEO黃肇雄共同與談，深入探討臺灣軟體產業在AI 與雲端浪潮下的轉型契機。記者黃仁杰／台北報導

數位發展部22日於「2025 Meet Taipei 創新創業嘉年華」舉辦「從Project到Product：臺灣軟體企業的全球競爭力之路」未來座談，由數發部長林宜敬親自主持，邀請趨勢科技CEO陳怡樺、玩美移動CEO張華禎及訊連科技CEO黃肇雄共同與談，深入探討臺灣軟體產業在AI 與雲端浪潮下的轉型契機。

[caption id="attachment_199396" align="aligncenter" width="1319"] 數位發展部22日於「2025 Meet Taipei 創新創業嘉年華」舉辦「從Project到Product：臺灣軟體企業的全球競爭力之路」未來座談。（圖／數發部提供）[/caption]

林宜敬指出，國內多數軟體業者都以專案開發為主，以外包方式承攬開發，雖能快速回應市場需求，但卻難以複製與累積開發量能。產品開發則面向廣泛市場，朝模組化設計轉型，一旦完成開發，就能透過複製與規模效益，賣給不特定多數。強調唯有「做Product」才能創造更大的價值，呼籲更多企業投入產品化發展。

座談就臺灣軟體產業的全球競爭力之路進行，探討臺灣軟體產業必須面對市場小、人才少、國際經驗不足的核心問題，並一致強調軟體公司必須從第一天就放眼國際市場。此外，行銷人才的培養也是一大挑戰，三位執行⾧認為行銷軟體最重要的是實戰經驗和理解客戶的專業語言，最後更探討了生成式AI對軟體業帶來的巨大變革與機會，特別是專業化小型語言模型（SLM）和主權AI的概念，為臺灣軟體業指明了新的方向。

趨勢科技CEO陳怡樺認為，理解客戶問題，並且學會講「客戶的語言」很重要。Gen AI 正在降低過往因不同國家語言所產生的溝通門檻，這正是強化國際行銷的好機會。趨勢內部正在採行一種新的行銷方式，稱為Forward Deployed Engineer（FDE），即是讓工程師到前台成為具有行銷及顧問思維的人才，讓客戶體驗、試用產品，汲取客戶回饋，快速優化產品。

玩美移動CEO張華禎指出，由於臺灣市場不夠大，公司從 Day one 就要定義產品以賣到全世界為目標。玩美移動以 beauty、fashion 等垂直市場為核心，用專業洞察解決客戶痛點，憑藉領域知識，獲得國際美妝集團給予「唯一聽得懂美妝的科技公司」的認可。同時也強調無論做B2B或B2C市場，「產品與訊息都必須有清楚的主軸」，才能吸引全球使用者。

訊連科技CEO黃肇雄強調， 臺灣社會對軟體業普遍存在誤解，認為它「比較簡單」，但若要取得巨大成功，其實比代工型硬體產業更加困難。面對全球競爭，產業快速變化，國際行銷需投入大量資金，為提升競爭力，需要建立一個足夠大的產業聚落，讓人才能在產業實戰（BD、行銷、產品規劃）中淬鍊，累積經驗與實力。並透過與國際夥伴的深度合作（如AI PC），強化產品在全球市場的競爭力。

林宜敬說，臺灣軟體產業正站在關鍵轉捩點上，並呼籲臺灣的軟體工程師能盡量留在臺灣，加入本土已布局國際的公司，或投入創業。目標是在三、四十年或更早，讓臺灣也能有像 TSMC（台積電）一樣稱霸全世界的軟體公司。

這篇文章 數發部盼成就新護國神山 打造軟體業產品化與國際化新局 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

這兩天聽到一集podcast，有感而發：
矽谷為什麼？EP116 — S&P500上市公司高階主管的三階段管理哲學 挑戰美國職場天花板 | 專訪Etsy資訊長 謝居呈
內容講的都是比較典型的美式管理風格，我個人認為也是相對主流的風格。

文／Evans Ye

這兩天聽到一集podcast，有感而發：

矽谷為什麼？EP116 — S&P500上市公司高階主管的三階段管理哲學 挑戰美國職場天花板 | 專訪Etsy資訊長 謝居呈

內容講的都是比較典型的美式管理風格，我個人認為也是相對主流的風格。不過基於我個人在兩岸工作幾年的觀察，固定思維多少都存在，之前的主管怎麼帶怎麼教的，都是最真實的體感烙印，比起書上與 training 講的形而上，真實經歷更容易實操也更穩健，所以如果沒有特別刻意去思考和改變，大部份的人還是腳踏實地『遵循古法』了。

與其空泛地說怎樣比較好，不如比較一下差異在哪。本來我想把管理風格分成美式與中式，後來想了一下，用成長思維 V.S. 固定思維去解釋也滿順的，姑且美式就叫做成長型管理風格，中式叫做固定型管理風格吧。

首先，我認為產業與職務特性是影響管理風格很大的先決條件(無關職業優劣)，比如研發工程師 X 成長型管理風格，OK；產線作業員 X 成長型管理風格，也許不那麼適合。其中有一些本源的差異：

知識變化速率

軟體產業的知識變化速度極快，需要不斷更新知識因應變化。而變化本身使得不在實作第一線的管理者沒辦法擁有最 up-to-date 的知識做正確的決定，所以有一部分決策需要仰賴一線軟體工程師 input，因此透明、合作來最大化正確決策的機率就是順理成章的事。另一方面，軟體發展的進程也不過是百年內的事，因此這個產業很多東西還在一直在高速發展中，比如之前大數據系統剛出來時，把大數據儲存與計算問題解決了，也使得需要大量數據運算的 Deep Learning 普及化，cloud/container/kubernetes 讓 software-defined infrastructure 達到工業級水平而大爆發，這些也僅僅是近十幾年內在軟體產業發生的典範轉移，所以能不能跟上時代，持續學習成長的能力就很重要，在這個產業中如果不創新，就會被創新殺死。主管如果故步自封，拖累組織進化的進程，恐怕是要第一個被淘汰，或者讓組織『被淘汰』了。

反過來說，如果完成工作所需的知識幾乎固定不會變動，不需要員工提升組織的知識邊界，而是需要員工穩定、高效率、正確的輸出，那用成長型管理風格可能有點勉強。用固定型管理風格，主管獨立做決策快速給命令、員工遵從階級制度確保命令被貫徹執行，以恐懼建立威信，用嚴懲來嚇阻犯錯，可能相對適合。這裡講得比較極端，具體怎麼拿捏好度就是智慧了。

創新帶來的回報

軟體開發如果更多涉略研發與創新(不見得是 research，新的應用、新的實作、新的 business model 都行)，有時也要一點運氣才能成功，但是軟體天性容易複製，網路效應容易放大成果，所以很容易 scale，回報也就大， 因此就很適合有相對高一點的創新佔比。

訪談中提到創投如果看到一個創業家沒有失敗過的經驗甚至會有點擔心，因為他可能還沒撞過牆，還太過膨漲，不知道怎麼在邊界內做事。有經驗的創業老手知道怎麼 take calculated risk，追求好的 decision quality 提升勝率，但也坦然接受不可控因素，從失敗中挖掘出有用的知識和以前沒考慮到的維度。

前面提到創新總有一點運氣成分，所以有良好的心態面對失敗就很重要。如果是固定型管理風格，管理者面對失敗就很容易敗給人性的弱點，會極力找各種理由，或用模糊的說詞避免直接承認失敗，因為害怕承認自己有所不足會有損自己的威信。這是因為擁有固定思維的主管覺得自己『應該要』比員工厲害，『應該可以』做好，所以有問題的話，一定是其他問題而不是自己有問題。有的主管則是自己都清楚狀況，但就是愛面子拉不下臉。

其實看破不說破，幫忙扶一下主管的面子，維持主管尊嚴確保指揮體系的效率，倒也無傷大雅，不過僅限在固定型工作環境比較適用。不承認失敗的另一面是放棄探究失敗的原因，對於知識相對固定的工作影響不大，但是如果是成長型工作，那所有人都錯失一次寶貴的學習經驗，軟體業 impact scale 大的天性，也可能令重複犯相同錯誤付出極高成本，更嚴重的是形成糟糕的表面文化。

這邊要注意的是，我們不是讚頌失敗，也要避免習慣失敗，或者用學習成長做藉口美化失敗。具體探究失敗的原因，保持成長心態，接受創新可能帶來的失敗，但如果是明顯可避免、工作態度不正確造成的失敗，也需作出適當的懲罰以設立底線，建立正確的價值觀。

市場供需

最後這個因素就比較現實了，優秀的軟體工程師一直都是都是供不應求，所以需要兩個面向來達成需求：

1. 培養：找不到人的一個方法就是自己養成，所以要採用成長型管理風格。
2. 留才：要留住人才就要有誘因，成長型管理風格能夠滿足人才自身的成長與成就感需求。

如果哪天軟體發展漸趨成熟，各種底層/中層/low-code solutions 都齊備且能夠滿足 80% of business requirements，也許軟體工程師的 bargaining power 就不存在了，到時候也只能忍氣吞聲求口飯吃，學習成長靠自己吧。不過我相信人類社會的發展一定是持續朝更好的方向前進，屆時大家都能擁有足夠的知識，判斷怎樣的管理方式適用。

最後

過與不及都不好，中庸之道的精妙在於了解整個系統後，如何妥善調控兩個極端中間的邊界來取得平衡。美國作家菲茲傑拉德（F. Scott Fitzgerald）在小說『了不起的蓋茨比』中說：『檢驗一流智力的標準，就是看你能不能在頭腦中同時存在兩種相反的想法，仍能維持正常行事的能力』。先不急著否定，探究事情的本源，也就能理解兩個截然不同的想法有各自背後存在的邏輯，往系統性理解前進一步。

走筆至此，大家應該不難發現我還不具備一流智力，文中多少帶有一些主觀傾向性吧(笑)。

這篇文章 軟體業管理風格(一) 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

軟體業 PM 有時候真的是常常在救火存在於生死存亡中，必須具備高抗壓性的 EQ，以及臨陣不亂的處事 IQ，才能夠順利的將專案結案、產品推上線。這曲折離奇的生命週期，像極了近期很紅的影集《泰國洞穴救援事件簿》，內容有微量劇透，大家可以斟酌閱讀。

軟體業 PM 有時候真的常常於生死存亡中在救火，必須具備高抗壓性的 EQ，以及臨陣不亂的處事 IQ，才能夠順利的將專案結案、產品推上線。這曲折離奇的生命週期，像極了近期很紅的影集《泰國洞穴救援事件簿》，內容有微量劇透，大家可以斟酌閱讀。

五個職場生存學

一、相信生機還是果斷放棄

起初地方首長好幾次度困難關頭，冒著政治生涯的風險要決定探探是否有生機或是果斷放棄，中間的機會成本來自於人命與耗費巨大資金與人力。跟 PM 平常做專案與產品總會有身邊的人事果斷的說，這必定失敗的產品不該再進行，實際上當我們數據不夠，又有什麼資格用「直覺」、「經驗論」來下決定？

如果沒有嘗試過的智慧以及冒著失敗的勇氣，那恐怕世界上一堆科技產品將不復存在，沒有我們拿著的 iPhone、每天上網交友的 Meta、聽著音樂的 Spotify。

二、尊重專業與妥善的專業合作

海豹突擊隊擁有絕佳的體能與裝備，一度不肯相信市面上的洞穴潛水員，殊不知特殊的地理環境必須仰賴更專業的潛水員經驗與裝備。另一方面水利工程師因為過去的經驗不斷被地方首長拒絕，最後水利工程師索性與懂地利的工作人員共同突破困境，解決淹水的問題。

作為 PM 指揮官我們不可能時時刻刻懂所有專業，人力、資金與時間有限的情況下，尤其在黃金關頭，我們能做的是不被過去經驗束縛，好好聽取專業人士如何透過邏輯推演、數據佐證，再藉由跨部門的專業相互協作，並非仰賴一個穀倉的自傲嘗試解決。

有合作，才有突破。有信任，才有解方。

三、最壞的打算與最好的規劃

當兩個政府高官有著不同的解決方案，卻遲遲不能說服共同長官，這時長官做了很好的決定，說到「不要因為最後失敗，卻被說沒好好考慮其他方案」，最後轉為讓兩者共同進行彼此實驗，用成本換取時間。最後的確有可能失敗，但不可能什麼都不做，要抱持失敗的風險，跟團隊人員說明白前提條件，妥善規劃後執行。

畢竟不是預言家，PM 不可能每次都打完美的勝仗，時機不斷變化，我們有的就是在做出相對正確的選擇，風險規劃、PoC（概念驗證）來減少可能發生的風險，都是必須步驟。

四、如何面對失敗與恐懼

無論是被困在洞穴裡的受難者，還是在外面著急想著解決方案的人，彼此都不知道能不能生存或是救出，所幸雙方都有鼓勵員要求大家用正向的態度面對，恐慌不能解決問題，而是盡可能做出能夠增加成功機會的行動步驟。

當產品專案可能延期、超出預算、無法上市等失敗，的確我們要下出停損點，而作為 PM 最不能做的是自己先喊放棄，就像是一個將領如果自己先放下武器投降，那誰還願意努力。當然並不是要過度樂觀，而是要放下恐懼，適時鼓勵，找出彼此不安的成分，一個個排除。最大的敵人往往是自己。

五、測試永遠只是測試

其中有個方案是要用管線將氧氣輸送到洞裡，外面測試成功了，有個地方長官很開心，卻被工程師直言不諱表示這只是測試，我們需要的是更多的時間與保險才能知道最終能成功。

這就好像我們平常軟體在開發者環境一切正常，最後上線使用真實數據後，卻有莫名的錯誤。這的確是再正常不過，而且我們通常還要直接在正式環境找出問題、排除困難。這時候我們除了平常心面對，也要給客戶打預防針。同時，還要想辦法隨時能夠有 Rollback 方案，更好的方式是上線前要有足夠的壓力測試、封測，都是幫助我們降低端出給用戶和客戶的風險。

結論

儘管影劇就是影劇，不能完全代表真實世界。換個角度，我們平常聽到的巨頭科技公司遇到的難題、學校出的案例研討，不也是「被改編」的嗎？我們仍然可以借鏡，訓練我們思考能力，作為 PM，真的需要臨危不亂的高 EQ，以及有條不紊的處事 IQ 能力。

這篇文章 從 Netflix《泰國洞穴救援事件簿》，思考軟體業 PM 的五個職場生存學｜專家論點【Mr.T】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

陸續用影音串流產業作為舉例分析 B2B 軟體業的獨特性以及如何解讀，如果你也是很喜歡接觸企業客戶，或是很好奇在 B2B 企業我們遇到的「面試」難題，該怎麼迎刃而且。歡迎閱讀下去。

陸續用影音串流產業作為舉例，分析 B2B 軟體業的獨特性以及如何解讀，如果你也是很喜歡接觸企業客戶，或是很好奇在 B2B 企業我們遇到的「面試」難題，該怎麼迎刃而解？

分析方式

一、Why 企業扮演什麼角色

終極目標就是用 1-2 句話概括描述，例如我們是專門協助網紅直播主能快速建立聲量與影音的平台。當然為了詮釋這句話，通常要先了解下面的五個段落內容。換個角度思考，企業是屬於業務導向、產品導向、還是技術導向來作為價值判斷的依據。當然會被反問到「自身覺得最重要的是哪種導向」，沒有對錯，只有價值觀是否合適。

更直白的例子，我們可以清楚知道什麼時候你會選擇看 Netflix, Disney+, ESPN 這些頻道，之所以消費者會有這些選擇，這些頻道必定有很明確的定位。

二、Where 市場在哪裡

每個洲際、國家都擁有完全不同的進入市場模型，也有些專業工作者在漫長的職業生涯有偏好的人生目標你可以想想自己喜歡歐美、日本、韓國、中國、台灣、東南亞等等幾種市場，「語言」也是很重要的思考點之一。

當然除了國家，也要思考期望服務哪些產業。此外，B2B 產業相對容易因為同產業間的合作，而跟不同國家的人一起工作。

三、Who 需要跟誰交手

想想面向佔比多少 — 內部夥伴（設計師、業務、工程師、行銷）、一線客戶（是專們合作一個還是同時多個）、外包廠商、第三方合作廠商。這些都會影響身為 PM 的溝通能力與專業能力。

B2B 軟體產業通常資金來源大部分是客戶，因此有沒有處理過大型專案（金額、人數、年限）、大型產品（需要跟各種廠商合作的生態系解決方案），是非常重要的一環。

四、What 解決方案是什麼

有些同學喜歡重度客製化，雖然很難複製成功經驗，卻有很明確的開始結束；也有夥伴喜歡全局思考打造標準化產品，這就很考驗如何衡量不同專案的優缺點。

通常這跟企業的商業模式非常有關，作為 PM 會是偏向專案經理、產品經理、類似顧問角色的重要性，會隨之而變。企業級產品的合作，通常有外包導向、專案導向、顧問導向、產品導向的不同類型，隨著企業提供的解決方案與角色定位，影響著我們作為職涯選擇，是否合適自己的職涯歷程。

五、How 如何打造專案或產品

其實這在進去企業服務之前很難知道，只能透過熟悉的朋友打聽組織編制是什麼、怎麼決定或放棄一間客戶、產品做法是屬於敏捷、瀑布、還是隕石。

這點就跟 B2C 產品的差別相距不遠，而相對不同的是，因為是企業間的合作，通常無法隨心所欲的製作產品，而是要想像「如何發掘產品需求」為出發點。

六、When 企業在哪個時間軸上

自己可以預測過去、現在、未來的座標在哪裡，也可以透過面試了解 3-5 年內的目標，儘管會得到官腔回覆，這就考驗我們如何深問細節。

結論

即使我們用影音串流產業作為範例解釋，這些通用的法則可以任意使用在各種 B2B 軟體產業服務，儘管這種拆解方式雖是冰山一角，看似稀鬆平常的思維，卻是不可獲缺且必須思考的面向。

這篇文章 如果我是 PM 想進入B2B 軟體產業？面試時可以用這 6 種分析方法選擇職涯方向｜專家論點【Mr.T】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

B2B 產業最為特殊的是不像是 B2C 是一般大眾消費者能接觸到的軟體與硬體，想看影劇就去 Netflix，想去學習新知就去 MasterClass，很容易的從自身角度使用軟體去親自感受優缺點。B2B 面向的既然是企業客戶，企業間通常會有保密協議，宣傳網站上的成功案例更不會描述太多產品細節，這樣我們該怎麼瞭解 B2B 企業呢？

B2B 產業最為特殊的是不像 B2C 是一般大眾消費者能接觸到的軟體與硬體，例如想看影劇就去 Netflix，想去學習新知就去 MasterClass，很容易的從自身角度使用軟體去親自感受優缺點。B2B 面向的既然是企業客戶，企業間通常會有保密協議，宣傳網站上的成功案例更不會描述太多產品細節，這樣我們該怎麼瞭解 B2B 企業呢？

領頭羊有哪些企業

B2B 串流產業有哪些常見企業 - Dacast、BrightCove、Vimeo OTT 、J-Stream、KKStream、IBM Cloud、Roku、Lumen，之所以不說「指標企業」，在於 B2B 通常難以一較高下，畢竟有的公司專注於重度客製化、產品標準化與模組化、如 CDN 或 Player 又或是電視棒的特定解決方案。
就像是拿橘子去比蘋果，同樣是水果但是完全不同產物，很難直接比較，更何況這些企業通常還有些是相互合作的關係。

解讀方式有哪些

一個好 PM 需要更清楚生態系如何生成，可以透過以下方式解讀：

一、財務報告：近 2 年的年報與季報

雖說是落後指標與「官方美化說法」，仍然可以大致且快速瞭解企業的歷史、宏觀的現況、主攻的市場是哪些、利潤與成本來源在哪裡，可以幫助我們知道這間企業「競爭力」的主戰場。

二、服務市場：產業、地區、語系

官網上通常會寫主要在於運動、醫療、金融、媒體等等，通常都暗藏巧思，就是安排的順序代表主要負責的「商業領域」的優先次序，當然這只是通常而已。點選每個產業後，會知道企業對於每個領域如何提供服務，往下拆解成功案例與相對應提供的解決方案。

三、成功案例：成功企業、成功指標

藉由個別的商業領域再度深入研究是哪些「客戶」，如何幫個別企業成功，儘管不會有太多商業機密，還是可以了解「應用場景」。例如我們可以知道 MasterClass 就是由 BrightCove 企業提供服務。

四、解決方案：技術類型、顧問類型

在服務市場與成功案例後，總有個 TA (Target Audience) 知道對象，再來就要了解是提供哪些「產品」或是「系統式的統包方案」， What 幫助客戶解決痛點是什麼，與解決後有哪些對應的改變。

五、定價模型：專業企業合作、SaaS 企業合作

從官網和財報可知道企業的定價策略是面向大型企業、還是中小型企業，每種定價都是怎麼拆出不同的解決方案。

結論

上述看起來複雜，如果用學術的方式就是 3C (Company, Customer, Competitor)、PEST (Politics, Economy, Society, Technology)、JTBD (Jobs-To-Be-Done)、User Journey 這些名詞，名詞提起來不起眼，畢竟每個書本、甚至學校有教過，一旦要落地身為 PM 必須時時刻刻記在心裡，筆者認為越是簡單的工具，有時候越實用，就用在生態系拆解。

這篇文章 如何在 B2B 簡報時獲得客戶青睞？這次讓我們以影音串流產業為例｜專家論點【Mr.T】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

影音串流企業，無論是 Hahow 教育學習類、Netflix 娛樂類、工作用途如企業內訓等類型，終究是面向消費者市場。換個角度，平台供應商所需製作的影內容片與讓消費者使用的平台，要全部從零開始打造所有細節相當困難。

影音串流企業，無論是 Hahow 教育學習類、Netflix 娛樂類、工作用途如企業內訓等類型，終究是面向消費者市場。換個角度，平台供應商所需製作的影內容片與讓消費者使用的平台，要全部從零開始打造所有細節相當困難，細節包含播放器、影片數位保護機制、檔案儲存與上傳管理系統、檔案壓縮技術等等。在消費者平常使用的背後，其實是企業與企業間的相互技術合作、內容授權與工程外包。

B2B 影音創流的合作模式

有別於 B2C 平台的商業模式，讓我們共同來剖析 B2B 影音串流生態系可能的商業模式。

一、平台合作：如 YouTube、TikTok

特性是多為使用者自製的內容，YouTube 就是最典型的 B2B、B2C 兼具的平台，各種各樣的小型 2B 企業商與內容創作者仰賴 YouTube 後台的檔案上傳、直播系統，播放內容。
平常看到木棉花 24 小時不間斷動畫直播、新聞線上轉播、語言教育學習。壞處為越是集中平台，你的掌控權就越小，例如使用者資料、無法定義收費模式等等，也有遇過 YouTube 無故關閉某個數十萬粉絲的頻道，一夜化為烏有。

二、內容合作：如 Hahow、Netflix

Netflix 儘管有自身的影片，很大的片庫更是來自於其他影片商的授權。擅長依靠著巨量用戶的優勢，成功的引進各種內容製作商上架專業製作的影劇，相對於內容提供者需要各種「授權出去」透過二次販賣獲取盈利，魚幫水、水幫魚的互利模式。
通常可發現 UGC 使用者自製內容與 PGC 專業製作內容的合作，往往有不同平台合作的模式。

三、技術合作

有的企業懂自己做網站和 APP、內容自製也不擔心，卻是不知道如何上雲、或是影片技術。此時就有專業的公司如 Azure 雲端儲存、CDN 傳播、DRM 影音保護、Player 播放器體驗、AWS 直播串流、Roku 硬體製造，各式各樣的合作塑造的生態系，我們作為消費者其實難以想像。

四、統包合作

就像是硬體廠商的生態 OBM 品牌廠、ODM 設計廠，軟體業也有相似概念，有的企業只出內容、品牌，至於網站、會員系統、播放器技術等所有細節，全部都「外包」給特定一家或是多家公司。至於願意揭露多少品牌合作的地步，就看合約怎麼簽署了。
第三項技術合作偏向甲方立場且很清楚需要什麼資源、或是偏屬某個專業的乙方技術提供者。而第四項統包合作就偏向外包服務公司、或是專屬串流的顧問服務。

結論

希望到這邊能幫助讀者們能更了解一點 B2B 影音串流不同於 B2C 影音串流，有非常大的不同！於 B2C 影音串流，現在的網路時代，多得是「打群架的共造生態系」，運用彼此的優點在市場上生存。
對於我們 PM 而言，知道這些可以更拓展我們思考的維度與深度，不單單只是思考「做產品」，更要思考「市場為何而生」，產生的競合關係是什麼！

這篇文章 原來 B2B 軟體中的影音串流產業，背後涉及到我們難以想像的企業間技術合作？｜專家論點【Mr.T】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

撰寫文件的種類、迷思、心態建立講起來過於玄妙，這次讓我們來點更實際點的內容。儘管每間公司定義都不同， Mr.T 簡單介紹最常見的 PRD 產品規格文件必須的內容，如何用 5W1H 架構來思考。

撰寫文件的種類、迷思、心態建立講起來過於玄妙，這次讓我們來點更實際點的內容。儘管每間公司定義都不同， Mr.T 簡單介紹最常見的 PRD 產品規格文件必須的內容，如何用 5W1H 架構來思考。

撰寫文件解囊一

1. Why 為什麼：知道為何而生

此產品規格背景敘述絕對不可少，千萬不要成為只負責做產品的打者，而是要想像因為做這件事情，可以對用戶有什麼不同。這很像我們常常聽到木匠建立教堂的故事，動機往往會有短見與長遠目標的差異。例如要製作電商的購物車功能，必要敘述是跟其他競爭對手的不同，以及產品定位在哪裡。

2. Who 用戶與客戶：使用者輪廓什麼

此規格的使用者就像是使用者故事，是誰用你的產品？如果是後台就是後台管理人員、前台的話是跨螢幕使用者、還是需要省時間的使用者等等，定義的狹隘或是廣義即可，重點是要清楚知道是哪個用戶「僱用產品」。
再深入劃分可以用行銷常常使用的 STP，或是我們用國家、產業、語系區分都是不同的模式，這會影響到 Go-To-Market 策略。我們有聽過奶昔的故事，付錢的是父母，其實重點是要服務小孩的族群。

3. What 產品功能：Jobs-To-Be-Done

少了前兩項，這項有可能多做多錯。用戶要完成的使用產品特定功能，具體是需要哪些內容，我們可以分為必要、需要、想要的 KANO 模型思考、以及用開發角度思考 Acceptance Criteria 來敘述、除了加法乘法思維還可以用減法的少即是多的思維。

4. Where 產品在哪裡上架

產品要用在哪些平台 Web/ iOS/ Pad/ 機上盒等載體、適用於哪些版號軟體版好 iOS 14、設計的版型該用 1920*1080 還是 RWD 等都必須要定義清楚。

5. When 產品何時上架

產品預計是哪個 Sprint 要上線、會放在哪個產品路線圖上。與 PM 們在專案管理上如何用適當的工具排序功能有關，思考面向往往是技術優先、商業賺錢優先、使用者需求為優先。

6. How 產品該怎麼做才做達標

如何清楚描述用戶需要的內容，很有爭議，必須大家清楚定義 DoD （Defnition of Done），要包含介面圖、流程圖、技術規格圖才算完成嗎？這些都需要團隊內部有共識。

撰寫文件解囊二

必要之物外，如果有這兩項 1W1H 會更有助於跨團隊的溝通

• Who：需要哪些團隊在什麼時候的協助，例如測試團隊何時需要進來幫忙、產品行銷團隊何時要來協助幫忙哪個功能加強推廣、有沒有可能影響到其他營運或業務團隊的推廣。
• How much：產品的測量數據有哪些，有金錢、點擊率、點閱數，我們怎麼衡量一個功能的成功或失敗，真的不如預期或是造成反效果，什麼時候需要下架。

撰寫文件解囊三

網路上隨處可見中國、歐美的部落格有說明各種 PM 們的思考脈絡，當然也有很多「範本」可以參考，我們要時刻記得的是，有範本很好，但不要被範本拘束，依據實際的組織溝通、產品開發進程而隨時調整，才是好的做法。

小結

網路上的工具源源不絕成千上百種，我們很難熟悉每個工具，或是成為一個工具箱。當然我們不是要立志成為「工具人」，而是要成為「能解決問題的人」，每個工具的應用場景畢竟不同。因此，期望每個專業工作者的思考脈絡都應該有自己的方法論、中心哲學，視情況而變。

這篇文章 軟體業 PM 在產品規格文件的必備小錦囊！一起用 5W1H 架構來思考吧｜專家論點【Mr.T】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

曾經講過 PM 需要撰寫的常見文件與容易遇到的分歧，或許仍然有不少朋友們對於寫文件的認知有不同觀點，對於 Mr.T 而言，期望來分享我們在寫文件時需要有幾個心態建立

曾經講過 PM 需要撰寫的常見文件與容易遇到的分歧，或許仍然有不少朋友們對於寫文件的認知有不同觀點，對於 Mr.T 而言，期望來分享我們在寫文件時，需要有幾個心態的建立！

文件撰寫的心態建立

一、透明化的重要性 - 寫文件不是必須，但不能沒有

為什麼有文件？在大家腦中想像必定不同，同樣口頭一句話也有不同的解讀，白紙黑字寫下來有助於彼此理解，儘管文字上仍然可能有分歧，但藉由圖文表達和撰寫的精細程度，可以幫助我們回溯記憶與減少溝通誤差。
有些人倡導不需要會議、也不需要文件的自組織，只要有共識即可，這我就不同意。因為人數一多，要傳達知識，不是口耳就是閱讀，而透過文件的非同步溝通再重要不過。

二、沒有完美的文件

可以套用敏捷宣言常見的一句話「可用的軟體重於詳盡的文件」，常常聽到期望先寫出好的文件再進行開發，而這觀念就時常常本末倒置，錯過開發的時機、產品上市的時機，或是導致 PM 的文件很常被退件，導致需要時常加班的元兇。此時，重點應該要擺在「大家要到什麼程度才算看得懂」。
我們要將事情從 0 分做到 60 分很容易，從 60 做到 80 分還需要一些努力，但要做到 100 分就需要耗費太多精力與機會成本，先思考，真的有意義嗎？

舉出最明顯的案例，常常是開發人員的卡關可以由一兩句話和在白板上解決，可能會被說「好的我了解，那等你寫到文件上我再來實作，這一次上版就來不及了」，豈不就錯過時機點呢？這關鍵在於大家的合作默契，並不是每次都要忽略文件，而是必要時執行先做、文件後補。

三、文件寫的再好都不一定有人看

建立再完美的索引標籤、再完整的規格文件，都有可能因為數十份文件、埋沒在 Google Doc, Sheet 文件海，而不知道該從何找起。也不能說這樣就不寫。
撰寫文件的好處有兩個，一是為了幫助自己喚醒記憶。如果有分歧也不必過度爭吵，而是大家在同一艘船上，寫的更好；二是知識需要累積與傳承，組織擴大與轉移階段，交接產品和專案時，這就是非常好用口頭搭配文件的手段。

四、規則是死的、人是活的

市面上流傳總是要有 A 文件、B 文件、C 文件曾能行走天下，殊不知如果總是被流程卡死，那我們不就變成「文件製造工作者」？我們必須要不斷保持觀念「文件是誰在看」、「看這文件預期有什麼幫助」、「時間不夠時哪些內容是必須、哪些內容可以後面補上」。

小結

文字其實滿有力量，在撰寫規格文件的過程中，常常幫助我們 PM 發現思考的邏輯缺陷、幫助我們回顧製作產品的細節，對於產品開發前期與當下有幫助，講遠一點，更是有幫助 PM 們在轉職時更能想起「過去自己在做什麼」，畢竟不太可能有人還記得兩年前的此時此刻在做什麼產品、遇到什麼困難、怎麼解決的細節。

另外告訴大家個小秘密，通常大家看完這篇文章，都會頭頭是道，覺得沒錯本來就該如此，今天無論你是身為主管、職員大致都會這麼認為，當事情遇到的時候，往往就會被要求「你這地方沒寫欸，這樣我不做某某事情喔」、「你這地方沒寫唷，這樣不專業吧」，這些諸如此類的現實議題，值得大家思考的課後議題。

如果是你，會怎麼做？

這篇文章 軟體業 PM 在撰寫文件時需建立的4種心態：寫的再好也不一定有人看！｜專家論點【Mr.T】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。

上篇文我們光是隨手舉例文件就有如此百百種，當然 PM 可不是文件產生器，而文件的產生與職責分配為什麼有那麼多分歧呢？期待透過文章可以跟讀者們聊聊有哪些因素

上篇文我們光是隨手舉例文件就有如此百百種，當然 PM 可不是文件產生器，而文件的產生與職責分配為什麼有那麼多分歧呢？期待透過文章可以跟讀者們聊聊有哪些因素！

分歧原因

一、組織人員不足

常見情況在於新創企業，或是中大型企業的新部門，受限於組織規模必須要一人身兼多職，人的時間有限又要做很多事情，事情通常是做廣不做深，如果要做深又一定會捨棄些事情不做。
另外，事情通常沒有做完、也沒有做得完美的時候，我們應聚焦在該如何解決問題，而不是一昧的強調人員不足，站在公司立場，未必有資金聘請足夠的人力。

二、組織認知不同

即使是要完整的工程師、設計師、資料工程師、測試人員等編制，卻還是會遇到情況，發生在於組織成長後卻沒有重新定義「R&R」，處在有人做就好的心態，當然包含了每個人對於職能定義不同。
舉例而言，有些流程只要是「人」，不存在需要必要技能都可以學得會去寫的時刻，往往會有爭執你寫可以、我寫也可以。
例如軟體 PM，我們每次有釋出版本，會投過開發環境、測試環境、前置正式環境、正式環境的流程該怎麼做，當組織有 PM、QA、Release Manager，就會需要良好的溝通彼此定義自己的職掌。

三、溝通效果不足

跨部門團隊的認知常常有分歧，導致一個權力較大的一方往往不寫文件，將責任推給其他部門，例如工程師可能會說寫程式就沒時間，當然是 PM 要負責寫，這時會發生 PM 不了解技術細節，又要開會當工程師的窗口來撰寫文件。延伸而來，就會期望有技術背景的 PM，更嚴重就是直接讓技術 PM 看程式碼寫技術文件，這豈不就讓 PM 的職掌超出範圍，本末倒置。

曾經筆者就有遇到朋友是作為軟體 PM，卻要寫資料庫欄位定義書，向組織人員反應卻會被提及「你會做那你可以先做」、「PM 最好懂一些順便做一做」、「該開發人員不想做」、「該開發人員做的品質不好」等相關緣由，變得自己成為技術文件產生器。

我們可以這樣做

真的遇到這些事情時，PM 們、設計師們、工程師們總是帶有點焦慮或生氣，上演了踢皮球大戰，這時候作為專業工作者，雖然有適度情緒是必要，但我們是來解決問題，而不是製造問題，遇到這些事情，我們可以這麼做：

1. 掉球－先接手，後轉手，沒人做，就會是開發的卡點，可以先到自己手上，但要不斷的上上下下表明未來一定要由更專業的人做。
2. 被迫接球－避開沒必要的爭執：針對原則爭執而沒有範例沒有意義，更何況跟自己的主管對立通常沒有好事，因此可以先做了之後，大家一起發現問題，就會知道該怎麼交手才是好的方向。雖然要花比較多時間，但總歸有效。
3. 選擇性接球－大家說都可以的時候：這時先評估「自己有沒有時間做」，或是跟組織討論真正的問題發生在哪裡，再來釐清有無替代方案。通常我們遇到問題，不要先想解決方法，而是去想問題背後的問的 QBQ ( The Question behind the Question )。

小結論

聽到此，期望大家未來在寫文件時，能夠把玻璃心撿起來，好好思考文件為何而生、為何而寫。除非自己的職涯想要成為專業的 Technical Writer，就不要讓文件成為你日常工作的大部份卡點。當然更不是鼓勵大家都不寫文件，未來會跟讀者們說明文件還是有期必要，作為 PM 或是專業工作者是避免不了。因此，期許我們一起成為更專業的工作者。

這篇文章 軟體業 PM 常見的踢皮球大戰上演在這邊！面對3大問題可以如何解決？｜專家論點【Mr.T】 最早出現於 科技島-掌握科技新聞、科技職場最新資訊。