Project management 对于一个项目计划来说，有多小太小？

我有一些朋友要求我制作网站，大多数都很小，通常我不会为技术计划操心，但有一位朋友的目标显然比我自己的目标更大，而且这个项目一直在拖延。如果我在项目之前制定了规范，我觉得这不会发生，我们的关系也会像以前一样牢固

---

所以我的问题是，你怎么知道有多小就是太小？你如何判断你正在着手的项目何时会陷入充满内疚的范围蔓延噩梦？

正如你可能已经意识到的那样，没有一个项目太小，至少没有一个非正式的书面计划。即使只是一个功能列表。

如果你想收费，或者不想永远做这个项目，项目计划总是一个好主意。即使它只是一页纸，概述了网站将有多少页，有什么特殊功能，谁负责什么。您应该考虑到您将花费20%的时间，或者过去的经验告诉您的文档或非编码类型工作的百分比，您可以更好地估计所需的工作量。如果是朋友，你可能想告诉他们你将免费做第一个X小时，但之后你的费率是每小时Y美元。此外，准确记录你所花的时间，以便向他们展示所付出的努力。此外，保持准确的日志有助于您估计未来的项目。

不需要计划的项目是甚至不需要启动的项目。在我看来，一切都需要一个计划，计划的范围会有什么变化。一个计划可能只是一个可交付成果的列表，每个可交付成果都附有一些截止日期。一个更稳健的计划应该包括时间表、成本、阶段、通信方式、依赖性等。因此我认为一切都需要一个计划，计划的内容是根据项目的复杂性而变化的内容。

德怀特·艾森豪威尔关于计划：

在准备战斗时，我总是 发现计划是无用的，但是 规划是必不可少的

在许多软件项目中似乎都是这样：您会发现您的计划需要不断更新，并且您的第一个计划与您最终完成的计划大不相同。但没关系，事先做一些计划要比随便做点什么好得多

敏捷专家试图通过将长期计划分解为2-4周的小冲刺来适应计划中的这些变化。他们会有更多关于短期冲刺的细节，而关于长期目标的细节会更少

---

如果项目更大，如果你是为外部客户做的，或者如果你正在尝试新的东西，你会特别想要更详细和精确。对于较小的项目和您以前做过且非常熟悉的工作类型来说，这不那么重要，但也不是不重要。

我没有从改进的评估角度考虑这一点，也没有证明这确实需要相当多的时间。谢谢。这是一个很好的视角，我很高兴我这么问。我真的很喜欢这句话。我从未听说过它适用于项目管理，但它似乎完全适合。我也喜欢在这个项目上进行冲刺的想法。我有点想知道是否有专门针对你周末做的项目的敏捷方法。这就是hackathon的编码风格吗？@Chuck，这是一个非常有趣的问题。。。我从未见过任何关于个人敏捷技术的东西。CMU软件工程研究所的瓦茨·汉弗莱（Watts Humphrey）写过关于个人软件过程的文章，请参见。