Скачать презентацию Localisation Resource Centre Summer School Introduction to Localisation Скачать презентацию Localisation Resource Centre Summer School Introduction to Localisation

82403f9397b8d7e8277cf526686e9673.ppt

  • Количество слайдов: 50

Localisation Resource Centre Summer School Introduction to Localisation John Malone Localisation Resource Centre Summer School Introduction to Localisation John Malone

Agenda • • Definition of Localisation Process and Schedule Localisation for the WEB Issues Agenda • • Definition of Localisation Process and Schedule Localisation for the WEB Issues and Considerations

Localisation. What is it? • Process • Language • Culture Localisation. What is it? • Process • Language • Culture

Localization is the process of creating or adapting a product for use in a 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 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 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 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. . . 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 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 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 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 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 • 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 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 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 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) Localisation Process • Schedule (cradle to grave)

The Master Schedule The Master Schedule

Overview • How to ship quality software on time – Setting the vision – 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. • 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 • 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 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. • 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 – 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 • 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 (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 – 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 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. • 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 – 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 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 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 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 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 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 Localisation for the WEB • Essential Differences • Quality, turnaround • Infrastructure

WEB Products Vs. Packaged Products • WEB products are WEB services! – Requires maintenance 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: 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 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 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 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 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. 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 “Old” Model Microsoft Example

The Process – the “New” Model MS Redmond MS Ireland MS Business Partners INTERNET The Process – the “New” Model MS Redmond MS Ireland MS Business Partners INTERNET

Virtual team • File transfer • Localization • Testing • Engineering • IQA review Virtual team • File transfer • Localization • Testing • Engineering • IQA review • Sub review INTERNET

Contingency Planning • How do you prepare for unplanned change? • What can you 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 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 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 • 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