There are lots of reasons to have difficulty working with DevOps people, but you really do have to work it out in order to provide the kind of value that your company needs. I have met people that just don't care about that. They are only interested in a fairly selfish pursuit of what they find compelling in programming. I guess one could portray that as being a "diva", but I think it's a lot more complex than that. In any case, there really isn't any room for that kind of thing if the teams wants to be successful. I've worked with people like that before and as the project inevitably dies, they are the first to blame other people. Which is sad because they are often very skillful and will have no trouble finding another group to help crash.
The problem occurs when devops no longer takes a customer service attitude towards developer teams, especially regarding how to incorporate new technologies into production. The developer teams are the experts of whether that new technology is the right cost effective choice for the project, and that needs to be respected by devops. Their job is to get it working in production or else find equivalent solutions that meet the properties identified by the development team as necessary. Unfortunately, devops tries to be involved early on almost like a consultant to constrain what choices can be considered at each step, risking that the company can’t benefit from the expertise of developer teams in identifying solutions.
Unless the ops person on the other side of this conversation is really bad they're unlikely to be asking you to do things just for the sake of it - there'll be a good reason, just as you have your reasons for wanting to do things your way. Devops is all about finding a middle ground between those two places, and improving life for everyone involved.
There are extreme cases where someone is always an "Extreme Overestimator" but those are rare. People will often shift between all of this made up classifications depending on the circumstances, their goals, their past experiences, etc.
It seems to be a nice tool to raise awareness for these potential states of mind but I wouldn't use it as an objective assessment of other people.
They are also the most unproductive ones and tend to form cliques.
In practice, none of the six companies I’ve worked for has ever used anything other than vague requirements at all times for all teams, whatever gives the most fungibility to the product / sales side of the organization. Adding scope definitely requires amending deadlines, so I can agree with that, but a Sales Liason is low risk to the project? No way.
It makes me question who is writing this and what their personal perspective is for choosing the taxonomy of risks, which in turn makes this whole thing seem childish to me and certainly not any kind of broadly applicable way of analyzing people at work or risks that are posed.
Meanwhile, there is actual research literature that attempts to study things of a similar vein, e.g.
https://static1.squarespace.com/static/55dcde36e4b0df55a96ab...
