[ Previous entry: "Godwin's Law" ] [Main Index] [ Next entry: "Trapped in the Closet" ]
|
03/03/2004 Entry: "Work professionalism"
Sometimes, people at work amaze me. Trying to delve into the psyche of some of these so-called "professionals" leave me guessing as to just how these people have gotten as far as they did with their work. I mean, most of the people I deal with are smart, pleasant, and professional. Most of them understand the "truth of data" concept, and when they come to me to have my team check our equipment, they are pretty certain that something went wrong, and have data to prove it. We try and catch such errors before they end up in reports, but sometimes none of us sees that one machine went bad, and it gave really bad results unnecessarily. But those are corrected, and we move on. We rarely make mistakes, and most people know and trust that, but some people never seem to learn that we have data on our side, and to prove us wrong, they have to have solid data that contradicts our data. We have this girl at work, I'll call her Susan. She's an analyst. I am not sure what kind she is, but whenever I do reports for a customer, she always comes to me and debates my reports. She's supposed to work for the customer, but it's apparent that she's easily bullied by the network carrier. "Grig," she says in her annoyingly submissive voice, "last weekend, you tested some numbers for our customer, and it showed that the MCI lines they used are getting busy signals during peak periods. Now we called MCI, and they said there's no reason for the busy numbers, and I called those numbers myself today, and I got right through. Can you fix your testing equipment?" I usually don't do these reports, but the girl who did them was out sick, and when I asked her about Susan a year ago, she said, "No, Susan never comes to me with problems..." These reports are not rocket science, they are scripts that collate the data, put them in a spreadsheet, then pivot tables them, and it gets mailed out. All I do is make sure the data isn't bad, and make sure the scripts ran with no errors. So, no. I don't care what MCI said, that's what our testing equipment reported. The testing equipment is not broken. If it was broken, it would have showed busy numbers for all carriers during that period. All it showed was that MCI busied out during a heavy usage period on Saturday night. MCI was not busy at any other time, and no one changed anything on the test machines. Just because the number works now does not mean it worked Saturday night. "Yeah..." she said, like MCI had a gun to her back, "but can you check anyway?" I checked, and the lines were reporting busy at that time, according to six different testing systems. "Well, we'll just have MCI come and attach some testing equipment of their own, and they will sit there and watch your systems!" she said, as if I'd backpedal. Not watch my systems, no! That would be funny, because only one of them has a monitor, so all they'd have to sit and watch were hard drive lights blinking on and off. "Okay," I said. "Speak to [these people] for computer room access, and let them know what time MCI will be there, and when you have that set up, I'll show you where these systems are. Keep in mind, too, that MCI is contractually obligated to this customer to have a low percentage of busy-outs, and so denial of any data that says otherwise is in their favor." She never got back to me. I think she's an MCI plant. Years ago, we had a Canadian customer who wanted us to test some of their phone lines. We weren't sure who got those reports, because that company had a very high churn rate among project managers. One manager sent me an e-mail that said, "Your testing indicates that there are problems in Toronto. This does not look good for us, since half our lines are in Toronto. Can you please eliminate any non-connect results from future reports?" Uh ... you are paying us to test your network, but don't want us to include failures? Things got pretty bad there, and for a while, it looked like I'd have to come up and meet face-to-face with some executives to explain exactly what we did, and why "cooking the data" was not a good idea. But then they decided that they would do their own testing, and I'd have to come up and show them how to do it. My company did not send me, and we don't test for them anymore... Phone carriers lie with incredible audacity. Some better than others. I have been in meetings where carriers just make up stuff on the spot, and it's pretty obvious. Back when I programmed for a call center, we lost all of our call centers on Sprint for 8 hours during a peak event when our tech call centers were getting slammed. Big chief executives wanted to know why, and as a programmer, I had to sit in and translate into plain English. This was because Sprint often used "baffle them with tech BS" to confuse and redirect the issue. After an hour of interrogation and constantly having to get them back on topic, we narrowed the excuse down to one large switch Sprint called a DMS250. Think of the DMS250 as turnstiles at an amusement park: it regulates flow, and counts how many people have passed, and thus, a rough idea of how many are in the park. One of the things this switch must do is regulate intake of incoming calls, and that's usually measured by calls per second (cps). Sprint: So, as you can see, the voltage spike in the data stream at the time-- The Sprint guy actually did start screaming at us, almost in tears. Very unprofessional. Even his Sprint buddies were a mix of looking out the window in embarrassment or trying to get him to sit back down. These weren't some off-the-street techs, either. The screaming guy was the head customer service representative for Sprint for our company. He easily made six figures. Later, we got an apology from Sprint for his behavior, and while he was still our main Sprint contact for a while afterwards, they always sent another guy to deal with face-to-face issues.
|
