Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

Re: OT: Getting people to use tools

by halley (Prior)
on Apr 30, 2003 at 20:49 UTC ( [id://254462] : note . print w/replies, xml ) Need Help??

in reply to OT: Getting people to use tools

You've already answered #1 and #2, just bear with me.

(1) Were you assigned to make the tool BY the future users? (Or was it by some lead figure or boss?)

(2) Does your tool get exactly the same results as what they got, only with fewer steps?

(3) If not, then why did you make a tool for them?

You can't change other people's behavior. They'll use the tool if they feel like it. Most people don't want to change their existing methods for some new method they haven't used, even if they don't like their current approach or results.

Update: If all of your managers sign off, and you decide that it's for the best, then "break" the other users' existing methods: change the system so their old methods won't work anymore. They'll start coming to you with the "now, how does this work again?" questions.

[ e d @ h a l l e y . c c ]

Replies are listed 'Best First'.
Re: Re: OT: Getting people to use tools
by logan (Curate) on Apr 30, 2003 at 20:58 UTC
    1. The initial assignment came from a manager. Since her departure, 2 subsequent managers have weighed in saying they want this.
    2. The tool gets the exact same results, and gives the option for more (install the build, give option to populate the system, option to run automatic build acceptance testing). And, instead of 30-40 steps, it's one step.

    Worse, this isn't an isolated instance. I've created dozens of tools, large and small, and I get the same thing every time. I don't think it's the technology that's an issue. I think it's attitude and mindset, which are far more difficult to change. Honestly, this isn't so much a perl question as a social engineering question, and I am both frustrated and baffled.

    -Logan, turning into Wally
    "What do I want? I'm an American. I want more."

      I feel your pain. A lot of my job is project work/tools. While they are adopted and used some of the time, some of them just sit there.

      I think the key thing for tools like that is not only management buy-in, but a policy that says it must be done that way. If using your tools are optional, people will do things the same way just to avoid learning something new. Something that I find useful in getting people to adopt something new is documentation. If they've got a reference (especially a quick reference), it seems to help.

      It is a weird phenomena though... You hand somebody something that will make their lives much easier and they'd rather to do it manually.

        When I want to watch TV, I turn on 3 devices with different remote control units, and configure them to the current task.

        I bought a fancy omnipotint remote a few years ago, and never used it again after the batteries ran out.

        Why? Nice idea, but they missed a few issues. First of all, a touch-screen is pointless when I operate it by feel alone. Worse, I have to turn it to face me to read the LCD screen, but upon doing that the IR emitter is pointing upward; I have to locate the touch spot then turn it sideways to by vision then "push".

        I'm sure the designers went to great length to make it interface with a PC and download codes from everything and have macros that work properly and state-changes and all that good stuff. But it doesn't work at its basic task! And for reasons that are not related to any of the things mentioned on the box, or probably mentioned on their product requirements document.