假设你手头有一个特定的项目，它可以分成几部分，你不能完全确定会出现的所有困难。 时间至关重要。
我很想听听关于这些的任何经验法则。
【问题讨论】：
标签： project-management evaluation
改变你的决定就像改变你正在建造的房子的蓝图。
这将完全取决于您在那时所花费的时间和金钱。
一些注意事项：
0) 在开始之前以清晰简单的术语理解问题。 了解对成功至关重要的因素，然后使用该列表查看是否有任何软件、语言或工具可以帮助解决问题，并在什么成本，以及成本是否超过收益。
1) 使用填鸭式的时间表。 如果您只有 1 天或 1 周的时间，并且没有更多的工作时间，请按照您将要构建的顺序构建它。令人惊讶的是，当您必须以 100% 的质量完成 50% 的功能时，多少不再重要了。专注于价值，价值，价值。阅读 37 Signal 的书 Getting Real 之类的内容，了解更多信息。
2) 不要重新发明轮子。从头开始似乎总是更容易。除非你只做一小部分的实现并且它真的更简单，这意味着你可以避免抽象，直到你忘记你正在构建的东西，考虑它。如果你能在相同的时间内更快、更好、更便宜地建造它，那就去做吧。
3) 了解您的工具的功能，以及任何工具为您的解决方案带来的好处。您应该熟悉或至少了解您可能或可能无法集成。
4) 选择一种可以解决很多问题的语言。您可能会发现许多出色的库和工具来构建您的软件，从而节省您的时间。如果您需要可以交付、可以运行并且可以依靠他人的聪明才智的东西，请使用已建立的东西，或者在需要时可以轻松访问 .NET 或 Java 的语言。
【讨论】：
对于您识别为软件组件/包的软件的每个部分：
您如何决定某个部件应该使用软件产品还是您自己的代码？ （考虑到有些工具很棒，但需要很多时间来学习）
问问自己，您正在考虑的组件是否是您产品主要业务核心的一部分。
如果没有，那么通常最好使用现有的解决方案，不要花太多时间在上面。
如果是，请确保没有比您计划的产品更好的现有产品。 - 是的，考虑购买它的许可证而不是开发你的产品。
在线搜索类似的组件（商业、开源甚至文章/演示源代码）。
如果组件包含用户界面，是否美观且易于使用？
如果您对以上所有问题的回答都是肯定的，则不要自己开发组件。
如果不是：
组件是开源的还是发布在文章/演示代码中？ - 如果是这样，它很健壮，您能否对代码进行改进或以它为示例来帮助您编写更适合您要求的代码？ - 如果是这样编写您自己的代码，请将代码用作您自己的组件的一部分，该组件不是从头开始开发的。
如果您对上述问题的回答是否定的，那么您将不得不自己开发（或者您在错误的地方进行搜索）。
您如何选择合适的软件产品？
在选择正确产品的这一阶段（如果有的话）应该花费多少时间（以百分比计），以及评估单个产品需要多少时间？
有没有退路，是否可以在对产品付出努力后发现它不合适后改变主意？
始终设计您的软件，使每个组件都是可替换的。
即使您自己实现了某些东西，也要确保有退路 - 有时您可能使用了错误的技术/设计，不得不用您开发/购买的新组件替换组件。
李>其他经验法则：
在考虑每个组件之前，请考虑使用哪些应用程序范围的技术。
用汇编语言编写所需的时间最长，用 C 语言更少，用 C++ 甚至更少，用 C#、Java、Delphi 等更现代的语言甚至更少。
哪个有更多与您相关的自我组件？您的团队在哪些方面有经验。
如果您使用的是 .NET (C#)，那么 WPF 可以帮助您降低 GUI 和业务逻辑之间的耦合并制作更好看的 GUI，但是学习如何使用它需要时间（5 天非常推荐最低课程）。
【讨论】：
与任何艺术一样，困难在于基于非常大的可能解决方案空间来编写一个好的解决方案。有多少开发人员就有多少方法可以解决这个问题。
我通常会花一些时间了解问题并尽可能清晰简洁地说明问题，最好是书面形式。问题描述应该完全从任何可能的解决方案中抽象出来。接下来，我通常会列出需要应用于解决方案的可用限制（时间、预算、法律、政治、绩效、可用性、团队内的技能可用性等）。
然后理论是，您需要在市场上寻找可以解决问题并同时满足约束条件的东西。在实践中，这个过程并不是那么简单：你尝试识别可能有用的市场类别，然后研究它们，看看有什么可用的，并不断尝试尽可能减少限制和能力之间的差距，通常是通过返回并重新审视和重新协商约束。
一些通用提示：
在研究过程中不断回到最初的问题。
总是有不止一种解决方案，在深入之前尝试扩展搜索空间的广度（专注于解决问题的非常不同的方法）。
在决定是否进一步调查之前，请明确一些值得研究的选项，以及值得花在每个选项上的时间。
很少值得找到最佳解决方案，尤其是在技术环境变化非常迅速的情况下。寻找足够好的解决方案：“The Paradox of Choice - Why More is Less”。
很少值得turning to users for help（除非他们是软件专家）在多个选项之间进行选择。如果您有许多看起来都一样有吸引力的选项，这意味着您需要回过头来更好地理解最初的问题，那么您很可能错过了一个或两个要求。
关于 using third-party components 的一些进一步说明（指的是 GUI 组件，但也易于应用于其他软件领域）。
还有更多关于 scoping, composing and researching 项目的注释。
【讨论】：
问自己两个问题。
1）是否成熟的产品。如果是，那么
2) 自己创建它提供的功能需要多长时间。如果该值乘以您的小时费率大于产品成本，请使用该产品。
咨询您的其他开发人员网络。他们用过吗，有没有遇到问题。咨询互联网。使用产品创建原型。它运作良好吗？有什么大bug吗？
这取决于项目的规模以及产品对成功的重要性。大多数情况下，您将能够在很短的时间内获得产品的高级视图。
在您说“不”之前可能只需要几分钟就可以使用它 - 还没有准备好迎接黄金时段。如果它通过了，一两天的实验可能会告诉你它通过了你的项目的集合。
如果这是一个包含许多开发人员的大型项目，那么您可能希望花更多时间使用它来开发原型应用程序，以确保值得投入所有时间。
如果您发现它没有成功，那么返回并没有错。事实上，你可能不得不这样做。理想情况下，您会尽早发现这一点。不是在第 11 个小时。同样，这是原型设计的目的。
【讨论】：
这里已经有一些非常好的答案，所以我不会重复它，但是有一点你绝对应该考虑，虽然我认为它很明显，但我还没有看到这里提到它：
您可用于实施解决方案的人员、他们的核心能力以及他们的一般能力水平。
你必须由谁来实施这个（假设它是一个团队，而不仅仅是你自己——即使只有你自己也是相关的......）会对结果产生巨大的影响。如果你没有经验丰富的程序员来帮助你开发这个，你最好寻找一些 OTS 产品来为你完成这项工作......或者，即使你有不太可能成功的程序员，你仍然可能希望找到整体项目风险较低的解决方案。
【讨论】：