《跨越鸿沟》是由杰弗里·摩尔（Geoffrey A. Moore）所著的一本关于市场营销的经典书籍。它详细描述了高科技产品在市场上从早期采纳者到主流市场的过渡过程，以及伴随这一过程的各种挑战和策略。书中所说的「鸿沟」指的是产品从「早期采纳者」阶段过渡到「早期大众」阶段时面临的市场接受度的断层。在 SaaS 领域，这个概念尤其重要，因为产品往往需要迅速获得大规模用户基础以实现规模经济。在《跨越鸿沟》中有一个非常重要的技术采用生命周期（Technology Adoption LifeCycle），技术采用生命周期为一钟形曲线（Bell Curve），该曲线将消费者采用新技术的过程分成五个阶段，分别包括创新者、早期采用者、早期大众、晚期大众与落后者。每个阶段都代表了产品在市场上获得不同群体用户接受的过程，并且对于 SaaS 企业来说，用户行为也略有不同：创新者- 冒险家，这些是最早采纳新技术的人。他们愿意承担较高的风险，对新技术充满热情，并且通常拥有技术背景。在这个阶段的 SaaS 企业提供的通常是最新的、创新的服务或功能。这些服务吸引了那些对新技术充满热情的早期用户，他们愿意尝试共建并提供反馈。这些用户通常对新技术的接受度高，愿意承担一定的风险。早期采纳者- 意见领袖，他们也对新技术抱有热情，但他们更关注技术能为他们带来的实际价值和优势。对于 SaaS 企业的这个阶段来说，用户开始认识 ...继续阅读 (93)

离上次聊跨端已经过去一年多了，想再聊一下跨端架构这件事，因为在实际工作中落地遇到了很多问题，以总结。先回顾一下上次聊的内容，上次主要聊了跨端架构的重要性、核心概念以及实际应用的几种策略。我们将跨端架构分解为三个层面：硬件形态、相同硬件形态下的不同平台和相同平台下不同的应用或应用中的衍生应用。还详述了几种常见的跨端架构方案，包括 H5 hybrid 方案、框架 + 原生渲染、框架 + 自渲染引擎和 DSL 编译 + 混合渲染。并深入探讨了如 Qunar 的 React Native 优先的多端统一化方案、Flutter 全平台方案和 Hybrid 方案等实际落地的策略。这些方案各有优缺点，需要根据特定的业务需求和场景来选择最适合的跨端架构方案。更多细节可以见：跨端架构的技术选型 2022而今，在此基础上，我想再聊聊关于跨端架构落地过程中因为遇到一些问题而产生的思考。1 平衡在实现「一次编写，多端运行」的愿景下，我们的核心关注点是成本和体验。这其中，复用代表了我们在成本方面的考量，我们希望通过复用代码来降低开发和维护的成本。而提升用户体验则代表了我们在体验方面的追求，我们希望无论在哪个平台上，用户都能得到最好的原生体验。然而，这两个目标之间存在着一种天然的张力。在实践中，我们常常需要在代码复用（降低成本）和优化用户体验（提升体验）之间寻找一个平衡。这就需要我们不断地试错、调整，找到适合 ...继续阅读 (140)

很多人在刚入职公司甚至在大学就开始看这本《高效能人士的7个习惯》，其成为了一个「众所周知」的提升效能的书。个人在很早以前就读过这本书，最近在 Lily 老师的指引下，又重温了这七个习惯。一些习惯在工作中已经在实践，一些在实践但是做得不到位，还有一些实际和理想有一些出入，知行没有合一。知易行难。再次梳理总结如下：《高效能人士的7个习惯》（The 7 Habits of Highly Effective People）是史蒂芬·柯维（Stephen R. Covey）在 1989 年出版的一本自助书籍。这本书提出了七个习惯，旨在帮助个人和组织提高他们的效能。这七个习惯的简要概述如下：主动积极（Be Proactive）：积极主动的人选择负责任的反应，他们理解自己的行为是基于自身的选择而非外界条件或情绪的产物。这是关于个人责任和主动性的习惯。如从语言表述开始，将「我必须」改为「我选择」。以终为始（Begin with the End in Mind）：高效能的人有清晰的目标和愿景，他们行动前先确立结果，让每一步都朝着既定目标迈进。为了实践这个习惯，咱们可以写下个人使命声明，作为行动指南。要事第一（Put First Things First）：这个习惯强调优先处理最重要的任务，区分紧急与重要，确保时间和精力投入在最能产生结果的活动上。这是关于时间管理的习惯。柯维推荐使用四象限来确定任务的 ...继续阅读 (88)

春节放假期间把微信读书上的几本和 AIGC 相关的书都粗读了一遍，其中提到 MaaS (Model as a Service) 模型即服务有两个不同的观点。一个是《AIGC 商业宝典》中提到的曾担任奥巴马政府首席数据科学家、并在 LinkedIn 和 eBay 担任数据科学家的 DJ·帕蒂尔(DJ Patil) 在其博客文章《模型即服务：机器学习小而美的未来》阐述了 MaaS 的概念和应用：将机器学习算法打包成可重复使用的服务，使企业能够快速地构建、部署和监控自己的模型，无须自己开发和维护底层基础架构。另一个是《AIGC 未来已来》中提到美国知名投资人 Chamath 也谈到模型即服务将会颠覆现有的 SaaS 服务。他表示，“很多软件尤其是企业服务领域的软件，将会被替换为一个单一的模型，来帮助我们解决特定的问题”。毫不夸张地说，如果在AIGC时代，企业想仅靠应用层面的竞争而成为下一个科技龙头，显然难以实现。我们从人工智能的发展历程中已经明显地看出，模型的迭代和进步才是AIGC爆发的关键。谁能够掌握更先进的人工智能模型，谁就拥有开启新时代的钥匙。个人理解这两个观点都没有问题，只是在不同时间线上的观点。帕蒂尔是 2012 年提出这个观点，并且在当下可以落地实施。Chamath 是最近提出来的观点，表达的是将来可以落地的构想。帕蒂尔所说的 MaaS帕蒂尔所说的 MaaS 改变的是传统的 ...继续阅读 (87)

冯唐在《成事心法》中提到过这样一个观点：「只要你把这 100 个相关的关键词搞清楚，而且每个关键词，你都能给出合理的答案，那么你也可以成为这个领域的专家」。想要快速了解 AIGC 文生图，从了解下面的 15 个关键词开始吧。AI 概念名称AIAI，Artificial Intelligence，人工智能人工智能这个词在大众想象中常常会勾起有关自主思考的机器人和智能机器的画面。但核心上，AI 是关于创建智能算法的学科，目的是执行通常需要人类智慧才能完成的任务。人工智能的概念自 20 世纪中叶以来就已存在，但它是在 1956 年的达特茅斯会议上，由约翰·麦卡锡正式提出的术语。从那时起的几十年里，AI 已经从理论概念演变成一个涵盖机器学习、神经网络和深度学习等的强大领域。如今，AI 不仅仅是一个研究领域；它已成为我们日常生活中不可或缺的一部分，改变着行业并创造出曾经只存在于科幻小说中的新可能性。AGIAGI，Artificial General Intelligence，人工通用智能，也称为强人工智能或全能 AIAGI 指一种具有普遍的认知能力的机器智能，它能在各种领域和任务中表现出与人类相当或更高的效能。与目前的人工智能系统（被称为弱 AI 或专用 AI ）不同，这些系统通常设计用来解决特定问题或执行特定任务，AGI 将能够像人类一样学习、理解、推理和应用知识于新的和多样化的情境中。A ...继续阅读 (87)

周期性：工资通常按周期支付，最常见的周期包括每周、每两周、每月或半月一次。这种周期性支付帮助员工规划他们的长期和短期财务需要。合同性和法律保护：工资的数额通常在员工合同中明确规定，这使得工资成为雇佣关系中双方约定的法律义务。工资支付受到严格的法律保护。雇主通常被要求在特定的时间内无条件支付工资，迟发或少发工资可能会受到法律的处罚。税收征缴：工资收入通常是可征税的，雇主在支付工资时需要按照法律规定扣除相应的税款，包括所得税、社保和医疗保险等。透明性：良好的工资管理要求具有透明性，这里的透明不是指对所有人透明，员工应该能清晰地了解自己的工资组成，包括基本工资、加班费、奖金等。工资不仅仅是员工为其劳动力所获得的经济补偿，它在现代社会中扮演着多重作用。首先，工资是确保员工基本生活需要的关键。通过为个人和家庭提供必要的经济资源，工资支持了社会成员的基本生存和福利水平。这种直接的经济支持功能对于维持社会稳定和个人福祉至关重要。在更广阔的意义上，工资水平反映了社会对不同职业的经济评价和需求，它影响着劳动力市场的供需关系，进而决定了资源在不同行业和职业间的分配。其次，工资对于劳动力市场的调节具有中枢作用。它是激励机制的核心，可以影响员工的工作表现和生产率。一个合理并具有竞争力的薪酬结构能够吸引和保留关键人才，促使员工提升专业技能，并且激发创新。工资还可以作为一种反馈机制，通知员工他们的表现和努力被 ...继续阅读 (89)

前面我们聊了 Saleforce 关于开放能力的演化，今天我们聚焦聊一下 SaaS 产品 API 的开放。因为 Salesforce 在 API 开放接口方面的发展历史反映了其作为一个 SaaS 平台不断演进的过程，以适应不同的集成需求和技术标准。以下是 Salesforce API 的发展历史的概述，以及每种API解决的问题和它们的价值：Salesforce API 发展历史Salesforce Web Services API (早期的SOAP API)Salesforce 最初的 API 是基于 SOAP（Simple Object Access Protocol）的 Web Services  API。这个 API 自 Salesforce 平台在 2000 年代初推出之初就存在，它允许开发者通过网络进行远程调用，与 Salesforce 的数据进行交互。SOAP API 允许企业和开发者在各种编程环境中利用 Salesforce 数据，为客户提供定制化的解决方案。它使得 Salesforce 不仅是一个 CRM 产品，同时也是一个可以集成到企业 IT 环境中的平台。尽管功能强大，但 SOAP 协议相对复杂，对网络带宽和处理能力有较高要求。Salesforce REST API随着 Web 2.0 概念的普及，RESTful 架构开始流行。它基于 HTTP 标准协议，使得 ...继续阅读 (107)

在当今快速变化的软件行业中，SaaS（Software as a Service）模式因其灵活性、可扩展性和成本效益而广受欢迎。作为这个领域的先驱之一，Salesforce 不仅仅是一个 CRM 工具，它通过不断扩展其开放能力，已经成为了一种全方位的商业解决方案平台。通过观察 Salesforce 的发展，我们可以清晰地看到 SaaS 产品开放能力的演化路径，以及这种演化过程给技术和商业带来的机遇与挑战。以下为 Salesforce 的开放能力的演化过程。SalesForce 开放能力的时间线我们先从时间线来看 SalesForce 在开放能力上所做的事情。2000 年： API 接口Salesforce 最初作为一款 CRM 软件服务亮相，在 2000 年代初期，它引入了 API 接口，允许第三方应用程序与 Salesforce 集成。Salesforce 提供了基本的 API，允许用户读取和更新其 CRM 数据。随着时间的发展，Salesforce 推出了更加强大和灵活的 API，例如 REST API、 Bulk API、Streaming API 等，这些 API 支持更大规模的数据操作和更复杂的交互。2005 年：Salesforce AppExchange2005 年，Salesforce 推出了 AppExchange，这是一个企业应用市场，允许第三方开发者创建和销售 ...继续阅读 (120)

最近比较多的文档专用时间都花在写 OKR 上，也有一些探讨，发现小伙伴们对于 OKR 在认知上是不一样的，有些多一些，有些少一些，有些甚至是为了写 OKR 而写 OKR，属于应付了事。于是今天就聊聊 OKR，聊下 OKR 是为组织解决什么问题，如何生成 OKR，写 OKR 过程中对于上线时间这种要不要写进去，以及 OKR 和 OGSM 有什么关系。先想一下一个组织为啥要用 OKR 这个工具，其解决的是什么问题？OKR 是一种帮助组织设定、追踪和实现目标的目标管理工具。其解决的主要问题包括以下 4 点：一，聚焦和优先级的问题，因为组织经常面临资源有限的问题，需要确定优先关注的领域。OKR 通过设定明确的、优先级排序的目标，帮助团队和个人集中精力在最重要的任务上。二，透明度和对齐的问题，通过公开共享 OKR，组织内的每个团队和成员都可以对其他部门和同事的目标有所了解，从而确保所有人的工作都朝着相同的方向推进，实现组织目标的一致性和对齐。三，衡量和追踪过程的问题，OKR 提供了一种衡量进展的机制，通过定期检查关键结果，组织可以实时了解他们是否接近既定目标，从而及时调整策略或努力方向。四，激发员工参与和动力，OKR 通过设定具有挑战性的目标来激励员工，同时关键结果的实现也让员工感受到成就感，从而激发他们的积极性和参与度。除以上 4 个以外，OKR 在提高执行力也能发挥比较大的作用。当一个组 ...继续阅读 (98)

新的一年了，又到了做规划和 OKR 的时候了。作为一个技术团队的管理者，此时除了面对业务的诉求，从技术架构、从团队管理、从未来发展应该做些什么呢？以下是最近一段时间来，个人的思考。从经营的角度来看，研发团队成本对于软件企业来说是成本的大头，作为团队的负责人需要在满足业务需求的前提下，提高研发团队的产出和产出的价值，同时尽量降低过程中的成本，也就是在之前文章中所说的研发价值。这里的研发价值可以具象到研发效能这个概念，在我们做技术规划和 OKR 时，底层思考中的研发效能不仅仅是衡量研发资源使用的效果，更进一步，是指研发团队达成既定目标和结果的能力，换句话说，就是提升当前研发团队的核心竞争力。研发效能不仅包括了技术层面的各种实践，如代码复用、自动化测试、持续集成（CI）和持续交付（CD），还包括了效能度量、流程优化，团队协作、项目管理、需求理解和用户反馈的及时整合等多个方面。研发效能的核心目的是优化交付的价值链，通过提高效能来缩短产品从构思到市场的时间，提升产品质量，降低开发成本，以及增强对市场变化的响应能力。这不仅能提高客户满意度和用户体验，还能为企业带来更大的经济效益和更强的市场竞争力。每个企业，每个团队在做规划时，应该是基于现况，基于客观事实来做规划，明确当下最重要，最需要解决的问题是什么，确认目标，一个个去解决。比如当前大家意识层面有所欠缺，那就想办法拉齐认知「共读一本书」；又或 ...继续阅读 (107)

引子在技术管理者的职业生源中，每一次空降都是一场冒险。无论是谁，一旦从大厂的云端跳伞，降落到充满活力但更为复杂的创业公司，都等同于跨入了一个全新的战场。最近和一个在某创业板新上市公司做过人力资源总监的朋友聊天，有聊到技术高管空降的部分。他分享了三个关于这家公司最近三四年中观察到的三个技术高管的空降过程。这三个技术人在这个过程中挣扎，扎根适应，或者离开。看这三个故事是对看文章的你有所触动？交待一下这家公司的背景：传统行业的新零售，趁着抖音等的火热，其业务从线上到线下，持续火热，于前两年上市创业板，这里分享的是在上市前后入职的三个技术高管的故事。传统零售线上部门研发总监我们的第一位主角是一位年逾四十的研发总监，他是从传统零售茂业百货的线上平台起步，CEO 看中了他为线下传统零售搭建线上零售电商平台的经验。既有传统零售转型的经验，又有足够的管理经验，其跨足到一个新零售公司，以百万+年薪，被公司寄予厚望。优势部门管理经验丰富，有多年的实际技术团队管理经验，快速建立起技术团队技术功底扎实，技术问题基本都能搞定性格不强势和团队能打成一片，兄弟义气，从前公司挖了一些人过来，且能够带领团队攻克难关劣势战略思路及能力差，大多数事情在技术逻辑上业务 sense 和能力不够结果在公司呆了两年多，也把技术团队做得不错，但是老板对其的定位是技术负责人以及线上业务的负责人，其只搞定了技术负责人的角色，没有搞定 ...继续阅读 (105)

SaaS（Software-as-a-Service，软件即服务）概念起源于 1999 年之前，而将这个概念真正实践到商业环境的则是 Salesforce 的总裁马克.贝尼奥夫。在此之前有 SaaS 的先驱 ASP 以失败退场。对比国外至少 40 年的 SaaS 领域的历史，中国到 2015 年才称之为 SaaS 的元年，并且到 2021 年中国企业级 SaaS 的融资事件总数和融资总额也达到一个小高峰。据艾瑞咨询的报告称，2021 年中国企业级 SaaS 市场规模为 728 亿元，宏观经济下行带来了更大的压力，企业 SaaS 总需求收缩将使得行业增速大幅下滑，未来三年 SaaS 行业的增长也将与宏观经济恢复速度相挂钩，在中性预期下，到 2024 年中国企业级 SaaS 市场规模将有望达到 1201 亿元。随着业务的深入和服务经验的积累，部分赛道的 SaaS 产品边界变得愈发模糊，厂商由点及面加速一体化布局，工具型 SaaS 横向渗透并融合特定业务场景来发挥自身价值。在这个赛道创业或工作的技术同学不少，但是技术同学限于技术领域，对于业务的关注较少，在老板、运营同学或产品同学提到 LTV、ARPU、MRR、CAC 等术语时，最开始可能都是一脸蒙，用某个产品大佬的话说，要先拉齐认知，于是有了这篇文章。这篇文章从获客、留存、营收和产品发展阶段等几个方面来梳理一下 SaaS 创业中技术人员 ...继续阅读 (99)

周四下午作为分享嘉宾参加思码逸组织的关于研发效能的技术沙龙，在最后圆桌会议探讨环节，有同学提了一个问题，研发效能是不是一个伪命题？现场回答了下，会后也有持续思考这个问题，基于会后的思考，做一个更完整一些的陈述和总结：从研发效能的定义出发，从背后的逻辑出发，从具体的实践方向出发，来看研发效能这个事情。说到研发效能，大家可能会马上想到度量、指标、流程、CI/CD、代码平台等等东西。但只是这些吗？为什么要做这些？做了这些有什么用？最终的目的是什么？…… 有很多问题冒出来。研发效能是什么看研发效能是什么前我们先看一下效能是什么？效能是一个衡量资源使用的效果的概念，常用于评价在完成一定任务或达成特定目标时资源（如时间、金钱、原料等）的使用效率。效能高意味着用较少的资源投入获得了较多的产出，或者用最优的方式使用资源以达到最佳的工作绩效。在商业和管理领域，效能是指组织或个人在达成既定目标和结果的能力。商业和管理领域中的效能更加注重最终的成果而不仅仅是资源的使用。传统意义上的效能只是商业和管理领域效能的一个过程态，但我们当下所追求还是传统意义上的效能，通过这种效能的不断达成，使得组织的效能增加，从而帮助企业更有效地管理资源，提高组织能力，并在市场竞争中保持优势。回到研发效能是什么，这里我们限定一下范围，主要是软件开发的研发效能，有代码产出的那种研发。对于软件开发来说，主要关注的还是人力成本，或者说 ...继续阅读 (95)

当你成为一个技术团队的管理者时，就会经常会被老板问到，研发的价值在哪里？如何让研发的价值更大？现在的研发团队和行业内相比效率/能力/水平怎么样？如此种种……每个公司每个技术团队的管理者都有自己的逻辑来回答这个问题，因为这是带团队的核心逻辑之一，且各有缘法。今天这篇文章不是想准确的回答这个问题，也不是标准答案，只是这些问题最近引发的一些个人思考。先抛两个公式：公式一：研发的价值 = (业务价值 + 技术价值) – 非正常成本 – 正常成本公式二：研发的价值 = 单位有效时间内产出的价值 × 有效时间 – 非正常成本 – 正常成本这是简化的研发的价值模型，可以作为理解研发价值创造的基础框架。实际应用中可能还需要进一步的细化和调整，因为价值的计算可能远比这两个公式复杂。总体来看，让价值更大在于攻守，如何攻，如何守，攻就是提高产出价值，守就是减少成本。在攻的方面，提高产出价值包括提高业务价值和技术价值。我们都知道业务需求是做不完的，如何在做不完的业务需求里面产出更大的价值，关键点在于业务需求本身的价值和业务价值生效的时间，将具有更大价值的业务需求更快的上线是提高研发侧业务价值的主体逻辑。当然，需求上线后可能还有 bug 之类的，这个我们作为守的那部分来聊。提高业务价值提高业务价值的主体逻辑包括两层意思，一个是更大价值的业务需求，另一个是更快的 ...继续阅读 (90)

在当今时代，互联网已成为我们生活中不可或缺的一部分，涉及到日常的方方面面。无论是打车、购物还是社交，我们都依赖于各种应用程序。但是，这些服务一旦出现中断，就可能引起严重的后果。2023 年 11 月份，我们见证了两次重大的网络服务故障：11 月 12 日下午，阿里云服务出现异常，导致依赖其服务的多个厂商及其产品功能受损，包括其自身的产品钉钉。紧接着，11 月 27 日晚，滴滴打车应用程序出现故障，直到 28 日中午才逐渐恢复正常。这次滴滴的服务中断超过了 12 个小时，引起了用户和司机的混乱和不便。就在昨天，12 月 1 日上午，上海医保系统无法进行结算，网友形容「看病一分钟，排队两小时」，凸显了网络服务依赖的脆弱性。特别一点说，滴滴出行在 2023 年 11 月 27 日发生的故障，使我们不得不重新思考我们对系统复杂度的认知。从滴滴的恢复过程中可以看出，系统经历了部分恢复、再次出现问题，数据混乱等现象。整个系统看似处于混乱之中，但在多方努力介入处理后，逐渐恢复稳定并重新运作。这个过程好比一个受伤的系统在逐步疗愈。公众的反应也多种多样，有人归咎于滴滴的「降本增效」策略，有人认为是管理层的失误，还有人指责技术升级不当。但如果把滴滴看作一个整体的系统，它无疑是高度复杂的，由人员、组织结构和各种在线系统组成。这个系统的复杂性在平时可能被我们低估，因为每个人通常只关注自己负责的那部分工作。 ...继续阅读 (103)

你是否也遇到过线上出问题了，查找日志，发现都是 ERROR 日志？你是否也遇到过虽然有日志，但是日志实在太多，在茫茫日志中无法有效地定位到问题？你是否遇到过要去排查前人写的代码产生的 BUG，却还需要把先把相关的代码过一遍，找到相关日志点，再去搜索日志？你是否遇到过日志越来越多，不同的人都在打，有些日志没有用了，还是在不停的打？你是否遇到过奇怪类型的日志，甚至相互冲突以至于无法定位问题？你是否遇到过因为打个日志，导致客户端崩溃？……当日志不在大家的视野中，凭着个人的喜好去打，去定位问题，最终整个日志就会变成一个不断膨胀的怪物，变成大家使用起来都感到困扰和无助的混乱池塘。当日志的生成和使用没有统一的规范和标准，每个人都按照自己的方式和喜好来记录和查找日志，日志的内容和格式就会变得五花八门，导致理解和分析日志的难度大大增加。另外，无效的、重复的、甚至是错误的日志会像野草一样无序地生长，使得日志的数量越来越大，而有效的、有用的日志则可能会被淹没在这个日志的海洋之中。此时，我们需要建立一套有效的日志管理策略，包括设定清晰的日志记录标准，实施有效的日志标准管理，优化日志存储和清理策略等。只有这样，我们才能把这个日志怪物驯化，使得日志成为我们解决问题的有力工具，而不是一种困扰。从过往的经历和上面描述的这些问题里面我们洞察了如下的问题点：日志规范管理的问题日志无序增长的问题日志劣化和无人维护的问 ...继续阅读 (103)

在前面的文章中我们聊了技术成本的精细化运营；聊了要识别出成本要素，找出每个要素的关键成本点，将成本定义为顾客付出的代价，根据成本的基本特性对其分类包括生产性成本、支持性成本、监察成本和浪费成本；聊了成本的核算以及成本和业务以及公司商业化策略的关系等等。今天我们从一个技术团队的负责人角度来聊一下软件研发过程中的成本。研发过程中成本主要包括研发过程的成本和对业务产生的影响而带来的「非正常成本」。而其中软件研发成本的核心是认知成本和沟通成本。认知成本认知成本是一个相对宽泛的概念，它涉及到所有获取、理解、处理信息以及进行决策的努力和资源。在一般情况下，认知成本可以分为以下几个部分：学习成本：这是指为了掌握新的知识、技能或工具所需要的时间和精力。如一个开发同学需要学习一种新的编程语言，那么这就会产生学习成本。理解成本：这是指为了理解新的信息或知识所需要的时间和精力。如阅读和理解一份复杂的技术方案文档就会产生理解成本。处理成本：这是指为了处理信息，比如进行分析、整理或应用，所需要的时间和精力。如分析一份用户行为数据报告就会产生处理成本。决策成本：这是指为了做出决策，比如评估选项、权衡利弊、制定策略，所需要的时间和精力。如选择一个软件开发框架或选择一个市场策略就会产生决策成本。在实际应用中，降低认知成本通常是提高效率和效果的重要目标。例如，良好的用户界面设计可以降低用户的认知成本，提高用户体验； ...继续阅读 (123)

一个技术团队管理者在带团队过程中常常要「通过别人的手拿到结果」，常常要主动去改变一些事情，去完成一些公司或上级的要求，甚至要自己去做一些事情……仔细回顾一下，有没有出现你的上级绕过你直接找你的下属来处理问题，而你一无所知，只有出了问题的时候才知道？有没有出现你发起了一个事情，任务已经交给下属/其它同事来跟进处理了，到截止时间，结果和你想象中的不一样？有没有出现你实在忍不住，亲自动手把那块代码写了，一边写还一边吐槽，也就十几分钟的事儿，跟他讲的时间都已经上线了……如此种种，是不是很是亲切，经常会遇到。这到底是哪里出问题了呢？如果把这些事项都当作一个项目来看的，这些项目中有三个主要角色：发起人（Sponsor）、负责人（Project Manager）和核心成员（Core Team Members）。上面的这些问题大多数是角色错位，职责分工不明确或者项目成员本身对于自己所在角色的认知不清晰导致的。今天我们就聊聊这三个角色，以及经常会出现的问题。发起人（Sponsor）发起人是项目的发起者，他们通常是公司的高级领导人或决策者，有权利和资源来推动项目的实施。他们的主要职责和特点包括：确定项目的战略目标，并向所有相关方清晰地传达这些目标，一般不参与具体任务。提供必要的资源和资金以支持项目的实施。对项目有最终兜底责任，在必要时提供对项目的支持，解决可能对项目产生影响的问题和挑战。监督项目的进度 ...继续阅读 (109)

在 10 月 23 日，语雀服务出现了一次重大故障，中断时间超过 7 小时。具体来说，这次故障的起因是在执行系统升级操作期间，新的运维升级工具出现了 bug，导致华东地区生产环境的存储服务器被误下线。由于存储系统使用的机器类别过于陈旧，无法直接将其上线，这导致了恢复过程时间延长。尽管语雀的工程师们立刻进行了恢复工作，但由于数据量大，恢复方案有限，恢复过程耗时 4 小时，数据检验耗时耗时 2 小时。这次故障给用户带来了严重的影响，也让我们重新审视关于本次故障带来的思考。我将整个复盘报告输入给到 chatGPT，其给我的回复如下：从语雀的这次事故中，我们可以学到以下几个关键的教训：重视运维工具的测试和质量保证：在这次事故中，新的运维升级工具的 bug 是导致故障的主要原因。这说明，即使是运维工具，也需要进行足够的测试和质量保证。在实际使用之前，应该在相似的环境中进行充分的测试，确保其稳定性和安全性。灾备和恢复系统的重要性：即使有了数据备份，恢复仍然可能需要花费大量时间，这会导致服务中断时间过长。因此，除了定期备份数据外，还需要建立有效的灾备和恢复系统，以便在灾难发生时，能够快速恢复服务。灾难恢复演练的必要性：定期的灾难恢复演练可以帮助我们在真实的灾难发生时，更快地恢复服务。通过演练，我们可以发现并解决恢复过程中可能存在的问题，提高恢复的效率。高可用架构的重要性：高可用架构可以保证在部分 ...继续阅读 (99)

我们经常会发现工作中会出现很多重点项目，很多事情忽然就来了，问就是老板需求，却没有一个过程来告诉大家前因后果和价值。这往往会导致大家感到迷茫，因为没有获得足够的信息和时间来理解和准备这些项目。这个过程从项目管理的角度来说是缺少立项，而立项往往是最容易被忽视的。当没有明确的立项过程时，目标模糊、资源浪费、沟通困难、出现项目风险等问题都会时有发生，从而影响整个项目的实施效果和公司的业务发展。1 什么是立项立项是一个组织或公司决定开始一个新项目时的决策过程，这个过程涵盖了对项目需求的明确、项目目标的设定、可行性的评估、资源的分配和风险的识别及管理等关键步骤。通过立项过程，组织能确保每个项目有明确的目标、适当的资源分配、风险控制措施以及一个清晰的执行计划，从而提高项目的成功率和效率。立项的本质是一个综合的决策过程，其中项目的各干系方对目标、方案、成本、风险和里程碑等重要预期进行对齐，以便做出是否启动项目并如何分配资源的决定。2 立项的作用立项就像是给项目开个「导航」，帮助我们明确要去的目的地，规划好路线，分配好需要的人和物，预防可能的风险，确认能否按计划到达，并让所有人都了解这个「旅行计划」，以提高我们的旅行效率和成功率。具体一些，包含以下六个作用：明确目标：立项过程有助于明确项目的目标和期望结果，使所有参与者对项目的方向和目标有共同的理解。如我们在开发一个新的移动应用的立项过程中，项目组 ...继续阅读 (105)

对于一个 SaaS 来说，隔离是一个非常重要的技术架构策略。当隔离的策略和业务不匹配的时候，往往可能会引发一些线上事故/问题，影响性能等等。隔离的意义在于创建独立、安全的运行环境，以保护数据的私密性、保证服务的稳定性，并防止资源的竞争和滥用，从而为每个客户提供高质量且可靠的服务。隔离的本质隔离的本质在于实现独立性和安全性，通过这两者，为每个客户提供一个能够有效，安全使用共享资源的环境。独立性: 隔离确保每个租户都有其自己的资源（如CPU时间、内存空间、磁盘空间等），数据，运行环境和网络通信，且这些都是互不干扰的。这使得每个租户都能在其自己的独立环境中运行，无需担心受到其他租户的影响。安全性: 隔离也保护每个租户的数据，防止其数据被其他租户访问或修改。此外，隔离还能限制每个租户的操作权限，使其只能执行一些安全的操作，以防止其执行可能影响其他租户或整个系统安全的操作。但是现实中我们往往做不到完全的独立性和安全性，需要根据实际的业务情况确定架构，从而有了不同层面的隔离策略。我们在实际工作中，对于隔离策略能感受到的最直接的影响是：一个良好的隔离策略可以在一定程度上改善服务的稳定性，减少因为某些不可预知的突发事件导致的线上问题影响范围。隔离是一件系统工程，我们从其应用层面和基于租户的落地策略来看这个事情。隔离策略的应用层面隔离策略可以应用在多个层面，并且从落地的位置来看，可以分为以下几个层： ...继续阅读 (96)

在我们的工作中经常会看到各种类型的指标，如营收指标、技术指标、效能指标等等，细化下来有年营收金额、SLA、千行代码缺陷率等等。这些指标量化着我们的工作和目标，让我们朝着目标前进，如果指标有问题，也会导致走偏，或者为了指标而玩数字游戏。当迷惑于指标，或者指标有问题的时候，需要停下来思考一下：指标是什么，可以分为几类？指标有什么价值？指标是如何生成的？制定指标的过程中有什么讲究？如何评判一个指标的好处？跟进指标的过程中有什么注意点？对指标进行复盘时要看哪些点？指标是什么指标的本质是一种衡量工具，它提供了一个客观的、定量的方法来评价某个特定的目标或过程的性能或结果。换句话说，指标是把抽象的目标或过程转化为可以衡量和跟踪的具体数值，是一个由虚转实的工具。指标的设计和选择必须反映出我们所关注的核心问题和目标。比如，如果我们的目标是提高产品质量，那么我们需要的指标可能包括产品缺陷率，客户满意度等。同时，指标也是一种沟通工具。它们可以帮助团队成员理解目标，以及衡量他们的工作是否有助于实现这些目标。当所有人都清楚地知道他们的工作如何对公司的总体目标产生影响时，他们可能会更积极地参与和投入。总的来说，指标的本质是将目标和过程量化，以便于衡量和沟通，从而推动团队或组织向预定的目标前进。从价值的角度来看，指标在企业管理和决策中发挥着重要的作用：提供信息和见解：指标能够提供实时的、可量化的信息，帮助企业了 ...继续阅读 (96)

在我们的工作中会遇到很多问题，也会有人来问我们问题，对于问题，我们可能会选择直接解决，或者 @ 某个人来解决，或者 @ 好几个人来解决。如果一个问题是交到我们这里来解决，尽量成为问题解决者。成为问题解决者成为问题的解决者意味着什么？对于技术管理者来说，意味着我们要负责任地处理问题，去解决问题，而不是转发，一定是要对问题本身有认知，有判断后再去处理，再去解决，而不是简单地将问题转发给其他人。这就要求我们深入全面的了解问题的背景和现状，分析问题的根源和可能的解决方案；这就要求我们具备批判性思维、解决问题的能力，以及对我们负责的业务领域和技术领域有深入的理解。也意味着技术管理者要对他的决策和行动负责。我们不仅要解决当前的问题，还要预防未来可能出现的问题，有前瞻性的思维，能够预见可能出现的问题，并提前做好准备。对于一线开发同学来说，意味着我们要负责任地处理问题，去解决问题，而不是转发，不是简单地把问题推给其他人，需要负责任并主动的去寻找解决方案。这需要我们深化对问题的理解，探索可能的解决方案，然后付诸行动。这不仅要求我们具备强大的技术能力，也要求我们有独立思考和解决问题的能力。在面对问题时，我们不应该急于求成，而应该耐心分析，找出问题的根源。这可能需要我们查阅相关文档和资料，或者利用调试工具进行深入地分析。我们必须理解问题的本质，以便找出最有效的解决方案，可能最终只是改一个配置或一行代码。 ...继续阅读 (98)

作为一名技术管理者，面对日常工作中的各种问题和挑战，我们需要具备出色的问题解决能力。技术团队管理本身就是一项充满挑战的任务，而解决问题的能力更是推动团队向前的关键。当一个技术管理者拥有极强的解决问题的能力后，他大概能应对挑战、降低风险、提高团队绩效、增强领导力并提升个人职业发展。在解决问题的过程中，我们可以将问题分为三个层次。了解这三个层次将帮助我们更好地应对不同场景下的问题，成为更优秀的技术管理者。1 应急响应类应急响应类问题的处理是通过快速反应和短期改进措施来修复问题的反应性流程。其主要作用是停止损害，防止蔓延。应急响应通常是一种反应式行为，并不研究根本性的问题以及背后的原因。应急响应不会导致理想状态的实现，但是仍然可以满足即时需求、保护客户，为更加深入地挖掘和调查重要细节赢得宝贵时间。有效的应急响应有助于企业产品获得更好的稳定性。应急响应类问题涉及到系统或产品出现紧急故障时，需要立即采取行动以避免进一步影响。这种解决方式专注于快速应对问题，暂时稳定状况，但可能不会深入探讨问题的根本原因。例如，服务器宕机导致网站无法访问，技术管理者需要立即组织团队快速评估问题的严重性，制定并实施紧急应对措施，进行故障排查，找出问题根源并进行修复，以保障系统正常运行。针对此类问题，常规处理流程如下：确认问题：在故障发生时，第一步是确认问题的具体表现和影响范围。快速定位：尽快找到故障发生的关键环节 ...继续阅读 (80)

1 为什么会有异地团队当一个企业成长到一定程度后，往往会在多地建立研发中心或者业务中心，这里企业的考量可能会有如下的一些点：人才资源：不同的城市和地区可能具有独特的人才资源，通过在多个城市建立研发中心，公司可以吸引和招聘到更多具有不同技能和背景的优秀人才。这有助于公司在保持竞争力，并确保能够获取到足够的人才来支持研发和业务需求。比如深圳是中国的高新技术产业中心，其在硬件制造、消费电子、通信技术等方面具有很强的竞争力，对硬件制造、物联网、人工智能等领域拥有丰富经验的工程师较多，并且由于深圳地理位置优越，靠近香港，拥有国际化的人才环境，因此在跨境项目和多元文化沟通方面具备优势；又如北京是中国的政治、文化和教育中心，拥有众多顶级高校和研究机构，拥有大量理论研究和技术创新方面的顶尖人才，北京的互联网行业较为成熟，尤其是在互联网+政务、在线教育、大数据等方面有较多经验的人才。市场覆盖：在多个城市设立研发中心有助于公司更好地了解和适应不同地区的市场需求。这可以让公司更迅速地响应市场变化，提供更符合客户需求的产品和服务。成本优化：不同地区的劳动力成本、房地产成本和生活成本可能存在差异。在多个城市建立研发中心可以让公司充分利用各地的成本优势，降低整体运营成本。如一些深圳/北京的公司，会把一些研发中心放到西安、成都、武汉、长沙等城市。政策支持：一些城市为了吸引优秀企业入驻，可能会提供各种政策支持，如 ...继续阅读 (93)

GPT-4 于 2023 年 3 月 14 日发布。目前 GPT-4 没有免费版本，仅向 ChatGPT Plus 的付费订阅用户及企业和开发者开放。如比尔盖茨在 reddit 回答网友提问时回答时说的：「AI is the big one. I don’t think Web3 was that big or that metaverse stuff alone was revolutionary but AI is quite revolutionary」，我们可能又到了一个历史性的转折点。现在各家企业，包括 Google、微软，以及国内的 BAT 等大厂都在大量投入，一些中小厂也在垂直的应用赛道拔城攻寨，作为一个技术管理者一定会面对这样一个洪流，在洪流之中我们需要注意什么呢？如果你所在企业要上线 AIGC 的产品，或者已经上线 AIGC 的产品，以下的五个重要事项需要特别注意。1 安全安全是产品的生命线，特别是对于 AIGC 产品来说，没有安全守护，不仅仅是产品玩完，甚至会连累其它产品甚至公司存续。1.1 内容安全这里内容安全的定义是指 AIGC 生成内容影响产品本身存在的领域。在国内与内容安全相关的场景包括涉政、色情、性感（性感和色情在内容安全中是不一样的）、暴恐、违禁、恶心、涉价值观等。其中每一项都需要检测，部分项出现问题甚至会关站和约谈。在 chatGPT 大火后，网络 ...继续阅读 (99)

在看文章之前先思考两个问题：人和人的差别究竟在哪？人和人之间为什么会有差别？在各种场合我们经常听到这样一句话：「听懂了很多道理，却依然过不好这一生」。 这里有两个逻辑，一个是知行合一的逻辑，另一个是人的成长在于是否超越了昨天的自己。今天我们聊一聊作为一个技术管理者应该要有的 4 种基本思维：掌控者思维、杠杆思维，终局思维，闭环思维掌控者思维在聊掌控者思维之前我们先看一下掌控者思维的反面：受害者思维。受害者思维又称为弱者思维，有受害者思维的人在任何时候都会把自己当作一个受害者或弱者，极端者会把整个世界都投射为「伤害者」，「都是别人不对，都是别人对不起我」。受害者思维是一种思维定势，其本质上是一种忽视自己的主观能动性的行为。在《乡村爱情 13》里面，王木生是老总儿子，富二代，但是干啥啥不行，还总是给自己找借口，说大环境不好，其他没这背景的都比他强。赵本山饰演的他爹王大拿就教训他：「自己没能力就说没能力，怎么你到哪，哪都大环境不好，咋，你是破坏大环境的人啊？」这就是比较明显的受害者思维，也就是我们常说的「甩锅」。 受害者思维不仅仅只有这一种表现，在《拆掉思维里的墙》里面，作者总结了 5 种受害者思维的表现。推卸责任，保住面子： 上面王木生就是明显的例子，还有像一些网上的评论说的「便秘都怪地球没引力」都是类似的表现。在这种情况下，受害者思维就会认为自己没有责任，不需要承担责任，相信地球没引 ...继续阅读 (88)

在我们聊企业级 SaaS 产品稳定性之前我们先定义一下这里的企业级 SaaS 产品是什么，稳定性是什么。1. 企业级 SaaS 产品根据各家研报的定义，企业级 SaaS 是指以企业客户为服务对象，通过 SaaS 交付模式，向企业用户提供管理软件的服务。主要具有网络供应，集中托管、按需供应及服务化四大特征。网络供应是指 SaaS 产品大多部署在云端，每个客户使用产品的方式，通过互联网进行分发；集中托管是指使用「多租户构架（Multi-Tenant）」，依靠对数据库分区/分表（其中的一种实现方式）来实现隔离操作，逻辑上隔离，物理层面是共享的。对私有化部署的客户，会单独处理；按需供应是针对中小企业的需求，中小企业的需求在短时间内有较大幅度的变化，特别是一些快速增长的发展类企业；服务化是指 SaaS 企业按月/年付费的商业模式，其核心的增长逻辑在于持续服务的能力，这也是 SaaS 企业的核心竞争力，第一次交付产品只是整个客户生命周期的起点。以上 4 个特征可以让客户享有开箱即用、较低成本、实时更新以及按需订阅的优点。1.1 SaaS 产品和 C 端产品的区别SaaS 端产品面临复杂的业务场景和用户场景，因此进行细节设计时，必须关注建模、抽象、角色、权限等问题。除了使用者本身的功能需求以外，还需要考虑管理者或者决策者的管理需求。C 端产品面临的场景相对单一，并且使用者是相对独立的单个用户，因 ...继续阅读 (80)

上次我们聊到了技术成本的精细化运营，有点干，今天我们再聊一点不那么干的，聊一下做这个事情背后的逻辑。企业存在的目的是在外部、市场上和经济体中创造成果，企业内部只有成本。在德鲁克的《成果管理》中提到成本时说「大多数企业的年度降低成本热潮总会像春季的伤风感冒一样如期而至，往往 6 个月过后，成本又恢复到原有水平，企业又开始为下一轮降低成本运动做准备」。感觉确实是这么个节奏，当你的成本控制有一定成效后，你会发现成长慢慢又开始涨了，而且还是那种特别有理由的，不得不涨。不管是控制成本还是做其它事情，一些做事的方式变化不会太大，如要有重点，如要一事一议，如要有大局观，我们控制成本有如下原则：先处理大头的成本或者先控制能产生更大效果的成本点，特别是大的原则；不同类别的成本要用不同的策略对待，如生产性成本考虑其投入产出比，监察类成本考虑不做会怎样，带来的成本是多少？最有效的降本方式是把某块直接去掉，减少比不上直接清零，评估确实去掉会更好的可以直接干掉；要有大局观，不能一个地方成本降低了，另一个地方成本增加了，不能这个月成本低了，但是整体成本却高了，有时我们可以容忍这个月成本高一些，接下来的成本低，总体成本低一些。在控制成本的过程中，要能识别出成本要素，找出每个要素的关键成本点，将成本定义为顾客付出的代价，根据成本的基本特性对其分类，输出成本诊断报告。在诊断成本时，主要成本可以分为：生产性成本，是企 ...继续阅读 (79)

在技术团队的日常管理工作中，一个管理者做得最多的事情是决策、开会，最不想看到的是线上事故，线上事故给技术团队带来非常大的冲击，而给线上系统带来风险最大的研发环节是线上环境的变更，甚至有人说：「没有变更就没有问题」，对此我们不置可否，但这些变更之所以会导致事故，从根源上来讲大部分是技术同学犯了错。这里的决策、会议，变更，错误合起来是我们日常工作中的大部分。而对于这些的基本认知是一个技术管理者在带团队过程中逐步提升的，今天我们就来聊聊这 4 个基本认知。1 决策在带团队的过程中我们会做非常多的决策，如去决策是否投入足够大量的人力满足某个业务，或者升级架构，或者构建某个流程机制等等。这些决策中从服务于时间维分为两种：当下的决策，如评估需求优先级，先做什么，后做什么，关注的是当下和已有的；未来的决策，如评估技术架构演进、团队演化和发展等等，关注的是未来。当下的决策在我们的工作中最常用于评估产品需求、评估技术方案或实现方案。对于产品需求，技术管理者的作用是把价值不高，或者没有价值的需求干掉，不让其进入研发，不让公司的人力成本白白浪费掉。一般我们会对于提需求的同学问如下的问题：为什么会有这个需求？一般是想看这个需求是怎么来的，用户故事是怎样的；这个需求的价值是什么？一般是想看这个需求做了之后对产品或业务的好处，看产出；如何度量这些价值？一般是想通过数据看到需求的价值，把价值反馈在指标上，如营收 ...继续阅读 (89)