job handover checklist [duplicate]

Question

I have resigned my old employer to start a new job, and I need to prepare a handover [documentation to be taken by some new employee that haven't arrived yet, and would be some weeks from when I go to when they fill the position again].

So what important points should I make sure to cover,

I was making some iOS apps, [90% completed], and a web portal [60% completed]

the other IT engineer is here so he can update on passwords etc.

Should I use some system like a wiki to leave things there for access? or just a normal doc?

what other things should I consider?

Answer 1

Don't worry about the format of the documentation. I'd stick to a plain document, rather than a wiki -- it's easy to get distracted by the mechanical issues and waste valuable time that would better be spent documenting things.

Important points to document:

1. Interfaces. Make sure you at least identify each interface.
2. Build process. Where are all of the pieces? How to put it together into a working build? Where are the test cases done so far (if any)?
3. Other tooling. What's needed to work on and/or finish the software? What environments, compilers, computers, etc? What's needed to deploy the software?
4. What's not done? What are the tasks that need to be completed in order to finish the software? What's been tested so far?
5. Resources. Who else is involved? Where are the requirements, if any? Who needs to sign off on the software? Who is the customer?

Answer 2

The most important questions to answer in the documentation:

• Where is the code? (SCM access, etc.)
• What do I need to work on it (compile, test, run, deploy)?
• How do I set up my development environment?
• Where do I start reading?
• What are the gotchas?
• Anything else out of the ordinary?

It's probably also nice to include information about the team, but it depends on the situation whether you need this.

I assume you have some sort of bug & feature tracking in place; if you don't, then you also need to include everything you would normally put there, which is:

• known bugs
• work in progress
• requested features

Detailed information about certain parts of the code, such as specific quirks of a particular function, are best left in comments in the source code itself. Make sure those are complete, accurate and useful. And while you're at it: Remove unused / commented out code, do a general cleanup, revisit everything you've worked on (if that's feasible).

Answer 3

The best way to approach this is from your perspective. Given what you now know about your project(s), ask yourself what you wished you knew on the first day, when you started work. Then, organize that information into a structure document, whether it's written in a wiki or using a word processor. If any of your current co-workers will be taking on the project, work with them, too, and see what they might be looking for.

You should also update any documentation that exists, but might be out of date. Nothing is worse than a spec, design document, or even a user manual that doesn't correspond to the current state of the application. Personally, before I start development, I read everything that I can associated with the project to get a feel for the end user, the requirements, the previous developer, and the directions and influences on the project. Out-of-date documents really hampers this effort.

Answer 4

I agree with the fact that you don't need to put your heart and soul into a complex documentation system. Alger answered about what information you need to pass. Also, don't forget to note the many passwords that you may be the only one to know.

I am personally using TiddlyWiki which is a mini wiki stored in an HTML file. It is really a great tool for storing various information and to pass the information you only need to give the HTML file to the new guy. Each one of the guys have his own, and we also have a "newcomer" mini wiki that we continuously update and give whenever a new developer arrives. It contains various information such as where to find softwares, code source repositories, who is the responsible for a given Java project, etc.