开发新系统时,是否应始终与利益相关者讨论db模式?

好的,首先,回答你的问题:不,不,一千次不!用户不是您应该与之讨论db模式的人;一般来说,你最好和一头牛讨论微积分。即使他们有技术背景,下一次需求发生变化时会怎样;他们应该参与模式更新吗?

更一般地说,这听起来像是技术领导让问题与“客户”或利益相关者失去联系的情况。如果你被要求 修理 问题是,我建议您需要构建某种类型的GUI原型,甚至可能只是一个故事板,然后进行演练 那个 . 然后你就会知道事情的进展了。

扩展更多

但我怀疑我们也有术语冲突。我会同意你关于“域模型”的观点。如果说db模式,你指的是用户在系统视图中可见的那些表和关系,“用例”,如果你愿意,那么我们就同意了。

数据应该与利益相关者讨论,绝对是的。数据库模式不应与涉众讨论,除非在特殊情况下,涉众都“精通数据库”。

ER和RDM之间的一个区别是什么?在RDM中,多对多关系需要中间的接线盒。此接线盒包含将接线盒链接到多对多关系参与者的外键。

在ER中,严格应用时,接线盒在多对多关系中是不必要的。您只需将关系表示为一行,并在行的两端表示“多”的可能性。事实上,ER图根本不需要外键。通过外键进行链接的概念可以从与大多数用户的讨论中排除。

数据规范化与ER图完全无关。一个构建良好的ER图中几乎没有有害的冗余,但这在很大程度上是偶然的,不是精心规划的结果。

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

要保存在数据库中并按需提供的值可以连接到属性,而属性又可以连接到实体或实体之间的关系。此外,属性可以绑定到域,即每个属性可以采用的一组可能值。存储在数据库中的一些值,如外键,应该在与大多数涉众讨论时忽略。

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

ER模型和图表的美妙之处在于,它们不仅可以用来讨论数据库中的数据,还可以用来讨论以用户可以看到的形式出现的数据。如果您有任何利益相关者不了解表单和表单填写,我的建议是,如果仍然可行,您应尽量让他们远离计算机。

首先,你可能应该非常仔细地回顾一下技术pm和她的赞助商之间的关系。我很惊讶你说技术pm是受保护的,而你后来暗示你可以解雇保护者。要么她是,要么她没有受到保护。如果你能解雇保护者,那么她就得不到保护。

我知道这是一个极端的建议,但你描述了一个经典问题的可怕解决方案。这个项目的每个方面以及由此产生的“代码”听起来都像是一场灾难。你本应该在这场混乱的监督中发挥更大的作用,但你没有(出于任何原因)。我意识到你应该期望PM级别的雇佣专业人员做得更好。

如果他们在这场灾难中恢复元气,然后慢慢地开始重新增加他们的责任。如果不是。。。总有一扇门。

干杯

-R

首席首相建议 中存在所需的功能 几个专有项目(几个) 其中包括开源的bugtracker, bugzilla等),但技术pm和 德夫不听。

如果这是真的,告诉首席pm要更加自信;然后告诉他/她安装bugzilla并完成它。如果技术pm和dev因为固执而没有听,他们需要一点聊天。。。

不管怎样,我都会说你的组织有问题。。。有多少数千美元的损失是因为一个案件“不是在这里发展”?然而,考虑到它已经达到了实施点,在发展水平的上游还存在一些问题。。。

至于与每个人讨论db模式,我会说不。在收集了应用程序需求之后,所有能够做出积极贡献的人都应该参与进来。

哇,听起来像是一场灾难。让我粗略地谈谈你的观点:

1. 首先,人们用他们觉得舒服的语言发展。如果一个人在一个旧环境中仍然感到舒适,而有更好的替代品存在,这无疑是一个迹象,表明他们对获得技能没有兴趣。

2. 数据验证可以防止人们走得太远而发现这是一条死胡同。缺乏验证意味着开发人员没有考虑用户。而且是 不 在最后加上的东西…根本不起作用。

3. 网络“对话”不能是你所思考的意义上的“模态”。然而,弹出一个额外的窗口是很容易的。页面上的帮助几乎应该总是使用这种弹出窗口。

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

5. DB模式是您遇到的最小问题。如果开发人员负责交付功能,并且在数据模式设计方面很有能力,我认为与首席PM讨论模式的细微差别并不重要。信息技术 应该 在不同的代码级涉众之间进行讨论,并且必须能够处理工作的需求。然而,从PM的角度来看,重要的不是模式,而是操作方面。当然,如果您对开发人员构建良好的db模式的能力没有信心,那么所有的赌注都没有了。

6. 如果您真的不知道dbms是什么,那么您可能会遇到严重的问题。你有标准吗?如果扩展项目中的其他所有人都在使用MS SQL Server,而这家伙选择了Oracle,那么您如何将专业知识和员工转移到该项目中或从中转移出去?这是一个组织失控的迹象。

7. 忽视替代专利产品有两个原因。首先,它们可能无法真正满足您的需求。其次,技术项目经理和开发人员可能只是为了浪费你的资源而编造或参与一些令人讨厌的“这里没有发明”的理由。问题是,在你的水平上,你不太可能有足够的洞察力来了解两者之间的区别。

8. 关于解雇开发人员…有没有可能通过赞助一些额外的培训来帮助他?如果此人在其他方面是一名优秀的员工,并且对您的业务非常了解,那么当需要朝着正确的方向努力时,我会非常犹豫是否解雇他们。

9. 这位技术首相听起来好像真的没有做好自己的工作。她是一个合乎逻辑的人,能够指出我所写的缺陷并推动改进。相对于她的职位,真正的问题是她是否能学会更好地为你的组织利益辩护。

11. 如果bugtracker等真的有效,那么走这条路是有意义的。然而,在解雇员工时,你可能需要更加谨慎一点。

首先,我同意Charlie Martin关于db模式的观点。

第二

我不知道领导/技术PM在项目中的参与程度如何,但听起来责任似乎是dev>技术pm>领导项目经理。如果是这样的话,那么技术pm就完全失球了。你可能想知道为什么球掉了,并以此为基础解雇/留住她,但像那样糟糕的工作是对我工作时间的谴责。

最后,imho,“保护”的东西是b.s.-你需要根据人们的素质和价值来奖励和谴责他们,而不是他们的姑妈是谁。

祝你好运干杯

在我看来,您的问题的第一个根源似乎是“受保护”的techPM。她为什么受到保护,由谁保护?我曾经参与过一个项目,首席执行官的秘书首先成为业务分析师,然后(在他辞职后)成为项目经理,因为他们有外遇。她不知道我们用什么语言编程,认为需求是浪费时间。由于她受到组织中尽可能高的人的保护,唯一真正的解决办法就是到别处找工作。

你似乎认为你可以解雇她和她的保护者,所以可能是比你低但高于首席首相的人,所以他对此无能为力,但你可以?是的,你应该解雇他们两个。

根据保护人的身份,潜在PM可能无法抢救。他可能处于岩石和坚硬的地方之间,他知道该做什么,但由于技术首相和她的保护者之间的关系的性质,他无法对她和向她报告的人施加任何影响。有一次,我的两个老板与我的一个下属发生了风流韵事,这造成了各种组织混乱(这就是为什么必须解雇保护者和技术PM的原因)。让他从怀疑中受益,并与他讨论如果技术pm和她的保护者不碍事,他将如何以不同的方式处理事情。如果你喜欢你所听到的,你可以留住他,但在组织上你需要介入,确保这个人是负责人,任何人都不允许忽视他。一旦领导失去了权威,他只有在管理层的大力支持下才能重新获得权威。

我还将与负责人和开发人员坐下来,确切地解释项目中目前无法接受的内容。如果开发人员觉得无法从领导那里获得指导(假设您决定保留他),或者无法适应新的业务方式,或者无法理解为什么现有的代码是不可接受的,那么减少您的损失,并摆脱他。如果一个新人能够挽救,他可能会更好地为领导工作,因为他不会有忽视他的历史。

我不一定认为db模式应该总是与涉众共享。大多数人都不知道如何处理这类信息。如果您试图确保产品符合需求,那么在项目开发的整个过程中,需求应该被清楚地预先列出并验证。

如果你在DEV上遇到问题,这只是课程的标准。应该找到更值得信任的人。如果你雇佣了一个差劲的程序员,那就是你的错误。

• 找一个更好的编码员。他会讨厌处理所有糟糕的代码,但希望他能慢慢处理,直到完成为止。希望你愿意付给他一大笔钱。
• 留下编码员,让他把一切都搞定。请一位能更好地管理他的新PM。那个程序员最了解自己的代码,可能只需要花更少的时间来改进它。从长远来看,你最好不要在工资单上留下一个不好的编码员,所以当你完成的时候就把他丢了。
• 吸吮它,为每个参与的人买一杯啤酒,然后用开源重新开始。您可能仍然需要一名技术PM来管理软件。你还必须忘记在那一点上做任何定制的事情。也许一个承包商可以做到这一点。

不管怎样,你都会损失一些钱。下次可能应该密切关注事情。

我倾向于这样想。数据库模式用于支持应用程序的数据存储需求。应用程序需要存储哪些数据将由最终用户的需求决定。如果您没有就最终用户对应用程序的需求咨询他们,那么您显然会遇到麻烦,但前提是您能够很好地处理他们的需求(以及可能的未来需求),那么数据库模式是一个技术决策,项目团队可以在没有最终用户/客户直接输入的情况下做出此决策。

最终用户不太可能理解表格、字段、规范化等的复杂性,但他们会理解“系统需要执行xyz”。用最终用户理解的语言与他们交谈,让您的团队做出适当的技术决策。

我的大问题是关于首席pm和技术pm的保护者之间的关系:首席pm有足够的理由害怕保护者的报复吗?他完全有可能感到无能为力,直到情况变得足够糟糕,这显然对保护者之上的人很重要。在这种情况下,他不应该受到更严厉的待遇。

鉴于您所概述的气候,开发人员可能会蹲下来,试图在政治上生存。关于开发人员,我无法给出足够的建议。

因此,如果你的描述和我惊人的精神力量给了我一个清晰准确的画面:

开发人员是项目经理的主要职责。就这样吧。不要过度地进行微观管理。喝两杯啤酒。回到你平常的工作。