I've been hiring several developers from different places around the world. It all goes well, but I see that some of them are abusing my polite overlooking too much lately.
They are all hired for a full-day. However, I see that after 5 hours in a day, not much has been done.
I am considering to develop a software that will take a screenshot of the computer screen every 1-5 minutes and upload it to my system. However, this is going to the extremes.
How do people usually manage remote developers?
You hire honest programmers, and you (in consultation with them and possibly other honest programmers as a reality check) set reasonable goals in short time lines. If they don't meet the goals, fire them. If they do meet the goals, then it shouldn't matter to you if they play solitaire for 2 hours straight while they're clearing their minds and mulling over a problem.
Screenshots seems counter productive. If it comes to that, you're in trouble.
The ideal is to have tangible milestones, and check their progress against them. If you can't get your money's worth on the milestones based on the amount of time you have to pay to get them, find other help. If you can't create the work at this level of detail, and don't know if you're getting ripped off, it might be inappropriate to source the work remotely. You could introduce a system of competitive bidding for the work, but if you can't detail what's needed at a low level, can you tell what the code quality is?
In general outsourcing and remote work should be about buying results, not buying time. Otherwise, as you've found out, the trust breaks down.
What you want is called a contract. The contract say what they have to deliver and when, and what you have to pay and when.
As simple as this. Everything else would be dramatically counter productive. It will break confidence between you and the freelancer. If you want to closely look at what people are doing, then consider hiring in your office.
They either produce enough code for what you are paying or you find someone who can. If they pounded on their keyboards and mice for 10 hours a day and produced garbage, are you still going to keep them just because you're paying them for 8 hours?
Set demands and get agreed upon deadlines. If you can't agree, hire people who will. You're a programmer and should be able to spot if they have hit legitimate obstacles or not.
I would create an excel sheet with a break down of each feature.
The contractor should update this daily.
Each item should have a progression defined in terms of %.
When a feature is 100%, it should be ready for you to "sign off".
If an item does function as expected, then this item needs to be flagged and corrected.
You need to be comfortable with the people you are hiring, before you hire them.
At the point you are thinking of essentially spying on the people you hire, it is too late. I am an honest programmer, but I wouldn't work under those conditions (even assuming that they are legal). It's like when you cross the border - you might not be hiding anything, but they sure make you feel like you are.
Do background checks, get references, ask questions. Use reputable services. Make careful decisions, and then follow the advice in the other answers given here.
I have been working with Scrum lately and I can tell you. With this Agile methodology slackers has no room to avoid transparency. And also proves that you are being a good manager/leader dispatching them achievable tasks.
Are you paying for results or time? If you're paying for results, then it's none of your business how long they take to achieve those results. If you're paying for time and you don't think they are being honest about their time, let them go and find someone else-if you can't trust them, what good are they?
If you provide the environment, recording is an option, but you'll need to inform them first, which will give them the ability to fake it. How long does it take them to search for the answer to a problem? Reading offline resources, simply sitting and thinking? If they aren't honest, all you're going to do is spend a lot of your time getting inconclusive results. If they are honest, you're probably going to offend them and they'll move on. Either way, they are gone.
What about source code repositories and you require them constant committing. Small, atomic commits: "commit early, commit often." Utilize DVCS's features (branches, tags) to commit stuff that isn't meant to be included in the final product.
That way you can have pretty good idea what is done, what has to be done and so on.
