之前在做项目复盘时团队内部对“效率”和“增长”两个问题经常聊不到一起。管研发的同事拿任务耗时数据说某个环节太慢了要用 EET 方法重新估算排期做运营的同事则拉出近一年的月度指标认为整体趋势在变好应该用 AGR 来看增长。问题在于两边用的分析方法完全不同数据维度也不一致最后往往陷入“你说你的、我说我的”的尴尬局面。后来我把这两种方法单独拆开整理了一遍发现它们其实并不冲突反而可以组合使用——一个负责看单次任务的微观效率一个负责看周期变化的宏观趋势两者结合起来才能更完整地回答“我们的研发效率到底怎么样”这个问题。这篇文章就把我对 EET 方法和 AGR 方法的理解做一个系统整理包括它们的计算逻辑、适用场景、Python 计算示例、使用边界和常见误区。如果你正在做项目管理、研发效能分析、数据运营或者需要在团队中建立一套可复用的效率评估与增长分析方法这篇文章可以作为入门参考。1. EET 方法与 AGR 方法分别解决什么问题先说结论EET 方法更偏向“点”上的评估AGR 方法更偏向“线”上的判断。在软件开发、项目管理和数据运营中我们经常会遇到两类问题。第一类问题是“某个任务需要花多久”比如这个需求什么时候能做完这次线上故障为什么定位花了三小时下一轮迭代的测试排期是否合理这类问题围绕的是单个任务、单个环节的执行时间评估对象是“一件具体的事”。第二类问题是“某个指标整体变得怎么样”比如月活用户数环比是变快还是变慢今年的整体增长相比去年是提升了还是下降了按照当前趋势年底的数据量大概会到什么水平这类问题围绕的是多个周期、多个数据点之间体现出来的趋势评估对象是“一段时间的走向”。EET 方法Expected Execution Time / Effective Execution Time预期执行时间 / 有效执行时间主要服务于第一类问题。它通过对任务执行时间的估算帮助团队更客观地判断工作量和排期。AGR 方法Average Growth Rate平均增长率主要服务于第二类问题。它通过计算多个周期数据的变化率帮助团队判断指标的增长速度和发展趋势。从管理层面上看这两种方法不是替代关系而是互补关系。EET 帮助我们回答“哪件事做得慢、慢在哪、预计需要多久”AGR 帮助我们回答“整体趋势好不好、增速是快是慢、未来大概怎么走”。如果只用 EET团队可能沉浸在一个个任务细节里看不到整体效率下降的信号如果只用 AGR团队可能知道趋势放缓却定位不到具体是哪个环节拖慢了交付速度。实际应用中更合理的做法是把两者结合起来既看单点也看趋势。下面先分别展开这两种方法再给出完整的对比和组合实战。2. EET 方法详解2.1 EET 的基本概念EET 在行业内并没有一个完全统一的定义。在项目管理语境下它通常被解释为 Expected Execution Time即“预期执行时间”用来估算一项任务从开始到完成需要投入多少有效工作时间。在研发效能分析语境下它也可以被解释为 Effective Execution Time即“有效执行时间”强调一个任务周期内真正投入到产出上的时间。两种解释并不冲突核心都是“量化任务在理想状态下的耗时”用来帮助团队做排期、定资源、找瓶颈。之所以强调“有效”是因为在很多真实开发场景中任务的日历时间并不等于有效产出时间。举个例子一个 Bug 修复任务从创建到关闭花了 3 天但真正动手调试代码的时间可能只有 4 小时其余的 20 小时都消耗在等待反馈、临时会议、上下文切换和非紧急沟通上。如果直接用 3 天去估算后续任务的排期会把很多非执行因素一并算进去导致排期越估越虚。EET 方法在计算时会剥离部分非执行时间让估算结果更贴近“真正做这件事”的耗时从而为工作量评估提供一个更稳定的参考基线。当然这并不意味着日历时间不重要。用户等待诉求处理的时间、跨团队协作的时间仍然会真实影响最终交付日期。EET 的价值在于把“纯执行耗时”和“等待/协作耗时”分开避免把两类时间混在一起后无法定位问题。团队可以据此判断到底是任务本身工作量大还是协作流程拖慢了交付速度。2.2 EET 的常用计算方式目前最常用的 EET 估算方法是三点估算法Three-Point Estimating。这种估算方式要求对每个任务给出三个时间估计值乐观时间 OOptimistic在一切顺利、没有任何意外情况发生的情况下完成该任务需要的时间。最可能时间 MMost Likely在正常条件下综合考虑常规波动后最有可能的完成时间。悲观时间 PPessimistic在考虑各种风险如需求变更、依赖阻塞、环境问题之后最坏情况下的完成时间。三点估算的公式为EET (O 4M P) / 6这个公式本质上是一个加权平均。最可能时间 M 被赋予了 4 倍权重乐观时间和悲观时间各占 1 倍权重整体期望值更偏向正常情况同时又保留了对风险因素的考虑。相比简单地取平均值三点估算可以减少极端值对估算结果的干扰。在一些团队中还会在 EET 的基础上引入资源效率系数。如果一位工程师每天 8 小时在岗但真正投入编码和评审的时间只有 5 小时那么资源效率就是 5/8 0.625。此时有效执行时间 估算时间 / 资源效率。这样做的目的是把会议、文档、评审等必要但非直接产出的时间纳入排期避免排期过于乐观。需要注意的是EET 估算出的结果不是一个“精确值”而是一个有参考意义的期望值。它适合用于多个任务的横向比较、整体工作量的粗略评估和排期方案设计但不适合当作对个人的严格考核指标。一旦把估算时间当成硬性考核线很容易出现“为了满足估算而低报 O 值和 M 值”的博弈行为导致估算数据完全失真。2.3 代码示例与结果解读下面用一个 Python 示例来演示 EET 方法的计算过程。假设一个开发迭代被拆成了 7 个任务每个任务都有对应的乐观时间、最可能时间和悲观时间单位为小时。# 文件路径eet_calculate.py tasks [ {name: 需求分析, o: 3, m: 5, p: 9}, {name: 接口开发, o: 6, m: 10, p: 18}, {name: 前端页面, o: 4, m: 8, p: 14}, {name: 联调测试, o: 2, m: 4, p: 8}, {name: Bug 修复, o: 1, m: 3, p: 7}, {name: 代码评审, o: 1, m: 2, p: 4}, {name: 发布上线, o: 0.5, m: 1, p: 2.5}, ] def calc_eet(o, m, p): 三点估算EET (O 4M P) / 6 return round((o 4 * m p) / 6, 2) results [] for task in tasks: eet calc_eet(task[o], task[m], task[p]) results.append((task[name], eet)) print(f{task[name]}: 三点估算 EET {eet} 小时) total_eet round(sum(item[1] for item in results), 2) print(f\n项目预计总有效执行时间 {total_eet} 小时) # 假设团队每人每天有效投入 6 小时 team_member_daily_effort 6 ideal_work_days round(total_eet / team_member_daily_effort, 1) print(f按每人每天有效投入 6 小时计算需要约 {ideal_work_days} 人天)运行这段代码会得到如下输出需求分析: 三点估算 EET 5.33 小时 接口开发: 三点估算 EET 10.67 小时 前端页面: 三点估算 EET 8.33 小时 联调测试: 三点估算 EET 4.33 小时 Bug 修复: 三点估算 EET 3.33 小时 代码评审: 三点估算 EET 2.17 小时 发布上线: 三点估算 EET 1.08 小时 项目预计总有效执行时间 35.25 小时 按每人每天有效投入 6 小时计算需要约 5.9 人天这里有几个信息值得解读。第一单个任务的 EET 并不等于“日历时间”它代表的是任务本身的有效工作量。第二总有效执行时间 35.25 小时是按“单人理想投入”估算的如果项目有 3 个人并行开发还需要结合任务依赖关系进一步拆分不能简单除以人数。第三在排期时不能只在总 EET 上直接加上缓冲时间而应该先确认各任务的执行顺序和依赖关系再决定缓冲放在哪个环节。这个示例虽然简单但已经足够说明 EET 方法的计算思路。实际项目中O、M、P 三个值不应该完全靠拍脑袋而应该参考历史任务数据、团队成员经验、需求复杂度和风险登记表来填写。历史任务库越大估算结果越有参考价值。2.4 EET 方法的适用边界与局限性EET 方法适用的场景包括需求排期与迭代计划制定、任务工作量横向对比、测试与联调耗时评估、发布窗口规划。在这些场景中团队关心的是“具体任务预计花费多少时间”EET 能把主观经验转化为相对可比较的数字帮助团队在多个候选方案之间做选择。但 EET 也有明显的局限性。第一它对输入数据质量要求很高。如果 O、M、P 三个值都是随意填写的那么计算出来的 EET 没有任何参考价值。第二它只看单次任务无法揭示长期趋势。团队整体效率可能在几个月内持续下降但如果只是单独看某一个任务的 EET很难发现“趋势恶化”这一信号。第三三点估算公式本身假设最可能值出现的概率是乐观值和悲观值的 4 倍这个权重是经验性的并不一定适合所有项目和所有团队。因此EET 方法更适合作为“微观效率评估工具”而不适合作为“宏观趋势判断工具”。要判断趋势需要引入 AGR 方法。3. AGR 方法详解3.1 AGR 的基本概念AGR 是 Average Growth Rate平均增长率的缩写常见于经营分析、数据运营、用户增长和容量规划等场景。它用来衡量一组周期数据的变化快慢回答“这个指标是在增长还是在下降增速大概是多大”。需要特别说明的是AGG 在不同口径下计算方法有差异。最常见的是复合年均增长率CAGRCompound Annual Growth Rate其次是简单平均增长率。两者在数据波动较大时结果差异明显实际使用中一定要先在团队内部统一口径否则很容易出现“同一个数据集两个人算出了两个趋势结论”的情况。复合年均增长率的含义是如果从期初值增长到期末值且每个周期都以一个固定速率增长那么这个固定速率是多少。它相当于把多个周期的实际变化压缩成一个可比较的“等效年化增长率”非常适合对跨周期数据进行长期趋势对比。3.2 AGR 的常用计算方式先看简单平均增长率。假设有 n 个周期我们可以先计算每个周期相对上一个周期的环比增长率第 i 期环比增长率 (第 i 期值 - 第 i-1 期值) / 第 i-1 期值然后对所有环比增长率取平均得到简单平均增长率。这种计算方式实现简单容易理解但容易受到极端值的干扰。如果某个月份出现了异常高增长下一月又回归正常简单平均增长率会被异常值拉高无法反映真实趋势。再看复合年均增长率。对于月度数据如果我们想计算月均复合增长率公式为月均复合增长率 (期末值 / 期初值)^(1 / n) - 1其中 n 为周期间隔数。例如 1 月到 12 月的数据一共有 11 个间隔月那么 n 11。如果进一步计算年化复合增长率通常用CAGR (期末值 / 期初值)^(1 / 年数) - 1这种计算方式只看期末值和期初值不受中间过程波动影响。但反过来它也会掩盖期间的重要变化。比如某个指标前半段大幅上升、后半段快速回落首尾值可能看起来没什么变化但 CAGGR 仍然可能很低。因此在解读 CAGR 时一定要带上过程数据一起看不能孤零零地只看一个数。另外当数据中出现 0 或负值时CAGR 的公式会失效。比如期初值为 0则比值无法计算期初值为负数开方后结果可能无意义。这种情况下需要改用其他口径比如分段计算增长率或者直接分析绝对值变化量。3.3 代码示例与结果解读下面用一个 Python 示例来演示 AGR 的计算过程。假设某个业务系统有 12 个月的月度活跃用户数据我们需要计算每个月的环比增长率、简单平均增长率和复合月均增长率。# 文件路径agr_calculate.py monthly_data [1200, 1280, 1350, 1310, 1420, 1500, 1610, 1580, 1700, 1820, 1950, 2050] def calc_monthly_rates(data): 计算每个周期相对上一个周期的环比增长率返回百分比列表 rates [] for i in range(1, len(data)): prev data[i - 1] curr data[i] rate (curr - prev) / prev rates.append(round(rate * 100, 2)) return rates monthly_rates calc_monthly_rates(monthly_data) print(每个月的环比增长率%, monthly_rates) # 简单平均增长率 simple_agr round(sum(monthly_rates) / len(monthly_rates), 2) print(简单平均月度增长率%, simple_agr) # 复合月均增长率 n len(monthly_data) - 1 cagr (monthly_data[-1] / monthly_data[0]) ** (1 / n) - 1 cagr_percent round(cagr * 100, 2) print(复合月均增长率%, cagr_percent) # 按复合月均增长率外推下个月预测值 next_month_predict round(monthly_data[-1] * (1 cagr), 2) print(按月均复合增长率外推下个月预测值, next_month_predict)运行这段代码预期输出如下每个月的环比增长率% [6.67, 5.47, -2.96, 8.4, 5.63, 7.33, -1.86, 7.59, 7.06, 7.14, 5.13] 简单平均月度增长率% 5.06 复合月均增长率% 5.49 按月均复合增长率外推下个月预测值 2162.52从结果中可以看到两个关键点。第一简单平均增长率是 5.06%复合月均增长率是 5.49%两者并不相同。原因是简单平均增长率受到 4 月-2.96%和 8 月-1.86%两个负增长月份的影响被拉低了。而复合月均增长率只看首尾值不受中间波动影响所以结果偏高。第二如果直接用复合增长率外推下个月预测值约为 2162.52但实际可能会因为季节因素、运营活动和系统容量问题产生波动。因此预测值只能作为参考不能当作确定目标。在处理真实业务数据时我通常会把两条线一起看一条是环比增长率的月度走势用来发现“最近几个月增速是否出现异常”另一条是复合年均增长率用来评估“整体趋势是否健康”。两者结合可以避免只看总数而忽略过程波动。3.4 AGR 方法的适用边界与局限性AGR 方法适用的场景包括业务增长趋势分析、容量规划、季度年度复盘、关键指标目标设定。在这些场景中团队希望从多周期数据中提取一个相对稳定的趋势值用来回答“整体是变好还是变差”“增长速度快不快”“按照当前趋势未来会到多少”等问题。AGR 的局限性也很明显。第一它过度依赖首尾值。对于复合增长率来说期中出现的所有波动都被平滑掉了。如果首尾值正常但中间曾出现严重的下滑CAGR 也无法反映这个过程风险。第二数据量太少时AGR 没有统计意义。只有 2 到 3 个周期的数据计算出的平均增长率很容易被单次异常值左右不能用来做决策。第三数据存在负值或零值时标准 AGR 公式不适用需要设计替代口径。第四AGR 是“结果指标”只能告诉你趋势发生了什么无法告诉你“是哪个环节导致趋势变差”因此需要结合 EET 这类过程指标一起分析。4. EET 与 AGR 的全面对比下面从多个维度对 EET 方法和 AGR 方法做一次系统对比。对比维度EET 方法AGR 方法关注对象单个任务、单个环节的执行时间多个周期指标的整体趋势核心问题这件事预计需要多久这个趋势是变好还是变差时间粒度小时、人天级月、季度、年级典型场景需求排期、任务估算、测试评估业务增长分析、容量规划数据要求任务的乐观/最可能/悲观时间连续多期指标数据计算复杂度低加权平均即可低但口径容易混淆对波动的敏感性对输入值敏感简单平均对波动敏感复合平均对波动不敏感主要优势支持微观任务排期和瓶颈定位判断宏观趋势和增长健康度主要局限无法反映长期趋势变化无法定位具体问题环节决策价值支撑“如何安排资源”支撑“是否需要干预”从表格可以看出EET 回答的是“怎么做”AGR 回答的是“要不要做”。在一个成熟的研发效能分析体系中两者应该被放在一起看。比如团队发现本月需求交付量AGR明显下降这时候需要借助 EET 方法拆解具体任务确认是开发环节耗时增加、测试环节阻塞还是需求变更过于频繁。反过来如果团队通过 EET 发现某类任务耗时持续上升但没有配套的 AGR 趋势数据团队也很难判断这只是偶然波动还是整体效率恶化的前兆。这里还需要强调一个容易踩坑的地方不要把 EET 的估算结果直接当成 AGR 的输入数据去计算增长率。EET 是“对完成时间的期望估计”不是“实际完成时间”。如果用多个版本的估算值去计算增长率得到的趋势可能只是“估算偏差的变化”而不是“真实效率的变化”。正确的做法是EET 用于排期和任务级评估实际完成时间用于效能趋势分析两者分开统计最后再综合判断。5. 实战案例从任务效率到增长趋势的联合分析这一节用一个完整的实战案例演示如何把 EET 和 AGR 组合起来对一个研发迭代做复盘。假设某团队正在进行版本迭代复盘。团队收集了两个层面的数据第一个层面是当前迭代各任务的三点估算时间用来计算 EET第二个层面是最近 6 个月的需求交付量用来计算 AGR。目标是判断“当前迭代的排期是否存在明显偏差”以及“近 6 个月整体交付效率是上升还是下降”。# 文件路径eet_agr_analysis.py # 第一部分EET 计算 tasks [ {name: 需求分析, o: 2, m: 4, p: 7}, {name: 后端开发, o: 5, m: 8, p: 14}, {name: 前端开发, o: 4, m: 7, p: 12}, {name: 联调测试, o: 3, m: 5, p: 9}, {name: 回归验证, o: 1, m: 2, p: 5}, ] def calc_eet(o, m, p): return round((o 4 * m p) / 6, 2) total_eet 0 print( EET 任务级估算 ) for task in tasks: eet calc_eet(task[o], task[m], task[p]) total_eet eet print(f{task[name]}: EET {eet} 小时) print(f当前迭代预计总 EET {total_eet} 小时\n) # 第二部分AGR 计算 delivery_data [18, 20, 22, 19, 24, 27] print( AGR 趋势分析 ) print(近 6 个月需求交付量, delivery_data) rates [] for i in range(1, len(delivery_data)): prev delivery_data[i - 1] curr delivery_data[i] rate (curr - prev) / prev rates.append(round(rate * 100, 2)) print(各月份需求交付量环比增长率%, rates) simple_agr round(sum(rates) / len(rates), 2) print(简单平均月度增长率%, simple_agr) n len(delivery_data) - 1 delivery_cagr (delivery_data[-1] / delivery_data[0]) ** (1 / n) - 1 print(复合月均增长率%, round(delivery_cagr * 100, 2))运行结果如下 EET 任务级估算 需求分析: EET 4.17 小时 后端开发: EET 8.5 小时 前端开发: EET 7.33 小时 联调测试: EET 5.33 小时 回归验证: EET 2.33 小时 当前迭代预计总 EET 27.67 小时 AGR 趋势分析 近 6 个月需求交付量 [18, 20, 22, 19, 24, 27] 各月份需求交付量环比增长率% [11.11, 10.0, -13.64, 26.32, 12.5] 简单平均月度增长率% 9.26 复合月均增长率% 8.45在这个案例中EET 告诉我们当前迭代预计需要投入约 27.67 小时的有效执行时间可以据此安排人力。AGR 显示近 6 个月需求交付量总体处于增长状态简单平均增长率为 9.26%复合月均增长率为 8.45%。如果把两者联合起来看可以得出两个管理判断第一当前迭代的工作量处于正常范围排期压力不大第二团队近 6 个月的交付效率呈上升趋势需求交付量整体向好。后续如果交付量继续上升可能需要提前评估团队容量是否足够这时 AGR 的预测价值就体现出来了。如果数据出现相反的情况比如 EET 很高但 AGR 放缓则说明团队可能正处于“任务变重、趋势变差”的阶段需要优先排查瓶颈环节如果 EET 很低但 AGR 也在下降则问题可能不在单个任务效率而是需求不足或优先级安排不合理。联合分析的核心就是用 EET 定位“哪里有问题”用 AGR 判断“问题严重到什么程度”。6. 常见问题与排查思路在实际使用 EET 和 AGR 的过程中团队常常会遇到一些问题。下面整理成表格方便快速排查。问题现象常见原因解决思路EET 估算结果总是比实际完成时间小很多三点估算的 O/M/P 值过于乐观或没有包含等待、协作时间统计历史任务的实际完成时间反推各角色合理的 O/M/P引入资源效率系数EET 估算结果总是偏大排期过于保守过度悲观P 值设置过高任务拆分粒度过大细化任务拆分参考同类型历史任务数据校准 P 值AGR 计算结果与业务体感不符使用了不同口径简单平均和复合平均结果不同统一口径建议同时输出两种值并解释差异来源数据中出现 0 值或负值CAGR 无法计算标准 CAGR 公式要求期初值为正且非零改用分段增长率、绝对增长量或自定义基线值进行分析EET 与 AGR 结论矛盾两个方法本身观察层次不同并非真的矛盾先确认结论不一致的原因再用任务级数据验证整体趋势是否被局部波动掩盖只有 2 到 3 个周期数据就计算 AGR数据量太少趋势判断没有统计意义至少收集 6 个周期以上数据再下结论短期数据只看环比把 EET 估算值当作实际完成时间EET 是期望值不是真实耗时分表记录“估算 EET”和“实际耗时”分别统计逐步提高估算准确率团队不同成员填写的 O/M/P 口径不一致缺乏统一填写说明编写估算说明文档给出每个级别的定义和参考案例必要时做一次校准会议这里最想强调的一点是EET 和 AGR 的计算本身并不复杂真正的难点在于数据质量和口径统一。如果团队内部没有达成一致的“估算标准”和“增长率口径”任何精细的计算都只是数字游戏。因此在搭建分析能力之前建议先把口径、填表规范和计算频率定下来。7. 最佳实践与工程建议经过一段时间的使用我在 EET 与 AGR 的组合分析中总结了一些实践经验这里分享出来供参考。第一先明确口径再投入计算。EET 要明确使用三点估算还是加入资源效率系数AGR 要明确使用简单平均增长率还是复合年均增长率以及统计周期是周、月还是季度。口径一旦确定就不要频繁更改否则历史数据无法横向对比。第二用历史数据驱动估算。EET 的 O、M、P 值不应该是纯主观经验可以按月统计任务实际耗时分布得出不同难度任务的耗时区间再把这些区间作为后续估算的参考基线。任务库积累得越久估算越准确。第三不要只看 AGR 的单个数值。复合增长率虽然简洁但它隐藏了中间波动。建议在输出 AGR 时同时附带环比增长率的走势必要时画出折线图可以用 Excel 或 Python matplotlib 完成避免团队被一个平均数误导。第四把 EET 和 AGR 放进同一份复盘文档。建议每周或每两周更新一次形成固定的报表模板。模板中可以包含三块内容当前迭代 EET 与预估偏差、最近 6 个月需求交付量 AGR、偏差原因说明。这样团队既能看到当周任务执行情况也能看到长期趋势变化。第五关注异常值处理。在执行 AGR 计算之前可以对原始数据做一次基础质量检查比如是否存在明显录入错误、是否有促销或重大活动导致的极端波动。如果存在可以标记异常或单独分析不要让个别异常值主导整体结论尤其是简单平均增长率更容易被极端值拉偏。第六结合其他指标综合判断。EET 和 AGR 都属于“效率/增长”类指标但研发效能还需要考虑质量指标比如线上缺陷率、故障恢复时间、需求变更率等。一个项目如果 EET 很低、AGR 很高但线上缺陷频发那也不能简单认定团队效率健康。建议至少搭配 2 到 3 个质量指标一起分析。第七把计算脚本沉淀成工具而不是每次手工算。上一节的 Python 示例可以直接封装成函数输入任务数据或周期数据输出 EET 和 AGR 结果。有条件的话还可以接入内部报表平台定时自动计算减少人工操作带来的误差。第八注意数据隐私和数据安全。在收集和分析任务耗时、成员行为数据时要遵循最小必要原则只采集与效率分析相关的数据避免过度采集个人信息。涉及生产环境指标和敏感业务数据时务必在合法授权的前提下使用并通过脱敏、权限控制等方式保障数据安全。8. 写到最后EET 方法和 AGR 方法并不是互相排斥的两种数据分析套路而是分别站在微观和宏观两个层面回答不同问题。EET 告诉我们“单个任务预计需要多久”适合项目排期、任务估算和瓶颈定位AGR 告诉我们“整体趋势变得多快”适合业务增长判断、容量规划和阶段性复盘。单独使用任何一种方法都容易得到片面的结论结合在一起才形成一套相对完整的效率评估闭环。建议你先从一个小范围试点开始比如选择当前迭代作为研究对象用 EET 计算每个任务的预计耗时再同时收集过去 6 个月的交付量数据计算 AGR。运行一个月之后对比估算和实际的偏差、观察趋势变化再逐步优化口径和流程。数据积累得越久结论就越可靠。等跑通这一套流程后你还可以继续学习更深入的内容比如蒙特卡洛模拟在工期估算中的应用、移动平均与指数平滑在趋势预测中的比较、以及如何用质量指标修正效率指标带来的误判。如果这篇文章对你有帮助欢迎收藏备用。后续我会分享更多关于研发效能分析、项目管理方法论和 Python 数据处理方面的实战笔记。