在实体企业做IT项目管理，是一种什么体验呢？
在实体企业做IT项目管理，是一种什么体验呢？
当项目开始时，个人认为最重要的是要弄清楚项目的目标和项目的范围，包括需求范围和时间范围。这种情况相信大多数人发生了，它只能根据个人经验从有限的需求声明计算，并且还有必要估计合理的时间，因为虽然领导者没有指定特定时间，但是并不意味着有可能的时间范围。关于项目需求的收集，有时我渴望满足所有需求，但在大多数情况下，这很难做到。我总是通过滚动规划，逐渐细致的指导来确定一些大需求方向，并逐渐改进这些需求。在大方面内进行需求的详细信息。如果允许时间，您可以通过原型构建原型，更好地掌握项目的需求以及存在的风险。
关于技术框架架构的选择，始终选择框架作为选框架。事实上，我工作的公司，有一套框架。大多数项目遵循此框架，这些框架遭受了生产环境，因此风险是最小的。有时候，我觉得这一框架很漂亮，或者太糟糕了，修改框架需要太多时间，但这不是我似乎最重要的事情。框架的目的是将程序员拉到管道，提高生产力，更复杂的框架是，性能越大，理论上，代码性能不使用框架，但可读性不易管理，所以必须使用良好的框架组织代码。
我经历了一个项目，我认为它过度设计了一个框架，一点设计设计，框架设计师被抛开使系统拆分，从而调用某些类库。它必须依赖反射和其他方式，并且为了完成功能性商业，许多不同的文件通常在十几个项目中进行修改。并不提到系统性能的影响，单一单一的开发经验非常糟糕，厌倦了在每个项目中要修改的文件。流行说说，解耦的主要目的之一是实现代码复用。确实，框架去耦的目的是真的，但是什么？从来没有随后的项目将使用这些解耦的子项目，因为一旦系统业务很复杂，虽然做出了最大的避免，就会有功能模块相互交互，而且它没有独立用作DLL以提供其他项目。
实际上，当新项目开始时，在大多数情况下，在原始副本代码的情况下，而不是直接使用DLL。解耦的另一个目的是降低系统之间的关系，使得更容易修改该程序，该程序在书上读取。但事实上，我觉得它不是这样的事情，任何改变，如果是一个简单的代码改变，即使耦合很高，它也可以改善，如果有更复杂的业务变化，则低耦合是也降低了。无法更改更改的大小。这不是负面解耦，只是解释当系统设计时，有必要考虑，而不是说，在我看来，保持吻原则会让我担心。团队建设
