Offshore Development and Designing
It is clear that outsourcing creates a significant impact on the entire software design and construction process. Offshore development is in its infancy, but will continue to evolve to become an increasingly effective way to go about certain kinds of software construction. This article describes a number of observations worth considering as you ponder how outsourcing and offshore development may fit into the new strategies.
Globalization looks like it's going to be a fact of life in the software industry. Outsourcing and offshore development are sensations these days. It's been on the cover of major newsweeklies, featured prominently on the West Wing television show, and a topic of conversation around boardrooms and discussion groups. And it is being accepted worldwide.
Experienced Developers
In addition to their coding chops, the developers are also likely to have significant domain knowledge and context about the product. The developers work in a given sector for a considerable amount of time. This helps them make decisions when specifications fall short or technological limitations force them to change course. And of course, it soothes the work.
Even the traditional in-house model developers are best served by clear and detailed design documents, but we traditionally rely upon their ability to understand the patterns and principles behind our design solutions to extrapolate solutions to new problems. So it is beneficial.
Lack of sufficient knowledge about your products
The real fact is that offshore "resources" may only be assigned to your project for a very short amount of time and they may be quite inexperienced and staffing may be insufficient across your project. Such developers may not understand the big picture of your product vision and they may find difficulty to make decisions about functionality and interface on the fly. So this problem should be cleared.
Efficient and Effective Communication
The use of offshore development changes the whole collaboration dynamic. The most efficient and effective way to convey information and drive decisions is through face-to-face conversation.
A designer, is non confident about a solution until he/she share it with the person responsible for building it. And it should make possible when the person responsible for building a design is in Kerals and the client is in Canada.
If we design an area of the screen to offer products that a user may be interested in, someone must assess the practicality of enquiring the data warehouse to score and sort items in the list. If it increases page-load time by 5 seconds we may decide that it should be offered as secondary functionality on another page. In an offshore development scenario, this feedback may not be generated until design is complete and construction has begun. So it is matter of concern.
The technical aspects
There is the additional need for the design and documentation of all technical aspects of the product which is beyond evaluating the technical feasibility of interaction designs. There is importance of differentiating the activities of engineering and programming, where Engineers are responsible for solving technical problems and determining how the software is to be constructed. And also the Programmers are responsible for actually producing the shipping code that comprises the product.
It is evident that a product organization relying on offshore development still needs engineering resources in-house. It has to validate the feasibility of proposed interaction designs first, and secondly it has to document the technical aspects of the design. And this is t a small task. While Interaction Designers are capable of designing and documenting a complete definition for all user-facing aspects of a product, there is a lot that goes on behind the scenes that also must be documented for the product to work properly. It is essential.
Provide clear explanation to the builders
There are both good and bad news about offshore developers. They will build exactly what you tell them to build.
They take your specification very seriously, not as a suggestion or starting point from which to improvise. And this is good news.
And the bad news is that if you don't clearly plan and articulate every aspect of your product from user interface and product behavior to business logic and algorithms, developers are forced to rely on their own experience and judgment to determine an appropriate solution to the problem or non planned documented feature.
Wall Street Journal article on Indian Engineers
The summary of this article is that Indian engineers, who knew little about the software or how it was used accustomed to work closely with veteran engineers familiar with the products and the U.S. managers offered only vague outlines for each assignment. The less-experienced Indian engineers didn't include elements in the programs that were considered standard among U.S. customers. U.S. programmers rewrote the software, delaying its release by months.
This problem not only will not meet your expectations but also limits your ability to hold the development organization accountable for the end product. Without clear and complete specifications, it is impossible to contractually define project completion and deliverable acceptance criteria. What you end up saving on a dollar-per-hour basis can become dwarfed by endless iteration and a failure to get a desirable product to market. So be prudent in getting developers and recruit them with sufficient ‘scanning'.
Conclusions
It is concluded that the designers get an effective and pleasurable experience to your customers. And also communication is one of the critical ingredients to this design process. And it is true if you decide to have the product built in India or Eastern Europe. It is important to define, design and document especially every aspect of the product. And it draws success of the outsource product.
