從認知-判斷-執行模型，聊聊優秀SaaS產品經理應該具備哪些能力

去年吳曉波曾在一場演講中説：“我會把2020年稱為中國企業服務的元年。”的確，由於疫情的關係，2020年企業協同辦服務浩浩蕩蕩進入公眾視野，釘釘、飛書、企業微信等產品扶搖直上，與此同時，推進了整個SaaS行業的迅速發展。例如，一些依託於釘釘的SaaS公司2020年收入漲了3倍以上。

中國的SaaS行業，確實是近幾年才開始快速發展起來，這中間還有產業互聯網概念興起的功勞。作為一個SaaS產品經理，很幸運我見證了這幾年這個行業的日新月異，也看到了一些想進入這個行業的同行們的困惑——SaaS產品經理應該具備哪些能力？今天我想來談談對於這個問題的看法。

無論是B端還是C端，產品經理都是擔起對產品進行規劃和管理職責，創造用户價值和商業價值的那個人。我認為一個優秀的產品經理宏觀上要能深鑽行業，洞悉大勢；微觀上又能不驕不躁，寫好每一個PRD，畫好每一個原型。因而我認為產品經理的能力模型可以抽象為“認知—判斷—執行”。

• 認知能力：指人腦加工、儲存和提取信息的能力，即人們對事物的構成、性能與他物的關係、發展的動力、發展方向以及基本規律的把握能力。
• 判斷能力：判斷能力是人在思維的基礎上對事物進行分析、辨別、斷定的技能和本領。
• 執行能力：執行力就是一種把想法變成行動，把行動變成結果，從而保質保量完成任務的能力。

其中“認知能力”決定產品經理的能力上限，“判斷能力”代表認知深度和專業度，而“執行能力”則是產品經理的基礎能力。

一、認知1. 認知SaaS

SaaS是Software-as-a-Service的縮寫，意思為軟件即服務，即通過網絡提供軟件服務。目前SaaS產品主要分為三大類：行業 SaaS、職能 SaaS 和通用 SaaS。

• 行業 SaaS 是解決垂直行業的一攬子需求，如地產行業的明源雲、餐飲行業客如雲等。這種類型的產品，具備高度的行業屬性。
• 職能 SaaS 是解決企業裏模塊化的需求，具備泛行業化、聚焦特定場景的特點，如EHR領域的北森、i人事；CRM領域的紛享銷客、銷售易等。
• 通用 SaaS 則不分行業和職能，如 tapd、釘釘（辦公協同），企業微信、飛書等。

SaaS公司為客户提供產品服務的交付方式主要有以下三種：

• 項目交付：case by case，以項目實施方式進行交付，也就是傳統的私有化部署的形式。
• 標準化產品解決方案交付：主要是以公有云的方式，為客户提供標準的整套系統解決方案。這也是SaaS公司最主要、最理想的交付方式。
• 以aPaaS技術能力進行交付：通過低代碼、零代碼的方式提供技術平台，藉助可自由配置的字段能力、流程引擎能力，由甲方it人員或公司運營人員配置成系統解決方案。

從這裏就能看出，SaaS的行業經驗壁壘相對較高，對產品經理提出了非常高的要求。具體到工作中不僅需要產品經理對整個行業有一定認知，也需要對自己產品的垂直領域有深入的瞭解。

1）SaaS的商業模式有哪些？

SaaS的商業模式是通過規模化服務客户來攤平自身公司的運營成本，從而獲得營收。

其營收公式= （SaaS客單價*客户數量）-公司運營成本。因SaaS不是一次性付費，而是訂閲續費模式，如果要保障自身一直有營收，其核心指標為租户的續費率。

目前，我發現國內有些公司已經有基於SaaS模式產生的一些新的商業模式。主要有兩類：

• 平台衍生類服務：如易訂貨，產品是為中小商家提供採購管理的SaaS產品，這一產品連接供銷兩端（採購方和供貨方），具有供應鏈平台型產品特質，因而在累積了大量用户後，形成了自己的平台生態，易訂貨在此基礎上衍生了為中小商户提供的金融貸款服務。
• 產業服務改造類：如面向C端用户的APP小豆苗，產品核心是為C端用户提供預約接種服務。為了挖掘新的增長點，更好地服務用户，入局產業端衍生了為中小社區診所提供的SaaS產品。

2）為什麼這些年SaaS會備受追捧？

如果對國外互聯網比較瞭解的同學不難發現，國外互聯網頭部公司大多都是to B，如微軟、IBM等；而國內互聯網巨頭公司目前都還主要是to C。

隨着移動互聯網的下半場接近尾聲，C端已成紅海，但國內產業互聯網還有巨大的藍海市場，加之去年疫情的加速和國家的倡導，更是催化了大量的to B公司。我們可以看到越來越多的to C公司在佈局B端，像BAT、頭條等。

在目前B端服務IaaS、PaaS、SaaS三種模式中，SaaS是距離客户最近的模式；同時SaaS模式本身天然具備兩個優勢：

1. SaaS公司在續費率足夠高的基礎下具備穩定的客户羣體，穩定的現金流；
2. 隨着SaaS產品的打磨，產品的標準化能力越來越來強，具備越來越強規模化能力的同時，產品接入的邊際成本也越來越低。公司毛利率可以逐年遞增。

SaaS這一商業模式不僅有穩定的客户羣，還有逐年遞增的毛利率；同時還存在和傳統行業結合迸發出產業互聯網的巨大想象空間，這就是為什麼這幾年SaaS被資本火熱追捧的原因。

3）什麼樣的市場適合切入SaaS的模式？

如果我們選擇創業或公司要向SaaS轉型，在拋開外部市場競爭的情況下，必須考慮要進入的賽道，其市場規模是否能夠覆蓋公司運營成本。其中市場規模=客户付費能力*客户付費意向*客户數量。

那什麼樣的市場適合SaaS切入？

橄欖型市場：

最適合SaaS模式切入的是橄欖型市場，即頭部客户少且數量規模一般，腰部客户眾多，長尾客户少。

國內頭部公司，普遍會有數據私有化、服務定製化的需求，SaaS公司接入過多很容易進入“項目制”的陷阱，走上和軟件實施公司一樣的“不歸路”。

而行業內尾部客户因處在“生死邊緣”，存活時間短（中國公司平均存活時間2年半），付費意願和付費能力都較差，且具有非常高的死亡率，與此同時，還需要對新入行的長尾客户不斷投入獲客營銷成本，投入產出低。所以腰部客户是SaaS最理想的客户羣體。

這裏要特別關注的一點的是，在目前國內激烈競爭的商業環境下，中小企業付費意願極低，每分錢都要花在刀刃上。因此如果一款SaaS產品對於中小企業而言不是剛需（一般距離花錢或盈利業務越近，“剛需”程度越高），那這個市場規模也難以讓SaaS公司盈利，這也是為什麼市場上有很多SaaS公司“叫好不叫座”的根本原因。

客單價高的市場：

在一些馬太效應嚴重的行業或一些GMV過萬億的行業，也存在SaaS的機會。

讓我們迴歸這個公式：市場規模=客户付費能力*客户付費意向*客户數量。如果客户數量規模一般，但客户付費能力和付費意向極高，也是有足夠的獲利空間。具我所知，市面上就有幾家類似的SaaS公司活得比較滋潤。

但我認為這種市場，最佳的交付方式不是純SaaS交付模式。因為在馬太效應嚴重的行業（或者是客户 “錢多多”的行業），大多為頭部大型企業。前面提到，這種企業或多或少存在一些定製化需求，很容易讓SaaS公司走進“項目制”的陷阱。目前，國內面向這種市場的SaaS公司，其解決方案主要是以“項目制+SaaS”，或“aPaaS+SaaS”的方式交付（後續有機會跟大家聊聊SaaS公司要不要做aPaaS），這其實很考驗公司對頭部市場需求的把握能力和戰略定力，很容易“一不小心”就變成了軟件實施公司。

2. 認知SaaS產品

1）SaaS產品和普通to B產品有什麼區別？

前面提到，SaaS商業模式的本質是通過服務規模化客户數量來攤平自身公司的運營成本，從而獲得營收。對產品側的要求是能解決規模化客户的需求，這是與普通B端產品最大的不同。

因而SaaS產品必須具備兩種能力：

• 業務系統能力：具備解決客户特定需求的能力；
• 標準化能力：具備支撐規模化客户數量的能力。

與之相對應，SaaS產品經理需要具備：

• 業務系統能力。因為SaaS一定會有很強的“業務”屬性。如果你去EHR SaaS公司求職，公司一定會要求對EHR領域有一定的經驗要求；如果你去求職垂直行業，比如房地產SaaS公司，一定會要求對房地產行業有較深的理解。因為只有對行業足夠深入瞭解了，具備高屋建瓴的前瞻性，瞭解行業發展趨勢和變化，才能打造出好的SaaS系統，為客户創造價值。
• 標準化能力。因為產品的本質是通過規模化來攤平成本，你在產品設計過程中製造的“重構”缺陷越少，你的團隊研發成本越低，標準化的能力越高，越能降低公司成本。而這種能力需要具備極強的行業理解能力和抽象能力，後續我會在在“判斷篇”進行説明。

2）SaaS產品的生命週期是怎麼樣的？

和其他的產品一樣，SaaS產品也有生命週期，吳昊老師的《SaaS創業路線圖》會有更清晰的解答，推薦給大家閲讀，老花生就不在此贅述了。我來重點和大家聊聊SaaS產品MVP階段和C端產品的差異點。

C端產品MVP流程。如下圖所示，

在產品規劃設計中，C端產品需要不斷為用户提供價值，用騰訊的話來説，“一切以用户價值為歸依”。假設你的產品終極價值是要幫助用户更快到達某地，那在MVP版本設計時，你需要做的就是交付更小成本、更快到達某地的工具。從產品功能層面來講，你需要確保交付產品每個版本的完整性、可用性。就如上圖所示，要給個滑板而不是車軲轆。

而B端SaaS產品MVP階段，如下圖所示：（ps請忽略我畫的只有4個版本的汽車..）

在用户價值層面和C端是一致的，也是需要幫助用户更快的到達某地。

但需要注意的是，在產品功能設計層面，如果產品終極價值是要給幫助用户更快的到達某地，而現階段受限於技術實現，最快的交通工具只能是汽車時，那你就必須造車。而不是一開始交付滑板，然後是自行車。如果你這麼幹了，那後續每次版本迭代都是一場“重構”災難。

二、判斷

判斷力實際是依附於認知能力之下的，認知不對則判斷有誤。落地到實際工作層面，一個產品經理的判斷力體現他對需求真偽、價值、優先級的判斷。

1. 判斷需求

在一般SaaS公司的架構下，B端產品經理普遍離客户有些距離，一般中間會夾雜着“客户成功”這一角色。因此目前B端產品大部分需求來源於客户成功同事轉述過來的需求。在這個過程中，存在着大量信息失真的情況，因此saas產品經理經常要做一件事情——判斷這個“需求”是不是一個需求中，存在着大量信息失真的情況，因此saas產品經理經常要做一件事情——判斷這個“需求”是不是一個需求。

1）接收到的是不是一個需求？

人們在現實世界中，往往都是下意識反饋解決方案的。比如朋友跟你説，你拿下錘子和釘子給我，如果你不進行深入挖掘，把錘子和釘子理解為他的實際需求，是無法挖掘到他的真實動機其實是要掛結婚照，而也許我們可以提供比錘子和釘子更好的解決方案。所以產品經理在日常的一些需求list中，要注意去區分什麼是客户的真實需求，什麼是客户自己提供的解決方案。

行業內早有範式對需求進行了規範，如果你能形成這種思考習慣，就能很容易跳出解決方案桎梏。範式如下：

作為【特定的角色】，需要一種方法來【滿足xxx需求】，然後【用户直接受什麼益】

我們按照上文的例子代入。

作為已婚人士，他需要一種方法來 讓他的結婚相框掛在牆上，然後 讓他時刻想起婚姻的甜蜜。

我們再舉個例子：你的客户跟你反饋，我需要在系統後台的首頁上看到，今天店鋪一天的彙總交易數據。

按照這個範式。

• 錯誤的方式：作為店鋪老闆，我需要一種方法 在後台首頁看到最新數據，然後快速瞭解今日店鋪經營情況。
• 正確方式：作為店鋪老闆，我需要一種方法 幫助我快速瞭解店鋪經營情況，然後 我有更多的時間做其他更重要的事情。

這個範式最好的地方是，特意將解決方案縮略表述成一種方法，為的是讓你聚焦在需求的同時，還能開闊你的思維。避免被框定在具體的解決方案中，進而可以瞭解到客户的本質需求。

就拿上面這個例子而言，如果你思考的是錯誤方式，你的思考範圍一定是想着在後台首頁增加什麼類型的數據，怎麼加入數據的問題。如果你思考是正確方式，我想你一定會挖掘出更好、更優的解決方案。

2）判斷需求的合理性

在B端的產品設計中，產品經理會遇到一些需求對於某個角色而言，是合理且可行的。但是這個需求對於組織或者其他角色有一定的利益損害。這時，就需要產品經理有較強的利益權衡能力。

在to B行業內，有一個老花生不是太認可的產品“流派”：TO BOSS流派。他們認為，在B端產品設計中，一定要優先注決策者的需求而非使用者，BOSS就是典型的決策者。當然我覺得TO BOSS在大多時候都沒有什麼問題，畢竟成單和續費的決策都在BOSS上，這無可厚非。但凡事都需要有批判思維，需要辯證的去看待決策者的需求。

舉兩個例子：

第一個是去年疫情期間，有些營銷SaaS公司，為了滿足BOSS需求，推出了全員營銷功能，幫助BOSS更好的去監控員工帶來的客户量，甚至將該功能當成亮點功能推向市場。

我對於這個事情的看法就是，沒有權利就沒有義務，員工與公司應該是雙贏的模式，如果只有單方面的員工義務，公司也必然會在某些方面有着看不見的損失，這並不是長久之計。

第二個例子是前年的時候，我們產品上遇到一個類似的需求，當時業務方為了更好地瞭解到店客户畫像，要求業務員填寫全部到店的客户印象資料，要求完成度達90%以上。對於業務員來説，如果當日到店客户較多，這基本是一個無法完成的事項，而且相當多的印象資料信息對於業務員而言，無任何實質性幫助。

當時我們也是基於BOSS優先的邏輯進行了產品設計。在產品運行了一段時間後，我們發現了2個嚴重問題：

• 第一是業務員出現了極大的不滿的情緒，甚至開始抵制使用產品；
• 第二，因為印象填寫本就主觀，出現了大量業務員隨意填寫的數據，不僅背離了當初對到點客户進行畫像分析的初衷，還產生了大量垃圾數據。

通過上述例子可以看到，to B的產品設計中，想要產品具備長久的生命力，必須要權衡整個生態環中各個角色的利益平衡，而不是一味從決策者的視角進行設計。

3）判斷需求優先級

需求優先級判斷是產品經理的日常工作之一。如果排除一些特殊原因，如boss指定、政策要求等外，我一般會遵循投入產生比來進行判斷。

ROI = 需求價值 / 需求實現投入成本

需求價值= 用户數量 * 場景頻次 * 場景重要程度 * 用户效用

（其中用户數量一般是看這個需求涉及的用户規模）

曾經有一個同事告訴我，他了解到騰訊微信上，只要有任何一個小小的改動，都需要經過張小龍進行方案評審並確認，而且經常是做的方案多，通過的方案少；而在我們公司，有大量的功能只需要做到組內內審，即可通過。為什麼我們不像微信一樣做？

其實認真想想就能明白，因為彼此產品的用户量，差了近幾十倍，用户完全不是一個量級，需求價值大小也不一樣。

不知道大家有沒有發現，有些優秀的產品在一些異常場景的處理上，處理的也不盡人意，只是預留了人工介入的入口。其實原因是場景發生的頻次過低，需求價值太低。

而對另一些產品來説，即便場景發生的概率是萬分之一，也是需要介入進去滿足需求的，這又是為什麼呢？究其原因，主要是這個場景對於用户來説，極其重要，就像我目前在處理的交易環節，任何細節上的異常流程，即便發生概率極低，都是需要去介入解決的。

在需求實現投入成本上，這個就需要產品經理具備一定的技術理解深度。一般來説，有一定技術理解和很瞭解系統實現的產品都能有一個大概投入人力、研發時長的判斷。

2. 判斷方案

需求確定的情況下，解決方案的優劣判斷也極其重要。對於SaaS產品而言，產品標準化是極其重要的能力之一。SaaS產品經理一定要對解決方案心存敬畏，如果你在過往設計中，設計了“帶病”的方案，那麼一定會在後續的產品迭代中給你帶來諸多困難，甚至把公司拖入泥潭。

那如何判斷解決方案是否可行？可以從以下兩點進行判斷。

1）解決方案是否可以滿足用户需求

方案是否可以滿足需求，可以代入用户視角，查看方案是否能滿足需求，這基本對用户有較深的瞭解的都能進行判斷。

2）解決方案是否具備可擴展性和普適性

可擴展性和普適性需要產品經理要具備極強的抽象能力，能理解業務模塊的邊界和關聯關係，像B端產品經理經常接觸的後台權限RBAC模型就是經典的產品抽象模型。下圖是一個電商促銷的產品模型，因為這塊過於抽象，有機會再跟大家聊聊怎麼設計。

但解決方案的判斷上，不僅僅只要求產品經理會抽象建模就行了，還需要產品經理具備很好的抽象粒度的把握能力，避免出現過度設計。

過度設計（over-engineering）是指設計出來的系統複雜臃腫，過度封裝、一堆繼承、接口和無用的方法，超複雜的xml配置文件。簡言之，客户需求是要一把殺雞的刀，你給設計了一把牛刀，殺雞焉用宰牛刀？

舉個例子，有一些C端運營後台或者是輕量型的後台，其權限設計特別簡單，甚至不進行對應權限的控制，如果你作為公司的產品經理，一定要將最複雜的RBAC（3）那套權限模型運用在你的後台，這就是明顯的過度設計。

那如何判斷是否存在過度設計？就是拿最常見的場景代入查看，如果配置或操作會變得異常複雜，那可能存在過度設計。

三、執行

大家應該不難發現，現在市場上因對產品崗位的理解不同，對產品的要求也不一致。像一些傳統軟件實施公司，對於產品經理的要求一般只需要進行需求管理，而在一些新興互聯網公司，普遍還會要求產品經理兼任一部分項目經理的職責。

產品經理的主要職責還是進行需求管理，今天我們主要聊聊這個部分。

以一個需求的挖掘到上線來為例，一般常規的互聯網軟件協作流程如下圖所示：

以上這些流程中，產品方案設計是產品經理專業能力的具象體現，在這裏我就重點介紹下產品經理在產品方案設計時需要具備哪些技能。

我們主要是基於用户體驗五要素的方法進行對應的方案設計。可能很多同學對這個方法很熟悉了，但實際工作中能按照五要素進行拆解和設計方案的產品經理真的為數不多，甚至有些“老手”都無法理清楚自己的PRD是如何對應五要素的。

用户體驗五要素如下圖所示：

1. 戰略層

設計戰略層的時候，需要產品經理能清晰地回答兩個問題：一是“用户通過產品能獲得什麼價值”，二是“我們能從產品中獲得什麼”。用俞軍老師的話總結來説，產品是用户和企業交換價值的載體。

而戰略層一般對應PRD中的背景説明。

以後台權限管理模塊的方案為例。戰略層就是：

• 用户可通過權限管理模塊，靈活地進行權限配置，以便保障業務信息安全和業務正常運轉；
• 我們能從這個產品模塊獲得客户對系統功能的認可，提升客户滿意度，從而提高產品在市場上的競爭力。

往往很多產品經理，因為對戰略層的不清晰，導致整體的產品設計偏離戰略層，致使一份“無效”產品方案的產生。

2. 範圍層

範圍層的定義是指產品涉及的範圍，其中包含產品邊界、功能的範圍，用户需求的範圍等。而範圍層的設計極其考驗產品經理的能力，既需要考慮怎麼樣的範圍能完成戰略層產品目標，又需要對用户的需求有着極強的把握。

如果產品經理對範圍層沒有很好的理解，在產品設計上就很容易產出一些“大而全”的產品解決方案，這種方案如果單從正確度和完整度層面講，是沒有什麼問題的，但就是無法回答“why now”這一問題，會讓研發團隊耗費大量的時間在處理一些在當下價值低功能，從而白白錯失市場機會。

關於範圍層的判斷，就拿我之前設計的一個從0-1的小產品模塊——“CC筆記”為例吧。

CC筆記功能背景：

我們發現一線業務人員，在已經給到產品官方介紹資料的情況下，還會自己用微信筆記（微信自帶功能，類似有道雲筆記，主要功能是可以自由編輯圖文、視頻和插入地址）重新整理產品介紹資料，通過微信轉發給到目標客户。

我們深入瞭解後，發現業務人員覺得是官方介紹信息過於“官方”，不夠具備用户視角，目標客户查看時需要二次信息轉換。其中存在兩個問題：

• 第一，因為使用的是微信自帶功能，轉發給目標客户後，無法獲知客户是否打開查看，也無法進行獲客。
• 第二，業務員的管理者擔心無任何約束的產品介紹，會存過度宣傳的可能，有較高的內容風險。

那我們在設計的的時候，考慮到第一個版本，先要完成CC筆記的替換。對戰略層的定義：

• 對用户而言“一線業務人員在CC筆記功能上能體驗到和微信筆記一樣的功能，並可以獲得客户相關瀏覽數據，幫助業務人員瞭解目標客户關注點，促進成交”。
• 對於這一版本而言“我們通過最小mvp版本完成CC筆記對微信筆記功能的替代，提升我們產品的使用率”。

在需求明確，且戰略層清晰的情況下，接下去就是如何框定產品範圍。

CC筆記功能要完成微信筆記的替換，在產品價值公式上，需要產品價值=（CC筆記功能價值-微信筆記價值）-替換成本 > 0

因為當時我們的產品載體是微信小程序，從操作體驗上來看，非原生CC筆記功能是無法超越微信筆記的，在這個公式中，CC筆記功能價值 = 自有編輯的能力 + 數據能力。其中CC筆記自有編輯能力是短板，那策略上通過強化數據能力和降低CC筆記到微信筆記的替換成本，從而促成產品價值>0。

在數據能力的設計上，我們希望能做到客户在瀏覽CC筆記內容時，抓取客户在每個內容上的停留時間，從而更好的幫助業務人員瞭解每個客户感興趣的內容點。

當時我們產品並不具備這麼強的數據採集能力，和研發同事一起評估確定這個功能研發週期相當長，於是在數據採集上做了妥協，功能範圍只完成了客户大粒度數據的採集，如單篇筆記的閲讀時間、打開次數、打開時間等等。

在降低替換成本的設計上，因考慮到大部分業務人員已有編輯好的微信筆記，主要考慮支持兩種方式：一是微信筆記轉成長圖後上傳至CC筆記；二是支持微信筆記的內容複製，粘貼到CC筆記上。

最後我們框定的範圍情況如下：

第一版本，主要聚焦完成CC筆記的替換；第二版本支持到管理員審核，規避內容風險。後來我們進行了2個項目的試點上線，運行了兩週後，發現數據不如預期，只有極少部分業務人員完成了筆記創建。通過數據分析得出主要原因還是替換成本過高，很多業務員粘貼編輯過程中出現了很多問題。

通過這個例子，大家應該能感受到功能範圍把握的不易，我自己對功能範圍的總結就是，一定要緊緊結合戰略層，戰略層之外的功能一定要堅決移除；框定範圍內的功能，一定要能滿足用户的需求。

如果重新來框定一次範圍，我會修改成下圖所示：

圖中黑色部分為修改部分，我會將一些其他類型的分享，進行移除，只保留核心分享功能。對於替換成本，採用管理員給業務員預設模板來降低微信筆記的替換成本。

後來我們也通過後台預設模板這一小小的功能改動，成功將CC筆記變成了業務員最喜歡的功能之一。

3. 結構層

對於非信息型產品來講，結構層主要交互設計。產品經理更多需要考慮怎樣的交互可以使用户滿意？市場上主流的用户操作習慣是怎麼樣的？你的目標用户羣體主流的交互流程是怎麼樣的？能不能通過交互設計降低用户對功能的認知和減少用户的誤操作等等。

4. 框架層

框架層的設計，一般已經聚焦在某個功能頁面之上了。在設計時需要通過框架的劃分，幫助用户優先看到他想看的內容。目前的互聯網職能劃分下，一般UX/UI同事會進行對應的設計，此處就不贅述。

5. 表現層

在目前的互聯網產品設計，主要是視覺設計，一般產品方案不涉及到這一層。

作者：老花生，5年SaaS產品經驗。現地產營銷垂直行業，有微信生態營銷和豐富的B端0-1產品經驗。

本文由 @82年的老花生 原創發佈於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議