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个很重要的思想，深深影响了我自己的工作思考与行为应对，也影响着我如何观察企业这个生命体，并不断尝试与企业产生共鸣，而不是简单的落在人格共鸣里。
