谈谈如何管理一个软件项目。

今天我们来聊一个稍有不同但在 Web 开发领域非常关键的话题：项目管理。虽然我在这行没多长时间（总共才 6 年，其中只有 3 年是有报酬的 ;-)），但我已经在不同规模的公司里积累了丰富经验：从中型媒体公司的 25 人开发团队，到仅有 5-6 人的小型开发公司（其中 3 人是开发者），再到作为独立开发者。

在我刚开始在一家中型公司工作时，我曾认为项目经理是个障碍。我只想沉浸在编程中。我有自己关于项目或功能应该如何完成的想法，我还自信自己能比项目经理更好地处理截止日期和项目要求。他们一天到晚问我在做什么，项目进展了多少，真的有这个必要吗？项目经理们真是让人敬而远之。坦白说，我曾经不明白为什么需要雇佣他们。我简直看不出项目经理的角色有何重要性。

然而，经过一些项目的开发和实践，我开始发现自己在没有项目经理的时候，会有种“天呐，我的项目经理哪去了？”的感觉。作为开发者，当我们没有项目经理的引导时，往往会沉迷于编程的艺术。我们本来打算做一件事，但到了截止日期几周后，却发现自己做出了完全不同的东西。这样的结果通常能工作，也许还算好看，但却不是我们最初承诺给客户的。

这不仅仅是指那些本应是简单登录功能，却发展成庞大的分层认证系统的项目。还有那些我们出于某种原因而厌恶，总想拖延完成的项目；有时我们甚至敷衍了事，编写次级代码，只是为了赶快结束。更不用说那些复杂到让我们不知从何下手，更别提按期完成的项目了。

这个问题似乎并不在于我们的能力——如果我们真的下决心，大多数人都能够严格遵守最初的规格和项目范围。我认为，问题的关键在于，没有项目经理在团队中担任角色，我们就缺乏必要的时间和任务管理来保证按计划推进。我们学会了如何通过优秀的编码原则和设计来解决逻辑问题。我们像艺术家一样，用数字作为我们的画布，但有时我们会让自己对创造力和对美的追求干扰了我们原本的工作。我们并没有学会克制，这本应是项目经理的职责——至少理论上是这样。

根据你的经验，下面的话可能听起来是不可思议的，但对我来说，这完全是真理。任何项目的成功都取决于一个坚实的开发方法，这种方法基于清晰定义的项目目标、模块规格、完整的用例，以及任务级别的开发划分和分配。一个优秀的项目经理能够把产品经理或客户联系人提供的高层设计规格和目标分解成清晰、可管理的小模块。然后，这些小模块可以进一步细化成特征/需求集，最终交给开发人员去完成。这是项目经理的工作，而非开发人员的。开发人员只应该被分配明确的任务，这些任务包括详细的用例和具体的完成要求。如何实现这些任务则取决于开发人员。

这并不意味着开发人员不应该参与项目的规划或设计阶段；实际上，他们必须参与。但是，涉及开发人员的设计和规划会议应该专注于项目或部分的技术目标，而不是管理层面和产品/客户层面的问题。这些会议应该专注有限，目标明确。比如，确定项目的数据库架构或选定开发框架。这里的抽象层非常关键，它有助于保持项目在预定范围内，防止开发人员扩大或缩小项目的交付范围。一旦会议的目标达成，项目经理就应该能够把技术规格具体化，分配给开发团队。

直到最近，我一直对“任务”二字颇有微词。每天早晨查看电子邮件，总会看到“您收到一个新任务，来自……”这样的消息，每当此刻，我都会不禁低头沉思，重新审视我的职业生涯。我总是在想，为何凡事都得变成任务：纠正一个错别字的任务，给网页末尾加上 5 像素的间距的任务。难道简单的发个邮件或即时消息，或者干脆转过身直接说出来，不是更方便吗？这怎么可能是编程的“禅境”？但最近的经历让我意识到，天啊，我们每个人都需要任务，就像我们都需要一个称职的项目经理一样！

任务分配及其良好的任务管理系统（注意这与严格的缺陷跟踪系统大相径庭）对项目管理至关重要。一个坚实而全面的项目管理系统能够实现适当的任务分配规范，这对多方面都至关重要。对于开发者来说，它首先是我们的购物清单，告诉我们具体要做什么，何时完成，并包含问题或功能的历史记录（大多数项目管理系统的任务都有评论/历史和文件附件功能）。从管理角度来看，项目管理系统能追踪开发者在各项任务上的工时，这些数据可用于计费或评估其他绩效指标。它还可以作为评估项目完成度的尺子，通过展示基于任务分配、耗时、项目完成任务的百分比以及开发者表现的各种统计数据。

虽然不想显得过于说教（或离题太远），但我还是想分享一些我从过去与不同项目经理和主管开发者合作中学到的实用技巧，并推荐大家使用。

任务估算的作用

不要忽视任务估算的重要性。虽然它们可能会占用一些时间，看似有些多余，但实际上，这是一种有效的时间管理手段，能反映出你的时间估计能力和工作的细致程度。具体方法是：对于每一个指派给你的任务，除非解决问题能在 10 分钟内完成，否则你应该在评论区列出需要修改的文件和行号，并简要说明预期的更改。然后，把工单交回给项目经理进行快速审核。如果你的时间预估符合项目的时间安排，任务就会再次交回给你。这样做的好处是，无论过去了多久，你都能迅速了解需要处理的问题以及具体位置。

记录已完成的任务

完成任务后，应详细记录下你修改的每个文件和行号范围，并简述所做的更改（此外，还应包括一个概括全部更改的简报）。这样做不仅便于后来的开发者追踪更改，还相当于用开发者的语言记录了完成该任务的具体细节。

实践六小时工作制

从我的上一位项目经理那里，我学到了一个关于时间管理的小窍门：每天只安排六小时的工作。他解释说，剩下的两小时通常会用于日常休息，比如上厕所、闲聊、任务转换的准备时间以及一些小型休闲活动。起初，我对此表示怀疑，毕竟上厕所会占用两小时听起来有点夸张。但实际上，这种安排非常有效。虽然并不是真的有两小时被这些零星事务占据，但它让我在工作中感到压力较小，能够更加轻松地完成任务，产出的代码和文档质量更高，经过更全面的测试。更有趣的是，与传统的八小时工作制相比，六小时工作制让我感到更有成就感和效率。你也不妨尝试一下，效果可能会出乎意料。

开发者兼职项目经理的风险提示

一般情况下，开发人员不应该同时承担项目经理的角色，即自行创建和管理任务。但在某些情况下，如资源有限或是单兵作战，我们可能别无选择。在这种情况下，作为开发人员，你可能需要花费四分之一到三分之一的工作时间来规划和管理任务，而不是实际开发。如果你的上司不理解或不愿意合理分配项目任务，你有必要向他们明确这一点。这不仅关乎你的心理健康，也关系到作为一名称职开发人员的全面性。在特殊情况下，如果你作为开发者被直接要求按照客户需求开发，并独自承担整个项目周期，我强烈建议你向管理层提出聘请项目经理的建议。如果这做不到，那你可能需要考虑更新你的简历了，因为项目分配、任务分解和其他高级项目管理职责本不应是你的责任。开发人员不适合做项目经理，反之亦然，这背后有其合理的原因。

细节决定成败

如果你接到的任务太泛泛而谈，而你对项目经理（PM）或老板的具体要求有所疑惑，不妨找你的老板寻求更明确的任务说明。通常，你的老板很快就能给你解释清楚你所需的信息，只有这样才能高效工作。要记住，学习是双向的：你可以从老板那里学到东西，反之亦然。一开始就花时间搞清楚准确的详细要求，总比你胡乱猜测，之后又不得不重新修改来得好。

话虽如此，现在有很多开发方法可以帮助你和你的团队以高效而明智的方式进行软件开发。我不是项目经理，也不自称对任何开发方法论了如指掌，但我特别偏爱像 Scrum 这样的敏捷开发方法。任何能保护开发者免受核心工作之外的商业流程（如规格变更、客户期望等）影响的方法论，在我看来都是上佳选择。尽量避免使用僵化、效率低下的传统瀑布式和牛仔编码方法。

总之，我希望我的一些个人经验能对那些过于专注于代码的开发者们（以及他们的经理们）有所帮助。别忽视管理你的业务这一面。它不仅能保护你的理智，还能在这个过程中让你成为一个更出色的开发者！