我们是一家小型（15 人）网络开发/设计公司，拥有大约 8 名全职 LAMP 开发人员。为了减少我们犯的错误并防止我们的预算超过我们的估计，我在开发开始之前对我们的项目进行了某种技术分析。这对于应用程序开发人员来说是一件轻而易举的事，但在我们的领域 (webdev) 中，这似乎并不常见。到目前为止，我们刚刚收到了我们的项目经理整理的一份简短的简报（通常不到一页），并因此一头扎进了开发阶段，结果出现了一些灾难性的预算失败。
为了解决这个问题，我开始阅读这个主题，我阅读了 CodeComplete2、Pragmatic Programmer 和 The Mythical Man-month。我想我已经掌握了准备和分析一个新项目背后的概念，但我缺乏实际的例子。有谁知道我可以查看的示例技术分析或广泛的项目简介，以便更好地将我读过的东西付诸实践？我非常喜欢通过例子学习，不用这么说:)
【问题讨论】：
标签： project-management analysis
很遗憾，大多数项目范围文档都受到商业保护，因此无法发布，但我很高兴能总结出我的经验，了解什么是好的文档，并且包含了我希望看到的内容.
要记住的主要事情是您要实现的目标 - 您要尝试在您和客户之间就正在发生的事情达成共识。错误的估计不仅与您认为需要和实际需要之间的差异有关，还与您认为您将交付的内容与客户认为您将交付的内容有关。
查看记录所有这一切的一种方法是让您被覆盖，如果客户确实回来并转到“报告模块在哪里”，您只需指向“将没有报告模块”的句子，但是那不是真的。这实际上是在开始时进行对话（可以是建设性的）而不是结束时（可能是对抗性的）。如果您的项目或客户经理开始认为过多的细节听起来很消极，请记住这一点。
那么，你应该包括什么：
对正在做的事情的高级描述——只有几段。它真的不会提供任何细节，但它设置了场景。因此，在本节中，您说您正在构建一个电子商务站点来销售小部件，它是一个 B2C 站点而不是 B2B 站点，该项目涵盖了站点的完整设计和构建等等。最多几段。
高级功能要求 - 概述将要构建/设计的关键功能的要点。对于每个数据实体，包括创建、读取、更新和/或删除，因为这将帮助您更好地理解任务。因此包括创建/读取/更新/删除用户的能力，创建、读取和更新订单的能力，创建/读取/更新/删除产品类别的能力，创建/读取/更新/删除产品的能力，包括文本、图片和视频。
非功能性需求 - 另一个会遗漏大量内容的领域。非功能性需求包括性能、用户负载、审计、归档、安全等。报告可能适合这里——虽然它真的很实用，但它会被遗忘，因为它通常是支持系统使用的东西，而不是它的核心部分。如果您没有在给定区域做某事（例如，不会有审计跟踪），那么请明确说明，也许在另一个名为...的部分中说明......
超出范围 - 在讨论是否包含某些内容（一些功能、与另一个系统的接口）时会出现问题。把这些写下来！根据我的经验，范围失败的关键领域之一是对这些对话的不同回忆，并将其提前写在纸上可以消除或大部分。这是报告可以进入的另一个领域（他们会知道他们想要报告，但不是什么所以它会漂移然后你交付并询问他们在哪里），还有用户管理（密码重置？）和安全性。
假设 - 在项目期间，您将没有足够的信息来做出真正准确的估计。没关系，你可以填补自己的空白，只要你明确这是你所做的。因此，如果您假设他们正在为您提供用于布置事物的公司模板，那么请将其写下来。如果您认为他们提供了所有内容的副本和图片，请再次将其写下来。
我会考虑的其他部分包括：
技术平台 - 如果您认为在高层次上描述技术平台很重要（在本例中为 LAMP 加上任何其他位）。以我的经验，这不是一个真正发生范围信条的领域，但它往往需要两分钟，所以它不会受到伤害。
与其他系统的接口 - 根据我的经验，增加任何项目复杂性的因素之一是您无法完全控制的事情，而发生这种情况的关键领域之一是与其他系统的接口。在您处理这些问题的地方，最好列出系统、界面类型以及将要发生的交互。所以，如果你要更新他们的库存系统，说你是，说它是一个网络服务，说你会触发库存查询，更新库存水平等等。
依赖项 - 同样，这是您的控制之外的一部分。如果有其他方为项目做出贡献（包括客户），最好列出您对他们的期望。谁在提供副本，以什么格式（是结构良好、易于导入的 Excel 文件还是一百万个 Word 文档）？您希望与之交互的第三方应用程序的测试系统怎么样？你什么时候需要这些东西？
希望这会有所帮助。
编辑：我挖出了一些我在上一份工作中使用的模板并稍微匿名了。它们是内部的（也就是说，我们是在公司内部工作的内部团队，而不是为其他组织工作的团队），但结构和原则是相同的。
我已经包含了一个非常接近您想要的文档类型的项目任务模板：
http://seventeensix.tumblr.com/post/749062608/a-sample-project-mandate-template
还有一个规范模板，其中可能还有一些你会发现有用的部分：
http://seventeensix.tumblr.com/post/749077647/a-sample-specification-template
项目授权一包含来自其中一个项目的一些真实样本（一个非常乏味的金融系统对账包），都包含结构和指针，说明奇怪的例子的去向。
【讨论】：
这些都是好书。我可能建议还添加“软件需求 2”和“人件：生产性项目和团队”（我还没有阅读人件；恐怕它已经在我的待办事项列表上一段时间了。）
但恐怕经验是无可替代的；如果你关注你的团队过去引用的内容，实际交付的内容，并尝试找出你对或错的部分是对还是错的原因，你将学会如何成为更好。
根据我的经验，尝试将大问题分解为小问题并没有什么坏处。迭代。当你认为你终于得到了需要 0.5 到 1 个程序员一天的工作时，那么你就达到了我在估算时间时取得最大成功的地步。
当然，您必须牢记为您工作的程序员：Alice 可能会在半天之内编写一个可交付的解决方案，Bob 可能需要一天，而 Charlie 可能需要两天时间，而 Bob 需要一个小时用于代码审查。了解程序员的优缺点也需要经验。
【讨论】：