Requirements collection requirements remotely

2

When developing software, one of the main steps is to collect requirements, acquire knowledge of the domain, and construct a ubiquitous language. Both agile methodologies and Domain-Driven Design put a lot of focus on it, because it really matters the involvement of development business experts.

It turns out that there are situations in which it is not possible to be in person with the business experts to hold meetings and discuss the software. I have already received proposals for development from customers in other states due to recommendations from local customers, but I was concerned about this issue of contacting business experts.

Of course, with the technology we have today, an efficient way to make this contact from a distance must be possible, but what I want to know are the techniques that really work. It seems to me that just sending an email with a questionnaire may not be enough.

In this case, how can we remotely do this part of the requirements collection, domain knowledge acquisition and ubiquitous language construction? What means to do this really work?

    
asked by anonymous 04.01.2016 / 02:03

1 answer

2

TL; DR

Use the same methods you would normally use, but investing more effort to maintain effective communication.

Challenges of distance communication

All material and all the people I have worked with, even when favorable, recognize that there are challenges in remote work.

Difficulties in language skills, delays due to very different time zones, important issues that are avoided because you need to write a lot, video conferencing meetings that are prolonged because of late communication, concepts that are not well explained because you can not just take a paper and draw. These are a few items that are major issues for remote teams.

In short, everyone I know reports that video conferencing is not the same as talking to someone in person.

Redoubled effort

To overcome the difficulties of distance, more effort is needed.

Distance should cause communication overhead and this should reflect on your deadline and budget.

The biggest effort can be invested in:

  • More video conferencing or telephone discussions; usually the opposite is done, you spend less time than you would in person, but considering that remote communication is less effective, you need to spend more time communicating.
  • Review each discussion information in writing and send it to the client after the meeting to confirm the understanding.
  • Invest in a good management system for your backlog and engage stakeholders to follow up and add comments.
  • Perform a greater number of software demos and collect feeedback more often than a normal project and thus mitigate communication flaws as early as possible.

Two important remarks on all of the above:

1. Get to know the user

The additional effort will be inversely proportional to the user's knowledge of IT and their own needs.

Before you begin to raise customer needs, talk to the customer to see how much people are aware of what they need and have some experience in participating in systems development to determine the work you are going to do have to extract the information.

Always be careful about the vocabulary used, depending on the level of the user this will determine if the communication will be more technical or business level.

It's not uncommon for users to be embarrassed to ask about some term they do not know and thus giving misleading answers about what they need.

When working remotely:

  • Hold meetings with all users to level the knowledge.
  • Hold individual meetings with each stakeholder and give them the opportunity to ask questions "secretly," without embarrassing their colleagues.
  • When talking about a technical subject, always summarize to the user what that is, never assume that he already knows. For example: "The JVM, that program you install to run Java applications blah blah blah .

2. Cut the punch line

I've talked so far about spending more time on communication and meetings. This is something that seems contradictory and counter-productive, after all who likes to spend more time in meetings?

However, everyone needs to keep in mind that this is the price of using a less effective means of communication. But of course this also means being aware that everyone's time is valuable and meetings should be extended as long as useful information is obtained, never more than that.

It's like downloading with less bandwidth: it will take longer to transmit all the necessary data and you should avoid navigating things you do not need in the meantime.

One tip would be to have few regularly scheduled meetings and several informal and on-demand meetings or "calls." Scheduled meetings are good at first, but soon they lose meaning because people do not have much to add and become repetitions, so in that case it is better to have users closer to jumbled conversations when doubts arise.

Considerations

Anyway, all the above tips are experiences that are all good, but which should be strongly reinforced in a project whose communication is the greatest risk.

Incidentally, thinking about this, it is worth remembering that within a project where the risk identified, it is always good to review the mitigation techniques related to this type of risk.

    
04.01.2016 / 03:40