If you put a developer in the meeting they'll be expected to come up with a solution for drawing 3 perpendicular red lines with transparent ink.
On Wed, Apr 23, 2014 at 10:06 AM, Rick Westbrock <[email protected]>wrote: > Past experience has shown me that a BSA to interface between the end > user/client and the developers is very helpful but most times as a > developer I have found it invaluable to be in a requirements gathering > session with the BSA and the end users to make sure nothing is missed. I > can also get instant clarification on a request rather than going back and > forth using the BSA as the messenger. > > -Rick > > _________________________ > Rick Westbrock > Remedy Administrator | IT Department > 24 Hour Fitness USA, Inc. > > > > -----Original Message----- > From: Action Request System discussion list(ARSList) [mailto: > [email protected]] On Behalf Of pritch > Sent: Tuesday, April 22, 2014 3:37 PM > To: [email protected] > Subject: Re: Remedy Support Team Hierarchy > > Maybe it's just a training issue - I don't think developers should be > making a habit of dealing with end users. It takes time for the client > facing person to learn (and in reality, they probably don't want to learn) > what the developers knows or what they need to know to research a problem. > However, a go between in most cases is not an issue. > > The situation I deal with currently is where there is a department of > folks (4 of them) that do all the client facing on issues - anything they > cannot figure out they discuss with me - I give them a list of items to > find out and they go and gather the information. The interaction helps in > them learning how to work with the clients, gather the information and > eventually solve similar problems without bringing me in. The only time I > speak directly to the users (besides when presenting a training class) is > if we cannot solve it and I need to see what is happening (beyond > screenshots). At that point the client facing folks set up a webex and > lead the live meeting. When we first stood up the system I was very active > in the troubleshooting but now I don't know about most of the calls they > field. In fact, recently they've started taking on more of the > adminstrative work such as adding users, maintaining menu lists, etc. Just > takes time and patience to get those folks up to speed. > > Of course if the person that is performing the client facing activities > isn't interested or capable of learning how to support the users, then that > may be an issue that needs to be discussed with management. > > just my two cents. > > ----- Original Message ----- > From: "Lisa A DLA CTR INFORMATION OPERATIONS Kemes" < > [email protected]> > To: [email protected] > Sent: Tuesday, April 22, 2014 2:13:43 PM > Subject: Re: Remedy Support Team Hierarchy > > Kathy, > > Sounds rough, but I think you are in good company with a lot of us. I'm a > contractor and so when an end user says they are having a problem with > "opening a form and saving it" there are about 1000 questions I have for > the end user, but that's what the Project Manager writes down and > communicates to us. Plus, I want to make sure I recreate the problem > EXACTLY as the customer is experiencing it (so I know what workflow to > look at). > > Can I just pick up the phone and contact the end user? Nope, I have to > work with ANOTHER contractor that asks the Program Manager of Remedy the > questions I have, who then asks the end user. This process can take up to > 4 weeks. It's awful, plus, because I'm not part of the conversation, I > can't ask follow up questions right then and there. > It's painful. Sometimes, I'm able to ask the Program Manager directly, > but what I'd really like to do is get to that end user. > > I think there are a lot of us in the same boat. > > Lisa > > -----Original Message----- > From: Action Request System discussion list(ARSList) [mailto: > [email protected]] On Behalf Of Kathy Morris > Sent: Monday, April 21, 2014 4:53 PM > To: [email protected] > Subject: Remedy Support Team Hierarchy > > ** > > Hi, > > > > Our Remedy team is having its challenges. Our Management has placed a > person who has no technical clue about Remedy, or any aspect of software > development to manage the critical Remedy Projects. Management seems to > think that you do not need Remedy experience to manage these type of > projects, all you need is the ability to go out there and ask questions, > chase info down. The problem is: 1) this new person does not even > know the right questions to ask, and 2) cannot articulate the answers. > When the developer explains things to this project manager.... It's like > us talking to a piece of sheetrock. By the way, most of the "ideas and > processes" this person has begun to build is without leveraging the > knowledge of the Remedy Developers J No information, new processes are > even discussed to the developers. Unreal. I have not even mentioned > the fact that the individual does not get along with 95% of the team. > This individual is completely different Management so they think they have > rescued us J > > > > What is the Remedy team structure like in other organizations? What roles > are there? My experience has been Director of Technology, Remedy Team > Lead, developers, admins, business analyst.... These type of roles. > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the > Answers Are, and have been for 20 years" > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the > Answers Are, and have been for 20 years" > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
