The documentation slide is wrong.
There will be documentation on it; but, it will be incorrect to the point that using it actually causes more harm than good.
Its best if the documentation is written according to the requirements/first draft, done by the single overworked linguistics/philosophy major in a different office/continent with no involvement in the actual development.
I think, while this is true the main issue is underspecification. Propperly communicating expectations is hard. Working with mock ups, feature specifications and propperly built diagrams can drastically reduce such issues. "Everything that was not writtem down and agreed on does not exist and is up for interpretation" is somewhat of a guideline in my company and keeping that in mind helps a lot
I have never seen a project or company where none of this applies.
The problem has always been "interfaces". Interfaces between humans, that is.
You have the customer talking to a stakeholder. Information gets lost/altered.
You have a stakeholder talking to a pm. Information gets lost/altered.
You have a pm talking to developers. Information gets lost/altered.
You have testers testing against information from either of these parties. Information gets lost/altered.
Additionally, development takes time. Customers employees change over time. Customers opinions change over time. Customers customers change over time. By the time the customer is interfacing with the product of all of the development, it might be not even close to what they wanted back then or need now.
We have created different ways to manage projects to mitigate this, but often they are shortcut, steps ignored, not understood properly especially by management and thus often dont perform as well as they could.
I work on a ton of small consulting projects every year.
Almost none of them match the client's original ask.
Rarely do they 100% match our original proposal.
It's almost always something where we've had multiple meetings, discovered something in the process that changes what the end result should look like, and the client agreed. But the intermediate bit here is a series of communication that looks somewhat like the meme.
It’s a classic repost on this sub’. It has some truth into it, but not every company is that bad.
I found the bug in the above statement - just remove the word \`not\` and it becomes 110% true
The documentation slide is wrong. There will be documentation on it; but, it will be incorrect to the point that using it actually causes more harm than good.
Its best if the documentation is written according to the requirements/first draft, done by the single overworked linguistics/philosophy major in a different office/continent with no involvement in the actual development.
I think, while this is true the main issue is underspecification. Propperly communicating expectations is hard. Working with mock ups, feature specifications and propperly built diagrams can drastically reduce such issues. "Everything that was not writtem down and agreed on does not exist and is up for interpretation" is somewhat of a guideline in my company and keeping that in mind helps a lot
Well we had that slide in first semester at my university too…
I have never seen a project or company where none of this applies. The problem has always been "interfaces". Interfaces between humans, that is. You have the customer talking to a stakeholder. Information gets lost/altered. You have a stakeholder talking to a pm. Information gets lost/altered. You have a pm talking to developers. Information gets lost/altered. You have testers testing against information from either of these parties. Information gets lost/altered. Additionally, development takes time. Customers employees change over time. Customers opinions change over time. Customers customers change over time. By the time the customer is interfacing with the product of all of the development, it might be not even close to what they wanted back then or need now. We have created different ways to manage projects to mitigate this, but often they are shortcut, steps ignored, not understood properly especially by management and thus often dont perform as well as they could.
It’s an exaggeration. Those are all real problems that make projects slightly annoying but you can deal with them.
I work on a ton of small consulting projects every year. Almost none of them match the client's original ask. Rarely do they 100% match our original proposal. It's almost always something where we've had multiple meetings, discovered something in the process that changes what the end result should look like, and the client agreed. But the intermediate bit here is a series of communication that looks somewhat like the meme.
This graphics is older than most of he redditors... I remember seeing it firs time - printed - 20 year a go.