[Extract from ‘Message of the week’ by Wesley Miao [A senior manager of Autodesk].
I’ll try to keep doing this, delivering a message to the whole team on weekly basis to share whatever I think that is worth sharing.
This week I would like to talk about iteration – a method to seek continuous improvement. The thoughts from “The Story of the Ribbon” presentation about how Microsoft put tremendous design effort to design Office 2007 new UI – Ribbon. I’m not sure whether it is true but from the presentation they drew a conclusion: for new designs, you need to at least do three iterations to get it right. Let’s not talk about whether it’s three iteration or four iteration to get it right, which is not the whole point I’m talking about here.
The idea is very simple and everybody understands it: we first create something and then we evaluate it and solicit feedbacks and then we make it better according to all feedbacks. This is one cycle or iteration. And then we do it all over again to get it better, and again to make it even better.
Let’s now think about how many things we’re doing everyday fall into this method.
1. Code review is definitely one type of iteration. We proposed the code change (create something) and involve senior people to review (solicit feedbacks) and we make changes according to feedbacks. This is one iteration. Usually we need to do two or three this kind of iteration to get it right.
2. Design document review. This usually involve even more iterations to get it right. We send the document to all relevant parties to seek feedbacks.
3. Our product release cycle. Typically we have a yearly release cycle for our major products. We created the product from June to Nov/Dec and initiated Beta programs as initial iterations – getting feedbacks from our beta users to make new release right. After we final release the product to our customers, we still have various approaches to seek customers’ feedbacks on new products.
So this whole thing (iteration) is not new to everybody.
The first point I have here is to raise everybody’s awareness. You need several iterations to get it right, to get continuous improvements. For everything you do and you create, if you find you’re not doing iteration, you need to seriously think about why is that and how to make iteration happen.
The second important point is how many iterations you need and how long each iteration lasts. Different people may have different habits. Some people prefer to work out the whole thing before they start soliciting feedbacks, whereas some other people prefer to break down the whole thing into small pieces and whenever they create a small piece they start asking for feedbacks. Generally I prefer shorter iterations to get more timely and early feedbacks to prevent bigger cost to fix something not right in the later stages of the game. Shorter iterations is also heart of Agile practices. I strongly encourage everybody to change your habit to constantly seek feedbacks whenever you create something, don’t wait till the end to get the feedbacks. If you do that (late feedbacks or reactively get feedbacks), you will have less chance to make it right.
The third point is how you get feedbacks: Code review and design review is one way to get feedbacks for the things (code and document) we created. But you may ignore that the real thing you are creating is the software. The best way to get feedbacks for the software is to have people use it. For most of the people in our team, you are creating something not for our end customers. Instead, you are creating something for our internal customers (Acad, Inventor, Revit, 3DSMax, Maya, etc). We all need to figure out a good process to seek feedbacks from them. While at the same time, we need think hard all kinds of creative ideas to dog-food the things we create. We are creating sample applications (which really should be called test shell applications) to test our component. We should engage our QA people to do more inspection and testing to provide timely and early feedbacks.
Again, the key thing here is “timely and early feedbacks”. By having shorter iterations, we will be able to achieve that.
Last, sorry for bad writing here. I just have something and I rush them out in an emai.
Cheers,
Wesley
Yesterday is HISTORY, Tomorrow is MYSTERY. 