Yesterday I had a #clubhouse discussion with Hemapriya and Balaji. As it was the first session, we kept it short to a 30-min discussion. The idea was to bring forth and discuss things that we’re stymied on in our daily work - issues, ideas, or irritants.
Some of the topics we discussed during the session were:
- Difficulty in getting information from SMEs
- At times developers redirect writers to some documents without bothering to check if that’s what they need.
- This is understandable for existing features, but doing the same for a new feature isn’t helpful especially when it is an external link.
- How to promote usage of documentation
- This has always been a concern for writers especially when they do not have control over where the document resides.
- The history of how help had been delivered was also talked about.
- The tendency of people to ‘google’ for information or reach out to the customer support is also a factor.
- Atleast for products with an user interface, you could do something as a contextual help or tripane help or even link to help. But what do you do for product documentation without an UI?
- Usefulness (or lack of it) of writers in a daily scrum meeting
- The decision was ‘it depends’. In a scrum meeting, when a writer says that they have nothing to work on vis-a-vis that specific feature, it gives an impression that they are not working. Typically, a writer can get into the writing mode when the feature is atleast half-baked. When it exists only on a plan, it is nothing but a vaporware.
- Writers also juggle multiple projects at the same time. So the comment of ‘being idle’ doesn’t hold true.
- Once the feature picks up steam, say end of week one, writers have somethign to write about even if it is just a new icon in the UI or a very complex feature.
- One suggestion that came up was writers can start up short stubs or placeholders for the articles that may need updates as a sprint starts. Subsequently, they can start updating it as the sprint progresses.
All of us liked the session and the format that we also thought of a few topics that we can talk about in the next session.
The idea of accessing the collective knowledge of all participants was one of the core ideas behind this. And being remote workers, the chances of technical writers talking to others outside their organizational teams is less. Addressing that was another reason for this.
Going forward, we would also like to add more people to these sessions so that we can learn from others and others from us.