• Nenhum resultado encontrado

3.1.1 Multi-site product development

Nokia is a global organisation employing 50 000 people world-wide. Products are being developed in 15 countries. NMP, one of Nokia's business units, is focused on developing terminal devices for wireless communication, such as mobile phones, communicators and data cards. The other larger units are Nokia Networks, Nokia Ventures Organisation and Nokia Research Center (Nokia 2000).

Products, sold in 130 countries, are being developed, for example, in Copenhagen, Beijing, Tokyo, Dallas and Helsinki (Helsingin Sanomat 2001). Product development places are called sites. Most development projects are co-efforts between at least two development sites, several projects and numerous subcontractors. Product development at NMP is hence multi-site, multi- project and multi-partner product development. The organisation is a multi-site organisation having global focus towards customers and global mindset in the product development (Steinbock 2001, 136).

Physical distances between development sites vary from few kilometres to several thousands of kilometres. Increased physical distance decreases communication. Hence the challenges of multi-site product development are mostly related to communication:

- different work cultures and ethical values (Steinbock 2001, 210)

- exchange of informal ideas and knowledge, such as coffee room discussions - co-operation in areas that require face-to-face contacts

- extra work

- exchange of physical objects, such as product prototypes.

- mistrust and tension between people

One of the opportunities for usability engineering provided by multi-site organisation is the instant access to local cultures and first hand knowledge of markets and users near to the development sites. Designers representing different countries and cultures are more able to bring in different points of view and cultural factors than if all the designers were representing only one or limited culture area.

3.1.2 Virtual organization

Virtual organisation can be described with the following dimensions (Nohria and Berkeley 1994, 115):

- electronic files replace material files

- increased computer-mediated communication in primary activities

- increased face-to-face communication in maintaining organisational cohesion

- structure consists of organisation of information and technology rather than persons such that the organisation appears 'structureless'.

Based on the definition above, NMP as a company can be identified as a virtual organisation.

Also multi-site product development teams and projects are virtual organisations. The practical challenges of a virtual organisation, very similar to multi-site organisation, are (Fulk and DeSanctis 1995):

- extensive geographic distances - asynchrony across time zones

- diverse national and regional cultures.

Ideas of Mowshowitz (1997) for virtual organisation reflect the characteristics of product development complexity (Tianfield 2001): "The virtual organisation approach makes explicit the need for dedicated management activities that explore and track the abstract requirements needed to realise some objective while simultaneously, but independently, investigating and specifying the concrete means for satisfying the abstract requirements." In my case project and observed projects, it is possible to identify four basic types of requirements that are related to mobile phone development:

- process requirements. For a virtual organisation it is critical to agree collectively how things are done.

- project requirements. For example, when the product must be ready and what resources are given to product development.

- product requirements. Technical attributes for the product.

- user requirements. The tasks the user expects to be able to perform with the product.

Following the definitions of Mowshowitz and Tianfield, a virtual mobile phone development organisation needs dedicated management and coordination activities to handle process, project, product and user requirements.

3.1.3 Continuous and parallel flow of new products

Product development starts from the creation of product concepts. Hundreds of new design concepts are created each year at NMP, but only some of those are developed further to new products (Helsingin Sanomat 2001). With the help of new concepts, NMP is maintaining a continuous flow of new products. Several innovative products and product variants are introduced to customers every year in different market areas.

The challenges of continuous parallel product development and flow are related, for example, to:

- high level management of product portfolio (what products and functions are introduced and when),

- maintaining continuously evolving design heritage,

- introduction of new technologies and functions across products (product consistency), - maintaining customer satisfaction,

- sufficient support functions for customers, retailers and operators.

A product that reaches the marketplace must fulfill the product and user requirements in order to be successful. When new functions and technologies are introduced with the product it is often difficult to know exactly and in early development phase how users will or want to use it. This was clearly seen in the introduction of mobile phone text messaging. At first it was a little used technical function, but it soon gained huge popularity, especially among certain user groups, and even new communication cultures have born along it (Steinbock 2001, xxvi). Similar challenges and uncertainties are seen in the introduction of embedded entertainment functions (radio, music players) and embedded imaging technology (digital camera).

A special opportunity in continuous product development is the change to iterate design from one product to another and to be able to learn from continuous user feedback. This is important for usability engineering and UI design - areas that should always use the concrete field feedback as design information input. Though the product must be usable in the first product release, “lead product”, there is almost always possibility and most often intra-organisational drive to improve it in the next product if the user requirements are not met.

3.1.4 Time-to-market driven product development

Characteristics for consumer products are decreased product lifespans, the birth of new consumer segments and, hence, increasing number of new products and product variations. A core question for mobile phone development is how to decrease product development time while simultaneously addressing the evolving customer needs (Valjus 1994).

NMP has a special process for defining customer needs and customer satisfaction (CS). In this process the company creates a product roadmap for the next 3-5 years. The roadmap defines, among other issues, when specific products are needed and with what functions. Project development projects are started based on the roadmap (Valjus 1994). The roadmap defines the product lifespan (birth and death) for each product. This leads to time-critical product development, time-boxing: a project must deliver the product with required functionality so that it is available when it is needed. Otherwise, there is no business reason to introduce the product.

Madachy (2001) discusses the challenges of time-boxing in software development. A general observation is that projects are more frequently becoming constrained by schedule, and delayed because of changing user requirements, unexpected problems and uncertainty in product design decisions. He recommends the use of iterative software development, instead of the Waterfall method, as faster method to develop software systems. However, the schedule is more important for some projects than others.

Several software development methods have been developed to solve the challenge of time-to- market product development and evolving user needs. Extreme Programming (XP) (Beck 2001) is a method that combines the ideas of co-operative team-work, implementation of small function sets in time, and function releases. Many of the XP development ideas are also seen in Stepwise Feature Introduction (Back 2002). In this method the software is developed as layers:

We consider here an approach to software construction that is based on incrementally extending the system with new features,

one at a time. We refer to this method as stepwise feature introduction. Introducing a new feature may destroy some already existing features, so the method must allow us to check that old features are preserved when adding a new feature to the system.

Also, because the software is being built bottom-up, there is a danger that we get into a blind alley: some new feature cannot be introduced in a proper way because of the way earlier features have been built. Therefore, we need to be able to change the structure of (or refactor) the software when needed (Back 2002).

3.1.5 Concurrent Product Development

An important characteristic and primum mobile of NMP product development is the concurrency that can be seen everywhere in the organisation. The core idea of concurrent product development is to propagate the concurrency throughout the organisation and in different levels of product design (Cleetus 1992b). NMP has understood and efficiently implemented this idea. Entire projects work concurrently in order to launch new products in different market areas according to product roadmaps. For each project, the actual product development, sales and production units work concurrently targeting for the same launch day (Lindén 1999). Inside each project, all R&D is done concurrently aiming strictly for the same project milestones. Even inside design teams, sometimes multi-site teams, the product design details are finished concurrently between different team members.

Lindén, research director at Nokia, theorizes (1999) that in a multi-site virtual organisation in principle it is possible to optimize the efficiency of product development concurrency: the work that is started in Japan in the morning, can be continued in Europe or USA when the day goes on. The negative effect of continuous work transfer would be the increased need for job control and coordination while swapping the tasks between teams. Control and job organisation are unproductive tasks that do not contribute to actual product development (Järvinen 1999).