Crowdsourcing is the new buzz word floating around the internet lately. Wikipedia defines it as "the act of outsourcing tasks, traditionally performed by an employee or contractor, to a large group of people or community (a crowd), through an open call". Though this a new term, the concept itself is not so new. It literally means outsourcing to the crowd. The Open source revolution which started almost a decade back is successfully tapping the power of the community to develop software. The key driving point of Crowdsourcing is participation and collaboration with the general crowd (or users) who use your applications and leveraging their expertise and time to enhance your product. Companies like Microsoft, Apple and Google etc have successfully tapped the potential of Crowdsourcing and made millions out of it by virtually investing nothing.
Over the years our project teams have matured in the way they handle the implementation of an Internationalization project, however things were not always so smooth. There were times when the project was tested and delivered to the client, but it refused to work on the client’s machines. The offshore team just couldn’t figure out the reason for this to happen. A lot of fire fighting effort was then required to get things back on track and take corrective actions. Most of the problems were due to wrong planning, lack of technical understanding and incorrect assumptions. Things are pretty much streamlined now with an i18n Center of Excellence (CoE), i18n frameworks, analysis tools, POC’s and best practices in place. Here I am going to recollect my earliest Internationalization experience and what we learnt from it.
Imagine yourself going to Japan to open a restaurant. Your market research says that your burgers are going to sell like hot cakes there, so you have planned a major investment there and drawn up plans for expansions. You land at the Narita airport and are absolutely clueless on how to get out of there. You look around and find that all directions and signs in Japanese. You try to ask for directions but all you get is blank stares because no one understands English. Somehow you manage to find your way out and get busy with your work. After a lot of hard work, you finally open your restaurant but you don’t find many people walking in. Your business goes dry and it’s difficult to survive with so much local competition around. What is really going wrong? Didn’t your market research say that you are bound to succeed?
As a product company your team has come up with a brilliant concept which has tremendous marketing potential in your country. Your marketing survey shows that the concept will soon catch up with other countries across the globe and you can capture the overseas market too. The only catch is that the product will be required to be globalized before it is launched in the international markets. A global launch is still 5-6 months away, so what product strategy will you adopt? Develop the product in English and later when you have access to the global markets, think of internationalizing it or start developing an internationalized version of the product right from conceptualization stage so that you are ready to penetrate the global markets when the time comes? This is a question most product managers will face while developing a product.
Effort estimation is the first step to undertaking any software project and a Globalization project is no different. Effort estimation for a product or application which needs to be Globalized follows more or less the same estimation principles as regular maintenance projects, yet there are no defined methods specifically for estimating the amount of I18N or L10N changes required. While working on the proposal for a Globalization project for one of our clients we were faced with the dilemma of adopting standard methodologies like SMC based estimation, FP based estimation etc or trying to create a hybrid and come up with our own estimation model which follows the same estimation principles but is more tailored for globalization projects. Finally we came up with a raw estimation model which was fine tuned over time and gave us estimates which were statistically inline with the results from other maintenance projects.