Organizing a Product Team

Identifying world-ready requirements in your specifications and customizing features for the global market are two essential steps toward designing a world-ready program. Of course, having people who will implement your plans is obviously another vital component. Putting together an efficient product team is a challenge that can make a significant difference to your bottom line. If your entire team-including developers, designers, testers, translators, marketers, and managers-is committed to all language editions of your product, and if management holds them responsible for all language editions, you won't have to hire a lot of extra people.

The golden rules for product team managers are as follows:

• Educate all product team members on internationalization issues.
• Hold all team members responsible for the international functionality of their features.
• Develop at least one localized or pseudo-localized edition in parallel with the domestic edition. (See Chapter 12.)

Managers might argue that holding all team members accountable for all international products will cause them to lose focus, but in reality such a policy will save time and effort in the long run. Developers who are responsible for only the domestic edition of a product have no incentive to design global code, and might not even know how to do it. Later, when problems are uncovered during software translation and testing, those developers will have to spend time fixing errors that would have been easy to avoid; instead of working on the next version of the product, they will be busy redesigning old code. If your team creates a program so domestically centered that bitmaps must be changed or features redesigned, you will sacrifice consistency among language editions. If you choose to minimize the time spent fixing internationalization problems, you will release poor-quality products. Fixing and adjusting an existing product takes time, during which your company pays salaries and loses sales.

Microsoft used to have separate teams working on each product-one for domestic software and one or more for international software-and each one reported to separate managers and had different objectives. The domestic teams wanted to finish their English products as quickly as possible, with a minimum of interference. The international teams wanted to release localized editions as quickly as possible, and constantly needed domestic teams to make changes that would lower localization costs. This arrangement created an "us vs. them" mentality, because each team invariably had different priorities and felt the other was making its job harder.

Eventually Microsoft merged the domestic and international teams, but managers still assigned responsibility for international editions to "international developers." Just as before, these developers had to contend with algorithms that were not designed for multiple languages, and they had to decipher code that other people wrote.

This old approach, with its sense of being disconnected, contrasts with the current approach, with its emphasis on being a cohesive unit. The results are clear. For the Windows XP project, the German language edition of the system was shipped the same day as the English edition. In addition, many language editions-including Chinese, Japanese, Korean, and several European languages-shipped within 21 days of the English release. This was an improvement of more than a year over the release delta between English and Japanese Windows 3.1. These goals were achieved because, after Windows 3.1, Microsoft moved all the development for Windows to Microsoft's headquarters in Redmond, Washington. The teams working on features related to East Asian languages, complex scripts, and multilingual versions worked alongside the rest of the Windows XP team and reported to the same managers. The Windows XP team was thus able to meet strict milestones for delivering localized editions of their operating systems.

Although some teams are still tempted to follow the old approach, it has proven to be a very inefficient way to create international products. Developers find it much easier and more rewarding to be the experts on a subset of features than to be jacks-of-all-trades trying to maintain a working knowledge of an entire product code base. And if you hire one or two people to monitor all international functionality, you are basically paying some developers to clean up after other developers who will continue to make the same mistakes. Why pay someone to fix design problems and bugs that educated developers can prevent in the software's planning stages?

As you delegate more responsibility for world-readiness to each member of your development team, remember that changes aren't likely to occur immediately. It takes time to instill global thinking into your company culture. A good example of the need for perseverance can be seen in the development of Microsoft Word. In the earlier versions, there were many different localized code bases. However, persistence has paid off. With team members sharing the responsibility for world-readiness, all localized versions of Word XP are now created from one code base. (See Figure 2-3.)

Figure 2.3 - The gradual convergence of localized versions of Word into a single, world-ready binary. ¹

In addition to promoting a company culture of world-readiness that trickles down to each individual, you will also need to consider the needs of some key people-your translators. (For more information, see "Making Life Easier for Translators" later in this chapter.) Quick release of localized software requires that translators begin work early. If you plan to hire translators from abroad, remember that it takes time to obtain work visas for noncitizens. Microsoft employed in-house translators and third-party contractors to translate German, East Asian, Arabic, and Hebrew editions of Windows XP in Redmond. All other European editions of the operating system were translated, tested, and manufactured at Microsoft's subsidiary in Ireland. The subsidiary also hired third-party contractors in Europe. If you do hire a third-party localization company, make sure that translators have direct access to members of your product team, or you will lose some of the efficiency and other benefits gained with early translation.

Much of the expense and lost productivity resulting from any inefficient approaches described in this section drain a project's resources subtly over time, and might be apparent only to people who prepare budgets and earnings reports. If you are having a difficult time convincing your company to change its approach to internationalizing software, arm yourself with schedules, bug lists, and sales statistics from past products. Back up that ammunition with market research and testimonials from product team members. Finally, show people this book.