Documentation Processes, Contd..

This is the second part of this article. Read Part 1 here…

So, what should go into a process? Let’s take the 2 cases of new documentation sets and existing documentation sets

 Considerations for new documentation sets

Writing the process for a new documentation set is fairly simple and probably the easiest to do. In all likelihood, the product team follows the SDLC. In such cases, following the DDLC is fairly obvious, isn’t it? Not really. Each team/ organization is unique in how they design and develop their products and to that extent the DDLC should follow what they really do on the ground.

 For example, documenting a product in a startup is largely different from documenting a new product in a 20-year old company with proprietary tools and systems. The assumptions you make, the roles involved, locations, tools, base processes, the test cycles, and approval processes are all very different.

Documenting a product in a startup

In most cases, product development in startups is casual, sometimes random and mostly ‘fly by the seat of your pants’ experience. Documenting, and by extension a process, is a tough exercise. However, I’ve found a very simple work flow effective:

1. Get feature/ version specs
2. Stay connected and contribute to the feature definition
3. Test/ play with the Sandbox
4. Write draft content with 80% final feature version (ensure you check the impact of the feature on other documents like the install guide, architecture document, web content, etc)
5. Do a manual test with the steps you have written
6. Initiate reviews by the tech/ test teams (a 30 mins in-person meeting can do the trick)
7. Add the 20% content (if it does come up)
8. Fix comments from step 6 and 7 and send for approval
9. Package and integrate
10. Publish

Documenting a new product in a 20-year old company

A new product line in an existing company most likely assumes the legacy tools and systems in place. This is true for both the DDLC and SDLC. A chunk of work then is in customizing existing work flows, ensuring the product and documentation deliver to meet organizational standards.

In essence the workflow mentioned above remains the same. In addition, it will also involve one time activities like:

• Setting up the codebase and sandbox
• Creating the relevant documentation repositories
• Figuring out how content will be published