Discover what software outsourcing artifacts work and which don’t from Accelerance client Keith Hardwicke from K&L consulting. First he tells the story of how he “accidently” became a programmer after getting his PhD in Electrical Engineering. And then how he was thrown into outsourcing and told to make it work. Somehow!
Suddenly, he and his team went from being software builders to being software describers.
Sound familiar? His journey is similar to many American programmers and managers who have had offshore software outsourcing thrust upon them.
But there is a happy ending. And there can be one for you too.
Providing too little, or the wrong information to specify a software development project will torpedo any attempt at outsourcing. You can spend days and weeks trying to explain what you want and/or keep your outsourced programming team on track.
Even providing too much information will backfire. It is very difficult to think of every contingency when you write a specification and written English is subject to misinterpretation, especially by a programming team using English as a second language. Therefore, the programming team will assume your specifications are strict instructions and give you just what you ask for. Even if it seems a little “strange” to them.
What specifications or “artifacts” are necessary to drive outsourcing of software development?
Keith describes the trial and error process of using several approaches to describing the software they needed that eventually led to a tight set of artifacts they found worked the best at directing a team of programmers offshore.
Even with good specs, you can still waste months of time and thousands of dollars if you select the wrong software outsourcing vendor. Keith describes how he found an excellent programming team in Ukraine after trying programmers from several other companies in several parts of the world.
Keith discovered that only three types of artifacts are really useful for specifying software for an outsourced programming team:
- Wireframes – sketches of the user interface showing the buttons, lists and other elements used to interact with the application. Included on the wireframe drawings are callouts or annotations with short snippets of information about how the software functions. They describe what happens when the user interacts with the user interface.
- Domain Model – similar to a database entity-relationship diagram that shows at a high level the objects modeled in the software. These objects usually correspond to things in the real world. For example, in the video interview application (described in more detail below) there are the videos, questions, statistics and different types of users and organizations you would expect to have in a human resources and job hiring situation.
- Functional Specification – adding more details of the application functionality that will not fit as annotations on the wireframe. This document is kept as short as possible since the programmers will rarely read long ones, especially if English is their second language. A useful part of the functional spec is Glossary defining in one place the terms used in the domain and user interface of the application.
In total, it’s usually from 25 to 40 pages of documentation for each sprint or iteration of software development.
In the webinar Keith describes the development of a video interviewing application using the Internet to enable job applicants to record themselves responding to a set of interview questions for later review by the hiring manager.
Describing the functionality of this software was fairly straightforward using the techniques describe above. Next problem? Finding a good offshore vendor who could develop the software by outsourcing Ruby on Rails. Keith selected Ruby on Rails because it minimized the architectural decisions to make and has been proven to streamline the development of web applications. But Ruby on Rails was a new platform for him and he needed a software outsourcing partner experienced with this software technology.
First he tried an Indian vendor who contacted him. He sent the artifacts describing the pilot project and in a week he received the Ruby code. It worked but used none of the Rails framework such as Active Records and automated build capabilities.
Next he tried Google searches to find a Ruby on Rails vendor and contacted the top 20 in the search results. Accelerance was one company who responded along with a company from Argentina. Accelerance recommended our partner in Ukraine based on several requirements Keith shared with us, and this was the vendor he ultimately selected.
Someone watching the webinar may jump to the conclusion that you should not outsource to India or outsource to Argentina. That’s wrong – Accelerance has excellent partners in both countries. But Keith’s story does illustrate the difficulty of finding a qualified offshore software outsourcing vendor by simply searching the web.
Watch the webinar and discover the best way to find your offshore software outsourcing vendor and how to describe the software you want developed once you do.
Until next time,
Steve Mezak, CEO
Steve@Accelerance.com
Accelerance, Inc.
Risk-Free Outsourcing
+1-877-99-ACCEL (877-992-2235) x101 Toll-Free
+1-650-472-3785 Global Calls + Fax
Or contact me at: http://www.Accelerance.com/contact.htm
Author of the new book -
Software without Borders: A Step-By-Step Guide to Outsourcing Your Software Development
www.accelerance.com/swb.htm
|
An Accidental Programmer's Journey to Offshore Development: |
||
|
Comments