中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

在國內，同已經比較成熟的企業內部工具或 SaaS 產品來說，低代碼還是比較新的領域。作者結合自己的實戰經驗，從五個維度與大家探討關于低代碼的業務操作思路，希望對你有所幫助。

聲明：本文所有觀點，僅代表個人

前幾天的春季發布會上，飛書正式推出了業務三件套，其中就包括飛書自研的低代碼平臺：飛書應用引擎。

恰好至今年 3 月 9 日，我加入字節跳動整整一周年，也在飛書做低代碼產品整整一周年。在我們圈子有一句話，叫做字節一年，人間三年，以此來形容字節跳動工作的繁重和壓力。

對我來說，這漫長的一年確實有許多值得回顧和復盤的地方，雖然在一年的時間節點上幾乎沒有任何儀式感，因為一直有下個重要的任務等著你去完成，但從個人成長的角度來說，這個特殊的節點是值得紀念的，而紀念它的最好方式，莫過于寫下這樣一篇文章了。

我知道字節、飛書、產品經理，都是互聯網圈子里的流量詞匯，在許多自媒體或是職場社交平臺，都能看到與之相關的內容。但這篇文章并不會將過多的筆墨放在字節、飛書、職場、大廠的話題，我會更關注我在這一年的真實收獲，那就是在做低代碼產品這件事上的收獲。

為什么呢？

在字節跳動這樣一個超大型組織內，每天都會有很多事情剝奪你的精力，平臺的光環也好、盛傳的裁員危機也罷，這些消息就像精神鴉片，吸食起來很爽，卻幾乎沒有益處。

相反的，你正在做的事情，事情背后體現的能力，能力背后蘊含的基本功，反而是每天忙碌的會議背后，更容易被忽略的東西。對個人來說，這些東西才是我們在平臺之外所獨有的，真正屬于我們自己的東西，說白了：

這是可以帶走的東西。

一、關于產品

我在飛書做的是低代碼產品，雖然這個領域在大類上屬于 to B 產品，但同已經比較成熟的企業內部工具或 SaaS 產品來說，低代碼在國內還是比較新的領域。

這個「新」體現在：

1. 不同公司對低代碼的理解和策略可能都不一樣，沒有一個成熟而公認的從 0 到 1 的演進模式，產品的形態基本都跟公司對低代碼的定位有關；
2. 少有成熟的方法論可借鑒，只能從現有的產品去倒推底層的產品設計理念；
3. 圈子很小，5 年以上的低代碼產品經理很少很少，招聘候選人很多是 B 端其他業務領域的產品，或者是國外 PaaS 平臺的產品（如 Salesforce）

這些也導致我們在做這款產品的時候，也面臨了很多的不確定性。

在這種不確定下，必然會導致討論→結論→推翻→討論的無限循環，這對于一線產品經理來說某種程度上是一種消耗和傷害。

但另一方面，也正是在這樣的無限討論中，我們才能對自己所做的事情有更多理解，更深刻地認識到它的價值和做事情的正確方法。

在這一年的時間里，我從完全不了解低代碼，到開始能用低代碼平臺搭建應用，再到逐漸了解每個平臺背后設計的理念，這其中最深的感觸只有一條，我姑且把它叫做：用戶分層。

二、用戶分層

凡是做產品經理的，一定會對一個問題非常敏感：我們的用戶是誰。而對低代碼產品經理來說，這個問題又顯得稍微抽象一些。

廣義上，低代碼的用戶是開發者，但開發者是誰，他們和企業的關系是怎么樣的，低代碼又如何為他們提供了不可替代的價值，這些都是我們在做這款產品時，需要去思考的問題。

經過一年的探索，我發現去研究開發者這個群體時，也需要用到用戶分層理論。

我最早接觸到用戶分層，是在美團做會員產品經理的時候，無論是 VIP 體系，還是等級體系，本質上都是按某種標準對用戶做分層，目的是在不同的層次下，匹配不同的功能和資源，從而達到整體收益最大化。

開發者也同樣需要并且可以分層。這個群體大致可以分為三個層次：

1. 無代碼開發者

典型畫像是中小型公司內的業務人員，他們的訴求是希望通過一款好用的工具，快速搭建出一個業務系統。

這種業務系統一般是經典的四件套：數據表格、詳情、表單和報表，例如最簡易的圖書借閱系統。包括所有圖書的列表、單本圖書的詳情、借閱申請表單和借閱數據統計，再輔以簡單的審批流程和權限控制，基本上就能搭建出一個最簡單的圖書借閱管理后臺了。

大多數無代碼開發者很少具備寫代碼的能力，因此提供給他們的產品需要足夠好用，易用性需要足夠強，才能被他們喜歡。

具體來說，在產品設計上，既需要保證一定的抽象性，功能不能太定制化，否則就偏離了 PaaS 的定位，同時也要屏蔽開發者無需感知的功能細節。

以按鈕的樣式配置為例，對無代碼開發者來說一般需要的是封裝好的快速的樣式配置：藍底白字無邊框的按鈕，一般用在強提示場景下，例如表單的提交；白底黑字有邊框的按鈕，一般用在弱提示場景下，例如頁面的返回。

如果我們將按鈕的 CSS 樣式全部開放給無代碼開發者，他們可能會覺得沒有必要且非常難用，因為他們的業務系統對靈活性要求沒有那么高。

但這樣的限制在某種程度上也同時限制了業務系統本身的天花板。

2. 混合開發者

典型畫像是大型企業里的業務人員，他們一方面渴望一個好用的應用搭建系統，另一方面希望這個希望滿足一定的靈活性，哪怕是通過寫部分簡單的代碼實現。為此，也要求 他們懂得一些基礎的編程知識。

對大型公司的復雜業務系統來說，完全無代碼的搭建幾乎很難滿足自己的需求，而對公司內的業務人員來說，完成比完美更加重要。

他們更看重的是能不能實現，其次再是體驗好不好。對他們來說，如果能力上無法實現，即使產品再好用，價值也等于零。

對這部分開發者，在產品設計時需要盡可能避免黑盒邏輯，盡可能白盒化展示。更通俗一點來說，從易用性出發，需要做一些邏輯封裝，但這種封裝邏輯需要在產品上展示出來，最終目的是方便開發者可以自主修改。

還是以按鈕的樣式為例，在產品設計時既要考慮將通用的 B 端業務領域經驗沉淀為快速的封裝配置，同時這種封裝邏輯的底層應該是原子化的。

例如，對強提示場景下的「藍底白字無邊框」按鈕來說，這種封裝應該體現為「背景 = 藍色」、「文字 = 白色」、「邊框寬度 = 0 px」等原子化配置。開發者在 90%以上的場景下不需要關心底層的邏輯，但是需要修改時，例如「公司內部的設計規范要求，強提示場景下的按鈕必須用黃色」，可以快速進行修改。

與無代碼開發者相比，給混合開發者提供的產品功能在天花板上是更高的，但因為暴露的產品細節也要多很多，因此在易用性的設計上挑戰更大。

但有一個原則我認為是需要達成共識的，對這部分用戶來說，他們往往并不喜歡黑盒邏輯，他們的訴求是：

我可以不用，但你不能不告訴我。

3. 低代碼開發者

典型畫像是獨立軟件開發商（Independent Software Vendors）的 IT 人員，他們對平臺的要求是提供最大程度的開放性。他們日常的工作是基于低代碼平臺提供的能力去做二次開發，對他們來說，大部分的應用搭建過程其實還是寫代碼的過程。

這類開發者往往基于低代碼平臺去構建復雜的業務系統，包括 CRM、ERP、HRS 等常見的 SaaS 產品，都有可能是 ISV 基于低代碼平臺開發完成的。

面向這類用戶去做產品設計時，往往需要考慮更底層的通用性，有時候甚至是代碼級別的通用性。舉幾個例子：

平臺自帶的數據模型模塊和外部數據源，能否作為一個統一的數據查詢端口供前端頁面調用，這種情況一般發生在系統遷移中。復雜的業務系統遷移很多時候是頁面先行，數據基座不變。

如果客戶公司有一套獨立的組件設計規范，那這套規范在接入低代碼平臺的同時，能否復用平臺已有的組件能力，包括屬性、樣式、事件、動作、方法等能力。

這些復雜的場景都需要產品經理在設計某個模塊的時候，前置地去考慮更多開放能力的接入，而這對低代碼產品經理的考驗是巨大的。

甚至，可能只有產品架構師才能完成面向低代碼開發者的產品設計。

如上可得，即使我們的用戶都叫做開發者，但這個群體的角色、身份、所在公司不同，對平臺的訴求是不一樣的，沒有一套統一的標準可以描述低代碼產品應該怎么做，原因大概就在這里。

三、關于方案設計

做低代碼產品，對需求文檔的要求非常高。

復雜的需求文檔，一般會有兩個階段：1、需求概要；2、需求方案描述。

在需求概要中，產品經理需要描述清楚問題的背景和價值、競品調研、核心方案。

背景和價值說明了為什么要做這個需求，為什么要在現階段做這個需求。低代碼產品的技術復雜度很高，因此說清楚需求的價值無論對于資源的分配，還是后期的跨團隊協作，都是十分重要的事情。

在這一年的時間里，我也經歷過著急忙慌地把需求方案趕出來，最后因為沒有對齊價值，導致在評審會上被質疑，最后使得需求被降級或取消，這樣的事情對產品經理來說是非常致命的資源浪費。

在價值證明階段，最容易出現的矛盾是產品自身的規劃與用戶反饋之間的沖突。例如在很早期的階段，低代碼產品大多都很難用且天花板也比較低，共創客戶可能會有非常多的負向反饋。那這時候，到底是先提升能力還是先提升體驗，就非常考驗產品 leader 的判斷能力。

很多人會說，就不能「既要也要」么。

如果資源充足，當前可以。

但經濟社會的常態就是「資源永遠稀缺」，否則就沒有成本的概念。當一個選擇一定伴隨著成本時，優先級的抉擇就成了產品經理每天要面對的最大矛盾。

當價值確定了，該怎么做就成了第二個問題。

中國的低代碼市場整理來說起步較晚，2008 年，Saleforce 的 PaaS 平臺已經承載了上萬個應用時，國內的 PaaS 平臺可能還在襁褓階段。

對于后來者來說，追擊領先者的有力武器便是借鑒，你也可以理解為「抄」。我覺得抄并不是一件丟人的事情，當我們對一個新事物的認知真的很有限時，與其用并不科學的舊法則來套用，不如用現成的新法則來嘗試。

但這個過程中對產品經理最大的挑戰不是搞清楚別人是怎么做這個功能的，而是搞清楚別人是怎么解決這個問題的，以及為什么是這樣的解決方式。

圍繞問題而不是圍繞功能，這是低代碼產品做競品調研的核心。

當然，正如用戶分層里說到，不同的產品針對的目標用戶是不同的，因此他們設計的理念也是不一樣的。

做競品調研時，找到值得研究的競品比調研本身可能更重要。只有你的產品和研究對象在目標用戶分層中基本保持一致，這樣的調研才更有參考價值。

最后就是核心方案，這部分的首要原則是解決核心問題的邏輯需要自洽。寫核心方案其實并不需要太多的筆墨，但難點在于推導過程是否邏輯自洽，是否是跑得通的。

在這一年的前半程，我的概要方案很多時候總會在若干個特定的點上沒有跑通，比如權限問題沒有考慮，跟其他系統的協作沒有考慮，跟正在開發的其他需求之間的沖突沒有考慮等。

因此要做到邏輯自洽，無其他更好的方式，只能不斷使用自己的產品，對產品的所有模塊都非常了解。這樣在一個復雜需求里，你才能在一開始就知道涉及到的重點有哪些。

只要在一開始沒有硬傷，后續的細節都是可以慢慢打磨的。

如果概要沒有問題，那更具體的方案設計就基本沒有問題，只是依據不同產品經理的水平不同，有的人可能寫得很細致，這樣開發過程中的溝通會更高效，有的人可能寫得比較粗略，那過程中的溝通就會更頻繁。

四、關于項目管理

雖然團隊里有 PMO 這個角色，但是很多時候需求的項目管理角色都會由產品經理擔當，在復雜的需求里，項目管理能力有時候可能比產品設計能力更為重要，因為它確保了交付成果。

對于產品經理工作的考察，大家都有一個共識，只有真正上線的需求，才算是一個產品經理的成績，在此之前的所有內容，都只能算是過程。

沒有一個產品經理在寫簡歷的時候會說，我上一段工作經歷中共寫了多少篇需求文檔，一共包含多少個字。大家在聊的都是，上線的需求對實際業務到底帶來了多少價值。

關于項目管理的標準流程，就不必多說了，在這里想分享一些推進大型復雜需求時，在標準流程之外的發力點。

1. 前置溝通

雖然從流程上來說，需求在設計完后就是評審，但為了評審順利，是需要做很多工作的。尤其是對低代碼產品來說，由于這是個新事物，且團隊里的很多人可能之前就不是做低代碼相關的領域，因此在認識上對齊就顯得更為重要。

溝通的內容與概要中的內容基本一致，也都是做這件事的價值和大致思路。

有溝通就有分歧，面對分歧時，需要產品經理提供足夠的參考信息，主要是競品的參考信息和用戶的反饋，在因為主觀認識不同而導致的分歧中，這樣的客觀信息反而能在求同存異時發揮更大的用處。

2. showcase

對復雜需求來說，最大的成本可能就是返工成本。為了避免返工，在流程中可以增加一環叫 showcase，即面向研發、產品、設計展示冒煙用例，在提測之前將已有的問題盡可能暴露，這樣在研發階段中可以增加一個質量監督節點，確保最終交付的需求是符合業務預期的。

3. 需求范圍管理

復雜需求往往牽一發而動全身，雖然 B 端產品不能像 C 端產品那樣快速交付持續迭代，但對于低代碼這個新領域來說，如果產品還在商業化之前的基建階段，我的建議是找到共創客戶，快速敏捷地交付獨立模塊。

對于低代碼平臺來說，只有真正能搭建出實際的應用，并經受住真實用戶的考驗，它才算是一個合格的低代碼平臺，而平臺背后的產品經理，也才算是真正的低代碼產品經理。

因此，明確管理每個需求的范圍，在指定時間內交付指定的功能給到用戶，接收真實業務場景的考驗，并拿到真實的反饋，可能才是低代碼平臺向前迭代的最踏實的道路。

五、關于低代碼業務

最后，聊聊我個人對低代碼業務的理解。

很早之前，我在讀吳軍的《浪潮之巔》時看到過這么一個觀點，如果某種技術對生產力的提升是 10 倍以上，那這個技術的誕生很有可能會顛覆某個領域。

例如從馬車到汽車的進化，從汽車到飛機的進化，每一個新物種的出現，都帶來了產業革命性的變化。

低代碼是這樣一個新物種么？很遺憾，我認為并不是。

至少在目前來看，低代碼對于生產力的影響，并不足以達到 10 倍以上。目前天花板級別的低代碼產品，也只能實現說「所有通過寫代碼而生產的應用，都可以通過拖拉拽+簡單的代碼實現」，況且能實現這個目標的產品，屈指可數。

既然不是新物種，無法出現突變式的演進，那就必然要遵循 B 端產品已有的客觀規律，漸進式演進。

在團隊內部的全員大會上，我向「飛書應用引擎」的負責人提過一個問題：如果說有一條原則需要所有的低代碼產品、研發、設計、業務人員都去遵循，那這個原則是什么？

答案依舊是：客戶第一。

與 SaaS 產品不一樣的是，低代碼產品的客戶并不會來自一個特定的行業，甚至并不是應用使用方本身，那這時候，客戶第一的原則背后就有一個更大的命題：誰是我們的客戶。

這個命題在商業化之前就變得尤為關鍵，到底是根據現階段種子用戶的反饋去迭代，打造滿足他們的產品，還是根據我們對產品的定位找到更適合的客戶，我相信沒有絕對正確的答案，但這個問題需要每個低代碼產品經理反復去思考。

做產品久了，會發生很多時候并不是沒有解決辦法，而是解決辦法太多的時候，選擇哪一條路去進行下去，就顯得尤為重要了。

六、結語

很早的時候，我問過 flomo 創始人少楠一個問題：

背景：

我們現在做的工具處于早期，面臨很多上手門檻問題，但體驗優化不能帶來工具天花板的提升，我們想要做的進階和復雜功能，在競品中都有，但是否要投入資源去做，團隊希望產品經理可以給要做的新功能想場景搏資源。我很怕陷入自嗨的詛咒里，最后做出了一個大家并不會用的功能。

問題是這樣的：

1、如果做工具產品時，目標是提升工具的天花板，那產品經理是否需要為想要做的功能去想象場景。這些場景是目前的業務方沒有提出來的，但產品經理也不知道用這個工具的業務在什么時候會遇到這樣的場景。

2、進一步地，如果從邏輯 （或者從競品分析）中判斷這個新功能是合理的，但它基于這個新功能的場景在上線很長的一段時間內（比如半年）都沒有出現在實際業務中，那這個新功能是不是一個偽需求。

少楠的回答簡單而堅定：

別看競品，給 50 個用戶打電話聊聊，邏輯沒用。