One item that gets little attention or praise is documentation. Long, the last piece of information - completed which most of the time results in documentation that is written hastly - incomplete and very error prone.
It today’s world of vast competition users and developers of IT related products need good documentation so not only can they know how to use a product but also how to troubleshoot any errors which may occur.
Thus, manuals given to users should be written with the utmost precision and care without spelling and bad word choice. The better a manual is written - the less calls for support will be taken. Likely, a vast array of illustrations/pictures will help.
Also important and overlooked quit a bit is documentation that a developer will write for not only their own use but for other developers as well. This documentation should contain a blueprint not only of the full product - but include explanation of practices and snippets of code that were utilized that were unique and need further explanition.
It is recommened that for each product a master guide be created which contains a easily navigatible table of contents so that if a manager needs to look-up some piece of information then can. Also, it’s important that the masterguide not leave out any critical steps.
One of my favorite steps is documentation because I try to be as creative with layout and illustrations as I can so that in the worse case scenerio any team member or user can possibly understand or remedy a problem or question with ease. Furthermore, the business may someday need vital information on the product/process with could be years later - so thus good documentation is vital.
In closing - I would recommend that documentation be created as the product/process starts - so that key information is not lost nor forgotten. One of the biggest downfalls I see with documentation is that it is done dead last in the product life cycle and thus it’s effectiveness is truly lost and the documentation isn’t as clear as it could or should’ve been.
It today’s world of vast competition users and developers of IT related products need good documentation so not only can they know how to use a product but also how to troubleshoot any errors which may occur.
Thus, manuals given to users should be written with the utmost precision and care without spelling and bad word choice. The better a manual is written - the less calls for support will be taken. Likely, a vast array of illustrations/pictures will help.
Also important and overlooked quit a bit is documentation that a developer will write for not only their own use but for other developers as well. This documentation should contain a blueprint not only of the full product - but include explanation of practices and snippets of code that were utilized that were unique and need further explanition.
It is recommened that for each product a master guide be created which contains a easily navigatible table of contents so that if a manager needs to look-up some piece of information then can. Also, it’s important that the masterguide not leave out any critical steps.
One of my favorite steps is documentation because I try to be as creative with layout and illustrations as I can so that in the worse case scenerio any team member or user can possibly understand or remedy a problem or question with ease. Furthermore, the business may someday need vital information on the product/process with could be years later - so thus good documentation is vital.
In closing - I would recommend that documentation be created as the product/process starts - so that key information is not lost nor forgotten. One of the biggest downfalls I see with documentation is that it is done dead last in the product life cycle and thus it’s effectiveness is truly lost and the documentation isn’t as clear as it could or should’ve been.
Comments