Cary Millsap posts a brilliant article about his approach to performance troubleshooting that resonated loudly with me.
When I first started working at Siebel, a standard review was a production health check that consisted of meetings with key project staff (Siebel Administrator, DBA, systems and network admins, project manager, developers) coupled with some standard checks on key Web, Siebel and Oracle configuration parameters.
At the tail end of one engagement where I had precious little to note or report on, I asked to meet with an end user for a brief chat. The response was surprising and not dissimilar to the standard retorts Cary describes.
-
‘Talk to a user ? Why on earth would you want to do that ?’ (delivered with suspicious frown)
-
‘The user won’t understand your questions.’ (patronising)
-
‘The users don’t understand the business requirements.’ (surprising and worrying)
-
‘The users are too busy.’ - ‘Can’t you just talk to a supervisor instead ?’
Of course, most of these responses are instinctive, defensive measures, immediate responses to what is probably a rather unusual request and, to be fair and in the interests of balance, I have been introduced to end users by development staff who do know and obviously have a healthy relationship with the user community.
If and when I succeeded in getting an audience with an actual user, I didn’t actually chat at first. Instead I introduced myself and simply asked if I could watch the individual use the system for 10 minutes.
It was often very enlightening just to sit quietly and observe the business process (typically, handling an inbound call at a call centre), the subset of available screens accessed by the agent, typical searches executed to locate data, actions they expected to be slow, actions they needed to be fast, common tasks they did frequently, lengthy interactive queries that were truly batch reports as well as interactions with other applications.