为什么你有许多架构师,项目依然延期并各种问题
为什么许多项目的技术方案高、大、上,具体实现却种种问题,代码惨不忍睹?
一、架构师欠缺深入编程的一线工作经历,容易泛泛而谈
许多架构师自身并没有长时间的深入编程工作的经历,在技术上的沉淀不足,导致对于软件工程的理解、目标没有清晰的认识。在做架构设计时,非常容易泛泛而谈,并且给出的方案,太过高屋建瓴,缺乏对具体实现的理解和把握。许多架构设计方案,仅仅停留在PPT上,具体的落实完全依靠一线开发人员。
二、技术选型阶段:技术选型不是出于项目需要,而是个人喜好
在技术选型阶段,较好的团队第一件要做的事情,通常并不是局限在技术本身,而是深入的理解业务,搞清楚自己要做的到底是什么,并且明确的给出期望的技术指标。
在此基础之上,团队会开展多次头脑风暴,共同探讨业务流程中可能会涉及的技术细节,以及可选的方案并制定客户认可的技术指标,这一点相当重要,在项目中不能单纯的追求高技术指标,而是权衡时间成本,人力成本,以及项目经费,制定合理的技术指标。
在这一阶段,许多架构师在技术的选型上,往往更倾向使用自己并不熟悉的,甚至完全没有用过的技术,借此机会提高自己,充实自己的简历。他们可能会选择更新,更激进的方案,不管项目是不是真的需要;也不太懂得权衡技术与成本,不愿意选择看上去好像落后一些但更稳定,更可靠,综合成本更低的技术,片面追求高大上,到了实施阶段,就非常容易出现种种不可控的技术因素影响项目的进度及品质。
三、实施阶段:缺乏对开发团队强有力的管理,存在技术断层
这一点几乎在所有的项目中都存在,架构师在设计好方案或搭建好开发框架之后,团队的开发工作与进度管控完全由项目经理控制,架构师不参与团队管理,大部分时间埋头写文档或自己研究技术,这种情况的项目,几乎必然会出现许多技术上的问题并影响项目进度及品质;很多项目的方案非常漂亮,但是具体实现和代码编写却惨不忍睹,就是架构师失职的重要体现。
架构师除了前期技术选型及框架搭建,最重要的工作,以及架构师这一职位的根本意义,我认为在于对整个团队的传、帮、带。
架构师要能够放低姿态,对整个团队进行必要的技术培训,对代码实现的质量担负第一责任,必要时对开发人员进行手把手的帮扶与指导,关于这一点其实没有什么技巧与方法好总结,只能以我自己的经验来说,过去我带过一个全部由工作经验一年以下的小朋友组成的团队,虽然他们的经验和能力有所欠缺,但是好在都很好学,在项目的前两个月中,我每天要花大量的时间用笔、用纸教他们具体怎么分析怎么实现,然后再去Review他们的代码,刚开始的时候所谓的Review,基本是两个人做在一起,看着我重写,这种方式他们进步的非常快,慢慢的在Review的过程中只需要我少少改一部分内容。不用一个月,整个团队的编码风格、代码品质就已经高度一致(注意我说的是高度一致,不是高水平,但这就够了)。
四、缺乏与项目经理的通力协作
与上一点所谈的问题相辅相成,大多数项目的开发阶段项目经理是主要话事人,架构师不参与团队管理。而理想的情况应该是两个人协同共管、架构师做为司令员,主管开发品质,技术建设,项目经理做为政委,主管项目方向、进度、人员问题及部门协调、客户沟通。
项目经理要有一定的包容心,能够容纳一个架构师与己分权,要给予架构师一定的人事权利,甚至是团队人员绩效考评的第一考评人,没有任何权利的管理工作是很难落到实处的。
关于这一点,大概需要一点缘分。
欢迎加我QQ交流探讨,共同学习:279060597,另外我在南京,有南京的朋友吗?
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· 上周热点回顾(2.17-2.23)
· 如何使用 Uni-app 实现视频聊天(源码,支持安卓、iOS)
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章