思考：管理最低成本高效率的方式，就是具备战略领导力。 被忽视的管理成本 • 管理要求，也是有成本的。 • 相当一些管理者完全无视这一点，而规模化的组织会数倍的放大管理成本，造成极高的内耗和浪费。 • 比如：手工记录详细工时，故事点，不必要的增加审批，验证等环节，都是为了管理而浪费效率的典型做法。 • 管理成本 VS 不确定性，这就是管理工作里最大的困境，也是优秀的管理者和平庸管理者的认知差异。 • 优秀的管理者和平庸的管理者，所需要的管理成本是数量级的差异。 Shape Up 中的战略性 • Shape Up 这一本小册子，囊括了几乎整个 Basecamp 公司的治理结构（意外的少，不是吗？）。 • 里面有章节描写了如何平衡宏观战略和微观工作，重点在于「克制」，是管...

“思考： 更好的管理，你需要理解组织内每个工种的愉悦感和挑战” 最糟糕的管理，就是「你听我的」 • 我懂得多，所以你们听我指挥。——这是最差的一类管理者。 • 我管宏观，细节你们搞定。——这也是最差的一类管理者。 • 即使是有人专业素养能完美的实现最优的「任务分配」，这也是一个缺少自驱力，容错能力极差的天花板很低的组织。 • 何况大部分人并不知道自己菜。 • 这才是大部分企业的现状。 管理的本质是服务 • 组织架构来看，管理者在一个金字塔的顶端。 • 但真正有效的管理，是把这个金字塔倒过来，管理者在最下面，支撑和服务上面的其他部分。 • 管理者只有两方面的任务： • 决策并最后对决策结果负责 • 其余时间，服务团队 • 有能力真的服务团队的关键是：你需要理解组织内每...

思考： “• 效率的核心只有一个：合理的权责。（反过来说，一切效率不佳的本质都是权责优化不到位） • 权责的关键只有两个：范围和边界。 • 谈范围的时候，永远往最上面找；谈边界的时候，永远往最左边找。 • 这就是降本增效的本质。” 你一定看过的 • 「降本增效」的时候，上游一个劲拿着鞭子往下抽，一直抽到最 working level。 • 老板没有能力做专业决策，下属需要组织完整的材料，并提供「量化」的依据，老板在数字里面选大的那个。 • 平级部门撕逼。 • 平级同事撕逼。 大概这些才是职场的常态，但这些是，不，对，的。 抛开有效范围说效率就是耍流氓 • 如果说的是公司整体的效率，那效率问题要从 CEO 往下看。 • 如果说的是科技部门的效率，那效率问题要从 CTO...

关于 QA 的定位（边缘场景 only） • QA 在每个 Cycle 的尾声进入，并测试各种边缘场景 • 实施团队对主要功能的质量负责 • Basecamp 的实践是，很多年来都没有 QA 这个角色，直到业务的规模发现，边缘场景的 bug 造成的影响足够大了才开始专门在这方面投入 • QA 是 Level-up（增值），而非 Check-point（兜底） • QA 提交的 tasks 默认是 nice-to-have 属性，实施团队来决定是否要修复 关于 Code Review • Code Review 和 QA 测试一样，不是强制的 • Code Review 会让代码变得更好，但不强制 • Code Review 是 Teaching 和 Learning...

即使是高度自驱，高度自由的项目，仍然需要管理进度。 但没有人喜欢「被管理」。 被理解的项目节奏 • 理解项目初期，会有静默期，团队需要时间消化 Pitch 里的内容，需要设计和思考，因此项目刚开始的几天，没有任何进度会是常态。 • 理解任何的工作的本质，都会经过「探索」，「排坑」，「确定」，「完成」这样的过程。 • 理解任何的「探索」阶段，因为存在不确定性，这时候讨论「进度」都是没有意义的。 • 理解没有称职的经理，愿意追问团队「进度」和「更新」。 • 理解没有任何工程师，喜欢被人追问「进度」和「更新」。 • 你我都清楚的知道，从任何实操来说，Number of Completed Tasks / Number of Total Tasks 作为项目完成百分比，是多...

项目团队的构成 • 一般一个实施团队为 1 个设计师和 1-2 个工程师（1 前端，1 后端） • 这几乎是效率最高的最小工作单元，能极大的降低协作成本 • 团队几乎完全异步和远程工作 • 没有专职的测试人员，测试部分如何权衡留到后文再写 Building 项目流程描述 • 一个 Building 本质上等同于一个软件研发的项目（而非迭代），输入的需求是一份 Pitch（见前文） • 团队进入项目，阅读 Pitch • 一般需要开一个启动会议，回答问题，确保理解一致 • 基于 Cycle 的长度，找到一个有限项目周期内可以落地的方案： • 前文提到的：Fixed Time, Variable Scope • 在团队自行在项目内逐步创建「Scope」：Scope 一般...

Betting 的核心逻辑 “The betting table is a meeting held during cool-down where stake-holders decide what to do in the next cycle. The potential bets to consider are either new pitches shaped during the last six weeks, or possibly one or two older pitches that someone specifically chose to revive.” • Betting 是决策层承担责任，做出商业和产品判断的机制。 • 之所以叫做 Be...

大部分软件研发行业说到“增效”，思考的都是怎么让“开发过程”更快。 就像所有的管理问题，从顶层设计才有效一样，所有的效率问题，从最上游找才会出现真正的答案。 Shaping 也许可以给你其中一个优秀的答案。 Shaping: 如何真正对需求负责 大部分企业，需求分析不过是软件开发流水线中的必要一环。因为大部分的企业，整个流水线上的产品，设计，开发，测试，每一环，都是拿工资干活的工人而已。 “Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth? This i...

Shape Up 的基本工作模式 Shape Up 中描述的关键工作包含三个部分 • Shaping：对应一般软件研发产品需求分析阶段的需求分析过程 • Betting：对应一般软件研发过程中的立项或需求排期决策过程 • Building：对应一般软件研发过程中的开发实施过程 Shape Up 的时间安排 • 整个工作节奏，分为一个六周的 Cycle 和一个两周的 Cool Down • Shaping + Betting 和 Building 是并行的而非串行的 强制和承诺 • 整个公司不同产品线的研发工作，都强制使用同样的工作节奏。 • 原因：允许不同周期的项目并行，会导致资源的调配越来越复杂，最终项目管理工作变成了 Calendar 上的甘特图游戏，疲劳而无效...

一本非典型性的软件研发担当手册 《Shape Up》是一本极其少见的，以「甲方」视角撰写的行业沉淀。不同于市面上绝大部分操蛋的敏捷教练，研发管理顾问，大部分二流的科技行业从业者那样只是告诉你一个你已经懂的自上而下视角的 SDLC 流程，《Shape Up》立体的建立了一个每一个软件研发过程中的参与者都能独立思考的工作形态——不是「制定」出来的，而是多年「自然而然的博弈」出来的。 这本书如此的立体，以至于你可以无论你是软件研发过程里的什么角色，这本书里你都可以找到属于自己的共识和许多问题的答案。 战略，管理，产品，项目，应有尽有。 这是一本非典型的软件研发管理手册。 Shape Up 尝试解决的痛点 • 一线的软件研发团队的工作最佳节奏，避免让人成为永远做不完需求的 ...

写在前面 ““时间是你最有价值的资产，不要浪费它。” —— 杰克·韦尔奇（Jack Welch）” 我们生活在碎片化的时代，无论是短视频，社交网络的文字，信息流，邮件，几乎都是以分钟为单位在消耗你的时间。我们的工作，家庭的琐事，也毫不客气的把你的每一天更用力的击成碎片。我尝试在这些被迫的碎片之间找到一条勉强可以喘气儿的路，尝试不要浪费这些已经支离破碎的资产，拿它们多做一些什么。 逆来和顺受 程序员们讨厌会议，讨厌被会议拆的支离破碎的日历。我们总是抱怨每天主动可支配的时间太少，太碎，突发的会议，孩子的吃喝拉撒，中年人的每一天似乎再也做不了什么事了。 ““我们不能改变风向，但我们可以调整自己的风帆。”” 如果时间不可避免的碎片化，再也放不下一个完整的目标了；不如把你的目...

这一篇，说说 In General，在职场里如何跟其他不一定直接利益相关的同事打交道。 职场里，免不了会有其他部门的同事和你产生交集。请不要吝惜多投入一下，让每一次和你产生交集的人都感觉你是很有帮助的。利人利己的同时，你的影响力就是这些小小的付出积累起来的，影响力的本质，就是其他人对你无条件的信任程度。 职场是很多圈子 给自己做积累的很重要的一方面，就是积累自己在圈子里的名声。 1. 这个圈子可能是团队内：你会收获团队信任。 2. 这个圈子可能是部门内：你会收获部门内影响力。 3. 这个圈子可能是公司内：你会收获跨部门的 360 度评价。 4. 这个圈子可能是某个技术圈或者社区内：你会收获更广阔范围内个人品牌积累。 5. 这个圈子可能是社交媒体：你会收获更多来自陌生...

在职场中，和同级之间的关系最难拿捏。更重要的是，同级往往是我们最直接的竞争对手，却又不得不天天合作。很多职场文章会说，同级之间都是利益，我觉得完全不是这么回事。 「边界」，是同级关系的核心。 很多人在工作中都会遇到这样的困惑：什么情况下应该帮，什么情况下应该拒绝？什么情况下要争，什么情况下要让？ 其实这些问题都可以用一个原则来解决：找到定义了合理边界后的工作框架，这些问题都不是问题。 “边界分两种：该打破的边界，和该坚守的边界。” 该打破的边界：非本职工作类型的协作，如沟通，管理，流程，甚至办公室政治。 这些「非技术性」事务，是大部分技术工作者不擅长的，反而是你最容易积累个人影响力和出售「有效人情」的。如果你有熟悉的关系，有擅长沟通的手段，越是治理结构不清晰的企业，...

我看了太多的职场「腹黑学」，告诉你职场没朋友，职场就是踩着别人折腾云云。 今天，我想和大家分享一个特别重要的话题：如何向上管理你的领导。每个管理者都是独特的个体，用统一的工作方法对待所有领导，在每一个公司每一个岗位都用同样的方式工作，是……很性价比很低的。 理解每个人是前提，前文在这里：《专栏：职场不用喝咖啡 - 入职以后先看人。》 让我们来简单说说几种不同的可能性，以及相应的应对之道。 第一种：能力出众的 这种领导最容易相处，因为他们往往有清晰的目标和专业的判断。此时的黄金法则是：全力支持，精准执行，并保持开放的学习心态。 能力强的领导身上必然有值得你学习的东西，而这些东西，往往就是你所欠缺的。 具体的微观细节，异曲同工，后面职场沟通的话题里专门去聊。 第二种：能...

“每个人都有所求，他们要什么你都不知道，每天难道开盲盒吗？” 职场不是生产线，是人的社会 • 你以为职场是在完成任务，其实你是在和人打交道。 • 你以为你在对接业务，你对接的是业务的打工人。 • 你觉得你只要把事情做好就行，但你做的所有事，影响的所有利益相关的同事。 因为职场从来就不是一个单纯的生产环境，而是一个复杂的人际关系网络。 你的每一个决策，每一份文档，每一次会议发言，都会引起涟漪，影响到与你相关的每一个人。如果你希望你的任何工作都能少内耗，多成事，那么你一定需要知道，做这件事的「最佳姿势」。 要为了公司好，首先要为了公司里的人好。 职场人类解析模型 嗯，我自创的。 你需要更客观的，不带评分色彩的去了解你共事的同事们，注意，这里的任何一个方面，都没有「高低之...

“本文是我的血泪教训的结晶。” JD 只是冰山上的一角 很多时候，我们选择工作就像相亲：都是看对方的"纸面条件"。 JD 写明的工作职责、薪资待遇、五险一金这些明面信息，就像相亲时大家最关心的"年龄、身高、学历、收入"。但正如婚姻幸福与否并不完全取决于这些硬性条件，工作的好坏，未来的前景，你未来甚至当下能获得的，也远非 JD 所能概括。 入职前，你必须「看见」那些 JD 之外的事儿。 行业和企业：最宏观的职场因子 前文：专栏：职场不用喝咖啡 - 最难跨越的职业障碍，行业 不再多说，因为这两者对职业生涯的影响是深远的。如何判断行业则是一个特别大的话题，未来希望有机会专题的聊，因为这方面我也经验有限。 组织架构：你在「棋盘」上的位置 前文：专栏：职场不用喝咖啡 - 组织...

那么，所有的「价」究竟有什么？ 所谓性价比，自然是「所得」和「付出」之间的关系。 我的理解： • 经济回报 • 个人专业能力积累的回报 • 行业背景积累的回报 • 岗位资历的回报 列出来这些，哪怕他们有优先级吗？ 我的答案是：没有。 他们几乎是完全不同的东西，并不适合直接互相比较甚至分出高下。 如何量化这些不同的价值 我的答案是：尝试都用用一个标准的分数来计算，把他们量化到同一个维度。比如用钱，把所有不同的积累，都转化为钱，然后就可以大概的「分出高下」了。 因为每个人对职场的定位不同，所以我会建议以下的一些可能的思考方式： • 「行业」：把行业里更高的职位的薪水纳入考虑，作为未来的现金流的一部分。特别是比较不同行业的时候，要考虑该行业的高级岗位的情况。 • 「岗位」...

职场坐标系的全貌 这是一个三维的坐标系：行业 vs 企业 vs 岗位。 你在企业里的位置，通过组织架构来定位；你在专业能力里的位置，通过技能图谱和岗位匹配度来定位。 于是有了最后一个指标轴，「行业」。 工程师为例子的行业背景 “其他职业如财务，人力资源，销售等等本质上也是如此，在此用「工程师」作为例子类比。” 如果你的工程师经历逐渐超过5年以上，那么你一定在至少一个行业有了比较深的接触。比如医疗，物流，金融市场，零售银行，支付等。 即使是产品软件而非企业软件，你的产品也是为了解决客户或用户的实际问题，对应的也存在一个依托的行业。比如建筑，制图，信息安全，项目管理等等。 IT 技术在企业里的价值，总是服务于企业商业模式中的价值流里的，脱离了商业模式的技术难以独善其身。...

“大概十年前，我有一个比较仰慕的职场前辈，在一个用英文的场合他用英文说了一句我当时觉得很棒很自然的表达，我自己英文也不差，但确实自认达不到这么自然的程度，很是仰慕。 于是那几天，我在思考我的英语技能，还有哪些地方还能补足，并也认清了我自己要更进一步还是有技能差距的（不要盲目的觉得很多高级岗位你上你也行）。 于是，我做了一件事，把他的岗位，他的技能里我能看到的部分，做了一个解构，跟我自己的技能做了一个比较。（见上文）” 如何解构自己 我的建议是： • 准备一个这样的表格 • 按照一个公允的标准来标记自己的技能，一个例子是： • Beginner：看过理论书籍，没有实践过。 • Intermediate：看过理论，并有过简单的实践，有案例。 • Advanced：熟知理...

“企业的地图有了，现在来看看自己。” 越高的岗位，越没有 JD 因为越难的工作，越不清楚应该怎么做。 职业生涯到某一个阶段，你会开始接到不是具体的工作任务，而只有一个工作方向或者目标需要你想办法达到。这会是你第一次真正的从「完成任务」往「做成事情」转变，你需要的知识，开始超越出你的 JD 的范围了。 绝大部分职场高级岗位，都是复合技能型的要求。 但所有的 JD，都可以被定义 我把所有的职场技能，拆解为了如下 10 个大类。任何一个市面上的岗位或岗位要求，本质上都是下面这些大类里的一个或多个的不同组合。 核心业务职能： 1. 研发（Research & Development） • 产品研发 • 技术研发 • 创新管理 2. 生产/运营（Production/Oper...

“看懂组织架构，看懂一个企业。” 科技部门的组织架构通常有两种模式（或者方向）：产品导向和职能导向。这不仅仅是一个架构图的差异，而是企业灵魂的写照，很多时候也是行业差异的具象。 产品导向的组织架构：贴近业务，快速响应 产品导向的组织架构，一般指的是科技职能实现回报往上，会出现业务职能或者事业部负责人。科技部门的职责在整个企业里以矩阵式混合管理。 产品导向的组织架构的目标和效果很好理解：想象一下，当科技团队直接对业务负责时会发生什么？ • 决策链更短，响应更快 • KPI直接与业务成果挂钩 • 技术方案会更倾向于务实而非完美 因此，产品导向的科技组织架构的企业，往往重业务发展和创新，重效率多一些。 例子： CEO | |--CTO(技术战略/标准/中台) | |--产...

“直奔主题吧，先跳到实操。无论是一个基础工程师，还是部门负责人，专业总监，职场里都有很多隐藏信息是非常重要的，就像下棋的时候不能只看眼前一步（不要只看你自己的工作内容和职责），脑子里永远要有整个棋盘。” 组织架构：权责的地图 很多人把组织架构图仅仅当作一张员工关系表，这是最大的误解。组织架构是一张「权责地图」，它不仅展示了谁管理谁，更反映了公司的战略重心，分工，权利和责任的分配框架。 要点： • 汇报线（实线？虚线？） • 职责边界 • 如果看起来有冗余或者重复，为什么有？区别是什么？ 业务架构：战略的地图 如果你在一个企业工作，甚至讲不清楚公司的业务是啥，靠什么赚钱，那么这一定是你的损失。去问，去查，然后自己思考。 几个关键点： • 公司靠什么赚钱 • 公司要支撑...

“如果上班这个事儿是有「性价比」的，那么我们先来谈谈「价」在哪吧。「性」这回事，放到后面一点，属于职场内的技巧。” 见过最多的问题：要不要为了高薪去接受更大的压力？要不要为了学习而接受较低的薪资？面对机会时，应该优先考虑什么？ 这些问题的答案，其实都藏在一个更根本的问题里：工作究竟能给我们带来什么？ 人生很长，我们需要复利效应 就像复利计算中最关键的是本金和时间，职业发展中最宝贵的也是你的核心竞争力。技能、经验、眼界、思维方式，这些都是会产生复利效应的"本金"。当你在工作中不断积累这些能力，它们就会像滚雪球一样，越滚越大，混出来的是你的人生路径以及抗风险能力，不光只是金钱。 越年轻的时候，未来（时间）越长，那么能力（本金）的积累，就越发的重要。这句话的反面就是：如果...

为什么有这个专栏 我在推特上写了快三年的管理，职场心得，收获了很多反馈，很感谢愿意阅读这些奇怪长推的朋友。但推特有个问题，长帖子很难成体系的管理，Article 功能又是高级付费会员才有的功能，而且试用下来体感并不好，于是我萌生了找一个专门的地方更系统的记录的想法。 另外，我在 https://xiaowenz.com/service/ 上公开了一个「咨询服务」，几个月来也有将近几十个朋友找我聊过不同的话题。我最大的感受是，即使是做了前置功课的沟通，30 分钟仍然不足以把很多问题聊透，而我自己确实也没有精力给每一个朋友提供 1 小时的时间窗口来“聊满”。 因此，我尝试用 Newsletter 写作和邮件互动的方式，把上面两件事「混为一谈」。 订阅可以获得什么 1. ...

非常老套的，我用这样的一个方式开了个头。 Very clichéd, I started in such a way. --- Hello World.