You begin the day by doing the two tasks (T1 and T7) that customers expect to happen quickly and that most certainly will hold up other, larger projects. You succeed in meeting the perceived amount of time these tasks take.

The next task (T5) involves a 'hurry up and wait' situation. No matter how quickly you order the item, it is going to take a day or two to arrive. Putting the order through sooner rather than later can prevent a lot of dissatisfaction on the other end.

Your next task (T4) is done in 30 minutes. Check.

Task T2 doesn't take very long, but the expectation for a new user account to be created is usually not measured in minutes and hours, but in deadlines. If the person's first day on the job is tomorrow, it is expected that her accounts will be created before she arrives, whether it takes one minute or one day, whether you do it early or late in the day. However, since the task is deadline driven, it is important that it gets done.

If there were an outage (caused, possibly, by two hosts being configured for the same IP address), and all work stops to fix an outage, the previously outlined schedule would be disrupted. However, I would still work to meet the expectation that the new account be created before the person arrived. Other tasks might be delayed for a day, which is understandable given the major outage. But for a task like creating an account, I would stay late rather than miss the deadline.

Installing a new server (T3) is one of those 'black hole tasks.' It should take a few minutes to mount the server in the rack, maybe an hour to load the operating system, a little longer to configure the system. At least vendors seem to think that's true. We system administrators know that it's never that easy. The first time you rack mount that particular product, it always takes hours to figure out the oddball mounting system the vendor has created. Server operating systems are often loaded, erased, loaded, erased, as you carefully adjust settings each time to get things just right. (This box is going to be around for years, so we might as well invest some time in getting things right.) Finally, configuration never goes as quickly as we hope it will. Therefore, we leave these black hole tasks until after we've completed the tasks that are expected to happen quickly.

We bent the prioritization rules for the last task (T6). Based on the expected time for completion, one would think I'd have done it earlier in the day, perhaps before or after T3. However, at every site I've worked at, Usenet NetNews is considered a low priority, recreational activity provided as a bonus to employees. (I've never worked at an ISP, where the situation may be different.) Thus, fixing a minor issue with it is a low priority and goes to the end of the list. The general rule is: when all parties agree that a task is low priority (or there is a management edict), move the task to the end of the list. Think of it this way: if someone complained that one of the other tasks wasn't completed, would you want to stand in front of your boss and explain that the customer's request was delayed because you were fixing a minor issue with Usenet? No, not at all.

Simple? Sure. It can take a little practice, but your customers will notice the difference.

Delegate, record, do revisited

When I explain this system to people, the main objection I hear from them is that their to do list is not static. They do not begin their day with a fixed list of things that need to be done. New items are added to their list all day.

That's why we use the delegate, record, do technique from Chapter 2 for dealing with interruptions. We can use our customers' expectations to influence which of these three actions we take.

A request for resetting a password should happen quickly because it's holding up other work. Therefore, it might be faster to do it than to delegate it to someone else. And you certainly don't want to record the task for later when it means delaying a person's entire schedule.

Mutual interruption shield revisited

Not only does this technique work for prioritizing your personal to do list, but you can use it to plan on a larger scale. Use it to organize your entire computer support department!

Remember the mutual interruption shield technique from Chapter 1? Essentially, you implement this system to make sure that people's expectations are matched. Your coworker catches all interrupts for half of the day so that you can get projects done, and you reverse roles for the other half of the day. What you're really doing is making sure that there is someone to do the tasks that customers expect will happen quickly.

Most helpdesks have Tier 1 members who answer the phone and only push an issue to the Tier 2 staff when they are stumped. This is, essentially, creating a mutual interruption shield for the entire team while providing response times that match customer expectations!

Prioritizing based on customer expectations and using the mutual interruption shield replicates the helpdesk tier system, which validates the combination. Or, one might say that the tier structure is validated by the fact that it aims to reach the goal of meeting customer expectations. Either way, it's pretty cool,

Добавить отзыв
ВСЕ ОТЗЫВЫ О КНИГЕ В ИЗБРАННОЕ

0

Вы можете отметить интересные вам фрагменты текста, которые будут доступны по уникальной ссылке в адресной строке браузера.

Отметить Добавить цитату