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.
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:
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.
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:
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.
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?”
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:
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.
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:
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.