- SAP Managed Tags:
Does the "who" drive how you work? How not what priority. Do you work differently with them according to what you know about them?
So if you know the person you are working with you can determine how to work with them based upon different things. I tend to in general group them into 4 different groups in my mind.
Group 1: The problem is exactly as they stated almost all of the time.
Group 2: It may or may not be an issue. After around 2 hours they figure it out.
Group 3: Usually they just need training. Of course, you have to prove it by the data.
Group 4: Will never believe you.
I'm sure there other groups. Of course, people change groups depending on what area they are working in. And of course the day might make a difference or the weather or... But in general you know them well enough to know what group they fall into.
Group 1:
Ask them about it. Have them tell you what they think isn't working and get to work looking at your code or your configuration.
Group 2:
If you have to fix it quickly - then you'll want to do the same as group 1. If you can wait a bit, then do so, the problem may not be an issue. If it still is, I start by looking at the data. The code/configuration comes next.
Group 3:
Start with the data. Ask them exactly how they did something. Skype is my friend at that point. Dig around, usually you'll find the issue. If not then back to the code/config. It may be that you would want to put together some training documents.
Group 4:
I have to love this group. Why? Because they are so very cynical. If you can get some examples from them. If not start by calling a co-worker that does the same job from one of the other groups. If you get the examples it's hard to know if it is data or it is code/config. I try data, but if it doesn't show up soon enough - right on to the code/config. Once you find the error (training, bad data, or code/config) you'll try to explain they might surprise you and fall into one of the other groups. If not, you'll have to phone a friend. Show a co-worker the change, training... Then ask they to show the person in group 4.
Group 1:
Yes! Fist pump. They usually know what they want. They can explain it well too. i usually still have some questions, but things move rather quickly. I'll let them lead and then ask the questions I have.
Group 2:
This is still a great group to work with. They know what they want. However, I spend more time on the questions. I try to draw things out so they know exactly what the project will look like. In my own scribbles at this point.
Group 3:
I start with getting a general idea from them. I generally get this before a meeting. Then I draw something up. Next meet with them and ask questions. Refine the drawing and more questions. Remember this is just the beginning.
Group 4:
Phone a friend. Get more than just that group in the meeting with you. Then basically I follow the same route as group 3. I meet with them before the meeting. Next I'll have a general idea and meet with my friend before the meeting. If at all possible have your friend with you at the meeting.
All of the rest of the requirement steps are the same for all of them. I usually have a straw man drawn out before the requirements are complete, but that depends on the size of the project.
Who loves documentation? Well actually I do. I just don't love creating it. But if a question is coming up many times, it makes sense to create some training documents. I do that. Then based on questions about the document, I will refine it. For new projects - it depends on how big they are. If it is big enough, their are people dedicated to creating it. Otherwise it becomes very important to have some training documents. You'll find that there will be questions and perhaps new requirements from them. Depending on the request it may be set up as an enhancement for a later date.
And yes, I try to create functional requirements, technical requirements, test documents AND training documents. There sometimes just isn't enough time. You might argue I have to have them all before I start. I do have the functional requirements before I start usually written by me.
So for me, sometimes who you are matters to me. Honestly if you are one of the people at the top of the food chain and you say drop everything, I will. If you have a requirement it is met. The first time if at all possible.
It matters who I work with. They change groups depending on what I'm working on. But it is a huge benefit to know how they work.
Now I hope to generate many comments. Does who you work with, matter? Are there more groups you would add?
Side Note:
Yes, I have read - "Who Moved my Cheese". Well worth the read.
Know your business users:
So if you know the person you are working with you can determine how to work with them based upon different things. I tend to in general group them into 4 different groups in my mind.
Group 1: The problem is exactly as they stated almost all of the time.
Group 2: It may or may not be an issue. After around 2 hours they figure it out.
Group 3: Usually they just need training. Of course, you have to prove it by the data.
Group 4: Will never believe you.
I'm sure there other groups. Of course, people change groups depending on what area they are working in. And of course the day might make a difference or the weather or... But in general you know them well enough to know what group they fall into.
The Break/Fix:
Group 1:
Ask them about it. Have them tell you what they think isn't working and get to work looking at your code or your configuration.
Group 2:
If you have to fix it quickly - then you'll want to do the same as group 1. If you can wait a bit, then do so, the problem may not be an issue. If it still is, I start by looking at the data. The code/configuration comes next.
Group 3:
Start with the data. Ask them exactly how they did something. Skype is my friend at that point. Dig around, usually you'll find the issue. If not then back to the code/config. It may be that you would want to put together some training documents.
Group 4:
I have to love this group. Why? Because they are so very cynical. If you can get some examples from them. If not start by calling a co-worker that does the same job from one of the other groups. If you get the examples it's hard to know if it is data or it is code/config. I try data, but if it doesn't show up soon enough - right on to the code/config. Once you find the error (training, bad data, or code/config) you'll try to explain they might surprise you and fall into one of the other groups. If not, you'll have to phone a friend. Show a co-worker the change, training... Then ask they to show the person in group 4.
New Project - Requirements:
Group 1:
Yes! Fist pump. They usually know what they want. They can explain it well too. i usually still have some questions, but things move rather quickly. I'll let them lead and then ask the questions I have.
Group 2:
This is still a great group to work with. They know what they want. However, I spend more time on the questions. I try to draw things out so they know exactly what the project will look like. In my own scribbles at this point.
Group 3:
I start with getting a general idea from them. I generally get this before a meeting. Then I draw something up. Next meet with them and ask questions. Refine the drawing and more questions. Remember this is just the beginning.
Group 4:
Phone a friend. Get more than just that group in the meeting with you. Then basically I follow the same route as group 3. I meet with them before the meeting. Next I'll have a general idea and meet with my friend before the meeting. If at all possible have your friend with you at the meeting.
All of the rest of the requirement steps are the same for all of them. I usually have a straw man drawn out before the requirements are complete, but that depends on the size of the project.
Documentation:
Who loves documentation? Well actually I do. I just don't love creating it. But if a question is coming up many times, it makes sense to create some training documents. I do that. Then based on questions about the document, I will refine it. For new projects - it depends on how big they are. If it is big enough, their are people dedicated to creating it. Otherwise it becomes very important to have some training documents. You'll find that there will be questions and perhaps new requirements from them. Depending on the request it may be set up as an enhancement for a later date.
And yes, I try to create functional requirements, technical requirements, test documents AND training documents. There sometimes just isn't enough time. You might argue I have to have them all before I start. I do have the functional requirements before I start usually written by me.
Does it matter to you?
So for me, sometimes who you are matters to me. Honestly if you are one of the people at the top of the food chain and you say drop everything, I will. If you have a requirement it is met. The first time if at all possible.
It matters who I work with. They change groups depending on what I'm working on. But it is a huge benefit to know how they work.
Now I hope to generate many comments. Does who you work with, matter? Are there more groups you would add?
Side Note:
Yes, I have read - "Who Moved my Cheese". Well worth the read.
12 Comments
| User | Count |
|---|---|
| 14 | |
| 8 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 |
