问为管理建立项目结构模型

EN

UML是将设计与项目上的技术资源进行交流的一种很好的方式，尽管在我的经验中，绝大多数非技术项目资源都会因此而丢失。UML确实需要最低程度的培训才能完全理解或制定它。一些非技术同行可能是用例图方面的专家，但当他们看到组件图时，最好用kanji编写。

我发现，在开始绘图之前，了解图表的读者是很重要的。非技术同行通常更容易理解和跟踪流程图，而不是活动或序列图。他们还可能只需要标有标签的框和箭头，而不是完整的UML组件关系图或部署图。有时，我会做两组文档，一组是为非技术对等体简化的，另一组是UML中的技术对等体文档。其他时候，如果时间不够，我甚至不去看UML图，因为大多数情况下，技术人员通常可以理解简化图中的复杂性。

另一个你必须问自己的重要问题是，你的非技术经理为什么觉得这些文件很重要？是因为这个项目遇到了问题，而微观管理的冲动也开始出现了吗？这是为了帮助准技术销售人员更好地向潜在客户解释您的软件和体系结构的优点吗？这可能就像一位经理想要在他的办公室或技术领域建立复杂的外观图，试图给他带来的办公室访客留下深刻印象一样肤浅(真实的故事)。底线是了解你的观众，并且很好地了解它。

主要问题是缺少的体系结构。

您的体系结构解决了哪些问题？即使是设计最糟糕的应用程序也有一个体系结构，所以除非您从头开始，否则就存在一个架构。在你的情况下，也许没人费心把它记录下来。管理层希望知道，您有一个项目具有某种优势(例如性能、易于维护、代码重用、公认的标准等)。

缺少指导方针，如何组织项目。

如果你不是在混乱中工作，他们会感觉更舒服。优先考虑50个子项目。指定正在跟踪进度的人。向他们展示你有一个系统，这样你就知道开发人员正在完成任务。你能证明这种架构对这种类型的项目是有利的吗？

不幸的是，他们真的想知道:多长时间？还有多少钱？你应该能够回答这些问题，但它可能没有他们想要的那样准确。