Documentation Matters

Documentation Matters

Subscribe to my newsletter and never miss my upcoming articles

Picture this: A Sev 1 ticket comes across your desk because orders aren't processing for some reason and you have to find the bug and fix it asap. There are no documents at all for this process and the coworker that built the process is out of the office so you have no idea where to even start to fix this issue.

It takes you two hours to locate the workflow and then even more time to read every step in the flow and to try and figure out what the issue even is. By the time you have fixed the bug (you hope anyway), it's been over three hours and your company has not processed any orders in that time frame. This makes your warehouse staff have to stay late and your company has to pay them overtime.

This makes the big wigs mad at you and it turns into an entire thing.

If only this situation could have been avoided....

Documentation is one of the most crucial parts of completing a project and it's a step that a lot of us tend to skip out on. Why do we skip it?

1.The business is breathing down our necks to get something done and you just want to get it over with 2.Docs take time and you do not feel like you have the time to get them done 3.You want to keep building and fixing things because it's the part of the job that you love

And I'm sure that there are some other reasons that I haven't mentioned above.

Even though they are all decent excuses, at the end of the day, not having docs on hand will hurt your org way more than taking an extra hour or two on a project to create them.

1.Your users will not know how to use the new thing that you built, so they will use it incorrectly or just not use it at all.

This can cause your users to create items with bad data, trigger the wrong flows, submit tons of tickets for bugs, or just abandon the item which in turn means you wasted your time altogether.

If you spend the time to create a high-level guide to the item that you created and walk the managers or super users of the item, you will not have this issue (as long as the thing you made actually fixes their business problem). The managers and super-users will train their departments and hold their people accountable to make sure that it is being used properly.

2.You will not remember what you built or why you built it.

If you have worked in an org for a long time and built a lot of different things, there will come a time where you just can't remember everything. This can be a problem when a user reports a bug or wants to enhance the item in some way.

If you do not have docs, you could spend hours or days trying to track down all of this information, and even when you get to the info, if you don't remember how it works or the reason it was built, your fix could actually break the item.

If you keep docs about how things work and why you built them, you can always reference them later when something goes wrong. It will save you time and your sanity when working on a project.

3.Your new hires will not know bleep about your org

If you hire a new person off the street who has never used your org before, you will have to hold their hand through everything because they can't find the information themselves.

You empower your new people to be independent when you have documentation. They can search for the issue and fix things themselves, allowing them to do the job that you hired them to do.

As you continue to fix bugs and create super awesome things, just remember to wrap things up in a nice bow and write everything down so you can save yourself and your team from having to experience all of these heartaches

Do you document your work? What software do you like to use? Is there anything that I missed? Let me know in the comments!

 
Share this