最近看大家都在做总结，技术文章写到一半，干脆我也还是先总结一下吧。从哪里开始呢，先从小钗大师“看手相”开始吧（美女看手相吗，我们聊聊管理玄学？），下图是做的测试结果

 

 

小钗大师解卦：

“完美超过18分算是强属性 所以你有鞭策大家干活的属性，而你又是个实干家，所以很多事喜欢自己下场干，并且你是强属性完美者，所以交给你的事情往往能做得很彻底，但会比较固执。 你的转折点可能是做leader后，推进者属性会让你不停的让项目组按照你的时间点和目标前进，但你又是个完美主义者，可能会要求组员按你的标准来，在一些小问题上纠结，最后容易大家都不开心。”

大师果然是大师，在基于对我的了解和“命相”上给出了一些结论，还是很中肯的，对自我认知有很大借鉴意义。

今年由于公司调整，来到了新团队。回顾这半年多做的事情。大部分产出，都是支持基建提效，或者利用技术方案优化业务。参与过一些业务迭代开发、也担任过几个业务迭代的技术owner角色。还作为技术owner承接了一个公司重要项目，时间紧、压力大、挨骂多、加班程度突破个人历史最高峰。

基建方面

熟悉了公司devops流程和一部分实现原理，统一优化了前端项目和node服务在发布系统中apollo配置的集成。

持续迭代的前端监控，解决了公司业务中traceId导致的用户体验问题、发现和解决了很多线上反馈或者没有发现的bug，还发现了能在风控能力上有一定作为，实现了一些监控。系统本身做了优化和提升，提高了查询性能、节省了存储空间、丰富了问题追踪视角。

承接了前端委员会提出的路由控制的问题，设计和开发了前端路由重定向系统，解决链接地址或者生成的二维码地址发送给客户或者三方之后是能修改的问题，对公司内部系统相互访问同样适用。同时能够统计访问记录，用以确定对外链接使用情况。也支持短链接功能，缩短地址长度。设计方案在前期还是做的很完善，系统稳定运行中，接入业务也在逐渐增长。下个迭代会和公司泳道完美融合。

和后端同事，合作开发了公共数据图表平台，一个内部配置化快速生成图表的平台，不需要建立业务代码仓库，也无需发版。通过ETL把业务数据导入到分析型数据库，做内部管理台使用的数据可视化图表和表格展示，开发速度快，数据查询速度快，是一个提效产出的平台，并且支持嵌入到任何管理台。目前已经接入了几个业务统计图表和供应链数据相关的表格。

解决开源工具Jaeger崩溃问题，开发GRPC本地工具WEB版等。

在新团队之后负责公司的NODE技术相关的建设，公司服务端是使用的GO，因此前端团队在使用NODE的原则主要是做一些工具或者独立服务于大前端开发的提效项目。不做业务接口、不做BFF层，避免一个业务接口周期中出现GO和NODE服务相互调用的情况（以前有存在这样的项目，现在已经被GO重构掉了）。

NODE方面，主要是设计开发和技术支持了几个独立服务项目，统一了技术选型和开发约定。团队内部通过开发迭代，拉入了很多前端同学参与进来，前期设计要求比较严格，需要经历需求分析、技术调研，技术评审。整个任务分配比较细，也不会占用大家太多时间，边做边培训的方式，带大家学习技术和理解方案设计。总体来说，也是因为有需求和问题需要解决，我们才会介入做相关事情，并不会为了发展技术而发展技术，大家的精力也大都在业务上。

业务方面

有做几个业务迭代，也做过几次业务技术owner，都中规中矩吧。有个小程序短视频优化的需求，大致就是模仿微博短视频的交互方案做优化迭代，发现滚动条很死板做了一个技术优化方案： JS进度条顺滑版实现 。平时比较关注自己小组负责的C端核心业务，排查和协助解决了很多线上问题。偶尔也会接到产品技术方案的调研，协助产品分析相关的业务数据等等的事情，经过一些拉扯，对业务的运行情况也有了一定了解。

在业务投入上，显得比较弱，也有部分原因是这半年多里，组织调整我换过4个小组，加上最后要说的CEO驾驶舱项目，占用了我两个多月的全部精力。

CEO驾驶舱项目

重点说下这个项目的情况吧（项目情况可以通过这篇博客了解：【开源】数字化转型实操——非要度量效能，从《一分钟日报》开始）。项目产品就是技术老大叶小钗，最初是在内部群里说了，需要几个开发同事做他的项目，对技术有要求。我自己刚好也没有特别多的业务忙，就第一个报名了，然后就被指定为技术owner了。最初就是开局一张图，产品原型、具体细节啥的都没有，讲了下需求，给了个三周的时间，就让先做了。当时实际并没有在认知上对齐，毕竟小钗和老板拉扯了一两个月才想清楚的需求，一张图说一个小时就让我们开发了。公司需要解决问题，必须要赶时间，才能赶上一些重要节点。总之还是挺难的，要在规定时间内完成，当时业务也是特别忙，想调动多一点人力都几乎没有。中途还有很多实现细节的讨论和拉扯，也出现过几次需求变动。

因为并非是一个非常清楚的产品需求设计，作为owner我也必然会介入更多的思考才能跑通功能并且认可合理性。前期在保障完成核心功能和认知没有完全对齐的情况下，我是希望能砍一些功能和实现方式。就出现了很多对刚的场景。但小钗是大领导，不像平时和产品沟通，我几乎是被全方面碾压，当然这个事情本身也是受限于能力差异与认知差异。

一方面我要思考的更多，一方面我也是全力在开发，时间紧张，工作强度大，加上休息略微不足。我站在我对产品的理解上，希望能给大家减少点开发负担也同时减少一些不合理的需求。我和小x讨论的过程中出现了很多分歧，在自我经过思考后得出了对应的结论，本身比较坚持。但实际上有时候是信息理解偏差加上自我思维固化导致的，其实自己也不一定就是对的（有时候也是对的）。在自我已经基于分析得出了结论之后，就会很固执，也没有完全带入到对方的思维中。这次项目经过了很多拉扯对刚，自己因为固执也挨骂不少，有时候骂了还是刚，还挨骂，当然大部分时候确实是我的问题。

固执会增加很多内耗，也是骂挨多了，就比较有意识的去注意这一点，后面会尽可能多的去站在对方的角度倾听和思考，有时候听了也不完全觉得对，但是能理解对方的立场。级别又比对方低，就还是听大哥的吧！通过很多轮拉扯，认知慢慢也开始对齐了起来，项目也汇报的比较顺利，自己也认可了自我的固执不正确，所以后面挨骂的就少了些。

现在想想当时也是很有意思，我每次极力的和小钗对刚，然后刚不下去之后，我就转身问服务端负责的同事，结果他都是认为小钗现在非常需要这些功能，我们必须完全支持他，争辩是没有意义的，其他同事默默吃瓜。最后我都是低头认怂，继续干吧。在这种压力下，还是比较容易激发出人身上的问题的，经过这个项目我现在也是非常认同我很固执了，我会时常提醒自己很固执这个事情，希望慢慢能改掉这方面的问题（但常常还是很容易会觉得我是对的）。妥协也是一种减少内耗的方式，留一些时间来认证，而不是一定立刻要争个输赢（但我有这方面争夺的强属性，可怕～）。

生活方面，这次项目封闭式开发，小钗想着大家太辛苦了每天都让点好吃的外卖（可报销），饮料随时供奉（不报销、花了我不少钱）。生活费超标了不少，经常向我家领导申请多给点钱，异地恋很多年，好不容易到我现在这边来上班了，刚好就遇到我在做这个项目，每天看不到我人，感觉还是异地一样。小伙伴们也是相爱相杀到最后相互同情、互相鼓励，体会到了团队的乐趣和团结。

今年的词条

多变

部门调整、四处坐客，不停调整找到适合自己做的事情。

基建

发现问题、提出方案、推动和协助解决问题、收获成绩。

坚持

坚持积极主动抗事、坚持技术学习、有价值的事情坚持做下去。

固执

唉，还真是个问题～

标签：21,迭代,项目,固执,业务,技术,开发,收获
来源： https://www.cnblogs.com/1wen/p/15827824.html