Archive for the ‘Code杂谈’ category

管理者最易陷入的四个误区

September 20th, 2022

误区1:对上错位

对上错位的表现之一,就是不会利用上级的实际和资源。当你成为管理者后,你需要意识到自己的“上下级关系”已经发生变化,从之前的只需要听命于上级,变成了还需要影响你的上级。

你会背负部门的目标,而达成目标需要资源(人力、物力、财力),但资源的分配权往往掌握在上级的手中,这就需要你学会如何通过影响上级获取资源。

其次,上级的时间总是宝贵又有限,但有的管理者却因为种种原因放弃了与上级沟通的时间,这种行为其实是错误的。如果你得不到上级反馈、和上级断了联系,甚至没有时间见上级,都会导致你失去上级的支持。

对上错位的表现之二,是不理解上级的决策和想法,比如某个层级的管理者总是在他的上级管理者已经作出了决策,并发出了指令之后,再替他的上级管理者考虑决策的正确性、周密性和是否需要执行的问题,帮助上级管理者再做一遍决策前的工作。

这样企业中就会出现人人都是决策者,决策和指令难以贯彻,实际工作无法落实的问题。

所以作为管理者,我们要与上级建立更为密切的关系、理解上级的想法,才能确保获取足够的资源,进而达成目标!

误区2:对下失职

对下失职主要表现为:向下错位,不为下属提供成长机会,不为下属负责。

当你成为管理者后,过分注重团队评价和关系时、对下属的工作大包大揽时,实际上都是”心慈手软“的行为,这等于直接剥夺了下属成长的机会。就算下属的工作中出现了问题,你急得像热锅上的蚂蚁,恨铁不成钢地直接替下属把事情做了,其实对他们的成长也是不利的。

打个比方来说,假设一个公司的副总经理给某个项目经理安排了一项工作,该项目经理应该在接到这项工作任务后,先制订工作计划,然后对下属主管进行合理分工,主管再对下级员工进行分工,借助团队的力量来完成这项工作。

而在角色错位的情况下,该项目经理可能没有给下级主管进行分工,而是自己去执行了,或者是直接给主管的下级分配任务了,相当于项目经理做了主管的工作。

既然主管的工作被项目经理做了,主管就只好去做一般员工的工作了,一般员工就会因为主管做了他的工作而变得无所事事。

再来看该项目经理的上级管理者,因为该项目经理角色向下错位去做了主管的工作,项目经理的上级分管副总就不得不去做项目经理的工作,因为副总做了顼目经理的工作,总经理就要分出部分精力来做副总缺位后留下的工作,这样一来,企业中各个层级的管理者都出现角色错位,这是典型的管理者角色向下错位引起的连锁反应。

你很有可能在关系的维护中、亲历亲为中投入了大量的时间,继而忽略了业务的管理,忽略了团队人员的成长。

公司既然把你放到管理的岗位上,不仅仅追求的是目标结果,它需要你学会“业务管理”和“团队管理”,既做好业务,又能够带好团队。

”给下属成长的机会“只是我们对下属负责的一部分,但除此之外,还需要加强我们自身对业务的理解。

每个人对于目标的理解是不相同的,团队中出现”不清晰的目标”、 “未拆解的目标”都会令团队失控,令业务失控。

当管理者对业务理解不足时,会对上级指派的目标不加理解,把上级的话原封不动地转达给下属,也是对下属的不负责任。要想提高目标拆解能力,需要学的是业务管理!

误区3:跨部门协作障碍

很多管理者在晋升后,会对自己的“一亩三分地“无比的看重,在跨部门合作中锱铢必较,或者抗拒跨部门合作。这样的行为,都会为自己部门埋下“未来资源难以调取”的恶果。

这就是管理者“本位主义”的体现。比如一些部门经理只关注本部门的经营业绩,对部门之外的其他工作视而不见或采取消极抵制的态度,这往往会造成与其他部门合作的不畅与无序等现象。

具体表现为,一旦企业经营出现问题,他们首先做的就是撇清自己部门的责任,事实上,这类管理者忘了一件事情,没有一个部门或个体能够超越公司整体利益而独善其身。

造成管理者这种本位主义的原因,在于缺乏战略思考和全局观,或者是管理者本人的团队协作能力有待提升。这类管理者最重要的在于完成一个职业的转变:从专注局部绩效,到关注跨部门组织协调的转变。

对部门最直接的绩效评价标准,就是其所领导的部门处于企业的何种位置和状态,以及该部门为企业创造了多大的经效益和社会价值。这一切存在的前提是企业整体具有一个良好的效益,同时其他部门能够有效顺畅的开展业务协作。

现代企业中的每项工作几乎都是团队作业,在对应部门的上下游中,前一环节向后一环节提出需求,后一环节向前一环节提供服务,部门和部门之间形成了服务协同关系。所以我们要在职场上高效、高质量地完成工作,就要学会协调资源和向他人借力。

误区4:自我认知偏差

你在晋升后,通常会发现你的工作时间,很多时候不能自主把控了,它们将被大量的会议、碎片化信息的处理所充斥。

这个时候,如果你听之任之,认为管理者只是为团队、业务负责的人,把自己当成管理“工具人”,没有自我、没有提升,不需要学习,不需要成长,就大错特错了!这样想,只会令你迷失在事物的海洋中,逐渐沉沦,在大量碎片化时间中处理没有结果的事件,使自己变得业务能力不出众、管理不突出,泯然众人矣。

“管理学之父”彼得·德鲁克在其著作《卓有成效的管理者》说到:所有的管理,归根结底,首先是对自己的管理。我们必须学会自我发展,这样才能在这个充满无限机会的时代下沿着自己所选择的道路登上人生的顶峰。

管理者需要带领团队一起完成组织赋予团队的业务目标,不管是完成目标还是带人,都不是容易的事情。需要管理者自身有极高的个人素养,这体现在很多方面。

组织每天会面临新的形势、新的挑战,在当今互联网红利结束的时代,竞争更加激烈,因此管理者需要有很强的学习能力、应变能力。管理者只有持续保持学习新的知识,了解市场动态、洞察用户、分析竞争对手、梳理自身业务才能更好地把握新机会,实时调整战略方向。

管理者每天需要面对领导、面对下属、面对跨部门的同事、面对客户、面对用户,沟通交流是必不可少的。要想得到大家的认可和喜欢,并且保持很好的合作和交流,很重要的一个品质是谦卑。

谦卑的人自信而不鲁莽,更容易被别人接纳,别人也愿意跟这样的人保持良好的合作与交流关系,更容易跟别人成为朋友。谦卑的人愿意接受别人的观点,愿意自我反省,从而让自己可以从多个渠道更快、更好地学习。

精益的本质——Fail cheap fail fast 低成本快速试错(转)

May 29th, 2022

什么叫做不精益?

1. 问题找错,痛点不痛、刚需不刚。刚需:极大提升效率,极大降低成品,极大提升用户体验
2. 闭门造车
3. 解决方案选择错误
4. 过早优化:核心需求没有验证,就开始补充周边功能
5. 过早扩张:核心需求还没验证,就考虑规模化

为什么要进行精益创业?

创业者往往重视显性成本、不重视隐形成本——最大的隐形成本是时间成本
精益创业能帮助企业低成本快速试错,节约时间

正确的步骤:需求探索-用户验证-推广

1. 需求探索-找到痛点-常识判断-找到核心用户-用户访谈-总结
– 做强感知产品,让产品的特性让用户很明确的感知到(eg. 360杀毒软件)
– 为什么用户访谈不能代替MVP?观察真实的客户行为、
2. 用户验证-推行MVP
– 选出最先需要验证的假设?-需要评估哪些数据?-只找一个功能
– 数据收集:漏斗分析(转化);留存分析(版本迭代效果);A/Btest(产品用的少广告用的多);灰度测试
– 验证假设—数据:避免KPI导向,KPI是手段而不是目的(数据造假的方法太多了)
– 验证假设—亲自体验:创业公司CEO就是首席产品经理
– 验证假设—用户访谈:产品是否解决了你的问题?是否愿意付费?对价格是否满意?
3. 推广-加速获得用户
– 黏着式-获得新用户的速度超过老用户的损耗
– 付费式-不同渠道投放广告,投放时衡量成本
– 病毒式-工具型产品病毒式推广相较社交型产品比较困难,但也有如微信支付的成功案例(eg. 微信红包的成功推广)

精益创业的误区与局限性

1. 精益是“术”,大势为“道”——红利与大势
2. MVP不是万能钥匙—最有风险的去做MVP,其他用常识判断,但常识未来会发生改变
3. 在激烈竞争时,有可能错过一些机会
4. 实体性越强,开发中的精益性就越小
5. 有时候向用户寻求建议的价值不大
6. 容易让创业者只专注产品,而忽视营销
7. 容易让创业者做出放弃决定

企业内部如何管理创新-把企业做小是保证创新的核心

1. 团队组成 敢死队,只要精英、不要菜鸟,保持小规模:1个产品两个研发
2. 去KPI,内部市场化,鼓励内部竞争
3. 团队激励
4. 容忍失败

课后讨论

(1)对创业公司来说,时间是最大的成本。需要快速验证产品的路径是否成功。
(2)对已经上线产品模块的功能验证:快速和用户沟通,包括面对面沟通和后续的会议纪要,都可以形成公开参与的机制,感兴趣的成员都可以参与进来。

参考:

https://zhuanlan.zhihu.com/p/26700079

分布式架构关键设计

May 24th, 2021

三种数据库方案

1. 一体化分布式数据库方案
它支持数据多副本、高可用。多采用 Paxos 协议,一次写入多数据副本,多数副本写入成即算成功。代表产品是 OceanBase 和高斯数据库。

2. 集中式数据库 + 数据库中间件方案
它是集中式数据库与数据库中间件结合的方案,通过数据库中间件实现数据路由和全局数据管理。数据库中间件和数据库独立部署,采用数据库自身的同步机制实现主副本数据的一致性。集中式数据库主要有 MySQL 和 PostgreSQL 数据库,基于这两种数据库衍生出了很多的解决方案,比如开源数据库中间件 MyCat+MySQL 方案,TBase(基于PostgreSQL,但做了比较大的封装和改动)等方案。

3. 集中式数据库 + 分库类库方案
它是一种轻量级的数据库中间件方案,分库类库实际上是一个基础 JAR 包,与应用软件部署在一起,实现数据路由和数据归集。它适合比较简单的读写交易场景,在强一致性和聚合分析查询方面相对较弱。典型分库基础组件有 ShardingSphere。

跨库关联查询如何处理?

由于数据分散在不同微服务里,我们无法跨多个微服务来统计这些数据。可以建立面向主题的分布式数据库,它的数据来源于不同业务的微服务。采用数据库日志捕获技术,从各业务端微服务将数据准实时汇集到主题数据库。在数据汇集时,提前做好数据关联(如将多表数据合并为一个宽表)或者建立数据模型。面向主题数据库建设查询微服务。这样一次查询就可以获取客户所有维度的业务数据了。还可以根据主题或场景设计合适的分库主键,提高查询效率。

对于不在同一个数据库的表与表之间的关联查询场景,可以采用小表广播,在业务库中增加一张冗余的代码副表。当主表数据发生变化时,可以通过消息发布和订阅的领域事件驱动模式,异步刷新所有副表数据。这样既可以解决表与表的关联查询,还可以提高数据的查询效率。

前后序业务数据的处理

前后序的数据都跟领域事件有关。可以通过领域事件处理机制,按需将前序数据通过领域事件实体,传输并冗余到当前的微服务数据库中。可以将前序数据设计为实体或者值对象,并被当前实体引用。

在设计时需要关注以下内容:如果前序数据在当前微服务只可整体修改,并且不会对它做查询和统计分析,可以将它设计为值对象;当前序数据是多条,并且需要做查询和统计分析,可以将它设计为实体。

可以在货物运输微服务,一次获取前序订单的清单数据和货物运输单数据(类似BFF),将所有数据一次反馈给前端应用,降低跨微服务的调用。如果前序数据被设计为实体,还可以将前序数据作为查询条件,在本地微服务完成多维度的综合数据查询。只有必要时才从前序微服务,获取前序实体的明细数据。这样,既可以保证数据的完整性,还可以降低微服务的依赖,减少跨微服务调用,提升系统性能。

DDD与微服务的服务流转关系

April 29th, 2021

微服务调用关系

DDD服务调用关系:

数据持久化对象 PO(Persistent Object),与数据库结构一一映射,是数据持久化过程中的数据载体。

领域对象 DO(Domain Object),微服务运行时的实体,是核心业务的载体。

数据传输对象 DTO(Data Transfer Object),用于前端与应用层或者微服务之间的数据组装和传输,是应用之间数据传输的载体。

视图对象 VO(View Object),用于封装展示层指定页面或组件的数据。

领域层

领域层实现核心业务逻辑,负责表达领域模型业务概念、业务状态和业务规则。主要的服务形态有实体方法和领域服务。

实体采用充血模型,在实体类内部实现实体相关的所有业务逻辑,实现的形式是实体类中的方法。实体是微服务的原子业务逻辑单元。在设计时我们主要考虑实体自身的属性和业务行为,实现领域模型的核心基础能力。不必过多考虑外部操作和业务流程,这样才能保证领域模型的稳定性。

DDD 提倡富领域模型,尽量将业务逻辑归属到实体对象上,实在无法归属的部分则设计成领域服务。领域服务会对多个实体或实体方法进行组装和编排,实现跨多个实体的复杂核心业务逻辑。

对于严格分层架构,如果单个实体的方法需要对应用层暴露,则需要通过领域服务封装后才能暴露给应用服务。

DDD代码结构

April 26th, 2021

微服务一级目录是按照 DDD 分层架构的分层职责来定义的。从下面这张图中,我们可以看到,在代码模型里分别为用户接口层、应用层、领域层和基础层,建立了 interfaces、application、domain 和 infrastructure 四个一级代码目录。

Interfaces(用户接口层):

它主要存放用户接口层与前端交互、展现数据相关的代码。前端应用通过这一层的接口,向应用服务获取展现所需的数据。这一层主要用来处理用户发送的 Restful 请求,解析用户输入的配置文件,并将数据传递给 Application 层。数据的组装、数据传输格式以及 Facade 接口等代码都会放在这一层目录里。

Application(应用层):

它主要存放应用层服务组合和编排相关的代码。应用服务向下基于微服务内的领域服务或外部微服务的应用服务完成服务的编排和组合,向上为用户接口层提供各种应用数据展现支持服务。应用服务和事件等代码会放在这一层目录里。

Domain(领域层):

它主要存放领域层核心业务逻辑相关的代码。领域层可以包含多个聚合代码包,它们共同实现领域模型的核心业务逻辑。聚合以及聚合内的实体、方法、领域服务和事件等代码会放在这一层目录里。

其中Domain 是由一个或多个聚合包构成,共同实现领域模型的核心业务逻辑。聚合内的代码模型是标准和统一的,包括:entity(充血模型)、event、repository 和 service 四个子目录。

Domain层代码示例:

Infrastructure(基础层):

它主要存放基础资源服务相关的代码,为其它各层提供的通用技术能力、三方软件包、数据库服务、配置和基础资源服务的代码都会放在这一层目录里。