82403f9397b8d7e8277cf526686e9673.ppt
- Количество слайдов: 50
Localisation Resource Centre Summer School Introduction to Localisation John Malone
Agenda • • Definition of Localisation Process and Schedule Localisation for the WEB Issues and Considerations
Localisation. What is it? • Process • Language • Culture
Localization is the process of creating or adapting a product for use in a specific target country or specific target market.
S. I. Hayakawa No word ever has the same meaning twice. To insist dogmatically that we know what a word means in advance of its utterance is nonsense. All we can know in advance is approximately what it will mean.
How about Culture? • Are there efficient ways to describe cultural differences? • Or are we encouraging a sophisticated stereotyping?
Let’s examine a simple matter like colour Culture Red Yellow Green Blue Europe/West Danger Caution Cowardice Safe Sour Masculine Sweet Calm Authority Japanese Anger Danger Grace-nobility Childhood-gaiety Future Youthful- energy Villainy Fertility-strength Virtue, faith, truth Arabic Happiness Prosperity Chinese Joy-festivity Honor Royalty
Localisation: A closer definition • General localization focuses on superficial cultural differences. . . like language, currency formats, date and time formats • Radical localization focuses on cultural differences that affect the way users think, feel, and act, (including) learning styles
Micklethwait & Wooldridge: The idea that most of the same products can be sold everywhere in the same way has been thoroughly discredited.
Cultural Context • High-Context Cultures rely less on the message than senders/receivers • Low-Context Cultures rely on detailed, unambiguous messages
Continuum of Context (Hall) High Context Low Context Chinese Japanese Arab Greek Spanish Italian English French American Scandinavian German-Swiss
Cultural Mapping Hofstede’s Value Dimensions • • Individualism-Collectivism Uncertainty Avoidance Power Distance Masculinity/Femininity
Hofstede: Individualism-Collectivism Importance of people’s personal goals versus the goals of the group • Individualistic Countries: U. S. , Australia, U. K. • Collective Countries: Japan, Pakistan, Taiwan
Hofstede: Uncertainty Avoidance Importance of predictability and order (avoidance) versus willingness to take risks and work without rules • High-Avoidance Countries: Portugal, Greece, Japan • Low-Avoidance Countries: Sweden, U. S. , Finland
Hofstede: Power Distance Belief in hierarchy and authority versus the belief that power should be distributed • High Distance Countries: India, Brazil, Greece • Low Distance Countries: Austria, Finland, Israel
Hofstede: Masculinity/Femininity Assertiveness, ambition, and achievement (masculine) versus nurturing and caring (feminine) • Masculine Countries: Austria, Venezuela, Japan • Feminine Countries: Scandinavia, Netherlands
Localisation Process • Schedule (cradle to grave)
The Master Schedule
Overview • How to ship quality software on time – Setting the vision – Scheduling – Resource management – Tracking – Corrective actions
Successful Scheduling Includes. . . • Setting the schedule. • Calibrating the schedule. • Agree on the tracking criteria. • Understanding dependencies. • Reaching milestones. • Creating backup plans. • Changing the schedule.
Dates and Milestones • Goals and Vision required for dates to have meaning • Identifying and setting key dates • What makes a good Milestone • Identifying Dependencies • Planning for the Unplanned • Agent for Change • PM’s role?
Keep it General - Get Buy-In. • Capture the major milestones: – Planning Research Complete – Goals and Vision Closure – Spec Drafts and Completion – Spec Inspections – Dev Schedule Complete – Dev Milestones (M 1, ZBR, Betas) – Code Complete – RTM • Choosing dates: art vs. science. • Give every milestone a purpose. Know how to measure if you met it.
The Development Schedule • Another set of CRITICAL milestones. • Aggressive but realistic. • Reflects key Dev milestones Don’t forget: vacation, meetings, sick time, integration, overhead, dependencies • Buffer – know how to use it. • The Dev schedule is the critical tool to ensure the right product is shipped at the right time.
Identify Key Dependencies • Who are they? – Dev Team – Component owners – Hosts Products – Project teams - test, UA, build • PM’s Role • To identify them • Establish key relationships
Project Management (Chaos is the natural state) • Planning • Preparation • Scheduling • Communication – status meetings, aliases etc.
(A project in Crisis) • RTM looms • Postponement Freefall • How to stop • “Just don’t do it” • PM’s Role? Remember this is normal!!
Must Haves for Success • Communication • Requirements sent to Development • Flexibility – From vendors – From component owners – From internal teams
Ongoing measures • Setting requirements with Dev team • Measure costs of change and present to management • Deliver spec’s on requirements for localisation • Costs Savings and Shorter Delta’s!
Hit and Track Milestones - RTM Rehearsal • Focus team on next milestone. • Know the criteria to measure if you made it – weekly bug goals, dependencies etc. • Milestone not complete until criteria met. • Don’t start the next milestone until finished with the previous one – accumulated slip. • Cause team to make trade-offs – consensus and buy-in.
Dependencies cont. • How to prevent problems? – Document shared goals and vision – Understand other’s commitments and schedules – Have clear contacts and owners – Don’t assume “can do” is the same as “it’s done” – Follow through to closure – sooner is not always better
Achieving Milestones • Why have Milestones? – Motivation – Evaluate progress and take corrective action – Rehearsal for the RTM • What is PMs role? – Leader responsible for delivering on dates – Hub for project group
Successful Milestones • A milestone is more then a date • Give clear measurable targets to aim for • Clear Milestone priorities and criteria • How do you know when it has been achieved? • Getting Closure • Moving on
Refining Schedule/Product • Cut early - Stay focused on product goals. Is the feature still usable after the cuts. • Low pri Þlate task Þcut candidate. • Ensure dev estimates become more “sure” for future tasks: prevention vs. reaction. • Track Feature Changes Closely
Changing the Schedule • Critical Role of PM: Push Back. • Consider ALL other alternatives: Cut features, simplify designs, more resources, work harder/more. • Know the costs – marketing, testing, support etc. • Communicate with management and with dependent components.
Critical Milestone: Code Complete • All features implemented to a measurable and agreed level of quality -- scenarios to test against. • Primary benefit: full stabilization begins. • Focus turns from Development to Testing. • Warning signs: “We’ll complete feature X after code complete. ” Understand the risk.
Localisation for the WEB • Essential Differences • Quality, turnaround • Infrastructure
WEB Products Vs. Packaged Products • WEB products are WEB services! – Requires maintenance for a better service • Short life cycle - many releases. • Different “perspective” to measure quality. • Different drive and focus on: globalization – localization – process.
Short Lifecycle Vs. Workload Major releases: usually 3 -4 x per year Minor revamps: every 2 -4 weeks Workload Disaster cases: not scheduled security fixes very short turnaround time (24 hours) Time
Different Point of View on Quality 30% 100% Functionality Localization Language Functionality 70% Localization Language Packaged Products Online Services Bugs are too costly e. g. re-releases, recalls, etc. More focus on the Content as it is the first element a user will see/experience. The first impression is the one that counts!!
A Recipe for a Successful WEB Product • “True” Globalized code • Excellent localizability • Process for quick turnaround • Process for a vendor outsource model
Globalization • Web services run on machines with different: OS – locale – browser - time zones – char. set - etc. • Awareness during development …and you need to drive these issues! English becomes just another language!
Globalization You also need to be aware and drive: • Vendorization of the product – Developer awareness of localization tools. – Simple & understandable code. • Focus on markets and their specific issues/needs – Language centric vs. Market centric.
Localization • New challenges and focus – “Vendor proof” localizability. – Fast turnaround Process. – “Smart” Testing process. • Use new technology – Find better ways to do the job.
The Process – the “Old” Model Microsoft Example
The Process – the “New” Model MS Redmond MS Ireland MS Business Partners INTERNET
Virtual team • File transfer • Localization • Testing • Engineering • IQA review • Sub review INTERNET
Contingency Planning • How do you prepare for unplanned change? • What can you do when a host or deliverables dates change? • What’s the right amount of buffer to build into your work? • How can you find out early that change is coming? • A new project arrives on an already stretched team
Beyond CC: Bugs, Bugs. • No change in code without a bug. • Each fix has benefits/costs. Know the trade-off. • Fix/Punt the ‘right’ bugs. • Use stabilization milestones: BETAs, ZBRs, weekly goals. • Understand the active/resolved/regress trends. This is your schedule. • Triage regularly, start early but not too early.
Agent for Change • PM is an Agent for change • Escalate-Escalate • Build a network - IPM’s, Loc teams, Key influencers • Cheaper - an argument with weight • Faster - ‘delight’ the customer • Set loc requirements - first milestone for every project
Things to avoid • Making assumptions • What worked before will work again • That it’s easy so does not need a formal procedure • Relying on good will and co-operation of others • Someone else won’t do it


