Skip to main content
Erschienen in:

Open Access 2022 | OriginalPaper | Buchkapitel

5. Qualitative Interviews with Developers

Aktivieren Sie unsere intelligente Suche, um passende Fachinhalte oder Patente zu finden.

search-config
loading …

Abstract

The previous chapters indicate that development approaches using innovative technology or Artificial Intelligence must be reviewed against the background of the increasing demands on interdisciplinary project teams as well as the growing complexity of functions. Interviews with engineers, executive managers and a psychologist from the development department of automobile manufacturers show that a structured guided process increases quality in respect of operational and functional safety. The surveys were conducted using the example of the “Code of Practice for the Design and Evaluation of ADAS” including ISO 26262 requirements. It focused on 1. Success and/or failure of guided development projects; 2. Different perceptions, expectations, ideas and conceptions about the optimal development process; 3. Liability-based product responsibility of the developers and 4. general developer’s attitude to the development process. As one of the insightful results, a practice-oriented guideline with supportive advice “forces” all participants involved in the product development process to sit around a table introducing and discussing their different aspects in a structured way. Through the surveys, the developers were sensitized to the advantages of a guideline-based development process. Often the employees themselves are the best advisors. Each expert contributes to the development of a reliable system through their special field of expertise. The developers concerned are the most aware of the weaknesses and can initiate innovations in companies from the “bottom-up”. A final consulting concept (checklist with 101 questions in Annex B) includes guidelines and requirements and will support the efficient, user-friendly development of new automated vehicle functions.
The previous chapters indicate that development approaches using innovative technology or Artificial Intelligence must be reviewed against the background of the increasing demands on interdisciplinary project teams as well as the growing complexity of automotive functions. As a result, proven management systems and system engineering approaches must be redefined or modified appropriately.
Interviews with engineers, executive managers and a psychologist from the development department of automobile manufacturers show that a structured guided process increases quality in respect of operational and functional safety. The final consulting concept (checklist with 303 questions in Annex B) includes guidelines in addition to the aforementioned requirements. It will support the efficient, user-friendly development of new functions.
In the subsequent empirical part, the previous lessons learned described above are supplemented by feedback from internal consultancy work between car manufacturers. After twenty years of professional experience in consulting and advisory activity on the development of safe, innovative vehicle systems the author conducted structured surveys with responsible developers, top executive managers and group leaders. The interviews were carried out with the aim of examining the need and acceptance of a structured, guided development process using the example of the “Code of Practice for the Design and Evaluation of ADAS”. This internationally coordinated development guideline was created for the safe market introduction and reduction of product liability risks concerning advanced driver assistance systems (see Ch. 4).

5.1 Response from a Guided Development Process

A guided development process has the goal to support all involved developers at each stage with methods and checklists from the concept idea to the release and the market launch. The use of guiding documents, such as the ADAS Code of Practice, ensures that appropriate procedures and specification processes for the development of new systems are applied. As a result, the developer achieves adequate safety. At the same time, by processing checklists for specifying or evaluating, it is ensured that no significant aspects are overlooked during development. Furthermore, compliance with the required due diligence or “Duty of Care” is documented and proved.
Using prepared qualitative interviews, the author received extensive feedback on the conception of a guideline-structured development process from Southern German automotive manufacturers. Ten employees were interviewed from administrative and technical staff up to executive management in the technical development of future assistance systems. Among them were six development engineers, one psychologist within the development and three executive managers.
Four engineers had experience on guideline-supported development through application of the ADAS Code of Practice in the context of development or corresponding preparation. Engineer 6 had superficial knowledge while Engineer 5 was unfamiliar with guided development. The psychologist and the three executive managers were familiar with the content of the ADAS Code of Practice (see Fig. 5.1).
Further background information on the 10 interviewed experts with departmental affiliation and experience with guideline-supported development for specific tasks is provided below (see also Fig. 5.2):
  • Development engineer 1 from the chassis development department: 8 years ago, he himself applied the ADAS Code of Practice for the first “lateral guidance assistant” in series development. Subsequently, he moved to another area of chassis development.
  • Development engineer 2 Research/pre-development: he applied the ADAS Code of Practice in a research project on the “emergency braking” function.
  • Development engineer 3 from pre-development: he has been familiar with the ADAS Code of Practice since its publication in 2006. As part of a pre-development project, he initiated the first steps for an automated function using this guideline and then forwarded the checklist to the next development phase.
  • Development engineer 4 from chassis development: he knows the ADAS Code of Practice very well. He has applied the guidelines for the series development of emergency brake functions to the product line.
  • After completing his doctorate, development engineer 5 is currently working on assistance systems. In future, he will be responsible for the series development of a “traffic jam assistant” in a new vehicle series. He is not familiar with the content of the ADAS Code of Practice.
  • Development engineer 6 has recently become a developer in charge of the future series development of automated driving functions. He has not yet applied the ADAS Code of Practice, but is familiar with it.
  • The Psychologist, like the development engineer 6, has recently been in charge of the future series development of automated driving functions. Prior to this, he had already conducted numerous car clinics with naive subjects as well as driving tests with professional test drivers on behalf of automobile manufacturers at a university. He has also not yet applied the ADAS Code of Practice but is familiar with the guideline, too.
  • Executive Manager 1 from chassis development – driver assistance systems, has previously asked his employees about their experiences with the ADAS Code of Practice.
  • Executive Manager 2: development of overall vehicle concept, process control, homologation, regulations and type testing. He is familiar with the content of the ADAS Code of Practice
  • Executive Manager 3: development of vehicle safety, integral safety and assistance, knows the ADAS Code of Practice. He is also familiar with the content.
The extension to the overview of all interviewees shows that they are mainly active in series development. Two engineers work in research and/or pre-development (Fig. 5.2).
Executive manager 2 is responsible for the final steps of the development process, in particular the topics of homologation, compliance with regulations, type testing and obtaining final approval from the technical department. Engineers 1 to 4 who have used the ADAS Code of Practice in their development tasks have an average professional experience of between five and fifteen years. In contrast, engineers 5 and 6, as well as the psychologist with a lower level of work experience between 6 and 12 months have no personal experience with guideline-based development work. Engineer 5 has not yet been familiar with the contents of ADAS Code of Practice. The three executives with many years of professional experience of between 20 and 35 years are familiar with the contents and the objective of this ADAS guideline.
The survey focused on the following topics:
  • Success and/or failure of guided development projects
  • Different perceptions, expectations, ideas and conceptions about the optimal development process
  • Liability-based product responsibility of the developers
  • General developer’s attitude to the development process
An elaborated interview guide (see Annex C) served as a support for the moderation strategy. In order to ensure a smooth conversation, the chronological order of the topics was flexible. The arrangement of the questions in the interview was adapted to the course of the interview. The duration of each interview was between 35 and 70 minutes.
To obtain an overall picture, the survey was taken by both: developers who were in favor of structured guidance support and by those who rather see obstacles (see Sect. 5.2 to 5.6). All developers who took the survey had already been in contact with the guide or the checklists. Four of the developers had already worked actively with the ADAS Code of Practice. The three executives surveyed were familiar with the guide, but had not yet used it themselves.
For the detailed evaluation, the interviews were recorded with an audio device and subsequently transcribed. The transliterated results could thus be structured and evaluated (Kuckartz U, 2016). By means of grouped statistics, the frequency of most frequently used topics of the interview feedback reports was emphasized according to their nomination. This makes it possible to recognize the essential subject areas and to evaluate them in comparison with the transcript (Mertens D M, 2019; Scheu A M, 2018). To analyze the words and the graphical representation, general-purpose software Microsoft Word and Excel was used, applying the mixed-method approach (Döring M, Bortz J, 2016).
The transcripts of all interviews contain 50,124 words and include 4444 nouns. All the nouns were evaluated in addition to the further analysis of the interview content. Of the total, 2703 nouns are attributable to the 6 developers, 387 to the psychologist and 1354 to the executives (see Fig. 5.3).
Initially, this evaluation considers the frequently used topic areas (nouns) of the employees in development. Three groups with six development engineers, one psychologist within the technical development and three executive managers were formed based on meaningful differences between the participants’ tasks.
During the interviews, the three groups focused on very different topics. This alone illustrates the complexity of a successful collaboration.

5.2 Engineers: Sensible Creativity under Time Pressure

Of course, it is beyond a doubt that developers are constantly focusing on the functionality of their “system” (60 nominations). Further on, the evaluation of all feedback from the development engineers shows “questions” (52 nominations) together with “question” (48 nominations) as the most frequently cited word, which tells us something about the engineer's approach: first he asks questions and then works on solving the technical challenges.
It goes without saying that particularly amongst engineers “development” (42 nominations) and “developers” (29 nominations) appear as part of their daily work content. The factor “time” (32 nominations) is conspicuous and is mentioned much more frequently amongst the engineers who have to develop the new system than it is by the psychologist and the executives. In particular, the introduction of additional “topics” (34 nominations) or “documents” (29 nominations) raises the question of the “sense” (28 nominations) (see Fig. 5.4).
A clear reply from the interviews is that daily development activities are subject to colossal time pressure. A wide range of different work contents demands flexibility. It is only on rare occasions that the developers are able to plan for a long time in advance. The developers are subject to a tight schedule and have to deal with a lot of documentation, instructions and tools. This is why current work orders are prioritized by urgency.

5.3 Psychologist within Development: Priority to Driver’s Needs

The task of the interviewed psychologist within the technical development who works in the area of chassis/driver assistance systems is to continue the development of a controllable driver assistance system that is already in series production. He plans to work with a guideline and checklists in the future.
Within the scope of these interviews, the psychologist’s focus is on the functionality of the “system” (24 nominations). He frequently mentions the noun “clinic” (10 nominations) which may be interpreted as an expression of his commitment to carry out scientific tests. Topics such as “driver” (11 nominations), “development” (9 nominations), and “item” (7 nominations) are also mentioned more frequently than was the case with the surveyed development engineers (Sect. 5.2) and executives (Sect. 5.4). This confirms the expectation that the psychologist mainly considers the drivers from the point of view of their different driving behavior, expectations, abilities and limitations.
Thus, the needs of the drivers have top priority:
„(…) dass man sich insgesamt bei der Entwicklung mehr Gedanken drüber machen muss, was macht der Fahrer, was braucht der Fahrer, und was braucht der Fahrer nicht.“ (… that in development you have to worry about: what is the driver doing, what does the driver need, and what doesn’t the driver need.)
In this process he considers it extremely important to insure the controllability of the driver assistance or automated system through use of a “clinic” to deliver final proof of a safe “development”.
With the help of a process consultant, their aim is the preparation of a car clinic:
„(…) dass man eben sagen kann, wir wollen eine Studie machen, und dann haben wir da Leute, mit denen wir da immer sprechen können und die uns erklären, wie so eine Studie aussehen könnte.“ (… you could say that, we want to carry out a clinic and now we have people available, who we can always talk to, and who can explain to us what format the study should have.)
Moreover the topics “standard” (6 nominations) and “code of practice” (6 nominations) are frequently mentioned in connection with guideline-based development.
At this point the psychologist takes particular care to ensure that sufficient design flexibility remains without restrictions during development of the system. To receive an honest evaluation in respect of observed requirements, he considers that an external consultant is needed – someone from outside the development department who could impartially assess the system. Consequently, he uses the word “department”, with 6 nominations, remarkably often. He points out that the opinion of experts within their own department is not easily changed by external opinions originating from outside the department. In addition, the psychologist considers the business policy scope. Different business units need to cooperate closely to achieve a successful company result (see Fig. 5.5).

5.4 Executives Focus on Responsibility for Duty of Care

Firstly, for the executives surveyed in this study (from the areas of chassis, bodywork and total vehicle management) it shows that their reasoning is based on the “topic/s” (46 nominations) they consider important within their scope of responsibility.
Below are some examples:
„Eine Möglichkeit wäre, dass man das Projekt spezifisch mal durchgeht und überprüft, sind alle „Themen“, die darin sind für dieses Projekt notwendig.“ (… One possibility would be to go through the project specifically and check if all the “topics” it contains are necessary for this project… )
„…Das „Thema“ Sensibilisierung. Am sinnvollsten mit irgendwelchen eklatanten Beispielen. Mir fällt so das Thema Toyota ein …“ (… The sensitizing „topic“. Most meaningfully clarified with some spectacular examples. The Toyota topic springs to mind …)
„… wurden entsprechend auch über das Tool alle wichtigen „Themen“ ausgefüllt – alles sichergestellt? …“ (… were accordingly all important “topics” appropriately filled out using the tool, everything assured? …)
The sample question mentioned is representative of the correspondingly high number of “question/s” (37 nominations) in relation to liability.
Furthermore, the terms “sign-off” (29 nominations) and “standards” (24 nominations) illustrate the main areas of interest. In addition, “responsibility” (13 nominations), “law” (12 nominations) and “State of the Art” (10 nominations) are often used. This indicates that managers in particular seem to worry about the political-judicial situation. Mainly the responsibility – particularly with regard to the “sign off” of the “system/s” (34 nominations) to be developed – is of central interest. The term “State of the Art” is mentioned significantly frequently. This is an indication of their responsibility for a safe system development (see Fig. 5.6).
Executives know about the legally binding nature of system releases and thus recognize the need to further establish the use of guideline-based checklists. However, as already mentioned, they do not regard it as an objective to force through the binding application based on pressure from disciplinarians above – or by establishing a standard. As a long-term goal, the independent and self-responsible processing of checklists is seen as sufficient, without the need for additional regular checks during system development. The acceptance is to be achieved by the credible commitment of the executives and the increased involvement of the developers, through which they change “from stakeholders to parties” (Osmetz, D. et. al. 2004). Findings from studies confirm that the credible commitment of top management, together with the involvement of the employees, is decisive for successful changes (Claßen M, Kyaf F 2010).
This way of involving the employees would make it easier for managers to share responsibility for sign-off. They could rely on the fact that relevant checklists had been compulsorily completed and promptly filled out. This also confirms that all relevant requirements had been considered during development.
Comparing the word-nominations of the executives with the development engineers, it can be seen that “topic/s” (15 nominations per executive vs. 6 nominations per development engineer) are more clearly in the foreground. By contrast “question/s” are more often raised by the development engineers (17 nominations).
Therefore, it can be concluded that executives are more accustomed to thinking about “topic/s” or “solutions” rather than open questions (see Fig. 5.7).

5.5 Advantages of Guideline-Based Development

Among all the interviewees, there is a general open-minded constructive attitude towards guideline-based support as an orientation aid with suggestions for the approach to the development of new innovative vehicle systems. In particular, less experienced engineers or developers from different disciplines can benefit from included reminders and the documentary support. Competent support with an internationally accepted document is preferred to a transfer of personal experiences among colleagues. Support with assistance of accompanying documents – such as Codes of Practice, which are binding not only inside the organization but also for all international automobile manufacturers and suppliers – is greatly appreciated. In the opinion of the interviewees, such a binding character leads to a higher level of care and increased motivation to adapt the new system to valid standards or to meet the requirements for system approval requirements.
None of the developers have continuously used the Code of Practice guideline during the development stages through their own initiative. A reason for the non-application was partly the opinion that a guideline is not necessary because of already existing adequate intra-departmental experience or that the fulfillment of relevant standards, approval regulations or sign-off tests from other departments suffices. Corresponding checklists were only processed if active support was provided. The respondents considered working together with a consultant to be easier and more effective. In the short term, it was possible to eliminate any uncertainties that arose. A further important advantage was seen by the interviewees as being the dual control (four-eyes) principle at the end of the development process, which acts as a check to see that all main issues were considered.
Overall, it can be seen that guideline-based development work as illustrated by the example of the Code of Practice has so far encountered a number of obstacles. The major barriers are currently the lack of awareness and oversized scope. Only a few developers are aware of colleagues or departments that use the Code of Practice. Moreover, as only a few are informed about the importance on the need for guideline-based development work by their own initiative, it is necessary to initiate the process by a responsible person. A more user-friendly form, together with intensive consultation work, promises a significant increase in practical application. For the integration of a binding application into the daily development routine, close cooperation between the responsible executives and developers is required. The greater their personal responsibilities within the development of new systems, the more the surveyed person considered the guideline to be useful. Regular application will therefore depend on the guide being perceived as an advantage which will then provide motivation for its use.

5.6 Conclusion: Structured Expert Communication Improves Quality

In individual interviews, a guideline-based development structure in the research and development centers of German automobile manufacturers was examined. The investigation was inspired by the practical application of the approach based on the guideline-supported example of the ADAS Code of Practice.
This identified a lot of information about the development staff´s perspective in relation to the sustainable development of safe vehicle systems and also their acceptance of structured, guideline-oriented development work.
For evaluation of the feedback, the interviewed development staff was grouped into six engineers, one psychologist and three executives. Amongst other things, the evaluation revealed that engineers are looking for meaningful creativity when developing a new system under time pressure. On the other hand, the feedback from the psychologist within the development department confirms his prioritizing of the needs of drivers and the proof of the controllability of the new system. Executives, on the other hand, focus more strongly on the responsibility for sign-off, thus completing the requirements for safe and fully documented development work.
Overall, it is apparent that development engineers, psychologists and managers are looking at the development of a new system with different perspectives, interests and attitudes – while in general, all of them welcomed the tool. Each expert contributes to the development of a reliable system through their special field of expertise. As explained in previous chapters, these views are important – since, for example, technical system limits or operating errors for end users could potentially lead to dangerous situations and accidents, which could lead to a harmful loss of image for manufacturers.
A guideline with supportive advice “forces” all participants involved in the product development process to sit around a table introducing and discussing their different aspects in a structured way.
Through the surveys, the developers were sensitized to the advantages of a guideline-based sustainable team development process. Often the employees themselves are the best advisors. The developers concerned are the most aware of the weaknesses and can initiate innovations in companies from the “bottom-up”.
As a team developer, the author repeatedly observes disruptions in the self-organization of a team that result in a lack of communication or conflicts between individual employees. Within the team development measures carried out for this purpose, the author conveys the values of the Inner Development Goals (IDG), considering the Corporate Social Responsibility and sustainability principles of the United Nations Sustainable Development Goals (SDG) for sustainable development on our planet (see Annex B questions 103 to 303, see also Fig. A.19).
Open Access This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://​creativecommons.​org/​licenses/​by/​4.​0/​), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.
The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.
Metadaten
Titel
Qualitative Interviews with Developers
verfasst von
Thomas Winkle
Copyright-Jahr
2022
DOI
https://doi.org/10.1007/978-3-658-34293-7_5

    Premium Partner