How to Communicate With Mobile App Developers

Both sides make mistakes: the client and the developer both do their bit. However, the client has more opportunities to influence the process. We will explain the subtleties that must be kept in mind in order to get a mobile app released on time and without conflicts or casualties.

Concern for the developers

Encourage them

Programmers spend 90% of their time in front of an unfeeling computer, entering commands: open, close, multiply, divide. This is where the difficulties with mutual understanding arise: it can seem as though these specialists are closed-off, capricious, rude and speak in an alien language.

What to do:

• give them attention and show interest. Keep in contact, don’t abandon the programmer to face the task one-on-one;
• don’t publicise the developer’s contact details: channel your colleagues’ requests or comments through one intermediary;
• explain the purpose of every function, as well as its benefits, why it would be bad without it and why it will be good with it;
• load up on patience. Remember, this is a programmer, not an entertainer: they are paid for code, not for conversations or fun.

Clarify terms

Churn, net-new, baked in, presos, guesstimate, drill down, synergy — IT guys aren’t the only ones who use strange words. Your business jargon is as unclear to them as their computer slang is to you.

What to do: Decipher your business’ terminology, including slang. Ideally do this in written form, so that the programmer can reread the explanations. Otherwise, instead of a list of private clients you could get Tesla, Einstein and Stephen Hawking.

Be tactful when calling

The developer chose this profession because it doesn’t involve much real-world communication. Of course, this isn’t the only reason, but it is one of them. Calls without warning are especially grinding: you don’t want your train of thought interrupted when you’re designing a complicated algorithm.

The second nightmare of a programmer is unset, constantly changing requirements: “You remember three months ago, we spoke on the phone and I asked you to add five new screens? Where are they?” The programmer prefers a text, because the message conversation remembers everything.

What to do:

• plan regular calls, for example: ‘Skype calls on Tuesdays and Thursdays at 3pm.’ Make a list of questions and discuss them all on an agreed day. If you need to make an urgent, unscheduled call, send a message beforehand and wait for agreement;
• provide a voice consultation in the effort estimate. Let them know that they will be paid for the time spent talking;
• write down the decisions made during the call.

Illustrate

Paradox: the developer understands complex technical documentation, but doesn’t finish reading a letter with a detailed description of the task.

What to do: draw up some annotated images. Even if on the screen there is only one button which needs to be changed from yellow to blue. Take a screenshot of the screen, circle the button in Paint and write next to it: ‘Change to blue.’

It is best to break up large tasks into several smaller ones and explain each step.

Evaluate your resources

Theoretically, three people can get through a mountain of washing up faster than one. In actuality, however, three people can’t fit around one sink. The same is true in mobile app development: not everything can be parallelised.

What to do: Ask directly. For example: “Do you need another programmer to help you? Would that speed up development?”

Care for yourself

Document your requirements

Yes, you can get away with not having documentation: explain in person, work in Agile, draw on a napkin. And then come unstuck at the stage of accepting the work, with questions like:

1. Has the developer done everything which was agreed?
2. The developer is complaining that the client is asking them to do more than was agreed. Is this really the case?
3. How can you prove to the developer that they have not met the agreed requirements? Or that they have met them, but not in the right way?

It is not mandatory to prepare detailed documentation, but it is useful to have a numbered checklist: they establish the hard facts and help to avoid emotions running high. It means spending a few hours making it, but this time pays for itself. Without a checklist, conflicts and additional work can drag on for days, weeks, or even months.

What to do: formulate comments based on facts. An example:

“Where the issue lies: point 5.
How it should be: when the ‘Account’ button is clicked on, the person’s account opens.
How it is: error ‘Page not found’.”
Ideally, add a screenshot.

A word about additional work. When requesting that they ‘add just one button, it should take five minutes,’ remember: drawing the button takes five minutes; programming what happens when it’s pressed takes five hours.

Make your requests precise

We’ll be honest with you: the problem is not always on the developer’s side. If the client leaves a huge amount of room for interpreting the task, disagreements are inevitable.

What to do: Before approaching programmers, ask yourself precise questions and try to answer them. For example:

• I want the report to be made quickly. By ‘quickly’ do you mean one second or two minutes?
• I want an attractive interface. What do you mean by ‘attractive’? Where are the examples of attractive and unattractive design?
• I need an app for a young audience. How young do you mean, 15 or 35?

The SMART criteria for setting tasks will help you here.

No time to explain? In that case, look for developers who have already released fintech apps within their portfolio, or hire a professional intermediary — a requirements analyst or a project manager.