Okay, the first thing, to answer your question: No NO, a thousand times NO! The users are not people you should be discussing db schemata with; in general, you'd as well discuss calculus with a cow. Even if they have the technical background, what about the next time the requirements change; should they be involved in the schema update?
More generally, this sounds like a case where the technical leads let the problem get out of touch with the "customers" or stakeholders. If you're being asked to actually fix the problem, I'd suggest you need to build a GUI prototype of some sort, maybe even just a storyboard, and walk through that. then you'll have an idea where things stand.
Extended: yes, it WOULD be normal to discuss the DB schema within the project. I'd say you do need to think seriously about some, um, major counseling with the leads.
Extended more: I understand your point, but the thing is that the database schema is an implementation detail. We're so used to databases we let ourselves lose track of that, and end up with applications that, well, look like databases. But the database isn't what delivers customer value; it's whether the customer can do the things they want. If you tie the ways the customer sees the application to the DB schemata, then you tie them to one implementation; a change, such as denormalizing a table in order to make a more efficient system, becomes something you have to show the customer. Better to show them the observables, and keep these details to ourselves.
But I suspect we're having a terminology clash, too. I would have agreed with you on "domain model." If, by db schema, you mean only those tables and relations visible in the user's view of the system, the "use cases" if you will, then we'd be agreeing.
ER 模型和图表的美妙之处在于，它们不仅可以用来讨论数据库中的数据，还可以用来讨论数据以用户可以看到的形式出现的情况。 如果您有任何利益相关者不理解表格和表格填写，我的建议是您尽量让他们远离计算机（如果仍然可能的话）。
通过相当机械的过程，可以将构建良好的 ER 图转变为构建良好的关系模式。 更具创造性的设计过程可能会产生逻辑上等效的“更好”模式。 一些技术利益相关者需要理解关系模式而不仅仅是 ER 图。 不要向不需要了解关系模式的人展示关系模式。
The DATA should be discussed with the stakeholders, absolutely yes. The DB SCHEMA should NOT be discussed with the stakeholders except under special circumstances, where the stakeholders are all "database savvy".
So how can you discuss the DATA without discussing the DB Schema? This is the primary use that I've found for Entity-Relationship (ER) diagrams, and the ER model in general. A lot of database designers tend to treat ER as a watered down version of relational data modeling (RDM). In my experience, it can be used much more profitably if you don't think of it as watered down RDM.
What is one difference between ER and RDM? In RDM, a many to many relationship requires a junction box in the middle. This junction box holds foreign keys that link the junction box to the participants in the many to many relationship.
In ER, when applied strictly, junction boxes are unnecessary in many to many relationships. You just indicate the relationship as a line, and indicate the possibility of "many" at both ends of the line. In fact, ER diagrams don't need foreign keys at all. The concept of linkage by means of foreign keys can be left out of the discussion with most users.
Data normalization is utterly irrelevant to ER diagramming. A well built ER diagram will have very little harmful redundancy in it, but that's largely serendipity and not the result of careful planning.
The "entities" and "relationships" in a stakeholder oriented ER diagram should only include entities that are understood by the subject matter experts, and not include entities or relationships that are added in the course of logical database design.
Values to be held in a database and served up on demand can be connected to attributes, and attributes can in turn be connected to either entities or relationships among entities. In addition, attributes can be tied to domains, the set of possible values that each attribute can take on. Some values stored in databases, like foreign keys, should be left out of discussions with most stakeholders.
Stakeholders who understand the data generally have an intuitive grasp of these concepts, although the terms "entity", "relationship", "attribute", and "domain", may be unfamiliar to them. Stakeholders who do not understand the subject matter data require special treatment.
The beauty of ER models and diagrams is that they can be used to talk about data not only in databases, but also as the data appears in forms that users can see. If you have any stakeholders that don't understand forms and form fill out, my suggestion is that you try to keep them away from computers, if that's still possible.
It's possible to turn a well built ER diagram into a moderately well built relational schema by a fairly mechanical process. A more creative design process might result in a "better" schema that's logically equivalent. A few technical stakeholders need to understand the relational schema and not merely the ER diagram. Don't show the relational schema to people who don't need to know it.
Well, first you probably should review very carefully the relationship between the tech pm and her sponsor. I'm surprised you say the tech pm is protected when you later imply you can fire the protector. Either she is, or she is not protected. If you can fire the protector, then she is NOT protected.
So it sounds like no-one is protected, and worse - NO-ONE is communicating. I'd recommend the following: call a meeting with the lead pm, the tech pm and the dev. Once together, ask each in turn: "without referencing anything except YOUR work (i.e. you can't blame anyone else for the duration of this exercise), tell me in 5 minutes or less why I should NOT fire you today".
I realize this is extreme advice, but you have described a HORRIBLE solution to a classic problem. Every aspect of this project and the resulting "code" sounds like a disaster. You probably should have had a greater hand in the oversight of this mess, but you didn't (for whatever reason). I realize that you should expect hired professionals at the PM level to do better than this.
Hence my recommendation for a SEVERE shake-up of the team. Once you put the fear of unemployment one the table (and I'd tell them that you are writing up the failure to communicate for each one), then REQUIRE them to post plans for immediate communication improvement PLUS detailed timelines for fixing the mess by the end of the week.
Then get off your own bum because you're now the LEAD-lead PM on this project.
If they shape up and pull off a comeback on this disaster, then slowly start increasing their responsibilities again. If not... there's always a door.
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.
If this is true, tell the lead pm to be more assertive; then tell him/her to install bugzilla and be done with it. If the tech pm and dev weren't listening because of stubbornness, they need a little chat...
Either way, I'd say you have a problem with your organization... How many thousands of dollars were lost because of a case "not developed here"? However, given that it reached the point of implementation, there are problems further upstream than the development level...
As far as discussing the db schema with everybody, I'd say no. Everyone who can positively contribute should be involved after the application requirements have been gathered.
Wow, sounds like a disaster. Let me address your points in rough order:
First, people develop in languages they find comfortable. If someone is still comfortable in an older environment when much better alternatives exist, it is a sure sign that they have little appetite for skill acquisition.
Data validation prevents people from going too far down a path only to find it is a blind alley. Lack of validation means the developer isn't thinking about the user. Also, it is not something tacked on at the end...it simply doesn't work that way.
Web "dialogs" cannot be "modal" in the sense you are thinking. However, it is easy enough to pop up an additional window. Help on a page should almost always use a pop up window of this sort.
Data validation should NEVER navigate away from the page where data is entered - this is horrible UI design.
The DB schema is kind of the least of your problems. If the developer is responsible for delivering functionality and is clearly competent in data schema design, I wouldn't think it critical to discuss the nuances of the schema with the lead PM. It should be discussed among various code-level stakeholders and it must be capable of handling the requirements of the work. However, the important thing from the PM's perspective isn't the schema so much as the operational aspects. Of course, if you have no faith in the developer's ability to construct a good db schema, all bets are off.
If you seriously don't know what the dbms is, you may have a serious problem. Do you have a standard? If everyone else in the extended project is using MS SQL Server and this guy chose Oracle, how do you transfer expertise and staff into or out of this project? This is a sign of an organization out of control.
There are two reasons for ignoring alternative proprietary products. First, they may not truly meet your needs. Second, the tech PM and developer may simply be featherbedding or engaging in some nasty 'not invented here' justification for wasting your resources. The problem is that you aren't likely to have enough insight, at your level, to know the difference between the two.
With respect to firing the Dev...is it possible to help him by sponsoring some additional training? If this person is otherwise a good employee and knows your business well, I'd be very hesitant to fire them when all that is needed is a push in the right direction.
The tech PM sounds like she really isn't doing her job. She is the logical person to point out the flaws I am writing about and pushing for improvement. The real question, vis a vis her position, is whether she can learn to be a better advocate for your organizational interests.
The lead PM sounds too passive as well. Comments made above regarding the tech PM apply here as well.
If bugtracker, etc. really work then it would make sense to go that route. However, you might want to be a bit more circumspect about firing people.
First off, I agree with Charlie Martin about the db schema.
Second,
It sounds like the developer on the project is very green - is this his/her first programming job? If so, I would only fire the dev if their resume says something else.
I don't know how involved the lead/tech pms are expected to be in a project, but it sounds like the responsibility is dev > tech pm > lead pm. If that is the case, then the tech pm completely dropped the ball. You may want to find out why the ball was dropped and fire/keep her based on that, but a botched job like that is reprimand time where I work.
Finally, imho, the "protection" stuff is b.s. - you need to reward and reprimand people based on their quality and value, not who their aunt is.
Looks to me as if the first source of your problem is the techPM who is "protected". Why is she protected and by whom? I once was on a project where the ceo's secretary became first the business analyst and then (after he quit) the project manager because they were having an affair. She didn't know what language we programmed in and thought requirements were a waste of time. Since she was protected by someone as high as possible in the organization, the only real solution was to look elsewhere for employment.
You seem to think you can fire her and her protector so it may be someone lower than you but above the lead PM so he couldn't do anything about it but you can? Yes, you should fire the two of them.
The lead PM may or may not be salvageable depending on who the protector was. He could have been between a rock and a hard place where he knew what to do but due to the nature of the relationship between the tech pm and her protector was unable to exert any influence over her and the people who reported to her. I was in that position once where two of my bosses were having an affair with one of my subordinates and it creates all kinds of organizational havoc (which is why the protector must be fired as well as the tech PM). Give him the benefit of the doubt and discuss with him how he would would handle things differently if the tech pm and her protector were out of the way. If you like what you hear, you can keep him but organizationally you will need to step in and make sure that is it clear this person is in charge and no one will be allowed to ignore him. Once a lead has lost authority, he can only get it back with the strong backing from management.
I would also sit down with the lead and the developer and explain exactly what is unacceptable in the project as it currently stands. If the developer feels unable to take direction from the lead (assuming you decide to keep him) or is unable to adjust to a new way of doing business or cannot understand why the code as it stands is unacceptable, cut your losses and get rid of him as well. A new person is likely to work better for the lead if he is salvageable anyway because he won't have a history of ignoring him.
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.
If you're having problems with the dev, that's just par for the course. Someone more trust-worthy should have been found. If you hired a poor coder, that was your mistake.
There are a few possible solutions:
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.
I tend to think of it this way. The database schema is there to support the application's data storage requirements. What data the application needs to store will be determined by the end user's requirements. If you're not consulting your end user as to their requirements for the application you're obviously headed for trouble, but provided you have a good handle on their requirements (and likely future requirements) then database schema is a technical decision which can be made by the project team without direct input from the end user/client.
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.
发布评论
评论（10）
好的，首先，回答你的问题：不不，一千次不！ 用户不是您应该讨论数据库模式的人； 一般来说，你还不如和一头牛讨论微积分。 即使有技术背景，下次需求发生变化怎么办？ 他们应该参与架构更新吗？
更一般地说，这听起来像是技术主管让问题与“客户”或利益相关者脱节的情况。 如果您被要求实际解决问题，我建议您需要构建某种 GUI 原型，甚至可能只是一个故事板，然后逐步完成该问题>。 然后你就会知道事情的现状。
扩展：是的，在项目中讨论数据库模式是很正常的。 我想说你确实需要认真考虑一些，嗯，与领导的主要咨询。
扩展更多：我理解你的观点，但问题是数据库模式是一个实现细节。 我们已经习惯了数据库，以至于忘记了它，最终得到了看起来像数据库的应用程序。 但数据库并不是提供客户价值的东西；而是数据库。 而是客户能否做他们想做的事情。 如果您将客户查看应用程序的方式与数据库模式联系起来，那么您就将它们与一种实现联系起来； 诸如对表进行非规范化以建立更高效的系统之类的更改，成为您必须向客户展示的内容。 最好向他们展示可观察到的结果，并将这些细节留给我们自己。
但我怀疑我们也存在术语冲突。 我会同意你关于“领域模型”的看法。 如果通过数据库模式，您仅指那些在系统的用户视图中可见的表和关系，即“用例”（如果您愿意的话），那么我们会同意。
Okay, the first thing, to answer your question: No NO, a thousand times NO! The users are not people you should be discussing db schemata with; in general, you'd as well discuss calculus with a cow. Even if they have the technical background, what about the next time the requirements change; should they be involved in the schema update?
More generally, this sounds like a case where the technical leads let the problem get out of touch with the "customers" or stakeholders. If you're being asked to actually fix the problem, I'd suggest you need to build a GUI prototype of some sort, maybe even just a storyboard, and walk through that. then you'll have an idea where things stand.
Extended: yes, it WOULD be normal to discuss the DB schema within the project. I'd say you do need to think seriously about some, um, major counseling with the leads.
Extended more: I understand your point, but the thing is that the database schema is an implementation detail. We're so used to databases we let ourselves lose track of that, and end up with applications that, well, look like databases. But the database isn't what delivers customer value; it's whether the customer can do the things they want. If you tie the ways the customer sees the application to the DB schemata, then you tie them to one implementation; a change, such as denormalizing a table in order to make a more efficient system, becomes something you have to show the customer. Better to show them the observables, and keep these details to ourselves.
But I suspect we're having a terminology clash, too. I would have agreed with you on "domain model." If, by db schema, you mean only those tables and relations visible in the user's view of the system, the "use cases" if you will, then we'd be agreeing.
数据应该与利益相关者讨论，绝对是的。 除非在特殊情况下，利益相关者都是“数据库专家”，否则不应与利益相关者讨论数据库模式。
那么如何在不讨论数据库模式的情况下讨论数据呢？ 这是我发现实体关系 (ER) 图和一般 ER 模型的主要用途。 许多数据库设计者倾向于将 ER 视为关系数据建模 (RDM) 的淡化版本。 根据我的经验，如果您不认为它是淡化的 RDM，那么使用它可以带来更多的利润。
ER 和 RDM 之间的区别之一是什么？ 在 RDM 中，多对多关系需要中间有一个接线盒。 该接线盒包含将接线盒链接到多对多关系中的参与者的外键。
在 ER 中，如果严格应用，接线盒在多对多关系中是不必要的。 您只需将关系表示为一条线，并在该线的两端指出“许多”的可能性。 事实上，ER 图根本不需要外键。 大多数用户可以忽略通过外键进行链接的概念。
数据标准化与 ER 图完全无关。 一个精心构建的 ER 图几乎不会有有害的冗余，但这很大程度上是偶然的机会，而不是仔细规划的结果。
面向利益相关者的ER图中的“实体”和“关系”应该只包括主题专家理解的实体，而不包括在逻辑数据库设计过程中添加的实体或关系。
保存在数据库中并按需提供的值可以连接到属性，而属性又可以连接到实体或实体之间的关系。 此外，属性可以与域相关联，域是每个属性可以采用的可能值的集合。 数据库中存储的某些值（例如外键）不应与大多数利益相关者讨论。
了解数据的利益相关者通常对这些概念有直观的把握，尽管“实体”、“关系”、“属性”和“域”等术语对他们来说可能比较陌生。 不理解主题数据的利益相关者需要特殊对待。
ER 模型和图表的美妙之处在于，它们不仅可以用来讨论数据库中的数据，还可以用来讨论数据以用户可以看到的形式出现的情况。 如果您有任何利益相关者不理解表格和表格填写，我的建议是您尽量让他们远离计算机（如果仍然可能的话）。
通过相当机械的过程，可以将构建良好的 ER 图转变为构建良好的关系模式。 更具创造性的设计过程可能会产生逻辑上等效的“更好”模式。 一些技术利益相关者需要理解关系模式而不仅仅是 ER 图。 不要向不需要了解关系模式的人展示关系模式。
The DATA should be discussed with the stakeholders, absolutely yes. The DB SCHEMA should NOT be discussed with the stakeholders except under special circumstances, where the stakeholders are all "database savvy".
So how can you discuss the DATA without discussing the DB Schema? This is the primary use that I've found for Entity-Relationship (ER) diagrams, and the ER model in general. A lot of database designers tend to treat ER as a watered down version of relational data modeling (RDM). In my experience, it can be used much more profitably if you don't think of it as watered down RDM.
What is one difference between ER and RDM? In RDM, a many to many relationship requires a junction box in the middle. This junction box holds foreign keys that link the junction box to the participants in the many to many relationship.
In ER, when applied strictly, junction boxes are unnecessary in many to many relationships. You just indicate the relationship as a line, and indicate the possibility of "many" at both ends of the line. In fact, ER diagrams don't need foreign keys at all. The concept of linkage by means of foreign keys can be left out of the discussion with most users.
Data normalization is utterly irrelevant to ER diagramming. A well built ER diagram will have very little harmful redundancy in it, but that's largely serendipity and not the result of careful planning.
The "entities" and "relationships" in a stakeholder oriented ER diagram should only include entities that are understood by the subject matter experts, and not include entities or relationships that are added in the course of logical database design.
Values to be held in a database and served up on demand can be connected to attributes, and attributes can in turn be connected to either entities or relationships among entities. In addition, attributes can be tied to domains, the set of possible values that each attribute can take on. Some values stored in databases, like foreign keys, should be left out of discussions with most stakeholders.
Stakeholders who understand the data generally have an intuitive grasp of these concepts, although the terms "entity", "relationship", "attribute", and "domain", may be unfamiliar to them. Stakeholders who do not understand the subject matter data require special treatment.
The beauty of ER models and diagrams is that they can be used to talk about data not only in databases, but also as the data appears in forms that users can see. If you have any stakeholders that don't understand forms and form fill out, my suggestion is that you try to keep them away from computers, if that's still possible.
It's possible to turn a well built ER diagram into a moderately well built relational schema by a fairly mechanical process. A more creative design process might result in a "better" schema that's logically equivalent. A few technical stakeholders need to understand the relational schema and not merely the ER diagram. Don't show the relational schema to people who don't need to know it.
好吧，首先你可能应该非常仔细地审查技术项目经理和她的赞助商之间的关系。 我很惊讶你说技术PM受到保护，而你后来暗示你可以解雇保护者。 要么她受到保护，要么她不受保护。 如果你可以解雇保护者，那么她就不受保护。
所以听起来没有人受到保护，更糟糕的是——没有人在交流。 我建议采取以下措施：与领导 PM、技术 PM 和开发人员召开会议。 一旦在一起，轮流问每个人：“除了你的工作之外，不要提及任何其他内容（即，在这个练习的持续时间内，你不能责怪任何其他人），在 5 分钟或更短的时间内告诉我为什么我今天不应该解雇你”。
我意识到这是极端的建议，但你已经描述了一个经典问题的可怕解决方案。 这个项目的每个方面以及由此产生的“代码”听起来都像是一场灾难。 你可能应该在监督这场混乱中发挥更大的作用，但你没有（无论出于何种原因）。 我意识到你应该期望聘请的 PM 级别的专业人士做得比这更好。
因此，我建议对团队进行一次彻底的改组。 一旦你把失业的恐惧摆在桌面上（我会告诉他们，你正在为每一个人写下沟通失败的情况），然后要求他们发布立即改善沟通的计划，以及解决混乱问题的详细时间表。周末。
然后摆脱你自己的流浪汉，因为你现在是这个项目的首席项目经理。
如果他们振作起来并在这场灾难中东山再起，那么就会慢慢开始再次增加他们的责任。 如果没有的话……总有一扇门。
干杯，
-R
Well, first you probably should review very carefully the relationship between the tech pm and her sponsor. I'm surprised you say the tech pm is protected when you later imply you can fire the protector. Either she is, or she is not protected. If you can fire the protector, then she is NOT protected.
So it sounds like no-one is protected, and worse - NO-ONE is communicating. I'd recommend the following: call a meeting with the lead pm, the tech pm and the dev. Once together, ask each in turn: "without referencing anything except YOUR work (i.e. you can't blame anyone else for the duration of this exercise), tell me in 5 minutes or less why I should NOT fire you today".
I realize this is extreme advice, but you have described a HORRIBLE solution to a classic problem. Every aspect of this project and the resulting "code" sounds like a disaster. You probably should have had a greater hand in the oversight of this mess, but you didn't (for whatever reason). I realize that you should expect hired professionals at the PM level to do better than this.
Hence my recommendation for a SEVERE shake-up of the team. Once you put the fear of unemployment one the table (and I'd tell them that you are writing up the failure to communicate for each one), then REQUIRE them to post plans for immediate communication improvement PLUS detailed timelines for fixing the mess by the end of the week.
Then get off your own bum because you're now the LEAD-lead PM on this project.
If they shape up and pull off a comeback on this disaster, then slowly start increasing their responsibilities again. If not... there's always a door.
Cheers,
-R
如果这是真的，请告诉领导要更加自信； 然后告诉他/她安装 bugzilla 并完成它。 如果技术经理和开发人员因为固执而没有倾听，他们需要聊聊......
无论哪种方式，我都会说你的组织有问题......因为一个案例损失了多少数千美元“这里不发达”？ 然而，既然已经到了实现的地步，那么在开发层面更上游的地方还存在问题……
至于和大家讨论db schema，我会说不。 在收集申请要求后，每个能够做出积极贡献的人都应该参与其中。
If this is true, tell the lead pm to be more assertive; then tell him/her to install bugzilla and be done with it. If the tech pm and dev weren't listening because of stubbornness, they need a little chat...
Either way, I'd say you have a problem with your organization... How many thousands of dollars were lost because of a case "not developed here"? However, given that it reached the point of implementation, there are problems further upstream than the development level...
As far as discussing the db schema with everybody, I'd say no. Everyone who can positively contribute should be involved after the application requirements have been gathered.
哇，听起来像是一场灾难。 让我粗略地阐述一下您的观点：
首先，人们使用他们觉得舒服的语言进行开发。 如果有人在存在更好的替代方案的情况下仍然适应较旧的环境，则明确表明他们对技能获取兴趣不大。
数据验证可以防止人们在一条道路上走得太远，却发现这是一条死胡同。 缺乏验证意味着开发人员没有考虑用户。 而且，这不是最后附加的东西......它根本就不是这样工作的。
网络“对话框”不能是您所想的意义上的“模式”。 然而，弹出一个附加窗口很容易。 页面上的帮助几乎应该总是使用这种类型的弹出窗口。
数据验证永远不应该离开数据输入的页面 - 这是糟糕的 UI 设计。
数据库模式是最少的问题。 如果开发人员负责交付功能并且显然有能力进行数据模式设计，那么我认为与首席 PM 讨论模式的细微差别并不重要。 它应该在各个代码级利益相关者之间进行讨论，并且它必须能够处理工作的要求。 然而，从 PM 的角度来看，重要的不是模式，而是操作方面。 当然，如果您对开发人员构建良好数据库模式的能力没有信心，那么所有的赌注都会失败。
如果您真的不知道 dbms 是什么，那么您可能会遇到严重的问题。 你有标准吗？ 如果扩展项目中的其他人都使用 MS SQL Server，而这个人选择了 Oracle，那么您如何将专业知识和人员转移到该项目中或从该项目中转移出来？ 这是组织失控的标志。
忽视替代专有产品有两个原因。 首先，它们可能无法真正满足您的需求。 其次，技术产品经理和开发人员可能只是在吹毛求疵，或者用一些令人讨厌的“不是这里发明的”理由来浪费你的资源。 问题是，在您的水平上，您不太可能有足够的洞察力来了解两者之间的区别。
关于解雇开发人员……是否可以通过赞助一些额外的培训来帮助他？ 如果这个人在其他方面是一名好员工并且非常了解您的业务，那么当所需要的只是朝着正确的方向推动时，我会非常犹豫是否要解雇他们。
这位技术产品经理听起来好像她真的没有做好自己的工作。 她是一个合乎逻辑的人，能够指出我所写的缺陷并推动改进。 相对于她的职位，真正的问题是她是否能够学会更好地倡导您的组织利益。
首席产品经理听起来也太被动了。 上面关于技术 PM 的评论也适用于此。
如果 bugtracker 等确实有效，那么走这条路就有意义了。 但是，您可能希望在解雇人员时更加谨慎。
Wow, sounds like a disaster. Let me address your points in rough order:
First, people develop in languages they find comfortable. If someone is still comfortable in an older environment when much better alternatives exist, it is a sure sign that they have little appetite for skill acquisition.
Data validation prevents people from going too far down a path only to find it is a blind alley. Lack of validation means the developer isn't thinking about the user. Also, it is not something tacked on at the end...it simply doesn't work that way.
Web "dialogs" cannot be "modal" in the sense you are thinking. However, it is easy enough to pop up an additional window. Help on a page should almost always use a pop up window of this sort.
Data validation should NEVER navigate away from the page where data is entered - this is horrible UI design.
The DB schema is kind of the least of your problems. If the developer is responsible for delivering functionality and is clearly competent in data schema design, I wouldn't think it critical to discuss the nuances of the schema with the lead PM. It should be discussed among various code-level stakeholders and it must be capable of handling the requirements of the work. However, the important thing from the PM's perspective isn't the schema so much as the operational aspects. Of course, if you have no faith in the developer's ability to construct a good db schema, all bets are off.
If you seriously don't know what the dbms is, you may have a serious problem. Do you have a standard? If everyone else in the extended project is using MS SQL Server and this guy chose Oracle, how do you transfer expertise and staff into or out of this project? This is a sign of an organization out of control.
There are two reasons for ignoring alternative proprietary products. First, they may not truly meet your needs. Second, the tech PM and developer may simply be featherbedding or engaging in some nasty 'not invented here' justification for wasting your resources. The problem is that you aren't likely to have enough insight, at your level, to know the difference between the two.
With respect to firing the Dev...is it possible to help him by sponsoring some additional training? If this person is otherwise a good employee and knows your business well, I'd be very hesitant to fire them when all that is needed is a push in the right direction.
The tech PM sounds like she really isn't doing her job. She is the logical person to point out the flaws I am writing about and pushing for improvement. The real question, vis a vis her position, is whether she can learn to be a better advocate for your organizational interests.
The lead PM sounds too passive as well. Comments made above regarding the tech PM apply here as well.
If bugtracker, etc. really work then it would make sense to go that route. However, you might want to be a bit more circumspect about firing people.
首先，我同意 Charlie Martin 关于数据库模式的观点。
其次，
听起来这个项目的开发人员很新手——这是他/她的第一份编程工作吗？ 如果是这样，只有当开发人员的简历中有其他内容时，我才会解雇他们。
我不知道领导/技术项目经理将如何参与项目，但听起来责任是开发> 技术下午> 铅下午。 如果是这样的话，那么技术经理就彻底失败了。 你可能想找出为什么失败并据此解雇/留住她，但像这样的糟糕工作在我工作的地方就是谴责时间。
最后，恕我直言，“保护”的东西是废话——你需要根据人们的品质和价值来奖励和斥责他们，而不是他们的阿姨是谁。
祝你好运！ 干杯!
First off, I agree with Charlie Martin about the db schema.
Second,
It sounds like the developer on the project is very green - is this his/her first programming job? If so, I would only fire the dev if their resume says something else.
I don't know how involved the lead/tech pms are expected to be in a project, but it sounds like the responsibility is dev > tech pm > lead pm. If that is the case, then the tech pm completely dropped the ball. You may want to find out why the ball was dropped and fire/keep her based on that, but a botched job like that is reprimand time where I work.
Finally, imho, the "protection" stuff is b.s. - you need to reward and reprimand people based on their quality and value, not who their aunt is.
Good luck! Cheers!
哇。 我感受到你的痛苦。
在我看来，问题的第一个根源似乎是受到“保护”的 techPM。 她为什么受到保护以及受到谁的保护？ 我曾经参与过一个项目，首席执行官的秘书首先成为业务分析师，然后（在他辞职后）成为项目经理，因为他们有外遇。 她不知道我们用什么语言编程，并且认为这些要求是浪费时间。 由于她受到组织中尽可能高的人的保护，唯一真正的解决办法就是到其他地方寻找工作。
你似乎认为你可以解雇她和她的保护者，所以可能是比你级别低但在首席总理之上的人，所以他对此无能为力，但你可以吗？ 是的，你应该解雇他们两个。
主要 PM 是否可以挽救取决于保护者是谁。 他本来可以进退两难，知道该怎么做，但由于技术经理和她的保护者之间关系的性质，他无法对她和向她报告的人施加任何影响。 我曾经处于这样的位置，我的两位老板与我的一位下属有染，这造成了各种组织破坏（这就是为什么必须解雇保护者和技术 PM 的原因）。 假设他是无辜的，并与他讨论如果技术经理和她的保护者不妨碍他将如何以不同的方式处理事情。 如果你喜欢你所听到的，你可以保留他，但在组织上你需要介入并确保这个人是负责人，并且不允许任何人忽视他。 一旦领导失去权威，他只有在管理层的大力支持下才能恢复权威。
我还会与领导和开发人员坐下来，准确解释项目目前的情况是哪些是不可接受的。 如果开发人员感觉无法接受领导的指示（假设您决定留住他），或者无法适应新的业务方式，或者无法理解为什么现有的代码不可接受，请减少损失并摆脱他也是。 如果新人无论如何都可以挽救的话，他可能会更好地担任领导职务，因为他不会有忽视他的历史。
Wow. I feel your pain.
Looks to me as if the first source of your problem is the techPM who is "protected". Why is she protected and by whom? I once was on a project where the ceo's secretary became first the business analyst and then (after he quit) the project manager because they were having an affair. She didn't know what language we programmed in and thought requirements were a waste of time. Since she was protected by someone as high as possible in the organization, the only real solution was to look elsewhere for employment.
You seem to think you can fire her and her protector so it may be someone lower than you but above the lead PM so he couldn't do anything about it but you can? Yes, you should fire the two of them.
The lead PM may or may not be salvageable depending on who the protector was. He could have been between a rock and a hard place where he knew what to do but due to the nature of the relationship between the tech pm and her protector was unable to exert any influence over her and the people who reported to her. I was in that position once where two of my bosses were having an affair with one of my subordinates and it creates all kinds of organizational havoc (which is why the protector must be fired as well as the tech PM). Give him the benefit of the doubt and discuss with him how he would would handle things differently if the tech pm and her protector were out of the way. If you like what you hear, you can keep him but organizationally you will need to step in and make sure that is it clear this person is in charge and no one will be allowed to ignore him. Once a lead has lost authority, he can only get it back with the strong backing from management.
I would also sit down with the lead and the developer and explain exactly what is unacceptable in the project as it currently stands. If the developer feels unable to take direction from the lead (assuming you decide to keep him) or is unable to adjust to a new way of doing business or cannot understand why the code as it stands is unacceptable, cut your losses and get rid of him as well. A new person is likely to work better for the lead if he is salvageable anyway because he won't have a history of ignoring him.
我不一定认为数据库模式应该始终与利益相关者共享。 大多数人不知道如何处理此类信息。 如果您想确保产品符合要求，则应预先明确提出要求并在项目的整个开发过程中进行验证。
如果您在开发过程中遇到问题，那是理所当然的。 应该找到更值得信赖的人。 如果你雇佣了一个糟糕的程序员，那就是你的错误。
有几种可能的解决方案：
不管怎样，你都会损失一些钱。 下次可能应该密切关注事情。
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.
If you're having problems with the dev, that's just par for the course. Someone more trust-worthy should have been found. If you hired a poor coder, that was your mistake.
There are a few possible solutions:
Either way, you're gonna lose some money. Should probably keep a closer eye on things next time.
我倾向于这样想。 数据库模式用于支持应用程序的数据存储需求。 应用程序需要存储哪些数据将由最终用户的要求决定。 如果您没有咨询最终用户对应用程序的需求，那么您显然会遇到麻烦，但如果您很好地处理了他们的需求（以及可能的未来需求），那么数据库架构是一项技术决策，可以由项目团队制作，无需最终用户/客户的直接输入。
最终用户不太可能理解表、字段、规范化等的复杂性，但他们会理解“系统需要执行 xyz”。 用最终用户理解的语言与他们交谈，并让您的团队做出适当的技术决策。
I tend to think of it this way. The database schema is there to support the application's data storage requirements. What data the application needs to store will be determined by the end user's requirements. If you're not consulting your end user as to their requirements for the application you're obviously headed for trouble, but provided you have a good handle on their requirements (and likely future requirements) then database schema is a technical decision which can be made by the project team without direct input from the end user/client.
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.
我的一个大问题是关于首席 PM 和技术 PM 的保护者之间的关系：首席 PM 是否有充分的理由担心保护者的报复？ 完全有可能他觉得无能为力，直到情况变得足够糟糕，这对于保护者之上的人来说显然很重要。 既然如此，他也不值得受到更多的严厉对待。
这位技术经理显然不胜任她的工作，而她的保护者更感兴趣的是偏袒她而不是完成工作。 这对我来说意味着需要以某种方式处理他们，至少要谈论完成实际工作的重要性，最多要解雇他们两人。
考虑到你所概述的气候，开发人员可能会蹲下来，试图在政治上生存。 我无法详细介绍开发人员来提供任何建议。
因此，如果你的描述和我惊人的通灵能力给了我一个清晰而准确的画面：
保护领导 PM 免受报复，并告诉他抛弃所有废话并实施现成的解决方案。 （如果他自己不能可靠地选择一个人，他就不应该担任领导。）对
技术经理和她的保护者进行纪律处分。 您确实不希望有人以这种方式破坏企业生产力。
开发人员是领导 PM 的责任。 就这样吧。 不要进行不必要的微观管理。 喝几杯啤酒。 回到你平常的工作中去。
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.