Off-Shore Development: From Concept To Reality
I'll talk about managing the project in a minute. But first, I wanted to mention that as part of the product specification process, you should absolutely do a search for what's already out there. Need a content management system that supports commenting? Take a look at Drupal. You get the idea. It's better to leverage existing pieces than to build from scratch.
You can get a variety of things built by people on sites like RAC. By this I mean, you are not limited to software development. Need articles for your web site? Want an entire e-book written but just don't have the time to write it yourself? No problem. Write the "product spec" and you can get people to bid on all these things.
You get what you pay for, especially with writing assignments. Want perfect English? You need to hire someone who converses with you perfectly when responding to your messages.
How to manage your project
First, I cannot stress this enough: managing a project is very time consuming. You don't just throw the product specification over the wall and then a week or two later get back the exact thing you had in mind. You have to manage this process from beginning to end.
Second, be realistic with your expectations. Never worked with a particular developer before? Don't ask them to build a perfect AJAX based word processing application from scratch. Can it be done? Yes. Do you want to 10,000 features in Version 1? No. So watch out for feature creep.
Third, establish a regular time to "speak" with your developer. I suggest twice per week. The reason you need to meet two times per week is that undoubtedly you will have something come up once in a while. You are working with someone 5 hours or 10 hours apart from you. This means that getting meetings scheduled is difficult. So regularly scheduled times allow you to just fall back to the next regularly scheduled meeting if something comes up. Your coder misses one meeting, that's a strike. Misses two meetings? That's game over.
Fourth, establish a relationship based on respect. Coder repeatedly shows up late for your online meetings? Fails to deliver what was promised? You have to manage through respect since your only other option is to send the project into arbitration, which can be a time consuming and painful process.
Fifth, if a deadline expires, do not, I repeat, do not, ask your coder to do more work without first agreeing on a new deadline. I made this mistake a few times -- it is so easy to do -- just say no.
Have I had bad experiences? Yes. I had a coder be incredibly rude to me. I cut that project off. I've had coders not deliver anything at all. But all this badness can be avoided by sticking to schedule, by establishing a relationship of respect (and cutting it off if respect is lost), and by regular communication; and, by testing a relationship out via a small project and then growing to a bigger one.
Lastly, make sure you are willing to cut your losses. As they tell us in business school - sunk costs are sunk costs. Yes, you may have already invested 20 hours in working with a particular coder. But if you're not getting what you want, it's better to kill the project and start over than to get further in the hole.
For larger projects, I cannot recommend enough a bug tracking system. Some coders already have these setup. There are also services online. For months I would exchange Excel spreadsheets with coders listing bugs and they would then fix them and send me back a list of fixed bug. This was a nightmare to track. A system like Mantis allows much easier bug tracking. Also, it gives YOU a sense of fulfillment because you are able to file bugs and not worry that you are going to forget the bugs you found.
Regular testing is a must. Developer sends you a release? Test it as soon as possible. File bugs. Cut features. The more features you can cut and the more you can focus on getting bugs fixed, the faster you will get Version 1 of what you want. If your product is perfect but it never gets out there because it's "not quite ready" then who cares how much time you invested in building the next great thing. What's most important is to get it out there and to start getting feedback, not for it to be perfect. This is product development 101.
Documentation As part of the project specification, make sure you ask for a page or two of documentation. This is something the coder writes up for you describing how the system they built works, what the key files are, and what the most critical functions are. In case you don't end up working with the same coder on future versions, this can help get another developer up to speed more quickly.
You can get a variety of things built by people on sites like RAC. By this I mean, you are not limited to software development. Need articles for your web site? Want an entire e-book written but just don't have the time to write it yourself? No problem. Write the "product spec" and you can get people to bid on all these things.
You get what you pay for, especially with writing assignments. Want perfect English? You need to hire someone who converses with you perfectly when responding to your messages.
How to manage your project
First, I cannot stress this enough: managing a project is very time consuming. You don't just throw the product specification over the wall and then a week or two later get back the exact thing you had in mind. You have to manage this process from beginning to end.
Second, be realistic with your expectations. Never worked with a particular developer before? Don't ask them to build a perfect AJAX based word processing application from scratch. Can it be done? Yes. Do you want to 10,000 features in Version 1? No. So watch out for feature creep.
Third, establish a regular time to "speak" with your developer. I suggest twice per week. The reason you need to meet two times per week is that undoubtedly you will have something come up once in a while. You are working with someone 5 hours or 10 hours apart from you. This means that getting meetings scheduled is difficult. So regularly scheduled times allow you to just fall back to the next regularly scheduled meeting if something comes up. Your coder misses one meeting, that's a strike. Misses two meetings? That's game over.
Fourth, establish a relationship based on respect. Coder repeatedly shows up late for your online meetings? Fails to deliver what was promised? You have to manage through respect since your only other option is to send the project into arbitration, which can be a time consuming and painful process.
Fifth, if a deadline expires, do not, I repeat, do not, ask your coder to do more work without first agreeing on a new deadline. I made this mistake a few times -- it is so easy to do -- just say no.
Have I had bad experiences? Yes. I had a coder be incredibly rude to me. I cut that project off. I've had coders not deliver anything at all. But all this badness can be avoided by sticking to schedule, by establishing a relationship of respect (and cutting it off if respect is lost), and by regular communication; and, by testing a relationship out via a small project and then growing to a bigger one.
Lastly, make sure you are willing to cut your losses. As they tell us in business school - sunk costs are sunk costs. Yes, you may have already invested 20 hours in working with a particular coder. But if you're not getting what you want, it's better to kill the project and start over than to get further in the hole.
For larger projects, I cannot recommend enough a bug tracking system. Some coders already have these setup. There are also services online. For months I would exchange Excel spreadsheets with coders listing bugs and they would then fix them and send me back a list of fixed bug. This was a nightmare to track. A system like Mantis allows much easier bug tracking. Also, it gives YOU a sense of fulfillment because you are able to file bugs and not worry that you are going to forget the bugs you found.
Regular testing is a must. Developer sends you a release? Test it as soon as possible. File bugs. Cut features. The more features you can cut and the more you can focus on getting bugs fixed, the faster you will get Version 1 of what you want. If your product is perfect but it never gets out there because it's "not quite ready" then who cares how much time you invested in building the next great thing. What's most important is to get it out there and to start getting feedback, not for it to be perfect. This is product development 101.
Documentation As part of the project specification, make sure you ask for a page or two of documentation. This is something the coder writes up for you describing how the system they built works, what the key files are, and what the most critical functions are. In case you don't end up working with the same coder on future versions, this can help get another developer up to speed more quickly.
0 Comments:
Post a Comment
<< Home