在国内，同已经比较成熟的企业内部工具或 SaaS 产品来说，低代码还是比较新的领域。作者结合自己的实战经历，从五个维度与大家讨论关于低代码的业务操作思路，希望对你有所协助。
声明：本文所有观点，仅代表个人
前几天的春季发布会上，飞书正式推出了业务三件套，其中就包括飞书自研的低代码平台：飞书应用引擎。
恰好至今年 3 月 9 日，我参与字节跳动整整一周年，也在飞书做低代码产品整整一周年。在我们圈子有一句话，叫做字节一年，人间三年，以此来形容字节跳开工作的繁重和压力。
对我来说，这漫长的一年确实有许多值得回忆和复盘的地方，虽然在一年的时间节点上几乎没有任何典礼感，因为不时有下个重要的任务等着你去完成，但从个人长大的角度来说，这个特殊的节点是值得纪念的，而纪念它的最好方式，莫过于写下这样一篇文章了。
我晓得字节、飞书、产品经理，都是互联网圈子里的流量词汇，在许多自媒体或是职场社交平台，都能看到与之相关的内容。但这篇文章并不会将过多的笔墨放在字节、飞书、职场、大厂的话题，我会更关注我在这一年的真实收获，那就是在做低代码产品这件事上的收获。
为什么呢？
在字节跳动这样一个超大型组织内，每天都会有很多事情剥夺你的精神，平台的光环也好、盛传的裁员危机也罢，这些消息就像精神鸦片，吸食起来很爽，却几乎没有好处。
相反的，你正在做的事情，事情背后体现的才干，才干背后蕴含的根本功，反而是每天繁忙的会议背后，更容易被忽略的东西。对个人来说，这些东西才是我们在平台之外所独有的，真正属于我们自己的东西，说白了：
这是可以带走的东西。
一、关于产品
我在飞书做的是低代码产品，虽然这个领域在大类上属于 to B 产品，但同已经比较成熟的企业内部工具或 SaaS 产品来说，低代码在国内还是比较新的领域。
这个「新」体如今：
不同公司对低代码的理解和战略可能都不一样，没有一个成熟而公认的从 0 到 1 的演进形式，产品的形态根本都跟公司对低代码的定位有关；少有成熟的方法论可借鉴，只能从现有的产品去倒推底层的产品设计理念；圈子很小，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 个用户打电话聊聊，逻辑没用。
专栏作家
鼎力哥呀，微信公众号：鼎力哥，人人都是产品经理专栏作家。一个90后产品经理，已经写了6年的公众号，通过输出获得了许多意料外的长大。
本文原创发布于人人都是产品经理。未经容许，制止借鉴。
题图来自Unsplash，基于CC0协议。
该文观点仅代表作者自己，人人都是产品经理平台仅提供信息存储空间效劳。 |
|
