8 tips for finding a remote team

2024 Author: Malcolm Clapton | [email protected]. Last modified: 2023-12-17 03:44

Once at the market I got into a conversation with a trader from Azerbaijan. Word for word, and we suddenly went from picking fruits and vegetables to starting his small business. Mamed has more than 10 retail outlets in different Moscow markets. To your question: "How did you manage to organize everything?" - I got the following answer:

It's not important for business to be smart. If that were the case, then all academics would be rich, but they are not. It is not important for a business to physically move a lot. If this were so, then the movers would be the richest. It is important for business to connect all parts into a whole.

Mamed fruit merchant

This is how, without any MBA, a simple trader deduced one of the main rules of business. Later, from my own experience, I was convinced of the validity of his words when I was looking for performers for my project on the remote work exchanges Odesk and Elance. It is very difficult to find a programmer and designer with whom you will have a mutual understanding, who will work not only for the sake of money, but also for the final result, who will themselves say: “Let me fix it here, it will be better”, is very difficult. Such masters are very rare.

And if you're determined to put together a remote team to work on your application, here are eight tips.

First advice. Work with programmers who speak the same language with you. In the course of work, there will always be moments that require clarification. The language barrier will hinder effective work.

Second advice. Try to work with programmers from the same time zone as you. In the work of remote commands, there is such a thing as ping. It would seem that the simplest request, for example, to change the color of a block from red to green, can be carried out by a designer for 2-3 days! How many such moments can there be? Dozens. In general, ping is one of the weakest points in the work of remote commands. If in the case of a team located in the office, the deadline for finishing work on an application must always be multiplied by three, then when it comes to a distributed team, at least five. That is, if you, your programmer and designer agreed to do everything in a month, then in reality everything will be done in five months. And you can't get away from this!

Third advice. Try not to work on prepaid basis. Prepayment is usually asked by those specialists who are mentally ready to give up the project in a quarter and a half of the way. Odesk and Elance provide effective tools both to protect the programmer from the dishonest customer and to protect the customer from the bad programmer.

Fourth advice. Never offer programmers to become business partners in exchange for making the application development cheaper. Honestly, such a mistake can only be made once in a lifetime. As a rule, in return for lowering the development cost, the customer offers the programmer a portion of the income from the application, called royalties. Ultimately, everything will come to the following: the person who has, say, 20%, will manage you, who has 80% of the rights to the application.

Fifth advice. Before starting a joint work, agree with the performers how often you will discuss the progress of the work and receive intermediate options. Yes, constant monitoring is necessary. There are, probably, unpleasant moments in this, as in any control, but this is better than hearing two weeks after the start: “I haven't started yet. I have problems here, the neighbor upstairs flooded it …"

Sixth tip. Negotiate with many performers. Ask them about the price, ask them to show published applications in the App Store. Search Google or Facebook for information. Study the artist before you start collaborating.

Seventh advice. Try to find a programmer-designer. Or an established pair of programmer and designer. It's difficult, but in this case, you can be calm about the quality of the application.

Eighth advice. Try to respond as quickly as possible to requests from performers to clarify something, provide additional materials, and so on. Remember ping, don't let your own laziness slow you down.

These eight tips, of course, do not pretend to be complete, but, in any case, give an idea of how to properly organize the work of a remote team. What is your experience? Share your tips in the comments. Let's put together a joint guide and help programmers, designers and publishers organize their teamwork properly.