我的日常工作内容

自我管理，自组织，多功能型。

1. 行文背景

21年年中在阅读完《走出软件作坊》 后，被作者的职业素养和思维深度所折服，抱着"寻找同类"的想法在豆瓣上阅读其他人对这本书的书评时，偶然翻到了作者本人对读者质疑的解答 —— 《走出软件作坊》- 我每天的工作主要干什么？为什么能有时间来写博客，甚至还能接受网友的IM交流，是怎么做到的？ 。

本文勉强算得上是一篇拙劣的模仿。目的也不是什么如作者一般地回答疑问，更多只是一丝顿悟 —— 写一篇类似的博客于己有着不少益处：

1. 总结自己当下的状态，同时从一个第三方视角来审视自己的工作流程和工作内容。
2. 过往针对这类问题有过断断续续的思考，这次正好借机清空下大脑的缓存，给大脑减压。
3. 也有助于向别人解释自己的工作，避免反复絮叨。

2. 个人职业背景

进入软件开发行业的这十余年里，未曾进入互联网相关公司，全部都是在传统软件行业企业里度过。

误打误撞以非科班的身份进入这行，一开始也是以技术卫道士为目标，死扣技术细节；奈何多年的实际工作经历下最终迫使自己面对现实，以实际遇到的问题为导向，逐步将自己改造成现在这种"自认为依然是做技术的，但周边人都认为我是在做管理"的，所谓的技术管理人员。

3. 工作内容

实际的工作过程中，我的工作内容比较杂，时间相对应也会比较灵活。

以下只能算是整体而言的工作内容分布，具体到某一天或者某一周，很可能我只在做其中的一件。

另外这些工作之间比较交织，不少时候属于交替进行，甚至同步进行在。比如在发现某个桎梏点，或者技术难点，我基本都会同步开一遍文档，一来进行问题跟踪，二来也是总结解决过程中的一些关键信息进行公开，以同步各方的认知，集思广益地解决。

3.1 实际的研发工作

这一部分大约会占据50%左右的工作时间。也是为什么我自认还是个"做技术的"的主要原因。

关于这部分工作内容，有几点需要说明的是：

1. 我基本不会涉及具体的业务代码编写。
2. 这里的研发工作量大部分属于是我自己给自己安排的任务。
   2.1 研究/预演新技术；
   2.2 解决遇到的疑难技术问题；
   2.3 迭代优化项目脚手架和二方库；
   2.4 其他。例如编写研发效能工具，禅道二次开发等等。

针对上面谈到的这些研发任务，我这里挨个解释下：

1. 所谓的"新技术"其实并不新，只能算是团队之前接触很少，没有相关沉淀。这类需求的来源一是繁杂业务本身的需要，二来则是为了享受技术发展带来的红利。前者例子如微服务技术栈，MQ的应用等，后者例子如Docker，K8S等。
2. 所谓的“疑难技术问题”普遍也并不难，毕竟是传统软件行业，还是个做电子政务的，技术难点往往是因为相关人员的技术功底不足，加上过往的历史债太多，造成问题看上去比较飘渺，这个时候就需要一个经验比较丰富的人能够比较快地定位到问题根源。
3. 一个技术团队内部必然是需要一个项目脚手架和多个二方库来沉淀过往的研发经验以及通用业务技术实现的，这里面就必然涉及到对它们的长期维护和更新，以保证过往的经验能够让未来走得更平稳，更快。这也是我这一小节工作的主要内容，也算是对于上面两个小节"新技术研究"和"疑难技术问题解决"的总结沉淀。

总体来说，这一部分的工作还算比较轻松，毕竟都是属于应用级的技术，业务场景对技术要求也不高。而且亲自下场解决技术问题，有助于建立在团队中的技术影响力。毕竟这行业属于"Talk Is Cheap，Show Me The Code"，手底下没两把刷子，难以服众。

3.2 文档编写

这一部分的内容会占据我整体工作时间的30%左右。而且不出意外的话该占比在接下来会保持稳步地增长。

自2018年底在集团总公司层面推动WIKI的使用以来，时至今日，因为公司特点和自身的工作内容性质，WIKI里大部分的文档都是我在补充完善。

在这过去的五年多里，随着对于WIKI理念理解的深入，以及相关工具操作的熟悉，逐步形成了一些指导思想：

1. 记录什么？ Everything。任何你你花费了一番精力查找到的相关资料、解决的问题等都是应用被记录下来的，哪怕只有一句提示性的话语。太阳之下无新鲜事，你遇到的问题团队其他成员十有八九会遇到，你花费了一些时间，TA十有八九也会如此。
2. 当下只要求内容。格式不重要、文笔不重要、写在哪里也不重要。我们远未到要求这些的地步，而且这些可以在之后的迭代中慢慢完善，重要的是你得先有个原型，然后才能雕琢。推进一件事情阻力最大是在0到1的起步阶段，作为主导者，你需要主动开启这一步。
3. 文档最重要的要求是持续更新。
   3.1 我们甚至允许你将文档里的内容自己再实践一遍，但是最后应该将在实践过程中的一些自我发现总结到对应文档下面。针对常见的“我感觉没什么可总结的；没有什么特别的”，所谓千人千面，每个人的学习路途，知识储备都是存在差异，这势必会导致面对同一个问题会产生各种不同的看法和联想，所以肯定是存在已存在文档没有提及的角度和内容。
   3.2 我们同样允许你在已经有了解决方案的前提下试点新技术，但基本要求依然是要沉淀下相应的文档介绍和关键说明。一番操作下来，除了你之外谁都不知道发生了什么，对于以后团队的发展没有助力，甚至会因为人员变动出现系统不稳定的情况。这是我们不希望看到的。

文档中主要记录的类目大概有：

1. 解决过的难点。我当下的工作职责里有一部分就是解答团队成员的技术问题，目前形成的一个处理流程就是我会先尝试在文库中查找是否有类似的解决方案，然后再进行接下来的操作。
   1.1 如果有过，那么直接把链接发给对方并提醒如果解决了那就视情况在文档评论区补充一两句自己的发现（一般没下文，但这个流程依然需要坚持去做）。
   1.2 如果没有过，那么在帮助TA解决的过程中，会留意为什么对方无法解决，以及过程中发现的一些其他问题也会分别记录下来，并且在主要问题解决之后，连带汇总分析这些问题一并进行文档的补充完善 —— 针对"对方为什么没有解决"，在行文时进行专门提醒相关的缺失知识点；针对发现的其他问题，更新或补充相关的文档；针对主体问题，视情况进行文档的补充。（这一步并没有清晰的标准，我会视当时的具体情况进行补充完善，比如如果相关知识点较少或者当时比较忙，我就只会把一些关键点进行记录，留待未来某天再进行完善，这个完善的人可能是我，也可能是其他人，最重要的是要先创建这个原型）
2. 某个需求解决方案较多时。典型如excel操作，Java开源组件层出不穷，这种情况下除了在脚手架中约定实现方式外，对于历史项目等类似的情况，会单独开辟文档罗列各种解决方案，并且简要说明相关优缺点，供相关负责人自行决策。
3. 脚手架或二方库说明。主要包括相关技术细节介绍和使用技巧介绍，一来针对性地满足日常的业务开发工作，二来吸引那些有兴趣参与共建的团队成员。
4. 人员培训内容。受限于公司业务特点和工作流程，以及团队组成的一些问题，培训存在内容，频次和效果等诸多不稳定因素，这种情况下我们采取“先编写相关的在线培训文档，然后以该培训文档为基础进行培训”的方式，确保每次培训至少有一些东西被沉淀下来。
5. 二方库的发布版本信息。针对组织内部的二方库，我们选择将版本更新说明信息的发布放在文库中实现。
6. 各种内部规范和约定。针对团队内部的一些默契，以及逐步新增的一些规范和约定，我们也是选择将其放到文库中进行公开，方便团队成员在线实时浏览。
7. 其他需要共享的信息内容。

总体而言，虽然WIKI的推进已经进入了第五个年头，但进展依然很缓慢。不过相较于最开始的两三年，好的现象已经发生了 —— 部分团队已经完全接受了我所推广的相关理念，并且在不断实践中，也已经看到了明显的效果。

3.3 优化研发流程

这一部分大约会占到整体工作时间的10%。

正是基于我作为问题解决者的角色，我有机会遇到整个研发流程中各种各样的问题，再加上骨子里对于重复操作的厌恶，于是在18年年底的时候就在部门内部明确提出要进行DevOps流程改进，并在过去这几年里私下持续性地积蓄相关理论知识和相关工具操作经验。

奈何行业以及公司的业务特点，这项工作一直以来都属于剃头挑子 —— 一头热的状态，虽然在坚持不懈的宣讲和推广下，在20年时候这项改良终于成功地被集团公司所注意到，但实际进展也并没有加快多少。

所以优化研发流程这项工作一直以来都属于“自己给自己加戏” —— 领导们没有DevOps的全局概念，部分领导甚至不认为当下的流程存在什么大问题，或者问题不在于你说的这些。而当你提出某项改良时，领导觉得这确实有效果，但TA更多的只是默许你有空的时候可以去试一试，前提是不要影响了本职工作。

基于以上现状，所以当下我对于流程优化的操作大概属于这样一个“发现-思考-优化”流程：

1. 持续积累DevOps相关理论知识。（过往已经看了近十本相关的DevOps书籍，以及10+个直接或相关的极客时间专栏等）
2. 基于发现的问题，在DevOps理论知识的指导下，思考如何通过解决问题向DevOps标准化流程靠拢，剔除导致问题出现的流程中的人工操作，由机器取代。

因为属于自下而上地推进改良，因此我很难像常规幻想的那样 —— 制定一个完美的方案，然后按部就班地执行下去，谁要是敢当拦路虎，阻挡前进的脚步，那就让领导出面直接摁死。

在实际的执行过程中，往往只能通过不断的尝试来找出这堵看似牢不可破的效率之墙上那几块有希望松动的砖头，然后通过持续地低成本尝试来撬下第一块、第二块、第三块；形成连锁效应之后继续类似的操作，直到理论学习中的那个流程初步成型，实现自运转。

关于第一块砖是哪个，有哪些可选项，谁都没有经验；每个公司，每个部门，甚至每个小组中都会存在差异。确实存在共性，但这不是本文的重点，所以这里先不谈。

举例一些推行过程中的具体操作：

1. 基于已经形成的协作默契和操作流程进行禅道二开。作为一个一天php都没正经学过，完全是在禅道二开中熟悉php的选手，除了体验到php的灵活性和开发效率外，我更是见识到了两个部门将禅道里的一套基本概念愣是玩出两套完全不同的理解来，而且都和禅道的基本概念大相径庭。例如在现在所在的平台部门： "产品"对应实际的项目组，"版本"对应每天打包的制品包，"发布"对应通过测试的制品包等等。
2. 根据发现的问题制定研发规范并推进落地。例如编码规范，提交规范等等。
3. 基于团队现状实现的Windows环境下自动化打包部署
4. 将SSL自签证书的操作自助化，最终实现这项操作由研发向技术支持的交接。

3.4 其他

这一部分占比大约是10%。

原本是打算分别进行介绍的，但一来上面文字细节有些多了，二来也是这部分工作集内部时间分布过于不稳定，所以干脆合并在一起介绍。

1. 培训。 这个主要是一些基础编码技能培训，脚手架和二方库技术宣讲，以及日常工作中遇到的问题经过汇总提炼之后的介绍。
2. 给有需要的业务团队一起评审相关技术方案。
3. 和售前人员一起评审宣讲PPT的技术部分，并答疑。
4. 阶段性向上汇报工作内容，以及一些接下来想要实施的改良。
5. 面试高级研发人员。
6. 等等。

4. 参考

1. 《走出软件作坊》
2. 《走出软件作坊》- 我每天的工作主要干什么？
3. 入行这几年
4. 架构师一职的自我理解
5. 软件开发之新人入门推荐
6. 软件开发-年限与能力
7. 研发路上的总结与反思
8. 谈谈加速源码理解的几种方法
9. 传统软件行业中技术团队的发展(现状篇)
10. 《进化——从孤胆极客到高效团队》