Stephen A. Fuqua (SAF) is a Bahá'í, software developer, and conservation and interfaith advocate in the DFW area of Texas.

The Mythical Man-Month: Wiki and Customer Service

November 26, 2011

Part three in a series. Many of the recommendations Dr. Brooks makes in this work can seem outdated at first glance; however, it does not take much to bring them into today's software development environments. Take the telephone log for example:

"One useful mechanism is a telephone log kept by the architect. In it he records every question and every answer. Each week the logs of the several architects are concatenated, reproduced, and distributed to the users and implementers. While this mechanism is quite informal, it is both quick and comprehensive." (p69)

Read the book for more context. Updated in modern terms: as an architect, or any kind of subject matter expert (SME), questions and answers over the phone, e-mail, or in-person should spawn an update to the enterprise Wiki (addition or clarification). Consider pro-actively sending a list of updated Wiki pages at least once a week, or even in a brief daily status update. If the answer to an active question is already there, find a polite way to direct the questioner to the Wiki. Here's where good customer service is important. In many cases this might be a missed opportunity to be of service:

One-line e-mail: "Did you look in the Wiki?"

One can imagine a much snarkier-sounding e-mail coming from a frustrated developer who does not want to be interrupted with "trivialities." But that's an unfortunate attitude, one that fails to recognize the importance of respect and service to other group/team members, without whom the developer's job might be meaningless. Perhaps a better response would be:

"Yes, I had a difficult time understanding that as well. We've documented that in the Wiki; please click under XXXXXX and then find the link with YYYYY in it."

Better yet, if time permits: copy and paste from the Wiki into an e-mail, and include the Wiki link for future reference. This is, of course, a double-edged sword. Somehow, someway, "users and implementers" must be encouraged to read the documentation for themselves, and discouraged from asking a thousand questions that have already been answered.

I do not recall that Brooks's sagacity encompassed this area. The best that I've come up with is this: offer to schedule an hour with the individual later in the day/week, and ask the individual to hold all but the most critical questions until that time. This gives the person an opportunity to find their own answers, allows you to continue focusing on your current efforts, and the face-to-face time may even be more appreciated than the individual responses would have been.

No TrackBacks

TrackBack URL:

Leave a comment