My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.
Suggestion #12: Learn to explain. - TonyBruce
Here's another one that dovetails into "advocacy". When I was asked once if I believed there was a "metric" that could help demonstrate if someone was a good tester, I said "look at the ratio of bugs that a tester has reported. Compare them to the number of bugs that were actually fixed. The closer that ratio gets to 1, the better the tester". I can't claim to be the originator of that. I heard it first from Cem Kaner in his BBST materials for Bug Advocacy, but it's as good a jumping off point as any. To get bugs fixed, you have to "sell the story". To sell the story, you have to be able to explain what you are doing, and do so convincingly.
Additionally, and in a somewhat separate sphere, from time to time we need to teach others what we are know, and get them up to speed so that they understand and can readily do what we want to have them do. We need to confirm that they understand what we have taught them, and verify that, were they to go and do that task themselves, that they would be successful.
Workshop #12: Use Screencasting and Master the Art of the Demo
If you tell me something is wrong, I may or may not believe you. If you show me something is wrong, I will be much more likely to believe you. If you show me something is wrong, explain to me what should be happening, and can help me see why the behavior isn't what we want to see, you have a really good shot at convincing me, especially if you can do it quickly.
All of these aspects can be rolled into a simple premise. Give quick and convincing demos of the issues you see, the features that should be implemented, or the shills that need to be transferred. People learn most by doing, and they learn best when they can go back and review what's been shown to them.
From my own experiences working with both local and distributed team members, being able to break down steps into specific and easy to understand sequences can make or break a demo. For a demo to succeed, it's important to place things in the proper order, and to talk about them in the proper context. A great way to do this is to get an application that will allow you to capture application steps and play them back. Screencasting software is available from a number of providers and ranging in price from Free to around $100. Using the screencast software to capture your screen output is a great way to demonstrate issues, provide annotations, and make clear how you were able to get from point A to point Z.
Recording your actions, however, is not enough. To make a demo actually work, try to use the following in you presentations:
- Imagine that the person you are talking to has no prior understanding of the application you are demonstrating. Could you explain the issue to such a person so that they would understand what is happening?
- Take the time to start from the beginning, and walk through to the point where an application will show the behavior that you want to describe. Take baby steps, and fill in the details as you go. Son't assume that those who are seeing the screencast will know what you are trying to describe. At the same time, don't add commentary to things that don't need it. If you need to press the Start button or launch an application from the dock, don't say that you are doing that. Your actions there are clear. Save the direct commendatory when you start getting into the section of the app that has an issue, or an area that you really want to explain carefully.
- Pause as you make key points. Allow the viewer/listener to take in what you are describing. You may find it worthwhile to reiterate certain things or explain the same thing but using different words. This is often helpful in in-person demo situations as well as for recorded screencasts.
- Provide annotations or create outlines, circles, or any other visual cues that can help you explain what is happening.
- In a live situation, take the time to assess if the person watching is folioing along, is engaged, and understands what you are saying. Ask questions to determine if they really do get what is going on.
- In a video example, make sure to go from start to finish for the necessary situation. Avoid any details or commentary that is not relevant to what needs to be explained. If demonstrating a bug, show the steps to get to the issue, demonstrate the issue, and briefly explain what you would expect to see happen. If you are demonstrating a skill or examples of a workflow, go from start to finish, and be as direct as is practical (remember, people can rewind and rematch videos).
Bottom Line:
The ability to explain and have that explanation motivate someone else to action is a great skill to develop. Using a screen casting application can really help drill down a person's ability to explain their ideas, and do so in as direct and effective a method as possible. Realize that, when I am talking about screencasts, they can be as simple as just capturing a few seconds of actions and displaying an exception or a crash, up to long, fully annotated and professional quality talks and demonstrations. In both cases, the goal is the same. Make it so that the recipient of the video or live demo can understand exactly what you want to say, and take the time to make sure that they actually do understand. In a live setting, that will require asking multiple times if they understand, or having them repeat what you are doing on their own. With a recorded video, your steps need to be direct and to the point. If the viewer wants to review again (or multiple times) they will be able to play a recorded video as often as they want to. YouTube doesn't get tired if someone wants to watch it for the tenth time.
No comments:
Post a Comment