The effectiveness of any cooperation directly depends on the level of communication: the better the communication is built, the better the result. It is especially important to adhere to this formula, establishing contact with IT specialists. As a rule, programmers are people with a technical mindset, which means that they love specifics, logic and accuracy. The ability to build a dialogue these days is no less important than getting good project funding or getting a pro in the team. The ability to clearly convey your thoughts is a kind of skill that requires constant pumping.
In this article, we will share recommendations on how to properly build a dialogue and understand each other in the process of working on a common project, what formulations and actions are best avoided, and what, on the contrary, will improve your communication with programmers.
Advantages of cooperation with a developer on freelancing
According to a study by Payoneer, the freelancing market is developing rapidly. Not the last place in this process was played by the pandemic. More and more IT professionals prefer to be self-employed, not to depend on the internal regulations and rules of companies. Of course, freelance programmers are in demand among customers, because there are grounds for this:
- the opportunity to build personal communication, agree on the terms of cooperation without third parties;
- promptly make changes to the TK directly (in case of emergency);
- coordination of technical nuances in the development process (it is possible to replace certain solutions with alternative, more cost-effective ones in this project);
- exchange of experience directly: a programmer with a rich portfolio can advise on how to properly implement the project, referring to his background;
- calculation without intermediaries: the customer knows exactly to whom and for what he pays;
- constant support of feedback;
- constructive wishes and objective criticism: this, of course, is an unpleasant moment, but if necessary, the customer can directly express his disagreement with this or that decision, in fact, just as the programmer can explain “why so, and not otherwise”;
- the cost of freelance developer services is usually lower than the services of a specialist who works for an agency or a large IT company.
How to be on the same wavelength. Foundation of successful cooperation
Before opening a project, the customer should clearly form, first of all for his own understanding, a general working picture and a possible final of cooperation. Of course, here you can not do without a properly drawn up technical task. To do this, you can seek help from specialists or do it yourself (there are a sufficient number of examples on the network).
Without a clear TK – the result of HZ
When the executor of the project is chosen, the most interesting begins. It is worth clarifying immediately:
- what technology stack the programmer plans to use to perform the task (unless otherwise strictly stipulated by the TK and the use of alternatives is allowed),
- whether there are any technical nuances that can significantly affect the development process,
- whether what is stated in the TOR corresponds to the skills of a programmer.
At this stage of communication, it is necessary to be extremely accurate and not to allow the use of abstract phrases and concepts. More specifics is a better result. Do not forget that you are communicating with a “techie”.
Deadline, or the Far Side of the Moon
How many jokes and myths around the concept of “deadline” can no longer be counted. But, alas, in every joke there is a share of a joke, as you know, and everything else is true. Therefore, before you start cooperation, be sure to clarify all questions regarding the timing. If the time frame is important for the customer, he should emphasize this information immediately. You do not need to use general phrases from the series: “The faster, the better”, “As soon as you cope”, etc.
It’s also important to understand that changing the terms of the TOR on the fly and making thousands of edits a day is a bad idea. As a rule, nothing good will happen in the end. In addition to delaying the deadlines, most likely, there will be a number of misunderstandings between the customer and the developer, because the latter is unlikely to want to redo the same work ten times without changing the payment.
Are you looking one way?
Don’t be afraid to ask questions about how your project is seen by the programmer. Do your views on the final result coincide? If you find common ground, feel free to get started.
Patience and hard work…
Everything will be rubbed, but not in our case. If the customer is not satisfied with something, it is better to immediately say about it. The same rule should be actively applied to the programmer. If you discuss the misunderstandings and difficulties that have arisen in time, you can prevent serious problems in the future.
Needless to say, or Popular problems when working with programmers and possible solutions
Now let’s imagine that you are the developer who will communicate with the customer directly. Of course, the “beaten warrior” saw everything and probably in his practice met with different types of people. Here a quote from a famous fairy tale immediately comes to mind: “Go there – I do not know where, bring this – I do not know what.” It is this situation, alas, that acquires the label of typical, because quite often there are customers who cannot describe what exactly they expect in the final of cooperation.
And it happens the other way around: the presence of a clear technical specification and the technologies chosen by the client do not allow to implement the project at a high level. And even despite the recommendations to change the stack, the customer says a categorical “no”. This is just the tip of the iceberg. The most frequent problems that arise in the process of communication between the programmer and the client, we list below.
“I know you can do that. My friend has a similar project, and they used such solutions. “
Agree, it is very strange when the customer, who turned to the programmer for help, begins to teach him to do the work. It is worth listening to a specialist and accepting the fact that the developer knows more about which technologies are more cost-effective, what is relevant now, what language is worth writing in, what frameworks to use, etc. If the customer has any constructive wishes, you need to voice them immediately, but at the same time take the position of the more experienced side.
“It’s easy! I know it won’t take more than a week for the task.”
The customer does not have the right to assess the laboriousness of the work. At least from the position that he is not a developer and does not know all the features of the implementation of technical projects. Want to be more advanced? Read about Agile and Scrum approaches. Realistically estimate the timing by talking to the developer. But at the same time, do not allow yourself to significantly go beyond the previously announced time frame.
Enter the position
Treat with understanding possible problems, delays and force majeure. Anything can happen in life, and work processes are no exception. The customer should not be too harsh to single errors, at the same time, it is better for developers not to abuse the understanding of the client. And vice versa – you can not use the programmer to the maximum, and even more so to test the limit of his patience with too frequent changes in the work.
“And how many more, and what already … And at what stage?”
These and dozens of other similar issues as an annoying mantra slowly but surely destroy mutual understanding and the desire to cooperate. Hypercontrol and hyper-interference are “bad bells” that sooner or later will result in conflict. The customer should not be too intrusive, but at the same time beware of letting everything go by itself. Agree with the programmer that you will have a certain time for control calls. Or use resources like Trello to keep up with the process.
“I already had one programmer, here’s his code … Raise something, add yours..”
It is very good if the customer already has some kind of base and understanding of what the project is. But it is very bad if he wants a new employee to understand someone else’s code. Especially if the logic of his work is not clear at all, and the past developer has not even heard of comments. If the situation allows, it is best to start work with a clean slate or to provide a specialist with an understandable working code.
“This new framework/language/database will be better, I assure you!”
Of course, any programmer is interested in his own development. Who will happily do the same thing? If the customer is flexible in the choice of technologies, he can allow the specialist to act at his discretion. The main result! But if the client clearly knows what the project should be written on, it is worth correctly refusing the developer and insisting on his own.
Summing up, I want to voice a few tips that will help to communicate effectively and get the desired result:
1. “Instead of walls, build bridges.” Don’t avoid discussions and comments. Try to always find a consensus, an adequate dialogue will help to solve even the most confusing situation.
2. Everyone plays a role: you do not need to tell a professional how and what to do. After all, since you know everything, why don’t you do it yourself? At the same time, the developer should not impose his views and talk about the fact that he has redone dozens of such projects and knows how to do it.
3. Giving adequate feedback in time, arguing your position, allowing you to correct mistakes is already halfway to successful cooperation. Try to find a middle ground in the conflict that has arisen and adequately solve it without mutual accusations and insults.
4. And finally. It happens that mutual cooperation is simply impossible – it happens. The main thing is to understand this even before the start of work, so as not to lose any time or money.