[consulting] oDesk

[Domenic Santangelo]

On Tue, May 5, 2009 at 12:58 AM, Matt Chapman <Matt at ninjitsuweb.com> wrote:
> Oh, but I forgot, contractors are different from employees. It's OK for them
> to over-inflate their experience and bill me for time spent learning what
> they said they already knew how to do....

That's why you (as the client) get an estimate and a rate, or (as the
consultant) don't move forward without providing an estimate and a
rate. In addition, I have to differ with you and say that
/automatically/ disqualifying paying for time spent learning is
short-sighted. Not that it's the best in every case, but consider this
hypothetical:

You ask for a bid for Feature X from two devs. One is a top-rated
well-known community member who estimates he can get it done in 16
hours @ $175/hr ($2800). The other is a relative newcomer who says he
can get it done in 30 hours @ $60/hr ($1800). There, you saved
yourself $1000 AND contributed to the education of a community member.
Lucky you! This savings of course assumes that he actually /can/ get
it done, etc etc but I think you get the point.

Now, if you're talking about billing you for time spent reading jQuery
for Dummies... well.. maybe that's a different story. But I encourage
you to keep an open mind. Don't spend so much time worrying about
whether or not you're getting ripped off, instead worry about value as
a whole. Does your contract stipulate that you'll get the deliverables
you want in the time you want for the price you want? Then go for a
walk and enjoy your good fortune and leave the worry to the (sub)
contractor. Far, far, far too much time is wasted (by a great many
people) fretting over every little dime. If you, as the one paying the
contractor, want to be assured in the value that you're getting, WRITE
IT INTO THE CONTRACT. Then, leave the poor dev to do their work. Check
up on them, yes - phone calls, skype, whatever, maybe once or twice a
day if they're not blocked; less if you're comfortable with that.

The point is effective communication. VNC'ing into my box or pinging
me every 20 minutes asking "How's it coming?" isn't effective, it's
controlling. Phone calls are effective, scrums are, ticket tracking
is, email is (usually). Tools like the ones talked about earlier are
nothing more than a smokescreen to make buyers feel more comfortable
while providing little true value. The objectives you hand off should
be Specific, Measurable, Achievable, Reasonable, and Timeboxed. What
is checking up on your developer thru screensharing measuring? Lines
of code? Time spent in vi? It's ultimately irrelevant to performance.
Like you said earlier, deliverables are what count. (See my blog post
about S.M.A.R.T. project management here:
http://www.workhabit.com/labs/smart-project-management ).

And here's the ironic part -- no matter what you think your level of
control is, if someone really, truly wants to screw you over they will
find a way, no matter how many times you look at their desktop.

-D

-- 
Domenic Santangelo
senior engineer  |  workhabit,inc.

// email: domenic at workhabit.com  |  web: http://www.workhabit.com
// office: 866-workhabit  |  direct: 916-288-8243