SaaS产品复杂性解析1｜具有权限的用户≠权限拥有人：通过微信登录捆绑探析角色共鸣

Posted 2021-04-28 蹦跶小草

1，   人们在帕提侬神庙东边的残片上，发现了古希腊神话中的命运三女神，Lachesis、Atropos、Clotho。作为宇宙混沌之初最早产生的神，命运女神负责掌控泰坦十二天神和包括奥林匹斯十二主神在内的所有主神的命运，也主宰着每一个凡人的命运，是能量最为强大的天神。她们的任务是纺制人间的命运之线，同时按次序剪断生命之线。

2，   在古希腊神话中，命运女神是最神秘莫测的神灵，也是最无可抗拒的神灵。命运之所以不可抗拒，是因为命运女神后面跟着仆从复仇女神。复仇女神对那些敢于反抗命运女神的人实施严厉的报复。

3，    神话总是一遍遍的告诉我们，要谦卑的敬畏自然的力量，敬畏客观的存在规律。

 

前天，上线了一个小小的模块，金柚网的在线客户，可以通过微信捆绑登录账号。这是一个极小的模块，在产品细节上，和一位年轻产品人员在核心功能讨论的间隙利用断断续续的时间讨论了2周，开发人员用1周完成代码与测试并上线。上线过程中还不小心打包了其他测试完成的代码，发生了一些小问题。

 

不过就是一个登录捆绑，难道不是研究一下微信的接口文件，直接写了代码测一下就搞定？这，有什么好谈的呢？

 

好吧，我还真是打算从它开始谈。而且会谈的多一点。

 

——Part 1——

01

登录权限的法律归属

在登录环节，2B业务的产品经理任何时候都需要特别留意：登录人个人自然人身份与权限拥有者（企业法人）之间的法律关系。需要明确的是：

1） 登录者所拥有的登录权限，不属于登录者个人所有，而是属于权限的拥有者，即企业。

2） 登录者登录时，身份是个人，也是企业的业务授权代表。登录者作为业务操作人，理应帮助企业维护数据安全；SaaS软件提供方，帮助登录者进行便利操作的同时，也应该通过某些设置，为企业客户提供合理的数据安全控制并进行提示。

3） 用户个人通过SaaS进行操作，产生企业数据，数据作为资产，属于企业。

4） 用户个人在企业离职交接前后的数据安全，需要SaaS提供方能够留意。

5） 用户个人在企业会有转岗即权限转移情况，这一过程前后的数据安全，需要SaaS提供方能够留意。

6） 登录者可能是多个企业的在线业务办理人，捆绑时，需要明确捆绑的是哪一个公司的登录权限。

7） SaaS公司通过软件多进行收费服务，根据合同，可能存在不同的有效期，合同有效期前后，登录者的权限便利与数据安全，需要SaaS提供方进行区别对待并区分设置。

 

02

登录权限的安全控制

出于对以上基本情况的考虑，所以：

1）        权限使用人，只有在登陆状态下，才可以进行捆绑；

2）        权限使用人和业务联系人，可能不是一个人。在捆绑的同时，系统需要对后者发送多种形式的告之。例如：

03

数据安全考虑下的系统自动解绑

权限使用人并非就是客户预留给金柚网的业务联络人。在企业更换业务联络人或者其他重要联络人时，出于数据安全考虑，系统会自动解绑微信登录。用户需要重新进行登陆捆绑。

 

04

合同有效期内登录权限的区分控制

1）        绝大多数的企业服务SaaS，都与客户签署了“服务合作协议”，协议到期日，系统自动解绑微信登陆。但客户依然可通过用户名密码进入。金柚网为企业客户永久保留数据资产。

2）        企业签署不同的服务合作协议，解绑的规则不一样，同时告之企业所对应的不同业务联络人。系统需要对每一种协议有效期的规则进行区分对待。现在金柚网提供的服务是10几种（类），就需要考虑到10几种（类）可能面对的不同处理，并在头脑中时刻留意业务部门服务变化引起的合作协议的变化，以及提前考虑对扩展性与伸缩性的要求。

 

05

一个小小的微信登陆，为什么捆绑搞的这么复杂？

1） 对2C产品经理来说，用户＝权限拥有人＝数据资产所有人，可以说，登陆者自身对自身的数据安全具有责任。

2）  对2B产品经理来说，用户≠权限拥有人≠数据资产所有人，登陆者自身对数据安全具有责任。但用户作为企业员工，转岗前后、离职前后出现的各种问题，都需要SaaS供应商能够主动帮助客户维护数据资产的安全。

3）  企业级服务供应商，如果自身提供的服务，涉及多产品种类多功能多角色使用，则就需要针对每一种服务和每一个角色进行一一分析排查，以避免出现告之不及时的情况。

 

——Part 2——

01

对SaaS产品经理的最大认知挑战，是对企业生命体的共鸣理解。

 

2C产品中，用户＝权限拥有人＝数据资产所有人，在认知上，产品经理始终无法脱离却又可近水楼台的一个思考场景，借用佛洛依德的理论，就是在本我（id）、自我（ego）、超我（superego）之间的认知转换与应用功能之间的平衡与协调。本我、自我和超我之间不是静止的，而是始终处于冲突与协调的矛盾运动之中。

（以下内容来自百度百科，因不做学术探讨，本文借鉴过来仅做补充说明）

弗洛伊德在“心理动力论”中认为：人格由本我、自我、超我三部分组成。

本我（Id）：位于潜意识中的本能、冲动与欲望构成本我，是人格的生物面，遵循“快乐原则”。

自我（Ego）：介于本我与外部世界之间，是人格的心理面。自我的作用是一方面能使个体意识到其认识能力；另一方面使个体为了适应现实而对本我加以约束和压抑，遵循的是“现实原则”。

超我（Superego）：是人格的社会面，是“道德化的自我”由“良心”和“自我理想”组成，超我的力量是指导自我、限制本我，遵循“理想原则”。

我、自我和超我之间不是静止的，而是始终处于冲突——协调的矛盾运动之中。本我在于寻求自身的生存，寻求本能欲望的满足，是必要的原动力；超我在监督、控制自我接受社会道德准则行事，以保证正常的人际关系；而自我既要反映本我的欲望，并找到途径满足本我欲望又要接受超我的监督，还有反映客观现实，分析现实的条件和自我的处境，以促使人格内部协调并保证与外界交往活动顺利进行，不平衡时则会产生心理异常。

（人们行为展现出来的自我，仅仅是人格中的冰山的那个小尖尖。）

考虑到产品经理本身也是一个C，在某种程度上，与用户的角色共鸣可以帮助产品经理进行交互体验甚至是功能期待的揣摩。当产品经理追求卓越极致时，用户可以感受到，征服用户也会比较直接而有效。

——

2B产品中，用户≠权限拥有人≠数据资产所有人。对产品经理说，思考的对象不可能是完全混乱的，在认知上，真正的逻辑出发不是人性，而是如何认知企业这个生命体。

 

绝大多数的企业管理方以及用户方也未必能够清晰的区分企业的运营所需以及其个人所需之间的各种交错关系，要知道企业每天在处理动态的变化，企业需求在变动中，而需求阐述人也在高度的变动中，甚至可能出现部门裁撤与岗位调动。

 

企业作为一个生命体，成长规律也是有看不见的科学逻辑与规律的。

 

有生亦有死，企业何尝不是一个有生命周期的“有机体”，所以，也是存在“企业本我”、“企业自我”、“企业超我”的。如果说“本我、自我、超我”，共同构成了人的人格结构、那么企业所对应的同类项，则共同构成了企业自身的精神结构并依托于企业的现实存在。

 

企业本我（Company Id）：企业的本能需要，生存、发展、追求卓越之间的关系。充满着支撑、矛盾、对抗、茫然等等，互为交替牵制。遵循第一要务“生存并实现商业价值”，通俗的说，就是“要活着”。企业内生具有商业扩张本能，作为构成的组成因子的人性生物性本能，会影响扩张的方向。“地盘概念、地位、与被认同、获得奖励、强势人物自我性格”等正面及负面情绪是盈利为商业目标下的潜意识复合体。

企业自我（Company Ego）：企业与外部世界之间的关系，是企业特性与形象的展现，需要注意的是，这种展现所具有的分散性，即企业对外的联系与触点，是通过不同岗位不同角色的员工所展现的，是企业形象在外部世界的复合投射与塑造。

企业超我（Company Superego）：是企业的社会面，是社会风俗传统文化对企业的期待，也包括对其员工的整体期待，指导企业基本的社会规范与行为礼仪，遵循“责任与社会贡献”。

 

02

2B产品经理的角色共鸣对象，不是人，而是企业。

 

既然共鸣的对象不是人，那么，是否能够与企业这个生命体产生共鸣并且共鸣到什么程度，是对2B产品经理的真正考验。

问题是：

1，如果产品经理不能与企业生命体同呼吸共命运，不能比企业内部的人更理解企业生命体，如何能够真正做好SaaS ? 即只有高维才能解决低维的问题。

2，如果产品经理不在企业的运营管理的核心甚至背负生存压力以及面向股东和员工的责任，又怎么可能并如何真正感受到企业生命体的深层驱动以及效率流转需求？

 

2B产品经理需要面临的问题还不仅仅是与企业的角色共鸣，不要忘了，企业由人组成。

 

如果我们的客户是小微企业，那么企业的需求，相对是可辨识的。某一用户输出的需求所暗示的管理需求，是相对清晰的。

如果我们的客户不是中小微企业，那么企业通过有限的单点个人所输出的管理需求、效率需求，就开始模糊起来。因为关联关系的复杂，通过一个人口述出来的需求，就不再清晰。甚至需求阐述人，面临产品人员的一次次细致询问也可能茫然起来，其个人根据职位岗位吐的需求，其实仅能代表个人的陈述性表达，而无法体现实操环节的整体性。

 

真相往往是，需求输出者都可能随时被裁撤或者岗位调动，那么其输出的需求的急迫性与紧急程度，靠谁来界定？又怎么界定？既然人员裁撤与岗位调动无处不在，我们是否可以忽视其需求背后的驱动来源？

 

如果应对具象需求，2B产品经理可以获得赞扬和认可；如果应对同类项需求，2B产品经理可以获得适当的鼓励；如果对需求需求层层盘剥应对背后的驱动来源，那么2B产品经理所做的工作，可能和需求的直接供给者阐述的内容，将大相径庭，“收获的”，可能是误解和不满，甚至是冲突与对抗。

 

举个简单的例子：

＊  业务一线部门A因为一个数据整理的不便，要求产品人员进行协助处理，这个业务一线的数据的困境，可能是因为其他部门（如财务部门B）提出了这样的梳理要求。

＊  在企业快速增长的复杂业务中，财务部门B，不可能对一线的业务行为细枝末节全部把握后再建设制度。所以财务人员对业务一线的整理需求是概括性的。

＊  而产品人员如果理解财务基本规范，会发现业务一线部门A也许并不需要进行这样的数据整理，而是另外一个业务部门 C，处理另外一组数据时，没有做好标准化梳理，从而诱发了后续的问题。所以，如何处理好部门C的标准化会提上日程。

＊  当产品经理梳理这个牵扯业务部门C 的5-6个人的需求时，业务部门E涉及几百人的需求涌现，如果不应对，可遇见的几百人的问题会传递到财务部门B，这将大幅度增加财务部门以及部门A的2个月后的工作量，同时可能牵扯到另一几百人的部门F的数据处理。而这种牵扯有可能在5个月后，进一步增加财务部门 B的工作压力甚至带来审计上的问题。

＊  在资源分配有限的前提下，产品经理的更可能也更应该做的是：提高业务部门E的需求优先度，并排除干扰聚焦解决。

这是我们处理企业级服务逻辑较为简单的一种应对，绝大多数情况下，当我们想解决业务部门E的问题时，发现需要进行一些基本的数据配置，而之前先要对entity的概念提供准确定义，通过搭建配置项来解决部门E的问题。

于是，当我们搭建配置项时，业务部门A\B\C\D\E的人均看不到产品的产出，所以针对产品经理的不满开始发酵。

如果最早的业务部门A的一个看似简单的需求（如计算清楚），而在实际计算应对中，却要满足5000多种组合变化呢？

 

真相是，这些需求往往自带了业务部门自身需要面对的管理层压力的数据要求，一个需求就综合了需求提出人的个人操作便利的期待＋需求提出人部门的内容＋需求管理部门的要求。因为企业内部流转的交错，这些需求无论怎样的应对，都会对其他部门造成影响。影响有可能是良性的，也有可能是更大困境的开始。

 

03

SaaS产品经理需要在各种冲突中，去体会如何与企业生命体进行共鸣。

在实际发生中，需求定位的复杂，比上面提到的情况有过之而无不及。SaaS产品经理并不是单一公司的IT部门，而是试图针对所有企业同类需求提供通用性的云端在线软件。

 

如果产品经理以订制化的要求，解决一家办公软件的需求，所面临的困境，是相对简单的。如果是面对市场客户的SaaS产品经理，所面临的是不同角色用户的短期期待与本质解决的冲突，是无处不在且如影随形的。

产品经理所处的环境与需求之间的逻辑关系将如下图：

 

这尚不包括，产品人员面临的其他困境如：技术人员要求需求传递要有清晰规范的文档与节奏控制；不同业务需求人传递来的业务需求仅仅是一句话和一个观点，而业务部门可能尚未对其内部流转做出严谨规范的梳理。（事实上，对创业公司来说，业务发展是动态变化的，每天每周都在发生迅速调整及转向，梳理需要足够的样本沉淀，以及研究人员对所有的entity进行抽象逻辑盘整，概念的统一性完整性意味着，这个工作往往需要集中在一个人或者少数几个有默契配合的人身上。）

 

客观冲突的来源在于，产品经理的角色岗位，是在一家企业的，当我们试图解决普适性问题时，我们的思想需要从我们身体所在的组织结构中抽离出来。通过抽离出来的思想，远距离的观察、研究并抽象出企业的需求本质与动机来源。

 

产品经理在剥离问题解决问题的同时，似乎并没有太多的时间进行解释。因为，研究要做，梳理要做、概念定义要做，文档要写、要解释给开发人员，要解释部署给运营人员，如果产品复杂，就已上线的内容还要进行运营维护与优化跟踪。2C产品，好不好用户好感受到的，但2B业务的复杂流转，就没有那么容易解释清楚。例如，对直销人员，就很难解释法务规范性的要求，以及一些设置上对未来审计的考虑。

 

当然还有一种应对，就是针对公司的内部部门A\B\C\D\E 各安排一个产品经理，问题在于，针对每一个产品经理，我们是不是又要配置基本的设计师、前端、开发、测试等工程师？企业成本控制，是不是又要疯掉了？然后客户的问题，又需要重新安排其他产品经理并配备不同的开发人员。要知道，每一个独立线的产品经理都有可能生产出一套自身的相对闭环完整的概念体系，如果系统发展到过于庞大和盘根错节，未来的统合和拆解，因为代价过于庞大而很有可能不了了之。

 

是不是开发人员冲出去，就能把问题解决好？如果开发人员掉入需求陷阱中呢？如果10个开发人员理解的需求成因完全不一样呢？（大多数企业级服务的开发人员总会有几十个人的）。本来一个人可以应对的问题，就传导成了不可控的n个问题。最终，作为一个公司的整体性的需求本质，就会渐行渐远。

经过这么多年软件开发的经验积累，目前存在产品经理的原因，就是对这种紊乱的提前预防。在迷雾线索中，需要挖掘研究的客户需求在不知不觉间就极有可能被替换成了相对清晰可辨的用户需求。然后，渐渐的，客户，可能被忘了。

 

好了，回到本文的标题，具有权限的用户≠权限拥有人。即用户需求与客户需求之间存在着非表象的复杂关系，甚至可能的相爱相杀的关系啊。

 

很少有需求供给者能够笃定一个看法，对2B产品经理来说，他首先是一个产品人，而非传统企业建制中的IT部门。需要有对企业级服务运营流转的深度理解并不断追寻与企业生命体共鸣。企业普适性的整体性复杂层相之间的大流转需求的重要性超过了固定岗位与角色相对清晰层相简单的操作需求。

 

整体性的需求，需要深度研究与理解；割裂性的需求，需要单纯的应对落地。

 

这里面隐含的另一个难度在于，作为客户的企业生命体，与产品经理所在的企业生命体，是不一样的，如何能够准确把握多方需求，并力求平衡呢？如何能够与自身企业进行共鸣的同时，也能与企业客户进行角色共鸣？

 

人们说，SaaS产品经理不用一开始想这么多，先随随便便做起来。要快、要快、要快。从上世纪60年代、70年代开始萌芽并出现的大型企业IT化流程建设以来，直到今日，企业管理对IT系统的需求仍在不断的扩大（包括那些已经IT化了的大型公司），这说明了以软件为载体的企业管理的复杂性可能不是我们看到的那样简单。

 

同时，互联网发展已经进入无处不在的物联网时代，企业从成长的第一天起，就自带大量的数据属性，有强烈的数据管理的需求，从归类到存档到调取，没有这些基本的数据存储，后续的数据价值将无从挖掘。所以随便的做起来，其实不但很难适应当下时代的发展，更难以适应未来的智能化时代。

 

在一个短周期内，的确是无快不破的；在一个长周期里，不犯错，才是真快。

 

所以SaaS产品经理要面临是尽可能的不犯错，尽可能的每爬一个台阶，都能对后面的爬台阶有所助益。如果出现对冲消耗，早期做的越快，后期的损耗也将越大。

 

道理不难，难的是如何践行。

 

——PART 3——

 

01

康威、布鲁克斯和钱学森

 

复杂软件的开发原理与思想，与其他复杂工程学，本质上并无太多的不同。坦白讲，我觉得所谓的思想性的东西，是历久弥新的。有3个很重要的思想，深深影响了我自己的工作思考与行为应对，也影响着我如何观察企业这个生命体，并不断尝试与企业产生共鸣，而不是简单的落在人格共鸣里。

 

这里跟大家分享——

 

康威定律（Conway’s Law）

“Organizations which design systems are constrained to producedesigns which are copies of the communication structures of theseorganizations.”

 - MelvinConway(1967)

 

“中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构”。

 

“用通俗的说法就是：组织形式等同系统设计。”

 

关于康威思想与软件工程的解读，云栖社区上有一篇作者为“肥侠”的文章：《微服务架构的理论基础——康威定律》，写的非常通俗易懂也很有深度，且图文并茂，推荐。（链接：https://yq.aliyun.com/articles/8611）

 

不少人会有一个误区，技术能力强的人，或者技术管理强的人，就等同于可以做出一流的软件，事实往往并非如此简单。要知道，能力强的人，是很多很多很多的啊。啊啊啊。

 

复杂软件开发，不单单是纯粹的技术应用问题，深层次上，也是管理的组织结构与沟通的问题。所以一个公司在组织结构动员能力上的深思熟虑与反复斟酌，才是真正影响复杂软件最终架构及未来扩展重要的底基础。

 

SaaS软件开发，不仅影响自身公司的组织结构、业务流程与标准，也会对客户公司造成潜在的影响，只能小心谨慎、小心推理、小心假设、小心建设、小心验证。（怎么搞的特别适合“小”一点儿的人来做？呵呵）

 

一句话：影响复杂软件开发的深层次因素，是企业的组织结构与动员方式。

 

Frederick P. Brooks 与《人月神话》

 

非常幸运，在进行业务概念定义的那几个月，认真看了一些书，有两本对我的启发最大，一本是李智慧的《大型网站技术架构：核心原理与案例分析》，另一本就是我现在放在手边时不时再翻一翻的Brooks的《人月神话》。

 

对SaaS产品经理来说，理解企业，理解组织行为与软件开发的关系，是一个重大挑战，尤其是对产品架构负责人。而一个产品最终的架构并不是一开始能够清晰表达的，我们所处的开发环境，对最终的结果影响，潜在而重大。

 

康威定律在整体逻辑上解释了这些关系，但具体的开发推进，产品及开发的人员结构关系，Brookes在《人月神话》里进行了进一步的说明，Brooks也因此获得了图灵奖。

 

《人月神话》的每一个内容，都值的细细品咂，但即使真的理解，也很难真的做到。这里主要是谈产品经理的角色共鸣问题，SaaS产品经理的角色共鸣与组织制度有着难以切割的关系。《人月神话》相关的一章的内容，考再谈到这个问题时，提出：

贵族专制、民主政治和系统设计

1. 概念完整性是系统设计中最重要的考虑因素。

2. 为了获得概念完整性，设计必须由一个人或者具有共识或者少数互有默契的小型团队来完成。

3. 对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。

4. 纪律、规则对行业是有益的。外部的体系结构规定实际上是增强，而不是限制实现小组的创造性。

5. 体系结构、设计实现、物理实现的许多工作可以并发进行。

 

对这些观点的践行，肯定会造成了产品部门与业务人员甚至开发人员之间的一些摩擦，这些摩擦，本身就是告诉我们企业管理的困境所在。也让我们更能与企业之间产生角色共鸣。

 

推荐大家阅读《人月神话》的全本，即使不做产品经理，书中所指出的很多道理也能帮助我们厘清并认识生活上的一些混乱。

 

钱学森与系统论

 

两年前在一个同学群内看到一个人推荐学习钱老的系统论，因为好奇，就买了几本看得懂内容的通俗本来了解。推荐大家一本《智慧的钥匙——钱学森论系统科学》（上海交通大学出版社），在看过这本书之后，被钱先生磅礴的系统思想震撼了，就立刻买来了《钱学森全集》。

 

钱先生反复强调的：“必须先研究事务，而后才能研究过程。必须先知道一个事物是什么，而后才能觉察这个事物中所发生的变化”。他推崇恩格斯的看法“一个伟大的基本思想，即认为世界不是一成不变的事物的集合体，而是过程的集合体。”

 

坦白讲，恪守这个做事风格是容易恼人的。本来一件简单事情，怎么产品经理就没完没了的问呢？世上无捷径，真正的企业服务SaaS研发门槛，来自于：

 

1）        高度依赖对业务术语的概念追踪。

2）        产品经理和开发人员都需要耐住性子，对目之所及的所有业务概念提供准确定义。

3）        遵循基础研发的客观规律，对entity，保持清醒的认知，并不断拆解已经无法进行普适说明的entity.

4）        尊重客观现实：所有的基础研发都是缓慢的，但这是后续指数级变化必须经历的积累。

5）        强积累也要求，团队的稳定性，对entity的标准认知和拆解过程的参与，可以促进共识理解。这将有利于推进并维护复杂软件的完整性。

 

在他看来，“系统工程是工程技术，是技术就不宜像有些人那样泛称为科学。工程技术有特点，就是要改造客观世界并取得实际成果，这就离不开具体的环境和条件，必须有什么问题解决什么问题；工程技术避不开客观事物的复杂性，所以必然要同时运用多个学科的成果。一切工程技术无不如此”。

 

在系统论里，钱先生谈到了简单系统、巨系统、简单巨系统、复杂巨系统。

 

简单系统：指组成系统的元素比较少，它们之间关系又比较单纯。

巨系统：巨系统是指组成系统元素的数目非常庞大的系统。

简单巨系统：如果组成系统的元素非常多，但元素种类比较少且它们之间关系比较简单，这类系统称为简单巨系统。

复杂巨系统：子系统种类很多并有层次结构，他们之间关联关系又很复杂，这就是复杂巨系统，如果这个系统又是开放的，就称作开放的复杂巨系统（OpenComplex Giant Systems）。

 

有关复杂系统及复杂巨系统，钱先生推崇研究系统行为《协同学》（synergetics）的哈肯（Hermann Haken）。哈肯认为“有序结构的出现并不是非远离平衡不可，…….系统的详细运动或微观描述可以用一大组联立一阶时间导数的常微积分方程来表达，有多少个描述系统状态的变数，方程组的方程就有多少。对复杂的系统来说，描述系统的变数在某瞬间可以成千上万，上亿万，但不管多少，用一个坐标标出一个系统变化的值，那系统的瞬间状态总可以用这样一个许许多多互相垂直的坐标轴所形成的多维空间中的一个点来表达。”“系统只有在目的点或目的环上才是稳定的，离开了就不稳定，系统自己要拖到点或环上才能罢休”。这也就是系统的自组织。

 

（想想我们日常沟通只谈问题，完全不锁定“目的点”的情况吧，冲突与不稳定的来源啊。）

 

关于这方面的模型建设方法，以后再找时间谈谈过程。重要的是，这个点的寻找与确定，并不是业务一线人员能够理解的（他们的确也不需要理解）。能够花在解释上的时间，是有限的。

 

SaaS产品经理面临问题复杂性时，可以借鉴哈肯的协同学的内容。金柚网提供的社保管理服务的前提，是能够进行准确计算，就目前看，计算400多个不同地区的社保计算，摊开看最小粒度的逻辑参数，至少是有2亿个的，（这里的确真心感谢数据收集中心的几个小朋友。）且不断在动态变化中。保证计算不混乱的重要方式，就是不断的寻找确定产品落地内容的“目的点”和“目的环”。

 

简单说，就是不断寻找具有确定性的多循环往复“内容”，以“循环往复内容”作为模型建设的依据，而不是停留在“问题”梳理上。

 

一定存在一个从定性上升的定量的过程。

 

“在这些研究和应用中，通常是科学理论、经验知识和专家判断力相结合，提出经验性假设（判断或猜想）；而这些经验性假设不能用严谨的科学方式加以证明，往往是定性的认识，但可用经验性数据和资料以及几十、几百、上千个参数模型对其确定性进行检测；而这些模型也必须建立在经验和对系统的实际理解上，经过定量计算，通过反复对比，最后形成结论；而这样的结论就是我们在现阶段认识客观事物所能达到的最佳结论，是从定性上升到定量的认识”。——钱学森

 

“非生命系统通常服从热力学第二定律，系统总是自发地趋于平衡态和无序，系统的熵达到极大。系统自发地从有序变成无序，而无序却决不会自发的转变成有序，这就是系统的不可逆性和平衡态的稳定性。但是，生命系统却相反，生物进化、社会发展总是从简单到复杂，从低级到高级越来越有序。这类系统能够自发地形成有序的稳定性”……“一个系统从无序转化为有序的关键并不在于系统是否平衡和非平衡，也不在于离平衡态有多远，而是由组成系统的各子系统，在一定条件下，通过它们之间的非线性作用，相互协同和合作自发产生稳定的有序结构，这就是自组织结构”。——钱学森

 

中国的社保计算，对应的是“社会系统工程”（Social Systems Eengineering, SSE）的一部分，要知道整个社会迈向的税收体系与人民基本生活保障之间的关系，与社保数据是有密切关系的。考虑到中国存在几千套社保政策，应对不同地域的经济发展状况与机构历史沿革，其计算的复杂性、操作的复杂性，单从外部观察，是难以在短时间内进行有效把握的。

（从外部是很难迅速Get到复杂软件的点的，最快的学习方法，往往来自笨功夫，就是先阅览所有的看似枯燥的概念定义，如果概念定义本身进行了逻辑场景排序，那么，阅读者就可以迅速把握整体业务语言。如果没有这个内容，好了，挑战来了，开始不断的问问题，定定义。整个过程，不需要任何的情感表达，仅需要严谨表达。）

 

钱先生是给出了应对方法的，他小心谨慎的提出了“钱学森猜想”供我们思考，“就是如果一个系统出现了从有序变到紊乱的趋势，我有办法治它。怎么治？就是把系统的联系切断几点，那就好了。原系统是按层次来组织的。如果要出现紊乱了，你就截断系统的某些联系，即增加层次，就可以防止紊乱的出现”。注意，是在出现紊乱趋势时，这种方式才是有效的。如果在走向有序时，联系切断的风险可能是紊乱的出现。

 

是不是听起来有些熟悉。嗯。道理都是想通的。上面提到的Brooks在《人月神话》这样表达：“对于非常大型的项目，将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。”

 

再扩展一下，想想道路旁的乔木，每年园林工作者总要把旁枝砍一砍削一削，这样它们才好继续扎根地下，向上生长，突破过往高度。

 

自然世界的道理，其实，都差不多的，如果能够理解并践行且笃定坚持，虽说艰难，也不过是尊重客观规律而已。

 

SaaS产品经理应对的思想挑战，就是对这种认知的学习，在面对复杂系统时，钱学森先生的系统论，可以帮助我们保持清醒的头脑而不被复杂具象问题淹没。对“目的点”和“目的环”的不断探索，并保持高强度的定力和体力聚焦，排除干扰，对锁定的内容进行结果跟踪，是SaaS产品结构设计师面临的最大个人挑战。

 

所以，一个非常现实的问题：当SaaS产品经理试图帮助用户时，又是什么样的环境与土壤才可以帮助到SaaS产品经理及开发人员呢？

 

02

真正的SaaS平台需要产品经理不断思考企业管理的本质性问题

 

高效率指向先进生产力，好的SaaS产品，要帮助企业具有先进生产力。我们通过软件提供的流转设计，是否是真的在拆解企业内部的整体性复杂流转，而不是头痛医头脚痛医脚？与头痛医头脚痛医脚相比，对发病诱因进行防微杜渐是最难把握的，后者不仅仅需要掌握医术，也需要不断的学习医理。

 

2B业务的SaaS产品经理如果不能深入理解企业管理的本质，对用户的行为就失去了认知场景。任何缺乏背景、场景的认知，都是有些轻飘飘的。

 

在我们追踪需求时，需求表述人、需求收集人、需求传递人、需求汇总召集人，需求研究与分析人，需求逻辑归类人，他们之间的不同岗位和不同角色，无形中会遮掩了真正的需求动机。不要忘了，回到我们一开始，还存在一个“具有权限的用户”≠“权限拥有人”这个法律与安全控制问题。

 

要知道，由人组成的企业，面临的不确定性，是高过一个人的；企业成员越多，不确定性就越多，企业也因此而更加需要确定性。

 

SaaS产品的在设计上的真正难点之一，就在于不断寻找“目的点”，从不确定性中，找确定性，然后在确定性中，拆解出可以进入敏捷开发的迭代内容。

 

我们是深处组织结构之中的，但是不要让我们的物理存在限制了我们思想存在。如果感受到了深深的无奈、无助、悲凉与孤独，那么，恭喜你，你与企业这个生命体，开始产生“角色共鸣”了。这一过程，也许可以帮助我们思考人生的意义。

 

最后，只好用2句话自勉一下：

 

Creatures often go to extremes to protect themselves from pain. But pain may bring us new function in improving Cognition, emotion, action, and consciousness.

——美剧《西部世界》

 

Pain is certainly necessary for growing up.

——蹦跶小草的自言自语和自我安慰