Sunday, 25 March 2012

Blog #3: Preparation of a software demo



Today I'll talk about the learning points that relating to the preparation of a good software demo!


A funny Dilbert comic depicting a '3-step' software demo


We had our first meeting relating to the preparation of the software demo some time back. We were all new to this and had minimal ideas on how to do a good software demo. After reading OP3’s “setting” which is about presenting for a road show, we realized that OP3 will be similar to OP2. The difference with both would be,
1)      The audience
2)      The organisation of the content (Proposal vs Demo)

We slowly narrowed down on the key factors which will constitute to a good software demo. Here are 3 key factors[2].
1)      Know our audience
2)      Have an excellent and catchy opening address for the software demo
3)      Explain first, demo later.

1) Know your audience
Knowing our audience is the most important factor of them all. By knowing our audience, we are able to limit our technical jargon, the amount of detail required of the demo and show only what is needed. For example, if our audience are non-technical based, it would be appropriate to just talk and show the features rather than diving deeper and explaining the inner workings of the program. They will get bored if we do the latter.
Furthermore, to keep the audience engaged, we need to show a demo that shows them how our product solves their unique / daily problems. As we come closer to these ‘daily’ problems in our demo, the audience will be more interested and attentive.

For our OP3, our audience comes from a diverse background. Thus, it would be best for our demo to be suited to a non-technical base. We will keep the feature demonstrations short and simple. Our demo will show more of the typical tasks they need to use rather than the features that advanced users will use.

2) Have an excellent and catchy opening address for the software demo
After viewing some demo videos on YouTube, I realised that introduction is the factor that will determine whether the audience gets turned off and decides that this is going to be a boring demo. In order to catch the audience’s attention, we need a strong introduction. Some humor in it would be good as humour engages the audience really well!

For our OP3, Yu Kai (Our introduction speaker) has decided to pose 2 questions to the audience during the introduction. These 2 questions are a depiction of a real life scenario and it relates to the hassle of the current situation of event organisation. As the other speakers continue, we will answer it such as, ‘to tackle the second problem’. Eventually everything is linked and the audience doesn’t get lost too!

3) Explain first, demo later
After introduction, comes the content. Despite the program being a completed product or a work in progress, a software demo will require one to explain the features rather than diving straight into the technical workings of a demo. Thus, a mixture of slides and demo would be good. Slides can explain the theory of the practical work being done in the demo. This will ensure that the audience gets a good grasp of what is happening.

Our product is still a work in progress thus, we will have to show more slides and explain them. However, we have to take note of not dragging them to the extent that the audience gets bored. Our demo will be at the end of each feature presentation. The length would be around 1 min out of a total of 5 minutes per feature presentation. The challenge here would be to engage the audience through slides. A possible way to tackle this would be to have catchy phrases in the slides and perhaps share a joke or question along the way.
Adding on to this, we have decided to use the storyboard layout provided in OP3 handout for organisation purposes. This has greatly assist us in organizing the flow of the demo!



There are many more factors that will constitute to a good software demo. However, these are the 3 most important factors which I feel are staple for a demo. In future software demos, these 3 key factors should be adopted. Most importantly, tweaking the content to fit the audience is still the most important factor.


References:
1) http://www.geonetwork.tv/ebrim/foss4g/img/Dilbert%20Software%20Demo.jpg (Dilbert comic courtesy of Geonetwork)
2) http://www.sales-training-lead-generation.com/blog/interesting-software-demos-5-tips/ 

3) http://www.youtube.com (For videos on software demo)

Saturday, 18 February 2012

Blog #2: Reflection on CS2103T Project - Floundering

Today I will be blogging about a main challenge that we face as a group. One of the main challenges that we face is floundering - To move forward with difficulty[1]

Floundering on Back of Horse in Water[2]

Floundering within our group has in fact affected the overall team’s working pace and the quality of work being delivered. During the first few group meetings, we have been trying to figure out the work and the roles that we will be good in. We rarely came down to a common team understanding of problems but rather were individualistic in understanding of problems within the group. Due to this, we experienced many false starts and circular discussions. Thus this led to some discussions being postponed / repeated.

During our first few meet-ups, we had to understand the project at hand and have to agree on a common understanding of the project requirements. We were quiet as we were new to each other. We rarely clarified the points as we did not understand on how the other person would react or was afraid if our clarification was ‘silly’. Thus we made individual assumptions on our common understanding of the project.

Due to this, when we met for another meeting, we had to work on the continuation of the previous discussion. However, we had various understanding of the project. We started clarifying them as a group. Due to this, we wasted valuable meeting time and repeated the discussions in subsequent discussions. [Circular Discussions].

We came up with a solution to this along the way.

Solution
In order for all to understand any problem at hand, we only move forward if and only if everyone agrees / understands them. Only then we will move onwards to the next phase of the discussion.

For example, we try to say
  • Here's my understanding of how the program works... Do we all agree?
  • Before we move forward, let's hear everyone's suggestions about improvements or better ideas on this problem.
Problem arising from above solution
This solution only worked to a certain extent. OP2’s Q&A was a very good test for this problem that we had. It clearly showed us that we still did not have a common understanding of the entire project.

Solution
We had an impromptu urgent meeting just to identify on what actually went wrong as a group. We realized was that we did not have a common medium to refer to when we felt lost and thus made individual assumptions once again. We had to reanalyse the entire project as the next phase was implementing it. However, for this meeting we started taking down detailed minutes. Kim Li jotted down notes on our discussion on how entire program will work. The change that we made was that she will post the minutes online so that everyone can refer to it when we feel confused about the project and not come up with individual understandings. Previously we only did minutes for the first meeting as it was a requirement for CS2101. Now we realise the importance of minutes.
We certainly do hope that this will be the last circular discussion that we will be having.

We also experienced false starts at the beginning. We made lots of assumptions at the start of the project. We carried on our discussions with these assumptions which actually led to ‘extra’ work and solutions that we out of scope.

Thankfully, we avoided this pitfall as we always stayed back after CS2103T lecture to clarify the doubts we had with Dr Bimlesh.
One good example was that we always assumed that for our CS2103T project, our GUI should be top-notch as it’s supposed to look like an official software. After clarifying with Dr Bimlesh, we were told that GUI is the last thing she would like to see as this course is leaning more towards the understanding of software engineering. This has in fact saved us LOTS of time in the upcoming weeks to come.

Floundering as infact made our team’s progress to slow down to a crawl at the beginning. However, the situation has improved and we have made up most of the valuable team time being wasted on circular discussions!

References:
[1] The free dictionary's defintion of floundering - 
http://www.thefreedictionary.com/floundering

Saturday, 28 January 2012

Blog Post #1- Communication

Image couresty of: kirstaabbott.com

Hello fellow readers. This is my first ever blog post and today I’m going to blog about Communication!

Communication is the means of conveying a meaningful message to another party. We communicate constantly with each and another every day. And strange it may seem, we are constantly having a conversation with ourselves whether you're aware of it or not. For example, we tend to ask ourselves, ‘Should I wear red or blue today?’

Using right means and mode of communication is most crucial in our message. One would agree that action speaks louder than words. The best example would be watching Mr Bean. He makes everyone laugh without saying a single word. Our tone, facial expressions and many other factors play a huge part in what we are going to convey to the other party.

I have worked with teams before and have gone through bitter times due to poor inter-personal communication skills. I would like to share an unforgettable experience of working in a team during my JC days. I was working in a group of 4 and was doing a subject called project work. Due to a difference in expectations, I was at times sarcastically insulting my friends’ work without realising it. Eventually, I decided to dump all of the work on myself thus burning midnight oils daily which in turn affected my health badly.

I did not complete JC due to my health status. I started reflecting my mistakes and realised that I was lacking in communicating my feelings out in a sensitive way. I was not willing to listen and only wanted my point across. Friendships and feelings were affected. Learning from these mistakes, I changed myself to be able to listen more and always thought before I spoke.

Right now, I’m having my first group project in NUS. I would say that things are going pretty well. We have similar expectations. We laid out our strengths and weaknesses in the first meeting and discussed on when we are able to meet up. Though we had some minor disputes in the first few meetings about the flow of events, we sorted it out within a few minutes. We heard each other’s views on the flow and decided on one that would work best.

We have just finished our first OP and I would say we did a fairly well done job despite a few hiccups. Due to our commitments, we could only rehearse a day before. Unfortunately, one of our teammates told us a day before that she would not able to make it down for the rehearsal as she was not feeling well. She did reassure us that she will do the rehearsal at home and ensure that the time limit is hit. My perception of her turned from uncertainty to trustworthiness. I believe that we are on the right track in achieving our goals!

Also on communication, I would like to share some personal experiences on intercultural communication with you. During my year 3 in poly, I decided to apply for an overseas internship program in China. I was working with Hewlett Packard for 3 months. Whenever I tell my friends about this, they will immediately give me a shocked look and ask the golden question. How could I, an Indian, communicate with people in China?

Well fortunately, my colleagues were able to speak simple English. Some were not so well versed thus; sentences like “I was excited” should be said as “I was happy”. The biggest challenge in China was to do some shopping on my own. I recall an incident where I wanted an exercise mat for myself. I tried to converse in broken Chinese with the sales assistant. However, my message did not go through. Soon, I started describing the item that I wanted with my hands and body. I used my hands to describe the length of the mat and my body to do some exercise poses. Eventually, she understood me and guided me to the correct section. This can clearly show that communication is not just about words. Actions play a vital role in such cases.

Thus these can show that communications is crucial in depicting the person you are on how you take the message and how you convey it out. Remember that in communication, be sensitive to one another. Cheers!