I have recently been working closely with IT development team and our main objective was to have a program to replace redundant, manual work.
======================================================
First, a team of analyst will make it a hard time for a requestor by making the requestor write a 25 page long of requirement for the developer to work on. Then after 20 times of changes, the document is good to go.
During development, the developer discuss with himself for the whole time, on how to do the developing, how the flow will go, how Operations can benefit from it and how it would be.
Then it is testing time. Program finally ready for testing but it didn't work as the initial requirement because developer assumed it in his version of 25 pager while the requestor have another understanding.
Analyst's final conclusion is proceed to get the system to production then only request for change because it is what the Developer understood from the program.
======================================================
What I learn is that, if you pre-ordered a car 1 year ago, it is not the manufacturer's fault that they gave you an engine that is meant to work 1 year ago.
I thought it would be fair if change to requirement is allowed at testing stage in order to achieve the objective but people of different background came to a conclusion that we should not fix it now, let it be rotten and shown then only get it fixed.
R.I.P Six Sigma
