项目经理的浮生绘记

技术债不可怕，可怕的是没人承认它、没人管理它。不懂技术的项目经理，一样可以把技术债管清楚。技术债不是失败的证明，而是项目真实走过的痕迹。

在你的项目经历中，印象最深的一次“迭代中需求突袭”是什么？你当时是如何应对的？如果现在复盘，你会采取怎样不同的策略？你认为建立一个有效的变更控制流程，最大的难点在哪里？

在你的项目中，是否曾因一个低级错误（如配置错误、兼容性问题）导致版本受阻或上线失败？你们后来是如何建立或优化“冒烟测试”或类似的质量门槛的？推行过程中，最大的阻力是什么，又是如何克服的？

作为项目经理，在技术（实现手段、质量与架构）与业务（市场需求、商业目标与领导意志）的拉扯中，不要选边站。你的正确站位，是站在“项目成功”的那一边。

项目经理不懂技术不是问题，不尊重技术才是。项目经理的职责不是解决技术问题，而是让技术有条件解决问题。

如何在不增加项目时长的前提下，将Code Review机制植入到开发流程中，让团队从“事后救火”转变为“事前预防”？

如果一件工作，在开始之前就没有被清晰地定义“怎样才算完成”，那么无论我们用多么炫酷的工具来追踪它，最终交付的都可能不是大家想要的东西。

在互联网项目中，最昂贵的成本不是开发时间，而是“返工”。而绝大多数的返工，不是因为技术难，而是因为“没想清楚”。

敏捷迭代规划会议，是团队在变化中依然保持节奏的“中枢系统”。不是项目经理在派活，而是团队在认领，让变化变成团队的动力，而不是负担。