20年职业生涯回顾——企业IT开发下

2024-01-27 周六 20:00

2025-06-09 16:51

职场： 总结工作精华

企业IT开发下篇

复盘分析

行业分析

之前工作的这十几年，都是在互联网企业之中，即便是P2P网贷行业，第一家也是个互联网风格的团队，第二家虽说风格很传统，不过研发团队的工作风格也还是偏互联网风格的。这次是第一次来做了一个非互联网行业的IT业务，开始接触企业级IT开发，后来最近这几年的这份工作中也对企业IT开发这个行业有了一些更多的了解。

与互联网行业不同，企业IT开发基本都是定制需求，大企业通常有内部的IT开发部门，自己需要的IT软件内部开发解决掉了，忙不过来也多是找外部的人力外包；但是某些中小企业，或者是没有内部IT部门的大型企业，就会考虑整体项目外包的方式。而随着企业能力、组织形式的不同，外包也有不同的方式，开发、运维，整个业务链条中各个部分是否外包出去，要看甲方自身的技术团队规模与能力。

这段工作经历中，这家公司主要服务于一家大型垄断性国企，甲方总体规模很大，不过总部规模很小，实际业务都是在各省的分公司负责，总部只负责一些全局性系统建设，大战略方向的工作，具体实施都是招标外包企业完成。

对于我所在的这样一家规模不大的小企业而言，能够抓住这么一个大型甲方，如果能够有一批持续稳定推进中的项目，公司的日常运营状态可以说就是持续进入正轨了。当然，持续拿项目并不是一件容易的事情，大项目一般都会给到大型国有IT开发企业，小公司很难抢到，本身也未必有足够的能力去完成项目开发工作嘛。而小项目也不乏竞争者，毕竟中国这地方，三条腿的蛤蟆难找，两条腿的人，近乎无限量供应的。

而且以前做互联网行业，给到研发部门的产品需求都是内部生产出来的需求，由有经验的产品经理完成产品设计，或者至少是已经完成了一个大体的构想，再拉上技术研发一起敲定产品细节，大家的沟通、协作，都是在一个共同体系之内。这次是要和一个本身能力相对一般的外部甲方合作，本以为公司原有的开发团队运转了这么多年，应该是有足够经验的，实际则是踩了不少的坑。

企业分析

这家公司成立了近20年了，老板属于是从所学专业到后来工作，再到创立这家公司，都是这个行业的业内人士，在行业中摸爬滚打20多年，对于自己做的这块业务了如指掌。这家公司之前是做电池相关配套硬件的，近几年才开始转型做软件，最初应该是老板通过自身的行业人脉，找了一个业内懂业务的做研发经理，不过听说之前也是经历过一轮大规模的技术方案变动，相当于推倒重来了，不过相关人员早都已经离职了，也就只是听说而已，细节早已不可考。

老板是公司的销售老大，带着项目部的小兵跑甲方，铺关系，跑项目，完成项目前期工作，拿到合同。拿回来的项目一般都会涉及研发的工作，可能是新的系统开发，也可能是给项目部的人员做一些配合性工作，视具体项目内容而定。

项目部主要负责非IT类的一些人工交付工作，规模不大。

据说这几年虽说IT项目做了不少，参见前面我罗列的工作内容，不过最后算账，好像也没啥盈利，老板还亏了不少小钱钱。不过由于我在这家公司的时间不长，也没怎么接触到一个项目的完整核算数据，对此并无发言权。

团队情况

前面说了之前有个业内懂行的研发经理，后来是离职了，听说是和老板闹掰了走的。距离我入职估计差不多有1年时间。这中间，一直没有招到研发经理，研发部门是让一个在上一任研发经理在职时招进来的售前工程师顶缸管理，可惜此人不怎么懂技术，主业是搞 to B、to G的售前，和搞研发其实完全是两种路数，只是售前要玩什么，我其实也没怎么搞懂。

更悲剧的事情是就这么一个不懂技术研发的研发负责人，在我入职前也已经走了，虽说人走了，还在干活，处于人肉身回老家，然后还在远程给这边干点活的状态，倒不是他在老家有什么更好的工作，完全是因为孩子在老家，然后家里发生严重内斗，闹得不可开交，他没办法必须回去收拾家务的残局。感觉老板在这个问题上应该也是挺郁闷挺悲剧的吧。

研发团队十几个人，有一个前端，一个全栈（还是人在老家远程工作），几个Python，几个NodeJS，一个测试，普遍水平不高，除了一个不知道应该放到项目还是放到研发的名校应届生，其他基本都是些二本三本、大专之类的货色，就只有之前说的那个代管研发部的售前工程师是个一本学校出来的。

吐槽与反省

这段工作经历在我前后经历的6家公司之中绝对算是相当不爽的一段，不过收获其实也很多，虽说之后这几年每每想起来，都觉得很痛苦，不过确实也是为后来下一份工作中的很多事情做出了一些铺垫，让我对于现实世界的运行规则有了更加深入的认识与理解。

这段吐槽会很多，估计些得会比较乱。

刚一入职，开始了解现有项目，就发现了一件极为奇葩的事情，就是这个技术团队的Git使用方式，奇葩得超乎想象。[之前那家P2P](328470113.md)每次上线手工逐行合并代码已经够奇葩的了，这里更神奇，所有的项目基本都是从同一个项目fork出来的，这没什么，复用原有框架嘛，不过这里fork的方式是从原来的项目再开一个新分支给全新项目，看前面工作内容里面罗列的这几十个项目，在Git上就没几个项目，全是不同的分支来的。据说中间还迁移过Git，所以提交记录也不全。
其实在一开始，这就是一个非常明显的危险信号了，这么不靠谱的状态，已经预警了这个团队的奇葩，更是预示着整个公司的奇葩，只是我因为从来没和这种水平的货有过交集，所以对这种奇葩没有概念，没能想到这些异常信号背后的深意。
不久和项目部一起开一个项目会，是老板从客户那边拿到了一个项目，回来给项目部的项目经理讲一遍，相当于是任务派发与项目交接，前期老板负责销售，商务沟通到了这个项目，中间就应该是项目经理和售前工程师去跟进拿项目需求细节，然后评估成本、周期，准备招投标相关工作，最后投标成功，签订合同，进入研发阶段。
本着快速学习了解行业、了解业务的目标，我也参会了，并做了以研发视角看项目的会议记录，把研发主要关注的内容记录下来。结果会后老板让项目经理发会议记录，这货居然基本是一个字都没有记，然后看着我在会上一通记录，直接来找我要会议记录。
本着都是同事，能帮就帮一下的原则，我也就把我的会议记录发给他了，还提醒他这是从研发视角做的记录，从项目经理的角度看，是要根据这份记录做增补和修正的，结果后来看到发出来的邮件，原封不动，一字不差。
更奇葩的一点，其实是对于这么一个并不完备的会议记录，老板并没有提出任何异议，这事儿就这么过去了。
后来发现这个项目经理就是个漏勺，跟甲方开会，什么都干不了，甲方说的东西听不懂也记不下来，去了跟没去一样。需要甲方配合什么事情，让他去和甲方沟通对接，就那办事儿的水平，张嘴第一句话就能把甲方得罪一个底儿掉，幸好是甲方对接人脾气好，要是当时我是甲方，肯定直接在群里开骂了。
但是就这么一个货，居然就在这儿一直这么干下去了，老板还真是一点意见都没有啊。
刚开始给研发团队开每日早会，就发现内部沟通有很多问题，例如测试给研发报bug，只会说什么什么功能报错了，或者是不工作，不会描述错误情况，当然，内部更没有什么文档系统或者bug共享系统用来做记录，一切全靠嘴说脑子记，就这帮脑子，绝对是最后什么都记不住的结果。
不只是研发团队内部沟通混乱，跨部门沟通更混乱。项目部经常抱怨研发维护的某些平台不可用，实际呢，平台好好的，可能是里面某个功能模块故障了，但是项目部从来不会明确说明具体是哪里出了什么问题，如果要去问，就会被东拉西扯地扯一堆闲篇儿，事后想来，估计是项目部的人想着可以把锅甩到研发负责的系统上面，这样自己不干活的结果就有理由搪塞了。
等于说所有人都在指望其他人出错，好给自己的错误找到甩锅的理由。
这么多的项目，光是整理出来的就有30个，其他小的、规划中的都还没计数进来，对于任何一个企业来说，都是不小的管理和维护压力，而这些项目的开发质量都停留在一个demo级别的水平上，很多项目本身的开发工作都不能说是完成了，就只是写了一个demo，把核心功能做出个样子来了，就拿去交付了，根本没有办法保证长期持续稳定运行，开发时就没有考虑长期运行的各种要求。说白了，就是核心开发者（研发老大）没有做过这么大的项目，更没有经历过项目长期运行，多次迭代演化的经验，只能做到对着业务需求，把业务功能弄出来交差，结果就是项目交付验收之后的运营维护成本畸高，因为日常始终要有人跟在项目后面不停擦屁股，而且当核心开发离职之后，接手的人其实是没有能力把擦屁股的活干好的，这就成了一个死局。公司的日常经营性利润（如果有的话）也就都被这些地方吸干了。
之前上一任开发老大的工作组织模式是他负责所有的核心业务功能，从数据抓取到业务计算，最后所有产出的数据入库，开发语言用的是Python。其他小兵只负责写前端展示的那一层，所以用的是Node.JS。当时觉得这个分工逻辑挺奇葩的，按说这么多的项目，不应该这么玩儿吧。不过后来经历了这一圈，有点想明白为什么是这么一个逻辑了，而且以当时的团队情况来看，这么一个分工其实是最合理的。
1. 首先，电池维护这个很窄的行业里面，人才数量其实是很少的，绝大部分人就是跑设备现场，拿着说明书干活的，没什么真正理解电池特性与相关业务的人，更别说懂软件开发的人，我认为同时具备这两种知识的人，在市场上是不存在的，换句话说，企业不可能直接从市场上购买到直接可用的人，无论出多高的工资，更别提企业IT开发行业其实利润水平不高这一局面了。既然没有现成的成品人才，那么就只能是企业内部慢慢培养，寻找适合的单技能线人才，培养其在另一条技能线上的能力，最终成为一个即懂业务，又懂软开的人才。
2. 这里面其实有一个悖论，既然市场上没什么这方面的人才，说明这种人才需求本身就是一个没什么市场的需求，换言之，这个行业非常小，小到可能只有很少几家企业在做这个方向。这也就意味着对于员工而言，掌握两个距离很远的行业的知识技能，并不会在市场上获得更高的溢价，因为这个市场压根儿就不存在。既然没有溢价，为什么还要去做呢？没价值啊。
  企业需要的人才市场上没有，自己培养且不说成本如何，员工自己都不会有价值认同，怎么办？说白了，这项技能要求对于员工来说是与这家公司强绑定的，既然工作技能要求与公司强绑定，那么对应的权益是不是也是应该有强绑定，两者之间才算做到了责权对等一致。
3. 上一任开发老大等于是把所有核心技能要求全部收在自己身上，至少解决了小兵是否要去深入了解业务这一矛盾性问题，上述的核心矛盾都收敛在他一个人身上，总比分散在整个团队每个人身上来得容易处理。
  同时，对团队其他人的能力要求大幅降低了，通过市场招聘来的人，按说就能够胜任简化后的工作了。
可惜实际情况并没有这么理想。一方面，上一任的IT能力不足，留下了一堆坑，不过我相信这些坑在他还在位的时候，还是能够被hold住的，毕竟主事之人还在，冤有头债有主。但是当他离职之后，等于最核心，唯一的双线技能人才流失了，IT开发部门不再拥有了解业务的能力。注意我的措辞，是这个部门不再拥有这项能力。市场上招聘来的人员是接不住这块业务的，整个部门的局面就只能是每况愈下了。
而且从我的感官来看，公司的招聘能力问题很大，或者直白的说，招聘能力不行。
上一任老大是懂行业业务，IT全靠摸索，没经验，所以他招人的时候，其实是不知道怎么评估受试者的水平与价值的，导致的结果就是招来的人性价比明显低于市场平均水平，用更高的工资从人力市场上购买了更低的工作能力。相对差一些的能力在处理相对简单的业务任务时还不明显，当这位老大离职的时候，就要暴雷了。从我了解到的历史来看，当他离职的时候，老板并没有认为这是一个多么严重的事件，还是想着从市场上招人来就能顶住，而且还是让即将离职的部门老大自己招人来接班。我猜当时给的招聘价码也未必有多高。
一个已经和老板闹翻，准备滚蛋的部门一号位，还有多少耐心愿意把交接工作做好？而且我严重怀疑这一交接过程老板根本就没有介入，没有监督，完全放羊了。事实是最后招了一个很能忽悠的糊涂蛋来接手开发上的这一摊事情，导致部门状况迅速下滑。
最终呈现出来的感官效果，就是一个人，合同工资1w5，能力只有1w，原来扛事儿顶住天的人走了，指望这个人能扛住2w+难度的事情，毕竟工资相当于是高配了，但实际结果是人的能力完全扛不住事情，干出来的产出可能都不值5千块。很有印度人那种Jugaad精神（参见随水的《【解读】为什么印度发展制造业那么难》）。你算算这里面要有多大的亏损，一个人这样也就算了，公司最大的成本部门一个个的都这样，不亏才怪。
关于技术方案选型：
1. 公司的项目开发语言选择的是Python，经过了[上一份工作](328470117.md)使用Python作为主力开发语言的经历，我就知道这会是一个大坑。
  Python这种语言，设计当初设计就是用来解决一些临时跑一次的小活用的，本身具有短小简单的特点，一堆语法糖，方便快速开发，相同任务需求下，代码量小，开发速度快。同时，因为设计就是处理小活儿，不用太考虑执行效率，为了方便开发调试，直接使用了解释执行的方式，多线程并发直接被GIL卡死，后世整出一堆多进程的框架来解决这个问题。其实即便没有GIL的问题，Python的运行效率也没啥希望，在各种常用开发语言的运行效率排行榜上常年垫底，基本上是要比第二慢还要慢上小10倍的速度。毕竟，人家设计就是用来写那些只运行一次的简单任务，而不是用来扛大活。
  上面说的所有这些Python的问题，都不是致命问题，Python对于企业级开发最致命的问题在于其变量的无类型以及数据结构组织管理的随意性，这种高度灵活随意的模式在快速开发时有助于提高效率，但是却是一种不可维护的代码结构，如果开发人员是有着丰富企业级项目开发经验，严格遵守相关准则的老手，情况可能还好；如果开发过程本身就是以快速完工，不求严格质量的方式进行的，那么后续的工作就会变得非常恐怖。
  我有一个比喻，就是用Python开发，前期，例如第一年，由于其灵活快速的特性，与其他“传统”开发语言相比，可以获得效率加倍的buff，看起来效率极佳，能够快速完成业务目标。但是由于Python这种无类型、低约束的灵活性，使得其不具有有效重构的手段，代码优化成本极高，之后每年，对旧代码的维护，扩展过程中，所需要的时间精力成本都要加倍，也就是说到第二年，由于技术债务，开发效率就和“传统”企业级开发语言接近了，而且由于技术债复利的特性，到第三年，Python的开发效率就已经毫无优势，反而成为拖累了。如果整个项目规模很大，周期很长，那么几年之后，就只有项目失败这一条死路可走了。
2. 最早拍板选择Python技术方案的那位老哥，我没有见过，不过从听到的各种事迹来看，他应该是属于懂行业业务，学过点编程语言，没完整做过大项目。现在看得到的这套项目开发架构，听说是他反复搞了2-3遍才找到的方案，说明是反复摸索了数次，而不是有架构设计的能力和经验。
  踩过的坑少，自然不会知道Python的这些烂事儿，估计当初他选Python，是看中了Python比较适合写爬虫抓取类任务，因为当初他开始搞的时候，首先就是要解决抓取原始数据的问题。不过后面真正放量开始抓取的时候，明显又遇到了GIL导致多线程效率不行的问题，这位大哥又整了一个挺奇葩的多进程架构，来规避多线程性能不行的问题。
  只是他这套多进程的方案，完全没考虑使用个成熟点的中间件，而是大开脑洞地自己攒了一套方案。这个方案虽说挺拉胯的，但是再怎么说，是能正常运转起来的，能够完成业务目标，只是后续维护使用，非常之麻烦。打个比方，原本这么一个大活，应该用个12气缸发动机来驱动，结果因为Python的GIL，导致不好造12缸发动机，就弄了12个单缸发动机来干活。确实躲开了造不出12缸发动机的问题，但是怎么同时控制12个单缸发动机，问题一样不少。只不过，这个问题可以被推后，可以被掩盖，只是后人能不能接得住，成了问题。
3. 总体来讲，最初建立起这套业务架构的首任研发老大的水平就是能够理解甲方业务，然后开发出一个Demo级别的IT系统，就直接交付了，你说它有什么问题吧，该有的功能都有，你说它是个完整的产品吧，其实就是个Demo。Demo系统是不用考虑长期运行的稳定性、可靠性问题的，也不用考虑系统长期演化过程中的代码可读、可维护性。但是一个企业级系统，常常是要持续运行数年，乃至十年以上的周期，现在的中国，由于企业信息化时代不长，加之业务发展迅速，变化多，IT系统的寿命相对较短，大多短短几年就要考虑迭代更新，不过一样要考虑运维相关的问题。这里倒好，完全不会思考一个系统、一个项目下个月的运行是否还能正常。从上到下，对于长期运维的项目到底要处理什么问题毫无概念，对于运维要做的事情也是各种胡来，毫无章法，结果就是我接手的时候，这几十个项目，每天都不知道要爆出些什么接口对接、日常执行，或者是运维上的紧急故障需要处理，而且因为没有历史记录，没有规划，每次都得现研究到底是出了什么问题，往往是一个很简单的疏漏，短短几个月、一两年之后，就会酿成大问题。而小疏漏多了，时间一久，就变成每天都需要去救火的局面了。
按说公司人员规模最大的部门的一号位发生人员变动，老板应该是高度警觉，深度介入，全程紧盯，严防死守，结果这边这位老板好像完全化身空气，对公司最大成本部门内部的情况一无所知。首先，这个问题和局面的唯一责任人只有老板，因为他本身就是公司所有问题的最终责任人。至于为什么出现这个情况，我分析了几种可能的原因：
1. 老板认为业务简单。
  这位老板在这个行业里面干了二三十年了，业务上的各种事情了然于心，所以觉得什么事情都很简单。确实，这里面很多基础性工作没啥技术含量，全国各地跑现场干活的人大多就是些中专、职高生，没啥技术含量。不过开发一套用来把这些没啥技术含量的工作给自动化起来的IT系统，是不是也是那么简单呢？按照这个逻辑，小学生都会用的微信，是不是一群小学生就能开发出来了？
2. 老板无条件地信任这位研发老大。
  这位研发老大应该是老板通过业内的关系或者私人一些的关系找来的，跟老板也是同校的师弟校友，目测老板是很信任他的。记得中间事情少一些的时候，我曾经尝试把中间代管研发那位搞的项目代码研读讲解的工作重新启动起来，给研发团队讲讲前人的代码结构，尤其是他那套抓取体系。简单看过结构之后，我发现这个项目相当恶心，代码写得有一种刻意人为加密的感觉，后人很难看懂，最后实际是分析了他的配置文件和部署模式，根据输入输出，大体把代码结构分块弄明白了，就给大家讲讲。开场的时候，我diss了一下前人的代码写得乱，不好读，就被老板diss了，说我不应该这么评论前人。
  行吧，不评论就不评论呗，之前那个代管研发部的也曾经想带着大家读懂这坨代码，我不知道情况如何，不过就从我看这坨代码的情况来看，他肯定是没希望看懂了，更不可能带着这帮小兵看明白，如果是一行一行读，一准掉坑了爬不出来。
  不过要说老板完全信任手下这位，就不知道他们之前是怎么闹崩了的了。
3. 老板就是个销售。
  这事儿老板自己都说过，他觉得只要把项目拿回来，就算ok了，后面就是研发的事情了。这不就是典型的销售思维么，项目签了合同落地，自己就有项目提成，至于后面研发交付怎么样，就跟自己没关系了，公司在这个项目上挣不挣钱，就跟我没关系了。算总账是老板的事情，不是销售的事情。
  既然老板给自己的定位就是个销售，公司赔了赚了跟自己有啥关系？研发部门好了坏了，研发的人来了走了，和自己又有什么关系？
  老板的精力投在哪里，公司的业绩才会从哪里出来。用我现在这个行业看到的一些现象来说，只关注销售拿单的企业，销售就会为了拿单而拼尽一切，完全不考虑实际开发成本、交付难度之类的问题，反正销售自己拿到项目提成就完了，后面开发过程，工程师拿一份死工资，很可能最后一年下来，老板发现所有的利润都被销售拿走了，自己反而一分钱挣不到。
4. 听说这公司之前的业务是做硬件的，后来近几年才开始转型做IT软件，等于是有这样一个转型的过程。根据我这几年在目前这家公司看到的现在所属行业内的一些企业的情况和感受来说，无论是贸然进入一个之前并不了解的全新行业，还是在原有行业内进行不同模式的业务转换，难度都很大，尤其是在业务内容转换这种情况下，虽说还在同一个行业内，但是业务变了，企业的组织架构、人员能力构成、评价体系、很多成本估算方式，都要跟着做全面调整。而老板常常会把自己之前在这个行业和业务上的成功经验作为某种锚定依据，觉得这个转换又不是换了行业，不会有多大的难度，也不需要做出太多的改变，应该是很轻松就能完成的工作。结果就是踩雷一片。
等到研发老大走了，做售前的也因为家庭事务问题走了，老板开始发现问题了，技术这边没人能对接得住他了。以他的行业经验拿回来的需求，研发没人能搞懂了，只能是蒙着干，出来的东西越来越不像个东西了。按说这时候老板应该把大部分时间精力放在凑齐管理团队，解决核心部门负责人缺失的问题上，不过看起来老板还是一副得过且过，就这么对付着了，招核心团队的事情让HR去烦心就完了。不知道是老板觉得自己做好销售，其他事情自然有人能办好，还是觉得自己公司这摊事儿足够简单，马路上随便招个人就能干了。按说他是明白这里面事情很多，非本行业的人进来需要学很久的，因为我入职之后他也没少花力气向我传授行业经验，按说能理解到这一层面的啊。
然后好不容易抓到我入职了，拼命搞售前，想的全是怎么落项目合同，说明对他研发的混乱不在意，只能说老板真是无知又傲慢。
研发团队这边手头维护的项目整天冒火冒个不停，项目团队时常就要抱怨研发不给力，这也坏了那也没了，老板想的是让我这个研发的经理去干售前工程师的活，因为售前工程师彻底离职了，没人对接售前这块工作了，他就开始想着拉我去搞售前的活，不然他得自己扛售前的工作，估计是忙不过来了。问题是售前工程师离职了，应该是重新招一个售前，而不是让研发经理把研发的工作扔一扔，跑去兼职干售前。
估计老板之所以这么搞，一方面是想省点成本，另一方面是察觉到了之之前那个售前虽说能干那些套话的行活儿，但是理解业务是不太行的，我这边从技术角度去看业务，理解业务，比之前的售前更靠谱。有个懂技术的跟着他跑，他心里更有底气一些。
只是这么拉着研发去干售前的活，研发的事情谁管？之前很多成本都是被研发部门内耗出去的，老板非但不想着解决，还要继续加深这种内耗，真是不算ROI啊。这里其实已经非常明显地体现出来这个老板是不懂公司经营的。
因为老板不在研发部门投精力，这边实际就成了一个成本黑洞，吞噬了本来的利润空间。
想起一个说法，一家公司里面，总会有一些人的水平很高，其贡献价值是远超行业平均值的，等于是在给公司其他人发福利，当然，考虑到很多事情必须要体系化作战，这种福利是必须的，同时这种大佬往往也会收割到同事们的赞美与恭维，作为补偿。
这个老板等于是用自己的个人能力、个人行业资源，在给公司里面这些拖后腿的人发福利。
一开始，我还觉得这个老板怪可怜的，自己也苦哈哈的，还没啥利润。后来想明白，这都是他自己的选择，自己的决策，作为这么一个小公司的老板，成也好，败也罢，他也怨不到别人，都是自己担着的。
最初入职的时候，我心里有一个假设，就是这家公司成立近20年，现在这套业务模式运行了3年左右，那么无论是从老板的角度，还是从部门内部运行的角度看，都应该是一个比较成熟稳定的状态，大部分人对大部分事情都应该是一种能够熟练处理的状态，只是在少数难点工作上会有困难，需要有人补强。这样一个假设，也是源自于入职前对各方咨询后的结论。彼时我还没怎么做过小公司的部门管理岗，对于这种岗位可能要管的事情没有太多认知，虽说常规的管理能力储备还算有点，不过其实是不足以支撑这个岗位的任务的。
事后看来，这个研发团队的运行状态完全不符合最初的假设，也不是在难点上进行补强就能够解决问题的。因为对这个团队来说，任何工作都是难点，那么如果新来的老大想要去在难点上用个人能力进行补强，结果就是一个人把部门的所有工作都扛走，这样最简单，也最合理；上面这个论断看着很奇怪吧，但事实就是这样，在最终由于各种原因，原有团队所有人基本都离职之后，我发现世界清静了，整个部门的运行效率达到了最大化，换句话说，我一个人的产出，比我+之前整个团队的产出还要高，之前的团队其实是在做负产出。
只是一上来就搞大换血，把旧团队全干掉，这不可能啊，哪见过说部门空降一个领导，第一件事是把部门的人全换了的？即便新官上任三把火，也没有这么玩的；而且玩新官上任三把火的，基本也都是体制内这种本已经高度固化，成熟稳定的业务，哪有在风雨飘摇，四处漏风冒火的业务上这么搞的。
但是这个团队的状态，其实人员重构是最合理，甚至是唯一可行的发展方向，只是我当时所有的时间精力都要用来了解业务，熟悉存量项目，应对老板弄出来的新项目，管理经验上虽说能应对日常性质的运作，对于这种大重构的工作，无论经验还是精力，明显都是没有可能能够完成的。
对于不可能直接招到能力对口的，只能内部慢慢成长这一局面，前面已经说过了，这也是这种类型的企业必须要面临的情况，或者说必须要支付的成本。
关于旧团队的人员：之前的团队成员普遍是一些二本三本、大专、没考上大学coding培训学校出来的人，在我之前的职业生涯中还真的是没有怎么和这种层面的人打过太多交到，实际干下来，味道确实酸爽。记录几个印象深刻的例子。
1. 最资深，在公司工作年头最久的后端开发，无法理解二维数组这个概念。不是无法运用二维数组进行数据处理，或者是什么复杂的操作，而是完全没有办法掌握这个概念。
2. 工资最高，用来接收上一任开发老大开发的这些项目的后端Python开发，抄代码会少抄2行，因为看不懂是干啥用的，所以就觉得不用抄了。这货你给他什么活他都敢说能干，能懂，实际是什么都不懂，后来我发现是他真的是什么都不懂，不懂到没有什么是“懂”这个概念，因为什么都不懂，所以觉得自己什么都懂，什么都能搞，事实是什么都能搞，搞砸嘛，也叫搞。
3. 新入职的一个后端开发，数数会数错，不过我怀疑他是故意的，在给我挖坑。初中电学中的功率概念，不理解，还是一副“我为什么要知道这个”的表情。我们是在搞电池相关的业务欸，这些学过很多遍，做过很多题的基本概念，还要我再重新教一遍？
  后来让他做个性能benchmark的活，我估计我干大概3-4个小时，结果花1个多小时讲一遍，回去干3-4天，跟没干一样；再讲一遍，又好几天出去，还是什么结果都没有，如此3次，我放弃了，自己干吧。感觉这帮人的思路就是：我把所有的事情都搞砸，就没人想给我派活儿了。
4. 一个前端小菜鸟，代码能力确实不行，我让他去折腾微信公众号注册主体公司变更的事情，然后让他给我写一份操作文档留底，免得下次再变更还要再摸索一遍。结果我得到了一个txt文件，2行，里面一个标点符号都没有。如何使用逗号句号，这是小学教的东西，而且是之后无论学文科学理科，都会要一直使用的能力吧。
5. 测试对于没有bug的定义：某次运行，跑过了，就叫测试通过。
说实话，这帮人的工作方式真的是很震碎三观，我之前从没想象过有这样的一种思维方式。后来这些年刷了些知乎，好像我们西南方向某大国的人比较习惯于这么干活。
高手能够适应各种情况，兼容一些很菜的伙，相反的，菜瓜的兼容性是很差的，自己干出来的东西乱七八糟，还没法和别人说明白，也听不明白别人说的，所以一个团队里面如果全是高手，干什么都会很顺畅很方便，如果只有1-2个高手，至少他可以和所有菜瓜对接，如果只有菜瓜，那就是谁跟谁都对接不到一起去了。接不上，事情办砸了，谁的责任呢？那就是一场互相甩锅的战斗了，这就叫干啥啥不灵，甩锅第一名。
人员能力差，项目难度大，这是行业中常见的问题，但是局面搞到如此这般混乱糟糕，也全是独树一帜了，我尝试猜测一下这个情况的发展历程：
最早的研发老大搭建部门结构的时候，是以他个人的开发能力为核心的，他完成所有核心业务流程的开发，主要是数据获取与处理，其他人只需要完成数据展示的部分，并不需要理解业务，也不需要理解最困难的部分，只需要按照老大的要求把数据展现出来，就ok了。这样一个模式之下，对于普通小兵的要求并不高，所以招聘拉胯一些，各种能力拉胯一些，并不会影响业务核心能力。小兵们不知道核心的情况，整体项目进展看起来也是ok的，所以会有一种迷之自信，觉得自己可以的。
只是当这位老大离开的时候，带走了所有的核心能力，估计当时他给自己招接手人的时候也是比较心不在焉了，而且根本就是不可能招得到的人嘛，再怎么努力也不可能找得到，都要滚蛋了，还那么上心干什么？核心一走，剩下的人虽说做了工作交接，其实是不理解自己接手的东西到底是什么，业务逻辑、技术相关知识，都是欠缺的，又没有自学的动力和能力，只能是混着，对付一天是一天，虽说对付的过程中问题只会越来越多，但是对付一天就有一天的工资，反正老板看不出来问题就完了。
估计老板在部门核心走了之后，可能还给部门内重点人员加了点工资，以保护剩下的“核心”稳定性。其实已经根本没有核心的，没有人能支撑住，全都碎到地上了。但是因为没人懂技术，所以这个局面其实也是无人知晓的。部门外部，老大傲慢地觉得这些技术上的事情都很简单，谁都能干，而且都做过离职交接了，这么简单的活，怎么可能有问题；部门内部，接的人稀里糊涂的接了工作，根本搞不懂到底是些什么事情，甚至连自己哪里不懂都不知道，就只能硬着头皮开始对付事儿了。
我接手部门的时候，HR姐姐跟我说了这边的人比较low，能力不太行，同时又说希望我能把他们带出来，让这些小兵能够各自hold住自己的任务，让整个部门的运作变得“正常”起来。所以真正上手开始管理这个部门的时候，我也是按照这个思路来走的，一方面是花时间精力了解公司业务与存量项目的情况，另一方面是给部门日常运作中遇到的技术性问题做补丁式的支撑，毕竟这么多的项目，全都熟悉一遍也需要相当的时间精力。而这些事情就已经是让我被动性的把时间精力都用光了，没有空余的精力去主动分析当下的问题以及应该如何排列优先级，什么问题是最优先需要解决的；其实这里面暗含了一个假设，就是部门和公司的日常运行状态是正确合理的，是适合公司当前要求的。所以日常出的这些问题是合理的，解决掉就好了。老板对于公司日常运作与发展方向的认知肯定是行业领先的，所以相信老板，紧跟老板节奏就对了。
实际上呢，老板干活就是眉毛胡子一把抓，想起一出是一出，一会儿是他的远大理想，一会儿是眼下马上就有眉目的新项目，一会儿又是哪个老项目的验收和下一期的推进，根本看不到主攻方向、辅助方向。至于对内管理，只会提一个模糊的要求，至于这个目标如何细化，是否合理，是否有足够的资源，团队能力是否匹配，就不是老板的事情了，甚至最后是否完成了，其实也无所谓。更难听一点说，老板想要的，跟公司需要的，没啥关系。
至于这些小兵，真是朽木不可雕也，粪土之墙不可圬也。以他们的基础能力，是很难成长到能够达到满足业务所需的能力水平的，同时在这里混日子的过了好几年，主动性、学习能力、工作习惯，各方面都可以说已经废了，而且对自己已经废了这种局面毫无认知，还自我感觉良好，你要是指出他的问题，他就觉得你是刻意针对他在搞事情。
反正最后我快滚蛋的时候，就是一种非常强的无力感，感觉如果要把工作做好，就是和全公司上上下下为敌。
这里还有一个点，就是入职刚刚3个月，刚刚把行业情况摸入门，疫情就来了，疫情一来，新项目全停。其实这个团队拉出来打一个项目的仗，就都漏出来了，但是日常做些维护性质的工作，我又没有太深入具体工作细节，净忙着跟着老板的项目思路跑，这群货就比较容易把日常工作中的漏勺都藏起来。说白了，还是我没有深入去抓问题，以为大部分情况下大家都是能正常hold住工作的。
现在回顾一下是否有可能把这份工作做得更好一点呢？
1. 在最初发觉团队工作有问题的时候，就应该果断一些，做出人员调整的准备，团队里面一个支点都没有，全靠部门老大顶着，这是有问题的，当初的老大一个人把架子全搭建起来，他能玩这个one men show，接手的可是接不动啊，必须要有几个业务骨干，能够支起来，如果内部没法出来支点，就必须考虑从外面招人进来换血。
2. 行业经验丰富的老板也不一定什么都是对的，所以要对这一点有防备。
3. 想清楚工作的优先级是第一要务，剩下所有的救火问题都是次要的，如果不能理清楚部门运作本身的业务逻辑和目前的核心问题，再怎么努力恐怕都是徒劳。
4. 接手一个有着很多历史项目的团队，风险其实比从零组一个团队做新项目大得多，有经验的都知道，历史项目都是屎山，只是高度有差别。
5. 做管理，要点一定是搞定人，人不对，事情一定对不了，对的事情也会给你整成一坨屎。
旧屎山项目太多了，部署结构奇葩，手工启十几个分布式进程，代码基本不可读，运维就要吃掉相当的人力资源，更别说各种出问题临时顶缸填坑的事情。
老板还在那想着说要有个数据中台，把所有分散在不同项目中的数据集中管理起来，想法很美好，逻辑也正确，就是这么一个团队，你跟他说中台，恐怕给你做成个出台。
后来项目部的副总提出来要开始计算每个项目的成本投入与收益情况，等于是要做精细化运营，把可能造成亏损的漏点找出来，其实这是很好的运营管理手段，不过比较可惜的是那时候已经没啥新项目进来了，倒是眼睁睁看着老项目在一天天滑向亏损的深渊。
其实老板作为销售，拿项目的本事还是很大的，扣除商务成本，留给项目开发交付的利润空间应该是相当可观的，比起我最近看到的几个定制软开项目的报价空间，那可是十分之优厚了。这么厚的利润空间，最后公司还是亏损状态，也真是没法说了。
曾经刷到过一个视频，一个职场话题博主说老板最怕顾问型员工，什么事情都是一副顾问性质的态度，我提个意见，至于老板你听不听，那就是老板你的问题了。
这事儿我觉得要分情况，很多小公司老板都是一副霸道总裁风格，什么事情都是我的判断肯定是对的，要维护自己的权威形象，并依靠这种权威形象完成对公司内的治理。既然老板你不肯听不同意见，那公司里面自然也就不会有不同的意见。只有老板愿意表现出开放、虚心，员工才会有发言的欲望。
后记：
由于疫情影响，我在这家公司的这不到10个月的时间里面，公司拿到的新合同几乎可以说是没有，唯一一个新做的项目，还是从一个原有项目上发展出来的一个补充功能类的合同，不能算是新项目。项目少，打仗少，真是很难直接注意到团队的问题，也缺少锻炼提升团队的机会。后来听说一个重要合同还飞了，伤害很大，开发工作都干了一多半了，听说这种没合同就开工，后面SB掉的事情，这也不是第一回了。

收获得失总结

前面吐槽部分已经有不少总结，这篇写得比较乱，毕竟是断断续续写了很久。凑合继续梳理一下。

第一次和一群很low的货打交道，尤其还是这种让他们承担远超自身能力范围的工作内容的情况，不过也是锻炼了自己的承受能力，在后来的工作中，对于各种奇葩烂事儿的预防与承受能力都得到了提前锻炼。
对于企业级IT开发这个行业有了比较深入的认识，虽说没有经历前期招投标这一流程，不过对于其中的商务、售前、开发、交付等各个环节都还是有了一定认知，了解了这种业务模式与之前十几年间经历的互联网行业的不同之处。
对于大公司、小公司的区别，以及企业运营中的成本、利润核算，都算有了一些认识。
1. 之前大部分时候都是在大企业，或者大企业的高管出来搞的创业公司，对于大企业中的螺丝钉来说，企业运营情况好坏基本上是被隔离在你的世界之外的，基本只会在每年年会公司老大介绍公司业绩的时候才会关注此事，日常情况下，干活拿钱，完事。
  而在小企业中，由于整个业务链条更短，不同部门之间的距离更近，公司运营情况是更容易被了解和关注到的。
2. **大公司之所以是大公司，就是它占住了一块规模很大的利基市场，这种市场占领是有一定护城河的，所以足以维持一个很大的企业营收体量，同时也就需要由一个规模足够大的团队完成其业务。规模大了，工作内容自然可以划分得更加细致，每个人的工作都会更加专业。**
  **小公司要么就是只有一个小市场，一个大企业看不上的小市场；或者是一个由于业务特性使得其受地理距离分隔特性明显，难以做大的小市场；要么就是还在起步阶段，正在尝试创造一个大规模利基市场，或者准备用一些新的手段打入一块已有的市场。**
文档的重要性再次得到了体现，互联网行业由于业务迭代速度快，文档工作通常是非常薄弱的，而企业级IT开发是需要考虑交付后的长期运行，二次开发，后期项目迭代等一堆问题的。按说对文档的要求是要更高的，要求高的甲方可能还要审核文档质量。
如果是像这家公司这样，属于窄赛道小众行业的，更应该积累一套行业知识培训文档，包含一批基础知识信息，无论是技术研发，还是销售、运营，来了先看一遍，能对行业所需基础知识与公司业务、产品有个基本了解，让公司各部门的人至少有一个公共知识的底线。
有一次管项目部的副总说了一句：我们应该干一些干过的，熟悉的活。当时我挺震惊的。工作这些年，初期的时候，每个任务，我们都会想方设法用一些新技术、新组件、新思路、新方法。如果每个项目都在重复之前做过的东西，我们肯定是不会一直这么干下去的。后来即便技术已经很成熟了，也会在业务上尝试各种不同的业务类型，绝不会简单地重复自己。
但是这么一个小公司，这么一个不给力的团队，还想着每次玩点新东西，那就是找死了，最合理的方案就是固化一套产品，尽量别变，每次都尽量用同一个模子扣出来，风险最低，效率最高，明知没有那金刚钻，就千万别去揽那瓷器活。
对于大厂管理层，如果要转去小公司，就要做好靠一己之力完成全部门所有工作的能力储备，小公司，尤其是创业期或者转型期，业务远没有持续稳定长期运转的部门，人员能力、基础管理，各方面都是跟不上的，而且肯定是内部无法解决的那种跟不上，才会从外面高价找人来做管理层，那么新来的管理层就要有能力补所有人的缺漏，在任何人搞不定自己该做的工作的时候顶上去，保证阵地不失手，还要在这种情况下再提升团队水平，达到业务所需的水平要求。
如果只是指望把开会、沟通、协调、部门间撕逼的本事拿来在小公司用，一定做不下去的。
老板永远是公司的一号位，所有问题的最终责任人，这种责任是没法推脱的，所以如果老板作为最大的受益者，如果不能做好这个位置，自然也理应成为最大的受害者。权利越大，责任越大。

离职

这份工作截止于2020年9月，不到1年。

补充后记

2024年10月31日跑去和我在这家公司的继任人吃了顿饭，聊了聊，可惜时间比较紧，能聊的时间有限，不过也是更新了一些认知。

之前的代码完全没有可读性的问题，说是老板要求的，要给代码做加密，防止甲方把核心技术撸走。
问题你想对代码加密不是这么个搞法啊，混淆器是有各种成品方案的，先老老实实把项目写完，扔混淆器里面混淆一把再发布就完了，别tmd人肉混淆啊，开发阶段直接人肉混淆，后面就别想着什么维护、改bug，功能扩展的事情了，只能是每次来个需求就从0开始再把所有功能写一遍了。
Python这种鸭子模型的破玩意，混淆器是不是像想象中那么好用，没试过，不知道大项目上会不会有坑。
项目Demo化，也是老板拍脑袋就让先做个Demo出来，然后就想着赶紧开卖，根本不考虑持续运行的问题，最要命的是，老板不靠谱也就算了，之前的研发老大您也真敢想都不想就跟着往坑里跳，完全不考虑后面怎么填的问题啊，老板叫胡来，你就老老实实跟着胡来玩，那肯定要不了几年就要天怒人怨，把自己坑死，什么都推进不下去，还要天天被老板骂。
运维，居然有在甲方内网环境，号称甲方全监控运维的情况下盘满爆库的破事儿，哈哈。
中间接任研发负责人的人好歹是把原来Python那坨全扔了，全面切换到 Java 体系了，那坨Python的东西真是没人看得懂，当初我也只能是先凑合封装起来。听说后来没人维护了，连启动都起不来了。
听说这几年拿合同的情况不错，团队还扩张了一些，不过今年就很惨，只拿到一个合同。按说老板的商务能力不至于啊，不过又说今年招了一个销售，然后老板跑来搞内部管理，折腾得鸡飞狗跳，项目也都没做过成本预算和事后核算，这可是4年前我走之前就在搞的事情啊，不做起来，怎么知道亏了赚了。
至于交付层面，这么多年了都是一坨屎，因为前期就不对，地基是流沙，想交付个高楼，只有塌房一个下场。
其实所有的问题，归根结底还是人的问题，按老板这个玩法，需要一个向下能镇得住场子，向上能接得住老板的思路，挡住老板不靠谱奇思妙想的CTO，问题是这样的人是否存在？即便存在，是否能愿意来这种公司？即便愿意来，公司的利润空间是否养得起？即便养得起，是否能长期和老板和平共存？

[回目录](328470102.md)

16324 字

20年职业生涯回顾——企业IT开发 下

企业IT开发 下篇