--- title: Fix Bid项目人天估算经验之谈——与一些真实数字 category: data-driven-sdlc estimation software-estimation fix-bid statistics --- 实践经验证明，合同报价部分的开发工作量估算，目前唯一靠谱的方法论就是：**尽力估算，然后结果✖3**。 > Tw内部喜欢用“膨胀系数”这个东西，我觉得偏差太大了。“膨胀系数”这词隐含的假设就是，落地层面的工作量可能会有一些膨胀，但点数以及估点所依赖的假设本身基本是准的——which明显不是真的。要实事求是。膨胀系数本身就是不实事求是：它隐含了估点的基本准确性、以及膨胀系数在1.1-1.5这个微调区间——毕竟你不会期待一个膨胀系数本身是3x甚至4x，那还能叫系数？ > > 那么什么叫实事求是呢？从经验来看，✖3倍是更加符合实际的算法。这是因为，相比于一般的、敏捷迭代中的1-5个点范围的故事卡估点，合同级别的开发工作量估算有两个根本性的不同，那就是：需求一定会变、估算者不完全了解技术架构。这两个假设是估点膨胀且无法预测的来源所在，除了直接乘3倍+似乎没有更好的办法。这并不是坑甲方，而是非常实事求是的态度。实际经验告诉人，不这么做就会亏钱。 > > 对于一个固定价格的合同，往往都在三个月以上，而考虑到大多数团队在已经进入实施阶段、开始做敏捷迭代交付的时候，都很难做到提前两个迭代准备好需求和技术方案的事实，对于一个更长期限的合同要有稳定不变的“需求”作为估点的假设或输入，可以说根本不可能，对甲方也是几乎不可能满足的要求。更大的可能是，实际交付的时候（无论是谁）发现当时想简单了，或者遗漏了需求，不加需求整个功能就不能上线。 > > 更别说一些别的业界常态了，比如入场时搭建环境客户配合积极性不高、估点的熟悉上下文但是实施同事不熟悉、本来是做个性能优化的合同也知道性能基线需要入场后现测但是涉及性能测试的标准和场景时引入了测试人员技术领导项目经理等许多人讨论了许久也没有达成共识、签合同的领导换人了后来者不认了等等等等了。 > > 因此，事后来看，我认为下文唯一有价值的洞见就是“尽力估工作量、然后乘以3倍+报价”了。 > > ——2025-04更新。 > > 以下是原文。 本文旨在为需要更加精确的人天估点的技术工作者（Tech Leads，CLT们）提供一个经验参考及指引。文章以一个已结束的前端项目数据回测作为开始，聊聊软件估算的那些事儿：难点、方法、框架与一些真实的数字。 > **太长不读：本篇以笔者已经结束的一些项目及其统计数据，来谈谈如何做固定金额（Fix Bid）项目的成本估算。在估点侧，我们需要的工具是一个估点基线、一个打开细节的框架；在报价侧，我们可能需要把常用的系数从1.2/1.5根据情况上调到2.5/3。这就是笔者依据一个两百万左右的项目回测和一些数据分析出来的经验结论。** 估算是我们每天的工作中一个司空见惯的话题，尤其是在软件开发行业：在敏捷开发中，我们会[每周定期做业务故事梳理和估点][Backlog Refinement Meeting]，以更好地安排未来两周的工作量；在/**thought**works作为乙方公司，打固定金额（Fix Bid）订单时估算的准确性决定了成本的准确性，进而影响收入的可预测性。就算是在每天的个人工作中，我们常常也需要[估算手头上多个工作的工作量](https://ethan.exthoughtworkers.tech/#/post/2023-08-05-my-tech-lead-journey-iv)，根据它们带来的价值判断每日每周的工作优先级。可以说，估算做的越准，对个人和生意的帮助就越大。 同时，估算又很难。对于低层级的工作，人们常常容易高估自己、低估未知的工作量；对于高层级的工作，人们又常常因为打开的细节不够，导致估算结果与真实执行成本相去甚远。在固定金额项目或某些生意模式中，成本估算是我们需要面对的一个问题。本篇我们就来聊聊估算相关的那些事。 ## 估算的目的与难点 估算有许多不同的种类，但是从要求和目的上讲，大体可以分为两类：不需要那么精确的估算，和需要尽可能精确的估算。 有一些估算不需要那么精确，这是由它们的目的决定的，这类估算往往只需要一个大概的**量度或范围**来做一些快速的决策，比如优先级排序、预算估算等。比如在[SAFe](https://scaledagileframework.com/)框架下的产品增量计划会（PI Planning）¹上，产品经理会希望团队对某几个大功能进行估算，以便综合功能的价值进行未来三个月的业务功能优先级排序；又比如在售前过程中，甲方有时需要知道某个服务项目的报价范围，以确定有没有远远超出他们的预算。在这些情况下，估点的目的是提供一个**量度或范围**——比如A功能比B功能大很多、某个项目20万而不是200万——而不是一个过分准确的数字，以便受众可以根据这个范围快速地做出一些早期决策。 有一些估算需要尽可能地精确。这类估算往往涉及成本计算💰💰，或者会产生相应的责任或承诺。比如打固定金额的SoW时需要根本成本算出报价，又或者每周的[敏捷会议上][Backlog Refinement Meeting]为下个迭代的故事进行估点——这是一个软性的承诺，等等。 在需要相对精确估算的场合，往往存在一些难点。众所周知，估算由于其预测性的本质，与实际情况一定存在或多或少的偏差，估算越大越估不准。原因就在于估算越大，它依赖的假设就越多，影响变量也更多。更有甚者，我们开始估算的时候，拿到的就是一两页纸的需求，详细程度听天由命。细致的业务场景梳理是没有的，UI图也是不一定有的，最多就是知道现有代码用的是什么技术栈写的，代码库都看不到。凡此种种，都是我们实际估算过程可能遇到的难点。那么，怎么去处理这些问题？~~太抽象的处理不了~~ 在介绍通用的估算原理之前，我们需要退后一步，来看看我们在估算过程会遇到的一个更常见的基础问题：**用什么单位来估算**。 ## 估算的单位 在涉及估算的场合，估算单位的选择也代表了估算方法本身所做出的假设。来了/tw，目前接触过最常见的两种估算单位，一个是点数，一个是人天。也有一些小伙伴，在估算的时候会纠结，我是应该用点数，还是用人天？简短的回答是，it depends（逃。应该说，视估算的场景和目的不同，选用的单位不同。 很多时候作为管理角色，最希望得到的当然是人天估算，这样时间和人数就都可以作为资源进行项目管理。但人们很容易忽略的是，人天这个单位本身就隐含了精确性、确定性，而软件工作的本质就蕴含了一些不确定性²——这不仅是整个敏捷和XP方法论的假设³，同时也得到了很多实践和数据的检验⁴。这不是说人天估算不好，或者我们不应该使用人天估算，而是我首先希望大家意识到人天估算中被隐藏的不确定性，是需要你有意识地去处理的。 使用点数进行估算呢，正是基于软件工作不可完全预测、但具有可对比性这一信息：比如改字工作就比CRUD“工作量更小”，诸如此类。使用点数时，有很多具有对比性的度量单位被提出，比如斐波那契数列（1/2/3/5/8/...）、T-shirt估算（XS/S/M/L/XL/..）等。使用点数估点时，最重要的是确定可用来作为对比的基线，比如1个点、2个点或XS的用户故事分别意味着什么，有什么例子，写出来公示给团队，等等。 进入到交付后，在估算用户故事、计算迭代速率的场景下，我推荐用点数来估点。确定好基线后，团队按点数估算即可。在迭代计划会（IPM）上预测未来迭代工作量时，可以根据过往迭代完成的点数多少来预测（比如过去3个迭代平均在28个点上下波动，那么就采用28个点，但此处28个点≠5个人*10个工作日）。由于在点数估点中参考的是过往的事实数据，它天然地就考虑（或者说，量化）了软件开发中不可预测的因素。 但在一些场景下，我们需要较为准确的人天估算，比如还是做Fix Bid合同的报价。前面我说过，人天估算往往需要妥善处理“不确定性”这个问题——这也正是本文尝试探究的。值得一提的是，目前最常见的处理方法，应该就是先把所有的任务列出来估一个数字（很多时候我们也没有足够的意识去思考这个数字的单位是人天、编码时间、点数还是别的什么），最后再乘以一个系数——比如1.2、1.5——以表示确实我们考虑了“不确定性”这个事情。看起来没什么问题，但经验告诉我，**这样的估点结果往往还会偏小**，原因不明确，但可能是在于估数字的时候容易陷入确定性的陷阱，以及背后隐藏的某些细节超过了哪怕是1.5的这样一个系数。 那么，较为准确的人天估算应该怎样获得？下文笔者就利用真实项目的回测数据和规律总结，重点回答一下这个问题。 ## 估算的基本原理 估算一个两百万项目的真实人天成本可能不容易，但是估算一个5个点范围内的用户故事卡，相信所有的开发者都有经验，因为这是我们每天日常的工作内容。 而1-5个点范围内的软件估算，在/tw其实早已有了一套成熟的方法论，那就是黑马第三部分和第四部分所回答的问题：你首先需要知道的是软件架构，从软件架构可以得到测试策略，然后你就可以对任意一个用户故事应用二层分解得到业务用例，而每个业务用例都映射到一个或多个软件架构中的层，进而得到一份任务列表（tasking）。任务列表上的每一项都有明确的输入输出，根据团队或个人日常实践可以得到精确到小时的工时，加总就得到这个用户故事的估点。这个拆解和计算过程就如下图所示。

估算一个更大项目的人天数，显然需要很好地利用这份精确估点作为基线，基于它再做一些更复杂的运算。 ### 估点基线

以上图这个常见的React前端架构为底本⁵，并以笔者一个过往项目的具体数据进行测算⁶，可以得到这样一份具体任务的估点基线：

有了这份估点基线，那么我就可以对任意一个1-5个点的任务按照已知的需求和UI信息，进行理想环境下的时间估算了——至于编码占整体项目时间的%多少，这是一个工程问题，没有行业统一的标准答案，但是后文同样会基于经验数据进行讨论。这里大家可能会注意到，这样一份估点基线，是依赖于**技术栈**、**软件架构（及其所决定的测试策略）**以及**团队特定的工作环境**这三个主要因素的。你可能会疑虑，它能否推广到其他的技术栈上？回答是，当然没问题。软件架构和测试策略的最佳实践往往是随着技术栈而确定的，你可以以此为假设固化到你的估点基线中；至于具体任务的时间，你既可以依赖经验，也可以采用过往项目的统计数据。如此一来，你只需要将分类换掉（比如在后端技术栈下，可能就是“API-业务逻辑-DB”的分层），就可以得出一份基于不同的技术栈（比如Vue.js、Spring Boot等）的估点基线。 ### 打开细节 有了前述的估点基线，就可以在这个基础上开展更高层次的估算了。对于不要求精确的高层级估算，往往有了估点基线就可以帮助你对T-Shirt大小心中有数了。对于精确性有更高要求的估算，这里有第一个建议，那就是仍然要按照这个估点基线的分类把对应的需求任务**细节打开**。 **打开细节** **是一个必做的重要动作**，做不做这个事对估点相对准确度有很大的影响。这不仅有技术因素，也有心理因素。因为当你不打开细节的时候，你面对的通常是一个很小的数字或很小的单位，比如说“一个功能”、“两个页面”，于是潜意识里你就会觉得，一个页面能有多难，一天搞完、两天最多，估三天以上那都是对我领这份工资的不尊重。面对一个很小的数字，人们似乎也很难去证明大估点的必要性 ~~比如你是否记得这样的对话：“什么？一个页面要做15天？一个卡要做8天？”~~ 于是，大伞下面潜藏的许多复杂度就被忽略（数据的、非功能性需求的、集成的、因为一个字段引起的惨案，等等），估点也因此不知不觉中缩水。应对的第一步也很简单，那就是把细节打开，按照一定的思维框架去打开。 比如说，我举个真实的例子。现在有一个需求，是要做一个类似ChatGPT那样可以跟AI聊天的功能，集成到我们正常开发的内部企业会议系统中。跟AI通过API交互，API及其背后的模型由其他团队提供，这里就假设已经准备好了，主要是做个UI。大概长下面这样。现在请你估个点吧。（建议读者可以盖上后面的文章，瞅两眼UI，尝试思考两分钟你会怎么来估这个点~~）

有没有同学是看着UI觉得：“嗯，不用管理会话，不需要支持选择对话模型，不支持上传附件，看起来就是内部AI套壳，1-2个API调用+一个输入框+一个回答框，问什么答什么都是API不需要我处理，很简单，要不了三天，加点保险怎么着最多五天搞定了”的？有这么想的同学请举个手🙋🏻‍♀️🙋🏻‍ 如果有的话，那么恭喜你，你就是我们想寻找的完美乙方😂。 事实上，在实际动工之后，我们发现在“两个UI+两个API”背后还有许多膨胀的复杂度，举一些例子，读者看看你有没有思考过： * **UI**：细节超多，还有许多定制的样式。比如placeholder里的字要有深灰浅灰（项目特定需求，默认组件不支持）、用户输入过长需要换行但隔壁确认按钮不能换行（同样的处理代码在手机上还会偶现bug需要修复）、回答时要自动向上滚动并在用户滚动时停止、支持一些基本的快捷键以与主流AI体验匹配（比如Shift+Enter换行、Enter发送等），等等，并且这些需求联动起来要求同时支持对UI实现提出了一些挑战。 * **API**：API不是通常的RESTful格式，而是主流Gen AI常用的SSE格式，基础设施得新弄。不仅如此，后端API提供的还是POST版本的SSE，在Chrome浏览器无法直接在标签页查看response，还需要手动写调试代码；mock server和mock response解析都得重新写；markdown需要引入parser，需要做一下选型；返回的markdown格式需要根据事件类型做分段转换，等等。 * **业务逻辑**： * 在AI回答中，还会返回回答所引用的会议记录，要求点击可以跳转，但这个会议记录不一定是当前会议的纪要，也可能是上一个或上上个会议（定期会议）的纪要，这个会议记录的id在当前页面拿不到，需要开发； * AI还可以总结会议产出并分点，要求每一点都有按钮可以一键生成一个Todolist，技术上需要在转换markdown的过程中魔改其结构插入React组件。 * **还是API**：API根本没准备好，连API契约都没有……于是又需要团队去确定契约、发邮件沟通，如此反复直到可以确定下满足业务的契约。 是不是汗流浃背了？笔者真实项目上，这部分的实现确实多花了不少时间。而这些问题，我觉得其实是可以通过打开细节去尽可能规避的。多从业务和数据角度出发问问题，比如：AI回答中有没有特殊的结构（比如引用等）？UI不是通用的，那么API如何兼容？中断、重试、出错等场景是否需要支持？是否需要支持保存对话记录？等等。哪怕不完备，也比完全不展开要好很多。毕竟很多时候，**实现本身不太花时间，搞清楚需要实现什么花时间**。 ### 细节打开的框架 打开细节有一些办法，或说思考框架。有些有效地帮助你打开到细节，有的则不那么有效。我个人实践觉得比较有效的是按照技术架构的组件或分层打开——其实也已经内置到上面的估点基线中，就是按“UI-业务逻辑-API”三层来打开（感谢[@来金同学](https://github.com/aikin)贡献的思考框架）。我发现这种方式能够有效地提示我细节中的复杂度。正常CRUD的任务，直接按数量对应到估点基线中就可以，比如一个需要新写UI组件的表单，那就按UI \* x + 业务逻辑（校验） \* y + API \* 3类似这样的拆分，放到估点基线里面查找工作量，然后再看看有没有额外的工作需要处理（比如有没有富文本字段、有没有三方集成、有没有临时跳走再跳回来自动填充等等特殊流程），各项任务相加即得出估点。 同时，我也见过一些其他的细节打开框架，比如有按照“页面-三方依赖-工作量”为维度的打开框架，也有按[“交互-复杂度-质量-运维”](https://w3.cs.jmu.edu/bernstdh/web/common/webapps/oop/fpcalculator/FunctionPointCalculator.html)为维度的打开框架，它们的目的都是为了帮助估算。不过怎么说呢，有些思维框架感觉不太像从技术人员的角度出发弄出来的，本质上还是偏管理的思路，在帮助打开细节和复杂度这方面有时帮助不是那么大，比如上面的例子中：以页面为单位的打开就太粗，一个页面可长可短，可简单可复杂，你没办法判断它的复杂度，最终还是得按技术框架打开；按工作量打开（比如感觉要做1-2个迭代的就是S、做3-4个迭代的就是M诸如此类），也有点假设当前提的意味：本来估点就是为了评估工作量，这里直接拿假想的工作量作为估算输入；等等。这也是一个需要不断摸索的话题。 打开了细节之后，一般的任务在估点基线中直接查就可以了——在我给的估点基线和打开框架里，通常就是列出有多少要新开发的UI组件、多个业务/胶水逻辑、多少API要集成，然后到估点基线中查阅、加总。此外，在打开细节过后，你还需要注意一些非常规、非可重复或有一定技术难度的任务，对它再进行单独的、独立的估点。这类型的任务包括但不限于： * **全新的API集成工作**。如果跟某个系统是第一次集成，那么视API完善程度与各种情况有大小不等的工作量。正常一般8个点起步，背后涉及的工作如契约确定、跨团队沟通、约会、团队契约协商、契约测试、多环境、集成调试，等等等等。 * **非功能性需求（NFR）**。比如是否需要支持多浏览器、响应式、可访问性（A11Y）、局部性能热点优化，等等。 * **有较高UI或逻辑复杂度/繁杂度的工作**。比如糊一个富文本编辑器、SVG/canvas画图、极其复杂的逻辑，等等。 最后的最后，根据经验，项目总体上还会有一些其他的任务，比如第一个迭代的技术架子搭建、文档与交接、加新需求及修bug、验收测试（SIT/UAT）等。这部分每个项目情况不同，我可以给出这个两百万量级项目的数据，仅作为参考：假设最后估得的编码时间是 $$x$$ 天/点，那么技术架子搭建10天、写文档与交接5天、处理新需求与bug $$4$$%、验收测试 $$7$$%。 最终，我们就得到了所有编码任务的总人天数。 总而言之，这一部分我的观点在于，你或你的团队都可以拥有自己的一套思考框架和打开方法。只要它能够真正地帮你更有效地打开细节、看到背后可能的一些复杂度，那它就是有效的方法。 ### 如何处理假设（Assumptions） 在实际情况和估点实践中，有些未知是难免的情况。此时自然的应对就是，根据已有的信息做出合理的假设（assumptions），然后基于假设继续进行估点。 当然，重要的是尽量找机会以及各种渠道，把做出的假设进行确认或澄清，以得到更加准确的信息，再修正估点。如果确实没办法得到清楚的回答，或者很多细节确实就是相当模糊（比如就像前面说的，业务、数据、UI和已有架构都没有一个详细的），那就是承认不确定性，可以考虑在基本的估点上直接2x或3x。除此之外，似乎也没啥更好的办法。 ### 公式框架 经过上面一通操作，你应该已经得到编程任务部分的估点了，而且有希望是一个不算偏差太大的估点版本。接下来，我们就要处理一下整个软件项目剩余部分的估算和报价部分——很显然，因为软件项目不仅只有编码工作，甚至可以说，真正与代码打交道的工作占其中的不到50%——很快你就会看到，这又是一个真实的数据。 让我们把一个开发者日常编码以外的时间拼凑出来，可以得到这样一个时间比例图⁷。

总体来说，这幅图上的几个关键数据是： * 编码时间其实大约就占总体开发者时间（Dev Manday）的31.5%； * 与故事卡交付直接相关——也是我们有时候的估算单位——的时间占总体开发者时间就47%，不到一半，还有许多项目级别、公司级别的时间开支。 简单来说，结论就是，**取决于你上面估算的是编码时间或是任务相关总时间，这个时间再乘以2-3的系数，大约就是开发者总人天数的估算值**。换句话说，**1.2-1.5的系数一般来说，对于真实成本是偏小的**。 然后再算上非开发者需要的人天，很自然地我们就可以得出合同的总报价了。这部分由于不是我的专业，在做估算的时候应该由相应的代表或角色来做，此处就不赘述了。 最后合同总报价（SoW ($)）的计算很简单，就是人天单价（Rate）乘上我们估算出来的总人天数（Total Mandays）。其中， $$SoW (\$) = Rate \times Total\space Mandays$$ $$\; \; \; \; \; \; \; \; \; \; \; \; \; = Rate \times (Dev\; Mandays + Non\text{-}Dev\; Mandays)$$ $$\; \; \; \; \; \; \; \; \; \; \; \; \; = Rate \times (Dev\; Estimation \div 0.315 + Non\text{-}Dev\; Mandays)$$ $$\; \; \; \; \; \; \; , or = Rate \times (Dev\space Estimation \div 0.47 + Non\text{-}Dev\space Mandays)$$ 这样我们就得到了一个人天合同的（可能较为接近真实情况的）报价。这个大概的流程就是这样：

当然，要得到一个完整准确的模型是不可能的。除了受估点基线中与技术栈和团队、已知信息准确度的影响，也与各个项目、甚至各家供应商内部成本的现实与计算有关系。这当然也并不是本文的意图。文章除了分享一些观点，更重要的是分享一些数字。当然，我也希望本文能够从经验和定性（而非定量）的角度指出，**我们在估点中常用的系数，1.2/1.5是偏小的，2-3才是比较接近真实情况的数字**。 > 这里还有个有趣的side-topic，那就是AI对我们日常的工作效率究竟能提升多少？假定可以提升20%-50%的编码速度，那么分散到31.5%的项目时间中，对总体的贡献其实也就是~6%-16%。50%提升我觉得是比较激进的数据，20%更像我的工作日常，30%可能可以冲一冲。所以也许可以说，AI这个投资在软件编码阶段的提升，大约是6%-10%的区间？ ## 总结 那么，快速总结一下。本文主要涉及的观点有这些： * 估算有不同的目的和单位。对于不那么要求准确度的估算来说，使用点数而非人天是相对准确且高效的。 * 大估算由许多小估算组成。小估算就是1-5个人天内的估算。这部分估算遵循黑马三四章的打开思路，以技术架构、测试策略和二层分解为基础。 * 从小估算可以总结出更为普适的、基于技术栈的估点基线。这是做大估算的基础。 * 做估算的过程中，很重要的一点就是**打开细节**。这是一个很有效的心理暗示，人们在缺乏细节和很小的数字时，容易有忽略复杂度的倾向。 * 打开细节有许多思维框架，判断框架有效性的标志就是它能够帮你看到复杂度。笔者常用的方式是根据软件三层架构来打开。 * 打开细节后并完成具体编码任务估点后，再加上一些通用的任务，比如I0框架搭建、文档与交接、修bug、测试阶段等。 * 编码时间和做卡时间分别占实际工作时间的31.5%和47%。因此，真正那个2/3的系数是加在这里。 * 这也提示我们通常采用的1.2/1.5的估点系数偏小了，可能是估点膨胀的来源之一。 * 有了经验数据，套公式就可以算得一个更加接近真实成本的软件估算。 全文结束，鸣谢。 [Backlog Refinement Meeting]: https://www.agilealliance.org/glossary/backlog-refinement/ ##   ¹：产品增量（Product Increment，PI）计划会一般比Scrum/敏捷中的迭代更长。一个PI计划会往往包含4-6个敏捷迭代，通常是2-3个月的时间。这个协作模式往往是为了提前协调多个相互紧密合作的中小团队的工作、依赖和优先级，常见于拥有较大体量的IT团队的大公司。 ²：比如需求变动、方案变动、沟通、流程、梯队培养、人员离职与更替、单位绩效考评等等。 ³：事实上，敏捷与极限编程实践中有许多实践正是基于这样的假设来减少浪费并变得“敏捷”，比如避免过度设计、迭代开发、小步前进等。 ⁴：后文引用的数据也会体现这一点。 ⁵：这里略去了与本架构对应的测试策略最佳实践，因为与本文的核心内容相关性不强。感兴趣的读者可以前往笔者文章[React单元测试最佳实践与前端TDD](https://ethan.exthoughtworkers.tech/#/post/2023-12-10-react-unit-testing-best-practices-v2)及[相关系列](https://ethan.exthoughtworkers.tech/#/post/2023-12-25-react-testing-strategy-and-best-practices)查看。 ⁶：数据集基于个人日常编码时间采集与Git提交时间统计，精确到小时/半天。 ⁷：这里，我用的都是我在项目上的真实数据——来源涉及三个项目，但交叉对比过基本可靠：做卡时间中的编码、非编码与Tech Huddle时间的分布，采用的是我在最近一个时长约四个月的项目中作为Senior Developer时的工作内容；参加敏捷三大会议10%（不包括故事卡相关的Kick-off/Desk-check等）这个数据是我在[另外一个10个人团队的项目做TL时采集的数据](https://ethan.exthoughtworkers.tech/#/post/2023-08-01-my-tech-lead-journey-i)，这与八叉在黑马计划与敏捷101课程中提到的健康团队敏捷时间应该在10%左右的数据是相互印证的；公司层面事务11%也是我在去年作为TL在同一项目上的数据，不同时间段可能有出入；其他项目事务14%是采用我在2019年当Senior Developer时总有效工时82%作为参考，减去(31.5+9+6.5+10+11=68)所得到的推测数据；最后的18%“其他”是扣除82%以外的部分。