Journals by RSS
Journals by EmailA few months ago I posted seven reasons an organization needs technical communicators. This week, a program manager I work with provided a few more ways that technical writers provide value to organizations and projects, so I wanted to pass along his wisdom—with my own discussion, of course. Because I gave seven reasons before, I’ll start with number eight.
Tag: software documentation
Tags: documentation, program management, project management, software documentation, team management, technical communication, technical writing
When I met other technical communicators at the STC conference in June and told them that I work for the LDS Church, most were at least a little surprised. What does a church need technical writers for?
As I answer that question, bear in mind that we’re not classifying marketing writers as part of this (especially because we’re not selling anything). Our team is called the “user education” team, so our concern is teaching users.
But what are we teaching them to use?
Our Church’s headquarters includes an IT department, part of which exists to develop and maintain Web sites and applications. Church software is designed to provide resources for Church members to learn about the gospel of Jesus Christ and perform their ecclesiastical responsibilities. It also helps others learn about and understand the Church.
Some applications help workers at headquarters accomplish their day-to-day tasks, and other systems are used by people in their homes or church offices to perform certain ecclesiastical duties. The work they do with Church software is important to them not just because it’s part of something a leader or manager expects of them, but also because these tasks are immediately connected to their beliefs. They have the deepest kind of interest in the success of their work.
We have a customized flavor of Agile development, and today as I was talking to one of the program managers about the next few cycles of work in a particular project, he said that the work in the last cycle or two was not yet defined. That’s fine; at least in our version of Agile, the work that was defined generally at the beginning is solidified as we go. Development is planned on an iteration-by-iteration (or sprint-by-sprint in some vocabularies) basis and more broadly on a cycle-by-cycle basis. A cycle contains several iterations of work, and the idea is to have a body of code that can be released to and used by the customer at the end of the cycle. The interaction designers prototype at least one cycle ahead of development.
The manager hopes that most of the new development work will be done at the end of the second-to-last cycle. As he talked, I got a little idea: What if the last cycle of an Agile project were reserved for bug fixes? We have hardening periods before the release for fixing bugs and for the testers to make sure they’ve exercised and proven the functionality that was developed at the end of the cycle. But what about an overall hardening cycle for the bugs that haven’t yet been addressed throughout the entire project?
This would benefit the team and the customer, but I wouldn’t be talking about this if I didn’t think it could benefit me, the technical communicator.
One of the challenges that technical communicators in the category of documentation face is keeping up with changes made to the product as it is developed. In some environments, specs or requirements are set out at the beginning, but in others—particularly in some software development companies—the customer, project management, or developers may alter the original set of requirements because of unforeseen circumstances, such as technical limitations or time constraints.
This challenge may be aggravated when the technical writer remains unapprised of such changes. Personally, I have signed in to a software application and seen user interface tweaks that affect the documentation in no small measure: images, procedures, descriptions; you get the picture. But I have found a few ways to get into the developers’ consciousness so that I’m not taken by surprise.
