Zero Defect Methodology
Like most of you know, I’ve worked at Universal for a very long time. Then I left and consulted for a while. Im back at NBC, Universal Lot, and im picking up a few pointers. Not positive pointers but pointers that reinforce the positive pointers I have :-).
Let me go back a few months. A few months ago I left Universal and worked for a small company in Venice. There, I got to know a very good and practical development process. The, what I like to call, “No-shit” process. What is the “No-Shit” process? Easy.
- Business Team hands over a functional document.
- Development team looks over the document with the business team.
- Development Team puts together a Technical Spec.
- Development team sits down with business team just to make sure everything is in-order.
- Development team starts development.
- Development team finishes product sends it to QA.
- QA looks at it then signs off on it.
- Business team signs off.
Of course, for simplicity I left out the if statements in there, like, “If QA finds bugs, send back to development team..”. But you get the idea. The idea is, “No-shit you have to do it like that, what are you stupid??”. That’s why I call it the “No-Shit” process.Back to my point.
The beauty of the “zero defect” process is that NOTHING new gets developed until ALL bugs from previous projects have been dealt with. Simple as that. No, this doesnt mean that the product will one day be perfect. What it does mean is that the product, be it software or a candy bar, will reach a point where the application’s expected behavior by the user occurs without a glitch. Using the above steps you can get your product to a quasi-perfect state.
Why is this methodology, method in doing something, good to know? Aside from working on a project for the rest of your life, you save time and money. How? Since most of the crucial piece of information are documented, the developer can go back to the documents created by both the business team and the developers and remember how each component ties into one another. I’ve had numerous times when i forget my pencil and notebook for a meeting and leave the meeting thinking, “I will remember all the small details”. I dont, most developers dont either, so documentation is good.
If the documentation is present there is also a reduced need to schedule co-workers for meetings. On average, on a large project, developers have up to 5 meetings a day. Those 5 meetings always deal with the same items,
- What did we do so far?
- Why did we do that?
- Refresh everyones memory about the reason we did that.
- They understand why we did that.
Going into the next meeting the same questions are raised about the same project. Ultimately you end up with a situation where all individual are asking for a completely different product because there was no clear documentation by the business team to pass around.
Steps #1-#3 would have also reduced the amount of time in these meeting by simply pointing to the document and asking, “Do we really need to meet? All the details of the application are here ::point to the document:: ” Meetings will then be on, “as-need-basis”. This, then allows others to work on other items and free up valuable resources.
Read more about Zero Defect here
Armando Padilla
About Author
