无敌的第 16 篇月更
(我什么时候才能给自己搞个头图)
也是做了一段时间的B端产品了，今儿突然想起来刚入行那会儿，师傅就面色严肃、语气正式的传授了一个重要心得：系统设计一定要注意延展性。
延展性？当时的我对这个概念还处于一脸懵的状态，只大概知道个意思，听起来太抽象，用起来处于基本不知道如何下手的状态。
而这过了一年又大半，踩了不少坑，才明白这个延展性说的是啥。
延展性这概念不仅适用于B端产品，也适合C端、开发、设计。其实讲的就是在进行功能设计的时候，就要尽可能考虑到后续产品的迭代，把繁杂的系统设计的尽可能灵活。
再专业一点，就是像程序设计一样做到可插拔、好解耦。
足够灵活之后，终极形态就像阿里提出的“大中台小前台”概念一样，不仅可以支持一个系统的业务，也可以分别支持多个系统的业务。
举个栗子。去年接的第一个B端需求，是为了提升收集用户反馈的效率，需要在后台增加一块可以自行配置调研问卷的板块，支持在产品内各节点弹出各类型的弹窗。
当时初出茅庐的我摩拳擦掌，兴冲冲的调研完需求，联合小伙伴一起把功能上了线。而当时考虑欠妥的这个功能，让我之后的一年都在填坑。
在最初调研功能时，由于只是基于当下业务和需求场景去设计功能，功能只是简单满足了那一个阶段的需求。互联网最不缺的就是快速变化。很快，经过测验，先是大部分弹窗类型都被废弃，只留下了适用场景最广泛的其中一类；再是弹窗的潜力被大大挖掘，各组产生了各种各样的使用需求，而面对他们的个性化需求，原有只适配用户反馈类的配置项应对变得吃力。
再然后，一年的时间内，除了弹窗，其他各种类型的消息触达需求不断生长，按理来说应该都归为一处的功能类型被分散在不同板块内，明显是在开发前缺乏了整体的规划。
事后我常常在反思，我做错了什么。总结下来是如下三点：
1.错把需求方当成老大，忽略真实需求方的规划。
提需求的是老大，用功能的是运营。产品经理的角色不应该是接到需求后就马上规划实现，而是识别出关键相关方，通过对需求的不断追问、业务场景的不断调研，找到真实的痛点、找到问题的解决方案。
像在规划这个需求的时候，一是没有识别出当下的真正需求方进行调研，二是没有判断出未来可能的其他各组需求方早日规划，导致犯了B端产品设计这条大忌。
有点类似老板给你了个活儿，你本以为是类似开发钉钉一样，老板说做什么，你就笃定的一股脑做下去了，根本没觉得要管真实使用的搬砖同学们想法。结果最后发现，你做的是微信，真实用户哪儿买你的账哦。
2.没经过MVP验证就上线，没有小步快跑迭代功能。
这往往是功能废弃的一大原因。B端不像C端，尤其是系统功能类的B端设计。要做到系统内，功能会重的多。所以在确认做之前，需求验证是非常重要的一环，最后实现的样子也需要提前反复确认。最后实现的第一版功能，最好是最精简、最重要、被充分确认过的核心功能。
在规划弹窗的时候，经过外部PTS设计了对于用户反馈可能需要的3类弹窗。当时自鸣得意的决定会指导业务，但是在真实应用场景中，只有最简单最好用的那一种会时常被翻牌，其他类型基本处于废弃状态。
有时候产品需要走在业务前面，但是这建立在对业务充分的理解上
，不然最后只能是资源的浪费。
3.功能设计起码要看远一年，同时记住站在系统架构上去延展。
仅从弹窗配置功能本身来看，经过一年的发展，由于老师考评激励体系的不断迭代，原有适配用户反馈类型的弹窗使用率走低，转而营销广告等其他类型转而需求旺盛。由于当时对弹窗功能规划的使用场景的局限，导致后期需要不断迭代满足新需求。
而从系统结构全盘再来看，无论是弹窗、push、站内信、公众号消息，本质都是消息触达的一种手段。如果在一开始规划的时候就能通盘考虑、统一规划，在一个各类消息owner不同的组织内部，会更容易实现进行各类消息的排期和管理。
同时，后续在推进和其他系统(比如标签系统、消息系统、实验系统)的对接时也会更统一、成本更低。
这里多说一句，多向前考虑一步，不是需求功能的范围蔓延，而是在提前考虑到的情况下，预留出加入新接口的位置，或者是格式/布局的提前设计，防止在后续新功能的加入后，没有可操作的空间。
简而言之，这一份复盘，最核心的问题还是在「延展性考虑不足」这第三点上。刚入行小菜鸟贫乏的系统设计经验导致只是需求跟进就疲于应对，单线程的思考模式导致了对待需求也像皮球一样只是你抛我接、缺乏思考。
不断变化的用户需求决定了前台功能需要快速迭代去跟进和响应，从而对后台也提出了快速配合、跟进配置的需求。而大多配置类的功能模块，本质是一种「快速响应需求迭代」的产品设计思维。
因为系统结构复杂、功能耦合、对接迭代成本高等诸多特点，导致中后台的设计在一开始就需要有固定的考虑重点，这些重点也正是提升系统延展性的基础：
1.功能通用性：
比如这次的弹窗可能一开始只是很简单的为了用户调研，但是要充分考虑到未来也可以配广告、可以配通知，甚至考虑到把弹窗在一开始就区分样式去建立用户对不同类型的认知。
除此之外还有一些设计甚至要反而把简单需求复杂化，比如高危操作二次确认防误触、敏感信息脱敏验证查看、简单的发券需求也要考虑从数据及用户层面做权限控制。
很多功能设计的规范很依靠积累、熟能生巧，习惯性的多琢磨功能的使用场景和通用性，可以有效降低后续的开发成本。
2.设计结构化：
功能通用性再向前走一步，就是设计的结构化、组块化。如果我们将功能视为一种通用能力，需要做的是把这种能力尽力发挥在各种场景内，和当下的场景尽力解耦。
像是无论弹窗的配置、各类消息的配置、甚至各种功能的配置，可能都需要有细分人群的需求。在这时，每个系统都独立依据自己的需求去筛选人群明显是费事费力的。但如果把用户标签系统抽离出来，再去对接各类型系统，无疑是效率更高的解决方案。
3.设计标准化：
在把功能与业务解耦、形成一种通用能力后，进一步就是可以把功能打包、形成一套标准化模板，以接口的形式赋能外部的业务场景，真正实现功能的效益最大化。
到了这一步，对于功能的标准化设计要求就非常高了。需要对各类业务场景和功能架构有充足的掌握和了解，市面上各类SAAS应用就是最好的借鉴模板~
如果你还想一起放松放松：)
Photo by rawpixel.com
From Brett Sayles
www.Unsplash.com授权协议
往期回顾： 如果你还想一起思考思考：)
如果你还想一起放松放松：)
2335
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
