架构师和PM其实都是需要对项目的进度和里程碑关心的。有人说“架构师PM化”是脱实向虚的一种表现,PM用表格和数字关心项目进度,缺少实体内容;架构师是对交付物的把控,用架构设计和模型拆解做支撑,其风险和进展都是有实体内容的。对此,你有什么看法?
本期话题:
1、一定要有很强的编码能力才能担任架构师吗?
2、你觉得怎样的迹象表明架构师已经PM化了?
3、你在工作中是否也遇到类似的情况呢?你认为有哪些好的方法可以避免呢?
本期奖励:
截止2023年7月3日24时,本话题下将根据回答质量选取5名用户,获得天猫魔投2K。快来参加吧~
注:话题讨论要求原创,如有参考,一律注明出处,否则视为抄袭不予发奖。获奖名单将于3个工作日内公布,礼品7个工作日内发放,节假日顺延。
本期话题获得天猫魔投的用户为:
anisbob、owenwang2023、喜欢猪猪、huc逆天、不起名字可以不
防止架构师项目管理化需要一些措施来确保他们能够专注于架构设计和技术领导的角色: 明确角色和职责:明确架构师的角色和职责,确保他们专注于系统设计和技术决策。与架构师共同确定他们的职责范围,并与团队共享这些信息。 分工合作:建立跨职能团队合作的环境,让架构师专注于技术领导和设计,而将项目管理任务交给专业的项目经理。确保架构师和项目经理之间的沟通和协作,以实现项目目标。 培养项目管理能力:为团队中的其他成员提供项目管理培训和支持,以便他们能够有效管理项目。这样,架构师就可以将更多的精力集中在架构设计和技术领导上,而不必过多地关注项目管理细节。 明确目标和优先级:与架构师一起确定项目的目标和优先级,并确保他们了解团队和组织的战略目标。这样,他们就可以在设计和决策中考虑这些因素,而无需过多地参与项目管理。 制定适当的流程:建立适合团队和项目的流程和工具,以支持项目管理活动。这可以帮助架构师专注于技术领导和架构设计,同时确保项目管理的顺利进行。 定期评估和反馈:定期与架构师进行评估和反馈,以确保他们在角色和职责上保持正确的方向。这样可以纠正任何过度的项目管理倾向,并帮助他们保持专注于架构设计。
架构师之所以能成为技术专家,是因为需要这个岗位更专注于项目或产品的技术框架和落地,包括技术选型、模块拆解、技术风险评估与技术方案确定等。能成长为架构师的人必定是要有一些技术信仰与追求的,通常都会经过长期的项目或产品的研发过程与实战经验来提升自我并乐于为团队提供强有力的技术基础支撑,从这个方面来看,绝大部分情况是需要有很强的编码能力才适宜担当架构师。 如果是编码能力一般般甚至是没有编码能力的人担任架构师,这对于技术团队而言通常会带来比较大的灾难。
1.不再关注项目或产品的主要技术方向与基础模块/组件的建设和完善;
2.项目过程没有专职的PM,项目内外的计划与进度、对内对外的衔接沟通、项目汇报与资源分配等项目的组织与过程管理,都由架构师来兼职完成;
在工作中类似的情况容易遇到 “架构师PM化”现象。究其原因,主要存在有公司、团队、个人等多方面的复杂因素,比如公司对“架构师”这个岗位的职责定位不清,团队最高管理者未真实管理,全盘把项目直接让“架构师”来承接,“架构师”如果刚好也想直接往纯管理的方向发展,那就很容易出现 “架构师PM化”现象。
了解了主要的原因,我们就可以有针对性的找到一些方法来避免:
1.公司层面上,在岗位职责应该给“架构师”岗位做好清晰的定义与引导,建议是把“架构师”往技术专家这个岗位的序列去规划;
2.团队层面上,尽量按研发的分工做好相应岗位角色的配置,除了“架构师”外,还应配备“产品负责人”、“项目经理”等主要的核心岗位,让“架构师”能放更多的精力在项目事务性的管理活动、忽视技术框架支撑、忽略长期业务与技术融合战略等;
3.个人职业发展规划上,支持每个人的职业发展选择,如果个人希望在项目计划与进度跟踪、成本预算控制、项目内外部的汇报与沟通、项目资源的调配等事务型的工作,可以从“架构师”岗位转岗到“项目经理”的岗位上为项目或产品做好相应的本职工作。
架构师和项目经理(PM)在项目中扮演不同的角色,但有时架构师可能会过度关注项目管理方面,而忽视了自身的核心职责。为了防止架构师过度PM化,可以采取以下方法:
一定要有很强的编码能力才能担任架构师吗?
架构师需要具备深厚的技术背景和广泛的编码经验,但并不是所有的架构师都需要成为优秀的编码人员。架构师更关注于系统整体设计、技术选型和解决方案,需要具备设计能力、架构思维和技术领导力。虽然编码能力对架构师是一项重要的技能,但并不是唯一决定性的因素。
你觉得怎样的迹象表明架构师已经PM化了?
一些迹象表明架构师可能已经过度涉及项目管理,例如过分强调进度和里程碑而忽视了技术质量、架构决策的权衡和技术创新。如果架构师过多地参与项目计划、任务分配和进度管理,而忽视了系统设计和技术挑战,那么就可以认为他们已经PM化了。
你在工作中是否也遇到类似的情况呢?你认为有哪些好的方法可以避免呢?
在实际工作中,确实会遇到架构师过度涉及项目管理的情况。为了避免这种情况,可以采取以下方法:
通过明确角色和职责、良好的沟通和团队合作,可以帮助架构师更好地专注于核心的架构设计工作,同时也保证项目管理方面的需求得到满足。
架构师PM化是一种脱实向虚的表现,他们参加各种评审会议汇报的次数多了,但是实际产出却少了;对于问题的排查和定位无法独立完成,喜欢拉会催进度,种种表现对于一个开发团队的发展是不利的。个人觉得要杜绝架构师PM化,需要在个人和团队两个方面做出改变。
个人方面:一个合格的架构师需要参与到每个项目中去,包括自己产出架构方案,做好架构决策,需要有一定的编码量,测试环节要参与测试分析;
团队方面:要有一个健康的考核体系,以实际产出看成绩。团队文化上,开发的小伙伴明确拒绝拉回催进度的架构师;如果架构师不做架构方案和决策,要及时指出。其次,可以引入卓越工程,将协调、沟通、事务性的工作固化在流程中,通过pipeline驱动项目的推动和可视化,倒逼架构师回归本职工作。
1、不一定需要很强的编码能力才能担任架构师,但是需要对业务和技术有深入的了解和理解,能够从整体上把握项目的需求和目标,并设计出可行的技术方案。
2、如果架构师开始过于注重进度和里程碑,而忽略了实体内容的风险和进展,就可能表现出PM化的特征。例如,过多地使用表格和数字来管理项目进度,而忽略了代码质量和用户体验等方面的重要性。
3、在工作中遇到类似的情况时,可以通过以下方法避免: - 确定好自己的职责范围,不要越俎代庖; - 与其他角色(如开发人员、测试人员等)进行充分沟通,确保对项目的整体把握; - 保持对技术趋势的关注,及时调整自己的思路和方法; - 不要过度追求进度和里程碑,要注重风险管理和质量控制。
架构师是一个公司代码的水平体现,在我看来,架构师是一定要能够编写出优秀的代码的。原因有两方面:第一,使开发人员能够更方便的获取信息,加快开发进度,减轻新人的学习成本,是每个架构师存在的基础意义。只有代码优秀的人,才能够编写出好的工具类,引进更优的技术。是问写出的代码不能运行,或效率很差,有的根本就没有代码输出,架构师的岗位意义又在何方呢。第二,关于pm话的问题,其实我认为一定程度上是应该走这个方向的,因为不了解公司要做什么,服务于什么客户,客户需求是什么,空中楼阁的设计基础架构,这有些脱离实际了,对整个项目或者服务是一种损害。结合了有关需求方向后给出的设计模式,工具代码,才能更好的辅助开发。如果一味的为了架构而架构,不结合实际,可能会起到相反的结果,比如引进了安全组建,但客户是个内网平台,不需要这部分的内容,不仅增加了开发人员的难度,而且浪费了资源
作为一个阿里云用户,关于如何防止架构师变得过于项目管理化(PM化),我可以提供一些看法:
强调技术领导力和实践: 架构师不仅需要有扎实的编码能力,还需要有一定的技术领导力。他们应该能够指导团队成员,在技术选型、架构设计和开发实践等方面提供建议和支持。架构师应该将技术创新和最佳实践贯穿于项目中,而不仅仅关注进度和交付物。
分工明确、角色清晰: 在团队中明确每个角色的职责和权责边界。架构师应专注于架构设计和技术决策,而项目经理应专注于进度管理、资源协调和风险管理等事务性工作。通过合理划分角色和职责,可以避免架构师过份关注项目管理方面的事务。
建立良好的沟通机制: 在团队中建立良好的沟通机制,促进架构师与项目经理之间的有效沟通。定期召开会议、进行周报汇报、共同讨论项目计划和进展,以保持双方的理解和协调。通过密切合作和有效沟通,可以减少角色之间的冲突和混淆。
引入技术评审和复审机制: 在项目开展过程中,引入技术评审和复审机制,由架构师主导并邀请其他专业人士参与。这样可以确保项目在技术层面上的质量和可行性得到充分考虑,减少项目经理对架构设计的过度干预。
培养全面发展的团队文化: 鼓励团队成员拥有全面的技术素养,并培养多样化的技能。这样可以使得团队中的每个成员都能够在必要时承担更多的职责,减少单一角色被过度依赖的情况出现。同时,也有助于促进团队成员之间的相互理解和协作。
总体而言,防止架构师过度PM化需要在团队协作、角色明晰、沟通机制等方面进行有效管理。架构师应该保持技术领导力和专注于架构设计,项目经理应专注于管理事务和资源调度等工作。通过良好的团队合作和明确的角色分工,可以平衡架构师和项目经理之间的关注点,使得项目在技术和管理层面都能够得到充分的关注和支持。
对于本期话题的三个问题,我的观点如下:
一定要有很强的编码能力才能担任架构师吗? 强大的编码能力是成为优秀架构师的一个重要条件之一,但并非唯一决定因素。除了编码能力,架构师还需要具备系统设计、领导力、沟通能力、技术判断等多方面的能力。编码能力是架构师所基于的基础,但在实践中,架构师更需要关注整体系统的设计和演进。
你觉得怎样的迹象表明架构师已经PM化了? 一些可能表明架构师已经PM化的迹象包括:过度关注项目进度而忽视技术创新;将大量时间花在与项目管理相关的任务上,而减少对架构设计和技术决策的投入;过分依赖工具和表格来管理项目进展,而不注重实质性的技术输出;对纷繁复杂的项目管理方法论着迷,而忽略对技术的深入研究。
你在工作中是否也遇到类似的情况呢?你认为有哪些好的方法可以避免呢? 在实践中,确实会遇到架构师过度PM化的情况。为了避免这种情况,可以采取以下方法:
清晰地定义和传达每个角色的职责和任务。 建立团队成员之间的良好沟通机制,促进合作和协调。 引入合适的工具和方法来支持项目管理,同时保持对技术创新的关注。 在项目进行中进行定期的技术评审,确保技术方案和架构设计得到验证和改进。 鼓励架构师保持对新技术和领域的学习,并将其应用到实际项目中,以推动技术发展。 通过以上方法,可以提高架构师团队的整体效能,保持架构师在技术、设计和项目管理方面的平衡,避免过度PM化的情况发生。
1、一定要有很强的编码能力才能担任架构师吗? 担任架构师不一定需要具备极强的编码能力,但对编码和技术有深入的了解是非常重要的。架构师负责设计系统架构和解决方案,需要理解各种技术选型和架构模式,并能与开发团队进行有效沟通。虽然架构师可以依赖开发人员实现具体的编码工作,但自身具备一定的编码知识能够更好地指导和评审团队的工作。
2、你觉得怎样的迹象表明架构师已经PM化了? 当一个架构师过度关注项目进度、沟通协调以及管理事务,忽视了对系统架构和技术细节的关注,就可能出现架构师PM化的情况。一些迹象包括:
将大部分时间花在与利益相关者或团队成员的会议上,而忽略了技术设计和评审的工作。 对项目进度和里程碑过度焦虑,而忽略了技术风险和可行性分析。 缺乏深入的技术讨论和决策,而更多地关注项目管理流程和文档。 不再积极关注最新的技术趋势和业界动态。 3、你在工作中是否也遇到类似的情况呢?你认为有哪些好的方法可以避免呢? 确实,在项目中架构师过度关注项目管理而忽视了技术细节是一个常见问题。为避免这种情况发生,可以考虑以下方法:
确保在项目团队中有明确划分的角色和责任,明确架构师的职责和关注点。 建立良好的沟通机制,使得架构师能够及时了解项目进展和风险,并提供技术支持和指导。 定期进行技术评审和代码审查,确保项目在技术层面得到适当的关注和把控。 给予架构师足够的时间和空间来关注技术学习和研究,保持对最新技术的敏感度。 在协调项目进度的同时,鼓励架构师与团队共同参与技术决策和选型,避免个人单方面的决策。 总之,平衡好架构师与项目管理角色的关注点,并建立合适的工作机制,可以有效避免架构师过度PM化。这样能够使得架构师更好地发挥其在技术领域的专长,为项目的成功贡献力量。
可以考虑以下几点:
1.明确角色职责:确保架构师清楚其职责范围,重点在技术架构设计和决策上,而非项目管理。这可以通过组织内部明确的角色定义和职责说明来实现。
2.培训和发展:为架构师提供相关的培训和专业发展机会,使他们能够不断提升技术架构设计和领导能力,从而更好地履行自己的角色。同时,也可以鼓励架构师参与技术社区和行业研讨会,与同行交流经验和最佳实践。
3.合理分配工作:确保给予架构师充分的时间和资源来完成他们的核心职责,避免将过多的项目管理任务压在他们身上。如果需要进行项目管理工作,可以考虑引入专业的项目经理或项目团队来支持。
4.有效沟通和协作:建立良好的沟通渠道和协作机制,保持架构师与项目经理之间的密切合作。通过定期会议、项目评审和沟通反馈,确保双方对项目状态和需求有清晰的了解,避免架构师被过多的项目管理工作所占据。
总之,为了防止架构师过度向项目管理方向发展,需要明确角色职责、提供专业培训和发展机会、合理分配工作,并促进有效沟通和协作。这样可以使架构师更专注于技术架构设计和决策,为组织带来更高的价值。
1、一定要有很强的编码能力才能担任架构师吗?
从某种意义上来说是的。
架构师不同于普通工程师,他们在长期编程中已经积累了大量经验,并储备广泛的技术知识和经验,能够理解各种技术和工具的优缺点,并根据需求选择最适合的解决方案,所以架构师的编程能力一定不差。
此外,架构师还需要具备良好的沟通和领导能力,与团队成员和利益相关者进行有效的交流和协调。
2、你觉得怎样的迹象表明架构师已经PM化了?
(1) 架构师花费更多时间和精力在项目管理活动上,例如制定项目计划、跟踪进度、协调资源、管理风险等,而非技术领导。
(2) 开始承担项目管理责任,例如负责项目的整体规划、决策和结果交付,而不仅仅关注技术架构和设计方面的工作。
(3) 参与项目决策,例如预算分配、资源规划、风险管理和项目优先级等方面的决策。
(4) 与利益相关者进行沟通:架构师可能开始与利益相关者进行更频繁和更广泛的沟通,例如与客户、团队成员、高层管理人员和其他利益相关者协商和交流项目相关事宜。
(5) 主动提升项目管理技能,例如参加项目管理培训、获得项目管理认证或学习项目管理最佳实践。
3、你在工作中是否也遇到类似的情况呢?你认为有哪些好的方法可以避免呢?
(1) 明确架构师的角色和职责,强调其在技术决策、架构设计和技术领导方面的重要性,同时强调项目管理的职责应由专门的项目经理来负责。
(2) 建立一个明确的技术评估机制,以确保所有技术决策都经过充分的评估和讨论,而不是仅靠PM或者架构师。如技术评审会议、技术评估报告等。
(3) 架构师应与其他团队成员保持密切合作和沟通,包括开发人员、测试人员和项目经理等。通过团队协作和信息共享,可以确保架构师始终保持对项目的技术领导地位。
(4) 为架构师设定明确的目标和指标,使其能够更好地衡量和评估自己在架构设计和技术领导方面的贡献。这可以帮助架构师更好地专注于自己的核心职责。
总之,明确工作职责与职业规划可以有效防止架构师PM化。
在我们的程序员工作环境中,项目的成功不仅取决于团队的专业技能,还取决于清晰的组织和协调。架构师和项目经理(PM)在这方面就起着至关重要的作用。但是我觉得当我们在这两个角色之间划清界限时,会引发一系列的问题和挑战。 1、一定要有很强的编码能力才能担任架构师吗? 我觉得不需要,架构师的核心职责是设计和维护系统的架构。这要求他们理解如何将各种技术组件整合在一起,以构建高效、稳定和可扩展的系统。编码能力无疑是架构师的重要技能之一,它可以帮助架构师理解各种编程语言和框架的优缺点,进而更好地进行设计决策。
但是哈这并不意味着只有顶级编程能力的人才能成为优秀的架构师。架构师还需要具备深厚的行业知识、沟通技巧和项目管理能力。他们需要能够清楚地向各个角色(包括非技术人员)解释架构选择的原因和影响,并且需要有协调团队成员,确保项目按照架构计划执行的能力。
2、你觉得怎样的迹象表明架构师已经PM化了?
架构师如果过度关注项目进度和里程碑,而忽视了他们的主要职责——架构设计和保证质量,那么可以说他们已经开始“PM化”。例如,如果架构师过分投入到日程安排、预算控制和风险评估,而忽视了技术选型、模式识别和代码质量,这就可能意味着架构师正在失去他们的主导地位。
3、你在工作中是否也遇到类似的情况呢?你认为有哪些好的方法可以避免呢?
我在我的工作中见过很多类似的情况,其中有许多案例表明,明确的角色定义和良好的团队沟通是避免这种情况的关键。 架构师和项目经理应该对自己的职责有清晰的认识,而且他们需要对各自的角色边界有一致的理解。并且并且需要密切协作,共享信息,尤其是关于项目进度和潜在风险的信息。
在这个过程中,团队成员的敏捷思维方式也非常重要。团队应该接受并欢迎改变,而不是把计划看作是刻不容缓的指示。在这种环境中,架构师可以根据项目需求的变化调整架构,而项目经理可以保证团队达到既定目标。
防止架构师(Architect)过度走向项目管理(Project Management)的路径,需要注意以下几个方面:
1.明确职责边界:架构师应该明确其职责范围,即专注于系统架构设计、技术选型、技术指导等方面的工作,而不是过多参与项目管理和日常事务处理。与项目经理(Project Manager)进行充分的沟通,明确各自的职责,避免职责冲突和重叠。
2.建立专业声誉:架构师应该注重自身的技术积累和专业能力的提升,通过持续学习和实践来提高自己在技术领域的影响力和专业声誉。这样可以让其他团队成员和项目经理对架构师的专业价值有清晰的认知,不会轻易将其引导到项目管理的领域。
3.参与架构决策:架构师在项目初期应该积极参与系统的整体架构设计和技术决策过程。通过积极参与决策过程,架构师能够在项目中发挥技术专家的作用,确保系统的可扩展性、可维护性和可靠性等方面得到有效的保证。
4.保持技术跟进:架构师需要保持对技术领域的持续关注和跟进,了解当前的技术趋势和最佳实践,不断提升自己对技术的理解和能力。这样可以有效地与项目经理沟通和协作,并提供合理的技术建议和解决方案,避免陷入过度的项目管理工作中。
5.拒绝过度承诺:作为架构师,应当避免过度承诺和负责过多的项目。要明确自己的时间和精力,并合理分配给各个项目。避免过度承诺可能导致项目管理角色的滑坡,而不是专注于技术架构的工作。
总的来说,防止架构师过度走向项目管理的路径需要架构师自身有清晰的职责认知和专业发展计划,与项目经理和团队成员之间进行积极有效的沟通和合作,保持技术专长和对最新技术趋势的跟踪,以及合理分配时间和精力。这样才能更好地发挥架构师的技术领导力和专业能力,为项目的成功提供高效的技术支持和解决方案。
从实际岗位属性出发来看,架构师和项目经理(PM)是项目中不同角色的代表,他们在关注项目进度和里程碑方面有着不同的职责和重点。从公司角度出发来看,两者在公司中本身的定位,又是因公司而异。公司的定位是什么,决定了在实际中承担什么样的工作内容。 但是,不管两者是什么样的定位,题言中对于实虚的定义是片面的。他俩应该是随时在协同,不会孤立的完成工作建设。因此,相互的工作交集的部分,是肯定的。不能说是该谁去做,而且按照事实情况来看。
对于架构师岗位来说,更关注项目的技术方面,包括系统架构设计、模块拆解和技术风险评估等。职责是确保项目的技术实施能够满足需求,同时还要考虑系统的可扩展性、可维护性和安全性等方面。架构师通常会与开发团队紧密合作,提供技术指导和支持。但是,从岗位落地来看,对于整体产品的技术把控,就会反推项目、产品的管理上来。所以,必然会有冲突在,就会很大程度上,承担更多的内容,不仅仅是技术。
架构师需要深入了解编码和技术细节,以便更好地指导开发团队和评估技术风险。但并不是所有的架构师都必须亲自编写代码。在某些情况下,专注于系统设计、模块拆解和整体架构规划等方面的能力可能更为重要。
项目经理更注重整个项目的组织和管理,负责制定项目计划、分配资源、跟踪进度、协调团队成员等。项目经理通常使用表格、数字和其他管理工具来监控项目的状态和进展,并与利益相关者进行沟通。
尽管架构师和项目经理在关注项目进度方面有所不同,但这并不意味着架构师就一定缺乏实体内容或者变得过于虚拟化。实际上,架构师仍然需要关注交付物和项目的实际结果。他们的工作重点是确保系统的技术实现能够成功交付,并且满足业务需求和质量标准。
如果非要去定义架构PM化,可能存在架构师开始过度关注项目进度和管理事务时,就可能出现所谓的“架构师PM化”现象。一些迹象包括过多参与项目管理活动、忽视技术细节和架构设计、沉迷于日常事务而忽略长期战略等。这可能导致架构师失去对技术实施的专注,并丧失其原本的价值
先说明下,目前的工作岗位以及状态信息。 岗位上,是技术架构岗。但是,公司对于技术架构的定位是多元的,是需要你承担相当大的职责的。技术的深度广度是需要的,但是对于产品、解决方案、项目管理,同样也是必备技能。 对于此,不同人有不同的态度,认为技术人不纯粹了。那么,扪心自问,你的技术是纯粹的么?你有能力纯粹么?真正的纯粹者,很少。一般人达不到。那么,怎么选择,就是个人的风格了。
当然,过犹不及是对的。岗位属性,多学点总没错,但是,要有自己的职业立场和规划。要明确自己的发展。所以,有些时候,也得避免一些过度开发不该的工作。
如果你在工作中遇到类似的情况,可以考虑以下方法来避免或缓解这种情况:
1.明确角色职责: 确保团队成员清楚自己的角色和职责,并与其他角色进行有效的沟通和协作。
2.良好的团队合作: 架构师和项目经理之间应该有良好的合作关系,相互支持并共同努力实现项目目标。
3.权衡时间分配: 架构师需要合理分配时间在技术设计、评估风险和指导开发团队之间,避免过度投入项目管理活动。
4.提升沟通能力: 有效的沟通对于架构师来说很重要。他们应该能够与利益相关者、开发团队和项目经理进行清晰而准确的沟通,以确保项目顺利进行。
对于架构师和项目经理这两个角色,确实有一些重叠和交叉的方面,我觉得不同的组织或者项目也可能对这两个角色的职责和期望有所不同吧。关于这三个话题,个人有以下看法:
强大的编码能力对于成为一名优秀的架构师确实是有帮助的。理解编码和软件开发的基本原理以及掌握常见编程语言和技术可以使架构师更好地评估技术选型、设计系统架构和与开发团队进行有效的沟通。然而,架构师的职责更广泛,涉及到系统设计、技术规划、性能优化、安全性、可扩展性等方面,因此不仅仅依赖于编码能力
架构师PM化可能体现为过度关注项目进度、里程碑和数字指标,而忽视对实体内容和技术细节的关注。架构师过度强调进度和里程碑,而忽略了对系统质量、可维护性和技术风险的考虑,可能导致技术债务的累积和系统设计上的缺陷。此外,如果架构师过于注重项目管理而缺乏对技术创新和演进的关注,也可能被认为是PM化了。简而言之就是重项目轻技术。
我的工作中未曾遇到过类似情况,有哪些方法可以避免的话,我觉得有以下一些方法:
1、建立清晰的角色定位:明确架构师和项目经理的角色定位和职责范围,确保双方都理解各自的主要职责。
2、建立跨职能合作:架构师和项目经理应该建立良好的合作关系,共同关注项目的技术实施和管理,确保项目目标的达成。
3、强调技术领导力:架构师应该在技术层面发挥领导作用,关注系统设计、技术选型和质量保障等方面,提供技术指导和决策支持。
4、沟通与协作:架构师应该与开发团队保持密切沟通,了解他们的需求和挑战,同时将技术决策和设计理念以清晰的方式传达给项目团队。
1、虽然拥有强大的编码能力对于担任架构师是一项重要的技能,但并不是说一定要具备极高水平的编码能力才能成为一名出色的架构师。架构师的职责包括设计系统架构、制定技术方案、解决复杂的技术问题等,因此深厚的技术理解和广泛的技术知识也是非常重要的。同时,架构师还需要具备良好的沟通能力、团队合作精神以及业务理解能力,能够协调不同利益相关方之间的需求和利益。虽然编码能力对于架构师来说是一项有益的技能,但并不是唯一的关键因素。
2、当一个架构师开始具备项目管理(PM)的特征时,可以观察以下迹象:
项目规划能力:架构师开始关注项目的整体规划、进度安排和资源分配,而不仅仅是关注技术方面的设计。 风险管理能力:架构师开始考虑项目中存在的风险,并采取相应的措施进行管理和应对。 团队管理能力:架构师开始负责管理开发团队,包括分配任务、指导培训以及评估绩效等。 业务理解和产品思维:架构师开始更加关注业务需求和用户体验,能够从整体上思考产品的架构和设计。 3、在我的工作中,我确实遇到过类似的情况。为了避免这种情况,以下是一些好的方法和建议:
拥抱跨职能工作:尽量与不同领域的人合作,了解他们的角色和工作职责,以便更好地协调和沟通。 持续学习和完善技能:架构师需要不断学习和深化技术知识,同时也需要学习项目管理和沟通技巧,以提升自己的综合能力。 建立良好的沟通渠道:与团队成员、项目经理等保持频繁的沟通和信息交流,确保大家对项目目标和任务有清晰的认识。 主动参与项目规划和决策过程:积极参与项目的规划和需求讨论,确保自己对项目整体有清晰的认知,并提供有价值的建议和意见。 建立良好的团队合作氛围:鼓励团队成员之间的合作与分享,激发大家的创造力和积极性,共同解决问题和应对挑战。
百度百科: PM项目管理: 是以项目为对象的系统管理方法,通过一个临时的,专门的柔性组织,对项目进行高效的计划、组织、指导和控制,以实现项目全过程的动态管理和项目目标的总和协调与优化。
架构师: 所谓架构师,就是设计师或结构设计者,软件项目的总体设计师,是软件组织新产品的开发与集成,新技术体系的构建者。
讨论观点一:一定要有很强的编码能力才能担任架构师吗? 首先可以先看一下架构师的定义,首先架构师一定是偏技术型的开发工程师才能担任,并且在项目的开发之初,作为项目的架构师要根据项目的需求拿出可以的架构技术方案来的,并且这些架构方案是可以实在解决shiji问题的。 举例说明,目前国家每年都设有架构师考试的,这个考试也能看出来一些端倪, 系统架构师考试一共有三门课程: 第一门是基础理论课程: 考试的范围很广,计算机基础知识,计算机原理,线程、进程、加密、网络概念相关知识、通信知识、数据库原理、设计模式、还有就是最新一些架构知识等等; 第二门课程是理论知识: 这一部门是需要考生拿出实在的解决方案的,并且可以分析出来一个项目里面解决方案。使用面向对象还是面向过程还是面向服务的方式来解决问题的。以及相关的优缺点等等。 第三门课程是论文: 这一部分是关于论文的考试,考试的范围很广,并且对于题目的选项也很广,比如说有面向需求分析、软件测试及应用、项目管理技术、信息系统开发方法、可靠性软件容错技术、设计模式、信息集成技术、开发模型及应用等等大概有20左右的题型,并且题目每年的题目也有差异,最近几年开始考试数据湖、区块链的技术等 从以上可以看出来架构师也储备的技术很广,并且也要有实际的架构经验才行,目前企业里面一般要求架构师需要搭建架构环境的,比如说微服务,拆分、以及使用springcloud还是其他的开源技术等等。 最后: 所以说,架构师是要具备一定的编码能力才能够担任的。
讨论观点二:我觉得这些迹象表明架构师已经PM化了? 关于架构师PM化的问题,不是说架构师没有技术编码的能力,只不过在进度上面架构师参与的角色开始变化了,架构师不仅要关注技术方案,技术难点框架,还要处理整个项目的进度问题,这个其实就与PM有交叉的部分了。如果架构师一直在项目抓项目进度的话,就已经说明了已经PM化了。项目不存在技术的问题,存在延期的问题这本身就是PM的工作而不是架构师的工作范围。
讨论观点三:我在工作中是否也遇到类似的情况?我认为那些好的方法可以避免? 也遇到过类似的问题,在项目评估的前期就已经把整个项目中遇到的问题,采用的框架已经分析好了,并且都是采用的是成熟的框架,并且公司也有相关的技术储备,如果项目进度还存在延期的话,PM要进行安排是否需要加班或者考虑加入新的成员参与项目,保证项目的进度不会出现问题。架构师也不用进行甘特图的处理或者其他项目管理工具来保证进度的进行。
总结: 一般公司都有技术负责人还有项目负责人,技术负责人主要进行整个项目内技术的管理,比如说技术框架、编码规则等等;这个是有专门的职位,比如说架构师、还有一个开发负责人,这个一般是开发主管,主要管理开发的进度,是否需要加班,是否存在延期,这个都是开发主管的问题。最后,一个项目的能够顺利进行离不开技术负责人也离不开项目负责人。但是随着一些公司的影响,这两个岗位职责开始越来越模糊了。
1、一定要有很强的编码能力才能担任架构师吗?
这个不能一概而论,我能想到的,这几方面的因素需要考虑: 第一,要看领域,是否足够标准化。越是标准化,做架构设计越像堆积木,拼法就那么几种。这种情况下,只要了解了那几套选型各自有什么特点就行了。相反,如果所在的领域不够标准化,任何问题都得追溯到很底层的细节,那么就需要很强的编码能力,并且对实战中的细节了如指掌才行; 第二,要看角色划分,也就是看架构师要解决什么问题,与编码程序员要解决的问题有没有区分度。比如在一个团队中,如果架构师的职责就是去解决那些疑难杂症,解决那些普通程序员解决不了的问题,当然就需要架构师有很强的编码能力。而如果架构师的角色就是去做上层设计,那本身就需要忽略细节、化繁为简,要照顾大局; 第三,要看系统复杂度。在一个简单的系统中,架构要解决的问题与编码要解决的问题基本类似,或者说架构的问题本身就是编码问题的简单组合,那这就需要比较强的编码能力了。相反,如果一个系统很复杂,那么架构要考虑的问题就跟编码中的具体问题产生距离了。比如,架构要考虑每次修改的成本,考虑不规范的编码可能引入的风险如何规避,甚至考虑系统中的哪部分适合独立出来外包出去。这种问题如果懂编码自然处理起来更轻松,但不是很懂的话倒是也能干。当然我说的是“不是很懂”,起码也得是个合格的程序员,而不是啥都不懂就乱指挥。
2、你觉得怎样的迹象表明架构师已经PM化了?
当出现以下四点的时候架构师就已经走向PM化了:第一点,整个公司的架构非常复杂,涉及的域众多,做主架构或者一号位需要大量的协调投入;第二点,不同域之间的资源错配现象严重,需要投入大量精力在锁定资源和推进排期上;第三点,项目结构过于复杂,PM催主架构,主架构催域架构,域架构催开发,层层订,各种站会,代码没几行,会议一大堆;第四点,现在做的一些项目和产品,技术含量其实是不高的,面条式架构,在架构设计和技术上的投入感觉不多。
3、你在工作中是否也遇到类似的情况呢?你认为有哪些好的方法可以避免呢?
是遇到过类似情况,架构师PM化其实就是架构师的脱实向虚,要杜绝,需要从组织、个人和文化上采用手段。
组织上要提倡做实事 首先,需要在组织层面将考核体系脱虚向实,更多的看战功看产出。这个虚其实就是考察形成体系、自洽和表述的能力。我们是需要一个完美的地心说体系,还是一个有用但还不完善的日心说,值得思考。
个人上要做点实事 架构师需要在每个项目中落到实处去;架构方案要自己产出;架构决策一定要做而且要有记录;最好有编码;测试要参与测分和执行。
文化上要对PM式的架构师说不 要形成一个氛围,开发同学可以拒绝整天拉会催进度的架构师。如果一个项目中架构师架构方案和架构决策也不做,可以直接by pass他,开发不如自己上。作为管理者,对于脱实向虚的架构师,要尽早点醒。如果项目中的架构师PM化,所有的问题交流都要拉下面的同学,我们也可以直接by pass他们,并且在绩效上反应,让PM架构师没有生存的空间。
引入卓越工程实现自动化去除对PM的依赖 通过自动化的pipeline,将协调、沟通、事务性的工作固化在流程中。我们目前的自动化只能cover到CI这一部分。如果自动化可以cover到契约测试、功能测试、回归测试甚至发布,通过pipeline就可以驱动事情的推动和可视化,PM也就自然而然没有啥存在的必要了,反过来可以倒逼架构师回归到本职工作上。
1、一定要有很强的编码能力才能担任架构师吗?
架构师需要具备一定的编码能力,更重要的是要有系统设计和架构的能力。包括系统的技术架构、数据架构、应用架构等,以及系统的性能、可扩展性、安全性等方面的考虑。他们更关注的是如何将这些技术组合起来,以实现系统的功能和性能。
2、你觉得怎样的迹象表明架构师已经PM化了?
架构师开始关注项目进度和绩效,而不是系统设计和架构。
架构师开始参与项目管理,而不是专注于技术领域。
架构师开始关注团队成员的个人表现,而不是整个团队的协作和创新。
架构师开始使用项目管理工具和技术,而不是专注于技术实现。
3、你在工作中是否也遇到类似的情况呢?你认为有哪些好的方法可以避免呢?
强调技术能力和实践经验,而不是只关注项目管理。
建立一个良好的团队文化,鼓励创新和合作。
提供足够的资源和支持,以便架构师能够专注于技术领域。
为架构师提供适当的培训和发展机会,以提高他们的技术水平和管理能力。
作为一位程序员,我认为编码能力是非常重要的一项技能,但并不是唯一的技能。架构师需要具备多方面的能力和知识,包括技术、业务、管理等方面。
首先,架构师需要对所涉及的技术有深入的了解和掌握,能够熟练地编写代码并解决技术难题。这是因为架构师需要设计和实现系统的整体架构,需要对系统的各个组件和技术栈有清晰的认识和理解。如果架构师没有足够的编码能力,就无法理解和实现复杂的技术方案,也无法解决系统中的技术问题。
其次,架构师需要具备良好的业务理解能力,能够深入了解业务需求和流程,并将其转化为可执行的技术方案。这是因为架构师需要设计出符合业务需求的系统架构,能够满足业务的性能、可靠性、安全性等方面的要求。如果架构师没有足够的业务理解能力,就无法将业务需求转化为可行的技术方案,也无法满足业务的要求。
此外,架构师还需要具备良好的沟通和管理能力,能够与团队成员、业务人员和其他利益相关者进行有效的沟通和协作。这是因为架构师需要领导和管理团队,协调各方面的利益关系,确保项目的成功实施。如果架构师没有足够的沟通和管理能力,就无法有效地与团队成员和其他利益相关者进行沟通和协作,也无法推动项目的顺利实施。
综上所述,虽然编码能力对于架构师来说是非常重要的一项技能,但并不是唯一的技能。架构师需要具备多方面的能力和知识,才能够胜任这一职位。在实际工作中,架构师需要不断地学习和提升自己的技能和知识,以适应不断变化的技术环境和业务需求。
作为一位程序员,我认为以下几个迹象表明架构师已经PM化了:
缺乏技术深度:如果架构师开始更多地关注项目管理和协调工作,而忽略了技术深度,那么就可能已经PM化了。这意味着他们可能会花更多的时间在计划、预算、进度和风险管理等方面,而不是在设计和实现系统架构上。这种情况下,架构师可能会失去对技术的深入理解和掌握,导致无法提供高质量的技术方案和建议。
缺乏技术领导力:如果架构师开始更多地依赖项目经理或其他团队成员来指导技术决策,而自己不再扮演技术领导者的角色,那么就可能已经PM化了。这意味着他们可能会更多地参与项目管理和协调工作,而不是在技术方面发挥领导作用。这种情况下,架构师可能会失去对技术的影响力和掌控能力,导致无法引领团队和技术发展。
缺乏技术创新能力:如果架构师开始更多地关注现有的技术和解决方案,而不再尝试创新和探索新的技术方案,那么就可能已经PM化了。这意味着他们可能会更多地遵循现有的流程和标准,而不是在技术方面寻求创新和改进。这种情况下,架构师可能会失去对新技术的敏锐度和判断力,导致无法推动技术创新和发展。
缺乏技术影响力:如果架构师开始更多地关注项目的商业价值和利益,而不再关注技术的影响力和价值,那么就可能已经PM化了。这意味着他们可能会更多地考虑如何满足业务需求和利益相关者的要求,而不是在技术方面追求更高的影响力和价值。这种情况下,架构师可能会失去对技术的热爱和追求,导致无法为技术发展做出贡献。
综上所述,以上几个迹象表明架构师已经PM化了。作为一位程序员,我们应该保持技术深度、领导力、创新能力和技术影响力,以便更好地发挥我们的专业优势和价值。同时,我们也应该不断学习和更新自己的知识
当一位资深架构师面临PM化的情况时,可以采取以下方法来避免:
坚持技术深度:作为架构师,应该始终保持对技术的深入理解和掌握。这意味着要不断学习新的技术和知识,并将其应用到实际工作中。只有通过持续的技术学习和实践,才能在设计和实现系统架构时提供高质量的技术方案和建议。
发挥技术领导力:架构师应该积极发挥自己的技术领导力,引领团队和技术发展。这包括与项目经理和其他团队成员合作,共同制定技术决策,并在技术方面发挥领导作用。架构师还可以通过分享自己的经验和知识,帮助其他团队成员提升技术能力,推动整个团队的技术水平提高。
推动技术创新:架构师应该积极推动技术创新和发展,尝试探索新的技术和解决方案,以提高系统的性能、可靠性、安全性等方面的要求。这需要架构师具备敏锐的洞察力和创新意识,能够发现问题并提出创新的解决方案。同时,架构师还需要与其他领域的专家合作,共同推动技术创新的发展。
关注技术影响力:架构师不仅要关注业务需求和利益相关者的要求,还要关注技术的影响力和价值。这意味着要从更广阔的角度考虑技术的影响和贡献,而不仅仅是满足业务需求。架构师可以通过参与技术社区、发表技术文章等方式,提升自己在技术领域的影响力和知名度。
综上所述,避免PM化需要架构师保持对技术的热爱和追求,不断学习和更新自己的知识,同时发挥自己的技术领导力和创新能力,关注技术的影响力和价值。只有这样,我们才能更好地发挥我们的专业优势和价值,成为一名优秀的架构师。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
送我,我是学生!!!
建议:将通义灵码直接接入到阿里云函数计算,让更多的普罗大众可以使用自然语言实现自己的编程需求,例如自动获取招考公告等。 在当今数字化时代,编程不再是专业人士的专属技能。随着人工智能技术的发展,越来越多的普通人也开始尝试通过自然语言来实现自己的编程需求。通义灵码作为一种创新的自然语言处理工具,能够帮助用户更加便捷地完成各种编程任务,比如自动获取招考公告等。为了进一步推广这一技术,建议将通义灵码...
嘿,大家好!👋 今天跟大家分享一些关于开发者的“100件小事”。作为一名程序员,我亲身经历了很多有趣和难忘的事情。下面就来聊聊我体会最深的几件小事吧!😎 开发者的强迫症 代码格式:每次写完代码,我总会不自觉地检查缩进、空格和括号的位置,确保代码整洁美观。有时候,一行代码的格式不对,我就会觉得整个项目都不完美。🛠️ 命名规范:变量和函数的命名一定要有意义,不能随便用a、b、c这样的名字。...
P人出游,你是否需要一个懂你更懂规划的AI导游呢? LLaMA Factory是一款低代码大模型微调框架,集成了百余种开源大模型的高效微调能力,使您无需深入理解复杂算法即可轻松进行模型微调。阿里云的人工智能平台PAI提供一站式机器学习服务,覆盖从数据预处理到预测的全流程,并支持多种深度学习框架与自动化建模,大幅降低了使用难度。通过结合PAI与LLaMA Factory,用户能够充分发挥二者优...
🎁嘿,大家好!👋 ,今天跟大家聊聊AI技术如何助力短剧领域的创新发展。随着AI技术的飞速发展,短剧创作迎来了前所未有的变革。这不仅仅是技术的进步,更是创意和效率的双重提升。🚀 AI助力短剧领域的创新 智能编剧辅助 创意生成:AI可以基于大数据分析,生成多种剧情梗概和创意点子。这对于编剧来说,就像是一个无穷无尽的创意宝库,可以激发更多的灵感。💡 剧本优化:AI还可以帮助编剧优化剧本,检...