继续整理技术团队最近的年终盘点，「采用我问他答的形式」主要是聆听，今天这位同学，我之前给他打的标签是「老黄牛」，我们先来看他一年来的角色变化：
居然是个完美主义者和凝聚者的「矛盾结合体」落地能力很强，交到手里的东西一定会做，并且会坚持做到最好。
但因为凝聚者属性很高，所以不会要求其他同学跟自己一个要求，作为组员是好事，作为Leader很有问题，这样会导致下属躺平，自己把活做完，死撑。
我其实不太了解为什么，这个同学协调属性和外交属性会急剧下降，反而是凝聚者属性明显上升，难道是因为谈恋爱了吗？
该同学表示应该是跟性格有关，他今年更愿意去多听其他人的意见，而且也不太会拒绝人，有点中庸（其实也有点和稀泥的味道），也想让团队的人都觉得我们团队是一个有温度的，轻松，畅所欲言的团队。
现在进入他的年终总结吧，大家注意他文章用了很多「我们」这个词。
你是谁？
个人·技术成长
之前小钗带着大家使用「DDD按业务线划分组织架构」后，也形成了一个虚拟职能线，分别有前后端「技术委员会」，我是前端技术委员会的成员之一。
在前端委员会里面今年主要做了两件事：一个系统拆分，一个脚手架。
系统拆分
这是一个由vue写的大型系统，已经迭代了「近4年时间了」，是个吓人的老家伙。
技术解决方案已经有些落后，而且最近频繁出现「依赖安装报错」，提交代码报错。
这是因为公司几乎所有的业务都写在了这上面，不同的团队同时在一个项目开发，规范这些根本没法约束。
即使之前统一处理过一次，但是隔段时间又会冒出这些问题来。所以我们决定按照业务对系统进行拆分，各个业务组只需要维护各自的系统，这样的话冲突更少，性能也会更好，然后这个负责人指定给我了。
这也是小钗之前干训班分享的分而治之的思路。
首先进行代码的拆分，我们按照模块将代码进行拆分，单独部署每个拆分出来的系统，这一步进行的还蛮顺利。
然后技术部基建也在进行，刚好这时SSO系统权限管理系统上线，需要去接权限系统，但现在一个系统被拆分成11个子系统，每个系统去接权限十分的麻烦。
而且又要保证现在使用的人的权限保持不变。这时我们想到的方法就是让产品去收集权限，创建角色。产品大佬们很无语，但是也配合我们搞了。
老系统我们是没有角色概念的，就是每个账号需要哪个菜单就勾哪个，现在账号要关联角色，角色关联菜单（「他说的SOD系统，审计要求」）。
让产品来决定哪个账号需要哪些角色，这几乎是「不可能的事」，系统设计之初没有意识到这一点，至少没有往深的想，反正是产品搞，管他们那么多干嘛，他告诉我需要哪些角色，我就赋予哪些角色就行了。
这一拉扯，一拖就是几个月，产品最后无能为力。这个时候我们才回过头来想，是不是可以通过技术手段来解决，跟小伙伴们头脑风暴，最后我们通过技术手段在「两周时间内」解决了问题。
回过头来看这个问题，我们最开始的方案看似没有太大的问题，其实是有「甩锅」的成分，我们把麻烦丢给了产品，产品只能一个个账号去看有哪些权限，哪些权限可以聚合为一个角色，哪账号能配置这个角色。
我们有几百个权限，几百个账号，这靠人是完全不能可能完成的事，但是我们「选择了视而不见」，所以我们还是需要站高一点，凡事都得多想点，而不是只把自己手边的事完成。
脚手架
现在开源脚手架有很多，而且也很强大，这造成了我们使用的脚手架没有统一，大家都「按照自己的喜好」进行选用。而且由于是开源的脚手架，如果要定制一些场景其实还是有点麻烦的，所以我们就打算自己造一个。
这个脚手架也是我们明年前端开发平台的一个开端。这个没有啥具体好说的，就是纯技术方面的规划。
团队·认知升级
我们的团队是公司第一个单元化组，为解决一个具体的业务问题而成立的。
当时的系统基本已经处于瘫痪不可用的状态了，为了能快速解决这个问题，小钗决定成立单元组专门来解决，我被选中了担任这个单元组的负责人。
组建队伍之初，后端老大帮忙找了个大佬来帮忙，自己又拉了一个平时有合作的小伙伴。
前端拉人时还是遇到了些问题，大家一听说是做这个业务其实「都不是很愿意搞」，最后在软磨硬泡之下，还是把团队给建立起来了。然后就开始了系统的优化迭代，然而每天问题反馈群里都有「几十个不同的问题反馈」，当时真的是焦虑得要死。
在这过程中，我们经过了几次大大小小的重构迭代，在2020年底的时候，我们的系统已经解决了大部分的问题，问题反馈也少了很多。
在2021年初的时候，我们开始了新一轮的重构优化，将PHP重构成了go，终于在今年6月份的时候，完成了所有的优化，整个系统的稳定都得到了很大提升。
一年过去了，基本已经没有在反馈啥问题。在这个过程中团队的小伙伴都很给力，特别是在成立单元组的初期，大家顶着压力加班加点的搞，但是看着反馈问题越来越少，系统越来月稳定，大家的「成就感其实挺高的」，觉得自己的努力是有成效的。
在这过程中，公司有几次组织架构的调整，但是对我们单元组来说影响并不大，我们团队的人基本都是稳定，只是平移到其他部门下，而且人员还有了增加。
但由于公司业务变化，我们负责的业务迭代减缓，小组的成员都被借去帮忙，整个小组七零八散，甚至我们组一个前端和后端小伙伴长期支持其他组的业务重构。
最开始的时候其实还并没有意识到这是一个问题，觉得都是在做事嘛，在哪不是做。而且我们都是作为研发部，在别的组人员不足的时候，肯定需要支持嘛，这不是集体荣誉感嘛，然而这就是我「短视的表现」。
后面跟小伙伴沟通的时候，大家普遍觉得今年的「成就感很低」，完全没有当初成立单元组时候的激情。
虽然我们的承担的「压力减小」了，但是我们却「没有感到轻松」，每天奔波在各个组的业务之间，有时候过需求都会忘记我们，而是在快提测的时候发现需要支持，就被拉去搞一下。
最后的结果是个人成就没有，团队成就也没有，难道我们要说我们帮其他小组创造多少收益，这关我们什么事，绩效又不会分我们一点。
你的感悟
关于团队的反思
作为小组leader，我认为这一年的工作「是失败的」。
如何去带领好一个团队，是「我们」一直都在想的问题，所有交给我们的业务都保质保量的完成，然后等着下一波需求来，然后再完成，「依次循环」？
这样肯定不是一个好的团队，这样的话我们只是「一群工具人」，别人有需要就拿去用，不需要就晾着。作为团队leader，我觉得应该有以下的几方面需要做到：
1）领地意识要强，在自己的领地里进行深耕
从一个小头部不断地向大头部移动，实现跃迁。
而作为一个小组要实现跃迁，就需要在自己负责的领域里面进行深耕，将自己组负责的业务做精，只要把自己负责的一亩三分地搞出彩了，才有可能获得更多的资源，而不是靠着给别人组打工，这样白白浪费了自己小组的资源。
2）努力扩展自己的业务边界，有担当
组织架构无论是如何完善，都会有一些三不管地带，这些三不管地带做也可以，不做也行，拉扯起来沟通成本太高。
这时应该适时的站出来，短期看可能接了些不好的业务，让自己组上的成员多了无谓的工作，但是往上看这是团队利益最大化。
3）多站在业务角度看待问题
一个优秀的小组，不仅仅是要能承接需求，也要有能力去PK需求。产品给啥做啥，这样就只是把自己做为一个工具。
需要拔高自己的视野，与产品共同探讨出最优方案，而不是一味的接受。
4）努力为组内小伙伴创造成长机会和成就感
对于中低T职级的伙伴，多组织分享，并且督促他们进行学习成长，让他们觉得有所收获。
而对于一些高T的小伙伴就需要为他们争取更多崭露头角的机会，让他们的技能能够发光发热，让他们去帮小组开疆破土，征伐四方。
个人总结
自从小钗来了后，开始实施「人才运营机制」，几场干训班培训，和平时他不加保留的分享，对整个团队都产生了莫大的助益。
这一年对我来说，最大的改变应该是「认知改变」，提升没提升不好说。
以前我认为作为一个开发，就是你给我原型，我给你代码，然后万事大吉。作为一个leader，上面给我需求，我分给下面的小伙伴，然后开发完成，上线稳定就好了，但是目前其实有了一些「不一样的认知」
除了技术方面，业务方面的事也需要去了解，并且要更加深入到业务中，要有「长期的规划意识」。我是产品和团队开发小伙伴们的沟通桥梁，也需要帮助产品更好理解技术实现，帮助开发小伙伴更好的了解产品的规划。
虽然说了这么多，但是具体怎么去做，我还是不是特别的清楚，目前来说也只到了“知”的地步，希望明年形成自己的一套体系，达到“知行合一”。
小钗总结
总结如人，这个同学的总结很实在，没有抖机灵的部分。
他最大的问题是「没有战略能力」，提不出来目标，所以小组同学只能打零工。
而他显然已经意识到这一点，开始在业务着手，我也希望他能继续深耕，走出一条自己的路线。
加油！好了，今天的分享就到这，希望对各位有用。「原创不易，多多分享」
想要更多交流可以加群：