It's not written in stone that you need 2 QA analysts, a project manager, a developer, and a build master to fix a bug. That only proves that bureaucracy is expensive, not that fixing bugs "late" in the process is expensive!
I'm not sure what exactly the second QA person adds to the process. As a developer, I need to be able to reproduce a bug myself in order to have any chance of fixing it, so there's your confirmation step right there.
Project manager? No, just have your QA person file the ticket as a bug (with the correct priority) and have your developers pull tickets off your bug tracker themselves. At worst, a slight email/verbal nudge from the usual boss should do.
Build person? No, have a continuous, automated build system. The job of the build person should be to maintain that system, not to run individual builds.
Now you're down to one QA person to file the ticket, one developer to fix the bug, and the same QA person again to close the ticket. Add in a few minutes of another developer's time to code review the first developer (you don't even do that despite having all that process?) and it's still cheaper.
Unit tests? Developers write their own unit tests. Have a failing unit test that reproduces the root cause of the bug before you fix the bug--that's a best practice anyway. For testing above and beyond that, it's not unreasonable to have SDETs maintain that stuff, though you already have the root cause of the bug captured in a unit test so your main concern should be whether any existing tests actually rely upon the broken behavior.
It's not written in stone that you need 2 QA analysts, a project manager, a developer, and a build master to fix a bug.
Well - that depends. For plenty of large software engineering projects (think aerospace) it's a given that you'll have that organization many times over.
On the other hand, a web startup may produce a high-quality shipping product with just two or three devops. The number of "lines of code" may even end up being similar between the two deliverables.
The code that gets burned into an ASIC requires a completely different set of development considerations than a non-critical "make deploy_production" web service.
But how do you quantify all these confounding factors?
Right - the aerospace people aren't stupid - far from it. They simply have vastly different goals and constraints, and thus a different organization and a different development process.
I'm not sure what exactly the second QA person adds to the process. As a developer, I need to be able to reproduce a bug myself in order to have any chance of fixing it, so there's your confirmation step right there.
Project manager? No, just have your QA person file the ticket as a bug (with the correct priority) and have your developers pull tickets off your bug tracker themselves. At worst, a slight email/verbal nudge from the usual boss should do.
Build person? No, have a continuous, automated build system. The job of the build person should be to maintain that system, not to run individual builds.
Now you're down to one QA person to file the ticket, one developer to fix the bug, and the same QA person again to close the ticket. Add in a few minutes of another developer's time to code review the first developer (you don't even do that despite having all that process?) and it's still cheaper.
Unit tests? Developers write their own unit tests. Have a failing unit test that reproduces the root cause of the bug before you fix the bug--that's a best practice anyway. For testing above and beyond that, it's not unreasonable to have SDETs maintain that stuff, though you already have the root cause of the bug captured in a unit test so your main concern should be whether any existing tests actually rely upon the broken behavior.