The other day I was taking an Uber (though I’ve since switched to Lyft), and the driver told me that sometimes the GPS will admit that it’s lost. “Yeah,” she said, “sometimes it will say ‘GPS is lost’. Everyone thinks it’s funny when even the GPS is lost.” I realized that she was probably thinking about the message “GPS signal lost.” For me, hearing the message “GPS signal lost” is about signals. The app is telling me, “Hey! I depend on this particular type of signal, and right now I’m not receiving it.”
I heard signal as a central word in the GPS’s utterance. The way the driver spoke, though, it sounded as though what she heard when the GPS lost signal was that the GPS found the current directions too confusing. There’s a subtle type of miscommunication here: one person is automatically reading an utterance as a technical diagnosis, and the other is not inferring some piece of technical information. But both people were presented with the same exact utterance.
I think larger examples of this type of miscommunication happen on technical projects all the time. Consider this hypthetical example: a customer asks to implement Single Sign On between the CMS that manages their larger site and the customer service portal that you work on. Now suppose that from the phrase “single sign on,” you heard that the person should be able to navigate between the two systems without having to sign in twice. But the person who asked for single sign on was thinking about systems that integrate with say, Facebook or a Google Account, so that if you update your contact info in one system the other system knows about it. The person who heard “not see a login screen when switching between pages served by the CMS and pages served by the customer portal” might technically be right, but they’re not capturing the spirit of what the customer asked for. The customer doesn’t know (and frankly it’s not the customer’s job to know) that syncing profile fields and using and external service to provide auth before setting a cookie are related but distinct features. In their experience, SSO means, “this site over here knows who you are, and if I click ‘allow’ on the nice dialog box, it will wire up to my Facebook account and never bother me again.”
The miscommunication happens, I think, because people working on the technical parts of an application will fixate on the technical language, and people working on the business cases will not. I think that, as people working on the technical side of the project, we need to resist the urge to just say, “well, if they wanted profile sync and SSO, they should have asked for it.” From their perspective, they did. It’s our responsibility to chase down what they wanted and figure out how to translate it into technical requirements.
I think the main takeaway is this: If you find yourself defending technical decisions by holding up particular pieces of language from a user story or bug report, you should double-check with someone before implementing those technical decisions. In other words, any assertion about the spec or user story or whatever that relies on particular language is probably not evident to all parties, and might not be what the other party met. If we swap in less-precise synomyms for some key nouns in the user story, could I still make the same inference? If not, use caution. You don’t want to be in a position where a customer said, “make the GPS understand driving directions in DC better, so it doesn’t get lost any more,” and then spend a month improving the path finding algorithms, only to find out that what they meant was, “Make the GPS stop saying ‘signal lost’ when I go through tunnels.” Or, put another way, be cautious about inferring technical details from non-technical sources. This advice goes slightly beyond saying, “If you’re not sure, ask,” and adds, “Consider the possibility that you and your customer both think you’re sure what the story means, but you’re talking past each other, because you’re clinging to the technical terms in the spec, and they’re not.”
Till next time, happy learning!
By USAF -http://www.af.mil/news/airman/0106/satellites_gallery05.shtmlhttp://www.af.mil/news/airman/0106/00_satellites_images/GPS_xxl.jpg, Public Domain, https://commons.wikimedia.org/w/index.php?curid=978591