“Yeah It’s on. ”
正文
抛开薪资待遇的部分，作为一个团队的管理者，天然都对员工的成长负责
自由度高的技术选型容易让屎山选手写的屎更难维护
在你的团队里，不论男女、不论层级、不论能力，只要在你的麾下，你就要对他的成长天然负责，妄图逃避规避找理由，都是不敢正视自己管理职责的闪烁其词，没有这样成就他人的心态，你可能仅仅做到了管理及格。
用人单位不是冰冷的一个组织，而是围在一起做事的一群人，既然是一群人，就自然有这群人凝聚出来的性格，这个性格决定了他们喜欢什么样的人，愿意接纳什么样的人，愿意培养什么样的人以及会淘汰什么样的人，比如不合群的人容易被淘汰，因为他容易与团队之间产生对立甚至内耗，降低团队的战斗力，这是站在用人单位的视角评估潜在的合作成本和磨合成本，以及可能的破坏力。
软件分层
一套软件通常包含以下九个层次：
- 应用（application）
- 数据（data）
- 运行库（runtime）
- 中间件（middleware）
- 操作系统（OS）
- 虚拟化技术（virtualization）
- 服务器（servers）
- 存储（storage）
- 网络（networking）
Pass 和 Sass
PaaS：Platform-as-a-Service(平台即服务)
PaaS公司在网上提供各种开发和分发应用的解决方案，比如虚拟服务器和操作系统。这节省了你在硬件上的费用，也让分散的工作室之间的合作变得更加容易。网页应用管理，应用设计，应用虚拟主机，存储，安全以及应用开发协作工具等。
包括了中间件服务，信息服务，连通性服务，整合服务和消息服务等多种服务形式
减少了用户在购置和管理应用生命周期内所必须的软硬件以及部署应用 和 IT 基础设施的成本
PaaS除了提供运行时外，也会提供软件的基础功能的服务，如通信，存储，推送等。
PaaS公司在网上提供各种开发和分发应用的解决方案
SaaS：Software-as-a-Service(软件即服务)
几乎我们每一天都在接触SaaS云服务，比如：我们平时使用的苹果手机云服务，网页中的一些云服务等。
ipaas和apaas
https://www.zhihu.com/question/58264113
一下就能看出，它们都是从Paas衍生而来。
Paas——云服务提供一个平台，企业自己设计软件应用，数据也由自己保管。这就是Paas。
aPaaS的全称是application Platform as a Service，即应用程序平台即服务。Gartner对其所下的定义是：“这是基于PaaS（平台即服务）的一种解决方案，支持应用程序在云端的开发、部署和运行，提供软件开发中的基础工具给用户，包括数据对象、权限管理、用户界面等。”
提供快速开发的环境，用户在几个小时内就能完成应用的开发、测试、部署，并能够随时调整或更新。 低代码或零代码，非技术人员就能完成应用开发
apaas从应用和数据层面入手，就足以看出，它趋向于PaaS和SaaS之间。
其次，就是打通企业内部的各个软件问题。
由于企业堆叠的各种SaaS软件，用着不同的主机和数据库，怎么将这些软件集成起来？这就需要一种技术，也就是iPaaS。
它从虚拟主机和数据库层面入手，创建一个中心生态系统来查看、管理和修改所有数据、基础设施和操作。从而轻松打通各个系统的数据与功能。
- 解决企业里各个软件造成的壁垒问题，减轻IT任务量——ipaas
- 满足企业追求的灵活但要性价比高的软件开发，降低开发门槛——apaas
技术偏重点：
- ipaas偏向IaaS
- apaas偏向SaaS
使用对象：
- ipaas：IT人员
- apaas：所有人
代表性产品：
- ipaas：阿里云ipaas、Dell Boomi、Informatica、Jitterbit……
- apaas：简道云、明道云、道一云、smartsheet、airtable……
小微/外包企业的前端
大厂谈高大上技术、谈架构，谈场景。小微企业前端谈温饱
困境
大厂谈高大上技术、谈架构，谈场景。小微企业前端谈温饱，我们或多或少面临这些困境:
边缘化
在这类公司，前端没什么话语权，他们只是一个简单页面实现，简称切图仔。
本质上是业务决定了前端的工作不会占用太大比重，自然也不会受到太多重视, 可取代性也很高。这类公司往往是传统行业，例如硬件、电力。相反依赖于端行业，如电商、社交，前端的地位会高很多。
这种环境下，前端不会关心太多业务，当然容易被边缘化，扮演相声里面的捧哏角色。
协助混乱/基础设施薄弱
小微企业，因为人员整体水平不高，协作通常也比较混乱、不规范。这里指的是一个项目的整体研发协作。
对于前端来说，我们的上游可能是后端，后端的代码质量和规范性对前端影响也会特别大。 例如接口混乱、文档不规范、未考虑应用场景、接口不测试等等… 这种工作环境下，效率会非常低，前端开发会非常痛苦。
基础设施弱，前端工程化总感觉束手束脚。
忙碌
感觉每天都很忙碌，却像什么事情都没有做。每天的工作重复一次又一次，原地踏步。
孤岛
像置身孤岛，知识和消息是封闭的，个人能力和技术很难有大的突破。公司的格局决定个人的格局。
人员变动
吸引不了优秀的人才，而且优秀人才也留不住，整体水平较低，很难有技术沉淀和开拓。
理想/企业文化的认同感
我们只是为了赚钱，别跟我谈什么理想。我们感觉自己在被压榨，是机器，这样的工作自然不会有什么幸福感。
极简的技术栈
Keep it Simple, Keep it Stupid。
最近对这个原则体会颇深。小微团队技术选型不应该随大流、追随最新最热的技术，而是应该选择符合自己的团队水平和业务情况的极简技术栈。
这四个原则非常重要：
- 简单
- 自动化
- 清晰健全的文档
- 约束
‘简单’主要是为了减低学习的门槛、降低心智的负担, 接口越简洁越好：
- 约定 > 配置
- 显式 > 隐式
- 声明式 > 命令式
- 接口协议: JSONRPC > Restful
- 构建工具: Parcel > Webpack, 除此之外还有Vue-cli, create-react-app
- 框架：随便举个例子 Vue > React。Vue 入门会‘相对’简单，React 太灵活、社区百花齐放、尽管我很爱它，但是它没办法阻止别人干蠢事。
- 状态管理: Mobx > Redux > Rxjs。
当然, 具体场景具体分析
‘自动化’，能够自动化解决的事情，就不要靠文档规范、靠口头沟通:
ESlint、Styleint、HTMLlint、Markdownlint… *Lint。有各种各样的 lint 工具和社区推荐规范，自动检测各个环节是否符合规范。 Prettier 代码格式化。只有一种代码样式，别BB
‘文档’，重要性不言而喻。有事先看文档，再问别人
‘约束’，在事情失去控制时，我能体会到那种绝望。这时候你会希望当初有更多的约束，尽量让代码保持在可控范围之内。例如 Typescript，各种 *Lint。如果没有约束机制，规范永远只是规范。
业界谈的非常多的就是中台能力，什么“小前端，大中台”，这些东西对于大厂非常重要，可以有效减少不必要的内耗，提高管理效率和资源整合能力，可以为集团的技术生产提高更高的赋能。 但是这玩意对于小厂，或者这么说吧，整个公司前端不超过10人的公司，投资与收益比是小于1的，是不划算的，因为不适合。
作为一个职业的前端开发，评估在公司这样一个商业机构里是否应用某一个技术，不应该是这个技术是否流行，不应该是这个技术能否让我开发爽，也不是是否可以炫耀自己独家掌握的技术，而应该是这个技术是不是适合我们产品，对用户和公司带来的价值有多大，对于同事间协作新人加入后的维护是否方便等。
避免单点故障
小微前端团队，人员资源非常有限，往往每个人负责不同的项目，这就可能出现‘单点故障’。假如这时候项目的负责人请假或者离职，就会让人措手不及。一方面项目交接过程会拉长，另一方面其他成员上下文切换的成本也很高。我们尤其害怕接手的项目是一个烂摊子。
解决单点故障的唯一办法是让更多的成员交叉参与不同的项目，项目的责任在于团队而不在于个人。另外可以配合例如代码 Review 这些手段，多种途径让团队成员可以熟悉项目的代码。
代码规范和共享代码在这里也可以起到很大的作用。如果’知识’可以在多个项目中复用和共享，那么项目上下文切换的成本就相对比较低。
集体利益大于个人利益
不管是大公司还是小公司，集体的利益永远是大于个人利益的。
- 集体利益大于个人利益。这是我们从小被灌输的思想，在一个集体中，你的行为和决策是需要对集体负责的。
- 对项目缺乏整体的把控，没有充分的风险评估。尽管前端只是一个完整项目的一环，作为前端团队Leader, 还是需要从整体上了解项目的进度。你要知道项目的开始时间、截止时间、提测时间、开发/测试进度、当前资源情况等。通过这些信息来进行制定资源的分配计划和风险预估。
- 推动协作效率的改进。作为团队 Leader，就不能只单纯关注技术和代码。我们需要去关注团队之间的协作通道，提高团队层面的协作效率，为团队成员扫除沟通方面的障碍。
问题不可怕，可怕的是不知道问题在哪里，你要想进步、就要多反思、多问为什么…
总结
小微企业的围墙不能靠一个人就能推倒，业务的扩张和升级才是真正的动力。
如果你觉得你公司有上升的动力和势态，而且你认同公司的价值观，不妨一起努力推动公司的进步。反之，要认真考虑自身的发展。
补充
升级的过程就是在不断解决问题，解决问题的同时我会发现有很多问题是过去管理上没有覆盖导致出现的问题，就是在过去管理过程中没有面向未来去搭建团队。我的视野需要往更前去看，把目前团队的「点状问题」变成「层面问题」。
所谓识人即要看清楚一个人的当下与未来的可能性, 就是通常说的能力与潜力.
程序员的三大美德：懒惰、急躁、傲慢。
- 懒惰，是一种品质，它会使你花很大力气去规避过度的精力消耗，敦促你写出节省体力的程序，别人也能很好地利用，你还会为此写出完善的文档，以免别人来问问题。
- 急躁，是计算机偷懒时，你会感到的一种愤怒。它会促使你写出超越预期的程序，而不只是响应需求。
- 傲慢，极度自信，写出（或维护）别人挑不出毛病的程序。
关于沟通
绝对坦诚。其实沟通没有什么套路，绝对坦诚、剖析事实就好。
调薪沟通
相信每一位小伙伴都会对调多少有个自己的期待，所以我一般开头都是问他们的预期是多少，然后直接坦诚告诉他最终调薪结果，坦诚地告诉他，调薪的原则是什么。再站在他的角度，引导他们思考一下这一年或半年来做了哪些项目，项目情况怎么样，must to do是什么、nice to do是什么。
这样聊下来就很清晰了，最终大家都比较能理解和接受，也让小伙伴更清晰接下来的加薪点。
离职沟通
团队要有流动性，就不得不做出取舍了，和leader对比分析后，做出了选择。接下来就是约小伙伴聊离职了。leader再一次让我去和小伙伴聊。这个挑战就更大了。所以怎么聊呢？
leader给了我思路，站在他的角度看待。剖析他目前情况、团队目前情况、团队的取舍、继续留的发展情况、未来规划。
对 “管理” 的理解
对于如何理解 “管理”，不同的管理者可能会有 N 种不同的回答。我对这个问题的理解是：管理，就是靠别人拿结果。
在不确定性中寻找确定性，通过成就他人成就自己，基于数据阐明一切改变。管理者是带来改变的人，管理者就是要靠影响他人，带来正向的改变。
那一些同学可能会问：我应该转管理吗？什么时候应该考虑这件事呢？对这个问题，我的理解是：当你要推动改变的事，你一个人搞不定时，就要去追求团队的力量了（管理）。
关于治理结构，我的建议是，团队成员平均意识和能力越是偏向于一般般和强执行的，越需要强化 —— 即越需要明确清晰的制度和流程。反之团队成员越是偏向于自驱和专家的，则越需要强化价值观，文化驱动，尽量降低强硬的流程制度对人的直观约束感。
所谓的项目管理或者软件开发模式，我认为最大的目的不在于将软件开发完成，而是如何让团队以一种更健康和轻松的方式达成目标。而评价什么方式是健康而轻松的唯一标准，就是加班的次数。
沟通，是第一要务，在遇到可能力所不能及时不要太过逞强，说出来，承认自己的能力尚有不足，让团队去分摊，毕竟模块的上级是整个部门，要往结果去走，在自己不能给出很好的决策的时候，多去交流，而不是认为自己可以，然后就可以。交流能学到的更多，比自己无脑接着来的更有益处。
人事管理
人事管理是重要的管理技能之一。许多人只会管理不如自己聪明的人或是能力不如自己的人，比如下属。许多中层管理人员一直停留在中层，就是因为他们只知道如何与职位低于自己的人一起工作，却不善于和比自己职位高的人一起工作。真正的技能是在某些技术领域能够管理比你更聪明的人并给他们提供优厚的报酬。
人才离开
这个地方的建议是面对人才离开要果断。我现在会这样跟自己说，大家分开是因为彼此的不合适，分开之后实际上是为了彼此更好。
情绪的管理
https://juejin.im/post/5e20130d5188254e1c43a3fe
丁香医生的在线问诊是一个探索型的业务，探索意味着什么？意味着会出现方向迷茫。业务方向不清楚，体现在产品需求层面就是产品的需求，这个月是一个方向，下个月又是一个方向。这样的情况就让我产生了一些急躁、焦虑的情绪。
产生负面情绪的例子还有：觉得团队成员成长速度慢、身边合作的人不专业、团队骨干成员流失等，实际上这些我们工作当中可能会出现各种各样的负面情绪。
把各种原因导致的负面情绪在工作中表现出来了。这不仅会影响到个人的工作状态和工作协作，负面情绪还会传递给团队。
所以说，当我们去开始带领一个团队的时候，一定要把自己的情绪管理好。或急躁，或焦虑，或担心，这些事情我们要尽可能去收敛，不要去把这样的问题轻易地表现给团队的成员。因为这些都会给他们带来一些负面的影响。
遇事的时候要保持良好的心态，对心如止水。
健康管理
生活工作中我们可以见到的健康问题还是很多的，无论如何我们都需要重视个人的健康。身体不健康、生命不存在了，谈其他的事情就没有什么意义了。
澈发员工的善意
管理的本质，其实就是激发和释放每一个人的善意。对他人的同情，愿意为别人服务，这是一种善意。愿意帮他人改善生存环境、工作环境，也是一种善意。管理者要做的是激发和释放人本身固有的潜能，创造价值，为他人谋福祉。
重视信息的价值
首先，我们要能从观念上要重视这件事情，然后我们要想尽办法尽可能的多去获取信息，因为有的时候信息不会主动找上门来。然后，我们要起到连接和过滤的作用。不是说我们收到了什么信息，转身就毫无保留的告诉给团队，有时候这样是不合适的，我们只需要把其中一部分，对团队成员更有帮助的信息告诉他们即可。
技术的价值
所有的技术都是服务于业务的，技术本身是不会直接产生“价值”，无论是技术驱动还是业务驱动的公司，最终使得公司活下来的是技术创造的产品而非技术本身。
技术的价值 = 产品的价值 - 技术的成本
技术的价值在于「持续交付」
-
公司/集团为「用户价值」负责：我们公司或者任何一家公司，最关注的是用户价值。我们做各种各样的服务、各种各样的产品，最终都是去为用户价值服务，从用户那里产生价值。
-
事业部/事业群为「业务价值」负责：我们需要用实际的业务去承载用户价值业务价值通常怎样是由公司的各个事业部、各个级各个业务部门去承担的。
-
市场/运营/产品等为「业务创新」负责：对于我们技术来讲，我们要为全部的业务价值负责吗？不是的。在业务价值之下，距离最近的有一个业务创新层。业务创新主要是由市场团队、运营团队、产品团队等来负责的。业务创新是指我们为什么要去做这样的需求、这样的需求解决用户怎样的问题、可以通过哪些方式更好的创造业务价值。
-
技术/产品为「持续交付」负责：在业务创新价值层之下，才是技术团队、技术人需要去重点关注的价值，叫做持续交付层。这是我们技术人要去负责买单的事情。
前端的价值
前端来说重中之重的价值就是用户体验，而用户体验的第一要求就是冷启动时间
前端能做的不仅是内部提效和外部体验，因为前端是人机交互的入口，才有机会将业务思考打包到代码中，直接透出给客户。
抛开复杂的底层数据逻辑，前端即是用户，同时也是创造者，理论上前端是应该对产品交互体验的痛点、业务的短板有着非常深入的了解，并且不断地打破这种局面。
作为前端，我们可以拿到第一手的用户体验反馈数据，包括任何的交互变动都可以拿到必要的数据支撑，继而可以在交互体验上有着更深入的研究，在此基础上，可以协助业务做一些更多的创新体验，甚至打造一个全新的产品。
底层数据的逻辑可以是通用型的但是表现出来的产品则可以是多样性的。
引导新人
引导新人的时候，要具备一秒变小白的素质。很多问题，作为老鸟，一眼就知道大体思路了。但是，新人缺乏长期历练形成的隐形技能。往往不得要领。这个时候，就得耐着性子，暂时忘掉自己的方案，沿着新人的思路，用自己的经验去判断，指出那些他们没想到的陷阱或泥潭。他们自己会更主动打磨自己的观点想法。所谓教学相长，其实经过这样一番探讨，自己也能更深入理解习以为常的概念。
我们一直习惯于去扮演业务高手。出现了各种各样的问题，首先告诉团队的人你们不要动、让我来。这对于管理来说，不是一个很好的事情，需要去规避。
总结一句话：要成就他人，就要发挥团队力量。
我们要对团队的成员发展去负责。
Bug引发事故，该不该追究责任
第一，追究责任，但不是惩罚。“知其然，并知其所以然”，搞清楚在什么场景下，什么样的 Bug引发了什么样的错误。相关人员应该尽最大的可能去做好善后工作，并思考如何避免下次犯同样的错误。
第二，对事儿不对人。在这个追究的过程中，重点在于怎么改善流程、改进制度，来避免同样的错误，而不是指责员工不应该怎么样。如果相关人员已经那么做了，为什么这个错误仍然没有及时被发现和制止？
第三，反复问“为什么”，从根本上发现问题。错误为什么会发生？有些 Bug 可能只是显露出来的冰山一角。
第四，员工关系的建立也很关键。我们需要培养的是大家相互信任、互帮互助，为了共同的目标努力的氛围，而不是一种不安全感。这种不安全感可能是自己不够自信，害怕犯错；也可能是对他人漫不关心，或是对其代码质量有怀疑。只有大家都相信，找出问题的根本目的是解决问题，避免问题再发生，才能建立一个不断反思、不断学习、不断进步的良性循 环。
A/B 测试
第一点：永远不要过分相信你的直觉。 有时候，我们会觉得一个功能特征的改动是理所当然的，更新后效果肯定更好，做什么 A/B 测试，这显然是画蛇添足。
第二点：实验样本的数量和分配很重要。 如果你的实验注定没有太多数据，也许就不要去做 A/B 测试了，小样本偏差会很大，帮不了太多的忙，除非你的测试结果出现“一边倒”的情 况。
第三点：分析的维度尽可能全面。 文章开头举的例子是说，虽然你最在乎的是用户转化率，但是功能改动可能会影响很多指标，这些指标都要尽可能地测量和分析。
第四点：其它组的改动对 A/B 测试产生的影响。 当 A/B 测试成为一个广泛使用的工具后，产品很多特性的改动都会用到这个工具。这也就意味着，当你在采集数据做分析的时候，别人也在做同样的事，只不过策略和数据样本不同。
第五点：比较值的趋势必须是收敛的，而不是发散的。 要想比较结果有实际的统计意义，一定是每天采集数据的比较结果逐步收敛，最终趋于稳定。如果一周内 A 比较好，后面又开始波动，B 变得更好，这样来回波动的结果是没有太大参考价值的。
第六点：数据埋点。 数据的埋点和采集是 A/B 测试成功的关键。
第七点：形成一个流程，或者设计一个工具。 这一点很重要。A/B 测试作为一个工具，只有在它足够灵活、好用的情况下，才能更广泛地应用到日常的产品迭代和开发中。虽然说这个方法很简单，但是做好一套包括埋点、采集、处理和具备 UI 的工具，会让工程师事半功倍
第八点：试图给每个结果一个合理的解释。 不用过分相信数据，也不要拿到什么分析结果都照单全收。试着去给每个结果一个合理的解释，不要觉得结果比期望值还好，就不用思考为什么结果如此完美。这可能并不是一件好事情，实际情况是：如果解释不了，可能它就是个 Bug。
竞争力
我和初出茅庐的应届生之间存在的竞争力是什么？
事实上程序员是工科而非理科。
工科类的职业生涯并非所见即所得，看懂了不代表就能“手起刀落”，我们时常看的“大佬们”文字凝结出来的果，其实背后耦合着无数的因。
工科类需要学习，更需要亲手记忆和“修路造桥”，所以我想时间给我带来的竞争力，大概就是：动手能力、面对问题的处理方法和对业务实现的拿捏程度，这是老师傅“吃过的盐”，其中滋味是无法用几句话一蹴而就的。
选用育留
- 第 1 件事：员工他有没有能力去做这件事情？
- 第 2 件事：员工他有没有意愿把这个事情做下去？
- 第 3 件事：在过程当中，整个组织环境是不是允许他去做这件事情？
技术沉淀
如果我们踏踏实实认认真真的去做了技术沉淀，它真的会去反哺到业务的优质高效交付上，同时团队伙伴也获得了技术的成长。
基建该搞什么
首先我们要说，基建的内容和业务阶段、团队既有建设沉淀是分不开的。越是偏初创期的团队，其建设，往往越偏向于基础的技术收益，如脚手架、组件库、打包部署工具等；越是成熟的业务和成熟沉淀的团队，其建设会越偏向于获取更多的业务收益，如直接服务于业务的系统，技术提效的同时更能直接带来业务收益。
企业文化
真正理解企业文化践行企业文化的人，格局一般不至于此，有些东西装是装不出来的，如果你真的想在一家公司长期干下去，你必须从内心去接受他的价值观和企业文化，并且正向的去思考去做事，而不是学一些形式主义和极端主义，放在嘴边当玩笑开。
敏捷开发
https://teobler.com/posts/20210314-software-craftsmanship
敏捷对一个团队的整体素质要求很高，需要团队的每个人觉悟和业务水平，技术能力都有相当高的水平
敏捷的本质是人，如何激发个体才是核心
”快而脏“是不存在的，垃圾代码只会让你把你所有时间用在debug里，垃圾代码只会拖累你。请记住，加快速度的唯一办法就是保证质量。
只关注流程不关注工程技术的敏捷不可能成功，也不能称之为敏捷，大多数公司陷入了“伪敏捷”的陷阱。
技术债务
对于技术债务，它的利息表现为系统的不稳定性，以及由于临时性手段和缺乏合适的设计、文档工作和测试带来的不断攀升的维护成本。 —— 《软件架构师应该知道的 97 件事》
技术债对于软件的影响：可维护性（Maintainability）、可演进性（Evolvability），而这些技术债对于非技术人员来说都是不可见的。它们源于生活，藏于黑暗中。
重构
https://github.com/phodal/migration
重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。 重构（动词）：使用一系列重构手法，在不改变软件可观察行为的前提下，调整其结构。
重构的唯一目的就是让我们开发更快，用更少的工作量创造更大的价值。—— 《重构：改善既有代码的设计》
好的代码不是一把写出来的，而是持续的演进和重构出来的
系统的核心就是系统的 core domain（核心域），一个有能力的管理者，能识别到哪一部分是系统的核心组成，并为它分配最好的开发人员
集权化
这已经不是老生常谈的问题。拥有流量优势、技术优势、运营优势的大厂，更容易占取利润更大的业务。剩下的又脏又臭的业务，被创业者和外包分而食之。
更可憎的是资金优势。通过巨大的资金池，在过去风口受益的，拥有巨大现金流的公司，会通过收购和投资的模式，强行切入到某个行业。
比如阿里，它的触角已经深到了以前互联网不屑入围的政企项目。通过资源拿到项目，然后通过外包完成项目，赚取差价。
今天广大的创业者，如果再盲目的追随大厂的脚步，就只能拿一点残羹冷炙，无异于自掘坟墓。
成本挑战
2B的服务、项目、外包，很多利润都是透明的，想象空间极为有限。由于竞争的因素，设施建设齐全的公司，会采用薄利多销的方式，售卖出去，造成了利润的进一步降低。
有两种形式可以突围，以使利润逐步增大。
第一，是极度压缩投入成本，包括人工成本、研发成本。这通常是和管理相悖的，充满了更大的挑战。如何在一个没有饼的空间中强行画饼，并画的有模有样，是值得深入思考的。
第二，是从外包、项目模式，逐渐进化为产品、服务模式。当在行业中树立了影响力，并有着竞争力强的产品体系，会让客户严重依赖。以通吃的模式，扩大服务半径，挤占其他竞争公司的空间。当达到这一程度，谓之为独角兽。
业务前端是“资源”?
前端岗位的特点就是有视觉稿就可以完成工作，不需要理解业务全貌，所以在繁忙期很容易让前端忽视了业务思考，加上之前描述的各种原因，业务前端经常沦落为“资源”，当你沦落为“资源”的时候，其实就已经失去了和业务平等对话的资格，他们只会把你当成莫得感情的开发机器，跟你输入需求，让你吐出页面，而你在这样的关系中，本来写着还算工整的代码，为了快速实现业务需求，也开始写起乱糟糟的代码，对于你所创造的产品也没有话语权，久而久之也失去了激情和耐心。
失去激情，写的不开心也就算了，因为你没有做出什么特别的东西，老板也不会特别认可你的辛苦，还会觉得你思考不够、没有业务 sence，对业务没有助力，没有让业务因为你的存在而有所不同……
业务前端的突破
好吧，那我决定做点什么改变一下，于是跟老板提出了一系列想法：
- 这里技术体系太老了，为了进一步提升开发效率，我们想要搞技术重构
- 前后端联调有点费劲，我们想搞个联调数据中台，提升联调效率
- 那里展现速度太慢了，我们要搞性能优化
- ……
老板往往会来一系列灵魂提问：
- 为什么要做？（有什么业务价值？有什么技术价值？）
- 为什么是现在做？
- 为什么是你做？
- ROI（投入产出比）怎么样？
还没有开始，躁动的心就被老板的一系列“质疑”浇了一盆冷水。
如果没有回答好这些问题、说服老板，自然也争取不到什么资源，只能一个人搞搞，一个人搞的往往质量不行、也没有人用，久而久之自己也不维护了，只能又开始埋头在需求中。
干的不开心，也没有成长，最后只能暗淡离职，但换了一个公司就会好吗，很可能又是类似的过程……
这真的堪称是业务前端的“困境”，那么如何突破这种困境呢？首先我们就要摆正心态，从了解业务开始。
程序员的宿命
程序员的职业生涯中难免遇到烂项目，有些项目是你加入时已经烂了，有些是自己从头开始亲手做成了烂项目，有些是从里到外的烂，有些是表面光鲜等你深入进去发现是个“焦油坑”，有些是此时还没烂但是已经出现问题征兆走在了腐烂的路上。
Any way，这大概就是我们这个行业的宿命——要么改行，要么就是与烂项目烂代码长相伴。
软件开发作为一种商业活动，判断其成败的依据应该是：能否以可接受的成本、可预期的时间节奏、稳定的质量水平、持续交付满足业务需要的功能市场需要的产品。
其实就是项目管理四要素——成本、进度、范围、质量
判断一个主管是否靠谱
有人问我怎么判断一个主管是否靠谱？我觉得一个好的主管，对组员的帮助是巨大的。他乐于和组员沟通，并且和组员的交流应该是激进坦诚（radical candor）的，真心希望自己的组员进步，坦诚地指出对方的缺点。他自己也一定是一个积极向上的人，对自己有自信，对组员没有保留，愿意把自己掌握的东西分享给组员，帮助组员以及团队一起进步。
相信的力量
意义感。我们这一代人，有一个很普遍的症状——害怕意义，从心底里排斥意义。我们从小被笼罩在宏大的叙事中，比如什么为了中华之崛起而读书，所以后面反而会产生逆反心理。但是其实我们是需要意义的，需要一些仪式感。有时候团队是可以被一些意义链接在一起的，但是就像我说的我们这一代人害怕意义，所以这一点要慎用。但是，我觉得作为 TL，不要去害怕意义，首先你要自己相信，然后你是可以带动团队的，能够大大增强士气。
人活着，真的是需要去相信一些看上去不那么可信的东西的。
大厂跳小厂
- 公司商业模式的可行性，这公司是靠什么赚钱，靠 C 端用户不断的拉新转化付费，还是 B 端用户的年年续费，靠投资人和机构一轮轮进入接盘输血，还是 toG 方向靠政府和商务关系回收项目账期，还是靠讲商业小故事和稳定的财务汇报来获得大公司并购收购…，尽量的走近用户，走近商业逻辑，看清楚这盘棋。
- 市场窗口期的长短，不同行业从荒漠到蓝海到红海，都有它不同的周期，有的需要上十年的蹲点储备，比如生鲜行业目前基本都是亏钱运营，要想整体性大幅的靠规模盈利需要至少 5~10 年的商业周期，熬不住就只能关门倒闭，有的是只有几个月，比如直播间的互动游戏（譬如类修勾夜店的打赏模式），比拼的短平快，对技术和运营的敏捷度要求极高，什么时候上车，什么时候放量，包括什么时候裁员，这个时机的判断就来源于他个人对于某个行业市场窗口期的判断。
- 团队人员成本和产品收益的衡量，每个月都关注公司的整体营销运营成本和研发成本，根据这个动态关系，决定什么时候招人，招多少人，招什么样的人，哪些人是进来临时充当研发劳动力，哪些人是进来作为长期合作伙伴，一起创业长跑的，几乎没有人会在一个公司干一辈子，他不会，他身边的同事不会，他招聘的下属也不会，在某个周期内，大家有一个共同的利益和目标即可，这时候他既不是资本家，也不是「剥削者」，他是一个承担了一定管理职责的骨干，既要做好人（给团队和员工带来更多软的、硬的成长和福利），也要做坏人（对员工做考勤来保证项目节点、辞退不合适的人、裁掉部分人来保证公司的整体的运行节奏），此时，在商言商，与公司一起渡难关，承担最大的风险并享受最大的回报，把公私分开，把个人情绪和团队目标分开，做一个高效的职场得分王即可。
- 多交往各行各业的朋友（不限工种），大厂的这些年把他保护的很好，不太见到社会上的「污垢」，感受不到「商业战场」的你死我活，多扩展自己的朋友半径，真朋友、假朋友、利益的朋友、一面之缘的朋友，什么类型的朋友无所谓，永远对自己的真朋友保持真诚和坦诚，充分利用自己能借助到的所有的朋友的合理，敢于开口敢于所求敢于 Say No，并在自己能负担的前提下，对朋友也伸以援手，你拉他一把，他拉你一把，拉着拉着，一个人的事业线就越走越宽了。
技术文章
技术文章要在逻辑清晰的基础上，进一步追求文章的易读性和实用性，提升阅读体验（也就是阅读时的爽感），增强文章的吸引力和价值。
XY问题
https://zhuanlan.zhihu.com/p/612569093
高效沟通的拦路虎
在提问题的时候，没有一开始就抛出自己的原始问题X，而是抛出一个自以为是是解决X问题的关键问题Y，觉得只要解决了Y问题，X问题就迎刃而解了。结果经过一番折腾用尽各种办法解决了Y问题后，才发现，解决了Y问题并不能解决X问题。
随笔
https://juejin.im/post/6867385407785402381?utm_source=gold_browser_extension
前端技术离不开业务，技术永远服务于业务，开发不光是写页面，利用前端页面实现工具化、自动化，推进到平台化更是重中之重
组织的核心是人才, 任何一个组织发展都离不开对人才的渴求, 作为一个组织的领导者, 一个团队 TL, 如何去识别和发现人才在有些人眼里可能是一种玄学, 但在我看来, 识人之明是有迹可循的, 是一种客观评价加主观直觉的综合判断.
所谓识人即要看清楚一个人的当下与未来的可能性, 就是通常说的能力与潜力.
管理者的核心职责，是带领团队去达成目标。
作为工程师，对自己的职业要有忧患意识，不要指望靠「公司不裁员」来维持自己的职业竞争力
作为前端工程师也需要一定的后端视野，更需要一定的产品视野，有的时候需要跳出技术人的视角去整体看待一个产品。
技术的革新从来都不会等待，历史的滚轮也不会因为部分人而停止，作为一个优秀的工程师只有不断地持续学习才能避免被淘汰。
大中小公司
工程师这个与机器打交道多过于人的职业，刚毕业的大学生到工作四五年的历程中，整个社会人格和成熟心智的塑造上，确实比一般的社会人会差之蛮多，在这样的背景下，程序员虽然技术造诣很深竞争力很强收入很高，但心智成熟度的欠缺会导致看问题总不能理性客观的同时还缺少烟火气。
- 大公司“效率低”、“螺丝钉”、“协作难”
- 中型公司“管理混乱”、“业务有瓶颈”、“不重视人才培养”
- 小公司“不稳定”、“身兼多职”、“制度不完善”
技术的价值
技术的价值在于解决业务问题，“业务支撑” 和 “基础建设” 从来都是同一件事的两个面，这个 “同一件事”，就是帮助业务解决问题。前一个解决业务 “活在当下” 的问题，后一个解决业务 “拥抱未来” 的问题；前一个是对业务诉求的单点式解决，后一个是提供通用方案解决共性普遍问题。都是在用技术的方式解决业务问题，但投入产出比上存在着不同。架构能力和技术创新，从来都是伴随着业务的普遍、共性、高频问题，不会凭空生出。不深入业务，不直面问题，也就谈不上技术成长和创新。
业务跟需求是不一样的。理解需求并不等于理解业务，需求是业务经过产品消化后的产物，可能已经经过演绎或者拆解，因此需求并不是业务本身，当然了解的需求越多，对业务的全貌也会更加了解。
公司裁员的征兆
业务发展遇到较大瓶颈，并且难以突破、频繁调整战略目标、高管开始陆续离职、开始严抓考勤、开始部分同事劝退，如果你现在的公司也开始出现这些症状，别想了立刻把简历准备起来吧
技术路线的选择重要但不具有决定性
———————————————— 版权声明：本文为CSDN博主「myan」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/myan/java/article/details/3247071
公司上市对普通员工有什么好处
https://zhuanlan.zhihu.com/p/104784444
我们先来说说好处吧：
-
公司上市，公司知名度提高，你对外介绍自己的时候会更有面子，可以催催牛逼。
-
公司会更正规，你应该能学习到一个公司从草莽到正规化的过程。
-
公司会更稳定，暂时可能不用担心公司拖欠工资、倒闭这样的事。
-
跳槽的时候可能会更有点底气。
-
可能会收到一个阳光普照的小红包。
说坏处了：
-
公司上市相当于公司增加了很多的股东，而公司产生的利润需要给这些股东分享，所以能给到员工的福利津贴很有可能会减少。
-
所谓正规化就是说公司会尽量把工作流程模块化，每个人就负责他自己那一块，不会有太多的发挥空间，因为这样才更稳定，不会因为一个人的变动而影响大局。
-
公司上市后，为了追求更好看的财报，控制成本会更严格，8K能招到人的岗位就绝不会用一个10K的人。所以你的收入提升空间也会比较有限。
-
公司的财务表现会是更重要的考量，所以从产品到运营方方面面都要考虑到这东西能不能赚钱，什么时候能赚钱。你很可能需要向一些短视的行为妥协。
总结一下，公司上市对普通员工来说，会更稳定、更安全，但也更受限制。所以对一个刚毕业的职场新人来说，在上市公司里能学习到很多东西，这是重要的经验积累。但对工作多年的老鸟来说，可能发挥的空间就比较小，但如果对求稳定来说，也是一个不错的选择。毕竟收入只是衡量工作价值的一方面，你说是吧。
什么是架构
所谓的架构，其实是对工程链路的一种整合、抽象，目的是为了更好地支撑一线业务。好的架构，一定来源于一线业务，一定是基于一线业务的实际场景不断地迭代、优化沉淀下来的结果。脱离了一线业务的架构，一定是站不稳脚跟的。
测试驱动开发
https://teobler.com/posts/20210221-agile-technology-practices-tdd
Test-Driven Development
TDD 的规则很简单，可以归纳为下面三条：
- 先编写一个因为缺乏生产代码而运行失败的测试，然后编写生产代码。
- 只允许编写一个刚好失败的测试 - 编译失败也算失败。
- 只允许编写刚好能使当前失败测试通过的生产代码。
如果遵循 TDD 三原则，意味着你的每一行生产代码都是有测试保证的 - 先有的测试，才有的你那一行恰好可以通过的生产代码。你的测试是完备的，你有信心部署你测试全过的代码，这些测试告诉我们，我们的系统是可靠、可部署的。
becoming cto
https://web.archive.org/web/20171128214925/https://juokaz.com/blog/becoming-a-cto
The CTO must protect the technology team from becoming a pure execution arm for ideas without tending to its own needs and its own ideas
CTO 必须保护技术团队免于成为想法的纯粹执行机构，而不会倾向于满足自己的需求和自己的想法。
If a CTO doesn’t have that sort of power for technical decisions, they are not a CTO, but more of a lead engineer, in a suit. Suit being optional.
如果 CTO 在技术决策方面没有那种权力，那么他们就不是 CTO，而更像是穿着西装的首席工程师。西装可选。
CTO is a job in business strategy, one which defines the direction of technology inside a company.
CTO 是一项业务战略工作，它定义了公司内部的技术方向。
I’d like to believe that this is a stepping stone to becoming a CTO - not caring about these sort of things, not overly focusing on technical details but instead looking out for the team and everything else on top of that.
我愿意相信这是成为 CTO 的垫脚石——不关心这些事情，不过度关注技术细节，而是关注团队以及除此之外的其他一切。
服务业务，技术克制
简单说就是贴着业务走。拒绝只求花里胡哨的技术demo，把核心能力做好，把产品成熟度做好，考虑拿到业务价值是第一位的。
