Skip to content

Latest commit

 

History

History
32 lines (20 loc) · 2.84 KB

GettingEveryoneToWrite.rst

File metadata and controls

32 lines (20 loc) · 2.84 KB

<!-- https://docs.google.com/document/d/1VtvwylS4SAV2o9ADO91EwfGcXVOca0-wJcNtLBZLARs/edit#heading=h.c0smabrpthpe -->

Getting everyone to write

How to swim in the deep water - A lone writer’s guide to survival

Starting notes:

  • Convincing others to help you write docs.
  • Use metrics from doc hits to prove that certain topics are key and need to be written and kept current.
  • Convince everyone that good docs save support calls (which is time and $$$) for the company.

Hack-a-thon content:

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.

  • When a new feature is developed, check to see if there is 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 explaning (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.