Latest posts by techwriter (see all)
- Hazards of Poorly Written Technical Documentation - December 26, 2016
- Get an ‘A’ on Your Next Research Paper With These 6 Simple Steps - November 28, 2016
- An Amazing and FREE Source of Magazines and Periodicals — ISSUU - November 25, 2016
By Tia Peterson
This is what the typical development environment used to look like: you, the technical writer/product manager/business analyst, sits in one space, just a few spaces away from a tester, who sits just a few spaces away from a developer. Possibly, an architect sits a couple doors away, along with an administrative assistant and a project manager.
Not so these days. Today, the picture likely looks more like this: a couple of developers and testers share an office, and communicate daily via e-mail and/or phone and/or Skype with you, the business analyst or product manager of sorts who probably sits across the country from them, or even further – across the world.
Today, teams are smaller – stripped down to bare essentials for a number of reasons, but highest among them: cost.Everyone is being asked to be more efficient: to complete projects faster, with fewer people, for more money. This means that you, as the chief person in charge of communicating requirements, needs to find a better, faster, more effective means of documenting and expressing those requirements than ever before.
5 Strategies for Effective Communication While Working Remotely
When communicating requirements remotely, you will need to learn to be as concise as humanly possible. Sure, you may have figured out all of the ways to cut costs by using Skype or instant messenger, nixing paper and submitting all documentation electronically, etc… but the costs will all come back to you in measures of time if you do not learn to say what you mean to say in as few words as possible.
Here are five ways you can achieve better communication…
Demonstrate. If you have not already, learn to use Visio or a similar program and make diagrams the central parts of your documentatio n. Diagramming is quite possibly the single most effective way of expressing the what of a system: the answer to the question, what does this thing do?
Chop up your documentation. Give to testers what testers need and give to developers what developers need. Do not waste time trying to create the perfect single document to be used by roles of all kinds, because such a document does not exist. Instead, focus on meeting deadlines by providing what is necessary when it is due. If you so desire or if it is dictated by the processes adopted by your employer or client, you can put all of the pieces together at the end in one big SRS. But for now, focus on what is necessary.
Show and tell. Do not wait until everything is completely ironed out before having discussions with developers and testers. Rather, use modified JAD sessions to present features and functions as they are being defined. This will allow for more and better questions upfront that can be worked into the documentation, rather than spending a ton of time creating a document or presentation that will be picked apart and in need of serious revisions later. Your developer or tester may be living and working in a time zone that is several hours ahead of or behind you. Instead of presenting a massive amount of documentation which will take weeks to sift through, discuss the functionality in pieces, making it possible for your developer to begin developing and your tester to begin writing test cases at the same time that you are finishing up another part of the documentation.
Keep communication free flowing while still holding formal conference calls. One of the most effective ways to work remotely is to set up a formal conference call weekly, or even daily, depending on what part of the development cycle you are in. In addition to this standing call, set up instant messenger and develop a habit of staying by your phone and e-mail program so that questions can be asked and answered on the fly. While working remotely, you cannot afford to go into a hole or be AWOL. It needs to feel as though you are in the office while in fact, you are nowhere near.
Ask for understanding. Don’t assume people are following you. Once they hang up the phone, you don’t know whether they are scratching their heads or getting straight to work, so, it’s up to you to ask the questions, “Do you understand what I am saying?” “Does this make sense?” “Are you able to follow these steps/this diagram, etc?” If you don’t ask the questions, you are leaving a lot of room for misunderstanding – the kind that can’t be cleared by just getting up and walking down the hallway.
Ultimately, if you are an effective communicator, you should be able to communicate requirements well, whether or not you are physically situated in the same office as the rest of your team. It is entirely possible to communicate requirements to a team even when each team member works from their home. The key is to adopt communication styles and strategies that make it possible to still get questions answered in a timely fashion. Additionally, if your documentation is skinny (i.e., stripped of the fat and presents only what is necessary), you will remove potential distraction and reduce the opportunity for misunderstanding and/or confusion that can be more likely to occur in a virtual office setting.
Tia Peterson is a freelance technical writer and website developer. To contact Tia regarding technical writing opportunities, please get in touch with her through [http://www.linkedin.com/in/tiadpeterson]LinkedIn where you can review her resume as well as view recommendations. To contact Tia regarding website development, please visit her main website, [http://www.tiadpeterson.com]http://www.tiadpeterson.com.