Slashdot Mirror
How Would You Document Your Job?
Q3vi1 asks: "As an support technician, there are several things I've learned about the environment I work in that would be difficult to find out without hours of research. Now I'm going to be moving and that means getting a new job. Before I do, I'd like to leave behind some of this information for the person who will replace me. How does one document all the details in an efficient manner for the next tech?"
envelopes.
You are being MICROattacked, from various angles, in a SOFT manner.
Good for you! You've got yourself a wonderful job as my replacement. As a congratulations gift I would like to leave you with the knowledge I've gleaned from my time here.
Imagine the best possible place you could work. Imagine people working together, sharing information in a timely manner, and open to constructive criticism. People working together to not only make a profit, but make a humane profit. People who care about the customer, each other, and the world in general. People who feel that the workload should be spread over all nations so that everyone can have a job, an income, and a healthy life.
Now imagine the reverse. Welcome to the team, sucka'!
and do it all in l33t...
flinging poop since 1969
why would you want to do this? are they paying you a bonus if you do this? is it in your contract? is the new guy a friend of yours?
just curious. I would just up and leave and let them figure it out (but I usually keep good ongoing documentation so I'm not really being as much of a dick as it sounds).
but it is a good question, why do something you don't have to do, especially when it comes to business?
The best thing for you to do is set up a Wiki. It will be very easy for you to write down your stuff. Whether in big chunks or in little "Oh, I should write down this little thing before I forget". And it will be easy for your successors to continue keeping the docs up-to-date.
A Multiplayer Strategy Game for Mac OS X, Windows, and Linux
I've prepared a 'quirks' document of everything (IT) unique to the company that you couldn't get from a reference book. If someone new needs anything more, they shouldn't have been hired.
People who feel that the workload should be spread over all nations so that everyone can have a job, an income, and a healthy life.
What makes you think that if all the workload was spread evenly throughout all nations that everyone would have a job, an income, and a healthy life?
Anything at all backing that up?
Having had this responsibility before, let me tell ya, it's easy.
Make a document with headings about each part of the company you know about (Departments, Management, Placing 1-900 Calls Unnoticed, etc.) and then, very simply, just talk about it. Such as:
Departments
Accounting tends to only make itself known when you need something critical and then they cry wolf. When this happens contact their manager, Foo B. Baz, and let him know what's happening. He'll kick someone's ass and get the PO through.
Sales lies. Repeatedly. If one of them calls you with the customer already on the line (and they will) and says something to the order of "we do X, right? Of course we do!" talk over him and explain why he's an idiot. With the customer there. It will be the last time that particular person calls you like that. Sales management will harass you, but just refer him to your manager and move on.
And so on, and so forth. Just a simple heading/topic document. Print it up and leave it in a drawer somewhere the next sucker will see it.
But he's leaving now. Any "up-to-date" is already gone.
The best way to have valuable knowledge is to gather it continuously and write it down in a consistent format. This way you both have documentation for your successor when you leave with advanced notice, and when you leave due to the 26 Speed Bus to Downtown doesn't notice you crossing the intersection. Not to rag on the good intentions of the original poster of this article, but isn't this a little late to start documenting?
Perhaps leaving a consistent documentation system to start from might be one of the most valuable assets he can leave the company -- for the gal after the guy after him.
You like splinters in your crotch? -Jon Caldara
The first part is easy enough: just write down what you think a new person would need to know. The second part is hard: organizing all the information so that he can find it. Unfortunately, I don't have too much advice on how to go about organizing things.
Software sucks. Open Source sucks less.
How about not documenting your job? Then when your replacement finds out he can't do what you did you can get hired back as a consultant for triple the pay.
Don't document anything. It's called job security, you fool!
1 Learn Hindi
2 ???
3 Profit
I have mod points and I am not afraid to use them
First, write everything down. Don't worry about organization at this point. Just get all of your thoughts down before you forget them. Next, determine the two or three keywords that categorize each tip and use those for the organizing things. Remember that things will fall into multiple categories. Use these categorizations to build up a comprehesive index into you tips. And there you have it.
The most important thing to remember is that you're writing this for someone else coming along, so tips need to be short and to the point and easily locatable. Basically, you're writing an O'Reilly "Cookbook" style document for your job.
I don't know what type of support position you are in, but I'm a sr. support technician at a networking company myself. If you are in such a position, the best thing is to spend what little time you have writing faq's for people, providing the best (but concice) description of how to do various tasks you do on a daily basis, and provide any documents you reference on a regular basis to those that will replace you. On the other hand, it would probably take as long as you have been working for the company to document everything you learned, so you have to be able to narrow it down to what is really important. Good luck on this task, and good luck on your new job!
Document everything out of the ordinary. Summarize the rest, the obvious. Assume they know or can quickly figure out the basics and tell them everything you expect to give them trouble. And attach your email address to the documentation.
Small detail. You will only ever find this kinda of documentation for obsolete projects. Nothing current will have this. Ever.
Personally I try to avoid writing documentation nowadays. In my line of work (webdevelopment) there isn't any time/budget to write documentation let alone keep it uptodate. I generally find it more usefull to tell a new person the internal details of the company then the details of the code. If they are any good they can figure out the code. Figuring out a new company is a lot harder.
For the guy I am going to replace, please document who is responsible for what, who actually takes responsibilty, who is the suckup, who is the guy/gal actually making the decisions and how much of a nutcase the boss is. Your code I can always rewrite.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
After years of having to learn the same things over and over because I didn't document things as I did them I have come up with a plan that works well for me. The first thing is to document everything. For that I have a set of IMAP mail folders that contains notes that I wrote to myself. If I find something interesting or if I do something that I might do again I just mail myself a little note about it. It's IMAP so I have it anywhere I have an internet connection.
After that I have a wiki that is similar but a bit more organized. This is where I put the stuff that I know someone will be interested in. It's also where I create user docs and FAQs.
Finally I have some critical documents that I created with Scribus. This is the bible for my job. Anything that I have to have in an emergency goes in there.
Beyond that, I keep important code in CVS.
Since this is an afterthought at this point I would go straigt to the wiki and printed documentation.
--
Set up a Wiki somwhere and just start typing. I've found this to be one of the best ways to quickly build up a large mass of information.
Whenever you think of something that you'd like to save for the future, just type it down somewhere in the Wiki. Later when you have the time you can browse around in it and rearrange the text and improve it.
You say you learnt most of this yourself? What makes you think your replacement won't be able to do the same?
I'm in a similar situation, I am leaving my job exactly a month from now, my replacement starts on Monday, so I have 1 month to pass over every bit of knowledge I can. However, there is only so much I can do, we are heavily reliant on my replacement being able to adapt and learn things themselves. Even with a crossover period, in support work, there is no guarrantee that you will be able to cover everything (unless you deliberately break things).
Originally I had to prepare for the fact that my replacement would not be starting while I was still working there, so I would have to document things, this is exceptionally difficult, you have no idea how much detail is required, as although they will be competant for the job (we are assuming that interviewing has taken place!), everybody learns in a different way.
You will only need to document things that are out of the ordinary. Think back to all those things where you'd wished there had been someone around to tell you what to do, and write down exactly what you did do. Hope that they pick up everything else themselves.
In preparation for when I leave, I have put together a 2 column table, in the first column I put "things I know" and in the second column I have put the name of the person within the company already who knows most about the tools/situation/problem/error message/process/etc. Hopefully this will help people out, rather than the new guy picking on one person to ask questions, and taking up too much of their time. It will help to spread out the burden of getting the new guy up to speed among everybody once I have left (there's more than 1 month's worth of stuff to learn). It also helps them to get to the right person almost straight away each time.
You think you know too much to document? Think about how you learnt it, can they learn it the same way?
.sigs are for losers
That is the first step, not the last, during a job cycle.
Do it properly in your next job and start documenting as soon as you put your fat behinf in your new chair.
DO whatever you can for the position you are leaving, most likely you will be caught doing many other things, so documentation most likely will be lacking any way.
IANAL but write like a drunk one.
is slashdot full of people sucking up to their employer recently?
post it's.
a lot of them.
the computer is online
i am not at it
what a waste of ressources
.... but not an amazing one, just say your open to contract work :-) unless its code, if your a coder your payed to document your code, not what your coding.
My first method of documentation is going through my typical workday, and writing down everything important. In the space of a week, that covers most of my tasks.
Next, look at what scripts or macros are used on a regular basis. Make a note of them, and email copies to managers whenever possible. You never know if the person who "cleans up" behind you is going to erase every file with your username.
Don't forget the 80/20 rule. Focus on the 80% first, then the more arcane aspects of the 20%. It shouldn't need to be said, but don't make comments about individuals -- positive or negative. Just comment on the needs of various areas, and try to leave names out.
Use whatever word processor is standard in the office, and type up the directions in outline format. That makes it easier to make small notes, exceptions to the rule, etc.
Email copies to your supervisor/manager and your current account. Printouts have a habit of getting lost... Keep a copy for yourself too (but don't email it). Being able to show your writing style is a major plus in interviews.
I actually am in the same situation as the computer guy at the school newspaper. I inherited a bizarrely complex setup that took me a year and a half to figure out and wanted to save my successor the trouble. To that end I've used leo (http://leo.sf.net) to document the server setup, ghost setup, and code needed to keep everything running. Leo allows me to organize both notes and code in the same place. I've talked it over with the guy I'm grooming for replacement, and it seems to be working, he's pledged to continue the project, so I hope it works out. Good luck to you.
I'm a clerk at a library. So I guess you could break my job down to an SQL statement: SELECT from 'stacks_3rdfloor' where 'call_number' == $callnbr. Or something like this: $ kill -9 snoring-patrons
Take off every Sig.
test