Wednesday, November 02, 2005
RentACoder, eLance et al - The Problems
So, as rent comes rolling around, I am drawn back to RentACoder-type freelance sites for those mythical 2-4 hour projects with good wages that I talked about earlier.
They do exist: I'm currently trying to swing a deal to model 60 chemical structures in a proprietary XML format for $250 -- the knowledge is all public domain, it's just a little matter of data humping.
From my point-of-view, these freelance sites are incredibly valuable as potential sources of work but their interface is not nearly refined enough to allow me an efficient experience. This got me to thinking - how can I streamline my experience with RentACoder (and eLance, should I choose to try the waters there)?
To answer this question, let's break down the bidding process into steps and substeps.
Clearly, the $250 project is not really a $250 project. So if this overview of the experience gives an accurate view of the problems, how we can improve the process? I've got some ideas, and I'll post them here later.
They do exist: I'm currently trying to swing a deal to model 60 chemical structures in a proprietary XML format for $250 -- the knowledge is all public domain, it's just a little matter of data humping.
From my point-of-view, these freelance sites are incredibly valuable as potential sources of work but their interface is not nearly refined enough to allow me an efficient experience. This got me to thinking - how can I streamline my experience with RentACoder (and eLance, should I choose to try the waters there)?
To answer this question, let's break down the bidding process into steps and substeps.
- Get a wide list of candidate projects - Obviously, I'm only interested in projects I can successfully complete, and thus get paid. That is, after all, the point of living, right? So this step breaks down into:
- Get list based on project type - You can only filter on broad properties of the project such as "Web-based application" or "Visual Basic" application", not on narrower domain-related properties such as "enterprise web-based GIS applications". So, you end up setting very broad parameters and filtering by the project's name. "HTML to address list parsing program": Yes. "Web Control expert": Maybe. "Duplicate eBay.com and PayPal.com": No.
- Trim list based on project budget: You can only filter on really, really broad categories: Unknown, 0 - 100, 0 - 500, 0 - 5000, >= 5000. Notice something weird here? I know my father would. Besides being very coarse-grained and having a predilection towards smaller budgets (which suggests something about the average project), there are 4 budgets which can specify a price range of "0 - 100". Grrr, bad overlap! Again, you can compensate for this by applying some fuzzy logic. "HTML to address list parsing program": @ 0 - 100, Maybe; @ 0 - 500, Definitely.
- Get list based on project type - You can only filter on broad properties of the project such as "Web-based application" or "Visual Basic" application", not on narrower domain-related properties such as "enterprise web-based GIS applications". So, you end up setting very broad parameters and filtering by the project's name. "HTML to address list parsing program": Yes. "Web Control expert": Maybe. "Duplicate eBay.com and PayPal.com": No.
- Trim list of candidate projects - Not all buyers are equal. Is this buyer a good fit for me? Are they willing to pay reasonable rates in order to get the security of dealing with someone with a shared cultural background? This involves:
- Learning if the buyer has the brains to complete the transaction - Based on their bid, do they know what they want? If not, does it look like they would recognize what they want if you helped them along? There are some projects that are terrible for this sort of thing. "Build us a website using TSN data. Project budget: $10,000." Not worth looking at at all. "We're looking to build a website which lets hockey fans review club statistics using TSN's live XML feeds. Although we're not exactly certain about what we want, we know we want Flibberjabbers and Doodads. Gewgads might be added later. Project budget: $8,000." Maybe worth looking at. After all, do I want to spend time helping them flesh out a bid that they can then hand over to someone else?
- Deciding whether or not the buyer is a serious buyer at the given price level - How many cancelled project requests has this person had in the past? How many completed projects has this buyer had? Does this project mark a change in their buying habits (e.g. it's their first $5000 project after 39 $40 projects)? How likely are they to complete the transaction?
- Discovering whether the buyer shares cultural traits - Have a look at their bid. Is the English well-written? Do they sound like someone who would respond better to "I can certainly assist you in this matter. At my rate of $50 / hour and an estimated 75 hours of work, this project will cost you $3,750." or to "GREETINGS ! IT BE ARE HAPPY TO DO THESE WORK FOR U ! PLEASE BE FINDING ARE BID OF 10$ TO YOUR GOODNESS !"?
- Discovering how difficult the buyer is to work with - How many projects of theirs have gone into arbitration? Of their successful projects, how do they rank the coders who worked for them, and how do the coders rank them?
- Discovering what the likely winning price will be - Look at their past projects. What's the buyer's "going rate", that is, the rate which they usually pay out?
- Learning if the buyer has the brains to complete the transaction - Based on their bid, do they know what they want? If not, does it look like they would recognize what they want if you helped them along? There are some projects that are terrible for this sort of thing. "Build us a website using TSN data. Project budget: $10,000." Not worth looking at at all. "We're looking to build a website which lets hockey fans review club statistics using TSN's live XML feeds. Although we're not exactly certain about what we want, we know we want Flibberjabbers and Doodads. Gewgads might be added later. Project budget: $8,000." Maybe worth looking at. After all, do I want to spend time helping them flesh out a bid that they can then hand over to someone else?
- Make bids - Even this step is not straightforward. It requires:
- Asking questions and build rapport - You're making a fixed-rate bid on a project. This is one of the most idiotic things to do in the software business. You want to ask a lot of questions and get the specification nailed down (or as close to as possible). You also want to build rapport and get the buyer on your side. Why? Well, you want him to pick you, but also because you're going to charge him a 20% premium for wiggle-room to allow for changes in the spec during development.
- Making the bid - The bid should be a detailed, well-formatted document expressing exactly what you are going to do. For a small project, this may be only 1 - 2 pages with 0.5 - 1 pages being boilerplate template. For a larger project, this may run up to 10 pages covering general feature points.
- Asking questions and build rapport - You're making a fixed-rate bid on a project. This is one of the most idiotic things to do in the software business. You want to ask a lot of questions and get the specification nailed down (or as close to as possible). You also want to build rapport and get the buyer on your side. Why? Well, you want him to pick you, but also because you're going to charge him a 20% premium for wiggle-room to allow for changes in the spec during development.
Clearly, the $250 project is not really a $250 project. So if this overview of the experience gives an accurate view of the problems, how we can improve the process? I've got some ideas, and I'll post them here later.
