Whenever the word documentation escapes someone’s lips, bells go off in my head. I can be sitting (or standing) in a scrum meeting and a developer says, “I’ve been working on such-and-such a task and the accompanying documentation,” and my automatic reaction is to think, “I should be doing the accompanying documentation.”

What he’s talking about is database diagrams (which I’m more than happy to leave to him) or notes from talking to people involved in the business process. I did discover recently that a business analyst put together what he called a quick guide, but it was mostly screenshots and very little text. It didn’t really explain steps. So guess what I’m going to be doing in the near future.

Project teams can accumulate quite a load of documentation over the lifecycle, even aside from any end-user material. In projects I’ve worked on, I’ve seen the following (and probably others):

  • Requirements documents
  • Concept documents
  • User stories and accompanying comments
  • Bug tickets and accompanying comments
  • Excel spreadsheets with matrices or database code
  • Prototype notes
  • Wireframe notes
  • Visio diagrams of workflows or database relationships
  • Samples of legacy reports

I’ve drawn on many of these for my user assistance material. It can be a lot to sift through, and sometimes I settle for asking someone questions rather than wading through the files (gee, that sounds like most of mankind—am I being hypocritical here?). I suppose it’s better that a team have ample documentation than a shortage.

My point is that if your team is going to the trouble of producing this stuff, take advantage of it. On the other hand, lately I’ve felt a little guilty if I wanted to ask, “Is there a document covering this?” as if I’m saying, “I’m antisocial and don’t want to talk to you. I’d rather sit at my computer with headphones on and read my screen, living in my own little tech writing world, than conduct an interview with you.” I’m sure that’s not what the other person would think I’m really saying. In fact, in large part, the developers I work with are as accommodating as they can be and very willing to answer my questions.

There’s a happy medium to be found, I’m sure, as with most aspects in life. If a project has a pile of team documentation, it can be a rich mine full of resources for understanding the product. However, the point may come where you get little return on the time investment and it’s simpler to ask someone. Provided that getting some face time and the answers you need takes less teeth-pulling than going through that project documentation.

Related posts (auto-generated):

  1. Technical Communicators as a Point of Contact between Users and Project Teams
  2. When the Team Is Open to Shoulder-Tapping
  3. Try a Quick Reference Guide for Short-Term Documentation Needs
  4. Establishing the Correct Name of a Project
  5. An Interaction Designer Who Understands the Need for Documentation