项目管理

本文将深入介绍技术项目经理，也就是 TPM 这一角色。 在大型科技公司和快速成长的创业公司中，TPM 越来越常见。但很多工程师、工程经理，甚至一些管理者，对这个角色仍然缺乏清晰理解。TPM 到底是什么？技术项目经理的职责有哪些？它和项目经理、产品经理、工程经理有什么区别？工程师和工程经理又能从 TP…

技术债务是软件开发中长期存在的问题。如何偿还技术债务、如何通过小改动理解代码库，以及什么时候应该进行大规模代码重写，都是工程团队在系统演进过程中绕不开的问题。 本篇主要讨论两个主题。 第一，如何通过偿还技术债务帮助自己进入工作状态。一个看似反直觉的观察是：做一些小的、非功能性改进，反而能帮助你更快理…

软件迁移是软件工程中最容易被忽视的话题之一，尤其是在高速发展的初创公司和大型企业中。 随着业务增长，公司往往需要采用新的系统和方法，以承载更高的负载、支持更多使用场景，或满足更多约束条件。于是，工程师有时就必须把旧系统或旧方法迁移到新系统或新方法上。这类系统迁移可能涉及服务替换、代码迁移、数据迁移、…

从一无所知，到否认它的存在；从接受它不可避免，到开始极力抗拒；最终，走向一种务实的中间立场。这大概是许多工程师在面对技术债务时都会经历的一条典型路径。 技术债务是软件开发中绕不开的问题。人们很容易想直接跳到结论：如何消除技术债务，以及如何避免技术债务。但如果跳过中间的认知过程，就很难真正理解最终立场…

最近，我越来越多地听到一种观点：基于时间的软件开发估算没有太大意义，所以我们应该停止这样做。比如，“我们只用故事点估算复杂度，不估算时间”，或者“要不要试试 #NoEstimates（不估算）”。这些建议在我身边出现得越来越频繁，但我对这两种做法都持保留态度。 我承认，软件项目估算，尤其是基于时间的…

想一想你这一周的工作待办清单：从回复同事的一条简短消息，到制定团队战略，你会如何分配时间和精力来完成这些任务？ 行为科学告诉我们，大多数人在工作中并不总是追求“最优解”，而是倾向于选择“满意解”：找到第一个“足够好”的方案，然后继续往下推进。这个概念由诺贝尔经济学奖得主、社会科学家赫伯特·A·西蒙（…

很多计划评审清单之所以看起来完整、会议里也没人提出明显异议，项目后面却还是失控，问题通常不在“有没有清单”，而在清单只检查了表面项，没有穿透到依赖、边界、责任和变更机制。计划评审会上最容易漏掉的细节，往往不是任务名称、时间节点这些显性内容，而是“谁来确认”“何时算完成”“一旦偏差出现怎么处理”这些决…

进度基线该管到多细，关键不在“越细越专业”，而在是否足以支持决策、预警和纠偏。计划审批之所以会拖慢项目，常见原因不是大家不重视计划，而是把进度基线做成了“全量细节审查”，导致审批者看不懂、执行者改不动、项目一启动就过时。更合适的做法是：基线只管关键路径、阶段里程碑、跨团队依赖和交付边界，执行层细节交…

项目在重新梳理进度基线变更后才发现阶段拆分存在风险，这通常说明前期计划并不是“排得不细”，而是阶段边界、交付定义、依赖关系和变更触发条件没有提前说清。要解决这类问题，关键不是把甘特图再切得更碎，而是回到阶段拆分本身：先判断风险出在“分段逻辑”还是“执行偏差”，再补齐里程碑、责任边界和变更机制，否则基…

阶段性进度计划的核心难点，不是把时间排满，而是判断计划应在什么时点冻结。冻结太早，后续变化无法吸收，计划很快失真；冻结太晚，团队始终在改，执行无法稳定推进。所谓“计划冻结点判断”，本质是在不确定性、协同成本和兑现压力之间找一个平衡点，让阶段性进度计划既能指导执行，又不过早僵化。 很多团队觉得计划一旦…