20年职业生涯回顾——企业IT开发
2024-01-27 周六 20:00
职场 ： 总结 工作 精华
企业IT开发
求职与入职
上一份工作结束之后，我是打算歇歇的，之前工作了整整16年，历经5家公司，换了4次工作，每次都是无缝衔接，一点喘息都没有，这次是打算稍微放纵一下，让自己歇一歇，放松一下心神。
实际操作也是让自己放空一下，不过说实话，是有点太放空了，记得当时基本每天起床吃了早饭，啥也不想干，列的TODO list基本就是荒废的状态，稍微推进一点，然后就继续歇着了。这么个状态，是有点太颓废了。
歇息中间，找了媛姐唠嗑，看看她这几年的情况，结果就被她拉下水了。她现在这个公司缺个管技术的老大，看我这正空窗期，就想把我拉过去填坑。
这是个之前完全没接触过的行业，倒是属于传统行业与IT技术相结合的生态位上，之前这些年除了搞互金的那两年，其余都是在纯线上互联网的行业，正好想看看做这种与传统行业结合的打法有什么发展空间，和这边老大聊了聊，又和这个圈子内部的另外一家公司的人聊了一下，两边的感觉都是说这公司缺一个有力的技术老大，评估了一下，觉得自己在技术能力上应该是足够用的，至于管理能力上的经验不足，应该是能够慢慢学习，慢慢补齐的。
既然有了这么一个还算OK的评估结论，觉得应该是搞得动的，就应下了这份差事。事后看来，这个评估结论是相当不靠谱的，后面很多失败也是死在了对自己的定位以及对这家公司的情况的不明了。不过，这些就都是后话了。
企业业务
其实入职前对于这家公司的业务不算很了解，虽说有过一轮接触，又侧面打听了一下，整体感觉还是比较常规的企业IT外包开发的路数，实际真上手了，发现还是隔行如隔山。
这家公司成立了十几年了，一直服务于一类特定行业的客户，以前是做硬件的，近几年转向IT平台业务，个人猜测，估计是硬件这块实在是被竞争得没啥利润空间了，毕竟在中国搞硬件都是薄利，尤其他这种硬件应该是没啥技术壁垒的。其实无论软件，还是硬件，都是用来服务甲方的一类UPS电源的电池体系，只不过甲方规模很大，设备很多，分散在各地。之前硬件是服务电池的，现在软件还是服务电池的，技术含量应该是比硬件更高了。
虽说是IT系统，但是由于业务目标是在硬件身上，所以真搞起来，对于硬件层面的诸多事务也都是必须要了解的，这里面的业务就相当复杂了。
工作内容
从这份工作开始，我开始写详细的每日工作记录，一天不拉的那种。原因是工作内容从简单的一线撸代码的技术工种变成了管理部门的管理性工作，每天要处理的工作内容大增，不做记录的话，很多事情追着追着就丢了，为了不丢事情，必须要记录。现在写工作回顾，也就有了非常一手的原始记录可供回顾了。不过这种非常细节的一手记录也有问题，就是太细节了，无助于还原很多事情的整体面貌，如果要想看明白整体，还是需要有认真梳理的过程的。
顺着时间线重新梳理一下工作内容，估计比较乱啊。
2019-11-6入职，入职也没啥培训，基本是两眼一抹黑的状态，先和现有人员沟通了解一下现有的项目，以及一些正在前期推进中的项目。公司规模不大，研发团队不到十个人，加上项目交付团队，十多个人，承担的项目数量倒是不少，基本主力人员手里至少都负责有1个项目的样子，真是麻雀虽小五脏俱得管着。
从当时的记录看，从我入职的初期就开始暴露内部沟通协调的问题了，完成一个当前正在推进中的项目所需的知识与技能分散在不同人手上，而且任何一个人的知识储备与能力都不足以完成对整件事情的整合与协调，换句话说，没有人有能力将这些分散的资源与能力整合起来，我也不行，因为我还是刚入行的小白状态。而且这个分析结论是我事后总结的，当时应该是完全没有意识到存在这么严重的问题，注意力也完全没有放到这个方向上，还在摸索公司的业务与团队情况。
其实这里已经开始暴露一个问题，就是公司内部缺乏文档机制，所有的行业知识都是存在于前人脑中，无人整理，更没有什么新人培训机制，全靠自己摸索。
推进中的项目也有一些野心很大，想要在甲方内部做得很深入的项目，从企业长期发展的角度看，这种项目如果做成了，是很可能形成一个长期合作关系，能够持续稳定地带来业务收入。不过这么复杂的项目，要和甲方内部N多部门打交道，在这些部门之间进行协调与沟通，甚至要明显触犯其中IT相关部门的利益范围，当时我从技术的角度看就觉得不好搞，现在回看，就那么几条连膛线都做不出来的破枪，肯定是没法玩的。
把第一个月的工作日志看完，就已经觉得头大了，推进中的项目数量众多，且种类纷繁，没有哪两个项目是类似的，还有一堆运维上的破坑，存量项目各种不稳定，时不时地报错出错需要处理，即便不算这些意外状况，存量项目中还有不少没有自动化流程，依然需要每天手工干的活。
觉得再看下去我要抑郁了...换个方式梳理一下试试？
尝试按照项目梳理，一堆项目，交叉推进，一个人可能负责多个项目，或者临时处理某个项目中的某些任务。所以日记写得很杂乱。
按照接触到的项目梳理
11月
- 底层数据采集：算是一个基础性服务，采集各项业务数据，供后面的业务系统使用，如果要搞数据中台，这东西就是中台的数据源引擎。
- 上游数据源经常改版，导致抓取后解析失败，失败了没人管。
- 20年初被盾了，估计是上了反扒了。
尝试切换其他数据源，但是又有质量问题，时效性、字段、各种问题。 - 能源三期：二期已经交付了，尾款没回来吧，还在继续做三期，算是个功能扩展，不过好像要求的东西也不少，记得后面发现不少烂坑。
- 最初还在前期状态，没合同没收到款也没有服务器。
- 中间应该是投入了不少人力资源，但是可以说是毫无产出。
- 要切换数据源，从我们的抓取数据源改到甲方的内部数据源。
- 扔给一个学校很好的小兵去推进，本来也是他一直跟的项目，结果就是推进速度基本为0。最后这个项目的进度拖延搞得我被狠狠k了一把，唉。
- 后面还想规划出一个四期项目。
- 其实三期就是在二期核容算备电时长的基础上附加了5项隐患功能，属于一点锦上添花，以及运维上的部署调整。
- 行拓的海事大屏项目：一个第三方设备监控管理平台，还要管发生设备故障之后的处理流程，东西很多，涉及甲方多个部门，难协调，貌似已经得罪了一些部门，正在被穿小鞋。
- 项目负责人是个之前画UI的，不算懂技术，不知道为什么扔去搞业务对接了，感觉不是能很好地把握甲方需求，各种被甲方带着就跑了，只能啥都应下来，回来也不是很能讲明白都要干什么。
- 一期刚开了个头，跟着又来了一个二期项目，需求很模糊，没有细化，甲方自己都没细化，又想甩锅让我们这个乙方给细化，估计就是做了细化肯定要挨骂。然后预估的报价也谈不拢。还没说里面甲方不爽我们得部门给穿小鞋的问题。
- 负责人的汇报工作被老大k了，没抓到重点需求方向，被带偏了。本质还是人的能力不到位，a.上说了，这就不是一个熟手，赶鸭子上架了。
- 项目从立项启动至今，经历了多次的内外人员变动、需求变动、设计变动，无论是外部对接的负责人，还是内部的项目负责人，都处在一种动荡的状态之中。这种动荡带来了混乱，混乱影响了项目进度，研发过程变得充满了动荡，相关人员无法得到应当知道的全部信息。
- 公司项目缺乏专一的产品经理，所以在从甲方给出的需求文档转换到最终设计的过程中，以及后续的开发过程中，对于产品设计的整体把控和细节优化都缺乏专人负责，每个人只是关注自己负责的一个小局部，存在整理设计不合理，各部分不协调的风险。
*想要在内部搞人人都是产品经理的模式，事后证明太天真了，真这么搞会把自己玩死。* - 验收方是个已经被我们得罪光的部门，未来的验收之路恐怕会非常热闹。
- 12月，甲方需求变动，对管理员的权限划分大变，与原有设计大冲突，如果要改，工作量很大，风险很多。
- 尝试抓住一个新的好做的需求点作为推进项目的抓手，把这个点做出来，让甲方有点收益，能显得项目有进展。
- ***甲方提需求没啥章法，想起一出是一出，时常整点互相矛盾或者变动巨大的需求出来，乙方其实也是毫无章法，产品设计一塌糊涂，靠不完备的设计推动研发，而研发人员穿插在多个新老项目之中，还要不停给老项目的问题擦屁股，基本就是一副以乱对乱的局面。***
- 一个前端显示控件颜色不合理要改颜色的问题，卡了好几周，在公司工作数年的全栈开发说搞不定，最后我花了半个小时给改好了。
*开始逐渐深入一线细节，就发现现有技术团队的各种奇葩事情，例如这个全栈，没上过大学，自学的，水平很菜，就是跟公司的年头长一些，对业务了解的更多一点，莫名其妙地转成了远程工作，管理难度极大。* - 一期还在开头，就想着弄个二期。商务都对接不上。
- 拿回来一堆需求点，我都懒得往这里整理，又多又杂。
- 削峰填谷项目：偏实验性，断断续续。
*典型的缺乏边界、目标、节点的项目，因为缺乏节点，做得有一搭没一搭* - 白盒硬件监控项目：
- 只调通了通信，采集的设备数据能回传，存储这块就已经乱了。
- 通信要过一个VPN，不稳定。
- 老板还把通过VPN通信作为一个技术亮点，实际情况这是一个恶心的瓶颈。只管有无，不管好坏，不管死活，是这里的传统。
- VPN是上一个研发部门负责人搭建的，没文档没说明。
- 老板希望在这个硬件基础上整出一套业务产业链。
- VPN不通的问题，分析了一下潜在的原因，让一个小兵去跟进解决，后来好像还是老子亲子下手才把demo流程跑通了。
- 还想在一个很弱的硬件上跑更复杂的功能，没跑起来。
- 12月份才知道硬件已经采购了1400个，不少钱了，然后才发现生产出来的时候里面程序都没调过，后面还在慢慢改程序，硬件通信模块规格也不合适，没法改了。*不知道之前怎么拍脑袋定的，很随意。*
- 硬件供应商中间还换过，真混乱。
- 通信上，各种不稳定，花式掉线，掉线就不一定能重连回来了。
- 撒出去的白盒回连都打到同一台通信机上，现在部署出去的盒子还只有个位数，如果几千个盒子都部署出去，这套通信方案是否扛得住？根本没有调研论证过，现在就只是一个demo水平，都还没跑通。
- 2020年1月份开始琢磨推动甲方采购硬件，管理平台放到别的项目里面，好乱。
- 梯次360平台：
- 云南高速高点视频监控：自己技术能力不够，又是一个攒局的项目。
- 贪多嚼不烂的典型之一。
- 还想往里嵌入更多功能。
- 还想玩个空手套白狼，拿到合同再转包。
- 电网停电通告数据抓取：对付着跑起来，时常失效，也没人管。
- 第一象限：核心业务平台
- 首任研发老大带队搞的，所有人都离职了，基本没人看得懂了。
*看到了吗，最重要的核心技术与业务平台，已经是没人看得懂的状态了。* - 运维相关：
一堆服务器，部署着不同的服务，有实体机，也有阿里云。- 数据库就好几台，对应不同的业务，又交叉，很乱
- 还有HBASE，是甲方的一个数据仓库，没时间精力做对接。
- 还有一个时常崩溃的时序数据库，没精力深入了解了，好像也没支撑什么重要业务。
- 老板嫌阿里云太贵，希望都尽量归口到实体机上去。
以上是不到一个月touch到的项目，数量真不少，差不多十多个项目，而且里面大部分都是推进中的项目，一堆问题。
12月
-
唐山空调管理：
- 先期丢过来的就是一个一句话的需求。先做了一些初步验证，用一个非常简单的方案解决之，能出效果。
- 第二天就被雷劈，前一日从项目经理那得到的信息非常贫乏，没有上下文，没有完整的技术指标要求，只是说了一嘴要的那个核心动作，其实还有一堆围绕的功能和指标要做。
- 是个之前大屏展示项目的延伸，增加了一个空调管理的功能，急活儿，按说不算复杂，虽说给研发的预算空间不高，尽量重用原有平台的结构，减少代码工程量，应该问题不大。
- 之前那个大屏展示的项目，还希望能够快速复制到其他省市，赚点容易钱，销售能力跟不上，缺人。
大屏项目也没给人家做呢，拿之前的项目复制出来改吧一下吧。 - 换电的电池监控：
- 实时信息走kafka，没给接口，拿不到数据。
- docker崩了一片：
- 运维层面的烂坑，当初设计的部署结构就比较要命。
- 后来好像踩了更大的坑。
- 填报项目：一个不大的活，涉及微信小程序，这边负责微信小程序的人比较弱啊。
- 湖南移动的填报小程序：
- 诈尸啊，上半年交付，由于甲方的一些原因，未能投产，也没能回款。
- 由于未能投产，甲方IT环境网络结构原因也未能完成收尾工作，现在又想给捞出来用，但是还是卡在之前卡住的一些问题上，很无解。
- 只能硬着头皮尝试解决
- 业务核容：
- 运行一般放在半夜，还要有人全程盯着，怕给跑崩了，电池放光。
- 一些甲方正在推进中的项目
- 山东的视频监控，数据已经接入，寻找应用场景
甲方还想要供应商提供源码，服务部署在自己的IT环境中，搞成自主研发的样子。 - 河南的，要搞什么端计算。
- 云南交警高点监控，与 7. 是同一个项目，攒局的模式，想简单地拉几个供应商把活干了。
- *实际情况是前期又看不到钱，供应商自己又不是没事干了，并不积极，然后为了推进项目，得支付不少人力资源，而相关的各种资源都是在现有团队能力之外的，导致成本畸高。*
*领导想得很美好，实际想要达成的要求，没一个是自己能做到的。各种事情纯纯都是口头沟通，没有任何有意义的文档，任务分工只有意向，一点都不明确。老板的思路是以乙方的身份推动事情，订立标准，控制标准的内容，以排除其他竞争者。问题是，这活我不会，团队里面也没人会，之前搞售前写文件的是个技术非常稀松的，我不相信他能把技术关键点控制到供应商+内部团队能做出来而竞争对手做不到的程度。* - 当时对这里面的各种弯弯绕，我是十脸懵逼的状态，各种晕，很多事情是经过了后面这几年的工作，现在再回头看，才能看明白一些端倪。
- 还想往人家的硬件体系里面嵌入一个开源项目，好先得自己nb，实际毫无相关技术能力，人家那么弱的盒子，怎么扛得住？
- 河北移动保时长：
- 靠外挂的白盒硬件获取各项数据，取回来的数据还是用一个demo做的展现，想把数据接入到 9. 第一象限平台处理和管理，好完成后续业务工作。
- 有个合同外的站点出事故了，影响范围挺大的，临时给加了数据采集的硬件，再临时弄一个页面，做数据展示与远程控制。
*各种临时急就章的小活，看似功能大同小异，但是每个东西都不太一样，导致内部管理的项目数量巨大，运维压力超乎想象。* - 前面 17. 里面的项目看着热闹，实际各种推不动，又想返回头来推动这个项目的进展。
- *白盒硬件是个大坑，后来被狠狠坑了一把。*
- 白盒的下位设备型号种类极多，原因是不同品牌厂家、不同年代的型号，都是不一样的，通信协议很多都是自定的，并无行业标准，需要逐一开发适配。
连硬件信号线的种类都五花八门，相同的接口，线序也是各自定义各自的。所以每次新站安装，都需要现场一顿调试，而现有跑现场的人是没有这种调试能力的，需要培训一个安装团队。 - 如何实时检查安装团队在设备现场的安装质量，确实把该调的都调通了，也是问题，设计相关流程与检查指标。
- 白盒的电网停电监控流程，涉及边缘设备上报告警与服务端的轮询检测与监控流程，后面还有相应的数据分析。整个流程涉及一堆业务模块，分属多个相关方。
- 江西监控中心项目：
- 没合同，先做一套数据采集、分析、微信群推送数据结果的功能，用于投标前搏一个好印象分。
- 实现大量复用现有平台功能。
*其实相当于在现有体系内各种拉飞线* - 还希望做些亮点功能，助推投标工作。
- 具体商务那边，还有一堆奇奇怪怪的操作，不是我一个搞技术的能搞得明白的事情了。
商务的人不给力，还要技术这边提供相关支持。 - 后来果然是越做事儿越大，这个那个功能都要，还挣不着钱。
- 微信公众号和小程序注册主体迁移：
- 看着就是个一般事务性工作，不过也是烂事儿一箩筐，有企鹅家微信体系搞的恶心事儿（迁移过程数日，要停服），有之前内部管理很随意而引入的混乱。也有一些固有性复杂度，这么多东西。
11月不到1个月的工作时间，接触到了十多个项目，12月一个月，又新接触到了10个项目，合计20个项目。这是什么含义？基本上1-2天就会要新增一个需要了解的项目，吼吼，太神奇了吧。
回想了一下，当时的状态应该是一副十分懵逼的状态，毕竟是接触了一个全新的行业，涉及的知识从甲方的线上设备管理平台开始，一直到整个业务链路上各种设备，包括我们准备插入数据链路的自研设备，一堆推进中的项目，一堆潜在的项目，还有老板心中的各种未来高大上的项目方向，一时之间要消化的东西太多了。而且这里有一个问题，就是因为刚接触这个行业，在没有一套底层业务逻辑理解的基础的情况下，是没什么办法能把这些项目之间的共性串联起来的，各种事情只能是勉强应对，没法整体思考。
2020年1月
- 清泰数据：
- 老板又想玩点资本运作，弄个新概念，灌到一个新公司里面出去融资。
边缘计算这么个概念，这也炒了好几年了，时至今日，都2024年了，也没见着谁家做起来了。 - 想弄个装点门面的门户页，依然各种需求不明确。
- 又要在门户页里面搞单点登录功能，把一堆散在不同地方的系统用一个单点登录包装起来，这些系统还分属业务链条上下不同的企业，光是以谁为主导，就足够吵翻天了。
- 老板又想玩点资本运作，弄个新概念，灌到一个新公司里面出去融资。
- 运维相关：
- 11月时 10. 把数据库简单理了一下，现在要开始深入了，一堆服务器，都跑着什么业务，没有任何文档记录，全靠人脑子。还想保证业务都是可迁移的，以为用个docker就万事大吉。
事后看来，第一任研发老大走了之后，遗留的问题就非常多。 - 从甲方IT部门要了一堆服务器，没怎么用起来。
很多都是连外网访问都没有的，怎么用都是问题。 - 扔在IDC机房的服务器，很多原始凭证找不到，也没地方可查，非常奇葩。
- 阿里云上的服务器分布在2个账号之下，互相之间想通信要走外网通信，支付外网流量成本，后来逐步收拢到同一个账号下，不用跟跨网段折腾了。
- 11月时 10. 把数据库简单理了一下，现在要开始深入了，一堆服务器，都跑着什么业务，没有任何文档记录，全靠人脑子。还想保证业务都是可迁移的，以为用个docker就万事大吉。
- 2020发展规划：
- 一堆要在2020年拿下的项目、合同。
- 监控外包项目：
- 河北移动容量预警平台扩容：
- 在现有项目上增加功能，一直没能转化为合同。
- 新疆铁塔维护合同续签：
- 89w，把原有人工操作转成自动化。
- 国家电网电动车：
- 软件开发人头外包的活，完全不涉及研发，就是给外包一批人头。
1月底就过年了，节前这20多个日历日，又整出一堆项目的事情。
除了这些项目上的事情，逐步梳理历史坑，对于团队人员，也开始抽出时间加强管理相关的工作。
2月
2020年春节，是新冠疫情全面爆发的春节，节前疫情就已经在武汉开始流行传播，以至于临近春节，武汉宣布封城以应对。而全国其他城市，在春节后，也是又多停摆了一周的时间，在此期间，武汉也好，北京也罢，都在不安与恐惧中为应对疫情做着准备。
疫情之下，甲方爸爸的新项目全停了，年初做的那一堆高大上的规划全成了镜花水月，整个工作重心也只能是保命要紧。
已经签了合同开发中的项目还能推进，人都散在各地，只能是先远程工作了，各种会也是只能远程开，很麻烦。
之前这一片热热闹闹的新老项目，新项目一下子就全都冻结了，只剩一个 11. 项目还能推进开发工作。
2月份研发团队都是在远程工作的状态，属于是被打了一个措手不及，尤其是在团队本身能力就很差的情况下，效率更惨了。
11. 这个项目其实是我入职干了3个月真正第一个带团队做的项目，之前研发团队的工作都是些在老项目里面打滚的活，这是一个全新的项目，不是在那坨老线团里面拉一根飞线就能对付过去的了。
这么一个全新的项目，虽说不复杂，暴露出来的问题着实不少啊。当时在我看来，这个项目没多复杂，关键的技术难点，我写了一个延迟队列来处理；多线程处理的过程，找了一个别人写的生产者消费者的中间件，本身都是很简单的东西，我写好例子，让小兵照着例子填业务逻辑就完了。
实际情况真是让我大开眼界，没想到这边这个开发团队是这么干活的，完全超乎想象。
3月
项目还是之前的项目，疫情一来，也就没有新项目了，没了新项目，公司收入都是问题，老项目还没交付的抓紧做，交付了能收回来尾款。
项目少了，而且疫情前景不明，按说就应该裁减人头，减少开支，但是老板又不舍得，然后搞了一个轮岗制度，人少上点班，也少拿点钱。当时这个方案就是老板直接拍板定的，我一个管理小白，刚接手团队4个月的时间，也不会提出什么意见。
事后看来，在疫情冲击下的应对是有一些错误的。
- 对于疫情持续影响程度的预测很差，当时老板乐观地认为这是一个几个月时间的短期冲击，类似2003年的非典，到夏天就能结束。实际影响长达3年之久。不过这也不能说是多么失败的预测，以当时的局面，谁也说不好这场疫情会怎么发展，不过从公司决策的角度看，至少应该准备一个最差情况下的储备预案，以及相应的业务评估，而不是纯靠走一步看一步的被动应对。
- 轮岗减薪这个方案，其实非常糟糕，人员的工作变得不连续，沟通配合也更困难，相当于如果平均每人只工作70%的天数，很可能最终的产出效率只有50%，算下来亏得更多了。
- 由于疫情影响了跨省交通，很多过年回家的员工都无法正常返岗，导致只能远程工作，然后好像就有点像 趁机多在老家呆一段时间了，当时管理逻辑还是宽松为主，并未深究，事后看来，应该更严厉。
当然，这也是后面被这群SB折腾得实在是郁闷了，看见他们就心烦，早死早超生。 - 减薪导致很多员工心思浮动，觉得收入降低了生活开支扛不住，尤其是身上有房贷的人。当然，如果是想用这个办法赶人走，那是挺好的。缺点就是最想走的一般都是那个重要性最高的。
事后看来，老板不舍得裁人一方面是不想在流动资金很紧张的情况下支付裁员成本，另一方面也是这边之前的招聘能力一直不行，虽说人员流动速度挺高的，但是因为每次招人都很费劲，也是挺舍不得的。
项目上，虽说甲方项目都暂停了，不过前期已经立项只是还没启动的项目很多还有机会推进，老板也是想抓紧这几根救命稻草，能在这么个局面下多推进点项目出来。
运维上，出了一个奇葩坑，域名备案失效了，而且这个重新备案的周期至少是1个月，一个月内，当前域名是不可用的。更奇葩的是，这个事情之前出过，当时是上一任研发部门负责人找开公司的朋友借了一个二级域名临时顶了那段时间。这次只能原样照方抓药，继续去借域名来顶着了。
先把业务恢复起来，然后看为什么域名备案审核失效了，是公司名称不对，数年之前公司曾经有过名称变更，域名备案没有跟着变，估计是被上级管理部门的定期扫描给扫出来了，然后就被咔嚓了。但是公司改名都好几年了，上次备案失效也就是不到1年的光景，也不知道上一次是怎么重新把备案弄回来的，肯定是没有把公司名称填写正确，糊弄过去了，没想到这不到一年时间就又被打脸了。这么重要的事情，就这么糊弄来糊弄去的，唉。
换了临时域名顶着，很多代码里面用到这个域名的地方也得改。
后来最奇葩的事情是我在之后的公司面试的时候居然面到了这个临时域名的提供者，世界真小。
另一个吐血的事情：
一台mysql服务器磁盘满导致数据库崩溃，更要命的是库文件损坏，无法启动……懂运维的朋友应该知道这种局面有多恶心多要命。私下问了一圈DBA，也没啥好主意，都说我遇到大麻烦了。最后也是废了不少时间，重新倒库，算是凑合对付过去了。
这个月就开始发现外部项目的相关事情占用了我很多时间，严重影响部门内部管理工作的资源投入。究其原因，还是人手不够，尤其能干活的人是人手不够的。
总结二三月份的空调项目中的错误
- *前期收到需求的时候想简单对付过去，产生这个心态的原因是手头事情太多太杂，不愿意再碰大项目，能简单对付就简单对付。这是一种在不良工作环境与状态下的不良应激反应。同时，前期沟通不畅，产品经理完全无法获取、理解、传达客户需求。*
*以往觉得一个部门/团队之中，不同岗位角色之间，肯定是有各种能力差别的，但是对于事情的大体理解应该是能够对齐的，只是能力图谱，各自业务环节的细节控制，会有差别，如果做人员对调，肯定是效率下降，但是理论上都还是能把事情做出来的。这里是不能做这种假设的* - *还是太过乐观地假设这边的开发能力了，以为我把业务梳理明白，把核心技术框架搭好，把关键组件写出来，事情就ok了，其实不是的*
- *这一时期，已经进入疫情阶段，老板也开始天天念叨收入少了，所以方方面面上也想着尽量简省一些，降低开发成本。不过老板又想要加这个加那个，先得自己公司能力很强，又能给客户提供更多的附加价值。*
- *由于疫情影响，过年之后团队难以尽快回京，只能是远程工作，开发协调工作也是在远程进行，很混乱。*
其实要总结的问题很多，这里先简单列一下，后面再慢慢写。
4月
已经开始有人提出离职了，在每日工作记录中已经开始有大片的面试记录，和工作交接记录，果然最先提出离职的，都是能力相对较强的人。
项目上，都还是之前列出的这些项目。老板一如既往地往高大上的方向去想，看看怎么能把项目盘子做大一些。至于怎么落地，开发团队是不是能接得住，那是不在老板的考虑范围内的，这一点，后面再吐槽。
项目24这个外包出去的活，外包工作做的很好，汇报的时候表现亮眼，老板看了眼红啊，自己这个研发团队在对比之下，就显得更加的不给力了。
随着工作的深入展开，踩到的坑也是越来越多了。
各种奇葩bug开始浮现，不是以前没有这些bug，只是要么没人注意到，要么被发现了也没人督促去追查，要求给出明确的bug定位、原因分析、修复说明，都是对付对付，没人再念叨了，就当没发生。
项目2依赖于项目1抓取的数据，想要切换到甲方内部的结构化存储的数据源，不用抓取这么“low”的数据获取方式，结果抽样验证了一圈，数据质量堪忧啊，没法用啊。老板的意思，是让我们趁此机会帮助甲方改进、优化他们的数据质量。
发现真是一个体系出来的人，甲方也是找供应商干活，自己啥也不懂，也没法验收供应商的工作质量，乙方内部也是这种感觉。
项目1的某个抓取停了3个月了，居然才被发现，然后项目部给某个甲方出报告的活就干不了了，问题是，那个报告是1个月出一次，好神奇。
老板提出来要做培训资料，哈哈，早干什么去了？
- 微信机器人、微信群：相当于一个利用微信的功能模块，在微信群里面发送一些报警、统计之类的信息，但是微信机器人这东西发消息发多了，就会被封号，很头疼。
运维坑，服务器物理部署位置有IDC机房，甲方机房，有阿里云，还有办公区的机器，有时候会有不同区域间的大规模数据传输，阿里云的外网通信又是收费的，做之前就没有规划，经常是随手挑一台就用了，后面都得踩坑。
很多人都开始离职，或者准备离职了，到做离职交接的时候，才知道之前那些前人做的老项目，现在这波人其实基本没接住。
5月
项目4这种之前闹着玩的项目因为老板找了新的合伙人入伙，商务推进的能力有所加强，又要尝试推进销售，让技术这边协助。
后续推进了一些，然后发现之前做过一轮和甲方的数据对接，但是1年过去，两边的人都已经离职了，各种死无对证，从头再来吧，两边对之前的方案都不满意。webservice这么古老又难用的东西，这年头为什么还有人在用，又不是维护老古董。
江西的几个项目没拿到，被截胡了。不过后面又出现了一些转机。
项目11偶发稳定性问题，项目部署在某甲方的虚拟化服务器上，推测是甲方机房运维最近在做迁移和部署调整，导致的问题。
- 梯次锂电出厂检测：新项目，用到之前项目5的硬件，规模不小。部分开发工作打算找外包做了。
研发部已经有一种不好的发展趋势了，一堆整天糊弄来糊弄去的货，原来泡在老项目里面，整体说：“啊，我在整这个，我在整那个”。我也没精力追查到底干啥呢，现在几个新项目要干活出结果了，就糊弄不下去了，都露馅了，连带老项目上糊弄事的情况也都开始暴露出来，南郭先生都现出原形了。
项目5因为有实际落地的场景了，项目28上面要用，又要开始推进。
运维：有台机器上的pm2崩了，最欢快的是之前都没做过pm2 save，根本不知道上面托管了哪些服务进程，相关配置又是什么，还好新招的几个人给力，连上硕果仅存的1个老员工，一起去排查去了，不用我去吐血3升而亡了。不过后面还是发现没有全部救捞出来，唉。
感觉事情逐步开始理顺了一些。
6月
开始接触一些项目前期的工作，老板希望我能多在项目前期介入，给项目部门提供一些支撑。在我看来，就是没人干活了，项目部自己的活搞不定，老想着拉别人帮着背锅。
项目28的算法部分找了个外面的公司来协助，需要进行数据与业务方面的全方位对接工作。
后面调试过程中，把用到的项目5的硬件电路板烧了，悲剧。
后面越来越发现问题大，满是坑。
项目27开始尝试接口对接，发现甲方想要的东西和我们规划的东西完全两码事嘛。
管理上，开始尝试推动绩效改革，不能再是混日子也没问题的模式了。
项目2要推动终验，好回款，又是一堆乱七八糟的事情，整个项目当初做的乱七八糟，各个环节都是碎得一地，当初老员工在的时候就各种 弄不明白扔着，现在又要从头梳理，要完成交付的话，还有不少工作量。这东西当初就是用东拼西凑的手段拼凑出来的，根本不是一个可以交付的状态，基本上需要把前人工作看懂，再整个重写。
部署环境也要调整，甲方爸爸内部在调整运维结构，给我们的部署环境换了，然后数据源也要跟着换，最神奇的是数据格式也要跟着换，这tmd，不是又要重新做了。甲方那边，运维环境调整也是一堆的坑，因为不同服务器之间的网络不一定是连通的，很可能变成给我们的业务服务器无法访问数据库，然后调整部署环境内部的这些配置还需要n跳的沟通，往来一次，不知道几天就过去了。
项目16又崩了，而且是很可能未来还会继续崩的那种崩，还得想办法优化，避免内存干爆了崩掉的问题。
甲方爸爸的系统一升级改版，我们这边就又要一片兵荒马乱。
人力：扛到6月，业务也没啥起色，疫情一点消退的迹象都没有，各个部门的人都有工作不饱和的问题，要开始琢磨减少人头，降低开支的问题了，公司收入困难，养不起这么多人，运维层面，还有不少不合理的开支，属于为之前的技术债付利息的状态，也没精力收拾。
7月
项目28，项目2，项目5，项目4，都在推进中，虽说问题一堆，好歹还是有进展的状态，不像以前很多项目，就是原地打转。
前阵子是没活干，这个月开始，项目上又要加班赶工，唉。
- 锂电换电数据抓取：好像是个每个月都要跑一次的玩意儿，很头疼。
项目9原本依赖的数据源是抓取回来的，这几个月甲方爸爸收紧了反爬，等于之前的数据源断了，新对接的数据源数据极度不全，要想维持一个可用的数据质量，需要跟甲方干很多扯皮的活，还得在工程层面重新对接，加各种校验、补全手段。虽说活不少，不过必须干，不然全线业务都要出事。
- 浙江负荷响应：一个比较应急的项目，按说应该属于老板心心念念想搞的，不过好像也没挣到钱。
项目11所在的机器又崩了，唉，运维坑一堆，各种连环套。
项目4最近在推进的潜在客户多起来了，尤其是项目30相当于是给项目4的应用前景打了个样板。开始设计整体技术方案与架构，又是个不小的工程。
8月
项目30因为要操作的站点数量巨大，第一轮试验，发现启动调度跑一遍的速度太慢了，还要尝试通过调整线程数、并发度、增加部署的服务进程量等方式来提速。
和管理层的矛盾已经开始浮现并激化了。
项目11上线后bug不断，当初看到的问题，让研发改，根本没改，测试的工作质量是：偶然有一次成功运行起来了，就算测试通过。
老板定了个目标，下半年，开始有项目合同能签订了，要用半年时间，干出原计划一年的营收。
老板又拉个个大学老师，想给公司增加点AI算法做数据分析的能力。
运维大坑，一批原来托管在某IDC的服务器，托管合同到期，IDC涨价10倍，晕死，换了个IDC，结果服务器拉过去，起不来了，硬盘配置有问题，啊啊~~ 都是什么运维烂坑啊。当初配服务器的人，根本没有把硬盘配置持久化，导致重启后丢失了所有硬盘配置，还得想办法远程解决之。
月中的时候，彻底和管理层闹崩了，滚蛋吧。
[回目录](328470102.md)
12472 字