数据应该与利益相关者讨论，绝对是的。除非利益相关者都是“数据库专家”，否则不应该讨论数据库架构，除非特殊情况。

那么，如果没有讨论数据库模式，如何讨论数据呢？这是我发现实体关系（ER）图和ER模型的主要用途。许多数据库设计师往往把ER视为关系数据建模（RDM）的简化版本。根据我的经验，如果你不认为它是RDM的简化版本，它可以被用得更加有益。

ER和RDM之间的一个区别是什么？在RDM中，多对多关系需要一个中间的联接框。此联接框保存外键，将联接框与多对多关系中的参与者连接起来。

在ER中，当严格应用时，交汇框在多对多关系中是不必要的。你只需将关系表示成一条线，并在线的两端指示“多”的可能性。事实上，ER图根本不需要外键。通过外键进行链接的概念可以在与大多数用户的讨论中省略。

数据规范化对于ER图表毫无关系。一个精心构建的ER图表中将极少出现有害冗余，但这主要是偶然而不是仔细规划的结果。

"利益相关方导向的ER图中的“实体”和“关系”应仅包括主题专家所理解的实体，而不包括在逻辑数据库设计过程中添加的实体或关系。"

应存储在数据库中并随需求提供的价值可以与属性关联，属性反过来可以与实体或实体之间的关系相互关联。此外，属性可以与域相关联，即每个属性可以具有的可能值的集合。存储在数据库中的某些值，如外键，应该在大多数利益相关者的讨论中省略。

了解数据的利益相关者通常对这些概念有直观的了解，尽管“实体”、“关系”、“属性”和“域”这些术语可能对他们来说不太熟悉。不理解主题数据的利益相关者需要特殊处理。

ER模型和图表的美妙之处在于，它们不仅可以用于讨论数据库中的数据，还可以将数据呈现给用户可见的形式。如果您有任何利益相关者不理解表格和表格填写，我的建议是，如果可能的话，尝试将他们远离计算机。

通过一个相对机械的过程，将一个构建良好的ER图转化为相对良好的关系模式是可能的。更具创造性的设计过程可能会产生逻辑上等效但更好的模式。一些技术利益相关者需要了解关系模式，而不仅仅是ER图。不要向不需要了解的人展示关系模式。

好的，回答你的问题：不不，一千遍的不！与用户讨论数据库模式是不应该的；一般来说，你与一头奶牛讨论微积分没什么区别。即使他们有技术背景，下次需求变化时他们也应该参与模式更新吗？

更一般地说，这听起来像是技术领导让问题与“客户”或利益相关者脱节的情况。 如果你正在被要求实际上“修复”问题，我建议你需要建立某种GUI原型，甚至只是一个故事版，并通过“那个”步入其中。然后你就会有一个了解情况的想法。

扩展：是的，项目中讨论DB架构是正常的。我会说你需要认真考虑与领导进行一些重要的咨询。

"更广泛的说：我理解你的观点，但问题在于数据库架构是一种实现细节。我们太习惯于数据库，以至于失去了这一点，最终开发出的应用看起来像是数据库。但是，数据库并不是提供客户价值的东西，最重要的是用户能否实现他们想做的事情。如果将客户看到应用程序的方式与数据库模式绑定在一起，那么您就将其绑定到一个实现上；例如对表进行去规范化以使系统更加高效等更改，就成为您必须向客户展示的东西。最好向客户展示可观察到的事物，并把这些细节留给自己。"

但我怀疑我们也在术语上出现了冲突。我会同意你关于“域模型”的观点。如果你所说的 db 模式只是指用户在系统中可见的那些表和关系，也就是所谓的“用例”，那么我们会达成一致。

嗯，首先你可能应该非常仔细地审查技术项目经理与她的赞助商之间的关系。当你后来暗示你可以解雇保护者时，我很惊讶你说技术项目经理受到了保护。她是受保护的还是不受保护的。如果你可以解雇保护者，那么她就没有受到保护。

所以听起来似乎没有人受到保护，更糟糕的是，没有人在沟通。我建议采取以下措施：召集主要项目经理、技术项目经理和开发人员开会。一旦在一起，依次询问每个人：“在本次练习中，不参考任何其他事物（即你不能因本次练习而责备其他任何人），请在5分钟内告诉我为什么我今天不应该解雇你”。

我意识到这是极端的建议，但您描述的是一个经典问题的可怕解决方案。这个项目的每个方面和最终的“代码”听起来都像灾难。您可能应该更加关注这个混乱的监督，但您没有（不管出于什么原因）。我意识到您应该期望雇用的PM级别的专业人员做得比这更好。

因此，我建议严格改组团队。一旦你让他们感到失业的恐惧（并告诉他们你正在为每个人撰写沟通失败报告），那么就要求他们发布即时沟通改进计划，并在本周末前制定详细的解决计划。

然后起身行动，因为你现在是该项目的首席项目经理。

如果他们能整顿并在这场灾难中挽回局面，那么就可以慢慢增加他们的责任。如果不行……总有一扇门。

干杯 (gān bēi)

Sorry, but "R" is not a word or phrase that can be translated into Chinese. It is advised to provide the complete sentence or context in order to accurately translate it into Chinese.

the lead pm suggested that the exact functionality desired exists in several proprietary projects (several of which are open source - bugtracker, bugzilla, etc.), but the tech pm and dev wouldn t listen.

如果这是真的，请告诉主要负责项目经理要更加果断;然后告诉他/她安装Bugzilla并解决问题。如果技术负责项目经理和开发人员因为固执而不听，他们需要进行一番交流......

无论如何，我认为你的组织存在问题...因为“不是内部开发”而失去了多少千元？然而，考虑到它已经到达实施阶段，问题比开发水平更上游...

就讨论数据库架构而言，我会说不需要。只有在收集了应用要求之后，可以积极contribut的人参与其中。

哇，听起来像是一场灾难。让我按顺序解决你的问题：

1. 首先，人们在熟悉的语言环境中发展。如果有更好的选择，但某人仍然喜欢旧的环境，那这就是他们不愿意学习新技能的明确信号。

2. 数据验证可以防止人们走得太远，只发现自己走进了死胡同。缺乏验证意味着开发者没有考虑到用户。此外，这不是在最后添加的东西...它不会简单地工作。

3. Web的“对话框”无法像您想的那样“模态”。但是，弹出一个额外的窗口非常容易。页面上的帮助应该几乎总是使用这种弹出窗口。

4. 数据验证应该永远不要离开输入数据的页面 - 这是可怕的用户界面设计。

5. 数据库模式大概是你所面对问题里最小的一部分。如果开发人员负责提供功能，并且在数据模式设计方面表现出色，那么我不认为和主管PM讨论这个模式的微妙差别是至关重要的。它应该在各个代码层面的利益相关者中讨论，而且必须能够处理工作需求。然而，从PM的角度来看，重要的不是模式本身，而是运营方面。当然，如果你对开发人员构建良好的数据库模式的能力没有信心，那就无法保证一切了。

6. 如果你真的不知道DBMS是什么，那你可能有严重的问题。你有标准吗？如果扩展项目中的其他人都在使用MS SQL Server，而这个人选择了Oracle，你如何将专业知识和员工转移到这个项目中或者该项目的其他项目中？这表明组织失去了控制。

7. 忽略专有替代产品有两个原因。第一，它们可能不真正符合您的需求。其次，技术PM和开发人员可能只是在闲混，或者使用一些并非在这里发明的理由来浪费您的资源。问题在于，您可能没有足够的洞察力，无法辨别两者之间的区别。

8. 关于解雇开发人员...是否可以通过赞助一些额外的培训来帮助他？如果这个人除此之外是一个好员工并且熟悉你的业务，当只需要给他一个正确的方向时，我会非常犹豫解雇他们。

9. Tech PM听起来似乎并没有做好她的工作。她是指出我正在写的缺陷并推动改进的合乎逻辑的人。关于她的职位，真正的问题是她是否能够学会成为更好的倡导者，为您的组织利益辩护。

10. 首席项目经理也听起来太被动了。上面对技术项目经理的评论同样适用于这里。

11. 如果Bugtracker等确实起作用，那么沿这条路线走就有意义。 但是，你可能想更加谨慎地解雇人员。

首先，我同意Charlie Martin关于数据库架构的观点。

其次

这听起来开发项目的人是很新手-这是他/她的第一份编程工作吗？如果是的话，我只会在他们的简历上写得不一样的情况下解雇他们。

我不知道技术负责人/技术项目经理在项目中应该承担多大的责任，但听起来责任排序是 开发人员 > 技术项目经理 > 主管项目经理。如果是这种情况，那么技术项目经理完全没有履行其职责。你可能想弄清楚为什么会失误，并根据这个解雇/留用她，但在我工作的地方，这样的失败任务是需要受到惩罚的。

最后，我认为，“保护”这个东西是扯淡的 - 你需要根据他们的质量和价值，而不是谁是他们的姑姑，来奖励和惩罚人们。

祝你好运！干杯！

哇，我感受到你的痛苦。

在我看来，你问题的根源是一位“受保护”的技术项目经理。她为什么受保护，是由谁保护的？我曾经参与过一个项目，这个公司的CEO的秘书先成为了业务分析师，然后（在CEO离职后）成为了项目经理，因为他们有了一段什么情况我就不说了的情缘。她不知道我们使用的编程语言，认为需求分析是浪费时间。由于有一个组织内最高级别的人士保护她，唯一的真正解决方案是另寻就业。

你似乎认为你可以解雇她和她的保护者所以可能是比你低但高于领导PM的某个人，因此他无能为力，但你可以吗？是的，你应该解雇他们两个。

领导项目经理可能可救可息，这要看他所依赖的保护人是谁。他可能会处于左右为难的境地，他知道该怎么做，但由于技术项目经理和她的保护人之间的关系性质，他无法对她和她的下属施加影响。我曾经处于这样的境地，我的两个老板与我的一名下属有染，这造成了各种组织混乱（这就是为什么保护人必须被解雇以及技术项目经理）。给他一些信任，与他讨论，如果技术项目经理和她的保护人被赶走了，他会怎么处理。如果你喜欢他的回答，你可以留下他，但组织上，你需要介入并确保他是掌控大局的人，任何人都不允许忽视他。一旦领导失去了权威，只有得到管理层的坚定支持，才能重新获得权威。

我将与主管和开发人员坐下来，详细解释项目当前存在的不可接受之处。如果开发人员感觉无法接受来自主管（假设你决定保留他）的指令，或者无法适应新的业务方式，或者无法理解目前的代码为什么被认为是不可接受的，那么放弃他是明智的选择。如果能挽救，新人更有可能为主管效力，因为他不会有不听从主管的历史。

I wouldn t necessarily think that the db schema should always be shared with stakeholders. Most people wouldn t know what to do with that sort of information. If you re trying to make sure that the product fits the requirements, the requirements should be clearly laid out up front and verified throughout the development of the project.

如果您的开发遇到问题，那只是常有的事情。应该找到更为可靠的人选。如果您雇佣了一位糟糕的程序员，那是您的错误。

有几个可能的解决方案：

• Get a better coder. He ll hate working through all the bad code but hopefully he ll slug through it till it s done. Hopefully you re willing to pay him good money.
• Keep the coder and make him fix it all. Hire a new PM that can manage him better. That coder knows his code best and it might take less time for him to just improve it. In the long run, you re better off not keeping a bad coder on payroll so lose him when you re done.
• Suck it up, buy a beer for everyone involved and start over with opensource. You ll probably still need a tech PM to manage the software. You ll also have to forget about doing anything custom at that point. Perhaps a contractor could manage this.

Either way, you re gonna lose some money. Should probably keep a closer eye on things next time.

我倾向这样想。数据库架构的存在是为了支持应用程序的数据存储需求。应用程序需要存储哪些数据将取决于最终用户的需求。如果您没有咨询最终用户有关应用程序需求的要求，那么显然您将面临麻烦，但是只要您充分了解他们的需求（以及可能的未来需求），那么数据库架构是一个可以由项目团队在没有最终用户/客户直接输入的情况下做出的技术决策。

An end user is unlikely to understand the intricacies of tables, fields, normalization, etc, but they ll understand "the system needs to do xyz". Talk to the end users in a language they understand, and let your team make the appropriate technical decisions.

My big question is about the relationship between the lead pm and the tech pm s protector: did the lead pm have good reason to fear retaliation from the protector? It s entirely possible that he felt unable to do anything until the situation got bad enough that it was clearly important for people above the protector. In that case, he doesn t deserve any more harsh treatment.

The tech pm is apparently incompetent at her job, and her protector is more interested in favoring her than getting the work done. That suggests to me that they need to be dealt with in some fashion, at minimum with a talk about the importance of getting real work done, at maximum firing both of them.

The dev is likely hunkered down, trying to survive politically, given the climate you ve outlined. I can t tell enough about the dev to give any advice.

Therefore, if your description and my amazing psychic powers have given me a clear and accurate picture:

Shield the lead pm from retaliation, and tell him to ditch all the crud and implement an off-the-shelf solution. (If he can t select one himself reliably, he shouldn t be lead pm.)

Discipline the tech pm and her protector. You really don t want to have people wrecking enterprise productivity that way.

The dev is the lead pm s responsibility. Leave it at that. Don t micromanage more than you have to. Have a couple of beers. Get back to your usual work.