3 ms·
No one said, "Lets do waterfall". What happened was people were just working, with weekly meetings which didn't pry too hard into what engineers did. Then there
by jboy55 4y ago
No one said, "Lets do waterfall". What happened was people were just working, with weekly meetings which didn't pry too hard into what engineers did. Then there was a massive fuck-up. Something took too long, was too buggy, too slow, and some customer was pissed and left.
Then the finger pointing happened.
Ops said, "Our servers aren't slow or missconfigured, QA should have done load tests before approving it. "
QA said, "The code we got was shit and buggy, it was all we could do to get all the breaking changes found before ship date!"
Devs said, "Product kept changing the design!"
Product said, "Sales sold something ill-defined and over promised!"
Sales said, "Everything we do isn't sellable! We needed these specs to compete! The reason the customers left was that Devs took too long to develop! Product couldn't write requirements! QA didn't test!".
So a solution was drawn. Product would get sales to get their sales-engineers to pre-qualify opportunities and sign off on a pre-qualification spec. Product would accept that, and once accepting it they would own it.
Product would take the Pre-Qualification doc, and produce a detailed requirements doc. Including timing estimates for interactions. They would present that to eng, and eng would sign off on it. Once they sign off, they wouldn't allow any changes to it. Product and Eng would need to complete a change request for every change to the requirements.
Eng would take the requirements and produce a detailed design doc. Then they would setup a time estimate that they would be held to. They would produce a machine spec sheet they would give to Ops to get the hardware ready. Once they complete eng, they would present the completed code to QA.
QA would have a test plan based on requirements only after they would accept the code from Devs. Once QA accepted it, they had a timeline to complete testing. When they have reached a low bug count, (Having a high number of bugs initially should have been caught by the pre-QA Test plan), they would sign off on the quality doc and hand code to Ops.
Ops would deploy the code, if the product didn't perform, it would be assumed at this point its the hardware config and thus ops issue.
All of this would be designed that the team wouldn't be "at fault" if they got the next team to accept the code, and every team would make sure everything was perfect before they accepted it. To keep deadlines, minimum times for doc creation and acceptance would be created. The only variable would be dev/qa time.
The process would be fool-proof, guaranteed that nothing could be produced that would cause another fuckup. Typically the first major project to go through this process would be the last. Either the company died before it would be completed, or the process destroyed itself in such a massive flame/backstabbing fest that even the CEO would get fired.