我比参与项目的人要高几层/级别。我将要描述。
一般要求是基于Web的问题管理系统。该系统是更大项目的一小部分。
领导下午有一个技术人员应该处理这部分项目。领导下午问我，帮助信息是否正常，不在请求帮助的位置。领导下午提供有关网站的反馈，并希望模态对话框等错误消息，并希望我看一看。我在看系统，我在想......
我有两个问题？
我
并不是在项目的早期就讨论和严格考虑db模式的SOP吗？
编辑：
我曾经与各种各样的客户合作，他们拥有不同程度的技术知识（和智能）。我总是与利益相关者讨论db模式。如果他们不知道架构是什么，我会教他们。如果他们没有理解的背景，我仍然会与他们讨论架构 - 即使他们没有意识到我们正在谈论架构。在我直接参与的大多数项目中，数据是系统中最重要的部分。彻底挖掘模式/域模型对于深入了解系统以及可以执行和报告的内容至关重要。我非常重视关于SO的海报的意见。值得注意的是，我的方法不是通常的做法。
BTW - 令人遗憾的是，该项目使用纳税人资金，IT部分是与着名大学的合作......开发人员和技术人员都是长期雇员 - 他们并非缺乏经验。当我知道那些失业的聪明而勤劳的人和那些像这样的人一起工作时，我感到特别难过。当我年轻时，我会向链上报告这种无能，并期待采取适当的行动。现在我已经处于连锁状态，我发现自己不想微观管理其他人的责任。
我的决心是要喝两瓶啤酒并回到我的职责......
答案 0 :(得分：5)
好的，第一件事，回答你的问题：不，不，千万不！用户不是你应该讨论db schemata的人;一般来说，你也要和奶牛讨论微积分。即使他们具有技术背景，下次需求变化时又如何;他们应该参与架构更新吗？
更一般地说，这听起来像是技术主管让问题与“客户”或利益相关者脱节的情况。如果您被要求实际修复问题，我建议您需要构建某种类型的GUI原型，甚至可能只是一个故事板，并遍历 >。那么你就会知道事情的发展方向。
扩展：是的，讨论项目中的数据库架构是正常的。我要说你确实需要认真思考一些主要的咨询工作。
扩展更多：我理解您的观点，但问题是数据库架构是一个实现细节。我们已经习惯了数据库，我们让自己失去了对它的追踪，并最终得到了看起来像数据库的应用程序。但数据库不是提供客户价值的东西;客户是否可以做他们想要的事情。如果您将客户看到应用程序的方式与数据库模式联系起来，那么您将它们绑定到一个实现;为了使系统更加高效，更改（例如非规范化表格）会成为您必须向客户展示的内容。最好向他们展示可观察的内容，并将这些细节留给自己。
但我怀疑我们也有一个术语冲突。我会就“域名模式”与你达成一致。如果，通过db模式，您只是表示在用户的系统视图中可见的那些表和关系，如果您愿意，则使用“用例”，那么我们将同意。
答案 1 :(得分：3)
应与利益相关方讨论数据，绝对是的。除了在特殊情况下，利益相关者都是“精通数据库”，不应与利益相关者讨论数据库模式。
那么如何在不讨论DB Schema的情况下讨论DATA？这是我为实体关系（ER）图和一般的ER模型找到的主要用途。许多数据库设计者倾向于将ER视为关系数据建模（RDM）的淡化版本。根据我的经验，如果你不认为它可以淡化RDM，它可以更有利可图。
ER和RDM有什么区别？在RDM中，多对多关系需要中间的接线盒。此接线盒包含将接线盒链接到多对多关系中的参与者的外键。
在ER中，严格应用时，在多对多关系中不需要接线盒。您只需将关系指示为一条线，并指示该线两端“很多”的可能性。事实上，ER图根本不需要外键。通过外键进行链接的概念可以在大多数用户的讨论中排除。
数据规范化与ER图表完全无关。精心构建的ER图将在其中具有非常少的有害冗余，但这在很大程度上是偶然的，而不是精心规划的结果。
面向利益相关者的ER图中的“实体”和“关系”应仅包括主题专家理解的实体，而不包括在逻辑数据库设计过程中添加的实体或关系。
要保存在数据库中并按需提供的值可以连接到属性，而属性又可以连接到实体或实体之间的关系。此外，属性可以绑定到域，每个属性可以承担的可能值集。存储在数据库中的一些值，如外键，应该被排除在与大多数利益相关者的讨论之外。
了解数据的利益相关者通常对这些概念有直观的把握，尽管术语“实体”，“关系”，“属性”和“域”可能对他们来说并不熟悉。不了解主题数据的利益相关者需要特殊处理。
ER模型和图表的美妙之处在于，它们不仅可用于在数据库中讨论数据，还可用于在用户可以看到的表单中显示数据。如果您有任何不了解表格和表格填写的利益相关者，我的建议是您试图让他们远离计算机，如果仍然可以。
通过相当机械的过程，可以将构建良好的ER图转换为适度构建良好的关系模式。更具创造性的设计过程可能会产生逻辑上等效的“更好”模式。一些技术利益相关者需要了解关系模式，而不仅仅是ER图。不要向不需要知道它的人显示关系模式。
答案 2 :(得分：2)
嗯，首先你应该仔细检查技术pm和她的赞助商之间的关系。当你后来暗示你可以解雇保护者时，我很惊讶你说技术pm受到保护。无论是她，还是她都没有受到保护。如果你可以开火保护器，那么她就不会受到保护。
所以听起来没有人受到保护，更糟糕的是 - NO-ONE正在进行沟通。我建议如下：与领导pm，技术人员和开发人员召开会议。在一起之后，依次询问每个人：“除了你的工作之外没有引用任何东西（也就是你在这个练习期间不能责怪其他人），请在5分钟或更短时间内告诉我为什么我今天不应该解雇你”。
我意识到这是极端的建议，但你已经描述了一个经典问题的可怕解决方案。该项目的每个方面以及由此产生的“代码”听起来都像是一场灾难。你可能应该更多地监督这个烂摊子，但你没有（无论出于何种原因）。我意识到你应该期望PM级别的雇佣专业人员做得比这更好。
因此我建议对团队进行彻底的改组。一旦你把失业的恐惧放在桌子上（我告诉他们你写的是每个人都没有沟通），然后要求他们发布立即沟通改善的计划PLUS详细的时间表来解决这个问题。本周末。
然后自行乞讨，因为你现在是这个项目的LEAD领导PM。
如果他们在这次灾难中成型并卷土重来，那么就慢慢开始增加他们的责任。如果不是......总会有一扇门。
干杯，
-R
答案 3 :(得分：0)
导致pm建议确切 所需的功能存在于 几个专有项目（几个 其中是开源的 - bugtracker， bugzilla等），但技术pm和 开发者不会听。
如果这是真的，请告诉导致pm更加自信;然后告诉他/她安装bugzilla并完成它。如果技术人员和开发人员因为顽固而没有听，他们需要一点聊天......
无论哪种方式，我都会说你的组织有问题......因为“这里没有开发”的案例，已经损失了数千美元？但是，鉴于它已达到实施的目的，上游的问题比发展水平还要高......
至于与每个人讨论db模式，我会说不。在收集申请要求后，所有能够积极参与的人都应参与其中。
答案 4 :(得分：0)
首先，人们用他们觉得舒服的语言发展。如果有人在较旧的环境中仍然感觉舒适，那么存在更好的替代方案，这肯定表明他们对获得技能的兴趣不大。
数据验证可以防止人们走得太远而只是发现它是一条死胡同。缺乏验证意味着开发人员不会考虑用户。此外，不在最后添加的内容......它根本不起作用。
在你想到的意义上，网络“对话框”不能是“模态的”。但是，弹出一个额外的窗口很容易。页面上的帮助几乎总是使用这种弹出窗口。
数据验证不应该从输入数据的页面导航 - 这是一个糟糕的UI设计。
数据库架构是您遇到的最少问题。如果开发人员负责提供功能并且明显胜任数据模式设计，我认为与主要PM讨论模式的细微差别并不重要。 应在各种代码级别的利益相关者之间进行讨论，并且必须能够处理工作的要求。然而，从PM的角度来看，重要的不是架构，而是运营方面。当然，如果你不相信开发人员构建一个好的数据库模式的能力，那么所有的赌注都会被取消。
如果您真的不知道dbms是什么，那么您可能会遇到严重问题。你有标准吗？如果扩展项目中的其他人都在使用MS SQL Server并且这个人选择了Oracle，那么如何将专业知识和人员转入或转出该项目？这是组织失控的标志。
忽略替代专利产品有两个原因。首先，它们可能无法真正满足您的需求。其次，技术总监和开发人员可能只是羽毛衬托或参与一些令人讨厌的“不在这里发明”的理由来浪费你的资源。问题是你不可能在你的水平上有足够的洞察力来了解两者之间的区别。
关于解雇开发......是否有可能通过赞助一些额外的培训来帮助他？如果这个人本来就是一个好雇员并且对你的生意很了解，那么当我需要的只是向正确的方向努力时，我会非常犹豫要解雇他们。
技术总理听起来她真的没有做好自己的工作。她是指出我正在撰写的有关缺陷并推动改进的合乎逻辑的人。从她的立场来看，真正的问题是她是否能够学会更好地为自己的组织利益做出贡献。
领导PM听起来也太被动了。以上关于技术PM的评论也适用于此。
如果bugtracker等确实有效，那么走这条路是有意义的。但是，您可能希望对解雇人员更加谨慎。
答案 5 :(得分：0)
首先，我同意查理·马丁关于数据库架构的信息。
第二，
听起来这个项目的开发人员非常环保 - 这是他/她的第一份编程工作吗？如果是这样的话，我只会在他们的简历说出其他内容时解雇开发者。
我不知道领导/技术pms在项目中的参与程度如何，但听起来责任是开发＆gt; tech pm＆gt;领导下午。如果是这样的话，技术人员就完全放弃了球。你可能想知道为什么球被丢弃并且根据这一点开火/保留她，但像这样的拙劣工作是我工作的谴责时间。
最后，imho，“保护”的东西是b.s. - 你需要根据他们的品质和价值来奖励和训斥人，而不是姨妈是谁。
祝你好运！干杯！答案 6 :(得分：0)
哇。我感觉到你的痛苦。
向我看，好像问题的第一个来源是“受保护”的techPM。她为什么受到保护？我曾经参与过一个项目，首席执行官的秘书首先成为商业分析师，然后（在他辞职后）项目经理，因为他们有外遇。她不知道我们编写了什么语言，并且认为要求是浪费时间。由于她在组织中受到尽可能高的人的保护，唯一真正的解决方案是寻找其他地方就业。
你似乎认为你可以解雇她和她的保护者，所以它可能是低于你的人但高于领先PM，所以他无法做任何事情，但你可以吗？是的，你应该解雇他们两个。
根据保护者的身份，铅PM可能会或可能不会被抢救。他本来可以在一块岩石和一个他知道该怎么做的地方之间，但由于技术人员和她的保护者之间关系的性质，她无法对她和向她报告的人施加任何影响。有一次，我的两位老板与我的一位下属发生了暧昧关系，并且造成了各种组织的破坏（这就是为什么保护者必须和技术PM一起被解雇的原因）。给他带来疑问的好处，并与他讨论如果技术人员和她的保护者不在路上他将如何处理不同的事情。如果你喜欢你所听到的，你可以保留他，但在组织上你需要介入并确保这个人是明确的，并且没有人会被允许忽略他。一旦领导失去了权威，他只能在管理层的强力支持下取而代之。
我还会与主管和开发人员坐下来，并准确解释项目目前的不可接受的情况。如果开发人员觉得无法从主导方向（假设您决定留住他）或无法适应新的业务方式或无法理解为什么代码现在是不可接受的，那么就减少损失并摆脱他也是。如果一个新人可以挽救，他可能会更好地为领导工作，因为他不会有无视他的历史。
答案 7 :(得分：0)
我不一定认为应始终与利益相关者共享数据库模式。大多数人不知道如何处理这类信息。如果您正在努力确保产品符合要求，则应在项目开发过程中明确预先确定要求并进行验证。
如果你遇到了开发方面的问题，这只是课程的标准。应该找到一个更值得信赖的人。如果你聘请了一个糟糕的程序员，这就是你的错误。
有几种可能的解决方案：
无论哪种方式，你都会失去一些钱。下次应该密切关注事情。
答案 8 :(得分：0)
我倾向于这样想。数据库模式用于支持应用程序的数据存储要求。应用程序需要存储的数据将由最终用户的要求决定。如果您没有向最终用户咨询他们对应用程序的要求，那么您显然会遇到麻烦，但如果您能够很好地处理他们的需求（以及可能的未来需求），那么数据库架构是一个技术决策，可以是由项目团队制作而无需最终用户/客户的直接输入。
最终用户不太可能理解表，字段，规范化等的复杂性，但他们会理解“系统需要做xyz”。用他们理解的语言与最终用户交谈，让您的团队做出适当的技术决策。
答案 9 :(得分：0)
我的一个大问题是关于领导者和技术人员的保护者之间的关系：导致下午有充分理由害怕保护者的报复吗？完全有可能他感到无法做任何事情，直到情况变得糟糕，这对保护者以上的人显然很重要。在那种情况下，他不应该受到更严厉的待遇。
技术人员显然无能为力，她的保护者更愿意支持她而不是完成工作。这告诉我，他们需要以某种方式处理，至少谈论完成实际工作的重要性，最大限度地解雇他们。
考虑到你所概述的气候，开发者可能会陷入困境，试图在政治上生存。我无法详细说明开发人员给出任何建议。
因此，如果你的描述和我惊人的精神力量给了我一个清晰准确的画面：
保护领导免受报复，并告诉他放弃所有的污点并实施现成的解决方案。 （如果他不能可靠地选择一个，他就不应该是领导。）
训练技术人员和她的保护者。你真的不希望让人们以这种方式破坏企业生产力。
开发是领导下午的责任。把它留在那。不要超过你需要的微观管理。喝几杯啤酒。回到平时的工作。