That sounds interesting. Could you provide some examples?
Well, one of the more obvious social pressures was the WCD metric, which showed up at the case and queue levels as part of the normal display. Cases were advisory-locked by working on them, and this information was shown as part of the queue display, making it obvious who’s working on something that’s part of a case, and who’s not. The last person to send a response to the customer was visible, to encourage people to prefer to continue work on the same case, but to take over if the person isn’t around. The WCD metric was also designed so that a customer never had to wait in queue a second time due to needing to email back for clarification, since what WCD measures is how long customer(s) are waiting for the resolution of an issue, rather than the duration of a single pass through the queue, or how long the customer sat around between responses. IOW, WCD was a “chess clock” timer, such that a response by the company stopped the timer until the customer made another move.
One of the viral aspects was that it was extremely easy to do all sorts of interdepartment workflows, but nobody was penalized for foreign WCD. If you transferred a case that the customer’s been waiting three days on, every department that sees it is going to prioritize it as if it’s been waiting three days, even if they’ve only just seen it now. The ease of relationship made departments demand that any department they relied upon use it, since it meant they could immediately begin a customer response as soon as they got what they needed. And departments that were receiving delegations by email from other departments, wanted to get on it so they could track the stuff.
I arrived at these design features by starting with the fundamental design dynamic of groupware, which is that nobody will ever do any work to put information into groupware unless they perceive a benefit to themselves. ;-) (There are some other dynamics, of course, but they’re not coming to me at the moment. I do not really design by consciously factoring all these principles; my designs are the output of searching for ideas within an intuitive space roughly defined by the principles.)
I used a similar set of principles in the design of WSGI and setuptools, in the sense of taking into account certain social/investment dynamics for WSGI, and prisoner’s-dilemna/viral adoption principles for setuptools.
What does WCD stand for? (“whole case delay”?) Are we supposed to know? If you mean for it to be opaque, you could signal that by putting it in quotes (“WCD metric”) the first time.
What does WCD stand for? (“whole case delay”?) Are we supposed to know? If you mean for it to be opaque, you could signal that by putting it in quotes (“WCD metric”) the first time.
Hm, I could’ve sworn I spelled it out somewhere abovet, but can’t find it now. “Weighted Customer Delay”. It’s roughly analagous to TDD (Throughput-Dollar-Days) from the Theory of Constraints, only measured in customer-hours rather than dollar-days.
Well, one of the more obvious social pressures was the WCD metric, which showed up at the case and queue levels as part of the normal display. Cases were advisory-locked by working on them, and this information was shown as part of the queue display, making it obvious who’s working on something that’s part of a case, and who’s not. The last person to send a response to the customer was visible, to encourage people to prefer to continue work on the same case, but to take over if the person isn’t around. The WCD metric was also designed so that a customer never had to wait in queue a second time due to needing to email back for clarification, since what WCD measures is how long customer(s) are waiting for the resolution of an issue, rather than the duration of a single pass through the queue, or how long the customer sat around between responses. IOW, WCD was a “chess clock” timer, such that a response by the company stopped the timer until the customer made another move.
One of the viral aspects was that it was extremely easy to do all sorts of interdepartment workflows, but nobody was penalized for foreign WCD. If you transferred a case that the customer’s been waiting three days on, every department that sees it is going to prioritize it as if it’s been waiting three days, even if they’ve only just seen it now. The ease of relationship made departments demand that any department they relied upon use it, since it meant they could immediately begin a customer response as soon as they got what they needed. And departments that were receiving delegations by email from other departments, wanted to get on it so they could track the stuff.
I arrived at these design features by starting with the fundamental design dynamic of groupware, which is that nobody will ever do any work to put information into groupware unless they perceive a benefit to themselves. ;-) (There are some other dynamics, of course, but they’re not coming to me at the moment. I do not really design by consciously factoring all these principles; my designs are the output of searching for ideas within an intuitive space roughly defined by the principles.)
I used a similar set of principles in the design of WSGI and setuptools, in the sense of taking into account certain social/investment dynamics for WSGI, and prisoner’s-dilemna/viral adoption principles for setuptools.
Thank you, that’s very interesting. I need to remember those techniques, some of them may come in handy later on.
What does WCD stand for? (“whole case delay”?) Are we supposed to know? If you mean for it to be opaque, you could signal that by putting it in quotes (“WCD metric”) the first time.
Hm, I could’ve sworn I spelled it out somewhere abovet, but can’t find it now. “Weighted Customer Delay”. It’s roughly analagous to TDD (Throughput-Dollar-Days) from the Theory of Constraints, only measured in customer-hours rather than dollar-days.