The advantages of remote work are obvious - there are fewer restrictions in finding specialists with the necessary qualifications, the ability to hire people outside the Moscow Ring Road, less costs of doing business. On the other hand, there are problems: the most significant are from the organization of work. For the last 4 years I have been working as a team leader for a distributed group of programmers (3-15 people at different times) for a foreign customer, and I want to share my experience with this project :-)

Hereinafter, the following labor organization is meant:

1. The customer (+ on-site team is optional) in the office somewhere in Europe / USA.
2. Tim lead distributed team - somewhere in the vast expanses of exUSSR.
3. Members of a distributed team are also somewhere in the vast expanses of exUSSR.

It is understood that if desired, the customer can communicate with all team members. Payment for work - hourly.

To programmers

For a programmer, remote work can have both advantages and disadvantages. Of your benefits - less control, you can work faster than expected and do not wipe your pants unnecessarily. Of the minuses - the speed of your work is treated with great suspicion, long tasks make everyone nervous, the team is easy to fall into hard overtime.
')
You should pay attention to the following:

1. Your team lead must be adequate :-) This is the most important thing: if it is not so, then no matter how good the developers are, nothing will come of it :-) Either you have to leave or either. You should not wait for a logical outcome - the collapse of the project and tearing all the customer, write about the problems as soon as possible (you need to feel sorry for the nerves).
2. And the lead and the customer should always have an adequate idea of ​​what problems there are on the project, so you should always keep them informed: what exactly you are working on, what problems there are. If you see that you probably will not be able to meet the deadline, you should write about this as soon as possible to your Timlid. If the team leader does not respond to the situation, it will be his problem, not yours.
3. If you work remotely - it does not mean that you can work 1-2 hours a day :-) It will be noticed very quickly :-) Of course, if you know that you really work 40% faster than the average programmer with your salary (i.e. you underestimated), you certainly can do a day job for 5 hours, and 3 to rest (but not vice versa - 3 to rest, and then frantically work :-)). Of course, for your future it will be better if you take the tasks ahead of time :-)
4. Do not deceive anyone under any circumstances, and do not hide if something goes wrong. The bad truth is always better than the unknown. This item is probably the most important. It is necessary to find the strength to speak bad news, and this should be done as early as possible so that there is more time to react.

Tim leader

In a team, everything depends on you and your motivation. If you do not control how much someone does, who works faster and who is slower, you cannot limit an effective communication scheme, the project will simply stall with terrible consequences for everyone. Without control, the performance of the team can fall three times in 1 month.

The following items will help make work more efficient:

1. All team members must send a daily report on the time spent on the clock, at least two tasks per day. You should set the deadline for sending the report (for example, 2 nights Moscow time). For being late with a report - reprimanded, if repeated often - will have to find a replacement.
2. Whips and gingerbreads: reprimand, deprivation of bonuses, dismissal - will have to be resorted to much more often than in the office, because Many programmers can not work effectively remotely, with this nothing else can be done. At the stage of the interview is also not to find out. It would be nice to agree on a monthly bonus budget for rewarding the most diligent employees. You personally should also have a good motivation, but you will have to follow this personally.
3. All team members should have proper communication tools: Skype + microphone, screen sharing software (for example YuuGuu), access to bugtracker (for example trac or bugzilla - without this, tasks are quickly forgotten if there are more than 5-10), wiki for important information and internal documentation. All mail should be checked at intervals of 1 minute (however, if you are a supporter of non-interference in work, you can transfer all urgent communication to IM, and set the check interval to 30-60 minutes).
4. In all letters, time must be specified in the same time zone. This may be, for example, Moscow time, or local time of the customer. (The local time of the customer is convenient to look in Skype - in the contact information)
5. Team members should be familiar with svn, update the local copy at least every morning and, if possible, commit changes by the end of the day. You have to look through what they have commanded, and ask directly if you need to: “Did you really spend 8 hours on these 10 lines here?” (Of course there are lines on which you can really spend 8 hours). Programmers should be aware that despite the fact that no one physically stands behind their backs, the results of their work are constantly taken into account.
6. Policy is required for test and production servers: this can be either a test server with auto-update from svn, or a test server for each programmer. Production server must be updated by only one person (for example, you).
7. It is advisable to have mail accounts of all people on the same server. This eliminates problems with spam filtering, email delivery speed and maximum attachment size. Well, if there is a place where you can upload large files that no longer climb to the mail for good (50MB or more)
8. As in the case of programmers, you should not hide bad information and hide from the customer if everything is very bad. It is always better to say bad news as early as possible, and work out a reaction. If someone from the programmers tells you that they don’t meet the deadline, you must respond: either help themselves, or someone from the team will help, or overtime, or inform the customer about the shift in deadlines. I think that even if you cannot pass the project, but you will always be “in contact” with the customer (without breakfasts and unrealistic promises), you will not completely spoil his opinion about the Russian developers :-)

Conclusion

I hope this information will help someone successfully complete the project with a distributed team, and snatch a piece of the market from the evil Indians :-)