作为一个空降的架构师，如何开展新工作？ 工作面试网络协议金山Firefox
程序员文章站
2022-07-06 13:45:42
...
我是今年三月作为架构师加入当前公司的。
作为一个空降的架构师，如何开展新工作？
先来介绍一下公司背景：
技术部在公司属于辅助部门，主要工作是开发软件给业务部门用
业务部门负责赚钱，在公司业务部的话语权非常高，因此，我们技术部老大反复强调，业务部就是上帝。
我所在的组有一个开发了快7年的产品，由于刚开始开发时没有想过什么架构的问题，因此，整个项目代码十分混乱，每一个模块除了该模块的开发者外，其他人根本看不懂。
用管技术的副总的话来说，系统再不重构迟早有一天会出问题。因此，副总把我招进公司，挑头负责架构设计和系统重构。但是，除了副总，公司里其他人却不愿意重构。
存在的问题
技术部老大的观点是，可以重构，但必须在完成旧系统的维护工作和新功能之后再重构。
我所在组的老大的观点是暂时不要重构，等过两年实在维护不了再说。
其他开发人员的观点是千万不要重构，因为重构相当于重新开发，会大大增加他们工作量。
测试人员同样不支持重构。
这两个多月我不断地和开发人员探讨重构的意义，也写了好多Demo给他们证明重构后的架构能降低新需求的开发难度。但是，大多数开发人员还是不愿意重构，他们宁肯在旧系统上赖着，也不愿意学习一些新的东西。
我试图强制开发人员按照我设计的架构编写代码，结果各种磨洋工，然后向上级反映我的架构严重拖累了开发进度。
总而言之，除了管技术的副总在面试我时流露出较强的重构系统的想法，其他人员都不愿意重构。而我和技术副总之间隔了两层领导，我不大好绕过组老大和部门老大向副总汇报工作。
我问了几个朋友的建议，他们是这样告诉我的
A: 你和别人的冲突点在于：你的重构加重了我的工作量，那么我不愿意做。
所以，你需要为重构争取时间，比如需求hold 60%，大家来做重构，或者专人来做这件事，之后做整体架构迁移。
当架构成型后，逐步让大家将新需求移往新架构，而有同学负责做老架构的迁移工作。
首先要保证的，是在沉重的开发压力下，不能加重现有研发同学的负担。否则想推动，几乎不可能。也许我做半年一年就走了，为什么要为你的kpi加班呢？
其次要保证的，是架构的稳定性，新架构不能动摇现有业务。
最后要说服现部门的leader，在能够争取到减少新业务开发的情况下（最好是停止），使用新架构在之后会带来减少工作量、规范代码结构、稳定架构的作用，并且不会让大家有额外的负担。和leader协商，用哪种途径去解决这件事。
否则，你重构就要我工作量double，工资又不double，我才不做呢。
B:不分析政治的事情，光从做事的角度来讲步骤：
分析业务，流程，文档，代码。
在完全不依赖其他开发人员的前提下，理清系统的大致脉络，列出功能蓝图。
基于1/2步工作完成的情况下，再评估到底要不要重构！
这是作为架构师接手一个陌生项目所必须的前期布局。千万不要为了重构而重构。重构可能只是手段，而非目的。
4、融入到原来的那群技术人员内部去，并把最重要的设计、最核心的代码，抓到自己手里。
5、理想状态就是业务部门需要什么新功能，你起码可以评估出工作量
到一个公司，最重要的是完成对关键岗位的站位，不仅仅需要领导的任命，更需要落实成一个事实。后者更重要。
C:我的建议：首先你要确定，公司目前的代码究竟有没有必要进行重构，重构的成本有多高？重构的受益有多大？
其次，如果你真的确定要重构，那么你要想明白别人究竟想不想重构，因为你是管理岗，管理岗意味着你不是具体敲代码的那个人，而是你要指挥一堆人按照你的想法敲代码，那么别人支持不支持你，就显得至关重要了。
事实上，人和人想法各异，就算大家都想重构，他们究竟想重构到什么程度，是部分重构还是完全推倒重来，这差别很大。如何协调意见向左的人，如何求同存异，是管理人员的必备技能。
而一切的基础是，首先你要取得大家的信任。让大家服气你。作为架构师，你起码技术过硬，作为主导重构的核心人员，你又要表现出足够的胸怀和气度以证明你可以肩负起这个任务，很多情况下总有谈不拢的时候，在这个时候，你本人是否有服众实力，直接决定了你的想法是否能够如期推进。
如果大家有什么好的建议可以评论告诉我，也可以加入架构师交流群：671017482一起交流，学习。
大家觉得作为一个空降的架构师，得如何开展新工作呢？
作为一个空降的架构师，如何开展新工作？
先来介绍一下公司背景：
技术部在公司属于辅助部门，主要工作是开发软件给业务部门用
业务部门负责赚钱，在公司业务部的话语权非常高，因此，我们技术部老大反复强调，业务部就是上帝。
我所在的组有一个开发了快7年的产品，由于刚开始开发时没有想过什么架构的问题，因此，整个项目代码十分混乱，每一个模块除了该模块的开发者外，其他人根本看不懂。
用管技术的副总的话来说，系统再不重构迟早有一天会出问题。因此，副总把我招进公司，挑头负责架构设计和系统重构。但是，除了副总，公司里其他人却不愿意重构。
存在的问题
技术部老大的观点是，可以重构，但必须在完成旧系统的维护工作和新功能之后再重构。
我所在组的老大的观点是暂时不要重构，等过两年实在维护不了再说。
其他开发人员的观点是千万不要重构，因为重构相当于重新开发，会大大增加他们工作量。
测试人员同样不支持重构。
这两个多月我不断地和开发人员探讨重构的意义，也写了好多Demo给他们证明重构后的架构能降低新需求的开发难度。但是，大多数开发人员还是不愿意重构，他们宁肯在旧系统上赖着，也不愿意学习一些新的东西。
我试图强制开发人员按照我设计的架构编写代码，结果各种磨洋工，然后向上级反映我的架构严重拖累了开发进度。
总而言之，除了管技术的副总在面试我时流露出较强的重构系统的想法，其他人员都不愿意重构。而我和技术副总之间隔了两层领导，我不大好绕过组老大和部门老大向副总汇报工作。
我问了几个朋友的建议，他们是这样告诉我的
A: 你和别人的冲突点在于：你的重构加重了我的工作量，那么我不愿意做。
所以，你需要为重构争取时间，比如需求hold 60%，大家来做重构，或者专人来做这件事，之后做整体架构迁移。
当架构成型后，逐步让大家将新需求移往新架构，而有同学负责做老架构的迁移工作。
首先要保证的，是在沉重的开发压力下，不能加重现有研发同学的负担。否则想推动，几乎不可能。也许我做半年一年就走了，为什么要为你的kpi加班呢？
其次要保证的，是架构的稳定性，新架构不能动摇现有业务。
最后要说服现部门的leader，在能够争取到减少新业务开发的情况下（最好是停止），使用新架构在之后会带来减少工作量、规范代码结构、稳定架构的作用，并且不会让大家有额外的负担。和leader协商，用哪种途径去解决这件事。
否则，你重构就要我工作量double，工资又不double，我才不做呢。
B:不分析政治的事情，光从做事的角度来讲步骤：
分析业务，流程，文档，代码。
在完全不依赖其他开发人员的前提下，理清系统的大致脉络，列出功能蓝图。
基于1/2步工作完成的情况下，再评估到底要不要重构！
这是作为架构师接手一个陌生项目所必须的前期布局。千万不要为了重构而重构。重构可能只是手段，而非目的。
4、融入到原来的那群技术人员内部去，并把最重要的设计、最核心的代码，抓到自己手里。
5、理想状态就是业务部门需要什么新功能，你起码可以评估出工作量
到一个公司，最重要的是完成对关键岗位的站位，不仅仅需要领导的任命，更需要落实成一个事实。后者更重要。
C:我的建议：首先你要确定，公司目前的代码究竟有没有必要进行重构，重构的成本有多高？重构的受益有多大？
其次，如果你真的确定要重构，那么你要想明白别人究竟想不想重构，因为你是管理岗，管理岗意味着你不是具体敲代码的那个人，而是你要指挥一堆人按照你的想法敲代码，那么别人支持不支持你，就显得至关重要了。
事实上，人和人想法各异，就算大家都想重构，他们究竟想重构到什么程度，是部分重构还是完全推倒重来，这差别很大。如何协调意见向左的人，如何求同存异，是管理人员的必备技能。
而一切的基础是，首先你要取得大家的信任。让大家服气你。作为架构师，你起码技术过硬，作为主导重构的核心人员，你又要表现出足够的胸怀和气度以证明你可以肩负起这个任务，很多情况下总有谈不拢的时候，在这个时候，你本人是否有服众实力，直接决定了你的想法是否能够如期推进。
如果大家有什么好的建议可以评论告诉我，也可以加入架构师交流群：671017482一起交流，学习。
大家觉得作为一个空降的架构师，得如何开展新工作呢？