This blog post was prompted by a comment posted by susan.keohan on my previous post dealing with my struggles to get workflow to cooperate which is basically a summary of three questions I had asked in Q&A and the extensive help I received in the form of answers there. Susan's suggestion to write something about asking good questions came as a bit of a surprise as there already are resources readily available in the SAP Community about that:
So, what follows is my personal way of going about this and there'll be some overlap with these existing resources.
For me, there are different reasons to ask a question, like trying to find out why something isn't working, how others are dealing with a given situation or how a process could be improved to work better than it currently does. Some of the questions are technical in nature while others are more "philosophical". In all cases, my incoming assumption is that it's highly unlikely that I'm the first person running into the issue or having to deal with a particular situation. There are just way too many people working in the SAP environment for a question to be really unique. But, this doesn't necessarily mean that somebody actually asked the question previously or that he or she had received a response.
Add to that, that I've always been curious and eager to find out why something is working (or not!) and you'll understand why I actually like asking questions. Without asking questions - especially the "why" ones - we as a species wouldn't have evolved the way we did.
Well, to state the obvious: do your due diligence before jumping in to ask your question! For me, this often entails some trial and error to see if I can figure out technical issues myself with the help of debugging or any of the other handy tools available to us like the performance analysis (SAT) or the SQL-trace (ST05). If that doesn't get me anywhere, I'll try to explain the issue to my colleagues in our programming and basis teams to find out if they have an idea or some further leads. The next - or even a parallel - step is then usually a search either directly in the SAP community, on SAP support, or with a wider net via Google. The tricky thing here is to pick the search terms which provide just the right number of answers, neither too many nor too few and I really wish I had mastered that skill! Unfortunately, this is still a lot like playing "hit and miss" as I often don't find anything because my search terms turn out to be too restrictive or I get hundreds of hits as the search was way too unspecific.
But, even if these steps don't provide an answer, they should at least help with delimiting the scope of the question to be asked. In addition, information captured in the form of screen-shots and/or code-snippets when dealing with a technical issue will come in handy when actually composing the question.
Once I've run through my own research options without finding an answer, it's time to compose a question to be posted in Questions & Answers. The first task is to come up with a meaningful title for the question. Sometimes this is easy, it basically writes itself but sometimes it's more involved especially when it's not easy to boil it down into a simple "How do I ...." kind of question. I'll let you be the judge of how well stated - or not - my own questions thus far have been!
When composing my questions, I'm obviously hoping to get some answers but I also realise that I'm not entitled to get one, let alone quickly. In order to enhance my chances I put in as much - perhaps sometimes too much! - information as I can. This includes some combination from the following list:
My experiences with answers to my questions have been quite positive. I often received just the reply I was hoping for (like here, even within 1 hour!). Some fellow community members lent a helping hand to walk me through the steps patiently (like rob.dielemans and mike.pokraka here, here and here) or the question triggered a lively discussion like when I asked How to get contracted developers to read and adhere to development guidelines. Unless I forget or in rare cases where the answer or comment isn't actually relevant for my question I at least aknowledge responses by an upvote or like as a way to say "thank you for your time to provide an answer". More often than not, I also respond with a comment of my own to let the responder know how I'm making use of her/his suggestion.
Once the discussion has run its course, I'll try to pick the best answer. Sometimes, this is easy because there was exactly one helpful answer which "did the trick" and helped me solve my issue. At other times, it's not quite as easy. This can be the case when the final solution turned out to be a combination gleaned from various answers and comments provided by several community members. Whenever that happens, I add my own answer describing what I implemented and then pick that as the helpful answer. This is not ideal and I'd rather have an option to pick more than one answer as helpful to really give credit where credit is due. The other thing I've done is to add a comment to describe my next steps and to at least make use of @-mentions to thank the community members who helped me to get there.
What I rarely do now is to also close the question as I'd like to keep them open for further answers if anybody has them at a later point in time. This is in part due to the fact, that it's possible anyway to add further comments to closed questions, so what's really the point of marking them as closed?
So, that's my take on asking questions here in our SAP Community. What's yours? What has been working for you in order to get answers? How do you pick and chose the questions you then provide answers to?
- The Q&A About page
- A blog post by "Former Member" from 2010 about Asking Good Questions
- How To Ask Questions The Smart Way
So, what follows is my personal way of going about this and there'll be some overlap with these existing resources.
Why ask a question at all?
For me, there are different reasons to ask a question, like trying to find out why something isn't working, how others are dealing with a given situation or how a process could be improved to work better than it currently does. Some of the questions are technical in nature while others are more "philosophical". In all cases, my incoming assumption is that it's highly unlikely that I'm the first person running into the issue or having to deal with a particular situation. There are just way too many people working in the SAP environment for a question to be really unique. But, this doesn't necessarily mean that somebody actually asked the question previously or that he or she had received a response.
Add to that, that I've always been curious and eager to find out why something is working (or not!) and you'll understand why I actually like asking questions. Without asking questions - especially the "why" ones - we as a species wouldn't have evolved the way we did.
What to do before asking a question
Well, to state the obvious: do your due diligence before jumping in to ask your question! For me, this often entails some trial and error to see if I can figure out technical issues myself with the help of debugging or any of the other handy tools available to us like the performance analysis (SAT) or the SQL-trace (ST05). If that doesn't get me anywhere, I'll try to explain the issue to my colleagues in our programming and basis teams to find out if they have an idea or some further leads. The next - or even a parallel - step is then usually a search either directly in the SAP community, on SAP support, or with a wider net via Google. The tricky thing here is to pick the search terms which provide just the right number of answers, neither too many nor too few and I really wish I had mastered that skill! Unfortunately, this is still a lot like playing "hit and miss" as I often don't find anything because my search terms turn out to be too restrictive or I get hundreds of hits as the search was way too unspecific.
Search by Nick Youngson CC BY-SA 3.0 Alpha Stock Images
But, even if these steps don't provide an answer, they should at least help with delimiting the scope of the question to be asked. In addition, information captured in the form of screen-shots and/or code-snippets when dealing with a technical issue will come in handy when actually composing the question.
How to ask a question
Once I've run through my own research options without finding an answer, it's time to compose a question to be posted in Questions & Answers. The first task is to come up with a meaningful title for the question. Sometimes this is easy, it basically writes itself but sometimes it's more involved especially when it's not easy to boil it down into a simple "How do I ...." kind of question. I'll let you be the judge of how well stated - or not - my own questions thus far have been!
When composing my questions, I'm obviously hoping to get some answers but I also realise that I'm not entitled to get one, let alone quickly. In order to enhance my chances I put in as much - perhaps sometimes too much! - information as I can. This includes some combination from the following list:
- the system release we are on
- a description of what I'm looking for or trying to achieve
- what I already tried and the results of that
- what I searched for thus far
- what I already found out, if anything
- relevant screenshots, working from the premise that "a picture says more than a thousand words"
- code snippets if applicable
What to do once answers start coming in?
My experiences with answers to my questions have been quite positive. I often received just the reply I was hoping for (like here, even within 1 hour!). Some fellow community members lent a helping hand to walk me through the steps patiently (like rob.dielemans and mike.pokraka here, here and here) or the question triggered a lively discussion like when I asked How to get contracted developers to read and adhere to development guidelines. Unless I forget or in rare cases where the answer or comment isn't actually relevant for my question I at least aknowledge responses by an upvote or like as a way to say "thank you for your time to provide an answer". More often than not, I also respond with a comment of my own to let the responder know how I'm making use of her/his suggestion.
Once the discussion has run its course, I'll try to pick the best answer. Sometimes, this is easy because there was exactly one helpful answer which "did the trick" and helped me solve my issue. At other times, it's not quite as easy. This can be the case when the final solution turned out to be a combination gleaned from various answers and comments provided by several community members. Whenever that happens, I add my own answer describing what I implemented and then pick that as the helpful answer. This is not ideal and I'd rather have an option to pick more than one answer as helpful to really give credit where credit is due. The other thing I've done is to add a comment to describe my next steps and to at least make use of @-mentions to thank the community members who helped me to get there.
What I rarely do now is to also close the question as I'd like to keep them open for further answers if anybody has them at a later point in time. This is in part due to the fact, that it's possible anyway to add further comments to closed questions, so what's really the point of marking them as closed?
More questions for you!
So, that's my take on asking questions here in our SAP Community. What's yours? What has been working for you in order to get answers? How do you pick and chose the questions you then provide answers to?
- SAP Managed Tags:
10 Comments
