How Support Works and Communicates with the Product Teams
| Microsoft's support organization is complex, with several sites around the world. Without going into a lot of detail about how CSS is structured, I would like to take you through a typical support call and show how support is connected to the product groups and eventually hits the build team. For further details about CSS, go to http://support.microsoft.com. Support uses the terms incident, case, issue, or Service Request (SR) interchangeably to track support requests that come in via phone call, Internet, or e-mail. Many companies use the term ticket or ticket number to track the support you request from them. We do not really use the ticket terms but do assign an SR number to every case that is opened. After the support incident is opened, it is routed to one of the thousands of support professionals (SP) or engineers (SE) who work with the customer to resolve the incident. If the incident is too difficult for the SP or SE to solve, he escalates the incident to the next tier. This is usually a more senior SE or leader who answers the question. This person is usually called an escalation engineer (EE). If the incident is resolved, the person working on the incident asks the customer if he is "very satisfied" and if it is okay to close the case. If everything is fine, the support person closes and archives the incident. If the EE cannot solve the problem, he requests help from the product group that owns the application or code that seems to be causing problems. Usually at this point, the case goes through a critical problem resolution (CPR) team in CSS that communicates with the development teams in the product groups. The CPR team determines whether a hotfix is needed and sees if resources are available and what the timeframe is to deliver the hotfix to the customer. Note that the product groups always provide the hotfix. The CPR team members can help debug or suggest where in the code they think the bug exists, but they never actually check the fix into the source trees. It's also important to note that it is at this point when the product group is brought in to help that the incident is given a bug or work item tracking number. This number is independent of the SR number that was assigned at the beginning of the support or service request. The work item tracking number is usually not shared with the customer because it is for internal tracking purposes only. Most product groups at Microsoft have a quick-fix engineering (QFE) team that handles the requests from CSS for a hotfix. The QFE team is dedicated to delivering hotfixes and service packs to CSS and customers. The QFE teams exist so that the product group developers can focus on writing code for the new releases. Now that we have a bug or work item number, the whole process discussed in Figure 1.2 in Chapter 1, "Defining a Build," begins. Usually a program manager owns the bug and takes it to the WAR meeting for approval. At this point, Figure 1.2 will give you through the life of the bug. This process has evolved over many years of trying to create the best and fastest ways to help Microsoft's customers without constantly interrupting the product group developers from writing code. You can see how this hierarchical process works and how support personnel must follow each step for opened incidents. Most of the incidents opened are resolved with the first-tier support professional or engineer answering the question.
|
EAN: 2147483647
Pages: 186
- Key #1: Delight Your Customers with Speed and Quality
- Key #2: Improve Your Processes
- Beyond the Basics: The Five Laws of Lean Six Sigma
- Making Improvements That Last: An Illustrated Guide to DMAIC and the Lean Six Sigma Toolkit
- The Experience of Making Improvements: What Its Like to Work on Lean Six Sigma Projects