2

我比我将要描述的项目所涉及的人员高出几个层次/级别。

一般要求是基于 Web 的问题管理系统。该系统只是一个更大项目的一小部分。

领导 pm 有一个技术 pm，他应该处理项目的这一部分。领导下午问我，帮助信息不在请求帮助的上下文中是否正常。领导 pm 正在提供有关该站点的反馈，并希望提供模式对话框等错误消息，并希望我看一下。我在看系统，我在想……

  • 在冷聚变中开发了一个新应用程序！？！？
  • 该应用程序的数据验证极差
  • 应用数据验证页面远离数据输入表单
  • 应用程序帮助页面导航离开表单
  • 开发人员和 pm 之间没有讨论 db 模式
  • 未讨论 db 架构，因为它不存在
  • 有一个菜单页面——也就是说，一旦你进入一个页面，你必须回到主菜单，然后进入你想要的下一页
  • 领导 pm 不知道 dbms 是什么...
  • 有一个技术 pm，她不知道什么是 dbms...
  • 领导 pm 想解雇技术 pm 很长时间了，但技术 pm 受到保护……
  • 领导 pm 建议在几个专有项目中存在所需的确切功能（其中几个是开源的 - bugtracker、bugzilla 等），但技术 pm 和开发人员不会听。

我有两个问题？

难道我

  • 解雇开发人员？
  • 解雇技术经理和保护她的人？
  • 解雇铅下午？
  • 为他们下载并配置 bugtracker/bugzilla，然后全部启动？
  • 为他们下载并配置 bugtracker/bugzilla，然后去喝杯啤酒忘忧？

数据库模式不是在项目的早期就被讨论和严格考虑的标准操作程序吗？

编辑：

我曾经与各种技术知识（和智力）水平不同的客户一起工作。我总是与利益相关者讨论数据库模式。如果他们不知道什么是模式，我会教他们。如果他们没有理解的背景，我仍然会和他们讨论模式——即使他们没有意识到我们在谈论模式。在我直接参与的大多数项目中，数据是系统中最重要的部分。彻底散列模式/域模型对于更好地理解系统以及可以完成和报告的事情至关重要。我非常重视海报上关于 SO 的意见。有趣的是，我的方法不是通常的做法。

顺便说一句 - 可悲的是，该项目使用纳税人的资金，而 IT 部分是与一所著名大学的合作......开发和技术 pm 是长期员工 - 他们并不缺乏经验。当我知道聪明而勤奋的人失业而像这样的人有工作时，我感到特别难过。

当我年轻的时候，我会向上报告这种类型的无能，并期望采取适当的行动。既然我在链上，我发现自己不想微观管理其他人的责任。

我的决定是喝两杯啤酒，然后回到我的职责中......

4

10 回答 10

5

好的，首先要回答你的问题：不不，一千次不！用户不是您应该与之讨论数据库模式的人；一般来说，你最好和一头牛讨论微积分。就算他们有技术背景，下次需求变了怎么办？他们应该参与架构更新吗？

更一般地说，这听起来像是技术主管让问题与“客户”或利益相关者脱节的情况。如果您被要求实际解决问题，我建议您需要构建某种 GUI 原型，甚至可能只是一个故事板，然后逐步完成。然后你就会知道事情的发展方向。

扩展：是的，在项目中讨论数据库模式是正常的。我会说你确实需要认真考虑一些，嗯，与线索的主要咨询。

扩展更多：我理解你的意思，但问题是数据库模式是一个实现细节。我们已经习惯了数据库，以至于忘记了它，最终得到了看起来像数据库的应用程序。但是数据库并不是提供客户价值的东西。这是客户是否可以做他们想做的事情。如果您将客户查看应用程序的方式与数据库模式联系起来，那么您将它们与一种实现联系起来；更改，例如为了使系统更有效而对表格进行非规范化，成为您必须向客户展示的东西。最好向他们展示可观察的东西，并将这些细节留给我们自己。

但我怀疑我们也有术语冲突。我会同意你关于“域模型”的看法。如果通过 db 模式，您的意思是仅在用户的系统视图中可见的那些表和关系，如果您愿意，“用例”，那么我们会同意。

于 2008-12-29T22:29:20.667 回答
3

应该与利益相关者讨论数据，绝对可以。DB SCHEMA 不应与利益相关者讨论，除非在特殊情况下，利益相关者都“精通数据库”。

那么如何在不讨论 DB Schema 的情况下讨论 DATA 呢？这是我发现的实体关系 (ER) 图和一般 ER 模型的主要用途。许多数据库设计人员倾向于将 ER 视为关系数据建模 (RDM) 的淡化版本。根据我的经验，如果您不认为它是淡化的 RDM，它可以更有利地使用它。

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

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

数据规范化与 ER 图表完全无关。一个构建良好的 ER 图将几乎没有有害的冗余，但这在很大程度上是偶然的，而不是仔细计划的结果。

面向涉众的 ER 图中的“实体”和“关系”应该只包括主题专家理解的实体，而不包括在逻辑数据库设计过程中添加的实体或关系。

保存在数据库中并按需提供的值可以连接到属性，而属性又可以连接到实体或实体之间的关系。此外，属性可以绑定到域，即每个属性可以采用的一组可能值。一些存储在数据库中的值，比如外键，应该被排除在与大多数利益相关者的讨论之外。

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

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

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

于 2008-12-30T16:37:34.217 回答
2

好吧，首先您可能应该非常仔细地审查技术 pm 和她的赞助商之间的关系。当你后来暗示你可以解雇保护者时，我很惊讶你说技术 pm 受到保护。要么她是，要么她没有受到保护。如果您可以解雇保护者，那么她就没有受到保护。

所以听起来没有人受到保护，更糟糕的是——没有人在交流。我建议如下：召集与领导 pm、技术 pm 和开发人员的会议。一旦在一起，轮流问每个人：“除了你的工作之外，不要引用任何东西（即你不能在这个练习期间责怪任何人），在 5 分钟或更短的时间内告诉我为什么我今天不应该解雇你”。

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

因此，我建议对团队进行重大重组。一旦你把对失业的恐惧放在一张桌子上（我会告诉他们你正在为每个人写下沟通失败），然后要求他们发布立即改善沟通的计划以及解决混乱的详细时间表周末。

然后摆脱你自己的流浪汉，因为你现在是这个项目的 LEAD-lead PM。

如果他们在这场灾难中振作起来并卷土重来，然后慢慢地再次开始增加他们的责任。如果不是……总会有一扇门的。

干杯，

-R

于 2008-12-29T22:51:23.917 回答
0

领导 pm 建议在几个专有项目中存在所需的确切功能（其中几个是开源的 - bugtracker、bugzilla 等），但技术 pm 和开发人员不会听。

如果这是真的，请告诉领导 pm 更加自信；然后告诉他/她安装 bugzilla 并完成它。如果技术 pm 和开发人员因为固执而没有在听，他们需要聊一聊……

无论哪种方式，我都会说您的组织存在问题...由于“未在此处开发”的案例而损失了数千美元？但是，既然到了实现的地步，比开发层面更上游的问题……

至于与大家讨论数据库模式，我会说不。在收集到申请要求后，每个可以积极贡献的人都应该参与进来。

于 2008-12-29T22:39:33.377 回答
0

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

  1. 首先，人们使用他们觉得舒服的语言进行开发。如果有人在存在更好的替代方案的情况下仍能适应旧环境，这肯定表明他们对获得技能没有兴趣。

  2. 数据验证可以防止人们走得太远，却发现这是一条死胡同。缺乏验证意味着开发人员没有考虑用户。此外，它不是最后附加的东西......它根本不是那样工作的。

  3. 网络“对话”不能是您所想的意义上的“模态”。但是，弹出一个附加窗口很容易。页面上的帮助应该几乎总是使用这种弹出窗口。

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

  5. 数据库模式是您遇到的最少的问题。如果开发人员负责交付功能并且明显胜任数据模式设计，我认为与首席 PM 讨论模式的细微差别并不重要。它应该在各种代码级别的利益相关者之间进行讨论，并且它必须能够处理工作的需求。然而，从 PM 的角度来看，重要的不是模式，而是操作方面。当然，如果您对开发人员构建良好数据库模式的能力没有信心，那么所有的赌注都是错误的。

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

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

  8. 关于解雇开发人员……是否可以通过赞助一些额外的培训来帮助他？如果这个人在其他方面是一名优秀的员工并且非常了解您的业务，那么当只需要朝着正确的方向推动时，我会非常犹豫解雇他们。

  9. 技术 PM 听起来她真的没有在做她的工作。她是指出我所写的缺陷并推动改进的合乎逻辑的人。就她的职位而言，真正的问题是，她能否学会更好地维护您的组织利益。

  10. 首席 PM 听起来也太被动了。上面关于技术 PM 的评论也适用于此。

  11. 如果 bugtracker 等真的有效，那么走这条路是有意义的。但是，您可能希望在解雇人员时更加谨慎。

于 2008-12-29T22:41:52.030 回答
0

首先，我同意 Charlie Martin 关于数据库模式的看法。

第二，

听起来这个项目的开发人员非常环保——这是他/她的第一份编程工作吗？如果是这样，我只会在他们的简历说其他内容的情况下解雇开发人员。

我不知道领导/技术 pms 在项目中的参与程度如何，但听起来责任是 dev > tech pm > Lead pm。如果是这样的话，那么技术经理完全放弃了。您可能想找出为什么丢球并据此解雇/留住她，但是像这样的拙劣工作是我工作的谴责时间。

最后，恕我直言，“保护”的东西是废话——你需要根据他们的品质和价值来奖励和谴责人们，而不是他们的姑姑是谁。

祝你好运！干杯!

于 2008-12-29T22:55:16.763 回答
0

哇。我感觉到你的痛苦。

在我看来，问题的第一个来源似乎是“受保护”的 techPM。她为什么受到保护？由谁保护？我曾经在一个项目中，首席执行官的秘书首先成为业务分析师，然后（在他辞职后）成为项目经理，因为他们有外遇。她不知道我们用什么语言编程，并认为要求是浪费时间。由于她受到组织中最高级别的人的保护，唯一真正的解决方案是另谋高就。

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

主要 PM 可能会或可能不会被挽救，这取决于保护者是谁。他本可以处于困境和困境之间，他知道该怎么做，但由于技术 pm 和她的保护者之间关系的性质，无法对她和向她报告的人施加任何影响。有一次，我的两个老板和我的一个下属有染，这造成了各种组织破坏（这就是为什么保护者和技术 PM 都必须被解雇的原因）。让他从怀疑中受益，并与他讨论如果技术 pm 和她的保护者不在，他将如何以不同的方式处理事情。如果你喜欢你听到的，你可以留住他，但从组织上讲，你需要介入并确保清楚这个人是负责人，不允许任何人忽视他。一旦领导失去了权威，他只能在管理层的大力支持下才能恢复。

我还将与领导和开发人员坐下来，并准确解释项目目前的情况是什么是不可接受的。如果开发人员觉得无法从领导那里获得指导（假设您决定留住他），或者无法适应新的业务方式，或者无法理解为什么现在的代码不可接受，请减少损失并摆脱他也是。如果一个新人无论如何都可以挽救，那么他可能会更好地为领导工作，因为他不会有无视他的历史。

于 2008-12-29T23:13:08.613 回答
0

我不一定认为数据库模式应该始终与利益相关者共享。大多数人不知道如何处理这类信息。如果您试图确保产品符合要求，则应预先清楚地列出要求并在整个项目开发过程中进行验证。

如果您在开发方面遇到问题，那只是课程的标准。应该找到更值得信赖的人。如果你雇佣了一个糟糕的程序员，那是你的错误。

有几种可能的解决方案：

  • 获得更好的编码器。他会讨厌处理所有糟糕的代码，但希望他能坚持到完成为止。希望你愿意付给他很多钱。
  • 保留编码器并让他解决所有问题。聘请一位可以更好地管理他的新 PM。那个编码员最了解他的代码，他可能需要更少的时间来改进它。从长远来看，你最好不要在工资单上保留一个糟糕的编码员，所以当你完成后就失去他。
  • 接受它，为参与其中的每个人买一杯啤酒，然后从开源重新开始。您可能仍然需要技术 PM 来管理软件。那时你还必须忘记做任何定制的事情。也许承包商可以解决这个问题。

无论哪种方式，你都会损失一些钱。下次可能应该密切关注事情。

于 2008-12-29T23:33:40.757 回答
0

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

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

于 2008-12-29T23:45:03.777 回答
0

我最大的问题是关于首席 pm 和技术 pm 保护者之间的关系：首席 pm 是否有充分的理由害怕保护者的报复？完全有可能他觉得自己什么都做不了，直到情况变得糟糕到这对保护者之上的人来说显然很重要。在这种情况下，他不应该受到任何更严厉的对待。

技术 pm 显然不胜任她的工作，她的保护者更感兴趣的是支持她而不是完成工作。这向我表明，他们需要以某种方式处理，至少要谈论完成实际工作的重要性，最大限度地解雇他们两个。

鉴于您所概述的气候，开发人员可能会蹲下来，试图在政治上生存。我对开发人员的了解不够多，无法提供任何建议。

所以，如果你的描述和我惊人的通灵能力给了我一个清晰准确的画面：

保护领导 pm 免受报复，并告诉他放弃所有的垃圾并实施现成的解决方案。（如果他自己不能可靠地选择一个，他不应该成为领导。）

管教技术 pm 和她的保护者。您真的不希望人们以这种方式破坏企业生产力。

开发是领导 pm 的责任。就这样吧。不要进行过多的微观管理。喝几杯啤酒。回到你平常的工作。

于 2008-12-30T17:19:45.893 回答