网站上的公告怎么做参考文献,网上购物网站建设规划论文,wordpress头像函数,中国影楼免费模板网前言 什么是架构#xff1f; 通常情况下#xff0c;人们对架构的认知仅限于在软件工程中的定义#xff1a;架构主要指软件系统的结构设计#xff0c;比如常见的SOLID准则、DDD架构。一个良好的软件架构可以帮助团队更有效地进行软件开发#xff0c;降低维护成本#xff0… 前言 什么是架构 通常情况下人们对架构的认知仅限于在软件工程中的定义架构主要指软件系统的结构设计比如常见的SOLID准则、DDD架构。一个良好的软件架构可以帮助团队更有效地进行软件开发降低维护成本提高系统的可扩展性和可维护性。这里的架构定义有更多元化的理解架构不仅是对软件开发设计和流程规范的定义也包含了参与架构设计的人员、以及项目过程中和架构有关的活动都可以称为架构。 从广义角度来理解架构意味着更全面的思考和新的融合。 按这张图理解架构是指架构师以商业价值为导向、以用户为核心在所处的商业、文化、技术环境中利用有限的资源和成本设计架构方案、组织或参与研发活动从而达到既定目标的一项复杂且持续的活动。 架构师面对实际问题在复杂的环境中如何做出正确的选择如何确保架构活动顺利进行保障项目落地可以从目标、资源、行为、趋势这四个层面来梳理。 架构 目标 明确目标在开始新事物时可能需要面对各种各样的选择和挑战。在这种情况下明确具体的目标并非易事。 可实现目标需要具有可实现性过高或过低的目标都可能导致挫败感和疲惫。要在充分评估自己能力、资源和环境的基础上设定合理的目标。具体、明确目标应该具体、明确易于衡量以便对自己的进展进行有效跟踪和调整。将目标细化为若干小目标有助于更好地管理和实现目标。有弹性目标制定过程需要有一定弹性能够应对不确定性和变化。当遇到挫折或不可预测的因素时可以适时调整目标以保持积极的心态和动力。持续关注和调整目标制定并非一劳永逸需要根据实际情况进行持续关注和调整。通过定期评估进展、学习经验教训可以保持目标与现实的一致性并提高实现目标的可能性。 上面4条是指导原则实际情况更为复杂比如技术人员通常以技术驱动去探索目标但是它不一定适合商业活动。拿MQ的对比Kafka和Pulsar后者相较更新、更快技术极客们通常会毫不犹豫的选择探索后者并将它应用到实际工作中。从普适性很强的成熟方案切换到新颖高性能的方案除了考虑切换的成本外还要考虑切换后带来的收益以及团队成员掌握Pulsar的成本。从发展的角度上看除非Kafka有致命的缺陷且不被修复那么随着时间推移Kafka可以一直演进迭代也会变得更出色。所以单纯从短期的技术先进性上看并不可取也要关注技术的生态这也就是常说的对技术的生态有一定的前瞻性。 结合自身的情况在线业务为什么要切GBF是要基于领域建设提高复用度达到降本增效。架构活动的所有目标都是为了降本增效。切框架短期内会使业务迭代成本变高中期途中就会陷入一个悖论当上下游环境协调成本高时如果从自身妥协方案会使得US短中期成本增高且如果没有改进的情况下无论是从US自身还是纵观全局看长期收益降低但是又不能影响进度或者说可不可以等时机成熟再进行我感受到过不小的压力。 这些原则说起来比较简单确保长期目标不动摇临时方案做取舍。做下来就会有犯难的时候如果临时方案做得多了容易形成包袱影响长期收益最终会使定制的目标打折扣。阶段目标保障和长期收益并不是完全对立的实际工作中也会存在需要做取舍的情况当阶段目标和长期收益出现矛盾时需要架构人员争取资源或做好取舍。纵使做完决定选择阶段目标临时放弃长期收益时这也只是一个短期的决定并不能代表将来也就是说在时机成熟的时候例如上下游在自身的演进中做了理想态的改造那么作为部门自身也需要时刻关注并及时跟进。 谈到取舍深有感触作为决策者或有决策权限的角色在决策范围内需要做好取舍。如果当事人不做取舍那么就只能让别人来替他做取舍。执行者大都选择丢掉休息选择加班、或者跳过总结归纳改进的环节长此以往这种决策低效且不科学。决策人员需要做好清晰的取舍避免无限度的索求全都要因为很有可能无法被完全满足导致取舍权分散给执行者。取舍权分散给执行者有什么不妥个人认为取舍的决策权下放分散给执行者存在问题是执行者接触到的信息有限、经验不足易导致决策过于片面不容易有全局观容易做出错误的决策项目风险加大。 资源 资源是有限的。 作为一个架构师要在有限的资源下最大化商业价值。如何让技术人员站在商业的角度来理解这句话 这里描述是一项架构师参与的商业活动既然是商业活动那么必定要有商业价值。大部分技术人员并不关注商业的价值逻辑通常只关注技术方案是否优越容易忽略技术方案落地过程中客观存在的资源、环境以及协作等因素。如何让技术人员理解商业价值可以从代码和设计的三个作用来阐述 技术人员主要通过上面这三个途径为公司赚钱。员工的工资和各种收入来自于公司的商业收入和融资。 结合自身的理解从公司到组织到个人都有属于自身层面的商业逻辑科学合理可持续发展的商业逻辑也是支撑公司、组织和个人发展的基础脱离了合理商业逻辑的事物短期内看并不一定会有明显的结果长期看会衍生出各种各样的问题问题的原因不仅仅归咎于问题本身及产生的过程更深层次上看是整个的商业逻辑是否合理、可持续。 那么作为个人来讲如何做到利用手中的资源最大化商业价值对公司、组织、个人都能受益 a.理解你所在的企业或团队的商业模式 b.理解你在自己所处环境中创造的商业价值 c.保障架构活动的长期商业价值 d.在架构规划中寻找扩大收入的机会 e.在架构规划中寻找减少成本的机会 前两点商业模式和商业价值每个人的认知不一样通俗讲就是这个公司、这项业务是不是核心、有没有前景。对于公司业务前景经常会有不同的声音常见于新兴业务属于仁者见仁智者见智不过也从侧面了印证了最近比较流行的一句话人们通常赚不到认知以外的财富。行业、企业的发展作为自然人很难影响和撼动历史和趋势中个人只有选择的空间。 那么第三条对我们来讲说是一个长期面对的事情当做出选择后如何在工作中确保自己和团队都能够有持续的、足量的、正向的价值和收益。和经济学一样技术的边际效益也是递减的因为技术一直在发展个人的价值和优势主要体现在增量价值上也就是说个人通过工作创造的价值是在平均价值之上才能说这个人具有一定的优势。然而这些优势并不是一成不变的因为开源的解决方案也在源源不断的提升越来越多的人掌握那么个人的增量价值响应的就会减少甚至不存在。这也就需要个人不断的学习、提升自己来持续提高竞争力。 文中提到的资源和经济学中的生产资料、生产成本类似商业价值依赖资源商业公司和组织对员工的期望是最小成本生产最大商业价值这些无论是从短期还是长期来看都要关注目标过于抽象时为了避免不同的人理解不一致可以根据每个人的环境、岗位具象专属的目标最好是根据时间粒度分散成阶段性的目标也就是说于员工个人而言更多的是对阶段性精确目标的最大化投入来取得收益。目标的定制依据这里已经介绍完了。 当目标确认完后就要奔着目标发挥自身的最大价值。也就是两个方面发掘机会和减少成本。 机会需要发现无论是来自于科学的数理统计、分析挖掘还是日常中的一些小Tips都是在发掘机会。这一点我在业务侧会接触到比较多的机会版本迭代中通常会和产品聊本次更新的动机是什么收益在哪作为C端的产品逻辑除了这些收益我们还要从用户体验出发这些变化会给用户带来什么样的方便以及我们会不会有额外的代价和成本。最常见的例子就是如何在有限的屏效中将活动信息、分享裂变、推荐合理的展示给用户、引导用户以及每个模块能否让大部分用户心领神会设计的初衷交互能否适应人群的习惯等等。但目前我还没有精力投入到指标的研究和跟踪中去分析验证只是有兴趣后面有机会需留意这块。 除了业务的机会也有技术的机会。比如发现并抓住开发中遇到的痛点。很多同学在开发或推进过程中会遇到各种各样的痛点非常多的情况就是考虑到时间、精力有限等因素后为了保障任务按期完成选择性忽略这个痛点当任务完成后又投入到其他事项中。这些痛点虽然造成了体感上的影响或者影响了一点点效率但并没有被抓住解决掉因为单论这一个问题不会被放大也不影响KPI或OKR痛点存在还会继续影响其他将要遇到的“幸运同学”当忽略的次数变得多起来量变易引发质变框架不够好用。如何应对这种现象个人觉得可以设计一种机制强化痛点发现、上报、跟进、解决、反馈提升也会从侧面提醒项目Owner除了关注任务的进度也要关注任务完成的质量。 成本包括人力成本、时间成本、机会成本也包括技术迁移的成本作为架构师需要从各类复杂成本中去衡量按时间轴推演保障中长期的收益。 行为 技术同学每天沉浸在逻辑中容易陷入一个思维区域世界由逻辑和数字主宰。合理的结构中商业活动需要和技术解耦因为技术自身不会给企业和组织带来价值而是大多数企业和组织作为一个平台使用技术盈利。技术落地的过程鲜有单兵作战大都是团队协作、组织协同。上面这句话推导的逻辑是商业价值 -- 组织活动 -- 人在组织 -- 活动主体是人 -- 遵循人性。 提到人性就会提马斯洛需求层次模型。尽管每个人所处的环境、接触的信息、个人的观念各有不同需求层次模型也会有千差万别但是从公司、组织和员工的角度来看这一模型相对稳定清晰。动机的抢占模型也可以理解为需求的压制模型如下图 有时候任务推进会感觉到超乎寻常的艰难合适的沟通方式表面上可以避免一些矛盾本质上是作为被推进方或者当事人的资源不足例如需求排不开通常推进方并不了解合作方的需求优先级或依赖层次和他要配合做这件事的成本有些事只是在推进放看来比较简单就会有一个求证的过程这个过程有没有必要我自己也不太清楚。当这些需求得不到满足的情况下合作方会自动诱发动机主导的意识和行为通常让人难以理解遇到这种事情的解决方式是分析他的需求优先级是否存在动机压制以及能否协调调整优先级改变动机压制的重要性和次序。 在最近的工作中经常遇到的一个现象是方案可行但是协同方没资源。因为组织的资源不单单为我所在的一个项目提供而是要支撑当下阶段的各个目标。如何在多样目标和复杂的组织资源协调中找到最优解是非常困难的一件事情。作为参与方尽量去解临时做兜底。一次次兜底就是一个个小包袱还要不忘提醒自己包袱不要太多。 动机优先级中每个人的认知和安排是不一样的有一个可以参照的依据设计思维的精髓在于深度理解和尊重用户对技术人员来讲到底是被动地迭代方案执着于填补设计的漏洞还是从共情用户的角度出发脱离现有技术方案的束缚。同时忘记现有的技术方案的优势 把关注点放在深度理解用户、解决用户的痛点上进而拓展技术设计空间找到更完美的技术路径。答案不言自明。 上面提到的这些只是理论也就是我们常说的理想态能否很好的落地就变得复杂起来因为单纯从理论上来看这些对每个人的要求非常高无论是职业素养还是主观能动性上做到的都是少数。同时伴随着边际效益递减、35岁危机、996等热门社会现象底层逻辑是人们没有安全感导致行为偏重自保这些能不能带来商业价值是值得分析和审视的。这里提到的安全感是指能够影响人做出科学决策的环境压力并不和居安思危中的危机感对立。 结合自己在技改项目的过程中有同学反馈担心会失去手里的业务和之前负责的一些方向也有同学有需求压制导致参与度不高有的会在交谈中表达有些虽然不明说但种种迹象表明团队协作或工作内容没有安全感。我给出的反馈和建议是当前目标是降本增效业务的前景很宽广当下还在高速发展完全没理由缩编但是这并不意味着可以无限度的扩张。我们需要在思考如何在不扩编的情况下更高效的做更多的事情花更短的时间支撑更多的行业。消除危机感的同时还需引导良好的设计思维刚才提到的深度理解和尊重用户很多同学是需要这种自我满足感的但是当节奏变得紧张、感受到环境不宽松时这些也就随之被抛诸脑后转而去满足更原始和低层次的动机也就是面对源源不断的需求和迭代将任务填满日程表从而持续不断的投入到紧张的迭代中。 顺势—天时、地利、人和 如何看清行业的周期、把握新技术。 俗话讲你永远叫不醒一个装睡的人。是这个人不愿意醒吗我看未必。而是人性的一些弱点导致这个人不愿意接受现实、害怕变化、对过往的路径严重依赖、或者思维僵化导致他不想醒。自我麻痹源自处于风险或者压力下的自我保护机制当个体面临压力、困境或威胁时为了保护自己的心理健康和自尊会出现一些消极的应对策略。这些策略通常表现为对现实的否认、回避或者对问题的轻视从而使个体在心理上暂时免受困境带来的痛苦。然而长期的自我麻痹可能导致问题恶化无法解决现实生活中的问题不能全力探寻新的出路甚至用勤奋弥补内心的不安容易陷入于目标无用的布朗运动——目标不清晰、动作不连续。 畏惧变化当人感受到压力时对变化感知异常慎重。在繁忙的事务中如何保持专注历史的包袱能不能放下如何卸载短时间内卸载不掉那如何长线对待如何同时支撑好业务当同时面临这些问题时每种取舍都有它自身的底层逻辑当我们面向未来去思考这些问题时就知道当下该如何选择。 对于路径依赖可以很好的用一句话解释成功可以借鉴但不会复刻。技术的生命周期可以从技术社区中获取技术的周期源于大多数人对该技术的定位。如果工程师们对这项技术不再有需求那么这项技术的命运将会毫不犹豫的被抛弃。 对技术周期的了解作为架构师的基本功这里不再作分析。当一个架构师的技术掌握优秀时又要避免一个误区拿着锤子看什么都是钉子。技术是实现商业价值的一个手段并不是唯一路径。在这个前提下技术不能拖累商业价值的最大化。所以说架构师面对公司、组织、以及工作开展的实际情况要选择合适的技术方案。 如何定义合适的技术方案先看三个不同的研发活动的层次 架构师在这三个层次的研发活动中侧重点是不一样的技术驱动需要保证技术的先进性、产品驱动保障客户的体验、业务驱动保障业务指标的全盘增长。 影响技术体系建设的外部因素还有行业发展、企业内部指标的压力、组织结构的影响等等需要架构师获取全面的信息通盘抓重点找到保障商业价值最大化的关键因素和节点。 总结 最近在学习郭东白的架构课本篇文章主要是结合自身实际的经历阐述架构师定位、架构活动如何保障企业、组织实现商业价值以及从员工层面的执行、管理角度分析各层次的定位、方向通过这些思考总结沉淀帮助我们在工作中更好地做技术落地和业务支撑。 推荐阅读 基于车道级数据的导航场景构建与还原仿真Android高性能高稳定性代码覆盖率技术实践高德信息业务DDD实战 用领域重构胶水代码高德数据优化篇之OceanBase最佳实践走近高德驾车ETA预估到达时间 关注「高德技术」了解更多
