Python微信订餐小程序课程视频

https://edu.csdn.net/course/detail/36074

Python实战量化交易理财系统

https://edu.csdn.net/course/detail/35475
书接上文：

“年终盘点一对一”之大公司来的同事

“年终盘点一对一”之很刚的同事

继续整理技术团队最近的年终盘点，【采用我问他答的形式】主要是聆听，这里是跟第三位同学质效负责人脱敏后的交流。

这位同学是公司的老同事，是我们的前端架构师，我们先来看看他一年以来自我认知的变化（美女看手相吗，我们聊聊管理玄学？）：

该同学还保持着完美主义的强属性，但是有一些非常重要的变化：

社交属性飙升。凝聚者属性由6变成了15，外交家属性由0变成了10；
思考属性大降。智多星属性由10变成了0，监督员属性由8变成了0；

我们交流下来，发现该同学今年靠自己推动落地的事情不多，更多是放在配合组织和协调资源上了。业务和技术上的思考，虽然有一些，但总体是有所欠缺的，获得的成就感反而很少。

自己做事的成就感变少，协调团队的事情变多，这个是所有转型的同学一定会碰到的事情，现在我们一起走进他的年终总结吧！

你是什么样的人

我正在校准定位

不知不觉 2021 年已经步入尾声，这是我在医联度过的第 5 个年关。这一年无论是公司的战略架构还是个人的认知心态都发生了不小的变化，在此对这一年的所见、所闻、所感做一个总结:

认知变化

在一次团队聚餐中，大家都喝了不少，有一个环节就是每个人三杯可以换小钗一杯和一句平时工作上没有的话，看着吃亏但架不住我们人多啊！

当时小钗说了一些**「对我很受用但于团队算是负能量的话」**，大概是：

只搞前端的话会很受限，建议我多站在团队视野考虑问题，但是也强调了我对于团队的最大价值依旧是前端，让我要兼顾

不得不承认，在此之前我一直是一个以技术为主线的人，为团队出技术方案，解决技术问题就是我为团队贡献的方式。

从技术方面看我算是个尽职的角色，很多问题都亲力亲为去解决。但从上级对我的期待来说，并不是简单的想让我作为一个技术产出者，而是承担起 **「技术管理」**这样的职能，带着大前端的进步。

如果是放在20年的 10+人的前端小作坊，“团伙式”运作还没有抛显出太大问题，但是在21年 40+人的前端团队来说，「缺少方法论的粗放式管理显然是不行的」。

出于老人的势能、亦或是出于小伙伴们对我的信任，大家对我的意见都是比较认可的，我说什么都“信”。但这显然是一把双刃剑。

「利」：

推动事情比较容易，很快能落地，质疑的声音很少，加上我是一个比较好说话的人，往往妥协之后也能达成一致。个人势能可以增加，以后可以做更多的事情。

「弊」：

我的上限变成了团队的上线，当我的视野遇到瓶颈时，我的瓶颈也便上升成了团队的瓶颈，这一点很致命。

大家遇到问题都会找我，经常成为一台**「单点的问答机器」**，每天的信息流非常混杂。

在这种情况下，即使有技术更厉害的同学进来，也很难在短时间内发挥效果。技术的问题一大堆，自己很难抽身去关注业务上的事情（毕竟我还是个业务 leader）。

长此以往，特别是在上升期的团队，这把双刃剑带来的危害会逐渐压过带来的益处，在20年末到21年初的一段时间，我有非常明显的感觉，最外显的是：

团队人数越来越多，但团队的技术实力却没有与之匹配的提升。

小钗曾在一次干训班上讲过：

如果把公司比做一条船，CEO 不是船长也不是舵手，而是这条船的设计师。

如果前端比作**「这条船」，那就应该想办法让里面的船长「高纬高势能同学」、舵手「某个领域专家」、水手「执行同学」**充分协作，让这条船行驶得又快又稳。

于是“前端委员会”变在这样的背景下成立了。

几个阶段

在整个过程中，我的思考经历了三个阶段

一阶段：前端委员会

委员会是一条跨业务线的团队，区别于很多公司的架构组，是一个虚拟的团队。

通过委员会，大前端的方向和推进进度得到了统一的把控，在一段时间内颇有成效。

二阶段：运作框架升级

在年中时，针对委员会制度不完善引起的一些问题。我们明确了使命和愿景，制定了一些规则

会议机制 - 避免低效会议
技术发起机制 - 防止乱搞事情
任务管理机制 - 保持任务的进度持续跟进
人员运营机制 - 给更多同学机会，防止占坑不拉屎的情况

三阶段：上通下达

这一阶段是在 12 月份开始的，主要是为了充分调动委员会的积极性，提升大家的 owner 意识，同时让更多的人参与到技术建设中来，实现整个前端信息的上通下达

技术分队机制 - 给高 T 同学“压力”
势能建设机制 - 提高前端在团队的势能
导师机制 - 新人快速成长
成果输出机制 - 保持团队的信心和活力

于是乎有了下面这个运作流程

：

效果

理想很丰满，现实很骨干，碍于各种因素整个机制大体运作了 60-70% 的程度，但也还是收获了一些成效

每个技术分队多线推进，成为队长的同学 owner 意识明显上升，加班加点都在搞事情，效率和产出明显提升。

参与技术建设的前端同学明显多了起来，大家也有了更多发言和展示的机会，过程中能看出很多同学是很有想法的，技术气氛活跃度提升了。

对我个人来说也带来一些变化，由于委员会同学的成长以及势能提升，技术上找我问问题的人越来越少了，平时噪音少了很多，同时自己从一个技术发起者偏向了协调者，主导推进的事情明显变少了。

你有什么问题

前端的困局

当一个前端在一线开发时，关注点常常在眼前的页面的效果，性能的调优，数据的呈现，很少会关注业务整体逻辑的实现。

比如这个业务的数据在数据库里如何存储的、不同业务的服务间是如何依赖和解耦的等等，这类问题太多了。

加上现在前端领域卷得一批，学都学不赢，哪还有心思仔细研究业务！这就导致一个开发想往业务leader转型时，前端总体难度会比后端大一些，特别需要一个给力的后端副手把控，不然很容易吃大鳖。

曾经有一个S级需求，我作为技术owner对后端把控不严，过程中各种翻车，导致项目多次延期，连续几个周末加班搞得大家很累。

还有就是，与其拘泥于流畅度提升几帧这些小而微的点，公司更关心业务数据这种更宏观层面的东西，而前端往往无法直接接触到这些数据，以及很有难有操作这些数据的能力。

但这个困局也不是没有突破点，身边有很多转型成功例子，比如我们几个大 BOSS 就是前端出身，身边的前端小伙伴也有很多在业务开花结果的案例，这就牵扯到下面这个问题了。

自己有时是一块“石头”

我在技术上很顽固，一直认为技术是自己的生存之本。作为前端技术委员会的负责人，很渴望搞好团队的技术建设，容易出现焦虑和死磕现象。

举个例子，今年中旬公司患者端H5项目已经膨胀到一定量级，构建一次动辄10来分钟，当时我还在患者业务线，经过一番调研后着手进行项目的微前端改造，而开发到不到一半时公司架构调整，我转到了医生业务线，这时基础架子已经搭建完成，也在团队做了技术宣讲。

按理说我可以脱手交接出去，但是还是花了1个月的时间协调开发、测试资源把整个项目上线，并观察运行了一段时间才放心脱手。

这样的后果是什么呢，本来换了新部门，作为业务leader应该首先了解交接过来的业务，和组员一同规划未来的业务方向，这些事情都忽略了。虽然表面上自己解决了问题，但回过头来想，这真的不是为了满足了自己技术上的私心吗？当时真的没有更好的交接方式了吗？作为业务leader尽职了吗？

还有我是一个不太喜欢发表意见人，人一多还容易怯场。特别是和上级一起的时候，经常有他比我职级高，说的肯定是有道理的念头。

时间一长，自己的想法憋在心里实际是很难受的，而且很难锻炼自己表达和梳理方面的能力。这也是我和其他前端同学软实力上很有差距的地方。

你有什么心得

授权的好处

在推进一些技术项目的过程中，经常遇到一种情况：

明明是很有用甚至的紧急的事情，大家也能从中间学到东西，但是推进起来就是很慢，感觉大家都不怎么上心，举个例子：

有个做Leader的同学在推进一个组件库的开发，当他搭好项目架子之后，里面几十个组件以认领的方式交给其他同学做。

开始有积极性高的同学认领了一些，但还是剩下了一些不得不强行安排组件来做，进度一直不理想，后面甚至已经认领的部分推进也推不动了。

有一天我俩散步的时候聊到这个问题，都在唉声叹气，就差说**「这届同学不行了」**之类的话…

说着说着我们突然想到：你之前已经做过类似的事情了，再做也没什么成长，为什么要全部自己负责，管那么细干嘛？

「为什么不交给其他同学来推进呢」，自己划个水，他其实很忙，业务上的事情多的一匹，给年轻人一点机会啊？

于是这个事情就移交给了另一个比较靠谱的同学推进，果然不仅他肝了起来，其他同学参与度也变高了，项目推进一下就快了起来。

至于为什么，后来我想可能有这几个因素：

「功劳得分出去」

当一个Leader推进事情的时候，碍于他的高势能和职级，下面的同学是不敢轻易发言的，大多都是等安排当苦力，做技术的人都知道，这种参与感很低。

因为基建的事情更多是靠职能线这种虚拟组展开，基本都是用自己的时间加班加点去做，没有参与感的事情更不想做了。

换了一个平级的同学来推进没有职级和高势能的束缚，大家畅所欲言发表自己的意见，参与感上升。

一旦某个项目有自己核心参与的一部分，这个项目就成了他的亲或者干儿子，责任心一下就上去。

这个推进的同学往往能逼自己做更多的事情。

这样有潜力的同学能进一步锻炼，参与的同学也能收获成就感。

而且据我观察，很多新人们一起推进的事情，是比老人推进快一些。后来在分队成立后，似乎也有这种现象，委员会周会的气氛整体不如分队周会的气氛，分队有时候拉扯起来就差拍桌子打架了。。。

当然完全撒手不管也不行，那就真的是划水了，很多事情还是得参与，把控节奏，防止项目走偏，顺便刷刷存在感。

业务上的事情

之前的产品需求，就算觉得不太合理，只要产品态度稍微强硬点，只要技术能实现我都尽量会去做，因此有时搞得下面的同学很累。

今年自己这方面原则性加强了很多：业务组leader不应该只考虑技术，业务的问题也要据理力争。

事实上产品也不是一根筋，只要道理讲清楚了，多数情况还是能达成一致的，产研共建嘛。。。还有对项目进度，一旦出现不可控因素，该调整排期就调整，太晚就不发版，不再通宵强行上线。

在某个时期业务也在调整方向，这个阶段业务上没有多少沉淀，在业务方向不明的时候我们该提出什么样的目标，帮助下面小伙伴平稳过渡，不至于左右横条，特别是在业务几乎停滞，为了不让大家闲着，我会到处要活干、找活干，给其他组打工，还会有一些额外的动作：

每周的例会一直没断，大家每周还是在思考总结
特别闲的时候周会变成分享会，分享技术或者扯犊子
有一些偏技术的项目厚脸皮找产品变成业务需求，增加点“KPI“

这样下来，就算目标不明确还是能总体稳住了小团队，有个同学中途有点想法出去面了一下，最后还是留了下来。

年末最后一个月突然来了好几个大需求，大家状态还是在线的，甚至有点打鸡血…我甚至都觉得，有这么饥渴的吗？

你有什么想对小钗说的

之前聚会交流后，我觉得在接下来一年的路径挺清晰，没有太多的困惑，如果有问题还是想在喝酒的时候说，并且我给自己做了一些规划，以更好打开视野。

多思考、多尝试自己不擅长的事情，多请教大师教导，多接受批评，再看几本书：

《宏观经济学》- 最近好多大佬推荐
《系统思考》- 老板之前叫我们看，看了2章就放下了，得捡起来
Web3 相关技术 - 据说是风口…

刚刚看到kindle上老婆加了几本带娃的书，我估计跑不脱。

最后感谢所有家人同事领导对我的帮助，我会更加努力！

技术部如何做复盘——“年终盘点一对一”之前端架构师相关推荐

“年终盘点一对一”之前端架构师
书接上文: "年终盘点一对一"之大公司来的同事 "年终盘点一对一"之很刚的同事继续整理技术团队最近的年终盘点,[采用我问他答的形式]主要是聆听,这里是跟第三位 ...
“年终盘点一对一”之一生之敌孙狗！
书接上文: "年终盘点一对一"想要进步的同学 "年终盘点一对一"之前端架构师 "年终盘点一对一"之大公司来的同事 "年终盘点一对一 ...
赠书 | 年终盘点：超融合架构(HCI)的现状和前景; 中国HCI厂商列表; 全球有哪些HCI厂商？
[编者按] 这篇文章可能会引起一些朋友或读者的不满,但确实是我个人在现阶段的真实看法.欢迎交流,用你的思考.依据来影响我.说服我. 临近年底,会议比较多,也借这个机会见到了一些存储圈和微信群里的朋友, ...
要成为一个好的前端架构师需要做的事情
要成为一个好的前端架构师需要做的事情: 了解业务:全面调研当前业务和竞品的现状,充分理解当前渲染链路和节点,确认当前存在的问题寻找方案:预估未来发展的方向,尽可能多的了解相关解决方案或创新自己的方案 ...
聊聊架构设计做些什么来谈如何成为架构师
阅读目录架构的定义架构是做什么? 做架构的最佳实践什么是好架构如何成为架构师结语又有2周时间没冒泡了,最近实在没有大块的时间来写文章,就当找个理由... 也因为碎片化的时间多了,所以开始刷 ...
python架构师是做什么的_【图片】架构师速成-一个10多年架构师的总结_架构师吧_百度贴吧...
该楼层疑似违规已被系统折叠隐藏此楼查看此楼架构师速成5-小学很高兴你很快的进入了小学,小学的东西会让你更加的耀眼. 阶段: 小学学时:2-3个月升学标准能自己制定目标及计划,get thi ...
web前端进阶之路；web前端不能只做普通程序员；web前端应该向前端架构师前进
有人说产品开发过程中web前端没有结论,只有随需求不停的修改,但是项目必须要有阶段性的结论,作为一个前端开发,如何避免为了某一个需求而陷入反复更改的困境呢?不要把责任全部推到产品不断的需求更改或者设计 ...
做一个java高级程序员甚至架构师应该掌握哪些技术
做人、做事，做架构师——架构师能力模型解析
引子究竟是什么让你在同一个位置上--例如程序员或技术负责人--工作了三年.五年或者更久,而仍然得不到任何的发展空间?你觉得自己已成为技术圈中的大牛,并信心满满地去拿明天就要颁发的某某大奖,然而却仍然 ...

技术部如何做复盘——“年终盘点一对一”之前端架构师