I am coming from a place where documentation is actually read by its target audience, which came as a huge surprise to me when I first started off at Kaspersky seven years ago, and which still remains one of the main reasons I'm so passionate about the job. Moreover, our documents don't simply describe products, they have the power to seal contracts between teams, while their revision histories convey sometimes painful but fascinating stories about team feuds over a specific parameter and overall service evolution. Which is why it is not always an option to lock oneself in a room with a notebook and a mug of coffee, more often than not one has to venture out and actually talk to people.
And then one has to ensure that the results of these conversation transform into a comprehensive document and get to the right hands on time. In this presentation, I would like to share our know-how for effective communication with stakeholders which is sometimes more crucial to continuous delivery of documentation than the software we use. Think facilitation, networking, and negotiation skills; Confluence as both a documentation development tool and a way for cross-departmental collaboration.
Besides stakeholders, we also need to communicate among ourselves, so we'll talk a little about the way we share knowledge within the technical writers' team. Our best-used tool is, of course, communication, both written (Knowledge Base) and face-to-face (team meetings, team-building events, mentoring activities, etc.).
And of course, the presentation will cover the business processes that help us coordinate efforts of everyone involved in document development and service transition. Since our stakeholders' pool includes people from all over the company (RnD to Accounting, and IT to Security), we need and employ a whole set of ITSM-based processes that define all stages and procedures required to get from point A to point B.