Bill Buxton from Microsoft Research in his keynotes talk on the MIX09 shown a very good idea I was not thinking about before: for each UI mockup you nead to have on the same piece of paper a small state transition/sitemap diagram that shows where exactly the screen represented by that mockup resides in the interaction flow. This is small but very important practice I think.
Watch the talk here.
It’s a midnight here and I’m trying to finish the delivery documentation since was not able to do that at office this evening. As usual this non-trivial task gives me a lot of inspiration and a lot of little lessons learned. In this process I need to check everything that I’m trying to describe. And almost always this happens to be the only moment when I can actually check anything by myself. When the iteration is in progress I don’t have time to look at the intermediate results, there are always some hot tasks to perform so I should trust my guys.
But each time I find out some little things that can put onto the face of the very good functional delivery a mask of incompleteness, so the customer will have a feeling that something could be better. After analysis of a lot of such cases I can draw certain conclusions on the nature of this thing and try to choose a strategy on how to improve it.
The first reaction when you see some little inconsistencies in UI or inconsistencies between two similar tasks implemented by different people is likely to be “WTF, how could they left such things not aligned !!!”. But thinking in the context of a Team I understand that everyone is in charge and everyone shares a part of the possible blame. Today I had a chance to see once more that Murphy’s laws are working very well. What is not described in the task definition and could be implemented and perceived by different people in different way WILL definitely be done differently.
That is why there is sometimes a temptation to analyze and describe everything ideally, provide the full complete specification. And the thing is that we should not do this. Ideal is not optimal in case of software development. Complete analysis and specification are very costly and hardly to be worthy in not-quality-critical systems. The optimal analysis is the one when a developer gets enough info to implement the thing without interrupting you too much. Here you need to count on the intuition of your team. The more intuition, experience and just a common sense a person has the less ideal should be your specification.
What can be done to increase that intuition level? How is it correlated not with that person but with me? Very simple: I must talk after each delivery and point out each time even those little things. Not blame, but point out. This can’t be done off course by spending just 8 hours of your time at work, to improve other people you should sacrifice your time but maybe this is one of the main things that improves me myself.
It’s very important to have at work a person who can always review your work and provide some advices, show you your mistakes or weak areas. Unfortunately, being a project manager leaves a very little space for such things especially in the projects where feedback loop from the customer is not strong enough. I guess all PMs must find a way of learning things without a teacher. And after all, who told that a teacher is needed when you want to learn 
Recent Comments