Giving presentation on software project to non-programmers [closed]
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this questionSoon I will need to give a presentation on my honours project for the engineering faculty and a large group of engineering and technology students at my university. While all the the people attending will be technical-minded, not all of them will be programmers and most will be from other engineering disciplines.
I have given presentations before, and I am confident speaking to a crowd, but I realize now all the presentations I have given before have been to fellow CS/SE majors and teaching staff. I wonder if my presentation style assumes that I am presenting to other software geeks, so they will know what I am talking about and I can开发者_StackOverflow中文版 put on a more interactive demo involving the audience.
My honours project isn't terribly complex or theoretical, I have a prototype C# Winforms app but it is designed to be extensible and operate with different data sources (ODBC or WS) in the future, and some research to how it could be extended with a rule engine and DSL and turned into a marketable product. The organization that is testing my prototype is saving tens of thousands of dollars a year by automating a critical business function.
I had planned to show off how extensible it was by some live coding and UML-style diagrams. I really enjoy doing demos and live coding but I don't know if that kind of presentation will be as accessible to non-programmers, and I am worried if I get too geeky and technical I may alienate the audience and judges.
What are the effective techniques you have found to present software projects in a way that is also interesting to non-programmers
When I was working on my doctorate, the faculty gave us this rule for seminars - and it has proved very useful since:
- Tell 'em what you're gonna tell 'em. (E.g., brief introductory problem description and results abstract)
- Tell 'em. (E.g. technical details comprising the bulk of the time)
- Tell 'em what you told 'em. (E.g. brief summary and conclusions)
- Open the floor for questions.
In your position, I would take about 10-20% of your allotted time to do #1 in a largely non-technical way. So you might describe the business function your code automates, why that's important, what things were like before and after applying your solution, how it's saving money, that kind of thing.
Then I'd launch into a highly technical discussion aimed at the CS/SE crowd. Even if the rest of the folks don't understand it and their eyes glaze over, your introduction at least will have given them a sense of what it's all about, and they might recognize a bit here or there.
For the third part, I'd briefly recap the problem and describe how you solved it in non-technical language, and then do your live-coding extensibility whiz-bang demo. Even if the non-CS/SE folks don't understand the demo, they'll see eye candy flying by and your professional peers and faculty all nodding and smiling, so they'll think it's cool.
I once attended a seminar by a guy who won the Nobel Prize for applying chaos theory to chemical systems. He applied this approach, so even though all the non-theoreticians like my fellow organic chemists and I were all completely out of our depth, the fact that the theoreticians were all excited left us feeling like it was a great seminar even though we didn't have a clue about what he'd said.
To appeal to both audiences, I sometimes give the technical explanation and then follow it up with my "in English, please" explanation. CSI and other dramas with science in them do this all the time, to good effect.
In other words, [insert plain english explanation here].
Lets attack this as a refactoring problem.
ie Instead of adding more to your presentation, Is there a way in which you can take stuff out?
For example I don't think showing off that your demo App can use multiple data sources is essential, much less grants for you to program right there during the presentation. I know it took care in the design of your app to reach that point, but still most people are more interested in the OUTPUTS not the INPUTS of an app. And even more in the BENEFITS of said app.
Some guiding points:
Make the presentation about them. If the audience has felt the pain that your program solves, remind them of that pain. If they are other researches like yourself then ask them to put themselves in the shoes of the organization you helped.
Compare the old way vs the new way of doing things. Why is the new way more efficient? Will it lead to more sales? will it reduce inventory? or save money? Will someone lose his/her job because your solution makes his task irrelevant. Note: When making technological presentations I've observed is important to address what happens to the people that was doing the task previously. Fortunately most of the time people don't lose their jobs, in most cases the same people can manage a much larger volume of work thanks to Technology.
Show results. What are the real results your demo company has observed?
Use meaningful visuals. If you could make some animations that explain your algorithm even better.
Tell your point at the beginning and the end. Most people will forget what happened in the middle so make sure to tell the most important thing at the beginning and the of your talk.
Practice, Practice. Yeah it sounds ridiculous but do your whole presentation in front of a mirror or video recorded at least twice. The more the better. Don't give one of the most important presentations of your life without a rehearsal.
Breath and be positive you will do fine :-D
PS: My suggestions are derived from this webpage. It has guided me several times: 6 Stimuli to reach the old brain
You're already working on knowing your audience, which I think is awesome, you just need to take it a step further, and ask yourself, if I were x person in the audience, what would I get out of this presentation.
I'd question the validity and how much effort should go into the technical/coding demo, if the group you're presenting to is never likely to use your specific implementation. It may be more important to portray how you approached the extensibility, so that you garner ideas within the peers on how they can approach it in the future, as well as hit on points throughout that are important to all of your audience members, and maybe shortcut the demo a bit to just show that, yes, indeed it does work.
I don't know about you, but personally I've always got more value out of these types of presentations based around how the project appeals to everyone, how you are managing to save tens of thousands of dollars per year for this company, theoretically why other companies might want to use it as well, what is the market and other factors, what were the giant technological hurtles you had to overcome, even if it's a simple project, there were things you must have thought about ahead of time to avoid and prevent you from getting backed into a corner.
I think if you're a really good presenter, and the purpose of the presentation is to be broad and appealing to the entire group, and not a talk on the chaos theory and application to chemical systems, which has that stated purpose, you should appeal to the lowest common denominator of the audience, and the entire audience can be entertained and appreciate what you have achieved at every step along the way, and to do this, they don't necessarily have to understand every step taken either.
I've been in the same situation
(presenting a software engineering/image processing/recognition project in an EE faculty competition).
Start with the issue (the problem)
Then the background (a BIT of technical background)
The solution:
Start with block-charts (all engineers read those)
Then explain the technologies and how briefly - how complicated the implementation was
(don't underestimate the complicated part - otherwise you may make your work seem to simple to engineers from other fields - they won't appreciate your effort)
Results:
Show short visual examples (try to make them intriguing)
(short code examples can go here)Short user interface demo
Show impressive graphs
Bibliography, thanks, possible future improvements/research
Questions (if the forum is large, tell them in advance that the time for questions will be at the end)
General advice:
Practice presenting (over and over)
Leave 45-60 seconds per slide
No more than 5 points per slide
1 line per point
Add jokes
No animations except for demonstrating complicated issues faster
Use clear fonts (Ariel or Calibri for regular text, 1 different font for titles)
Use high contrast colors (bright on black or dark on white if you must - no dark on dark or bright or bright)
Well first of all, I would suggest talking to your faculty advisers about what they expect from your presentation. If there's any question about how you should balance technical details understandable to only CS people versus more general concepts understandable to the larger audience, I think it would really help to get input from those who will be evaluating you.
One thing I really like to see from a presentation is a "take home message". What is the one thing you want everyone in that audience to remember long after they've left the room? Tell them the take-home message at the very beginning. Tell them you will spend the rest of the presentation explaining why they should care and why they should believe you. Even if people get lost in some of the technicalities, if you at least drive home that one message, you've delivered one thing to a lot of people.
Another suggestion: don't forget about format. Presentation slides should be readable from anywhere in the auditorium/lecture hall. Don't overwhelm people with too much text on one slide. Keep bullets short and easy to scan. Do you want people spend their time reading your slides or do you want them to listen to what you have to say? Don't use acronyms, but if you must, explain what they mean--and put the definitions on your slides--unless you are sure they are common knowledge. If people are sitting there wondering what the heck that acronym means, they aren't listening.
As to whether you should show actual code or do live coding, my gut feeling is that you shouldn't unless it's absolutely critical to the point you're making. If your project were actually about some coding construct (e.g., if you had invented the concept of an "extension method"), okay, it would make sense to get into some actual code. But it sounds like the significance of what you've done is definitely up a level from that. You might want to show how little code it takes to, say, hook up a different data source, but I wouldn't actually get into walking through the code itself unless you feel you can't make your point otherwise. One thing I probably would like to see if I were in the audience is a demo of your code in action. Show me what is does, and tell me why that's cool.
I hope it goes well!
Here is my advice:
- Be clear who your audience is and what your message is - Are you trying to impress six faculty members who are marking your project, or proving you can entertain the whole audience.
- Have a Contents page early on - that way the audience know what to expect.
- Put the geek stuff in an appendix to your main presentation. That way you can dip into it ,for questions, but you will not loose the main point of your talk.
- Make sure your presentation flows and tells a story - limit slide numbers and don't clutter them e.g. project goals,possible uses, design challenges, software choice, what you did (limit techie), results (demo), results and limitations, next steps, questions.
- Have a Conclusions page at the end -- make sure you circle back and cross refer to your original contents page.
- Leave 15-20% of your time for questions. This will reveal what the audience is interested in, and allow you to display a deeper understanding of the topic i.e. only do live coding if they ask for it.
- Rehearse out loud even if you feel stupid doing it.
Good luck.
A few tips
- Use a common technical language. only use terms that the hearing will recognize.
- It links what you expose yourself, with examples recognizable by the audience.
you can also read these great articles.
- 11 Top Tips for a Successful Technical Presentation
- Tips for a Successful Technical Presentation
Bye.
Mix and match some topic everybody know. It has helped me to theme slides with images ranging from the Divine Comedy to the Simpsons I don't know how formal is your presentation but it's a common constructivist technique to hook on something your audiente already know to show your point.
I once attended a presentation of Larry Wall where he explained Perl 6 features using examples from golf mixed with the Lord of the Ring.
What I do is to talk analogies, try to convert to real world the terms you are explaining.
BTW, Why are you talking about software tech aspects to non tech people?? You have to target the content to your audience first. Who is your main audience?? The techies or non techies, choose one.
Regards,
I'd be inclined to not use code (unless you actually have to), and use some form of generic (and straightforward) pseudocode.
Also, if you are doing the talk with prompt cards, put 'Breathe!' at the top of the cards. It helped me...
Focus on the user interface (aka how it makes their lives easier) and how it is different from similar products (why they should listen.)
I think Simon Peyton Jones gives excellent talks. See the How to give a good research talk section on this page. In particular, check out the video of his talk about the subject linked to in that section. You can find other videos out there of his talks on Haskell, functional programming, etc. to see how he practices what he preaches.
Please listen to the following podcast : Manager Tools - Presentation basic
It will cover all the basics you need to do effective presentations.
Now when doing project presentations do the following:
Create a High Level Architecture model ... see this model you can probably do better (note: the model image is from my blog.).
Create a High level requirement list
Create a application workflow process diagram (once again pretty colors, arrows and blocks). This model will show how a user is expected to work with the application in order to solve its main task.
In order the present the application first show them the requirement list and talk about them, then the high level architecture and finally the application workflow process diagram which can be followed by a live demo.
The most important rule is to present at a fairly high level with lots of diagrams and models to show what you are talking about.
加载中,请稍侯......
精彩评论