As the lone writer, it is in your best interests (and key to your survival) to get others to help you write the documentation. How? You might get lucky and find someone who will give you all the info that you need. But more likely you will need to ask multiple people to piece together the complete info necessary for comprehensive documentation.
If your development team is using agile, request for documentation to be included in the definition of done requirements:
** Advantages: Direct access to the best authority - the original developers - while the information is still fresh in their minds and they are highly motivated (because they cannot complete their sprint without getting this done).
If your development team is using agile, request for documentation to be included in the definition of done requirements.
** Remember, the goal here is to capture information, not to produce full documentation. There is no need to require full documentation at this phase, bullet points will suffice.
Advantages: Direct access to the best authority - the original developers - while the information is still fresh in their minds and they are highly motivated (because they cannot complete their sprint without getting this done).
Remember, the goal here is to capture information, not to produce full documentation. There is no need to require full documentation at this phase, bullet points will suffice.
When a new feature is developed, check to see if there is a design document for the feature. If there isn’t a design document, ask the developer (or the development team) to write up a summary of what the feature is. You might need to ask the developer some questions to ferret out more information, but it is a good practice to get them used to you asking for a description. The developers should get used to providing that type of information about the features that they work on. Ideally in a design document that is kept current. Additionally, if there is no design document, it is an opportunity for you to implement a new process that will help everyone - development, QA, marketing, project and program managers, and of course you (the doc team). See the “Quick Wins” section of this guide.
Check in with your SMEs. One or more of them should have information about the feature and should be able to help you out.
Ask QA. Presumably they are building test cases to test the feature.
Ask Marketing. Their perspective might be very different than development, SMEs, and QA. But is it good to know if their perspective of what is being developed matches with what the SMEs think, and what the development team has built.
In a maneuver to help others with writing documents, it’s important to reassure them that contributing to the writing process through explaining (perhaps generally) key or minor features to the project is essential for everyone’s understanding. It may not be apparent to the others at first, but something as seemingly insignificant as a passing comment about this-or-that feature from one of the developers, a minor bug that QA is having issues with, or even a project manager’s foggy idea of changing an existing feature; all of these can be expressed, logged, and re-read through documentation.