Faced with a new task and an eight-hour deadline, do you: a) spend seven and a half hours building a tool to do the job and thirty minutes using it to deliver the result, or b) spend all eight hours working up something that does the trick but can't be re-used?
If you answered a) you are probably an engineer at heart, whereas b) is what everyone else does.
I once spent four days automating a large spreadsheet we used for a weekly report: it had twenty sheets and thirty pivot tables fed from separate SQL queries on a mainframe database. Most of the time was spent on the Query and Pivot Table object models, where the lack of a decent manual had me going round in circles. The report took me about forty-fifty minutes each week to do manually. Over fifty weeks, that's about the same number of hours I spent on the automation. Why bother? Because I learned a lot of new stuff and got practice on the Excel object model (I'm an Access whiz); anyone else could do the report when I was on holiday; I could produce the report faster and more accurately each week, which was what the boss wanted.
One way people make progress is by making tools so they can do in an hour what used to take all day. That way, they have the rest of the day to do something else. And a "tool" is anything that helps you do the job: it might be a piece of software, but it might be a report, your mobile phone, or indeed something you buy in the hardware or kitchen store.
A good tool should be: intuitively obvious to the person who might use it; robust; easy to maintain and modify; and let people do the job in less time and with less effort than they it did before.
Never use IT departments and outside contractors to develop tools for you: what they produce will fail all those tests. And it will cost a fortune.
No comments:
Post a Comment