views:

129

answers:

2

After reading E-myth Revisited, I realize that I can do a better job at making my company less reliant upon me... I spend a tremendous amount of time answering silly questions (silly to me, but necessary for my developers to get the job done).

I need to write a set of operating manuals for what to do in certain situations...

For instance:
  • How to make a build
  • How to write test cases
  • How to report status
  • How to fix a bug
  • How to handle support question A, B, C, etc...
  • What to do when you are stalled
  • What to do when the power goes out (really, I need to do this)
  • etc...

What are some useful, generic operating manuals that you can think of, for a software development company?And please, if you have some good, short, online versions that you know of, please post them. I would much rather use a starter manual and modify it for my needs, than start from scratch.

+2  A: 

What about a wiki - at least then other people can start to contribute.
Otherwise they are just going to rely on you for the manuals

Martin Beckett
Yes, we already use a Wiki and certainly, this is where the operational manuals will go. However, I still need to come up with the manuals. They can't write them themselves, although I may tap them for part of it.
Jason
A: 

I disagree with the wiki. As the owner of the company -- it is your responsibility to write the manuals, or delegate it in a very controlled fashion. People should rely on you for the manuals.

Really though, back to the question. The obvious standards, coding, SQL, etc for your platform and programming languages. You'll be able to find examples of these anywhere on the internet. As for customer support, you should probably write that yourself, you know how you want your customers treated. As for test cases, again, you'd have expect your developers or testers to have a professional understanding of what needs to be done, you might indicate the acceptable minimums however.

What to do when you are stalled. That's what managers are for :-)

I think it boils down to writing the manuals that are unique to your business, and trying to steal or borrow manuals for the generic processes.

Phil Bennett