2021工作总结

liazylee

已于 2022-02-10 17:06:30 修改

阅读量323

点赞数

文章标签： python

于 2022-01-25 17:50:24 首次发布

本文链接：https://blog.csdn.net/liazylee/article/details/122689633

版权

文章目录

工作

这一年：得到，失去，释怀，成长，完结

2021年还剩不到一周的时间了。是时候回顾今年一年的经历了。我将今年分为上半年跟下半年两部分，上半年：工作是为了生活，下半年：生活是为了工作。

工作

1月-2月-3月-4月-5月-6月

融资

工作上未曾有大的变化，只确定公司会拿到融资。碳作为一个风口，其实刚听到此消息的时候，感觉一下子被上天眷顾了，需要努力成长了。

于是在一月左右建立了gitlab平台，摒弃了公司用了10年之久的svn。同时开始编写git相关文档，为以后协作开发作准备。

同时深感公司tower平台不适合作为资源信息共享以及项目管理工具，于是研究大部分工具，最终选择了jira与confluence分别作为公司项目管理与资源信息共享工具。并在本地服务器上部署运行。

中间公司因为扩张搬了两次办公室，全程安排了网络设备，服务器，监控的采购，安装，部署，使用。

中间因不满产品安排研发人员的任务，使其工作效率变差，而去申请了管理岗位，同时得到反馈消息，会几倍的扩张团队，所以想将一年半的IT技术总监的名头发挥一点作用。为此还专门请教了一些前辈，以及向老板提交了管理岗位的申请，现在想想也是有趣。申请内容如下：

专业技术：带领团队进行技术攻坚，不断精进技术。参与系统架构，技术选型。
任务分解：与其他部门进行沟通，将任务合理的分解分配，确保任务完成，以及质量可控，减少因部门间的沟通而产生的开发效率减慢。
团队建设：进行项目复盘总监，每次迭代之后，总结成功经验，吸取失败教训，提升团队能力；定期举行站会，10到15分钟进行项目进度同步，提出问题，留待会后解决。
质量管理：使用git版本控制，在实践中不断去优化演进代码分支管理规范，同时在此基础上进行code review，让团队不断进步。

现在回顾起来差不多都去执行了，对小型团队来说也非常有用。

7月-10月

从7月开始，仿佛按下了快进键，3位前端，3个后端（包含我）从8月份开始到9月30日，共计完成了6个项目。质量不高，速度还是很快的。当然从这时候开始也没有周六日了，连续的高强度的加班，让我丢失了生活的节奏。多亏了女票闲职在家，为我日夜加班提供了支持。

面试也是被面试

这个方面比较有意思，本身我从毕业6年半到目前为止在IT方面被面试的次数不超过10次，但我这三个月中我面试的人超过100+。奈何公司地理位置不佳，面试的人差强人意。刚开始面试别人还是很紧张的，后面多了就改变策略了，想办法引导求职者到自己擅长的领域，偏讨论的形式。当然工作所需的必备技能也还是会问的，偶尔偏私心也会问公司项目管理制度上的问题，让对方给一些意见。尽量让双方都有收获，也不妄浪费这场面试的时间。

工程师文化实践

因为在面试中被问到公司文化，当时脱口说了一堆“自由”，“效率”，“自驱”，“自动化” 的词语。上网搜索收集，发现自己所想要的跟google推崇的“工程师文化”有异曲同工之妙。于是为公司引进了工程师文化。主持了一次分享会，解释了自己理解的工程师文化：

一切以解决问题为结果导向，遇到问题动手，不惧犯错，从错误成长。
追求效率 一切能解决效率问题的方法、工具都需要推崇。其中尤其指自动化工具，不惜一切代价追求自动化。
自由自我驱动学习，追求信息平等，拥有20%的时间做自己想做的项目。

其中各种详情就不用赘述，说说自己在团队中采取什么措施吧，

实行工程师文化的前提是领导是追求技术的，所以要求自己每天浏览新技术，新方向，对比其中利弊形成文档，以便同事参考学习。大概每两天产出一偏文章，包含git使用、效率工具、编程思想、编码规范、代码示例，初步培养大家在confluence上更新资料习惯。
向下管理团队，任何人都可以平等表达自己的意见与建议，同时保证大家得到上级信息是没有加工的，看到问题，直接说。你解决问题能力有多强，你的意见就有多重要，被大家认可的才能有效的执行。管理人靠的是大家一起形成的共识而进行合作，而不是用层级关系来压迫形成共识合作。管理不仅需要管，还需要理。
每周周三周五抽15min左右的时间来进行站会，周三项目进度以及信息同步，周五大家同步遇到难以解决的问题，以及风险，分配人进行配合解决。以及周五下班之前两小时进行部门间的code review，以及一些开发中的分享。
项目复盘，每次项目结点上线后，全体人员一起完成一个复盘的分析文章，问问自己why，不去思考外部因素，只去解决该问题，考虑自己能去做什么，并将其写入复盘分析文章内。先列出自己部门的优点与缺点，然后跨部门的评测缺点，并提出更高的标准。然后将能被采纳的标准作为okr。形成一个不断反思，不断前进的团队。规范标准也是一步步内部形成。最终创建成一个持续改善的文化。

感受

三个月的时间很短，但是我们尝试了很多。

从永远单兵作战的小作坊（单人svn、代码无规范，项目结构随意）到现在初具规范的成熟团队，git flow合作模式，部门代码风格严格统一，项目文件目录结构合理，往工程化前进，经过两个月的合作形成了自己一套前后端口接口返回格式规范，更是在20%的时间里前后端一起用gitlab-ci做了一套CI/CD，以及完成了6个模块的上线。

在的项目截止日期下的重压下，每个人痛但是快速成长着，庆幸这么高的工作强度以及不断提高的标准，没有人离职。

当然对比成熟的大公司规范，这只是小打小闹，但从0到0.5建设团队，每每想到此处心里还是有点成就感的。