Off-Shore Development
I seem to get more and more questions lately about how I do off-shore development. I have developed several online products while in b-school all at low-cost and very functional. They include a shared shopping web site, an RSS poster, a complete advertising network, and some lead generation tools. Here's some more detail on how I go about doing this.
First, and most importantly, you have to know what you want built. I mean, exactly what you want built. The most important thing you can do is write a very detailed product specification. Personally I enjoy this part of the process, maybe because I used to do it for a living (and I of course still write product specs on nights and weekends).
A product specification really has two critical parts. One part describes the functionality. The other part describes the user interface - how you want users to interact with the product. In the case of a web site, it's best to be able to specify this down to the individual page level. Some people find this part frustrating or challenging, or both, and I understand why this is the case. It requires a lot of thought and many decisions to figure out what you want on each page. The good news, however, is that if you can get this down on paper, you will get something that looks a lot closer to what you had in mind than if you don't write it down. Remember that the software engineer, especially a developer who is not working in the same office as you, has to understand everything about what you want built from the specification you provide. The more detail you provide, the easier it is for the engineer to build what you want.
Here is a product specification I wrote last summer for www.rssense.com as an example. This specification is 17 pages single-spaced in Word. In more formal product or program management organizations, the user interface (commonly referred to as the "UI") and the functionality are specified in separate documents.
This is because a great software developer is not always a great designer, and a great designer is not always a great software developer. In fact, in many cases, I would say they are not the same person. As you write your specification, you will get a sense for whether you are more naturally a functional person (you enjoying getting into each feature) or a design person (you like talking about how the front page of your web site should look, what kind of graphics you like, the color scheme, etc.).
One of the best things you can do is to look at lots and lots and lots of web sites. Every web site has a design. Some are good, some not so good. But by doing this you will get a lot of ideas about how you want your own site or product to look and feel. When doing off-shore development, you may find that you got the functionality you wanted (or at least most of it), but when you show the site or product to your friends, they tell you it looks pretty bad. Then you can put out a separate bid (I'll describe this part of the process later) to get someone to tune up the site and make it look really nice.
What's critical is that you get the FLOW right. For example, take something as seemingly simple as user registration. How many fields do you want the user to have to fill out? Do you want them to have to click on a registration email to confirm they are who they say they are? What happens if the user forgets his password? And so on. These are all separate parts of the FLOW of your application. Try signing up for a bunch of different web sites - blogger, typepad, wordpress, flicker, yahoo email, ofoto, whatever. They each have slightly different ways of getting users signed up. What do you like? What don't you like? You might imagine that there is some toolkit in the sky that contains "sign up" routines - but actually this stuff gets developed over and over again. So think about what experience you want your users to have.
There are a couple of schools of thought on how to do design work. One school says you should basically do all the user interface design for a product first and then build out the functionality. The other school says that they sort of go hand in hand. As much as I try to get developers to build all the pages first so that I can actually feel how the flow I envisioned will work, the reality is that you usually get some amount of functionality in parallel with the development of the web pages. That is because laying out web pages down to the individual pixel level is no fun. What is fun is seeing the functionality actually work. So when it comes down to management of the project (which I will get to later), this is one of the biggest things, besides feature creep and schedule, that you have to manage.
In practice, functionality and design work are often done in parallel simply because it saves time.
In formal program and product management organizations, people actually build out mocked up screenshots of each page or feature of a program and then post these on the wall. Believe it. So for any given application or product, you might end up with hundreds (or thousands) of pages posted down the hallways and along the offices. I'm not saying you have to do this - you'll see that the spec I posted above is sort of a quick and dirty version of this - but this is one of the most important parts of the development process. I cannot emphasize enough that the less you specify, the more you leave up to chance.
Now, separate from this process is what is called the engineering or implementation specification. Those of you reading this blog probably don't want to deal with this, and in practice, given the size and scope of projects developed via rentacoder and other contract sites, this probably won't get done. In this specification, the engineer actually writes out for each function or feature HOW a particular piece of functionality will get implemented. I have found that it is sufficient to specify some basic platform requirements: PHP, Linux, MySQL, etc. And some basic parameters: no large graphics, etc.
Again, the less you specify, the more you leave up to chance.
The flip side is, if you over-specify, you will scare your developers. That's right. You have to find the balance between specifying and micro-managing. In practice, I've found that most people don't have this problem.
Also, give your developers credit. Give them a summary page up front that describes what the application does end to end. What's the purpose? It's very, very helpful to describe some usage scenarios. We used to describe these down to the individual person level - e.g. Joe is a systems administrator at a large bank. Here's how he will use the product. You don't need to get into this level of detail but my point is that you do need to put yourself in your users' shoes. Try writing a couple usage scenarios and this will really help you to describe the functionality and your developers to envision how the users will use your web site or application.
In my next post I will talk about the bidding process and then about managing the project.
First, and most importantly, you have to know what you want built. I mean, exactly what you want built. The most important thing you can do is write a very detailed product specification. Personally I enjoy this part of the process, maybe because I used to do it for a living (and I of course still write product specs on nights and weekends).
A product specification really has two critical parts. One part describes the functionality. The other part describes the user interface - how you want users to interact with the product. In the case of a web site, it's best to be able to specify this down to the individual page level. Some people find this part frustrating or challenging, or both, and I understand why this is the case. It requires a lot of thought and many decisions to figure out what you want on each page. The good news, however, is that if you can get this down on paper, you will get something that looks a lot closer to what you had in mind than if you don't write it down. Remember that the software engineer, especially a developer who is not working in the same office as you, has to understand everything about what you want built from the specification you provide. The more detail you provide, the easier it is for the engineer to build what you want.
Here is a product specification I wrote last summer for www.rssense.com as an example. This specification is 17 pages single-spaced in Word. In more formal product or program management organizations, the user interface (commonly referred to as the "UI") and the functionality are specified in separate documents.
This is because a great software developer is not always a great designer, and a great designer is not always a great software developer. In fact, in many cases, I would say they are not the same person. As you write your specification, you will get a sense for whether you are more naturally a functional person (you enjoying getting into each feature) or a design person (you like talking about how the front page of your web site should look, what kind of graphics you like, the color scheme, etc.).
One of the best things you can do is to look at lots and lots and lots of web sites. Every web site has a design. Some are good, some not so good. But by doing this you will get a lot of ideas about how you want your own site or product to look and feel. When doing off-shore development, you may find that you got the functionality you wanted (or at least most of it), but when you show the site or product to your friends, they tell you it looks pretty bad. Then you can put out a separate bid (I'll describe this part of the process later) to get someone to tune up the site and make it look really nice.
What's critical is that you get the FLOW right. For example, take something as seemingly simple as user registration. How many fields do you want the user to have to fill out? Do you want them to have to click on a registration email to confirm they are who they say they are? What happens if the user forgets his password? And so on. These are all separate parts of the FLOW of your application. Try signing up for a bunch of different web sites - blogger, typepad, wordpress, flicker, yahoo email, ofoto, whatever. They each have slightly different ways of getting users signed up. What do you like? What don't you like? You might imagine that there is some toolkit in the sky that contains "sign up" routines - but actually this stuff gets developed over and over again. So think about what experience you want your users to have.
There are a couple of schools of thought on how to do design work. One school says you should basically do all the user interface design for a product first and then build out the functionality. The other school says that they sort of go hand in hand. As much as I try to get developers to build all the pages first so that I can actually feel how the flow I envisioned will work, the reality is that you usually get some amount of functionality in parallel with the development of the web pages. That is because laying out web pages down to the individual pixel level is no fun. What is fun is seeing the functionality actually work. So when it comes down to management of the project (which I will get to later), this is one of the biggest things, besides feature creep and schedule, that you have to manage.
In practice, functionality and design work are often done in parallel simply because it saves time.
In formal program and product management organizations, people actually build out mocked up screenshots of each page or feature of a program and then post these on the wall. Believe it. So for any given application or product, you might end up with hundreds (or thousands) of pages posted down the hallways and along the offices. I'm not saying you have to do this - you'll see that the spec I posted above is sort of a quick and dirty version of this - but this is one of the most important parts of the development process. I cannot emphasize enough that the less you specify, the more you leave up to chance.
Now, separate from this process is what is called the engineering or implementation specification. Those of you reading this blog probably don't want to deal with this, and in practice, given the size and scope of projects developed via rentacoder and other contract sites, this probably won't get done. In this specification, the engineer actually writes out for each function or feature HOW a particular piece of functionality will get implemented. I have found that it is sufficient to specify some basic platform requirements: PHP, Linux, MySQL, etc. And some basic parameters: no large graphics, etc.
Again, the less you specify, the more you leave up to chance.
The flip side is, if you over-specify, you will scare your developers. That's right. You have to find the balance between specifying and micro-managing. In practice, I've found that most people don't have this problem.
Also, give your developers credit. Give them a summary page up front that describes what the application does end to end. What's the purpose? It's very, very helpful to describe some usage scenarios. We used to describe these down to the individual person level - e.g. Joe is a systems administrator at a large bank. Here's how he will use the product. You don't need to get into this level of detail but my point is that you do need to put yourself in your users' shoes. Try writing a couple usage scenarios and this will really help you to describe the functionality and your developers to envision how the users will use your web site or application.
In my next post I will talk about the bidding process and then about managing the project.
0 Comments:
Post a Comment
<< Home