《高可用架构·中国初创故事(第3期)》一1.1 在新工作中找到你的出路

简介:

本节书摘来异步社区《高可用架构·中国初创故事(第3期)》一书中的第1章,作者: 高可用架构, 更多章节内容可以访问云栖社区“异步社区”公众号查看。

1.1 在新工作中找到你的出路

伴随着技术型公司增长的波动性,忠于公司的高级职员会逐步减少。当一个公司业务重点发生转折或改变的时候,开发经理们通常开始找寻新的工作。当然,获得新工作的第一步,始于面试。

面试中,面试官将尽力描绘他们公司的美景,如同薄雾笼罩的莫奈名画。而一旦你开始工作,则图画开始扭曲,甚至有些像毕加索的作品。面试中所描述的微妙的小问题变成了你亟待解决的巨大危机。表1-1中以调侃的口吻比对了面试说词与现实之间的差异。


q1

在你加入公司走上令人生畏之路时,你需要充分利用现状。

1.1.1 立即着手处理

在你任开发经理的一开始的日子里,急迫的问题需要立即引起你的注意。一些问题自从上任经理离职之日就开始堆积在那了,在你桌上堆放着延期数月的决策方案。在沼泽中跋涉是对处理这些积压工作最形象的比喻。

在专注于这些问题时,你可能会感受到压力,这会危及你长期的成功。只关注急迫的问题,会让你失去从公司、产品、同事以及你的团队中学习成长的机会,所以要做一次深呼吸看一看更广阔的天地。

如果在解决悬而未决的问题与处理日常危机之间分割你的时间,你会最终减少一些重复出现的问题,这样会提升团队的效率。每天花一部分时间从公司获得一些情况要比全力以赴处理积压问题更有效率。此外,你最好去了解一下团队所面对的重大问题,这将会促使你较早找寻出解决之道。许多问题还会在日常工作中冒出来并迫使你持续转移注意力。可以通过建立一个根据自身时间来处理多方面要求的体系来避免这个混乱的过程。

1.维护一个问题和处理成果的列表
从一开始养成细致的任务管理和记录保存好习惯将会对工作非常有帮助。维护一份清单,清单中要包含有关你的决策、处理过程以及一些重大问题,特别是那些对你较为迫切的问题。根据问题解决完成时间排出列表的优先级。管理好这份列表不仅有助于你减缓由于遗漏问题而引起的焦虑,将列表组合还可以让你和老板一起对你所排的优先级和问题处理进展进行评审。

逐日审核你的任务列表锁定优先问题。对于大的任务,则要锁定那些短时间内能够完成的子任务。每周要把重点放在高优先级的大任务上,否则,短期紧迫的要求依旧会导致进一步的延期。如果你日常处理这些问题的时间有限,则要避免时间透支并妨碍你的工作进展。

当你完成了一个解决问题的任务的时候,记得标记上日期并将任务存档。这个档案文件将在日后你被问起如何处理这些问题细节时有所帮助。验收成果同样有助于提高自身工作的积极性。

2.尽可能去授权
在适当的时候,对一些紧迫的问题进行职责分配,不要试图亲力亲为地解决所有问题。适当的任务分配可以使你和你的团队更富有成效,并且通过处理新任务也可以提升整个团队成员的士气。任务分配时,要确认受托者清楚了任务的内容、与其他相关工作的优先次序以及进展状态检查的时间点和完成日期。同样也要确认项目成员知道可以从你这里得到更多的信息。

如果不适合将整个任务分配出去,你可以将一部分任务分配给团队成员。例如,你可以把信息收集分给其他人而把审核留给自己。或者你也可以让一个团队成员提供一个问题的背景分析并指导他去分析数据。如果你能赋予团队成员承担部分重要工作的机会,你们都会受益。

当处理完棘手问题时,记得向老板通报你的进展。这有助于预防对你工作上的误解。

1.1.2 经历初始培训

初始培训阶段的成功需要集中付出努力与时间。每天要留有稳定的时间用于熟悉公司的员工,学习公司的技术,了解公司的产品、市场以及运作流程。找出你最机敏且能集中精力的1~2个小时。每天提前上班,并把每天最初的时间用在培训上,然后在以后将这段时间用于处理疑难问题。

作为新任的开发经理,在你的老板给你一些灵活度来熟悉工作和企业文化时,你会拥有3~6周的“蜜月期”体验。这一时期你可能会期望加班,用这些额外的时间来熟悉工作并处理重要的问题。如果老板认识到了你额外的付出,他会为最初雇用你的决定感到满意。在你展示了自己的能力后,就可以将工作时间适当减少到适度合理的水平。

要知道你是否被特别雇用,被期待成为变革代理人或期待给一个高效的部门带来增量变化。这些期待将决定你如何把结果展示给你的团队和老板。例如,如果你认定的重大问题而公众却期望维持原状的话,你就要耗费大量的时间和精力去说服老板和团队去认识一些问题的重要性。

你解决长期问题的时间也很关键。例如,如果你等到6个月以上再讨论宏观问题,你将面临比较巨大的挑战。你可能失去了展示创新理念甚至确定问题之所在的机会,一旦你沉浸于细节,就很难认识到系统中的瑕疵。当人们更愿意从新经理那里倾听新颖的观点时,你会发现开发团队更加抗拒变革。

如果你提议实施重大变革,要向公司如实陈述其利益和成本。“兜售”你的变革可以帮助你避免树敌或面对其他人抗拒变革的行为。

1.1.3 收集信息

收集公司产品、人员以及过程方面的信息有助于你制定头3~6个月的工作策略。通过与老板交流以及花时间与你的直属下级、同僚们沟通,以获取公司更广阔的前景。你的目标是了解公司的成就与全局性问题,并学会如何发展才能最好地为公司服务。从询问如下开放式问题开始,找到并分辨出问题的主要切入点。

运作良好的业务是什么?
你看到的主要问题是什么?
你建议的解决方案是什么?

然后将学习成果融入到工作总结中,并寻找一个解决模式。

1.创建讨论总结
当你与同事、经理以及其他员工商讨问题时要做笔记;然后把你的点评融入到带有强调符号的陈述之中,以确保思路清晰而富有条理。释义转述和总结性注释会使你的陈述短小精悍。

之后,分门别类整理总结文件。每一类都可以包含问题以及成就两个方面。在每一个问题方面之后,罗列出一个你们交流讨论的相关解决方案。这里有一个用于收集信息的推荐分类列表(当然,你的列表也可以用不同的展示方式)。

技术            质量问题

人员            内部文档

组织架构          风险

清晰的目标         客户服务

方针            市场和销售

过程            财务问题

计划            其他

问题和解决方案可以分为三类:你和你的团队可以直接解决的问题;需要通过与其他部门或其他组织中的人员合作解决的问题;你只能施加影响而不能直接解决的问题。根据你的摘要标示出每一个问题。

一个最终文件的摘录可以做成这样。

4.技术

有利因素:我们的技术比竞争对手更快更可靠。

有利因素:编程语言和函数库都是最新的。

问题:系统在A-15子系统中没有冗余性,将导致“核心崩溃”。这需要与运营部门协作。

问题:API几乎没有错误校验。两个缺陷数据请求就可以导致系统擦除数据库。

解决方案:我可以通过与开发人员讨论直接解决。

2.把你的总结应用于工作之中
之后,为发现的问题和取得的成果设置优先级。将成功的做法与问题进行排名可以让你考虑如何保持有利因素的优势。一个简单的A、B、C优先级对最初的排序就很好,并且可以在每一级别都遵循这一体系。将老板的指示级别提高,但也不要低估其他人的反馈。最终,你必须决定解决哪些方面的问题并且如何解决它们。从最高级别的问题中制定一个行动计划。例如,估算未来3~6个月你能完成多少。一个切实可行的计划会帮助你避免一次跟踪过多的任务以至于能完成的工作越来越少。

制定计划前要确认相对于改善型工作你完全了解自己能承担的混合型项目工作。对于一个小公司,至少要花费自己10%~20%的时间和团队5%~10%的时间来解决和当前项目没有直接关系的问题。这类与项目无关的问题包括提高生产率、指导培训讨论、推进技术、规划未来、改善工作关系,以及解决人的问题。

行动计划的失败通常是由于缺少公司的支持,所以要确信在你不断的努力下能从老板那里争取到支持。你需要你的老板极力支持——至少是认可——如果你希望成功。如果你的老板否决了你的建议,你需要理解他的忧虑——或者,你依旧相信你的建议,去做更多的研究然后兜售。在你的方法获得成功以前,你的老板需要知道你在用一种合理的方式来解决企业中存在的问题。

你也应该与其他部门经理特别是市场和销售经理们沟通。他们需要理解实现他们所谓的短期目标为何要花费如此多的时间和资源。要说明你的变革能给公司带来的长期利益。由于你确定的问题并不仅仅与你的部门相关,与其他人讨论和反馈意见将增进你对问题范围的了解以及帮助你找到最好的解决方案。

将每一件费神的事情当做一个带有时间表和资源的项目。要持续促进项目改进,否则他们就会失去动力;不能提升领导力就会导致随着公司的发展壮大,生产力却更为低下。

得到公司的总体概况

当我加入目前公司的时候,我花时间与不同部门的十几个人去交流。我把所听到的信息整合入一个只有几页纸的总结性文档中。这个过程让我洞察到了即将发生的一切。与每个人交流是一项启发性活动,它指引我直奔最先需要解决的首要问题。

相关文章
|
1月前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
2月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
53 3
|
2月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
1月前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
171 69
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
1月前
|
设计模式 负载均衡 监控
探索微服务架构下的API网关设计
在微服务的大潮中,API网关如同一座桥梁,连接着服务的提供者与消费者。本文将深入探讨API网关的核心功能、设计原则及实现策略,旨在为读者揭示如何构建一个高效、可靠的API网关。通过分析API网关在微服务架构中的作用和挑战,我们将了解到,一个优秀的API网关不仅要处理服务路由、负载均衡、认证授权等基础问题,还需考虑如何提升系统的可扩展性、安全性和可维护性。文章最后将提供实用的代码示例,帮助读者更好地理解和应用API网关的设计概念。
71 8
|
2月前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
63 1
服务架构的演进:从单体到微服务的探索之旅
|
2月前
|
负载均衡 Java 持续交付
深入解析微服务架构中的服务发现与负载均衡
深入解析微服务架构中的服务发现与负载均衡
92 7
|
2月前
|
消息中间件 运维 Kubernetes
后端架构演进:从单体到微服务####
本文将探讨后端架构的演变过程,重点分析从传统的单体架构向现代微服务架构的转变。通过实际案例和理论解析,揭示这一转变背后的技术驱动力、挑战及最佳实践。文章还将讨论在采用微服务架构时需考虑的关键因素,包括服务划分、通信机制、数据管理以及部署策略,旨在为读者提供一个全面的架构转型视角。 ####
42 1
|
2月前
|
弹性计算 运维 开发者
后端架构优化:微服务与容器化的协同进化
在现代软件开发中,后端架构的优化是提高系统性能和可维护性的关键。本文探讨了微服务架构与容器化技术如何相辅相成,共同推动后端系统的高效运行。通过分析两者的优势和挑战,我们提出了一系列最佳实践策略,旨在帮助开发者构建更加灵活、可扩展的后端服务。

热门文章

最新文章

下一篇
开通oss服务