Exploring the Perspectives of Managers on Data Presentation in Software Analytics Tools

Exploring the perspectives of managers on data presentation in software analytics tools

Bachelor’s Thesis, 15 Credits

Patrik Skuza

Bachelor's degree, 180 Credits Field of Study: Computer Science Program: Computer Systems Developer Spring 2021 Final Seminar: 2021-06-01 Supervisor: Jesper Larsson Examiner: Hamza Ouhaichi

Abstract There is a lack in research on the perspectives of different managerial roles on data about software projects in software analytics tools, such as the perspectives of chief financial officers (CFOs), chief executive officers (CEOs) and compliance officers. Today, software analytics tools are mainly developed to address the needs of technical stakeholders such as developers, but research shows that there exist potentials of expanding this technical users’ scope of focus to also include higher level stakeholders, such as managers. The goal of this study is to explore what managers working in software development organizations consider to be useful data to have about software projects in software analytics tools, as well as examining how they want data about software projects to be presented to them in such tools. This study was done in four steps. First, a literature review was conducted. Second, a questionnaire was conducted with four CFOs, one CEO and one compliance officer working in six different Swedish software development organizations. Third, semi- structured interviews were conducted with three CFOs, one CEO and one compliance officer working in five different Swedish software development organizations. Fourth, a visual prototype simulating a software analytics tool was constructed based on the data gathered from the interviews. The result of this study shows that abstraction, limitation, and visualization of data about software projects, as well as presentation of useful data in software analytics tools that support the work tasks of managers, is helpful in addressing the perspectives and views of the target group.

Keywords: Software analytics, tools, stakeholders, managers, useful data, software projects, data presentation

Table of contents

1. Introduction ...... 1 2. Purpose ...... 2 3. Research Questions ...... 2 4. Delimitations ...... 3 5. Literature Review ...... 3 5.1. The potential of Software Analytics for managerial roles ...... 4 5.2. The needs of Software Analytics for managerial roles ...... 5 5.3. Software Analytics tools ...... 7 5.3.1. CodeScene ...... 7 5.3.2. SonarQube ...... 9 6. Method...... 11 6.1. Method theory ...... 11 6.2. Method description ...... 12 6.2.1. Literature review ...... 12 6.2.2. Questionnaire ...... 12 6.2.3. Interviews ...... 13 6.2.4. Prototype ...... 13 6.2.5. Exploratory data analysis ...... 14 6.2.6. Theme analysis ...... 14 6.3. Method discussion ...... 15 6.4. Design of data generation methods ...... 17 6.4.1. Design of questionnaire ...... 17 6.4.2. Design of semi-structured interviews ...... 19 7. Results ...... 20 7.1. Questionnaire ...... 20 7.1.1. Background information about the respondents ...... 20 7.1.2. The respondents’ understanding of CodeScene ...... 21 7.1.3. User-friendliness of CodeScene ...... 21 7.1.4. Prioritization of problems ...... 24 7.1.5. Types of useful information ...... 25 7.1.6. Customization in CodeScene ...... 29 7.1.7. Functionalities in software analytics tools ...... 30 7.2. Semi-structured interviews ...... 32 7.2.1. Background information about the interviewees ...... 32 7.2.2. Data about software projects considered to be useful to have access to ...... 33 7.2.3. Needs for abstraction of data about software projects ...... 34 7.2.4. Aspects of design and data presentation ...... 34 7.3. Prototype ...... 36 7.3.1. Projects ...... 37 7.3.2. Views ...... 38 7.3.3. CEO Dashboard ...... 39 7.3.4. CEO Level 2 ...... 40 7.3.5. CFO Dashboard ...... 41 7.3.6. CFO Level 2 ...... 42 7.3.7. Compliance Officer Dashboard ...... 43 7.3.8. Compliance Officer Level 2 ...... 44 8. Analysis ...... 45 8.1. Questionnaire results analysis ...... 45 8.2. Analysis of qualitative data ...... 46 8.2.1. Perspectives on data considered to be useful ...... 46 8.2.2. Perspectives on presenting data about software projects ...... 48 9. Discussion ...... 50 9.1. Limitations and Challenges ...... 53 9.2. Future Work ...... 54 10. Conclusions ...... 55 11. References ...... 56 12. Appendix ...... 59 12.1. Appendix A – CodeScene Off-boarding simulation ...... 59 12.2. Appendix B – CodeScene Dashboard ...... 60 12.3. Appendix C - Interview Dashboard Picture ...... 61 12.4. The design of the questionnaire ...... 62 12.5. Interview Questions ...... 76 12.6. Interview Protocols ...... 77 12.6.1. Protocol 1 ...... 77 12.6.2. Protocol 2 ...... 84 12.6.3. Protocol 3 ...... 91 12.6.4. Protocol 4 ...... 110 12.6.5. Protocol 5 ...... 119

List of Tables

Table 1 - The questionnaire translated into English...... 17

Table 2 – Questionnaire - Section 1 / Question 1: What is your job title? ..... 20

Table 3 - Questionnaire - Section 1 / Question 3: How old are you? ...... 20

Table 4 – Questionnaire - Section 2 / Question 1: I understand what CodeScene is for a tool...... 21

Table 5 - Questionnaire - Section 2 / Question 2: That CodeScene is easy to use is a condition for me to use the tool...... 21

Table 6 - Questionnaire - Section 2 / Question 5: I think that the availability of help texts about information displayed in CodeScene is a condition for me to use the tool...... 22

Table 8 - Questionnaire - Section 4 / Question 2: That it is quick to learn CodeScene is a condition for me to use the tool...... 23

Table 11 - Questionnaire - Section 2 / Question 3: I think a tool that can help me to prioritize cost problems in software contexts can be useful in my work...... 24

Table 12 - Questionnaire - Section 2 / Question 4: I think that a tool that can help me to prioritize problems with work allocation in a software context can be useful in my work...... 25

Table 13 - Questionnaire - Section 3 / Question 1: Access to information about efficiency in development teams is useful in my work...... 25

Table 14 - Questionnaire - Section 3 / Question 2: Access to information that can be helpful in preventing future costs in software contexts is useful in my work...... 26

Table 15 - Questionnaire - Section 3 / Question 3: Access to information on ROI (Return on Investment) for planned work is useful in my work...... 26 Table 16 - Questionnaire - Section 3 / Question 4: Access to information about the distribution between planned and unplanned work in the software development process is useful in my work...... 27

Table 17 - Questionnaire - Section 3 / Question 5: Access to information about work allocation and its impact on software quality is useful in my work...... 27

Table 18 - Questionnaire - Section 3 / Question 6: Access to information about delivery risks in important code components is useful in my work...... 28

Table 19 - Questionnaire - Section 3 / Question 7: Access to information about developers' lack of knowledge in code components is useful in my work...... 28

Table 20 - Questionnaire - Section 2 / Question 6: To be able to quickly customize the type of information that is displayed to me in CodeScene is a condition for me to use the tool...... 29

Table 21 - Questionnaire - Section 4 / Question 4: Having the choice of not having to see information that I do not think is relevant is a condition for me to use CodeScene...... 30

Table 25 - Information on the interviewees ...... 32

List of Figures

Figure 1 - CodeScene. The "Refactoring Targets" functionality...... 8

Figure 2 - SonarQube. The "Quality Gates" functionality [23]...... 10

Figure 3 - SonarQube. The "Cognitive Complexity" functionality. The affected code can be seen to the right supported by explanations. The ranking and severity of different parts of the code can be seen to the left [23]...... 10

Figure 4 - SonarQube. The dashboard-view is partly illustrated [23]...... 10

Figure 5 – Prototype: Projects screen...... 37

Figure 6 – Prototype: Views screen...... 38

Figure 7 – Prototype: CEO Dashboard screen...... 39

Figure 8 – Prototype: CEO Level 2 screen...... 40

Figure 9 – Prototype: CFO Dashboard screen...... 41

Figure 10 – Prototype: CFO Level 2 screen...... 42

Figure 11 – Prototype: Compliance Officer Dashboard screen...... 43

Figure 12 – Prototype: Compliance Officer Level 2 screen...... 44

Figure 13 - Themes identified in discussions on useful data in software analytics tools. The colors of the bars represent the work roles of the interviewees. The numbers represent the number of interviewees that discussed the themes during some point...... 46

Figure 14 - Themes identified in discussions on the wants of data presentation in software analytics tools. The colors of the bars represent the work roles. The numbers represent the number of interviewees that discussed the themes during some point...... 48

Definitions

CFO Chief Financial Officer CEO Chief Executive Officer Managers Refers to CFOs, CEOs and compliance officers if not specifically stated otherwise. ROI A financial term which is an abbreviation of “Return on Investment”, relating to the profit of an investment.

1. Introduction The software development process is an essential part of many organizations. It is a social process, spanning over a wide range of stakeholders with different perspectives, goals and levels of technical competence [1]. The software development process is supported by tools in various degrees, for tasks such as automation and for supporting the activities of different stakeholders [1]. It is also an error-prone process, where wrong decisions, software defects, or lack of awareness of underlying problems in the software development process can result in high costs or software failures.

Software analytics tools can be used for gaining insight [2], monitoring projects, improving risk management [3], support decision-making [2] [4], and thus mitigating failure rates and lessen future costs in software development organizations. As has been noted in prior work, there is a clear connection between analytics and competitive value, but managerial and cultural barriers towards analytics usage remains a problem in many organizations [5].

The cost of various software defects in the US alone costs the economy billions of dollars each year. Likewise, it is not uncommon for large software projects to either be delayed or to fail completely [3]. A continuous and significant problem exists in project managers ability of making good decisions, which might be a possible explanation to the failure rate experienced in various software projects [3]. As noted in another study, an information gap between IT and finance typically exist in large and complex organizations [6]. The study suggests that this gap originates in the lack of technological awareness in both finance teams and project managers, which results in technical debt in software [6]. Technical debt, as originally formulated by Cunnigham, is a collection of problems in software or software quality issues which result in higher costs over time, if they are left unresolved [7].

Finance teams selected with managing IT related investments generally view projects occasionally during various case reviews or budgeting processes and are therefore not actively updated throughout the software development process [6]. Project managers, which typically bridge the communication gap between IT and finance, are often not equipped with sufficient financial knowledge to effectively carry out their roles [6]. This creates a potential situation where inadequate information about the software development process in finance teams and project managers, results in decision making that ultimately leads to the accumulation of technical debt [6].

The monitoring of technical debt is supported by various software analytics tools [8], but the broad adaptation of these tools in organizations is lacking [6]. Most software analytics tools focus on the developers perspective [3] [9], and so does the research on software analytics [2] [9]. Software analytics tools should be able to support different views relevant to different stakeholders, as the needs of information vary between stakeholders [3] [10]. The user experience is also an important aspect of software analytics tools, and a need of research in this field exists on how information can be presented and interacted with, as related to different stakeholders [3] [9].

This work focuses on exploring the perspectives of managers that work in software development organizations, on useful data about software projects and how such data could be appropriately presented to them in software analytics tools. More specifically, this work focuses on capturing and presenting the perspectives of managers across five organizations in Sweden.

2. Purpose The purpose of this work is to explore what data about software projects that managers working in software development organizations consider to be useful to have in software analytics tools. Furthermore, this work is aimed at gaining insight on how managers working in software development organizations want data about software projects to be presented to them in such tools.

The results are to be captured in a visual prototype built in Adobe XD [11], expressing the findings in a simulated software analytics tool environment, with focus on presenting the type of data the managers find relevant, as well as the preferred manner of presenting this data among the managers. The purpose of constructing the prototype is to support the findings with a visual artefact, as well as presenting how the findings could potentially be implemented in a software analytics tool.

By carrying out this work, I hope to contribute with relevant insight on how current software analytics tools could be modified or how future software analytics tools could be built, to capture the perspectives of managers that work in software development organizations. As such, these findings could potentially promote the usage of software analytics tools amongst managers, and thus increase their decision-making capabilities in software development organizations.

3. Research Questions 1. What data about software projects do Managers that work in software development organizations consider to be useful to have in software analytics tools? 2. How do Managers that work in software development organizations want data about software projects to be presented to them in software analytics tools?

4. Delimitations The work in this paper consists of a questionnaire, semi-structured interviews, and a prototype construction. The questionnaire allows for capturing the respondents’ perspectives on both the CodeScene software analytics tool, and software analytics tools in general. The questionnaire is used as means of preparation for the interviews. The semi-structured interviews are used as means of gaining relevant data, used in answering the research questions. The prototype is constructed based on the data from the interviews.

A total of five interviews are performed with the target group of three chief financial officers (CFOs), one compliance officer and one chief executive officer (CEO). The same target group, as well as one additional CFO is used for the questionnaire.

The target group resides in Sweden and are working in different Swedish software development organizations. Most of the target group have not used software analytic tools personally in their work. The target group have some understanding of the CodeScene software analytics tool. As such, CodeScene is sometimes used as a reference point for software analytics tools in the data collecting process, to better capture the perspectives of the mostly unexperienced target group as relating to prior practical experiences with these types of tools.

I have been granted a free license of the CodeScene software over a four-month period to help me explore this research field in an economically feasible manner, as many software analytics tools tend to be expensive. The team at CodeScene have also supported me in finding the target group used in this work.

5. Literature Review In this section we review the following:

• The potentials of Software Analytics for managerial roles. • The needs of Software Analytics for managerial roles. • Software Analytics tools: - CodeScene. - SonarQube.

These topics are presented to explore previous research made in the research field of software analytics as related to managerial roles. CodeScene and SonarQube are also briefly presented as means of understanding what data is offered, and how this data is presented in these software analytics tools.

5.1. The potential of Software Analytics for managerial roles High performing organizations measure their software development process at a significantly higher scale, and in better ways, as compared to worse performing companies [12]. Measuring the software development process can be achieved in different ways, including monitoring the infrastructure in organizations [12]. The work artefacts and metadata produced throughout the software development process can also be statistically measured in significant ways [3] [13]. This can help to support the decision-making of managerial roles, and thus increase the effectiveness of the software development process in organizations [2] [10] [12] [13]. Another way of measuring, is by proactively checking the health of the developed system, which can result in less accumulation of technical debt over time [12] [14]. Information is a key component in organizations, as good quality information promotes better decision-making, and better decision-making leads to greater results. In fact, high performing organizations generally have better and more complete information, as well as higher quality information flow than their competitors, which is relevant as better information flow in organizations results in better functioning [15].

As previously noted, software projects are highly dependent on well-informed managerial decisions, and software analytics tools have the potential to support such decisions. As finance teams are responsible for approving budgets for software projects, their decisions also have a direct impact on the software development process [6]. Depending on how well-informed different decisions are throughout the software development process, software projects can either succeed or fail [4]. As such, stakeholders have a significant impact on software projects, all the way from initialization to the closure of projects [16].

The process of resource allocation in developer teams serves as a prime example of error-prone decision-making found in managerial roles [1]. Managerial roles often do not have sufficient insights as related to individual-based efficacy and knowledge distribution in software components, which oftentimes results in replacing high-skilled, high-cost developers with lower-skilled developers, which negatively impacts the quality of the software [1]. Low quality in developed software can have a significant impact on raising future costs by introducing technical debt [14]. A decision like this could potentially be supported by a finance team as well, as this would lower the cost of development in the short term. As noted in a study, a lack in technical terminology such as technical debt, often exists in finance teams and other managerial roles in large and complex organizations [6]. This study also suggests that increasing the knowledge of technical debt in these roles could potentially promote decision- making [6].

In summary, software analytics tools have the potential to increase the success rates of software projects, by providing important information for managerial roles, as well as facilitating information flow throughout software development organizations.

5.2. The needs of Software Analytics for managerial roles The research field of software analytics is mostly focused on exploring the perspectives of developers, whereas the perspectives of other important stakeholders, such as those responsible for higher-level decision-making in organizations, are largely unexplored [2] [9]. Not only is there a lack in prior research relating to higher-level stakeholders, there seems to be a significant gap in the needs of these stakeholders as well, as relating to what kind of information is important for these stakeholders, and how this information is to be presented to them [2] [3] [17].

This research gap is also reflected in various software analytics tools, which most commonly make use of models based on the needs and wants of developers, as most of the available research focuses on primarily or exclusively exploring the perspectives of developers [3] [9] [18]. The result of this research gap is the lack of a good model which incorporate the views and perspectives of stakeholders other than developers [3]. One argument for the absence of usage of software analytics tools in various stakeholders other than developers is therefore the lack of research in the context of higher-level stakeholders. If their data needs and data presentation needs are not represented in many software analytics tools, then these stakeholders will simply not use these types of tools [3]. Another argument highlights the importance of transparency in decision- supporting models. The lack of transparency in some models can potentially lead to distrust, as not understanding the implications of what the models are presenting might limit the amount of decisions made based on such models [3] [12].

Naturally, a separation of concerns exists between developers and other stakeholders. Developers focus mostly on lower-level concerns having to do with software, such as code, performance and architectural traits [3]. Managerial roles generally focus on higher-level concerns, such as project goals and allocation of resources [3], while managerial roles which focus on finance are mostly concerned with financial-related tasks, including reviewing and defining different goals in various budgeting processes [6]. The fact of the matter is that there may be a huge difference in concerns between managerial roles and developers in organizations. One commonality between various stakeholders is the importance of relevant data and metrics [3] [12]. Another commonality is the importance of being aware of the quality of software at different stages throughout the software development process [19].

As we have seen in section 5.1, good quality information and good quality information flow can have a significant positive impact on the effectiveness and success of organizations. The software delivery performance in software development organizations can be substantially increased in many ways, including visually displaying quality and productivity metrics across stakeholders in software development organizations, and investing in management capabilities that enable the flow and access of relevant information for different stakeholders [12]. Some key attributes of such capabilities include visualization, communication, transparency, and ease of use [12].

Previous work have illustrated the importance of abstraction, visualization and simplicity in the information presented in software analytics tools to higher-level stakeholders [1] [3].

• Abstraction in this context refers to the ability of “drilling-down” from high level summaries, to lower level views such as code components and artefacts [1] [3]. As such, abstraction can serve the purpose of supplying stakeholders with complete context, while maintaining a sufficient level of transparency which enhances both the understanding of a problem domain and facilitates action [1] [3].

• Visualization is used in this context to denote the importance of presenting data in a visual form [1] [9] [10] [12]. Visualization can support the users of software analytics tools by increasing program comprehension [10], supporting both monitoring and communication capabilities [12], and as a way to simplify the grasping of data [9]. Visualization may also serve as an instrument in software analytics for bridging the gap between managerial and developer domains [9].

• Simplicity refers to the application’s ease of use [12] [16], as well as simplifying and contextualizing metrics, as opposed to having complex metrics that can be hard to comprehend and act upon [1] [20]. The more simpler and contextual a metric is, the easier it will be to act on, as less interpretation will be required to understand what data is being represented by a metric [20].

Other important aspects that have been mentioned in previous work that may be important for higher-level stakeholders to have available for them in software analytics tools include views [3] [8] and dashboards [8] [21].

• Views are described as a functionality within software analytics tools which support the concerns of different stakeholders, from the perspective of supplying relevant displays, with relevant data and metrics supporting the interests of different stakeholders [3] [8]. One study suggests that different stakeholders need different views, as the concerns of various stakeholders naturally differ [8].

• Dashboards are described as display containers which contain information, which can provide the views functionality as explained above [8]. One study goes further on this topic, suggesting that visualization is an important aspect in dashboards [21]. This study also suggests that a limited amount of metrics in dashboards can be helpful, and that dashboards can be more helpful if the users are convinced of the importance of the information presented in dashboards [21].

5.3. Software Analytics tools The following section is used to present the CodeScene [22] and SonarQube [23] software analytics tools, with focus on some functionalities that currently exist as well as the visual aspect of how data is presented. CodeScene is presented as it is used in the data generation methods in this study. SonarQube is presented as it is used in many smaller and global software development organizations across the world [23]. These tools are selected as they express aspects of data presentation which are of value for higher-level stakeholders, such as visualization, abstraction, and dashboards, as described in section 5.2. By exploring such aspects in current tools, it is possible to better understand how important data presentation aspects for higher-level stakeholders are currently implemented in such tools. Other popular tools such as Coverity [24] are discarded as they implicitly focus on developer concerns.

5.3.1. CodeScene CodeScene is a software analytics tool created by Empear AB, a Sweden based company with headquarters located in Malmö [25] [22]. CodeScene works on two data sources, the source code and the version control history [26]. These data sources are used for creating and displaying a large collection of metrics in the software. A number of metrics, such as those that present the amount of unplanned work and hotspots based on relevance, can be used to analyze technical debt within software [22]. Some metrics are calculated with the use of machine learning algorithms [26].

CodeScene supports a variety of analytical functionalities. A list of some supported functionalities are as follows:

• Refactoring targets, which displays software components as circles on the screen. The size of the circles represents the size of the code in the components, and the color of the circles represent the severity of complexity within that code (see figure 1).

• Complexity trend, which displays the historical growth of complexity, code and comments in specified components as a diagram.

• X-Ray analysis, which contains the same functionality as Complexity trend, but does it at function level, granting a lower-level view of components based on change frequency, size of code and complexity. This is displayed as a list that can be sorted.

• Hotspots, which display code components based on development activity. The color of the circled components represents the amount of activity within that code.

• Change Coupling, which displays the percentage of dependency between different files in the software. This is displayed both as a list that can be sorted, as well as a visual view of the files with strings between them, representing the amount of coupling.

• Commit Activity Trend, which displays the number of commits and authors per week as a diagram throughout the history of the software.

• Knowledge Risks, which displays critical software components that have a low knowledge distribution between developers. These are displayed as circles, where the color of the circles demonstrates the degree of risk within the components.

• Off-Boarding Simulation, which simulates knowledge loss in software components if specified developers were to leave the organization. The results are displayed as circles, where the color of the circles represent the severity of the knowledge loss that could occur (see Appendix A).

CodeScene offers a dashboard view as well (see Appendix B), where the general code health is displayed on a scale from 1 to 10, where 10 represents the healthiest code. Notifications can also be found within the dashboard, which notifies the user of the most important warnings. CodeScene supports integration with various project management tools as well, such as Jira and Trello, which unlocks more functionality [22].

Figure 1 - CodeScene. The "Refactoring Targets" functionality.

5.3.2. SonarQube SonarQube is a popular software analytics tool created by the Switzerland- based company SonarSource S.A [23]. SonarQube works on the source code, and supports integration with version control systems such as GitHub [23]. SonarQube focuses on two dimensions of code, security, and quality. The solidity of these aspects can be used to gain insights on technical debt [23].

Some functionalities that exist in SonarQube are as follows:

• Quality Gates, which scan commits based on factors such as bugs, vulnerabilities, code smells, coverage, and duplications. These are represented as visually displayed wide-bars which are segmented on the factors and use colors and scale-systems such as percentages to indicate the state of the quality of different metrics (see figure 2).

• Quality Profile, which can be used to configure coding standards and rules for software components that will be checked for in the software. This function has its own page within the software and has the form of a settings-page where configurations can be added or deleted.

• Cognitive Complexity, which analyzes the code for complexity based on structure and the degree of understandability that it expresses. This function is part of the Code Smells factor which can be found in Quality Gates. The severity is ranked as numbers, and the code can be directly viewed in an IDE by using a supported SonarQube-plugin (see figure 3).

• Security Hotspots, which highlights code that should be reviewed based on security concerns. The affected code is illustrated as a snapshot, and the security concern is described in text format below.

• Security Vulnerabilities, which highlights unsecure code that requires immediate attention, and explains why the relevant piece code is a problem. It is illustrated in the same manner as Security Hotspots.

Similar to CodeScene, SonarQube offers a dashboard view (see figure 4) which shows the state of the general code, based on a scale from E to A, where A represents the healthiest code [23].

Figure 2 - SonarQube. The "Quality Gates" functionality [23].

Figure 4 - SonarQube. The dashboard-view is partly illustrated [23].

6. Method The following section presents the methodology process used in this paper. The different parts involved in this process are explained and motivated. This section also contains a discussion where the used methodology process is compared with other relevant ways of conducting research, based on the available resources at hand.

6.1. Method theory A method process for conducting research contains different parts, which are chosen based on the research that is to be performed. The method process should be defined in a suitable manner as relating to the goal of the research [27]. A set of data relating to the research questions needs to be collected or generated first. Analysis is then performed on this data to better understand the data. Data can be divided into two main categories: quantitative data and qualitative data [28].

Quantitative data is data that is based on numbers [28]. Some examples of quantitative data include:

• Number of buttons in an application. • Number of people voting for a political party. • Time in seconds that it takes to execute a program.

Qualitative data is data that is not based on numbers. Qualitative data includes data such as images, sounds and text [28]. Qualitative data can for example be generated by conducting interviews, or by writing down notes based on observations [28]. Some examples of qualitative data include:

• Interview recordings. • Text-based answers in questionnaires. • Business documents.

Creswell defines the three following research approaches: quantitative method, qualitative method, and mixed method [27]. A quantitative method focuses on understanding the relationship between quantitative data and performing statistical analysis on such data. A qualitative method focuses on exploring and understanding a domain using qualitative data and performing qualitative analysis on such data. A mixed method contains elements of both approaches, and involves the collection of both quantitative and qualitative data [27].

A mixed method should be chosen as the research approach if the expectation is that the integration of both quantitative and qualitative data in the research will generate more information about the research topic as a result, as compared to using either one of these alone [27].

6.2. Method description The data used in this paper were acquired through a literature review, a questionnaire, and a set of semi-structured interviews. The quantitative data was analyzed using an exploratory data analysis approach, and the qualitative data was analyzed using a theme analysis approach. A visual prototype simulating a software analytics tool was built based on the gathered data. The chosen research approach in this paper was the mixed method as described by Creswell [27].

6.2.1. Literature review The literature review was conducted with the use of IEEE, ACM Digital Library, Google Scholar, and Libsearch – which is a discovery tool for finding articles, books and more. The students at Malmö University have access to Libsearch.

Search queries such as “software analysis”, “software analytics”, “tool”, “data analysis” and “stakeholder” were used in different combinations and with the help of different Boolean operators to find the references used in this paper. No date filtration was used in the beginning of the search process to gain an understanding and feel for the research field. The date filtration was later changed to only show papers from 2015 and onward. This was done to have the main part of the research phase focus on newer research, as it was observed that the research field was constantly evolving with time. Backtracking from the references list was often used to find relevant papers, as well as noting down important papers that were often referenced to by many researchers. Each relevant paper was read through, and the important parts were digitally highlighted.

The search process was documented in a separate document to make it possible to verify the literature review process, as well as redoing the search queries. Another document was created which mapped all the useful papers with relevant themes and terms. This helped in keeping a clean structure and quickened the lookup process whenever a paper needed to be referenced.

6.2.2. Questionnaire A questionnaire was used in this study to better prepare for the semi-structured interviews. The available research is limited on what managers consider to be useful data to have in software analytics tools, as well as how managers want data about software projects to be presented to them in such tools. It was therefore deemed necessary to conduct a questionnaire as a data-generating method prior to the semi-structured interviews, to better understand the general thoughts and context of the target group of respondents.

A questionnaire is an effective way of collecting data from many people in a standardized way, and is a well suited data generation method for obtaining brief information from people [28]. A questionnaire can provide a researcher with both quantitative data, for example by using Likert-scale type questions, but it can also be used to collect qualitative data, by allowing the respondents

12 to answer questions in a text format [28]. A questionnaire can be used as a way of identifying patterns in answers and to statistically analyze answers [28]. Questionnaires are also very low in cost, both in time and money [28] [29], which was one of the reasons for choosing to conduct a questionnaire. More specifically, an online questionnaire was conducted due to time and costs savings.

The problem with a questionnaire is that it can be made biased if the questions are suggestive, and the quality of the answers can be hard to assess as the researcher cannot easily identify misunderstandings [28]. It is also impossible to verify the honesty of answers [29].

6.2.3. Interviews A set of five semi-structured interviews were conducted with three CFOs, one compliance officer, and one CEO. Each interview was recorded after permission was granted from the interviewees, and each interview was manually transcribed to allow for a theme analysis.

Interviews are used as a data-generating method for qualitative data, and allow for the obtainment of detailed information about emotions, experiences or feelings from interviewees [28]. This is one of the reasons why interviews were chosen, as an exploration of the interviewees thought processes was considered helpful to better understand why different answers were given by the interviewees. Interviews are also a well suited data generation method as a way of following-up about prior questionnaire responses [28]. By conducting interviews, it was therefore possible to further explore the answers from the questionnaire, which helped in understanding various answers in a more detailed way. Semi-structured interviews were specifically chosen as they allow for both follow-up questions and a predetermined structure of the interview [28]. This is important as follow-up questions can provide further clarifications into unclear answers, as well as an opportunity for further insights into unexpected topics that may be relevant in answering the research questions. A predetermined structure helps in maintaining relevant discussions as related to the research questions, and also aids in comparing the answers of the interviewees as a same set of topics and questions are explored with all interviewees.

6.2.4. Prototype A visual prototype simulating a software analytics tool was constructed based on the data collected from the semi-structured interviews. The prototype was constructed to support the findings in a visual format. More specifically, the prototype was used to illustrate how data about software projects might potentially be visually implemented in a software analytics tool, based on what the group of interviewees viewed as important or relevant to their work roles. The prototype served the purpose of providing the research field with a potential simulation of a realistic looking software analytics tool, based on how three CFOs, one CEO, and one compliance officer wanted to view and use a software

13 analytics tool in a relevant manner as to support their work roles with decision making capabilities.

The prototype was constructed in Adobe XD, which is a professional tool used in many sectors of businesses to construct UI and UX based prototypes to illustrate the design of applications [11].

6.2.5. Exploratory data analysis Exploratory data analysis (EDA) is an analysis method that revolves around the idea to explore and review collected data with an open mind [30]. This way of analysis minimizes biases that a researcher may have, but rests on the responsibility of the researcher to not let any prepossessed ideas to distort findings as related to the studied data [30]. EDA allows a researcher to go through data in a similar way to how a detective works, by objectively viewing the data and puzzling the pieces together. This allows for finding structures or patterns in the data that might lead to hypotheses [30].

EDA was chosen as the analysis method for quantitative data, as it helps with analyzing data in a neutral way and provides a researcher with an objective framework or attitude. The core principles in EDA are skepticism and openness, and the objective of using EDA is to look for patterns in the data to gain insights about the studied research field and to summarize the findings [30].

6.2.6. Theme analysis Theme analysis rests on the idea of going through data and extracting the occurring patterns that are relevant to the research field that is being studied [28]. It is not a straight-forward task as patterns can be omitted if the researcher is not skilled or fully engaged in the analysis activity [28]. Theme analysis is often used to explore and better understand qualitative data, as images, audio and transcribed texts are well suited for a theme analysis approach [28]. As the semi-structured interviews generated qualitative data, a theme analysis approach was used to better understand the generated data. This was done by first transcribing the recorded interviews to text-format. A theme analysis was then conducted on the transcriptions to identify themes that relate to the research questions.

The problem with a theme analysis approach is that a researcher may skew the findings, either unconsciously or consciously, as theme analysis is highly dependent on the researcher skills of finding patterns and being open minded [28]. Prior research can influence the way a researcher analyzes and categorizes the data, as this might lead to the researcher omitting patterns or important findings if they do not relate to what the researcher has previously encountered in studies or research materials [28].

6.3. Method discussion A mixed method approach was selected for conducting research on the perspectives of managers on useful data about software projects, as well as how they wanted data about software projects to be presented to them in software analytics tools, as the data gathered in this study was both quantitative and qualitative. As the research field is scarce on the views on software analytics tools of managerial roles, it was highly relevant to collect the views and background information from the interviewees prior to the semi-structured interviews using a questionnaire. This allowed for better preparation for the interviews, which might have had a positive impact on the quality of the data generated from the interviews.

The literature review was conducted to understand the state of the current research, as well as what research gaps exist. By performing a literature review, it was possible to understand what general perspectives and needs exist in higher-level stakeholders such as managers, as relating to the research field of software analytics. The literature review supported the construction of the questionnaire, as some aspects such as simplicity, visualization and abstraction (see section 5.2) could be better understood prior to the construction of the questionnaire. The literature review therefore supported the phrasing of better and more relevant questions in the questionnaire.

Many factors, such as the words used in questions, the order of the questions, the structure of the questionnaire, as well as the size of the overall questionnaire have an impact on the response rate and the quality of the collected data [28]. As the respondents did not have a technical background, it was necessary to use simple, yet precise words when constructing the questions. As the research questions partly focus on presenting data about software projects in software analytics tools, there is a visual aspect to the research topic that is relevant to explore. To simplify the process of answering questions having to do with the visual aspect of data presentation, three images were constructed which showed the relevant functionalities or visual aspects that were being asked about (see Appendix C). The questionnaire generated data from all six respondents that were asked to fill in the questionnaire.

By analyzing the responses to the questionnaire, it was possible to better prepare for the interviews. One such finding was that a clear majority did not have adequate experience with software analytic tools prior to the questionnaire, which lead to the construction of a six-minute video where I walked through some key functionalities in CodeScene while explaining the visual aspects of the software, as well as the navigation and what potentials exist with such tools.

The interviews allowed for gathering a large amount of qualitative data, totaling up to around 50 A4 pages of transcribed conversations. The questions were carefully constructed to not contain any complicated technical terms and were asked in an order which made the most sense depending on where the conversations were leading to. This was one of the positive advantages of choosing semi-structured interviews as a data-generating method. An advantage of choosing semi-structured interviews rather than structured interviews, was that it was possible to further explore the topic if clarifications were needed, or if the topic of the conversation was important for answering the

15 research questions. In such cases, it was possible to generate more data as compared to a structured interview. Unstructured interviews would have neutralized my control over the interviews due to a lack of a specific, predetermined structure. In this case, the interviewees did not have enough knowledge about the research topic, and they generally lacked in technical terminology having to do with the research topic. Unstructured interviews were therefore determined to be unsuitable as a data-generating method choice for this study, as a specific, predetermined structure was deemed important to ensure that the conversations would cover important topics that related to the research questions. It was therefore deemed better to choose semi-structured interviews as they offered more control and ability to steer the direction of the conversation so that it generated more relevant data.

The choice of creating a visual prototype was made to hopefully contribute to some degree to the research field with an artefact that tries to present how a possible software analytics tool might look like and what data about software projects it could present, based on the data gathered from the interviewees. The validity of the prototype was not checked against the interviewees after the design-phase due to time and availability constraints. This is important to note as the validity of UI and UX designs are highly dependent on iteration-cycles of feedback to assess the quality and the correctness of the produced design [31]. As such, the prototype cannot adequately represent the exact views of the interviewees. It is nevertheless assumed to be of some value, as prototypes that try to capture the perspectives of managers on data about software projects in software analytics tools, currently do not exist in the research field of software analytics. The prototype should therefore be viewed as a visually aiding tool that might give some clues on how future software analytics tools that are meant to be used by managers could potentially look like, or as an artefact that could be further explored in future studies.

A better research method for creating validity for the prototype would be one which consists of iterations where feedback on the prototype is gained on each iteration. One such research method is design and creation, as described by Oates [28]. The plan was to have at least one iteration of feedback to further validify the prototype, but as mentioned, availability and time constraints eliminated this possibility.

By only interviewing five people, it was hard to make any generalization claims based on the collected data [28]. A survey was therefore considered when choosing the research process, as it generally contains a large amount of people and has more validity when making generalization claims [28]. The difficulty of finding enough respondents to include in this study eliminated the possibility of conducting a survey. Another potential problem with generalization was the selected group of interviewees. CodeScene supported me in finding managers for the questionnaires and interviews, which could have potentially skewed the data as compared to using a larger sample of randomly selected people from different localities around the world.

6.4. Design of data generation methods This section explains the design of the questionnaire and the semi-structured interviews.

6.4.1. Design of questionnaire The questionnaire was constructed using Google Forms and was sent to each respondent by email. The questionnaire was designed to begin with an introduction to CodeScene, as well as describing the purpose of the questionnaire and the goal of this research.

The full questionnaire as viewed by the respondents with all example images can be viewed in the Appendix section of this paper (see The design of the questionnaire). The entire questionnaire was translated into English in table 1.

The questionnaire was divided in five sections. Sections one to four were mandatory. The first and the last section accepted answers in text format, whereas sections two to four contained Likert-scale questions based on a scale from 1 – 5. Number 1 on the Likert-scale indicated “Do not agree at all”, and number 5 on the Likert-scale indicated “Completely agree”.

Table 1 - The questionnaire translated into English. Background Information What is your job title? What is your current workplace (company/organization)? How old are you? CodeScene in general I understand what CodeScene is for a tool. That CodeScene is easy to use is a condition for me to use the tool. I think a tool that can help me to prioritize cost problems in software contexts can be useful in my work. I think that a tool that can help me to prioritize problems with work allocation in a software context can be useful in my work. I think that the availability of help texts about information displayed in CodeScene is a condition for me to use the tool. To be able to quickly customize the type of information that is displayed to me in CodeScene is a condition for me to use the tool. Type of useful information in CodeScene Access to information about efficiency in development teams is useful in my work. Access to information that can be helpful in preventing future costs in software contexts is useful in my work. Access to information on ROI (Return on Investment) for planned work is useful in my work. Access to information about the distribution between planned and unplanned work in the software development process is useful in my work. Access to information about work allocation and its impact on software quality is useful in my work.

Access to information about delivery risks in important code components is useful in my work. Access to information about developers' lack of knowledge in code components is useful in my work. Information presentation Having access to a collection of relevant information for my work role from the beginning of using the tool is a condition for me to use CodeScene. That it is quick to learn CodeScene is a condition for me to use the tool. Having easy access to a documentation that teaches me the most important functions in a quick and easy way is a condition for me to use CodeScene. Having the choice of not having to see information that I do not think is relevant is a condition for me to use CodeScene. I think the availability of different depth levels (very general - more specific - very specific) in the information presented in CodeScene is a condition for me to use the tool. The example image below demonstrates a "drag-and-drop" function that allows for repositioning of various information elements on the screen. Such a feature is important for me to have in a tool like CodeScene. The example image below demonstrates predetermined templates that contain a collection of relevant information for different work roles. This is an example of a function that simplifies the use of the tool, by offering appropriate views from the beginning with relevant information for different work roles. Such a feature is important for me to have in a tool like CodeScene. The example image below demonstrates a view function on the left that makes it possible to create and rename different pages for a user. This gives the user opportunities to create and fill their own pages with information that is relevant to their work role. Such a feature is important for me to have in a tool like CodeScene. Optional part What type of information do you think is most important to include in a tool like CodeScene? In what form do you wish to see information in a tool like CodeScene?

The questions were designed to gain a general context about the respondents’ views on data about software projects in CodeScene, and in software analytics tools in general. This was done to better prepare for the semi-structured interviews. To decrease the risk of misunderstandings and biases, a comment field was provided as an optional field to every question from section two to four, which were the sections that contained all Likert-scale questions.

6.4.2. Design of semi-structured interviews The interview questions were designed based on the answers from the questionnaire, on the findings from the literature review, and on the research questions. A six-minute walkthrough video was prepared both in Swedish and English where I showed some key functionalities in CodeScene, and presented navigation and visual aspects of presenting data about software projects in the tool. The interviews were conducted online over Zoom due to COVID-19, as well as time and costs savings.

The transcriptions can be viewed in the Appendix section of this paper (see Interview Protocols). The interview questions can also be viewed in the Appendix section of this paper (see Interview Questions).

Each interview began with explaining the purpose of the interviews, as well as gaining the permission to record the interview from the interviewees. The interviewees were then informed about their freedom to not have webcams activated, as well as having the freedom to not answer questions. The anonymity of the interviewees was guaranteed. Each interview was manually transcribed into text format to allow for theme analysis.

The questions were designed to gain data on the following topics:

• Background about the interviewee. • Views on the relevancy of the presented functionality. • Views on the design of CodeScene. • Views on the navigation in CodeScene. • Views on improvement opportunities in CodeScene. • Views on what the interviewee wants to see in a software analytics tool. • Views on how the interviewee wants data about software projects to be presented in a software analytics tool. • Views on “the perfect software analytics tool”. • Views on “must-haves” in software analytics tools. • Views on what it takes for the interviewee to use software analytics tools. • Views on how data in software analytics tools can be acted upon. • Views on usability as relating to software analytics tools. • Views on customization options in software analytics tools. • Views on important visual characteristics of software analytics tools. • Views on how a software analytics tools should handle the interests of different work roles. • Views on three different dashboards. • Views on the CodeScene dashboard.

The last two questions were supported visually. The first of these questions was supported with a view of three different dashboards in other tools (see Appendix C), and the last question was supported by sharing the screen with the CodeScene dashboard.

The interview questions were designed to use simple and precise language and to gain insight on data that is relevant to the research questions.

7. Results This section presents the results from the questionnaire, interviews, and the constructed prototype.

7.1. Questionnaire A total of 6 out of 6 people who were asked to participate did participate in the questionnaire. The respondents consisted of four CFOs, one senior compliance officer and one CEO. The age of the respondents varied between 39 and 49 years of age, and all respondents were working in software development organizations at the time of conducting the questionnaire.

The questionnaire was made available for the six respondents only, as to hinder the possibility of other users accessing and answering the questionnaire. Sections 1 and 5 had text-based answers, while sections 2 to 4 were Likert-scale based questions. All answers are presented as tables except for the answers on the workplace of the respondents (section 1 / question 2), which are left out to preserve the anonymity of the respondents.

7.1.1. Background information about the respondents

7.1.1.1. The job title of the respondents Table 2 – Questionnaire - Section 1 / Question 1: What is your job title? Answer Number of % of total number of respondents respondents CFO 4 66.7 % Senior Compliance Officer 1 16.7 % CEO 1 16.7 %

7.1.1.2. The age of the respondents Table 3 - Questionnaire - Section 1 / Question 3: How old are you? Answer Number of respondents % of total number of respondents 39 1 16.7 % 45 1 16.7 % 47 3 50.0 % 49 1 16.7 %

7.1.2. The respondents’ understanding of CodeScene In the question regarding to how well the respondents understand the CodeScene tool, the respondents’ answers indicate that their knowledge of the tool varies partially among them (see table 4).

Table 4 – Questionnaire - Section 2 / Question 1: I understand what CodeScene is for a tool. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 2 33.3 % Neutral 1 16.7 % Agree to some degree 2 33.3 % Completely agree 1 16.7 %

Comments: - “I was among the first customers to use the tool”. - ”Have not heard much about this tool”.

7.1.3. User-friendliness of CodeScene This section presents answers on different aspects of user-friendliness of CodeScene, such as the importance of the tool being easy to use, or the importance of having access to relevant, work role-based information from the beginning of using the tool.

7.1.3.1. The importance of CodeScene being easy to use In the question regarding to CodeScene being easy to use, all respondents answered that they either agreed to some degree or agreed fully that this is a condition for the respondents to use CodeScene (see table 5).

Table 5 - Questionnaire - Section 2 / Question 2: That CodeScene is easy to use is a condition for me to use the tool. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 0 00.0 % Neutral 0 00.0 % Agree to some degree 3 50.0 % Completely agree 3 50.0 %

7.1.3.2. Availability of help texts in CodeScene In the question regarding to the availability of help texts in CodeScene, half of the respondents answered that they agreed to some degree that this is a condition for the respondents to use CodeScene. The other half were either neutral or did not agree to some degree with the statement (see table 6).

Table 6 - Questionnaire - Section 2 / Question 5: I think that the availability of help texts about information displayed in CodeScene is a condition for me to use the tool. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 1 16.7 % Neutral 2 33.3 % Agree to some degree 2 33.3 % Completely agree 1 16.7 %

7.1.3.3. Access to relevant information in CodeScene In the question regarding to having access to relevant information per work role from the beginning of using CodeScene, the majority of the respondents answered that they agreed to some degree that this is a condition for the respondents to use CodeScene (see table 7).

Table 7 - Questionnaire - Section 4 / Question 1: Having access to a collection of relevant information for my work role from the beginning of using the tool is a condition for me to use CodeScene. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 0 00.0 % Neutral 1 16.7 % Agree to some degree 5 83.3 % Completely agree 0 00.0 %

7.1.3.4. Quickly learning CodeScene In the question regarding to learning CodeScene quickly, the majority of the respondents answered that they either agreed to some degree or agreed fully that this is a condition for the respondents to use CodeScene (see table 8).

Table 8 - Questionnaire - Section 4 / Question 2: That it is quick to learn CodeScene is a condition for me to use the tool. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 0 00.0 % Neutral 2 33.3 % Agree to some degree 1 16.7 % Completely agree 3 50.0 %

Comments: - “Ease of use is extremely important”.

7.1.3.5. Access to documentation in CodeScene In the question regarding to easily having access to a documentation that can make the learning of the most important functions fast and easy, the majority of the respondents answered that they either agreed to some degree or agreed fully that this is a condition for the respondents to use CodeScene (see table 9).

Table 9 - Questionnaire - Section 4 / Question 3: Having easy access to a documentation that teaches me the most important functions in a quick and easy way is a condition for me to use CodeScene. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 0 00.0 % Neutral 1 16.7 % Agree to some degree 3 50.0 % Completely agree 2 33.3 %

7.1.3.6. Availability of abstraction levels in CodeScene In the question regarding to the availability of abstraction levels in the information presented in CodeScene, half of the respondents answered that they agreed to some degree that this is a condition for the respondents to use CodeScene. The other half were either neutral or did not agree to some degree with the statement (see table 10).

Table 10 - Questionnaire - Section 4 / Question 5: I think the availability of different depth levels (very general - more specific - very specific) in the information presented in CodeScene is a condition for me to use the tool. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 2 33.3 % Neutral 1 16.7 % Agree to some degree 3 50.0 % Completely agree 0 00.0 %

7.1.4. Prioritization of problems

7.1.4.1. Prioritizing cost problems in the context of software In the question regarding to the usefulness of a tool that can help in prioritizing cost problems in the context of software in the respondents’ work, the majority of the respondents answered that they either agreed to some degree or agreed fully that this can be useful, while the minority remained neutral (see table 11).

Table 11 - Questionnaire - Section 2 / Question 3: I think a tool that can help me to prioritize cost problems in software contexts can be useful in my work. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 0 00.0 % Neutral 2 33.3 % Agree to some degree 1 16.7 % Completely agree 3 50.0 %

Comments: - “We do not have much internal development. I base my answer on previous experiences”. - “Still work to be done for us to articulate this”.

7.1.4.2. Prioritizing work allocation problems in the context of software In the question regarding to the usefulness of a tool that can help in prioritizing work allocation problems in the context of software in the respondents’ work, half of the respondents answered that they agreed that this can be useful. The other half were neutral or did not agree to some degree with the statement (see table 12).

Table 12 - Questionnaire - Section 2 / Question 4: I think that a tool that can help me to prioritize problems with work allocation in a software context can be useful in my work. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 1 16.7 % Neutral 2 33.3 % Agree to some degree 0 00.0 % Completely agree 3 50.0 %

Comments: - “See above”. - “Not at CFO level”.

7.1.5. Types of useful information

7.1.5.1. Effectiveness in development teams In the question regarding to the usefulness of information on effectiveness in development teams in the respondents’ work, half of the respondents answered that they were either neutral or disagreed to some degree that this can be useful in their work, while the other half either agreed to some degree or agreed fully with the statement (see table 13).

Table 13 - Questionnaire - Section 3 / Question 1: Access to information about efficiency in development teams is useful in my work. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 1 16.7 % Neutral 2 33.3 % Agree to some degree 1 16.7 % Completely agree 2 33.3 %

7.1.5.2. Preventing future costs in the context of software In the question regarding to the usefulness of information that can be helpful in preventing future costs in the context of software, the majority of the respondents answered that they either agreed to some degree or agreed fully that this can be useful in their work (see table 14).

Table 14 - Questionnaire - Section 3 / Question 2: Access to information that can be helpful in preventing future costs in software contexts is useful in my work. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 0 00.0 % Neutral 1 16.7 % Agree to some degree 2 33.3 % Completely agree 3 50.0 %

7.1.5.3. ROI for planned work In the question regarding to the usefulness of information on return on investment (ROI) for planned work, all of the respondents either agreed to some degree or agreed fully that this can be useful in their work (see table 15).

Table 15 - Questionnaire - Section 3 / Question 3: Access to information on ROI (Return on Investment) for planned work is useful in my work. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 0 00.0 % Neutral 0 00.0 % Agree to some degree 3 50.0 % Completely agree 3 50.0 %

7.1.5.4. Distribution between planned and unplanned work In the question regarding to the usefulness of information on distribution between planned and unplanned work in the software development process in the respondents’ work, the majority of the respondents answered that they were neutral, while the minority agreed to some degree or agreed fully with the statement (see table 16).

Table 16 - Questionnaire - Section 3 / Question 4: Access to information about the distribution between planned and unplanned work in the software development process is useful in my work. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 0 00.0 % Neutral 4 66.7 % Agree to some degree 1 16.7 % Completely agree 1 16.7 %

7.1.5.5. Work allocation and its impact on software quality In the question regarding to the usefulness of information on work allocation and its impact on software quality in the respondents’ work, the majority of the respondents answered that they were neutral or disagreed to some degree with the statement (see table 17).

Table 17 - Questionnaire - Section 3 / Question 5: Access to information about work allocation and its impact on software quality is useful in my work. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 2 33.3 % Neutral 3 50.0 % Agree to some degree 0 00.0 % Completely agree 1 16.7 %

7.1.5.6. Delivery risks in important code components In the question regarding to the usefulness of information on delivery risks in important code components in the respondents’ work, the respondents’ answers indicate that the usefulness of this information varies among them (see table 18).

Table 18 - Questionnaire - Section 3 / Question 6: Access to information about delivery risks in important code components is useful in my work. Answer Number of respondents % of total number of respondents Do not agree at all 1 16.7 % Disagree to some degree 1 16.7 % Neutral 2 33.3 % Agree to some degree 1 16.7 % Completely agree 1 16.7 %

7.1.5.7. Developers’ lack of knowledge in code components In the question regarding to the usefulness of information on developers’ lack of knowledge in code components in the respondents’ work, half of the respondents answered that they agreed to some degree, while the other half were either neutral, did not agree to some degree, or did not agree at all with the statement (see table 19).

Table 19 - Questionnaire - Section 3 / Question 7: Access to information about developers' lack of knowledge in code components is useful in my work. Answer Number of respondents % of total number of respondents Do not agree at all 1 16.7 % Disagree to some degree 1 16.7 % Neutral 1 16.7 % Agree to some degree 3 50.0 % Completely agree 0 00.0 %

7.1.5.8. Relevant information types In the optional text-based question regarding to what type of information the respondents believe to be the most important to include in a tool like CodeScene, they answered the following:

- “A clear link between the cost for the company (customer) and problems in the code”. - “For my role, it would probably be financial information, ROI, Cost and technical debt”. - “Financial or at least quantifiable”. - “A Link to financial goals”. - “I know too little about the system to be able to answer this”.

7.1.5.9. Data presentation and visualization In the optional text-based question regarding to what form the respondents wish to see the information in in a tool like CodeScene, they answered the following:

- “I would have liked to see it as part of my own BI tool, i.e. that you can import information from CodeScene and visualize in existing management reports”. - “Summary. Visual with detail behind available”. - “Dashboard”. - “It should be as intuitively presented as possible”.

7.1.6. Customization in CodeScene

7.1.6.1. Adapting the information presented in CodeScene In the question regarding to the ability to quickly be able to adapt the type of information that is presented in CodeScene as a condition for using CodeScene, half of the respondents answered that they either agreed to some degree or agreed fully, while the other half answered that they were either neutral or did not agree to some degree with the statement (see table 20).

Table 20 - Questionnaire - Section 2 / Question 6: To be able to quickly customize the type of information that is displayed to me in CodeScene is a condition for me to use the tool. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 1 16.7 % Neutral 2 33.3 % Agree to some degree 1 16.7 % Completely agree 2 33.3 %

7.1.6.2. The choice of not having to view some information In the question regarding to the choice of not having to view irrelevant information in CodeScene as a condition for using CodeScene, the majority of the respondents answered that they either disagreed to some degree or were neutral, while the minority answered that they either agreed to some degree or agreed fully with the statement (see table 21).

Table 21 - Questionnaire - Section 4 / Question 4: Having the choice of not having to see information that I do not think is relevant is a condition for me to use CodeScene. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 2 33.3 % Neutral 2 33.3 % Agree to some degree 1 16.7 % Completely agree 1 16.7 %

7.1.7. Functionalities in software analytics tools

7.1.7.1. Drag-and-drop In the question regarding to the importance of having a drag-and-drop function that enables repositioning of various information elements on the screen in a tool like CodeScene, the respondents’ answers are equally balanced between disagreeing to some degree, being neutral, or agreeing to some degree with the statement (see table 22).

Table 22 - Questionnaire - Section 4 / Question 6: The example image below demonstrates a "drag-and-drop" function that allows for repositioning of various information elements on the screen. Such a feature is important for me to have in a tool like CodeScene. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 2 33.3 % Neutral 2 33.3 % Agree to some degree 2 33.3 % Completely agree 0 00.0 %

7.1.7.2. Role-based templates In the question regarding to the importance of having a role-based template function with a predetermined set of relevant information relating to different roles in a tool like CodeScene, the majority of the respondents answered that they either agreed to some degree or agreed fully, while the minority were either neutral or disagreed to some degree with the statement (see table 23).

Table 23 - Section 4 / Question 7: The example image below demonstrates predetermined templates that contain a collection of relevant information for different work roles. This is an example of a function that simplifies the use of the tool, by offering appropriate views from the beginning with relevant information for different work roles. Such a feature is important for me to have in a tool like CodeScene. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 1 16.7 % Neutral 1 16.7 % Agree to some degree 3 50.0 % Completely agree 1 16.7 %

Comments: - “With the ability to adapt Finance to my needs”.

7.1.7.3. Views In the question regarding to the importance of having a view-functionality to create and fill pages with relevant information relating to a user’s work role in a tool like CodeScene, the majority of the respondents answered that they agreed to some degree, while the minority remained neutral (see table 24).

Table 24 - Section 4 / Question 8: The example image below demonstrates a view function on the left that makes it possible to create and rename different pages for a user. This gives the user opportunities to create and fill their own pages with information that is relevant to their work role. Such a feature is important for me to have in a tool like CodeScene. Answer Number of respondents % of total number of respondents Do not agree at all 0 00.0 % Disagree to some degree 0 00.0 % Neutral 2 33.3 % Agree to some degree 4 66.7 % Completely agree 0 00.0 %

Comments: - “Ideal if it proposes for me based on role”.

7.2. Semi-structured interviews A total of 5 out of the 6 questionnaire participants were interviewed. The interviewees consisted of three CFOs, one senior compliance officer and one CEO, who all worked in software development organizations.

The interviews were divided in two parts, the first one consisting of playing the prerecorded walkthrough video of CodeScene, and the second one consisting of conducting the questioning part of the semi-structured interviews. R1 did not need to view the walkthrough video as the person was very familiar with the software prior to the interview.

7.2.1. Background information about the interviewees Table 25 - Information on the interviewees Interviewee Work Role Length of Interview R1 CEO Approx. 25 min R2 Senior Compliance Officer Approx. 45 min R3 CFO Approx. 65 min R4 CFO Approx. 40 min R5 CFO Approx. 50 min

7.2.1.1. Interviewee R1 R1 is a CEO of a company that is listed on the stock exchange and has been an active CodeScene user since it first launched. R1 has also provided feedback on improvements in various phases throughout the evolution of CodeScene. R1’s work consists of trying to make the right choices for the company based on the right data.

7.2.1.2. Interviewee R2 R2 is a senior compliance officer at a company. R2’s work consists of ensuring that the company follows both internal and external rules, such as Swedish rules and EU rules. R2 does this by writing instructions for others, partaking in various projects and by monitoring what the company is doing. The monitoring is mostly trade-based monitoring. R2 has not used CodeScene prior to the interview.

7.2.1.3. Interviewee R3 R3 is a CFO at a tech-company. R3’s work consists of financial advisory, managing profits and losses, and explaining different decisions and what impact those decisions may have on things like liquidity. R3 has previously worked with steering companies that heavily invested in IT capabilities. R3 has not used CodeScene prior to the interview.

7.2.1.4. Interviewee R4 R4 is a CFO that works with managing the economy of a company that does not produce their own software. R4 has previous work experiences with economy departments in larger companies with large development costs. R4 has not used CodeScene prior to the interview.

7.2.1.5. Interviewee R5 R5 started as a CFO at the beginning of 2021, and works with everything having to do with finance, as well as some legal work. R5’s main area of responsibility is finance. R5 also works with bookkeeping, financial analysis and planning. R5 is familiar with CodeScene prior to the interview but has not really been using it.

7.2.2. Data about software projects considered to be useful to have access to All interviewees mentioned what data about software projects would be useful for them to see in a software analytics tool.

R1 talked about wanting to see indicators for critical problems in software, and how these problems impact the budget and the project. R1 also talked about the importance of having a financial presentation of problems and recommendations, and what the financial impact of various paths within the project would have. R1 mentioned that viewing business impact of various problems and solutions would be very helpful.

R2 talked about the importance of making sure that monitoring systems and algorithms that are being used in the company work correctly. R2 also talked about how a person-dependencies view could help in R2’s work, by being able to connect different security controls throughout the company to the corresponding developers and verifiers. Furthermore, R2 mentioned that it would be helpful to indicate what problems exist in control and security type software, and what potential consequences these problems could lead to.

R3 talked about wanting to see a timeline per project, which would indicate at what stage the project currently is in. R3 also mentioned the importance of having a financial perspective in projects, which would show things such as ROI, revenue expectations, cost expectations, and recommendations that would improve the financial and delivery aspect of projects. R3 mentioned a financial based comparison feature which could compare projects against other similar projects as well, which could be useful for comparing against other projects or companies. Furthermore, being able to see the value of individuals in projects would be interesting, and it would be useful to see the business impact of problems, recommendations and of developing extra functionalities according to R3.

R4 talked about wanting to see more money and how it relates to various risks and quality. R4 mentioned how information about technical debt would be

33 interesting, and how hard it is to understand the quality of different IT projects. R4 talked about wanting to see recommendations on where to invest money, as well as what the results would be of acting on different recommendations. R4 also mentioned wanting to see the biggest risks in software, as well as being able to use data from CodeScene in R4’s own tool with the help of an API.

R5 talked about ranking and prioritizing things as a way to make decisions. One example was if an employee would get a better offer at another company, what would be the consequences of losing that developer, and what should be done to mitigate the impact of such a situation. R5 talked about value judgements being useful and being able to see tradeoffs as well as recommendations on allocating resources and risk management. R5 also talked about the importance of simplifying the tool, and that it would be helpful to hide many things for a non-developer user.

7.2.3. Needs for abstraction of data about software projects All interviewees mentioned the need of more abstraction in terms of hiding unnecessary information in software analytics tools, as well as a need for abstraction levels where the user would start with very simplistic and general pieces of information, and could then dive deeper into relevant information elements with more specific data about software projects.

The primary negative remark amongst the interviewees was that the data in CodeScene was too complicated or technical for them in the current state.

R1: “So to be able to double click downwards into more and more depth, instead of getting bombarded with a lot of information as is the case now in CodeScene [...]”

R2: ”So it would be two different levels as I see it... Which one breaks down into.”

R3: ”That is why I try to like, have a higher, abstraction level as you put it, to NOT deal with details... [...]”

R4: ”It gets a little bit too technical for my part.” “[…] Ehm, and then I would like to, of course click on, but to get a, first, very high-level, is, ehm, and then a possibility to go into details… […]”

R5: ”[...] and once again the next level down, it does not show you absolutely everything at that level, it just shows you the – a few things, that, are most relevant, again to that particular line of decision making, or question.”

7.2.4. Aspects of design and data presentation The interviewees all agreed on simplifying the design and underlined the importance of being able to easily see problem areas in projects.

R1 wanted to see a lot simpler version of the tool with a very plain overview per project. R1 talked about a “stupefied” version of CodeScene which R1 would be

34 very happy with, which would clearly indicate information about software projects with red, yellow and green colors, where green means “good” and red means “bad”. R1 also talked about the importance of a very fine and simple design. R1 mentioned that the tool is not intuitively simple and that it is not easy to grasp the financial perspective of projects in CodeScene today. R1 also mentioned being able to click on an overview report. Furthermore, R1 mentioned that the tool could be simplified with templates for different users and that it should be more intuitive and more self-learning.

R2 praised the graphical circular representation of data in CodeScene. R2 wanted to see a personal view over the projects that R2 is interested in. This view should be customizable so that R2 can choose what type of data about software projects R2 wants to see on the screen. R2 would like to be notified when a problem exists and how serious it is, instead of having to digest large chunks of information about each problem. R2 mentioned that illustrations and diagrams could be used in reports. R2 also mentioned that a graph is a good way of representing changes and to understand historical differences.

R3 mentioned that nothing really “stood out” in CodeScene’s design and mentioned that not everything had to be represented as circles. R3 wanted to have more customizability options in a software analytics tool and mentioned a smorgasbord of dashboards that would allow R3 to choose what to see on the screen. R3 also mentioned wanting to see the program from a financial perspective to simplify executive decision-making and wanting data to be based per project.

R4 mentioned that the visualization in CodeScene was positive. R4 wanted to have a very high overview from the beginning, as the standard view in CodeScene was too technical. R4 said that the design in CodeScene was maybe not fitted for different work roles, and that the design maybe tried to put too many things in one view. R4 also talked about wanting to highlight the most important risks and wanting to see more customizability options in the dashboard to be able to view the things R4 is interested in. R4 also mentioned wanting to see data about different software projects, such as how much money was being spent on each project, and how much more money would be needed to reach an acceptable level or a goal. R4 also mentioned being able to click on reports and pin them to the dashboard. R4 wanted to have more clarity on different metrics to understand what they meant and also mentioned wanting to have a standard view for different roles which could be further customized.

R5 talked about the importance of simplifying complex things for the non-techy audience. R5 also underlined that a tool for a non-techy audience should be really simple and praised the idea of hiding unnecessary information from the user based on their user profile or use cases. R5 mentioned that data should be presented for users in an intuitive and simple way, and that R5 would like to see data about the particular projects that R5 was interested in. R5 was not very interested in customization. R5 was instead more interested in the data, what the data was trying to illustrate, and making that data come out in a clear way.

7.3. Prototype The visual prototype was built in Adobe XD [11] with the goal of visually representing the interviewees thoughts and preferences on design, as well as what type of data about software projects they would like to see in either CodeScene or software analytics tools in general. Considering the non-technical backgrounds of most interviewees, it was rather difficult trying to make the right choices in terms of translating the interviewees perspectives into visual constructs in the design-phase of the prototype. Nevertheless, there are some similarities between the interviewees thought processes and ideas, such as ideas of a simplistic design with notations of data abstraction, as well as abstraction levels which allows for gaining more detailed data about various information elements on the screen. This allowed for creating a rather cohesive prototype which hopefully can give at least some insight on what managers would like to see in a software analytics tool.

The construction of the prototype was made in one iteration with no feedback phase on the finished prototype due to availability and time constraints. As such, the finalized prototype is presented in one section only, instead of several sections categorized on iterations and feedback.

The finalized prototype only contains screens which could be supported with adequate input from the conducted interviews. Each work-role dashboard contains a path which leads to a deeper abstraction level of that particular dashboard by clicking on one of the information elements. This was implemented as a way of demonstrating the abstraction levels-aspect of the design, which was discussed by all interviewees, and not to illustrate every single possible functionality with a new screen. This reduces the amount of work needed to construct the prototype, while maintaining a minimized level of bias by only constructing the level 2 abstraction screens that had the most amount of supporting data from the interviews. As such, there exists a limited number of elements which will open a new screen on left-click. This decision was made to minimize the influence of my personal thoughts and potential bias on screens or functions which could not be constructed based on the interviewees input due to the lack of data.

To facilitate the understanding of the different metrics, question-symbols have been implemented in various degrees throughout different screens as means of representing a possible function which would provide more data about the corresponding information elements for the user.

The general design of the prototype is limited in technological terminology and tries to maintain a very high abstraction level of the most important and frequently mentioned data, as discussed and indicated by all the interviewees. All clickable elements and all screens that were constructed in the prototype are described and presented within this section.

7.3.1. Projects Projects (see figure 5) is the screen which a user will arrive at after logging into the prototype. Here, a user can click on the project which the user is interested in or add a new project to the tool. Projects is based on the idea of seeing data about projects which the user is interested in, as expressed by R1, R2, R4 and R5. As such, the user will only see data about the software project which the user chooses to click on.

Clickable elements: • Solar Panels Project-window. - Results in: Transition to Views.

Figure 5 – Prototype: Projects screen.

7.3.2. Views Views (see figure 6) is the screen which a user will arrive at after clicking at a project in the Projects-screen. Here, a user can choose to click on either CEO, CFO or compliance officer which will all have different screens with a different set of data based on the information gathered from the corresponding work roles of the interviewees. Views is based on the idea of segregating the interests based on work roles, as expressed by R1, R3, R4 and R5. As such, the user will only see the relevant data about the chosen project based on the general interests of the chosen work role.

Clickable elements: • CEO-window. - Results in: Transition to CEO Dashboard. • CFO-window. - Results in: Transition to CFO Dashboard. • Compliance Officer-window. - Results in: Transition to Compliance Officer Dashboard. • Projects-tab. - Results in: Transition to Projects.

Figure 6 – Prototype: Views screen.

7.3.3. CEO Dashboard CEO Dashboard (see figure 7) is the screen which a user arrives at after clicking at the CEO-window in the Views-screen. Here, a user can click on the Costs Savings Recommendations-button to arrive at CEO Level 2. This screen is based on R1’s idea of “stupefying” the tool by hiding a lot of information, while presenting the financial perspective which R1 talked about. This screen contains data about risks, prioritized with three colors as described by R1, as well as data on how much costs each risk is associated with. This screen also shows information about the overall quality of the project, at what phase the project currently is in, and some data on how much the revenue could be increased with, based on the input received from the interview with R1.

Clickable elements: • Views-tab. - Results in: Transition to Views. • Projects-tab. - Results in: Transition to Projects. • Costs Savings Recommendations-button. - Results in: Transition to CEO Level 2.

Figure 7 – Prototype: CEO Dashboard screen.

7.3.4. CEO Level 2 CEO Level 2 (see figure 8) is the screen which a user arrives at after clicking the Costs Savings Recommendations-button in the CEO Dashboard-screen. This screen presents the user with recommendations on what particular things could be improved in the project to save costs, as well as data on what financial impact each recommendation will result in for the software project, if the recommendation is to be acted upon. This screen is based on the ideas of future budget impacts, as well as financial impacts of making different decisions which R1 discussed in the interview. It also contains three colors which represent the severity of the financial impact of making different decisions where the red color needs the most attention, as explained by R1.

Clickable elements: • Dashboard-tab. - Results in: Transition to CEO Dashboard. • Backwards-arrow. - Results in: Transition to CEO Dashboard. • Views-tab. - Results in: Transition to Views. • Projects-tab. - Results in: Transition to Projects.

Figure 8 – Prototype: CEO Level 2 screen.

7.3.5. CFO Dashboard CFO Dashboard (see figure 9) is the screen which a user arrives at after clicking at the CFO-window in the Views-screen. Here, a user can click on the Mitigation Recommendations-button to arrive at CFO Level 2. This screen is based on R3’s, R4’s and R5’s ideas of implementing a financial perspective into the tool relating to risks, costs, recommendations and prioritizations. Financial terms such as ROI, total costs and financial prognosis are also implemented in this screen as they were discussed by R3, R4 and R5 in different degrees in the interviews. It also contains data about project completion as discussed by R3 and R4, and some data about key people which has been brought up by R3, R4 and R5. Moreover, this screen allows for customization of the dashboard to allow for more control over both how and which data about software projects is shown, which was brought up by R3 and R4 during the interviews.

Clickable elements: • Views-tab. - Results in: Transition to Views. • Projects-tab. - Results in: Transition to Projects. • Mitigation Recommendations-button. - Results in: Transition to CFO Level 2.

Figure 9 – Prototype: CFO Dashboard screen.

7.3.6. CFO Level 2 CFO Level 2 (see figure 10) is the screen which a user arrives at after clicking the Mitigation Recommendations-button in the CFO Dashboard-screen. This screen is based on the idea of getting recommendations on financial investments in software projects, as well as the financial impact of acting on those recommendations, as discussed by R3, R4 and R5. This screen is heavily abstracted in technological terms and focuses on the money instead, which was talked about by R3, R4 and R5. The recommendations contain a shortened amount of data on impact and recommendations, so that a user may quickly understand the financial consequences of acting on a recommendation, as well as the recommended amount of money to invest and where it should be invested. This screen is also possible to customize so that the user can choose which data they want to see, as has been discussed by R3 and R4 during the interviews.

Clickable elements: • Dashboard-tab. - Results in: Transition to CFO Dashboard. • Backwards-arrow. - Results in: Transition to CFO Dashboard. • Views-tab. - Results in: Transition to Views. • Projects-tab. - Results in: Transition to Projects.

Figure 10 – Prototype: CFO Level 2 screen.

7.3.7. Compliance Officer Dashboard Compliance Officer Dashboard (see figure 11) is the screen which a user arrives at after clicking at the Compliance Officer-window in the Views-screen. Here, a user can click on the Prevention Information-button to arrive at Compliance Officer Level 2. This screen contains data about key people dependencies in monitoring systems, as well as systems problems over time as discussed by R2. It also contains a status bar which indicates the current status of the systems, as well as some legality aspects and data about future problems prevention which R2 talked about. R2 also talked about customizability in views, with one example where R2 preferred graphs when looking at changes over time. Customizability options have therefore been added to this screen in the prototype, as well as customization of graphs so that the user can fit the view to the user’s liking.

Clickable elements: • Views-tab. - Results in: Transition to Views. • Projects-tab. - Results in: Transition to Projects. • Prevention Information-button. - Results in: Transition to Compliance Officer Level 2.

Figure 11 – Prototype: Compliance Officer Dashboard screen.

7.3.8. Compliance Officer Level 2 Compliance Officer Level 2 (see figure 12) is the screen which a user arrives at after clicking the Prevention Information-button in the Compliance Officer Dashboard-screen. This screen contains data about prior systems downages as well as prevention information. R2 talked about the importance of making sure that security and monitoring systems work correctly, as well as the consequences of system failures. The consequences aspect of system failures is therefore indicated on this screen in the descriptions. R2 also talked about seeing data about problems over time, which the graphical representations to the right of the descriptions provide. These can also be customized as R2 talked about the ability to customize how data is shown on the screen.

Clickable elements: • Dashboard-tab. - Results in: Transition to Compliance Officer Dashboard. • Backwards-arrow. - Results in: Transition to Compliance Officer Dashboard. • Views-tab. - Results in: Transition to Views. • Projects-tab. - Results in: Transition to Projects.

Figure 12 – Prototype: Compliance Officer Level 2 screen.

8. Analysis This section presents an analysis on the quantitative and qualitative data generated from the questionnaire and the interviews.

8.1. Questionnaire results analysis The answers based on the introductory statement “I understand what CodeScene is for a tool”, show that all respondents have at least some understandings of what CodeScene is for a tool. Moreover, the answers illustrate that some respondents are very familiar with the tool, while others only have a basic understanding of the tool.

All statements relating to aspects of user-friendliness in CodeScene, such as statements having to do with the importance of being able to quickly learn the tool, or the importance of having help texts about displayed information in CodeScene available to the user, have more agreements than disagreements among the interviewees. The number of neutral answers to such statements, defined as picking the third alternative on the Likert-scale, range between zero and two. This portrays a picture of aspects such as CodeScene being easy to use, availability of help texts, access to relevant information per work role from the beginning of using CodeScene, and different abstraction levels in the information presented in the tool, being all rather important conditions for the respondents to use the tool.

The statements that relate to the usefulness of presenting financial data about software projects, such as statements having to do with prioritizing cost problems in software or preventing future costs in software, are mostly agreed with, where a minority stayed neutral in some cases. The answers to these statements are either neutral, agreeing to some degree, or agreeing fully. This can indicate that access to financial-type information is particularly important among the respondents. Statements that are made on a lower level as compared to financial-type information, covering software development aspects such as code knowledge, effectiveness in development teams and work allocation, generally have more neutral answers and contain disagreements (options 1 - 2 on the Likert-scale). A possible interpretation may therefore be that information containing software development terminology with no direct financial association, is less important to have access to among the participants as compared to information containing financial terms. The only statement in the questionnaire which has more disagreements than agreements is the statement “Access to information about work allocation and its impact on the quality of the software is useful in my work”, which further strengthens this interpretation.

Answers relating to the importance of having customization options in CodeScene indicate that quickly being able to adapt what type of information is presented in CodeScene is more agreed with, as compared to the option of not having to see information that the participants deem to be irrelevant. This indicates that the customization of presented information is seen as being more important than the option of hiding irrelevant information in CodeScene.

For the functionality-based statements, the answers from the role-based templates and the views functionalities are more agreed with than disagreed with among the respondents. These answers indicate that functionalities that allow for segregation of data about software projects based on either the work- roles or the preferences of the respondents, are important implementations to have in a tool like CodeScene.

8.2. Analysis of qualitative data The analysis of the data generated from the interviews is supported by themes that are based on the two research questions of this paper.

8.2.1. Perspectives on data considered to be useful A set of themes on what is considered to be useful data about software projects in software analytics tools are identified based on the generated data from the interviews (see Figure 13).

Perspectives on useful data reconstructed as themes

Risk Assessment

Financial Perspective

Key People

Historical Aspects

0 1 2 3 CEO Compliance Officer CFO

Data which helps with risk assessment within software projects is mentioned among all the interviewees as being a useful implementation within a software analytics tool. This includes recommendations on mitigating risks and problems, as well as data about the impact of acting upon the recommendations.

The CEO and all CFOs also mention the representation of a financial perspective within a software analytics tool to be useful. The key parts of the financial perspective include financial data about software projects, such as ROI, cost

46 and revenue, cost and revenue expectations, as well as data on how much capital has been spent currently on various parts and processes of software projects. The financial perspective also includes recommendations for improving the financial state of a software project, as well as the financial impact of acting upon the recommendations.

A difference in the perspective on useful data seems to exist between the compliance officer and the CEO and CFOs. The difference is partly illustrated by the lack of discussion of a financial topic, as well as a contrast in what data is defined as useful in the conversation with the compliance officer. The compliance officer is defining useful data as data that indicate whether security and monitoring systems are working correctly, as well as possible risks and problems with such systems, accompanied with suggestions on resource allocation to solve such problems. Moreover, the compliance officer also mentions a key people representation which shows all people involved in quality controls of different security and monitoring systems as being useful. A historical aspect of problems is also discussed as being useful, which would compare the size of problems over time within an organization.

Key people and historical aspects are also mentioned as being useful among the CFOs but in a financial context instead. A key people view should connect people in the organization with performance gains and performance issues, relating to finance. That is, a key people view should financially measure and value the economic aspects of people involved in projects. As an example, a scenario where an employee of the company is getting a better offer from another company is mentioned by R5, which illustrates a possible use case for such a function:

[…] one of the members of the development team is getting a better offer from another company, and we are thinking, how much extra package we should give, to try to keep them. I can see, those sorts of things, just, prioritizing, and trying to make sort of value judgements on things, that, that could be quite useful.

The historical aspects are described as having the form of a status which indicates the degree of project completion in percentage, as mentioned by R3, or described as having the form of a prognosis which would indicate if the project will be completed in time based on the current development process, as mentioned by R4.

The identified themes on useful data are all indicative of higher-level concerns as opposed to lower-level technical concerns, such as data about code dependency or code complexity. This matches with the results from the literature review which states that managerial roles mostly focus on higher-level concerns, such as project goals and the allocation of resources [3]. It is therefore reasonable that the perspectives of the interviewed managers on useful data about software projects in software analytics tools does not strictly include lower-level technical concerns.

8.2.2. Perspectives on presenting data about software projects A set of themes on the wants of presenting data about software projects in software analytics tools are identified based on the generated data from the interviews (see Figure 14).

Perspectives on data presentation reconstructed as themes

Abstraction Levels

Limited Data

Relevant Views

Visualization

Project-based Data

Customizability

Intuitiveness

0 1 2 3 CEO Compliance Officer CFO

Abstraction levels, limited data and relevant views are discussed by all interviewees as being desired aspects of presenting data about software projects in software analytics tools.

- Abstraction levels refers to having a higher-level view from the beginning which shows the most important data with few details, from where one should be able to access lower levels of abstraction which will show more details about the data that was chosen to acquire more details on. - Limited data refers to having a limited set of data displayed. - Relevant views refer to being able to have access to views which contain relevant pieces of data for the user.

Visualization and project-based data are also discussed by some of the interviewees as being desired aspects of presenting data about software projects in software analytics tools.

- Visualization refers to having a graphical representation of data, such as graphs or circular illustrations which provide insight on the severity of problems.

- Project-based data refers to only viewing the data that is specific to the chosen project.

The two themes that are least discussed among the interviewees are customizability and intuitiveness. These are also discussed as desired aspects of presenting data about software projects in software analytics tools.

- Customizability refers to being able to customize what data is presented for the user. - Intuitiveness refers to a coherent way of presenting data, so that the usage and navigation of a software analytics tool is intuitive, and thereby effortless to some degree.

A major part of the identified themes on data presentation relate to the results from the literature review on important aspects of presenting information to higher-level stakeholders. For instance, the ideas of abstraction levels, limiting data, relevant views and visualization are all important aspects of information presentation to incorporate in software analytics tools for higher-level stakeholders [1] [3].

Abstraction refers to the ability of “drilling-down” from high level summaries to lower-level views [1] [3]. This interpretation is supported in terms of accessing lower-level views from higher-level views, as this is considered important by all interviewees.

A limited amount of metrics in displays can be helpful [21], which is also supported by all interviewees, based on their wants of limiting the amount of data that is presented to them in software analytics tools.

Views are described as relevant displays with relevant data for various stakeholders, and can thereby be used to support the concerns of different stakeholders [3] [8]. Access to relevant views with relevant pieces of data for the user is also stated to be an important aspect of presenting data among all interviewees.

Finally, visualization refers to the importance of presenting information in a visual form [1] [9] [10] [12], which is supported by the majority of the interviewees. It is therefore reasonable to assume that software analytics tools that are to be used by managers, should contain visual presentations of various pieces of data, to better address the wants of data presentation of managers in these types of tools.

9. Discussion The purpose of this work is to explore the perspectives of managers on useful data about software projects in software analytics tools, as well as examining how managers want data about software projects to be presented in software analytics tools. These tools are currently not widely used by higher-level stakeholders such as managers due to an unclear understanding of what managers need in such tools [3], even though previous work in this field illustrates that software analytics tools have the potential of increasing decision- making capabilities in managers by providing them with important information, thereby increasing the effectiveness of software development processes in organizations [2] [10] [12] [13]. By exploring the perspectives of managers on useful data and how they want data to be presented in software analytics tools, it is possible to provide the research field of software analytics with valuable insights that may contribute to the development of software analytics tools that are more suitable to be used by managers.

The results show that a commonality between all managers exists on what they consider to be useful data about software projects in software analytics tools. The commonality consists of data which relates to risk assessment in software projects, such as recommendations on reducing risks and problems, as well as data about the impact of acting upon such recommendations. The work of all the interviewed managers consists in various degrees of risk assessment, which is likely the reason to why this type of data is considered useful by all the interviewed managers to have in software analytics tools.

The representation of a financial perspective, consisting of financial data about software projects such as ROI and cost and revenue expectations, as well as recommendations on increasing the financial aspects of software projects, is considered to be useful data in software analytics tools for all managers except for the compliance officer. A likely explanation to why the compliance officer did not mention a financial perspective to be useful to have in a software analytics tool is that the work of the compliance officer is not related to finance, whereas the work of the CEO and the CFOs is highly related to finance.

The other two pieces of data that are considered to be useful to have in a software analytics tool is data on key people and historical aspects relating to software projects. This is mentioned by both the compliance officer and in various degrees by the CFOs. Moreover, the description of key people and historical aspects differ between the compliance officer and the CFOs. The compliance officer described such data in the context of security and monitoring systems, such as the involvement of key people in quality controls of systems, whereas the CFOs described such data in a financial context.

Two important observations are recognized here. The first observation is that what is considered as useful data can differ among a group of managers. This indicates that a software analytics tool should not merely focus on trying to appeal to all kinds of managers in a single view. Instead, a software analytics tool should offer a variety of views, based on either work roles of different managers, or possible use cases of different managers. This is supported by previous work which states that different views that support the concerns of

50 different stakeholders by supplying relevant data and metrics for different stakeholders, is important to have available in software analytics tools for higher-level stakeholders [3] [8].

The second observation is that the data that is considered as useful to have in software analytics tools based on the generated data from the interviews, is not explicitly represented in any of the studies from the literature review. What is mentioned in some of the studies however, is that there is a lack in prior research in the research area of software analytics on higher-level stakeholders needs of information in software analytics tools [2] [3] [17]. This study therefore seems to contribute to this research gap by providing this research area with insights on what managers consider to be useful data in software analytics tools.

On the other hand, various data presentation aspects that are considered important to include in software analytics tools for higher-level stakeholders have been studied to some extent in previous work [1] [3].

The results show that a set of three commonalities between all managers exists in how they want data to be presented in software analytics tools. These commonalities consist of: (1) Presenting data in abstraction levels, where the initial view with data should be at a high abstraction level, showing the most important data with few details. The initial view should also allow for accessing lower abstraction levels with more details about the data elements that the user is interested in gaining more insights on. (2) Presenting a limited amount of data for the user, as opposed to presenting a large amount of data. (3) Presenting relevant views with relevant pieces of data for the user.

All of the managers except for one CFO also mention wanting visualization, which refers to viewing data in a graphical format as opposed to a text format, as this may facilitate the comprehension of presented data. Project-based data is also mentioned by all managers except for the compliance officer. The compliance officer is instead more interested in being able to see if all relevant systems are working correctly. A majority of the managers also want customizability options in what kind of data is shown, while a minority mentions wanting more intuitiveness in how data is presented, referring to a more coherent way of presenting data, thereby facilitating the ease of use of software analytics tools.

The ideas of abstraction levels [1] [3], limiting data [21], relevant views [3] [8] and visualization [1] [9] [10] [12] are all supported by previous work on important information presentation aspects in software analytics tools for higher-level stakeholders, while project-based data, customizability and intuitiveness are not. This study may therefore contribute to this research area by providing additional important data presentation aspects for managers in software analytics tools, consisting of project-based data, customizability, and intuitiveness. As with the case of perspectives on useful data, some differences among the managers are identified, where an example is the project based-data way of presenting data. Moreover, the aspects of customizability and intuitiveness are less discussed among the managers, which results in less support for these among the managers.

A majority of the resulted questionnaire data is further explored in the interviews and is also almost entirely supported for in the various discussions, except for an inconsistency in the answers for the “Access to information about work allocation and its impact on the quality of the software is useful in my work” statement in the questionnaire.

This is the only statement in the entire questionnaire which has more disagreements than agreements among the managers. It is clear from the interviews that information on resource allocation as well as its impact on various aspects of software quality is important for the managers to have access to in software analytics tools, as they are frequently arguing for mitigating risks in software, as well as a majority of the managers being interested in financial aspects of software projects. However, the answers in the questionnaire argue for the opposite case. An interesting observation based on this is identified here. “Work allocation” is not clearly defined, as it can refer to both the allocation of physical individuals, as well as the allocation of workload among individuals, which may confuse the managers. Moreover, “Software quality” is used in the statement, which may indicate that the statement refers to more technical aspects in terms of the impact of the work allocation, which is considered to be irrelevant for the most part among the managers based on the interviews. It is therefore possible that the majority of the managers are disagreeing with this statement as they do not wish to have access to technical information about software. This interpretation is further strengthened based on the generated data from the interviews, as the managers are not interested in technical aspects of software. The verdict is that this statement is unambiguously defined. It is therefore not fully understood what the answers from the questionnaire really indicate.

The purpose of the prototype is to support the findings in this study in a visual format, based on the generated data from the interviews. The purpose of the prototype is not to illustrate an ideal software analytics tool made for managers. Instead, it is constructed as a way to potentially illustrate the general data presentation aspects and the general type of data about software projects that managers find useful to have in a software analytics tool. The graphical contents of the prototype, such as graphs and illustrations, are implemented as a way to demonstrate the functionalities that are discussed by the managers in the interviews in a general sense. Therefore, the shape of various graphical elements, such as the length of bars of a bar chart, or the size of buttons, should not be confused with a realistic representation of the managers thoughts and ideas on such details. As an example, the size of buttons, and the graphical representations of graphs are not discussed from a detailed point of view during the interviews. The positioning of various information elements is not discussed during the interviews as well.

With this being said, the purpose of the prototype is to illustrate the general concepts of data presentation, as well as the desired data, as discussed during the interviews. If a graph or a “create a report” functionality is observed in the prototype, then it simply means that these are discussed at some point during the interviews as being important or desired to have in that specific view. A separation of concerns based on work roles is implemented in the prototype, which further segregates the data presentation aspects and the desired pieces of data based on the discussion of each manager and their work roles. This

52 functionality is implemented as it is discussed as a favorable way of separating the concerns of different work roles among the majority of the managers. The prototype incorporates the data about software projects that the managers consider to be useful, as well as the wants of the managers on data presentation, based on the generated data from the interviews.

The prototype has not received any feedback and is therefore constructed based on the discussions of the managers as relating to the research questions. As a consequence, the validity and the correctness of the prototype is not satisfactory at its current state of design. However, and as mentioned previously, a majority of the data presentation aspects considered to be important to have in a software analytics tool by the managers, which are also implemented in the prototype, are also supported by previous studies in the research field of software analytics. This strengthens the validity of the corresponding aspects of data presentation. As such, even though the useful data as discussed by the managers are not represented in previous studies, a majority of the data presentation aspects are, which results in the validity of the prototype being to some degree strengthened, based on both the discussions of the managers in this study, as well as other relevant studies which present similar findings.

This study can be used for software analytics tools developers to gain insights on what managers find to be useful pieces of data about software projects to have in software analytics tools, as well their preferred ways of presenting data in such tools. This study can also be used by other researchers to further validify the findings, testing the validity of the prototype, or to further build upon the design of the prototype.

9.1. Limitations and Challenges The results are based on five interviews with managers from Swedish organizations that specialize in software development. More interviews with managers are desirable to further strengthen the credibility of the results of this study. The small number of interviewees, and the fact that they are all located in Sweden, is a possible threat to generalization. The credibility of the results is strengthened to some degree by some similar findings in previous studies.

The biggest challenge of this study was a substantial difficulty in finding managers that work in software development organizations which were willing to participate in the interviews. As the research field of software analytics is a slowly emerging research area, resulting in many studies being small and exploratory [21], it is possible that the chosen research topic had an impact on the size of this study, potentially reflected by the small number of managers who participated in this study.

CodeScene was referred to in various degrees both in the questionnaire and the interviews, as all of the managers had some prior knowledge of this software analytics tool. CodeScene was also used as a free license for the tool was granted to me to support my research economically, as software analytics tools are generally expensive to use. As CodeScene was sometimes used as a reference point for a software analytics tool, it may have had a somewhat biased impact

53 on the managers perception of what a software analytics tool is and how it functions.

As the analysis and discussion is mainly based on interpreting the interviewees perspectives relating to the research questions, a risk of misinterpretation exists, particularly in instances where the discussions of an interviewee are not supported by other interviewees or the literature review. Most of the interpreted data is supported by more than one interviewee which strengthens these interpretations to some degree. Moreover, the analysis and discussion are based on what different aspects of software analytics tools that the interviewees consider to be good or helpful for them, which originate from their subjective perspectives. It is therefore important to note that the input of the interviewees might not always be correct due to either preconceived views, or oversimplified views of various software development processes or software analytics tools.

9.2. Future Work This study is exploring the perspectives of managers that work in software development organizations on useful data about software projects and their wants on data presentation in software analytics tools. The work is positioned in this particular context as a research gap on this topic exists within the research field of software analytics. This study can therefore be described as an early step of contributing to this research gap with valuable insights relating to the aforementioned area of exploration. As this study is small in nature, more research needs to be done to strengthen the credibility of the results. The prototype can for instance be used to gain feedback from managers on its validity, as well as further improving its design and correctness.

10. Conclusions The results show that the perspectives of managers that work in software development organizations on useful data about software projects in software analytics tools, is comprised of data which support risk assessment, data which connects software projects with financial aspects such as recommendations on increasing revenue, data on key people in software projects such as people involved in quality controls or financial value judgements relating to the performance of people, and data which contain historical aspects of software projects, such as data on whether problems are increasing or decreasing. These are considered to be useful pieces of data to have access to in software analytics tools for managers that work in software development organizations.

The results also show that managers that work in software development organizations want data about software projects to be presented to them in software analytics tools as abstraction levels, with initial higher-level views where the most relevant data is summarized and accompanied by fewer details, from which the managers then should be able to access lower-level views with more details based on their data of choice in the higher-level view. Having a limited amount of data presented with less technical details is considered important in software analytics tools, as well as having access to relevant views which contain relevant pieces of data for the user. Visualization in the presented data is also important for a majority of the managers, which refers to having software analytics tools presenting data in a graphical format, as opposed to only presenting data in a text format. Having data presented based on the project that the user chooses is also considered important for the majority of the managers. A minority of the managers also consider customizability options to be important in software analytics tools, referring to having the choice of choosing what kind of data is shown in these types of tools, as well as presenting data in an intuitive way, which could facilitate the ease of use of such tools.

The managers perspectives on these aspects of useful data and data presentation in software analytics tools also shows to be different in some instances. These differences are based on the managers work roles or use cases that are relevant for their work. For instance, financial-based data relating to different aspects of software projects is not discussed as being useful or important by the compliance officer. The compliance officer instead prefers data relating to quality controls of various monitoring systems used within their company.

Finally, this work indicates that a software analytics tool should not offer a single generalized view to be used by a group of managers with different work roles, as what is considered to be relevant for one work role is not always considered to be relevant for another work role.

11. References [1] V. Kaulgud and V. S. Sharma, "Software Development Analytics: Experiences and the Way Forward," in 2015 30th IEEE/ACM International Conference on Automated Software Engineering Workshop (ASEW), 9-13 Nov. 2015 2015, pp. 10-13, doi: 10.1109/ASEW.2015.25. [2] T. M. Abdellatif, L. F. Capretz, and D. Ho, "Software analytics to software practice: a systematic literature review," presented at the Proceedings of the First International Workshop on BIG Data Software Engineering, Florence, Italy, 2015. [3] R. P. L. Buse and T. Zimmermann, "Information needs for software development analytics," presented at the Proceedings of the 34th International Conference on Software Engineering, Zurich, Switzerland, 2012. [4] M. Nayebi, G. Ruhe, R. C. Mota, and M. Mufti, "Analytics for Software Project Management -- Where are We and Where do We Go?," in 2015 30th IEEE/ACM International Conference on Automated Software Engineering Workshop (ASEW), 9-13 Nov. 2015 2015, pp. 18-21, doi: 10.1109/ASEW.2015.28. [5] S. Lavalle, E. Lesser, R. Shockley, M. Hopkins, and N. Kruschwitz, "Big Data, Analytics and the Path From Insights to Value," MIT Sloan Management Review, vol. 52, pp. 21-32, 12/01 2011. [6] T. Stablein, D. Berndt, and M. Mullarkey, "Technical debt-related information asymmetry between finance and IT," presented at the Proceedings of the 2018 International Conference on Technical Debt, Gothenburg, Sweden, 2018. [7] W. Cunningham, "The WyCash portfolio management system," SIGPLAN OOPS Mess., vol. 4, no. 2, pp. 29–30, 1992, doi: 10.1145/157710.157715. [8] E.-M. Arvanitou, A. Ampatzoglou, S. Bibi, A. Chatzigeorgiou, and I. Stamelos, "Monitoring Technical Debt in an Industrial Setting," presented at the Proceedings of the Evaluation and Assessment on Software Engineering, Copenhagen, Denmark, 2019. [9] A. E. Hassan, A. Hindle, P. Runeson, M. Shepperd, P. Devanbu, and S. Kim, "Roundtable: What's Next in Software Analytics," IEEE Software, vol. 30, no. 4, pp. 53-56, 2013, doi: 10.1109/MS.2013.85. [10] T. Menzies and T. Zimmermann, "Software Analytics: So What?," IEEE Software, vol. 30, no. 4, pp. 31-37, 2013, doi: 10.1109/MS.2013.86. [11] Adobe Inc. "Adobe XD | Fast & Powerful UI/UX Design & Collaboration Tool." Adobe.com. https://www.adobe.com/se/products/xd.html (accessed Mar. 30, 2021). [12] N. Forsgren, J. Humble, and G. Kim, Accelerate: The Science of Lean Software and DevOps Building and Scaling High Performing Technology Organizations. IT Revolution Press, 2018. [13] L. Guzmán, M. Oriol, P. Rodríguez, X. Franch, A. Jedlitschka, and M. Oivo, "How Can Quality Awareness Support Rapid Software Development? – A Research Preview," Cham, 2017: Springer International Publishing, in Requirements Engineering: Foundation for Software Quality, pp. 167-173. [14] R. Kozik, M. Choraś, D. Puchalski, and R. Renk, "Data analysis tool supporting software development process," in 2017 IEEE 14th

International Scientific Conference on Informatics, 14-16 Nov. 2017 2017, pp. 179-184, doi: 10.1109/INFORMATICS.2017.8327243. [15] R. Westrum, "The study of information flow: A personal journey," Safety Science, Article vol. 67, pp. 58-63, 08/01/August 2014 2014, doi: 10.1016/j.ssci.2014.01.009. [16] A. Alsulaimi and T. Abdullah, "Management of Stakeholder Communications in IT Projects," in 2020 3rd International Conference on Computer Applications & Information Security (ICCAIS), 19-21 March 2020 2020, pp. 1-6, doi: 10.1109/ICCAIS48893.2020.9096842. [17] I. Noorwali, "Stakeholder Concern-Driven Requirements Analytics," SIGSOFT Softw. Eng. Notes, vol. 43, no. 1, pp. 1–6, 2018, doi: 10.1145/3178315.3178324. [18] M. Christakis and C. Bird, "What developers want and need from program analysis: an empirical study," presented at the Proceedings of the 31st IEEE/ACM International Conference on Automated Software Engineering, Singapore, Singapore, 2016. [19] S. Forouzani, Y. K. Chiam, and S. Forouzani, "Method for Assessing Software Quality Using Source Code Analysis," presented at the Proceedings of the Fifth International Conference on Network, Communication and Computing, Kyoto, Japan, 2016. [20] P. Ram et al., "Actionable Software Metrics: An Industrial Perspective," presented at the Proceedings of the Evaluation and Assessment in Software Engineering, Trondheim, Norway, 2020. [21] H. Huijgens, D. Spadini, D. Stevens, N. Visser, and A. v. Deursen, "Software analytics in continuous delivery: a case study on success factors," presented at the Proceedings of the 12th ACM/IEEE International Symposium on Empirical Software Engineering and Measurement, Oulu, Finland, 2018. [22] Empear AB. "Software Quality Visualization - Tech Debt | CodeScene." Codescene.com. https://codescene.com/ (accessed Mar. 17, 2021). [23] SonarSource S.A. "Code Quality & Code Security | SonarQube." Sonarqube.org. https://www.sonarqube.org/ (accessed Mar. 18, 2021). [24] Synopsys, Inc. "Coverity SAST Software | Synopsis." Synopsys.com. https://www.synopsys.com/software-integrity/security-testing/static- analysis-sast.html (accessed Mar. 18, 2021). [25] Enento Group. "Empear AB - Företagsinformation." Allabolag.se. https://www.allabolag.se/5590283270/empear-ab (accessed Mar. 17, 2021). [26] A. Tornhill, "Assessing Technical Debt in Automated Tests with CodeScene," in 2018 IEEE International Conference on Software Testing, Verification and Validation Workshops (ICSTW), 9-13 April 2018 2018, pp. 122-125, doi: 10.1109/ICSTW.2018.00039. [27] J. W. Creswell, Research design : qualitative, quantitative, and mixed methods approaches, 4th ed. ed. SAGE Publications, 2014. [28] B. J. Oates, Researching Information Systems and Computing, 1st ed. ed. SAGE Publications, 2005. [29] B. Gillham, Developing a questionnaire, 2. ed. ed. (Real world research). Continuum, 2007. [30] W. L. Martinez and A. R. Martinez, Exploratory data analysis with MATLAB (Chapman & Hall/CRC series in computer science and data analysis). Chapman & Hall/CRC, 2005.

[31] J. Nielsen, "Iterative user-interface design," Computer, Periodical vol. 26, no. 11, pp. 32-41, 11/01/ 1993, doi: 10.1109/2.241424.

12. Appendix

12.1. Appendix A – CodeScene Off-boarding simulation

12.2. Appendix B – CodeScene Dashboard

12.3. Appendix C - Interview Dashboard Picture

12.4. The design of the questionnaire

12.5. Interview Questions

- Can you start by telling me a little about yourself, and what you do in your work? 1. Based on the video, what did you think stood out most in the tool and why? 2. How relevant were the features presented in the video for your work role? 3. What are your general thoughts on the design that exists in CodeScene? 4. What did you think of the navigation in CodeScene? 5. What improvement opportunities do you see in CodeScene? 6. Based on your work role, can you name and explain the things that you want to see in a software analytics tool? 7. Based on your work role, how do you want information to be presented to you in a software analytics tool? 8. How would the perfect software analytics tool look like, in your opinion? You can be as creative as you want - there are no limits for what is possible. 9. If you had to mention and explain something that, in your opinion, must be included in a software analytics tool - what would you mention, and why? 10. What are the requirements that need to be fulfilled, for you to use software analytics tools? 11. What is required of a software analytics tool, for you to be able to act on the information presented in such a tool? 12. What is your definition of "usability" when it comes to software analytics tools? 13. What customization options do you want to have access to in a software analytics tool? 14. If you had to mention two visual characteristics that you would like to have in a software analytics tool - what would you have answered? 15. How would you like a software analytics tool to handle the interests of different work roles – separation of concerns of different work roles? Questions on the interview dashboard picture (see Appendix C) as well as the CodeScene Dashboard:

1. The image consists of three different dashboards, which are marked by the purple rectangles. I want you to look at the different dashboards from a visual perspective. Is there anything you like or dislike about the pictures? Is there possibly something that you are inspired by and would like to see in a similar form in a software analytics tool? 2. I want you to look at the CodeScene Dashboard and try to come up with similar input as in the previous question. All input is valuable, even small

details that seem completely irrelevant. I simply want to know what you think about the existing design, from the perspective of your work role.

12.6. Interview Protocols P – Patrik Skuza X – Interviewee [word] – Replaces words that could potentially reveal the interviewees’ identity. {inaudible} – Replaces words that are inaudible. (field) – Clarification on what field/subject the interviewee is talking about.

12.6.1. Protocol 1 The interview starts and X grants permission to record the interview.

P: Intevjun är uppdelad i två delar. I den första delen tänker jag visa upp en 6 minuters video för att ge dig rätt kontext i vad ett mjukvaruanalysverktyg är, så jag kommer att spela upp den alldelles strax. Och del 2 av intervjun är då intervjun i sig själv, den semi-strukturerade intervjun...

X: Patrik, bara innan vi kör förbi, du vet, om det är för, jag är, vet ju allra högst, jag vet inte om du har hört min historia, men jag, till skillnad från andra som du kanske intervjuar, jag vet ju i allra högsta grad vad CodeScene är. Jag var med från början och den första kunden in, och jag använder ju CodeScene än idag, i stort sätt. Så jag vet inte, den här 6 minuters om den är för att försöka förstå vad CodeScene är, så tror jag att vi kan göra det väldigt kort.

P: Ja okej, perfekt, men då kanske vi skippar videon helt?

X: Ja, jag tror det, därför att jag, jag är ju den som gett [namn] väldigt mycket input innan första data presentational {inaudible}, hur vi ska göra, starta lite grann till en början för att förstå egentligen, vad är det som attraherar mig, jämfört med en annan användare som kommer från kod nivå. Så jag tror jag har rätt mycket av den bakgrunden – så bara kör på.

P: Perfekt, perfekt. Då har vi sparat 6 minuter där.

X: Precis.

P: Okej! Då går vi över till frågorna direkt.

X: Bra.

P: Kan du börja med att berätta lite om dig själv, och vad din arbetsroll går ut på?

X: Jag är VD på ett börsnoterat bolag som heter [namn]. Så min arbetsroll är som VD jag brukar säga att jag försöker vara smörjoljare och städare och städa

77 sen driva, och försöka få fram rätt beslut med rätt beslutspunkter. Så besluta, driva, inspirera – klassiskt VD jobb, med det jag förväntas göra.

P: Okej, perfekt... Så okej – finns det någonting som du tycker står ut mest i CodeScene?

X: Hur menar du, i funktionsväg, dataväg, vad du kan göra, eller vad menar du med ”som står ut”?

P: Ja, det kan vara funktionsmässigt, det kan vara rent visuellmässigt, det kan vara vad som helst, liksom den ena saken som du tänker på, när du tänker på, när du hör ”CodeScene” – någonting som står ut...

X: Att det borde, och då sagt till [namn], att det borde, det är ett väldigt komplicerat verktyg för att verka på en konsoliderad nivå när man kommer till beslutsfattare högt upp. Man ska ha kunskaper, förståelse för toolen, för att egentligen konfigurera det på rätt sätt. Det är inte så själv-intuitivt enkelt att förstå om du ger det till någon som inte till vardags, är, utvecklare.

P: Ja, bra svar, faktiskt, i CodeScene...

X: Så om du ger det till någon som inte jobbar med utveckling och förstår vad en JIRA är och förstår vad domäner är, och förstår hur du bryter ner i domäner, och förstår det här, problematiken med att du inte har väldigt många utvecklare, och testare, så är det svårt att du besitter på en finansiell roll som håller i budgeten – att snabbt få sig en uppfattning om ”ligger vi på budgeten”, ”under budgeten”, ”vad betyder detta för mina kostnader längre fram”, och ”ska jag fortsätta fram med detta projektet” – är INTE lätt att få svar på i CodeScene idag.

P: Ja, precis, tack, tack för det svaret. Så... Vad är dina generella tankar kring designen som finns i CodeScene?

X: Inte, asså det, ännu en gång, det är ett ”by engineers, for engineers”. Det är inte, ja det är samma sak med första svaret som jag hade, det är INTE utvecklat designmässigt, för att vara intuitivt enkelt, att kunna ha större användargrupp än, utvecklarna själva, och ibland ansvarig för utvecklare/test. Det är väl det första, ja det är egentligen detsamma delsvar av första frågan.

P: Ja, precis, precis. Okej. Så... Det här kommer också att återkoppla tillbaka till föregående fråga, MEN, vilka förbättringsmöjligheter ser du i CodeScene, rent praktiskt – VAD hade du velat se...

X: Förenklat...

P: Implementerat i CodeScene... Ja, till exempel.

X: Förenkla, förenkla, förenkla... Förenkla – förstå skillnaden på vilka målgrupper man använder sig... Som man vänder sig till. Och för de målgrupperna som kommer från en annan del i vassen, förutom själva utvecklingssidan och ledare och utvecklare – Förenkla verktyget, med, kanske redan färdiga templates, eller enkelt sätt att förklara, knutna till... Jag och [namn] har pratat i många år om finansiella mått – Göra det lättare att förstå

78 vad verktyget faktiskt ”bringar” en vevare, utan att man behöver ha, antingen intresse... Jag var väldigt speciell på det sättet att jag är väldigt intresserad av teknik och är en VD som driver mycket teknik själv. Så för mig var det inga problem att sätta mig in i, både rapporterna och verktyget, och förstå på djupet vad det faktiskt ”bringar” mig. Men jag tror att en ”generell” VD på börsen eller på ett mindre bolag, har absolut inte, varken intresset eller tiden till att lägga det själv, och då, för de kommer detta att vara ett verktyg som inte används – om det skulle se ut som det gör idag.

P: Ja. Tack, tack för ditt svar. Okej, så ifall vi då tänker utifrån din arbetsroll, som VD – kan du nämna och förklara vad du hade velat se i... i CodeScene?

X: Mm. Asså, vi har pratat om det länge – en VÄLDIGT enkel överblick, som summerar INOM det området, koden/domänen som CodeScene övervakar: 1. En indikator hurvida vi står – är det någonting som nu CodeScene markerar som är riktigt, riktigt fel – och hur det påverkar min budget, pengar eller autot... var man nu sätter budgeten. Det är den enkla, så en ÖVERGRIPANDE vad som... Vi började, jag vet inte om du har sett de rapporterna eftersom jag, jag och [namn] efter de första rapporterna för 3 år sedan på [namn], så introducerade [person] de här sliderna, där man ser: Rött, Gult, Grönt, inom olika domäner, hurvida man ligger till för vissa områden.

P: Mhm.

X: Det är MITT I PRICK sånt – det är sånt jag skulle vilja se egentligen, att hela, VD-ytan, ska VARA uppbyggd på den ”dum-nivån”. Ju enklare, desto bättre. Är det Rött, är det Grönt, och om det är Gult – vad ska vi göra för att det ska bli rätt?

P: Okej, ja, perfekt...

X: Och GÄRNA så kopplat som möjligt, för just nu är det inte kopplat till ”vad betyder detta i bottom-line”, i antingen ren produktivitetshöjning, att du ”missar” att du skulle kunna göra X-miljoner pengar i om ni hade gjort detta rätt, för då hade ni kunnat komma till slutkund snabbare. ELLER att detta kostar dig X-miljoner varje månad ni fortsätter, på grund av att du har 4 utvecklare som ”står och stampar” och inte gör något, för de är icke produktiva. Så kopplat TILL financiell utveckling.

P: Precis... Så man hade kunnat beskriva, lite ditt svar som, att beskrivningar är av ett väldigt högt värde tillsammans med...

X: Oooja.

P: ...det som presenteras ut...

X: Ooja.

P: Så det räcker inte liksom med att ha, låt oss säga en Röd... ruta – ”Det här är fel” och ”Det här måste man fixa direkt”. Utan, det ska finnas en bakgrundsbeskrivning till...

X: Yes.

P: ...VARFÖR det ska fixas, och sen även då, kunna se vilken impact det hade haft på det financiella.

X: Yes. Och kanske ännu viktigare – financiella före VARFÖR det ska fixas, för annars blir det lätt, att om man skriver det, och nu håller {inaudible}... Jag kan BARA uttala min egen roll, jag kan inte uttala mig vad funkar för andra roller, men om man tittar på beslutsfattande roller, de som håller i pengarna, så är det – det är inte så viktigt för mig att veta exakt VARFÖR, det vill säga ”på grund av kodrad x” och att det kan bli spallt i databasen längre fram – det är sånt som jag oftast inte förstår. Utan det är viktigare att säga ”Om inte detta fixas så kommer det kosta 1,5 miljon extra – det kommer ta dig 2 veckor längre innan ni kommer till projektslut.” Bra – det fattar jag. Och då kan jag ställa en fråga till, ”vad ska vi göra för att göra det bättre”. Så det är viktigare än att förklara varför det måste fixas det här – vad är business impact, om det inte fixas.

P: Okej, perfekt, tack, tack för det svaret, Så... Låt oss säga så här. Hur hade det perfekta mjukvaruanalysverktyget sett ut, enligt dig, och du kan vara hur kreativ du vill – det finna inga gränser för vad som är möjligt.

X: Asså det, dubbeklickar, som jag pratar... På ENKLASTE - På min mobil skulle jag kunna ha en pling som visar mig att inom det jag satt in CodeScene på att mäta. Jag tittar på CodeScene ofta som ett besiktningsföretag som att köpa hus, fast besiktning på kod. Okej jag har satt JUST NU är högst upp för mig för [namn] så är projekt A viktigast av allt. Som jag bedömt det ”Om inte projekt A lyckas under 2021 – så har jag jäkligt stora problem som VD”, vilket gör att jag får söka efter nytt jobb och sälja {inaudible}. Projekt A är skitviktigt – okej. Jag skulle vilja ställa in CodeScene som bara mäter Projekt A som för en daglig – som när man tittar på vädret på min [namn], så skulle jag kunna få en chans som visar mig: ”Hur ser Projekt A ut EGENTLIGEN nu” – du kan lugnt {inaudible} vidare och fokusera på annat, ELLER – det är ett problem.

OM det är ett problem någonstans så skulle jag kunna dubbeklicka på det problemet och komma ner till nästa vy under – som visar ”detta problemet innebär nu, om du inte gör någonting åt den här varningen/flaggningen, så kommer det att bli 3 miljoner dyrare, 2 månader senare – A FAN. Dubbeklicka igenom om du vill veta mer information. Då kommer du ner och tittar på lite ”gritty” – detta beror på att X, Y, Z av N... Här har du frågor där du kan ställa om du vill veta varför detta hänt, eller vad borde vi göra åt det. Så att kunna DUBBELKLICKA sig ner i mer och mer djup, istället för att bombas av mycket information som vi gör nu på CodeScene – och det är väldigt mycket installeringar och mycket knappar du ska veta, du ska trycka, du ska monitorera det, och installera det rätt. Så väldigt ”dum-version” högst upp som är för mig... för jag har väldigt mycket frågor som kommer till mig varje dag, jag har cirka 9 minuter och lägga på en fråga varje dag som kommer till mig. Jag vill se: ”Okej, är detta bra?” – behöver inte veta mer, allting är grönt. Men är det någonstans det börjar brinna så vill jag kunna dubbelklicka och se mest business impact-nivå, dubbeklicka igen, vad är det för information/jag behöver göra någonting åt – och utifrån det kan jag agera.

P: Ett jättebra svar... Det, ett jättebra svar... Tack för det svaret.

X: Mm.

P: Då ska vi se. Vad är din definition av ”användarvänlighet”, när det kommer till mjukvaruanalysverktyg?

X: Ja... Oof ingen aning – bra fråga. Vad är min definition generellt? Jag använder inte många förutom CodeScene, så är det skillnad på vad som är definitionen av ”användarvänlighet” till för vanliga... Det ska inte vara krångligt, det ska vara lite intuitivt, och det ska vara självlärande, att lära sig med, att faktiskt komma med förslag till mig – och det ska vara väldigt enkelt, och sen det ska vara, ett, ett... Det ska vara SNYGGT. Allt, vi människor tilltalas av någonting som är roliga färger, lite rundare kanter än fyrkantiga kanter, det är lite att när man öppnar det så blir man lite gladare... Det låter korkat på en nivå, men jag vet nästan alla som {inaudible}, som jobbar med grafisk design och utvecklingsdesign, tittar just på det här – att tilltalas av någonting som man vill kunna komma tillbaks till. Så ”användarvänlighet” är inte bara för mig att det ska vara ett UX som är enkelt att komma fram till – det ska också se jäkligt bra ut och vara enkelt och använda. Där har du ”användarvänlighet” för mig.

P: Jaja, tack så mycket, tack för den... för det svaret. Okej, så det känns som att du har överlappat mycket på, hehe, på de frågor som jag tänkte ställa från början.

X: Jaa.

P: Men det är jättebra, det är jättebra. Det är precis det jag är ute efter. Då ska vi se här... Förresten, kan du se min video?

X: Yes.

P: Okej, perfekt. Då kommer jag snart ta upp en fråga var jag också visar en bild.

X: Okej.

P: Så okej. Jag ska se till och dela min skärm nu, och ta upp den bilden... Och bilden har vi här. Share screen.

X: Nu ska vi se nu står det ”started screen share”... Nu ser jag den.

P: Okej, perfekt. Så, Dessa... Jag kommer att ställa två frågor. En fråga har att göra med den här bilden, och en annan fråga, har att göra direkt med CodeScenes egna dashboard. Dessa frågor kan kanske kännas lite flummiga men det är meningen. De är väldigt öppna och ALL, all form av input kan vara av värde. Så, på bilden har vi tre olika dashboards, som då markeras med hjälp av lila rektanglar. Vi har bild nummer 1, 2 och 3. Finns det någonting som du direkt gillar, ogillar med bilderna? Finns det kanske någonting som du blir inspirerad av, och som du kanske hade velat se i CodeScene som du ser här på bilderna, som inte finns idag? Ja det är som sagt en väldigt öppen fråga men jag vill helt enkelt bara höra dina åsikter kring bilderna - vad du tycker.

X: Nu ska vi se... Bild nummer 1, 3:an står ingen, 3 någonstans, jo där står 3:an där, där nere. 3:an ser ut som en klassisk financiell, ”financial report” bilden kommer från [namn] som jag använder lite av i arbete – lagom intressant. Men har oftast mycket data. Det är gärna sånt jag inte hade satt på min dagliga interface till verktyget, det är sånt jag hade kunnat få en gång varannan vecka – på en overview rapport som jag kan klicka mig in i. Det är ingenting som är, som jag hade jobbat med som en dashboard i mitt dagliga... det hade inte sett... överhuvudtaget. Nummer 2 är intressant! Just det här med gröna flaggningar/varningar, new bugs... Nu är ju detta helt och hållet på en utvecklarenivå, att man ska titta på hur många bugs, vulnerabilites och så vidare. Men om detta kunde omformas till att, på en VD-nivå, titta på andra saker, som att okej, detta är inte bugs, men detta ”new dangers”, ”new slowdowns”, ”new functional deviance”, ”new scope creep” och så vidare, som hade kunnat kopplats till business impact för mig, så är det ju någon – nummer 2 som jag hade tyckt var absolut bäst för en daily view. Nummer 1, det är inte speciellt mycket kommentarer. Så nummer 3 – mycket mer en konsoliderad financial report som jag känner igen, som vi jobbat med idag, men ingenting som jag velat jobba med en daglig dashboard. Nummer 2 ja om man hade, skräddarsytt om det till att det var nått som passade min vy istället, för jag är inte så intresserad av ”vulnerabilites” och ”bugs”. Jag är på nivån över, vet du – ”vad betyder egentligen detta för projektet”.

P: Ja, precis. Okej, tack för det! Och nu kommer vi då till sista frågan, som har direkt, att göra med CodeScenes egna dashboard. Så jag tar och öppnar upp ett projekt som jag har här. Så du vet ju säkert hur dashboarden ser ut, om du nu...

X: Yes.

P: ...Använder CodeScene, dagligen. Vad har du för tankar kring hur dashboarden ser ut. Är det någonting du tycker saknas? Vad tycker du om att dashboarden är fast på en plats, att det inte finns så mycket anpassningsmöjligheter – vad har du för tankar kring CodeScenes dashboard? Vad ser du för förbättringar – vad hade du velat se annorlunda?

X: Hallå.

P: Hallå hallå?

X: Nu hör jag dig igen. Du försvann lite grann där.

P: Aha, okej.

X: Vad jag tycker, jag kan säga så här mycket, det är, ännu en gång, det är väldigt, det är ju väldigt mycket bättre än när vi började jobba med det – det är ingen snack om saken. Men ännu en gång, jag saknar, ännu en gång, på den nivån som jag ska nu antagligen representera, som är beslutsfattare-nivån som håller i plånboken, så är det för mycket.

P: Mm.

X: Det är för mycket – det ska, okej, det är jättebra att vi har ”key personnel” och ”development costs” och ”interactive hotspots map” och så vidare, men jag skulle väldigt gärna vela knyta det till ett steg upp som att ”okej”... {inaudible}

P: Hallå? Du försvann... där ett tag. Jag hör ingenting.

X: Hallå?

P: Hallå? Nu hör jag dig, ja?

X: Asså egentligen en konsoliderad nivå, lite högre upp än denna – en enkel dashboard som visar ”Projekt A är på väg att lyckas – du kan somna om, det är Grönt”, eller ”Projekt A är Gult, dubbelklicka ner för att se vilken business impact som är till skada, eller i risk, och dubbelklicka en gång till för att veta vad jag borde/vilka frågor jag borde ställa just nu, för att få detta trackat rätt. Eller det är Rött – du måste göra detta nu direkt. Det är lite grann på den nivån istället för den här... sen skulle jag då kunna dubbelklicka vidare mig hur mycket jag vill och kunna ta ut detta här (CodeScenes dashboard), men för mig, som beslutsfattare, som inte har den tiden/intresset att lägga i... och om man nu vill attrahera mitt folk, min sorts roll, så är detta för komplicerat... eller inte komplicerat, det är inte så komplicerat, utan för detaljrikt, det är för många knappar att skruva på för att jag ska kunna få en överblick.

P: Ja. Ja okej [namn] tack för dina svar! Det var jättebra svar...

X: Det är inga problem. Tack så mycket och lycka till.

P: Det är precis det som jag tänkte... var problemet.

X: Bra! Där är problemet med usability-sidan för jag tror att man får segmentera ordentligt vilka sorts användare vill du locka till på vilka, och sorts funktioner och vyer – och utifrån det så måste du förenkla.

P: Ja. Definitivt. Yes, ja okej.

P and X thank each other and say their farewells.

12.6.2. Protocol 2 The interview starts and X grants permission to record the interview.

P: Intevjun är uppdelad i två delar, varav den första delen då, kommer att vara den här videon som jag spelar upp – en 6-minuters video där jag snabbt går igenom lite, CodeScene, några funktioner, visar vad det är. Och direkt efter påbörjas då del 2 – där jag har några förberedda frågor. Någon fråga kan kanske röra till något jag gör i videon, men de flesta frågor är rätt så öppna och... Det är bara att reflektera och ge input så blir jag glad! Så Okej, jag hoppas du är bekväm [namn], så ska jag ta och starta videon nu.

X: Ja.

Some technical difficulties occur, and the problem is shortly resolved.

*The video plays*

P: Okej, så det var videon – jag hoppas att den i alla fall var lite hjälpsam. Okej, så då går vi över till del 2 av intervjun, där jag ska ställa några frågor. Ska vi se... Jag kan stänga ner denna filen... Så skulle du kunna börja med att berätta lite om dig själv och vad din arbetsroll går ut på?

X: Mm. Jag är då en jurist som jobbar med compliance och det betyder regelefterlevnad. Så jag ska se till att företaget där jag jobbar, följer alla regler som finns. Svenska regler, interna regler, EU-regler... Allt möjligt. Och det är då både genom utbildning, genom att skriva instruktioner, genom att delta i projekt, ge råd, men också genom att kontrollera det vi gör. Och det är kanske där man har mest IT då, själva kontrolldelen, men även för att till exempel registrera incidenter som händer, övervaka, motparter från ett penningstvätt perspektiv, och så här. Så, det är ganska brett – det handlar väldigt mycket om handelsbaserade övervakningar, alltså, det [namn] i mitt fall då, handlar i form av financiella instrument och fysiska instrument – på till exempel Nasdaq och andra börser, för det financiella, och [namn] till exempel motsvarighets på den fysiska sidan, och där handlar man med [namn] istället. Och då har vi ju handelsövervakningssystem som då fångar upp förhoppningsvis, om det är någon marknadsmanipulation.

P: Okej, tack, tack för det svaret. Intressant, väldigt intressant. Så okej... Här kommer då en fråga som har lite med videon att göra och... ehm... så baserat på videon, vad tyckte du stod ut mest i verktyget, och varför?

X: Det är ett väldigt visuellt verktyg, så det är förmodligen lätt att, för att säga, upptäcka var man börja göra någonting eller vad man bör åtgärda. Sen vet jag inte om det bara är det den gör liksom, eller om man har själva åtgärdandet också i programmet. Och sen har jag väldigt difust uppfattning om vad det liksom kan vara för mjukvaruproblem som det här ska upptäcka. Är det liksom typ virus och såna där saker, och hot, intrång utifrån eller också, ehm... att ett system inte fungerar så bra på grund av att man har gjort en ändring i ett annat system, som det är ihopkopplat med, och så alltså... Jag är väldigt så här difust bild av vad det är den upptäcker för problem egentligen.

P: Mm. Okej, tack, tack för det. Så... Hur relevanta var de presenterade funktionerna i videon för din arbetsroll?

X: Jag skulle säga att det är relevant för företaget, för IT-avdelningen, liksom att ha någon, ehm... form av såna analyser eller sånt här system, och där våra liksom applikationer, och koder som vi använder också, ingår. Jag tänker då framförallt på handelsövervakningssystemet, som är det mest automatiserade kanske, {inaudible} utan att det bara liksom, JIRA, och Excel, applikationer. Och sen handlar det om algoritmer också, där har vi ju, lite motsvarande kan man väl säga i botten, att det finns säkerhetssystem som känner av, heartbeats från algoritmerna som är igång, och man kan ha... liksom olika popup- meddelanden och automatisk avstängning om vissa saker inträffar och sånt där. Jag ser ju inte att compliance-avdelningen i sig skulle ha sånt här system, men vi är ju intresserade av att allt i verksamheten är ”up-and-running”, så vi är intresserade av att det finns ett sånt system hos IT-avdelningen. Men inte att vi skulle ha det själva.

P: Okej, så, om jag kan ställa den här frågan: Det finns alltså ett visst intresse, ehm... att se till att mjukvara innuti organisationen fungerar som det ska, för du berättade någonting om algoritmer och heartbeats, att man på något sätt monitorerar att algoritmer faktiskt fungerar.

X: Ja det finns ju andra exempel ocskå, vi har ju till exempel inspelning av vissa telefoner, och det är ju viktigt också att känna av att den inspelningen fungerar med jämna mellanrum, så att det inte alltså, det helt plötsligt upptäcker att den där programvaran har inte gått på ett tag och vi har inga inspelningar.

P: Ja.

X: Så det finns ju lite såna här olika, olika... System som däri är intressanta att ha koll på.

P: Okej, tack, tack för ditt svar. Så... Den här frågan kanske överlappar lite med den förra frågan, men, mm... Vad är dina generella tankar kring designen i CodeScene – den visuellmässiga aspekten av CodeScene?

X: Ja men det såg enkelt och lättanvänt ut. Man liksom, kunde bara klicka och, ehm... visualiseringar av hur stora problemen var och... även sånt här koncentrationen av utvecklare, per mjukvara och sånt här. Så det såg väldigt lätt använt ut.

P: Okej, tack. Ehm... Och... Så om vi då tänker utifrån din arbetsroll, vilka förbättringsmöjligheter ser du i CodeScene, vad hade du velat implementera i CodeScene – som hade då kunnat hjälpa dig i ditt arbete?

X: Ja men det skulle väl vara att få en trygghet i att såna saker fungerar, som algoritmerna, handelsövervakningssystem, att de inspelade telefonerna, det finns säkert andra exempel också fast jag inte liksom har i huvudet just nu... Och sen det här med att se beroende av nyckelpersoner kan också vara, väldigt viktigt. Däremot även om det är en person som har utvecklat allting så har vi alltid, så att säga en ”four-eye principle” – innan det sjösätts ska någon annan verifiera det, och den personen syns kanske inte i, ert program. Men det hade

85 kanse varit bra, att ha det inlagt också, att här har vi haft... Här är person nummer 2 också inblandad och har kvalitetskontrollerat det här, så att man ser att... Ehm... Det här att mäta arbetseffektivitet på, hos anställda är däremot inget man kan göra, framförallt inte i vårt företag som finns i Tyskland, också, där... det strängligen förbjudet att mäta anställdas prestationer... Någonting som måste godkännas av fackföreningarna i sån fall – och det gör de inte.

P: Aha, okej.

X: Så just den funktionen skulle vi inte ha någon nytta av.

P: Ja, okej, tack för det svaret. Ett jättebra svar. Om vi säger så här: Information och hur det presenteras – information kan presenteras i olika former, till exempel text-form, diagram, cirklar – som vi har sett i CodeScene, olika former av tabeller. När det kommer till din arbetsroll som complianceansvarig – hur vill du helst att information ska presenteras för dig? Och då tänker vi då ur ett mjukvaruanalysverktygs... Som CodeScene till exempel, hur hade du velat att informationen ska presenteras för dig – i vilken form och varför?

X: Jag tror att, som en sån här första bild, så är det grafiska väldigt bra – det här där du ser stora eller små cirklar, och vad det nu kan va. Men sen bör du nog kunna - liksom klicka på det och få upp en textinformation som säger lite mer om vad det här innebär. Så det skulle vara två olika nivåer som jag ser det... Som man bryter ner i. Och de här illustrationerna, diagram och heatmaps, och sånt här, det är också väldigt tacksamt att ha med i rapporter, som när vi ger rapporter till ledningen. Så är det ju bra att kunna ta med bild som visar status på olika saker. Det brukar de tycka om istället för text, sen måste det naturligtvis vara en liten förklarande text, men... Ehm... Men det är bra med bilder, men sen beror det också på hur mycket skulle vi göra med det – förmodligen skulle vi bara ha det här för att identifiera ett problem, som vi sen liksom... Ehm... Informerar IT-avdelningen om då. För det är inget vi skulle åtgärda själva, utan vi skulle ha det för att uppmärksamma problemet, och kanske för att få pengar i en ”select-and-authorize”-process att, göra vidareutvecklingar, göra något åt det, eller byta system, eller vad det nu kan handla om. Så vi behöver kanske inte så där vansinnigt mycket information – utan mer liksom... Att vi uppmärksammar vad problemet är.

P: Okej, tack för ditt svar. Så, för att förtydliga – Så, när du pratar om det här med nivåer, till exempel två nivåer, för din arbetsroll så som du ser det ur ditt perspektiv så hade det nog varit jättebra att ha ett väldigt... en väldigt hög-nivå i verktyget på informationen som presenteras, så det kanske inte är så nödvändigt att ha alla de här tekniska grejerna som... det finns problem i kod A på rad 30 till 43... utan du vill mer... Du hade mer velat se det på en mycket högre nivå än det. Till exempel att: Vi har ett problem. Och problemet är lokaliserat här. Sen kanske ni kan ta den informationen och gå vidare till IT- avdelningen med den informationen, eller kanske istället för det ha, liksom en ”Okej”-symbol, allt är okej, finns ingenting att oroa sig för. Är det lite mer åt det hållet som du hade velat se det?

X: A precis. Var i koden det finns eller egentligen... {inaudible} närmare i vilket system är inte så intressant, utan bara att det finns ett problem, ja inom vilket system för att veta vem som är ansvarig för det då, och vad kan det få för

86 konsekvenser är också viktigt. Så jag kan bedöma om det är en risk som man ska... utreda eller inte.

P: Ja precis. Okej. Tack, tack för det. Hur hade då – Hur hade det perfekta mjukvaruanalysverktyget sett ut enligt dig? Och du kan vara hur kreativ du än vill – det finns inga... ingenting som är omöjligt.

X: Ja... Då skulle jag väl kunna ha en vy där jag bara ser de system som jag är intresserad av. Och... kanske... A men på något sätt se om det är några problem med de, eller interaktionen mellan dem... Och så skulle jag ha information om vem jag ska kontakta om det är problem. Fast egentligen är det ännu bättre om... A, jag vill ha information om vem som ansvarar...

*Interruptions with the internet connection*

X:… Till det direkt utan att jag behöver, blanda mig i. Så en alert som går till IT- avdelningen när någonting händer, och en alert som går till mig, liksom, så jag ser och kan följa upp med IT-avdelningen att de har åtgärdat det. Information om hur allvarligt det är, som sagt så att man vet hur snabbt det måste åtgärdas, och hur mycket resurser man ska lägga på det...

P: Okej, tack. Tack för det svaret – perfekt.

X:... Och så att man ser också, det kan gärna skapa något litet ärende, så att sen när det händer någonting, när det blir... att det blir en alert av det – inte bara att jag går in och kan se att någonting är fel – utan att det gärna blir en alert så att jag uppmärksammas på att det är någonting fel.

P: Okej.

X: Och sen också att det kommer en... en ny notifiering när det är stängt och åtgärdat och funkar som det ska igen.

P: Okej, ja, perfekt - tack för ditt svar. Jättebra svar. Okej. Så... Vad är då din... vad är din definition av ”användarvänlighet” – när det kommer till mjukvaruanalysverktyg?

X: Ja... Det är ju även att jag som jurist ska förstå det. Så det ska inte vara massa kodsnack och IT-tekniska termer och så där, utan... Jag vill veta att nu är det problem med telefoninspelningen, det spelar inte in längre. Sen får liksom IT-teknikerna kolla vad det beror på, och vad ska fixas, och... Så där. Så jag vill ju ha... A men, på ett språk som jag förstår helt enkelt – det behöver inte vara detaljerat och ingående.

P: Okej, perfekt. Tack för det svaret. Då är jag lite intresserad också av att... få veta, om... dina tankar kring anpassningsmöjligheter – att kunna ändra antingen på hur – i vilken form saker presenteras, eller kanske i vilken ordning som saker presenteras i, eller kanske som du sa – det här med alert. Kanske kunna ändra det till ditt tycke på olika sätt. Vad önskar du att ha för anpassningsmöjligheter i ett mjukvaruanalysverktyg – vad önskar du att se?

X: Egentligen så... Ehm... Så ser jag ju för mig att det här verktyget finns på IT- avdelningen, och sen, någon... Skulle jag kunna liksom klicka i vilka system jag är intresserad av, och få en alert när någonting händer i de, så att jag egenltigen inte behöver gå in i systemet eller så där, utan det är liksom det verktyg som IT- avdelningen som IT-avdelningen användender för att prioritera deras arbeten, spara kostnader och sånt där. Jag vill egentligen bara ha... veta om någonting går fel.

P: Okej, ja, tack, tack för det svaret. Så... Okej så... Ifall ett sådant verktyg hade fungerat på ett så bra sätt att du hade kunnat använda det, och det hade då sett till att alla dina... Krav kan uppfyllas, men även att en IT-avdelning ska kunna använda verktyget, och då vara lite mer detaljerat och tekniskt – då finns det ju, i detta här exemplet, egentligen två arbetsroller, eller ja, låt oss kalla det för arbetsroller: IT och complianceansvarig som då hypotetiskt ska tillsammans kunna ha användning av verktyget. Men då finns det ju också, låt oss kalla det för problem – det finns ett problem att det finns olika målgrupper, och olika målgrupper kan ha olika intressen. Så hur hade du då velat att ett mjukvaruanalysverktyg hanterar olika arbetsrollers intressen?

X: Ja... Det är ju väl egentligen att systemet, programmet ska innehålla all funktionalitet som både IT vill ha, och som jag vill ha – men ska man kunna på något sätt kunna filtrera sin vy så att man bara ser det man själv är intresserad av och kan få ut någon rapport som man själv är intresserad av.

P: Ja okej...

X: Jag tror bara det handlar om vilken användarvy man har.

P: Ja. Så – abstraktionsmöjligheter, lite enklare förklarat – abstraktionsmöjligheter...

X:... Jag tror inte det är några konflikter egentligen att någonting de vill ha, någonting jag vill ha liksom står i strid med varandra. Utan det är nog bara mata in allting och låt oss titta på det vi vill.

P: Ja okej. Perfekt. Så... Okej... Om du hade behövt nämna två visuella egenskaper som du önskar ha med i ett mjukvaruanalysverktyg – vad hade du då svarat?

X: Jag tror jag skulle... Vilja ha någonting som kan jämföra över tid – man ser om ett problem har blivit större eller mindre. Och... A men någon form av påverkansgrej så man ser vad ett problem påverkar. Att det påverkar den här och den här funktionaliteten, eller det här och det här... Processen eller vad det nu kan handla om.

P: Mhm. Och om jag kan då bara ställa en liten snabb följdfråga – Ehm... Hur hade du då önskat att det hade sett ut, rent visuelltmässigt, den här jämförningsfunktionen över tiden, till exempel, där man ser att ett problem antingen har minskat eller ökat, eller vilken påverkan det har, på till exempel det financiella... Hur hade du velat se det? Är det kanske i textform? Eller är det

88 kanske någonting liknande det som finns i CodeScene med cirklar, eller, hur hade du önskat se det?

X: För förändring är väl... En graf ganska bra, för då kan man verkligen följa förändringen dag för dag, så att säga, annars hade man också kunnat tänka sig någon cirkel- eller stapeldiagram så att du ser liksom att det har gått från det här, till det här – på tre månader. Men då ser du inte, liksom exakta variationer – så en graf är kanske det bästa.

P: Okej, tack. Så okej, nu har vi då kommit till de två sista frågorna i intervjun. Och dessa frågorna är kanske lite annorlunda på det sättet att de är väldigt öppna och... Ehm... Man hade kanske kunnat säga att de är lite flummiga till och med, men det är ju meningen med dessa frågorna, meningen med dessa frågorna är att, du ska kunna brainstorma lite och bara säga liksom precis vad du tänker på, kanske vad du känner, och, och så vidare. Så jag vill bara höra dina åsikter i vilken form de än kommer i. Så den första frågan har att göra med en bild som jag har framställt här. Jag ska se till att dela den.

*Shows the picture*

P: Där. Okej, kan du se en bild? Av tre olika dashboards?

X: Ja.

P: Ja? Perfekt. Så... Den här bilden består då av tre olika dashboards i olika typer av program... Det är nödvändigtvis inte jätte-intressant att på bild nummer 3 här borta, att det kanske står ”Catering”, ”Cargo” och ”Passenger”. Utan, det som är mest intressant är hur programmet ser ut, och vad för typ av information du kan tänka dig att du kan få ut, från de olika dashboardsen. Så... Finns det någonting du gillar, kanske ogillar, med bilderna? Finns det kanske möjligtvis någonting som du hade velat se – som du hade velat ha användning av i ett mjukvaruanalysverktyg? Finns det någonting du tycker är helt tokigt, och någonting som du inte alls hade velat se? Kanske någon vy som du direkt känner att ”Nej, det här är ingenting jag hade velat se”. Men sen kanske det finns en vy där du tänker ”Ja, det här är ändå nära till det som jag hade velat se, därför att...” Jag vill ha lite mer input kring det hållet – vad du tycker kring, kring de olika dashboardsen...

X: Jag gillar de två översta (picture 1 and picture 3), rent så här visuellt. Den till vänster (picture 1) känns mer som ett ärende-hanteringssystem, och den till höger (picture 3) känns mer som en rapport. Så det beror lite på vad man ska ha det till. Men båda de var snygga, överskådliga och... Användbara. Men jag tänker mig någonting som den till vänster (picture 1) får ha liksom en överblick över ”Okej, är det någonting som händer?”, ”Vad gör vi åt olika saker?”, och så drar man ut en rapport som ser ut ungefär som den till höger (picture 3), när det är dags för kvartalsrapport för ledningen.

P: Okej, perfekt. Så bilden till vänster (picture 1), är det enkelheten i den bilden som du gillar? Liksom att det inte är för mycket information, att det inte är för lite information, utan att det, det känns okej, det känns som någonting jag kan jobba med... Eller vad är det som är så bra med den bilden?

X: A men den känns väldigt överskådlig, och... Enkelt och det känns... Det känns som att en levande bild som hela tiden, liksom stapelna kan gå upp och ner, och bilderna kan svänga, och så här, medan den bilden till höger (picture 3) den känns mer som en statisk grej, som man får ut vid något tillfälle då och då, men den till vänster (picture 1) ger en mer överblicksbild av...

*Interruptions with the internet connection*

P: Nu tappade jag bort dig där i en stund. Jag kan inte höra vad du säger – nu hör jag vad du säger.

X: Okej jag sa att den bilden till vänster (picture 1) känns mer som en vy man ska ha när man arbetar med det här, som sin överblicksbild, som ständigt uppdateras – och den till höger (picture 3) ser mer ut som en... A en rapport som man får ut en gång var en månad, eller var tredje månad, eller vad det nu kan vara för att mer dokumentera, vad som har hänt.

P: Perfekt. Tack för ditt svar. Ett jättebra svar. Okej så nu har vi då kommit till den sista frågan i intervjun. Och den här frågan är också öppen, väldigt öppen. Och det har att göra med CodeScene dashboarden, så jag tänkte dela min skärm en sista gång och visa hur dashboarden ser ut i CodeScene idag.

*Shows the dashboard*

P: Klickar vi på projektet så kommer vi till dashboard. Så här ser då dashboarden ut just nu i CodeScene. Det finns lite notifikationer, kodhälsa, sen finns det ju också lite andra saker som man kan se, men då behöver man integrera verktyg som JIRA och så vidare. Men... Nu har jag då scrollat till botten, och det är liksom det som finns i dashboarden idag. Och jag vill helt enkelt höra dina tankar. Vad tycker du om den här dashboarden, är den bra, är det någonting du hade velat se, finns det liksom någon information du gillar, om inte – var kan då problemet kanske vara, och hur hade du velat ändra det så att det passar din arbetsroll mer?

X: Jag tycker det ser bra ut – inte som... En förbättring hade väl varit att ta bort mycket av det så att man inte behöver scrolla, utan man ser det man vill ha uppe på skärmen utan att behöva scrolla. Också kan de man inte har öppna vara som små ikoner där uppe så att man lätt kan klicka upp de...

P: Okej.

X: ...Istället.

P: Ja okej, tack! Tack för din input. Det var sista frågan i intervjun. Jag måste säga att jag fick väldigt bra input.

P and X thank each other and say their farewells.

12.6.3. Protocol 3 The interview starts and X grants permission to record the interview.

P: Intervjun är uppdelad i två delar. Den första delen är då den här videon jag pratade om igår, jag kommer att spela upp en 6-minuters video var jag går igenom några funktioner i CodeScene, jag visar lite vad som är möjligt i CodeScene, och hur CodeScene kan användas i en organisation för olika syften. Därefter kör vi igång med del 2 och det är en vanlig semi-strukturerad intervju var jag har förberett ett par frågor, och helt enkelt... Frågar dig lite olika saker. Jag hoppas det låter bra! Om det låter bra så ska jag ta och dela videon, och starta igång den.

X: Det låter bra.

*The video plays*

P: Okej, det var videon. Jag hoppas att den var i alla fall lite användbar. Just det, jag har även CodeScene uppe på datorn i bakgrunden, så är det så att du skulle vilja, någon gång under intervjuns gång, titta på någonting igen, och så vidare så är det bara att säga till, så löser jag det.

X: Yes.

P: Okej. Då kan vi gå över till frågorna nu, i så fall.

X: Mm.

P: Kan du börja med att berätta lite om dig själv och vad din arbetsroll går ut på?

X: Jo, jag är då en CFO, och... För ett techbolag då. Och, som tränar finansbakgrund, så ja. Så, tyckte jag att det här lät intressant, med tanke på att jag liksom, på något sätt ville förstå, eftersom man inte har då den {inaudible} bakgrund – normalt sätt brukar jag då, som kommer från finansvärlden, förklara för andra som inte då har finansbakgrund eller ekonombakgrund, då är det typ okej, nu ska jag förklara det här så att du kan förstå – varför, våran ”P&L” balansräkning och så, i bolaget, och varför vi måste göra si och så när det gäller likviditet, och så vidare. Ehm... Men jag hade själv svårt att förstå, liksom, hur kan jag påverka det som egentligen är vår största – både investering och kostnad, vilket då liksom, ja, utvecklingskostnader då.

P: Mhm.

X: Så att... Min bakgrund, om man säger, är egentligen finans, och även inom, hur ska jag säga, rådgivning, advisory, och ja – den typen av verksamhet då.

P: Okej, tack. Ja – intressant, intressant, det här med...

X: Så för att om man säger från forskningsperspektivet du tänker på det som, som en student, så tänker du att... Min teoretiska bakgrund är, och teoretiska

91 grund är liksom ekonomi och finans. Och, på senaste tiden då, har jag då, mitt, så att säga mitt objekt – har då varit IT-bolag.

P: Ja.

X: Styra IT-bolag.

P: Okej.

X: Innan har ju objektet varit att styra konsumentföretag, som i för sig investerar väldigt tungt i IT, men mer i den formen av IT som gör att kunden använder olika former av applikationer – som då givetvis kanske utvecklas av andra, men om du jobbar för ett IT-bolag så utvecklar du egna, ehm... Och då blir det lite annorlunda. Det är därför jag tycker att det här verkar intressant.

P: Ja.

X: Men det förstår du ju säkert eftersom du... Jag tror du vet vad du gör.

P: Ja. Jaja! Tack för den bakgrundsinformationen, ehm... Jättebra, att, att veta. Ja det är intressant det här med utvecklingskostnader för, för utvecklingen är ju en så pass abstrakt grej, att det är svårt att kategorisera eller analysera och så vidare, ibland, i vissa aspekter av mjukvara, så ja... Definitivt.

X: Mm.

P: Okej, baserat på videon – vad tyckte du stod ut mest i verktyget, och varför?

X: Ehm... Det som jag kommer ihåg mest var att det var cirklar, överallt. Sen kände jag att det var ett fokus på ”Key employees”.

P: Ja, okej.

X: Ehm... Sen vet jag inte om du ställde frågan vad jag inte, det var en sak som jag tänkte att jag inte såg, men som jag funderade på, men – det som, det som jag såg, a, ett slags dashboard var det ju.

P: Mm. Ja.

X: Av, performance, i, i... A, kod – helt enkelt.

P: Yes, ehm... Okej, tack för det. Ehm... Så... I fall vi, tänker tillbaka till, några av de funktionerna som jag då visade upp i videon, i verktyget. Ehm... Hur relevanta var de... Var de presenterade funktionerna för din arbetsroll?

X: Det jag tyckte var intressant, det just det att om man då letar efter ”key-employees”, det var ju de som jag tog med mig. Att... Man... På ett sätt tror jag att man vet väl kanske vilka som är key-programmers liksom, men frågan är om det stöds av data då. Det är ju intressant att se. Så det är min key- takeaway att, ehm... Jag hade ändå ett hum om vilka som var våra key- developers, asså, genom att man bara pratar om det, men jag hade inget papper på det – ingen data på det.

P: Ja, precis, precis... Okej.

X: Om man ser värdet, det värdet som jag ser just nu är att {inaudible} man kanske data på vad värdet av individer är, och...

P: Ja, jaja... Perfekt. Okej, om vi nu tänker... Ur ett designperspektiv... Vad är dina generella tankar, kring designen som då finns i CodeScene?

X: Ehm... Designen var väldigt ”soft”, den var väldigt, den var inte för stark eller skrikigt på nått sätt, utan ehm... Jag ska inte säga otydlig, men den var ju väldigt... {inaudible}... det var ingenting som stack ut egentligen.

P: Okej. Ehm... Fanns det någonting i designen som du inte gillade, kanske någonting som du upplevde som negativt, och då tänker jag mer utifrån perspektivet utifrån din arbetsroll – om du nu skulle använda CodeScene i ditt arbete. Fanns det någonting i designen som du tyckte, inte stämde överens med hur du, vill att saker ska se ut?

X: Jag tänkte mest spontant först på – det finns säkert i produkten, eftersom jag inte använt den, det får du ju svara på i så fall, men just att man kanske då, trycker på, vad du fokuserade på en person, men att man tänker per projekt – per utvecklingsprojekt då.

P: Mhm.

X: Ehm... Att det tydligt kom fram vilka, för det är ju oftast – pratar man om vilka projekt man jobbar med. Utvecklingsprojekt. Och någonslags timeline på utvecklingsprojekten – var är de någonstans? Var ligger själva projektet – hur många procent ”completion” är utvecklingsprojektet, ehm, ligger vi på liksom.

P: Ja, ja, okej, tack, tack för det svaret. Ehm... Så... Det här är kanske, det överlappar kanske lite med föregående fråga, men navigeringen – navigering är ju en viktig aspekt av alla möjliga sorters program. Vad tyckte du om navigeringen i CodeScene?

X: Jag har ju inte provat den själv, men bara av att titta på den, så var det hyffsat enkelt, men som sagt... Man ska inte förenkla för mycket heller. Ehm... Jag personligen är väldigt, väldigt... Jag gillar ju tables till exempel, men det kanske också är att jag har en viss forskningsbakgrund också ju. Man kan görta mycket med det också, tables. Allt behöver inte vara runt – cirklar. Men det beror på vilken, säga... publik du ska ha, men... Ekonomer är ju inte alltid jätteglada i piecharts, till exempel.

P: Ja, okej. Tack för det svaret. Ehm... Okej. Då kommer vi kanske till, till en lite mer intressant fråga – Utifrån din arbetsroll, hur... kan du nämna och förklara vad du hade velat se i mjukvaruanalysverktyg, vilken typ av information, vilken form den här informationen skulle kunna ta, och så vidare. Vad är det liksom du, som CFO, vill ha i ett mjukvaruanalysverktyg?

X. Ehm... Ja, det är ju egentligen, en, en... Då tittar man tittar på avkastning då – i de här produkterna, och det kanske det är så att om man då har en

93 produkt, som är... i ett projekt, så om man då utvecklar har man kanske en grundbas, men man måste göra vissa, ändå, typ av customization för kunden. Så vore ju bra att se, asså return on investment givetvis. Ehm... Per projekt – för det kan ju finnas så... det kunde ju varit roligt att kunna länka det till själva spacet av projektet också, för det är ju det som kan ställa till ibland att man inte har en, en, den här kravspecifikationen som är förväntad av kunden – är den... är den rätt så att säga? Ihop med den format av utveckling som faktiskt ska göras? Förstår du vad jag menar när jag säger så eller ska jag utveckla?

P: Ja, nej, nej det är bra. Så... Kan man, hade man kunnat lägga fram det på det sättet att – return on investment, i olika aspekter av mjukvara... Låt oss säga – vi har en applikation, ett projekt som utvecklas, och – det finns till exempel förbättringsmöjligheter i, i projektet... Och dessa hade till exempel kunnat presenteras i ett mjukvaruanalysverktyg för, för någon som då besitter en CFO... en CFO plats.

X: Ja, det man skulle kunnaa göra också är att – det skulle vara intressant att se ett ”norm-projekt”, som så här har ett historiskt data på vad du har, låt oss säga vad du har gjort i 100 projekt innan, och de tar ungefär så här lång tid, ehm... det finns ju, i alla fall det som jag har varit med om är ju att man kanske har någon liknande grund, och sen har man, får man customization – och sen så, är det ju intressant – en del projekt går fort att implementera, och en del tar längre tid.

P: Mhm.

X: Så det kan ju också vara en intressant parameter att titta på.

P: Okej.

X: Att ha, har du tracking av, något slags norm-projekt så har du ju, det betyder inte att det är jättebra, men norm... brukar man liksom, ta bort de projekten som kanske då, är outliers, har varit kanske kaos, som inte haft, funkat alls.

P: Ja, precis.

X:... Och några projekt som gått alldeles för enkelt, och har varit bara... liksom plug-and-play – så har man ju någon slags förväntning på hur den här – provisionen på ett normalt projekt, liksom.

P: En referenspunkt?

X: Ja referenspunkt, jag skulle kallat det normprojekt, liksom.

P: Mhm. Okej. Så... Då ska vi se här... Ehm... Så om vi då tänker tillbaka igen, på ett mjukvaruanalysverktyg – hur hade du velat se att information presenteras, utifrån din arbetsroll?

X: Men jag tror att det är väldigt individuellt, så att, jag tror att det skulle bara vara så att man skulle själv kunna välja vilka sidor man själv vill se. Asså man har ett smörgosbors av olika dashboards, och så kan man klicka i och säga ”jag vill se de här sakerna” – jag vet inte om du jobbat med ”Qlik View” till exempel?

Som är ett, så att säga – financiellt tool, eller ”Qlik Sense” som är mer ett avancerat tool, och man kan då, i real-tid kan man se detta eller real-tid också.

P: Så, anpassningsmöjligheter, tänker du?

X: A, mm.

P: Ehm... Ja definitivt. Tack.

X: Använder ni själv detta, i... låt oss säga, i egna så att säga – för att se hur effektivt CodeScene är, själva? Använder ni er själva av det – produkten?

P: Menar du på universitetet eller?

X: Nej, på CodeScene.

P: Jag, jag jobbar inte för CodeScene, utan – jag är student på Malmö Universitet...

X: A, men jag frågar om de på CodeScene använder det?

P: Ja, ja det gör de – inte alla roller... Just nu så använder, så använder... endast utvecklare det på CodeScene, och – ja. Det är ju liksom det som är primära målgruppen.

X: Så primära målgruppen kan man säga idag är, detta är – i ett produktutvecklingsbolag då, kan man säga? I en, som du, ehm... Låt oss säga du är chef över produktutvecklingen?

P: Ja, precis... precis.

X: Och då är det ju ett verktyg som du absolut skulle ha liksom.

P: Ja... ja.

X: Men frågan är, hur skulle andra användare kunna använda detta?

P: Ja, precis.

X: Jag tror att den som använder... den som sitter på en produktutvecklingschefs-stol är ju mer mån om att se hur alla presterar som jobbar där givetvis, i projekten, jag tror att det är därför jag fokuserar mer kanske på, om man ska kalla det ”business-caset”, eller vad man nu har haft till exempel innan. Det skulle också vara som en – från det finansiella perspektivet så är det ju, lite där jag kommer in på norm-projektet, så att det är... Någonstans har man ju sålt det här projektet, eller hur?

P: Mm.

X: Och ni har sålt in ett projekt, {inaudible} ansett ett projekt, att man ska utveckla någonting. Ehm... Och det är ju någonting som jag skulle vilja se – hur det är ”connected” till själva business-caset som har blivit, ehm, approved då.

För det är ingenting som egentligen ska ha startats utan att det har blivit approved, att man vill ta sig an på det.

P: Mm.

X: Och det är kanske en ovanlig koppling som man glömmer bort, utan, när man börjar med någonting så vill man ju jobba med det.

P: Ja, ja...

X: Men man glömmer lätt bort att – vad var, vad var det vi klubbade igenom, vad hade vi för case, vad hade vi för intäktsförväntningar av det här projektet, vad hade vi för kostnadsförväntningar på det här projektet, och... och, var ligger vi i så fall?

P: Mm... Ja precis – och när du då, menar ”var ligger vi”...

X: Hur företaget är liksom mot det, låt oss säga – hur hela firman ligger mot det, låt oss säga i detta projektet.

P: Ja, ehm... Men i det, i det här då tankesättet – ifall man då använder ett mjukvaruanalysverktyg och vill, vill se ”hur vi ligger till” just nu. Ehm, det här med referenspunkter är ju, ett väldigt bra verktyg, eller bra, ett bra sätt att jämföra hur vi faktiskt står sti... står till, idag – eller just nu. Men vad är dina tankar kring olika former av rekommendationer i, i ett analysverktyg – exempelvis då att det finns två stycken risker just nu, och, dessa här riskerna har, ehm, en sån här business impact – försämrar... ökar exempelvis X och Y kostnaderna med så här mycket, och löser ni det, så kommer då att return on investment att öka – är det, är det till exempel, rent financiellt och kostnadsmässigt rekommendationer, vad som kan förbättras i ett projekt – för att öka return on investment, olika typer av rekomendationer – är det någonting som du hade velat se, eller ha ett behov av i ett mjukvaruanalysverktyg?

X: A men det tycker jag absolut. Och, just det – att inte bara påverka asså, det, det kan påverka under tiden när {inaudible} det är ju kostnaderna givetvis. Hur snabbt kan du bli klar.

P: Ja.

X: Men du kan faktiskt påverka intäkterna, om det är så att du kan sälja upp någonting till kunden. I projektet.

P: Okej.

X: Asså, customization eller någonting som då gör – i själva projektet – och då kan det ju växa, så att säga. Och då... det är ju givetvis det är ju oftast det som man kanske då snurrar in på att, okej, så då är det annorlunda mot vad det var från början av, och då, då är det ju svårt att jämföra givetvis.

P: Ja, precis. Ehm... Så på något sätt, tänker du då, att det finns någon form av koppling till krav? I, i projektet... Till krav i projektet i mjukvaruanalysverktyget. Ehm, för du är ju lite inne på att kunna jämföra vad som godkändes, i början

96 av projektet, och, fast, ja – startpunkten, vad som godkändes, och sedan vilken väg projektet sedan tar. Då behöver man ju kunna koppla tillbaka till någonting, och jag tänker att du kanske syftar på krav i detta fall? Eller är det någonting annat du syftar på?

X: Nej, det är krav jag tänker på.

P: Krav, okej. Och sedan – till exempel att, som du då sa att ”man säljer vidare”, eller...

X: Mm.

P:... Du kanske inte sa det precis så – men att man vidareutvecklar kanske, någon ny funktionalitet som inte var planerad från början, och sen även kunna ha med det då – och lägga till det i verktyget, och se vilken business impact det hade haft. Är det lite de vägarna du är inne på?

X: Mm, absolut.

P: Okej. Ja perfekt. Ehm, så... Okej. Hur hade då det perfekta – det perfekta mjukvaruanalysverktyget sett ut enligt dig? Om du hade fått bestämma – och det finns inga liksom, allt är möjligt. Det finns ingenting som är omöjligt – vad hade du då, sagt? Hur hade ditt drömverktyg sett ut?

X: Ehm... Det är ju egentligen att det någon... att du slog på datorn liksom – sätter dig, börja jobba, och ehm... Liksom det också, någonstans, ehm... Visar då att, om vi diskuterar så – per projekt, för det är så jag har jobbat, ehm... Hålla koll på det, att man har liksom en, ja, automatiskt så att säga – har man då någon norm-kurva man kan följa, då kan man också få lite... Asså accountability, om man säger så, under tiden. ”Okej här ligger vi före”, och ”här ligger vi efter” – på dagsbasis, eller veckobasis, eller, beroende på hur långt projektet – eller hur stort projektet är. Ehm... Det skulle kunna va en, en hjälpande insats liksom. Att, ehm, ”tracka” det åt en. Men då måste man ha det som vi pratade om innan, man måste ha ”specen” klar, ja, jämföra ”speccen” (krav-specifikationer) mot vad som egentligen händer.

P: Exakt. Ja. Precis, tack för det svaret. Om du hade behövt nämna, och förklara en sak, som enligt dig MÅSTE finnas, måste finnas i ett mjukvaruanalysverktyg, vad hade du då nämnt, och varför hade du nämnt den saken?

X: Nej men, det är ju nog det jag sa först egentligen, ehm... Avkastningskravet per projekt.

P: Mhm.

X: För det är ju så här att om du kommer från ett financiellt perspektiv, så... Mitt jobb beror ju mycket på att, att, göra projektet mer lönsamt, än vad företagets lönsamhets-meta är just nu. Ehm, och då är det ju viktigt att veta att vi inte tar åt oss projekt som är mindre lönsamma än det som vi faktiskt har. Det kallas ju då ”internal rate of return” på finansspråk, då.

P: Mhm.

X: Asså att man jämför, ehm... avkastningen som vi har just nu, mot vad vi hittar på nytt.

P: Okej, ja.

X: Det är nog viktigast för mig, för det är ungefär som att, om man utvecklar någonting, att man får en varningsklocka, om, om det är så att någon klagar på din produkt. Det kanske jag inte kan göra som finansansvarig, liksom, men, om jag sitter på produktstolen, då vill jag ju höra hur användarna i så fall skulle... inte bara nöjda med en ny produkt. Förstår du hur jag menar?

P: Ja, ja...

X: Vad är det absolut viktigaste för att veta att du är på rätt väg? Och gärna då, så att det är liksom, så tidigt som möjligt.

P: Okej, okej, så...

X: Och det kan man bara göra på ett sätt – det är ju att få en indikation under projektets gång, liksom.

P: Ja, precis. Så, från det som jag då har förstått hittills, så vill man gärna ligga på, ehm, en högre abstraktionsnivå, gentemot det som kanske finns, tillgängligt, idag, i CodeScene, som då fokuserar mycket på kod... det finns fel i den här komponenten, på rad 30 till 40, och så vidare... Utan, det, det som du då är ute efter som CFO, är att kunna ha ett mycket högre, att kunna ha ett mycket högre abstraktionsnivå, i ett verktyg som det...

X: Ja.

P:... som då fokuserar på prestanda, ehm... Och innuti den här termen ”prestanda” så finns ju så klart avkastning, kostnader, olika sorters financiella, och business-impact... Insamlade. Och det ska då presenteras på ett lätt sätt, liksom – här finns en varningsklocka. Men dessa här två sakerna är kanske okej...

X: Mm.

P:... och det är ingenting som du måste oroa dig för. Okej... Ehm. Sen finns det också – den här, det här perspektivet med detaljnivåer.

X: Mm.

P: Det är ju kanske så man vill ha en dashboard – exempelvis. Som en dashboard vill man ha det väldigt enkelt. Okej – det finns två varningar. Ehm... Men vad händer därefter? Då kanske man vill gå djupare in och se – okej. Så varningen säger att, att vi har tagit på oss för mycket arbete... Och sen kanske man...

X: A.

P:... vill gå ännu längre...

X: Det är så, A – precis. Det är jättebra att du sa det, abstraktsnivå – för att min, mitt fokus som CFO är inte att gå in på detaljnivå, och, och vara produktchef, utan jag vill i så fall kunna säga ”du, du måste kolla in de här liksom bottlenecks som vi har, i så fall, de här flaskhalsarna börjar jag se här.” Vad händer? Jag kan ju ställa rätt frågor till produktchefen...

P: Ja.

X:... och säga ”Varför... Har vi ingen progression på de här två projekten?”, till exempel. Varför står de still? Eller varför kommer vi ingenstans här, till exempel?

P: Mhm.

X: Eller varför vi har ett problem med en viss kod här – är detta... Förstår du vad jag menar?

P: Ja.

X: Så att... Då... Det finns ingen mening för mig att gå in och liksom, ja... Det kanske jag bör fråga ”Har du rätt team i det här projektet?” liksom. Att strukturera om ett utvecklingsteam liksom, det är inte mitt jobb – men mitt jobb är att fråga ”Kan du leverera dessa här produkterna i tid – i ett lönsamt fashion till vår kund?”. Och då är det ju bra liksom, att, den som är, till exempel produktchef, som jag jobbade mycket ihop med – att jag kan ställa rätt frågor till den produktchefen. För det är ju inte alltid produktchefen rapporterar till CFO:n.

P: Ja, precis. Okej så... Då har vi varit inne lite på två olika arbetsroller, till exempel produktchef, CFO, och, och ett program som CodeScene, ska ju kunna då, ehm... Stödja olika typer av perspektiv och arbetsroller, olika arbetsroller har olika behov, och kan ha olika intressen av vilken typ av information som är lämplig att visa för dem. Så det finns det ju, om vi kan definiera det som ett ”problem” – det finns ett problem, med, abstraktion, av information för olika arbetsroller. Så om vi säger att vi till exempel har då – samma exempel: En CFO, och vi har en produktchef, ehm... Vad har du för tankar? Har du något tips, har du någon rekommendation, har du något sätt som du hade velat, ehm, att CodeScene stödjer? Liksom för att kunna göra den här ”speration of concerns” – den här separera... Att du som CFO har tillgång till detta, en produktchef har tillgång till det som den vill ha, och så vidare, liksom. Hur skulle man kunna lösa det på ett bra sätt, tycker du?

X: Jag tror att mina tankar mest går, i så fall att man får väl ”label:a” det någonstans. Ehm... Asså, mitt, mitt view är ett, liksom, ”financial of software” liksom, eller ”economics of software”, som kan göra, att man får, tar rätt executive decisions.

P: Mhm.

X: Det är... det är...

*Interruptions with the internet connection*

P: Nu ska vi se, för jag tappade bort dig där, i någon sekund – nu är det tillbaka, nu funkar det.

X: Ja. Nej men jag sa det med lite ”economics of software” eller ”financial of software” – att man har den label:en att man tittar från det perspektivet som gör det enklare att titta från vad de här executive decisions, till exempel, som att – kanske inte ens värt att göra något projekt. Eller vilken prioritering av projekt man ska göra.

P: Ja, tack för det svaret. Och, med ”labels” – vad menar du med ”labels”?

X: Jag tänker det är ingen som jobbar i produktutveckling som tycker om ”economics of software” liksom – eller ”financial of software”. Det är ju ingen som är intresserad av det, det är liksom inte det som driver de, de driver att använda, den senaste software... senaste mjukvaran, senaste applikationer, och så, att utveckla något som är spännande, och, det är ju inte alltid ett, så att säga avkastningstänk – alltså, det är det som man har i ”economics” liksom, men... Det kanske är drivande, så ehm, Patrik, att... Man har liksom en helt annan, man har en grund, ett drivande tankesätt som är lite olika givetvis.

P: Mhm.

X: Att mitt ansvar är ju att, ehm... Återkoppla till investerare och styrelsen, liksom.

P: Ja – ja, ja, ja...

X: Och är syftet bara till exempel, att om vi ska bara - bygga någonting men jag vet inte, hur andra bolag gör, men jag menar, någonstans vill man ju hitta lönsamhet. Men även, ser man då på företag som Spotify, och så vidare och så vidare, som fortfarande inte har lönsamhet, så... Kanske inte det är det som är målet heller.

P: Mhm.

X: Men jag tror ändå att det kommer, det kommer ändå bli det till slut, på något sätt. Asså har du ingen lönsamhet så måste du alltid ha någon som stoppar in nya pengar hela tiden.

P: Ja precis, intressant...

X: Det är ju inte riktigt det som är syftet, med, CodeScene, tror jag, förstår du vad jag menar?

P: Ja, ja.

X: Hur kan vi hålla på, att utveckla någonting - så att folk stoppar in mer pengar? Och är du som ägare då, det är ju jätteintressant, du som ägare, var

100

CodeScene intresserad {inaudible}, ägare av företaget som använder CodeScene, ehm... Varför ska du investera i det? Jo, för att du förmodligen vill ha någon form av performance, som du kan ta beslut på.

P: Ja, precis...

X: För, jag vet inte om du själv har varit med i några andra projekt men asså det är väl egentligen så – rätt så ofta, men, man kommer på efter ett tag att ”a, nu har vi hållt på med det här projektet i 2 år – vi har bara kommit så här långt”. Och där vill man inte ens vara.

P: Ja, ja...

X: Så jag ser ju CodeScene som någon slags proaktiv... proaktivt verktyg. Där, värdet för en ekonom är att kunna ställa rätt frågor, och samarbeta med produktutveckling i... tidigt. Även om man inte liksom är, så att säga ”tränad” i, i... vad ska man säga... Good science.

P: Ja, ja det var ett riktigt bra svar. Väldigt bra svar, tack, tack för det. Okej. Så... Då har vi bara två frågor kvar, egentligen, och dessa frågorna är då... de är lite mer öppna – av den öppna typen, så jag tänker då dela min skärm. Den första frågan handlar om en bild, som jag har snabbt konstruerat ihop, ska vi se här... Var har vi den – här, ”Photos”.

*Shows the picture*

P: Kan du se bilden, nu, på min skärm?

X: Ja.

P: Okej perfekt – så de lila rektanglarna avgränsar olika dashboards. Jag har hittat lite olika dashboards på internet som har lite olika karaktärstyper- och drag. Ehm... Så – Jag vill att du tittar på dessa olika dashboardsen, främst utifrån ett visuellt perspektiv, så det kanske inte spelar någon... nödvändigtvis något... nödvändigtvis ingen någon roll, att det står ”Catering” här, och att det är ”Cargo”, ”Passenger” (picture 3)... Utan mest visuellt – att ja okej, här har vi lite stapeldiagram, och cirkeldiagram och så vidare. Mest utifrån den visuella aspekten av en dashboard och... Finns det liksom någonting som du ogillar direkt, med någon av bilderna. Finns det någonting du tycker om, kanske färgerna som du tycker om, kanske sättet som informationen presenteras på, ehm... Finns det någonting i dessa bilderna som du hade velat se, i, ett verktyg som CodeScene till exempel – varför, varför inte? Jag vill mest höra dina tankar, och känslor liksom. X: Mm. A. Ehm... Jag kan börja med den jag gillar minst, det är den längst ner (picture 2).

P: Ja.

X: Och... För den är liksom... Det är ju egentligen tanken är väl egentligen bara det här ”göra en box”, liksom – det är grönt, allt är grönt. Och väldigt detaljerad information verkar det som, inte så mycket, egentligen. När jag tittar på den. Den som jag, näst minst, var väl den första till vänster då, 1:an då. Som visar

101 lite, så att säga, provisioner, och overall progress då, till och med det här, även om det inte var så intressant, med, själva, exakt vad som står, men det står lite mer detaljerat... asså lite... en hel del detalj – men ändå inte övergripande, men jag tycker den nummer 3, som är högst upp till höger, va?

P: Mhm.

X: Den är ju både några typ... Inte bara för att det står financial review, men, det kunde ha stått ”highlights in CodeScene”, fyra bulletpoints med det viktigaste, sen har du ju även lite staplar, och du har även ett diagram över tid, som... Och sen har du också någon slags... delning av totalt då, liksom, så att, man kan säga – det är ju värdet av att ha olika typer av grafer, då ju. Så jag tycker att 3:an är, ju helt klart starkast.

P: Mhm.

X: Ehm...

P: Så när du tittar på bild nummer 3, och där var det stod financial review – just nu så finns det 4 punkter... Hade du...

X: Bakom det, liksom, A förlåt mig.

P: Ehm... Hade du då velat se dessa punkterna som – problem? I mjukvaran liksom, eller frågor du kan ställa till en produktchef? Är det liksom det som du vill se där till vänster? Eller?

X: Ja både det som är bra, och mindre bra. Det kan ju vara, uppifrån och ner liksom att – här är ett projekt som går riktigt bra, ett projekt som kanske går mindre bra, ehm... Inte för att de på något sätt har det här, utan det är mer visuellt då ju. Ehm... Sen kanske den här nummer 3, när jag tittar närmre på den, egentligen – ehm... Man skulle kunna gå ett steg längre med att, kanske, lägga in någon form utav... Det är ju mer att jag kanske attraheras mer till den är ju att den liksom kanske är mer ett financial dashboard – än de andra.

P: Mhm.

X: Ehm... Och... Då borde man nog kanske ändra... Så att säga – gå ner lite djupare i själva produkt... Ehm... Nivån då ju.

P: Ja.

X: För det är ju det som driver i så fall, om du hade haft liksom... Ehm... Totala utvecklingstimmar bara, till exempel, eller mot, som du egentligen inte, du jämför inte det med någonting men du ser ju kanske hur många timmar du använder. Ehm... Och, och det kan ju givetvis jämföras bara som det är. Eftersom du förmodligen, eller så som jag har jobbat i alla fall – man budgeterar någon form av utvecklingstimmar ju... Och det är ju någonting som utvecklare, ja, också är rejält ointresserade av.

P: Okej. Ja, tack för det svaret...

102

X:... Inte, inte ointresserade, men jag menar det är liksom ingen som {inaudible} du har liksom 200 timmar på dig att göra detta – det är liksom inte så man jobbar, som jag har uppfattat det, utan man vill jobba agilt, man vill jobba, ehm... Tills man är klar, tills produkten är häftig nog, och kan liksom, vara, så, testad, i olika miljöer, ehm... Det är väl lite därför jag försöker liksom, ha ett högre, som du sa abstraktnivå på det, för att INTE lägga mig i detaljer, i, eller... INTE heller förstöra någon form av motivation på detaljnivå. Utan faktiskt, det är väl ingen som tycker det är kul att jobba med ett projekt som inte går frammåt.

P: Mhm.

X: Ehm... Och ser man inte – har man utmaningar i projektet så det kanske, ibland jobbigt att ta upp det – det är enklare om chefen ibland säger att ”hur... vad är det som händer i detta projektet”, liksom, förstår du vad jag menar – att det kommer en fråga istället. Då är det lättare att säga ”Ja, vi behöver kanske lite extra hjälp här för att bli klara – vi behöver ta in...” Och då är vi ju lite tillbaks till det som vi tog upp först, asså att man kan då titta på teamsen, då tittar man ”okej – vilka team har vi här”, då kan man kanske säga ”vi behöver ta in en andra utvecklare för just det här projektet, för att få fart på det”. Ehm... Och så har jag upplevt att det är ibland, att man har ett, en bugg någonstans, eller någonting, att... rätt som det är så tar man in rätt person och den personen löser någonting som ingen hade löst på... 20 månader liksom – på något sätt...

P: Ja.

X: Jag kan inte förklara det, jag kan inte förklara det Patrik – men det är bara vad jag själv har... liksom varit med om – som man inte tror det är sant, att en annan person kan gå in och bara ”a, nu fixade jag koden” – vi hade inget performance problem, vi hade bara ett kodproblem liksom...

P: Ja, hehe.

X: Vi behövde inte mer ”data-storage”, behövde inte mer storage – det var ett kodproblem liksom...

P: Jaja! Ja...

X: Och det är ju... fantastiskt bra.

P: Det är, det är lite så det kan vara, hehe, med mjukvara, det är... Det är svårt ibland, ehm... Men ja jag tyckte att du gav jättebra input. Ehm... Känns som att jag fick lite bättre koll på läget. Men, då går vi igen, in i samma grej, att, ifall vi nu säger, att ett verktyg, som CodeScene, ett mjukvaruanalysverktyg, hade kunnat ge dessa här typer av rekommendationer, att ”ja okej, det ser ut som att vi behöver person X i... ehm, i det här teamet”, och som då hade täckt det här, caset som du berättade, att det liksom har funnits projekt där man la in, en ny utvecklare – eller en specifik utvecklare, och så löste sig massor av problem, till exempel. Då är ju syftet... Då är ju målet, egentligen fortfarande, att... Att projektet ska lyckas så bra som möjligt, ur ett finansiellt perspektiv – för det där...

103

X: Mm.

P:... ledde ju till att projektet, plötsligt inte blev, inte var så dåligt längre utan det blev bättre – för att det gav mer kanske intäkter, eller man kunde slutföra det snabbare, och då behövde man lägga ut mindre kostnader över en längre tid, vilket, på så sätt sparade pengar, till exempel... Så det är fortfarande ett väldigt ekonomiskt perspektiv – rekommendationer som, förbättrar det ekonomiska, hade man kunnat abstraherat det på det sättet kanske...?

X: A precis. Plus, plus kopplat också till att, ehm, det, de personerna som är duktiga vet man då, det är lite så som jag såg på den här CodeScene produkten också, att man fångade upp de som är riktigt duktiga, på något sätt.

P: Mhm.

X: Man vet vilka som är key... key-people liksom.

P: Ja.

X: Men... skulle jag rekommenderat dig att även läsa lite om, asså, jag vet inte om du vet vem [namn] är?

P: Nej det vet jag inte.

X: Ja men då skulle... Läs om honom och tänk på det här projektet... Han är ju en av världens bästa investerare – har de största... Även de... Så att säga – de tuffaste kunderna, de största universitets-foundations, liksom, i, i investeringsvärlden, kan man säga.

P: Mhm.

X: Och hur då, får man fram, ehm... Medarbetarna också, så att man har rätt team – på rätt plats. Och då är det ju grundat lite, i det här... Inte, och det är ju liksom möjligheten kan vara just inom programming, att, det handlar inte om titel, och plats i företaget, utan det handlar om du har rätt, och kan, liksom, ha rätt oftare än andra, när du gör någonting. Och i den här världen skulle man kunna översätta det som att har du rätt, din kod är bra och inte dåligt, på något sätt – och då får man ju mer att säga till om ett projekt, genom att man då baserar det på, ehm... Merits liksom, asså ”Meritocracy” kan man väl säga, istället för ”Democracy”, så är det ju grundtanken med meritocracy, och det är ju lätt att jag... Så att säga, ett fotbollslag – tänk den tanken liksom.

P: Mhm.

X: Det är ju klart att någon som är key-player har mer att säga till, det bara blir så eller hur.

P: Ja, ja.

X: Men i ett företag brukar det inte vara så, utan det är mest den med högst titel som säger någonting. Men han har liksom... Instutitonell... passion av det, bakom i varje, så att man kan se liksom om han har några nya projekt, så kan

104 man få, asså rösta på vad som man tycker är bäst, och, det baseras ju på hur dina projekt har gått bra, eller du har röstat på något projekt som har gått mer eller mindre bra, innan. Så det är högst teknologisk bakgrund liksom, så han drivs framförallt av data, och hur du har liksom gjort, gjort tidigare.

P: Mhm. Jaja, intressant, väldigt intressant ja. Tack, tack för ditt svar. Jag ser här att vi börjar närma oss slutet. Vi har en minut kvar tills klockan är [time]. Ehm... Jag har en fråga till – ehm, kvar, som handlar om CodeScenes egna dashboard. Men jag vill bara se liksom, om, om det är okej, om vi kanske går över någon minut, över tiden.

X: A det är okej.

P: Okej, det är okej – perfekt. Ehm... Då ska jag se till och dela min skärm. Där. Oj, där ska vi klicka. Så, nu tror jag att man kan se min skärm. Så här.

*Shows the dashboard*

P: Kan du se min skärm nu?

X: Ja.

P: Perfekt. Så, så precis så som i videon är detta, dashboarden i CodeScene. Jag scrollar upp och ner... Men så ser det ut i alla fall. Det finns olika typer av information, saker som ”System Level Hotspots” och ”PR Statistics” och så vidare, behöver, integrationer mot andra verktyg som JIRA, och så vidare, till exempel - ”Development Costs” och sånt, men det kan man också lägga in.

X: Aha, har ni... Kör ni JIRA också i bakgrunden?

P: Jag har inte JIRA integrerat just nu, i CodeScene, men, det finns möjligheter att integrera Trello, JIRA, ehm... och massa andra verktyg – och på så sätt få in data därifrån, och utöka liksom, hur mycket, hur mycket nytta CodeScene kan göra, så det finns idag, integrationsmöjligheter mot andra verktyg ja.

X: A men det kan jag också, rekommendera... Vi använder JIRA så att, så det kan jag, det har jag tyckt, har varit ett bra system.

P: Mhm. Ja. Okej. Så, det jag vill veta här, är liksom dina åsikter kring dashboarden. Vad tycker du om dashboarden – är det någonting som du tycker är dåligt, någonting som är bra? Hur hade du velat att dashboarden kanske skulle ändras för att, passa din, roll, mer, mer än så som den ser ut i dagsläget?

X: Jag skulle vilja ha någonting, det skulle vara ”investments”... Asså som en föreskrift för allt som vi pratat om, egentligen va.

P: Mhm, ja.

X: Det, eftersom man inte bara har ”financial”, ”financial review”, utan, det är ju en investering, och man kan se investeringen är ju, ehm... turdelad, kan man säga då ju, eftersom, man investerar, man ser utvecklingskostnaden som, man jobbar extra på någonting, eller – egentligen är ju... Om man utvecklar en ny,

105 så är det ju en annan sak, kanske då, men om, {inaudible} en ny produktutveckling. Ehm... Om man går från en ny generation till en annan, det är svårt att, ehm, kanske mäta, vad värdet är där då. Till skillnad från när vi pratade om ett projekt till en kund, förstår du vad jag menar?

P: Mhm.

X: Asså när man utvecklar egen, asså från en egen version, generation 1 till generation 2, kanske, på, ja som om ni själva har utvecklat CodeScene, från generation 1, till CodeScene generation 2.

P: Ja.

X: Där är det ju liksom inte, någon säker return on investment egentligen att titta på. Men där är det ju intressant att titta på, vad har vi totalt spenderat, liksom. Ehm... Och investerat, och det är ju... Det är som med, om man går från, ehm... Från ett HR perspektiv liksom, man kan ju, man kan ju se, som vi säger då, kostnader pratar vi om, man kan ju se alla, alla löner som en investering också. Jag tror att i IT-bolag ser man ju lite så ibland, att, det är ju en investering att hela, egentligen ett helt produktbolag är ju en investering, kan man säga.

P: Mhm.

X: Även den årliga lönen är en investering liksom.

P: Ja.

X: Men, det som är intressant är också då hur mycket kapital – capital investments som behövs. Är du med? Det är skillnad på ”on-going costs” om man säger så, versus ”investment capital” då, så kapitalåtgången. Och, det är ju därför man hela tiden raisar nya pengar, och släpper in nya investerare.

P: Mhm. X: För det går ju, det går ju åt en hel del att utveckla nya saker. Som man kanske inte alltid kan, mäta i, direkt return on investment eller hur?

P: Exakt.

X: Utan return on investment har man ju, mer, tanken där Patrik som, på projektbas då, förstår du vad jag menar – det är två olika nivåer.

P: Ja.

X: Utan, ibland måste man ju bara satsa för att få en ny generation eller hur – för att hänga med att vara ett SaaS-bolag, till exempel, att verkligen vara ett SaaS-bolag på riktigt, det finns många bolag som, som utger sig vara ett SaaS- bolag som egentligen inte är SaaS-bolag.

P: Ja, jaja.

X: Och det kostar ju att komma dit, liksom.

106

P: Exakt, då måste man offra, kanske lite, på den... return on investments kortsiktigt.

X: Ja, precis, och då är det ju en long-term versus short-term tanke där – då har man då ett kapital... Investering som man vill göra då vill man se det också, inte bara per projekt. Nu kom vi väldigt mycket in på ”per projekt” – vilket är ju superviktigt hela tiden, day-to-day liksom.

P: Ja.

X: Ehm... Men jag tycker ju att, jag är ju egentligen inte ute efter, det, egentligen, jag är ju egentligen inte utväxt efter att ”rate:a” den bästa programmeraren – det ska produktchefen veta liksom. Det är ju egentligen inte mitt jobb, eller hur?

P: Ja.

X: Utan jag är intresserad av: Vad kan vi presentera till... Asså styrelsen/board, vad kan vi – kopplingen till mig som CFO är ju oftast, i {inaudible}, där jag kommer i kontakt med JIRA och såna grejer, givetvis, genom governance och standups. Att allting är liksom uppkopplat, och det här är ju ett verktyg, som absolut hade varit uppkopplat på det sättet att, a, nu tittar vi på det här perspektivet, ur et CFO perspektiv då, ehm... Och, ehm... Då är jag kanske inte intresserad av vem som är author eller contributor till vad, eller hur?

P: Ja.

X: Samtidigt är jag inte bara intresserad av det financiella, för då är det bara ett financial... desktop ändå.

P: Ja...

X: Utan det handlar om att merga de här två vyerna, liksom. Att... Asså jag är ju intresserad av att, det är ju helt annat, data, utifrån liksom, vad, vad har man för avkastningskrav på andra produktbolag – och hur ligger vi till där emot? Är du med?

P: Jaja, Mm.

X: Asså, det säger ju egentligen ingenting om hur vi, hur effektiva vi är som företag. Om vi inte vet, vad, ehm... Vad, så att säga normen är utav andra företag på den högre asbtraktnivån, om man har då data, utifrån så att säga – i liknande bransch givetvis. Och det finns givetvis, det finns ju data – det är mer, från min bakgrund som analytiker då, som, asså, om man har en sektor som man då följer, till exempel, så som jag gjorde, så vill man ju hela tiden jämföra sig själv – hur detta företaget gentemot andra företag i en liknande bransch. Och då är det ju inte så olika faktiskt, om man nu egentligen... Man kanske till och med vet vad vissa gör bättre än andra liksom.

P: Jaja, det är, jättebra input. Det kändes som att det lyste upp en lampa i mitt huvud, det där med – det är inte bara finance. Det är finance ”slash” investments ”slash” att kunna jämföra sig med marknaden och se hur...

107

X: Ja.

P: Det är det som är den ”riktiga” referenspunkten, att kunna jämföra sig med... Medelmåttet av den här branschen, det är ju där man egentligen kan se...

X: Man kan se det som, om man tar hela utvecklingssidan, okej vi har det som jag började räkna på själv, var ju liksom att ”okej” – i [namn] har vi 80 utvecklare, i en annan marknad, i [namn] har vi 50 developers, där har vi 30 stycken, här har vi 20 stycken, förstår du hur jag menar?

P: Jaja.

X: Och vi tillsammans, får den här outputen, eller hur? Men jag vet ju inte hur bra den är. Det enda jag kan göra är att ”Okej vad gjorde vi förra året”, men det säger mig heller ingenting mot, hur bra vi är liksom...

P: Jaja, exakt.

X: Utan... Det skulle vara intressant, att kunna titta på mer som ”Okej, vad...”, för det är där man hittar i så fall, alltså, någon form utav – vad ska man titta? Och vad är dessa bottlenecks i så fall, i, i det specifika företaget. I utvecklingen då.

P: Ja.

X: Och det kanske är så enkelt att titta in, ”ja” – key personnel, det är, ehm... Vet inte hur det märks, men det kanske är så att 20 % av alla utvecklare... De 20 % är med på alla lyckosamma projekt, är du med? Och koppla det till människor, det är alltid människor. Jag menar – vi drivs ju inte bara av... projekt. Utan det är att jobba ihop med rätt team, och jobba ihop med rätt människor, och det glömmer vi bort.

P: Mhm.

X: Och jag tror att där kommer ju teamet in. Det som jag är intresserad av – jag är från skuld, jag är faktiskt {inaudible} intresserad av team, team-buildingen liksom, och det är ju men för att man själv ser, att det ibland helt enkelt är fel människor som jobbar ihop.

P: Ja, det är det ofta, faktiskt. Den här kemin, mellan människor – det är den som skapar resultat.

X: Ja, och det är faktiskt det – jag som finanspersoner tycker liksom det är väldigt intressant. Ehm, för oftast ser man ju bara att ”om jag bara får med mig den och den, så kan jag fixa detta” – om 6 månader. Men det är liksom inte bara ”jag får 2 personer” – så kan jag göra det på 6 månader, utan det är mer . får jag med mig han eller hon, de två, då fixar vi det.

P: Ja.

108

X: Det, det är ju jag nyfiken på. Jag kunde aldrig se vilka som jobbade ihop i ett projekt, till exempel. Jag kunde aldrig se vilka teams, jag kunde aldrig se någonting om, kanske mitt sätt att liksom, att, att titta på det, men, så, om man är intresserad av ledarskap och hjälpas åt, om man då inte har en – någon slags hög... asså om man har en massa låg prestige i att, vi vill alla jobba fram oss, i bästa miljö, då är det inget problem, att, att sitta och prata om såna här grejer, liksom. Från ett finansperspektiv med en produktchef. Om inte produktchefen, känner sig hotad – att nu drar vi ner budgeten här. Så får det ju inte vara heller.

P: Ja. Ja... Jaja, definitivt. Jag måste säga att det var väldigt, väldigt bra input som jag fick, allmänt, från hela intervjun.

X: A tack.

Discussions outside the realm of this interview continues for a time.

P and X thank each other and say their farewells.

109

12.6.4. Protocol 4 The interview starts and X grants permission to record the interview.

P: Intervjun är uppdelad i två delar. Den första delen är en 6-minuters video, som jag tänkte spela upp. I videon går jag igenom CodeScene – någon funktion, och försöker liksom, ehm, skapa rätt kontext för, vad ett mjukvaruanalysverktyg är, ur just CodeScenes synvinkel och perspektiv. Och därefter kör jag då igång med den riktiga intervjun, där jag har några förberedda frågor, och, som jag då helt enkelt tänkte fråga kring.

X: Ja.

P: Jag hoppas det låter bra – jag hoppas du är bekväm! Om du är det, så kan jag då börja dela min skärm och sätta igång den här videon.

X: Då kör vi.

*The video plays*

P: Okej, perfekt.

X: Ja, bra.

P: Just det, och jag har, jag har även CodeScene uppe i bakgrunden på min datorn, så är det någonting som du vill ehm, titta igenom, eller kolla, kolla på en gång till under intervjuns gång så är det bara att säga till, så kan jag ta upp CodeScene på, på skärmen. Okej, då kan vi gå över till del 2 av intervjun – ehm, och då kanske du kan börja med att berätta lite om dig själv, och vad din arbetsroll går ut på?

X: Mm. Jag heter [namn] då, och sitter som Group CFO på [namn]. Och det är egentligen ett bolag där också [namn] är ägare, [person] äger också [namn]. Ehm, min roll är väl att hålla ihop bolagets ekonomi – jag har också tidigare erfarenhet från ekonomiavdelningar i lite större producerande bolag, med stora IT utvecklingskostnader. Kort om mig.

P: Okej, perfekt, tack, tack för det svaret. Ehm... Så okej, baserat på videon, ehm, vad tyckte du stod ut mest i verktyget, och varför?

X: Jag tror det är sättet att visualisera på. Ehm, min – kanske inte så mycket från [namn], eftersom vi inte utvecklar egen programvara, men där jag jobbade tidigare, på [namn], så la vi oerhört mycket kostnader på IT, olika IT projekt – vi hade liksom ett hemmabyggt ERP system, en produktgenereringssystem. Ehm, och för en ekonom så är det ju oerhört, oerhört svårt att få en överblick av kvalitén, och vad vi egentligen gör, och var vi lägger vår tid. Ehm... Jag gillar ju den visualiseringen, dels där du ser liksom... Känsligheten för personer, ehm, där du kan se... Om där - en som jobbar, är väldigt ensamt i stora ytor, vilket kan vara en stor risk för ett bolag, ehm, och sen kanske jag kan se, i min roll, att jag skulle vilja se lite mer pengar, på riskerna – än, än bara ”nämen vi ser en hotspot, vi ser att den är röd, men hur stor är den tekniska skulden egentligen?”. Jag skulle kanske vilja ha, lite mer specifik, ehm... För att fixa det

110 här, vad skulle det kosta. Man får ju sätta någon form av liksom standard, ehm, komponenter eller priser, där man kan få en uppfattning om vad... vad, skulle, vad skulle kosta oss att stänga – eller att bli av med vår skuld (technical debt)?

P: Ja, ehm, tack för det svaret...

X: Eller om någon slutar till exempel, ja vad skulle det kosta oss då? Och risken att lära upp någon annan.

P: Ja precis, precis, ja – det var ett jättebra svar, ehm... Det är lite för abstrakt på den fronten, när det kommer till kostnader, och den financiella aspekten av utvecklingen...

X: För min del blir det ju lite för tekniskt.

P: Ja.

X: För jag, jag vet ju inte – jag kan tänka mig att det här är perfekt för en utvecklingschef som behöver ha koll på sitt team, som kan varenda del- komponent i ett system. Men jag behöver ha en bättre, övergripande bild.

P: Mhm. Ehm, så den här övergripande bilden som, som du nämnde nu på slutet, är det då, en högre abstraktionsnivå, kan man kalla det för det? En högre, liksom, detaljnivå? Av dashboarden?

X: Ja, både och – jag skulle kanske vilja, jag skulle – som, i min roll, så skulle jag vilja se vilka projekt jobbar vi med, ehm, och vilka, vad har vi kanske för kodhälsa i respektive projekt, ja, om jag nu hade suttit som CFO på [namn] som är en utvecklare till ERP system, så vet jag kanske att de har 6 olika system. Hm, de här systemen har vi, den här kodhälsan har vi på de här systemen, den här tekniska skulden har vi, och då kan jag liksom dyka ner, och också kanske ifrågesätta, eller ta en diskussion med någon, om investeringsbegär... Asså behöver de 1 miljon till, 2 miljoner till? Var är det vi ska investera våra pengar? Ehm, och var är det vi ska fokusera för att vi ska, få det bästa resultatet? Så tänker jag.

P: Okej...

X: Så ja skulle vilja liksom lyfta upp det ett snäpp. Ehm...

P: Ja, precis. Ja, lyfta upp det ett snäpp...

X: Mm.

P:... Ha då till exempel information på teknisk skuld, och sen då, för att kunna åtgärda det, eller som du sa, veta hur mycket som ska investeras, och var, så kanske klicka på det, och sen kanske dyka ner ett snäpp ner, liksom, så från början ha det väldigt högt...

X: Ja precis. P:... upp, och sen när det väl behövs så ”okej jag ser att det finns ett problem” – klicka på det, dyka ner ett steg, och sen få det lite bättre förklarat...

111

X: Mm.

P: Okej, ja, tack för...

X: Och sen tror jag att, att, att ehm, vi kanske är lite bekväma – nu använder jag [namn] – som mitt analysverktyg, jag skulle ju vilja ha in detta, i samma verktyg. Jag tror att man är lite, lite motståndare till att gå in i mer än ett system. För att ehm... Jag gör ju dashboards till exempel, till vår ledningsgrupp – det här skulle kunna vara en del av min dashboard om vi jobbat mycket med IT-utveckling – men då skulle ja vilja kunna presentera den på samma ställe.

P: Ja, ja precis. Okej, tack. Ehm, så, om vi säger så här, vad är dina generella tankar kring designen, som finns i CodeScene?

X: Ja men, jag tycker att den ser enkel ut. Ehm, asså själva färg, färgsättning och så – men för min del är den för, för teknisk. Och... ja. Och, kanske inte anpassad efter roller, utan att vi kanske har försökt få in för mycket, på en vy.

P: Okej, ja. Ehm, så den här frågan kanske överlappar lite, med vad du sa tidigare, men bara för att förtydliga liksom, ehm, vad ser du för konkreta förbättringsmöjligheter i CodeScene – utifrån din arbetsroll?

X: Jag, jag tror att, försöka hitta mer, ehm, jag tycker att den vyn som finns nu är, är, ur ett tekniskt perspektiv. Om man vill, ska tilltala en CFO så måste man sätta det ur ett ekonomiskt perspektiv.

P: Okej, tack. Perfekt. Så, om vi då tar och flyttar oss ett snäpp uppåt, med frågorna, ehm, vad hade du, vad hade du velat se, i ett mjukvaruanalysverktyg, ehm, vad hade du varit nöjd med, hur hade ett sådant verktyg sett ut, och vad hade, ehm... det haft för funktioner?

X: Lite som jag sa innan, kanske en övergripande bild först på vilka projekt vi har, hur mycket pengar vi har pumpat in i de olika projekten – hittills, och vad vi, vad som finns kvar att göra, för att nå en accepterad nivå, liksom.

P: Mhm.

X: För jag tänker, vi ser ju, vi ser vad som händer, och vad som har hänt hittills i projekten. Ehm, vad har vi egentligen. Antingen så plockar man ju det från något ekonomisystem om man har tur och har det – så att man vet hur mycket timmar man har lagt på respektive projekt, eller så kan man sätta ett pris per kodrad, eller vad det nu må vara, i någon form av schablon, för att se – vad har vi egentligen lagt ner i det här systemet? Ehm, vad, var har vi för... kodhälsa, och för att nå en viss kodhälsa, vad behöver jag putta in ytterligare då i så fall?

P: Mhm. Jag vet att du nämnde...

X: Så tycker jag.

P: Ja, tack. Jag vet att du nämnde någonting med tid i ett föregående svar – att tiden också, var viktigt och kunde användas ehm, på något sätt, för... Ja givetvis

112 finns det ju, rekommendationer, kanske kring vad vi kan göra till exempel, vi kan ändra individstrukturen i den här utvecklar- i det här utvecklarteamet och på så sätt förbättra effektiviteten av kodkomponent A – men sen finns det ju också ett tidsperspektiv när det kommer till projekt. Som, som kan vara av väldigt högt intresse – till exempel, hur långt har vi kvar på ett projekt, egentligen? Och finns det någonting vi kan göra för att snabba på processen, liksom? Hur, hur hade...

X: Absolut, ehm, ja...

P: ...Hur ser du att tid kan kunnas liksom implementeras i ett sånt här verktyg, och hjälpa din arbetsroll?

X: A men, det, det, tror, ja men det tror jag också för jag menar, om... Om man sitter som CFO i ett utvecklingsbolag så är det oerhört viktigt – när vi kan launcha produkten, om den inte redan är på marknaden.

P: Mhm.

X: Det ger ju ekonomi i sig. Ehm, och kan man starta tidigare, så är det klart att då kan intäkterna också komma tidigare. Så tiden hade också, lite så där, om vi puttar in det här – jag vet att {inaudible} massa såna här grafer, att om vi gör det här så händer detta, att man kanske skulle kunna se... Fortsätter vi som vi gör nu så kommer det här projektet vara färdigt, december 2021. Men skulle vi göra annorlunda, det här istället, då skulle vi kunna, vara färdiga i juni istället – det skulle kosta mig så här mycket. Men någonstans kan jag göra ett investeringscase av det i så fall och se ja men det är kanske värt att putta in den här miljonen – för då kan jag starta, och leverera produkten tidigare till kunderna.

P: Mhm.

X: Så tiden, tiden är ju också viktig så klart, att ehm... För någonstans finns det ju, varje projekt har en tidplan när det ska vara färdigt. Och den har ja jättesvårt att ifrågesätta i min roll, eftersom jag inte har den tekniska kompetensen. Det hade varit super om verktyget hade kunnat indikera: ”Ja men, kör vi så här fortfarande, så är... så håller vi deadlinen, eller så håller vi inte deadlinen”. Ehm, tänker jag.

P: Ja, tack, tack för det svaret.

X: Mm.

P: Okej, om vi då går ännu ett snäpp ut, zoomar ut lite grann till...

X: Mm.

P: Så har jag då, framställt en sån här väldigt öpen, kreativ fråga: Hur hade det perfekta mjukvaruanalysverktyget sett ut enligt dig, och du kan vara hur kreativ du än vill – det finns inga gränser för vad som är möjligt.

113

X: Ehm, ja men, jag är lite tillbaka – dels att jag skulle vilja ha det i den platformen jag jobbar med vanligtvis, när jag tittar på, ehm, följer upp min, ja – jag använder [namn] till exempel, jag skulle vilja ha in det där. Så att man har ett öppet API så att man kan hämta den informationen, man vill ha. Och sen egentligen lite så som [namn], att man faktiskt själv kan bygga, det – man vill visa. Ehm. Kan ju finnas vissa standard funktioner, eller standard grafer, ehm, som finns att plocka ifrån, asså lite som ett smörgåsbord liksom – vad är det jag vill ha, för att jag ska kunna dra in det i min egen dashboard.

P: Okej.

X: Och även då möjligheten att färgsätta, och så, efter bolagets... Vad vi har för... Så att det passar in i våra rapporter.

P: Ja, tack, tack... tack för det svaret. Okej mm. Så det här med mjukvaruanalysverktyg, utifrån det som jag sett i tidigare forskning, i ämnet, så är det väldigt väldigt sällan, att någon som innehar en CFO position använder ett mjukvaruanalysverktyg.

X: Mm.

P: Och dels kan det ju förklaras, genom att de är så väldigt tekniska idag, och att det inte finns så många verktyg ute på marknaden, som är så pass liksom, visuella som CodeScene. Utan då är det väldigt väldigt tekniskt, ehm. Men som då, som då CFO – vad har du för krav på ett mjukvaruanalysverktyg för att du ska kunna använda det? Finns det någonting som MÅSTE finnas med i verktyget, och om det inte finns med så kommer du inte att använda det liksom?

X: A men jag tror det måste vara enkelt, och jag måste kunna förstå det. Och jag tror liksom, det är bra med jag behöver ju hjälp att tolka informationen, och ge rekommendationer. Så om jag ska gå in i sånt verktyg, och få liksom ”jaha hur går det?”, så måste jag ju få hjälp att förstå det. Och då kan det ju vara de här KPI, kodhälsa, teknisk skuld, men jag måste ju också förstå att, är det bra eller dåligt? Vad är benchmarken, och vad kan det här kosta oss? Så enkelt att använda, visuellt - det du nämnde, är också super viktigt, inte tusen olika siffror och... För det kommer jag aldrig förstå. Utan, också gärna tydliga rekommendationer, eller... Highlights, lite som du visade nu liksom, var är de största riskerna, vad borde vi göra åt det?

P: Mhm. Och, bara för att förtydliga – det här med hjälp, ehm... När det till exempel kommer till inlärningsmomentet av ett mjukvaruanalysverktyg som CodeScene – hur ser du att inlärningen kan ske, på bästa möjliga sätt, är det med hjälp av en dokumentation? Är det med hjälp av en interaktiv, liksom, walkthrough? Att i programmet står det liksom ”klicka här för att göra detta”, eller är det kanske frågerutor kring varje mättal, och funktion, att man kan klicka på det så får man upp en förtydling, vad detta här egentligen menas med, och så vidare? Eller hur tänker du kring ”hjälpen”? X: Ja, men ja precis. Det måste finnas tydligt vad de här mättalen betyder. Jag tänker, jag tänker inte en skriftlig instruktion, för den tror jag blir alldeles förträlig, 2 rundor och några {inaudible} så den kommer jag inte ha framme när jag sitter med verktyget. Utan jag tror ju, att, asså en kombination av lite interaktivt, också att man får information när man är inne i verktyget – som du

114 pratade om kodhälsa, om jag ställer mig där, så ska jag få en rätt bra definition på vad detta är, och hur detta har räknats ut, och vad det betyder. Men även då kanske hjälp, i, ehm, vad är det jag ska göra någonting? Vad är jag ute efter, och hur gör jag det i så fall, i någon form av steg... steg-för-steg, lite det här ”next” liksom, ja - nu gör jag detta, och sen nästa, asså är du med?

P: Ja, ja.

X: Så en kombo av det, tror jag att jag hade behövt.

P: Okej, tack för det svaret. Så... Du nämnde, tidigare, att ett verktyg ska vara enkelt att använda, så jag, vi kan då, istället för ”enkelt”, kan vi då använda oss av termen ”användarvänlighet” – vad är din definition, av användarvänlighet, då ur kontextet av ett mjukvaruanalysverktyg?

X: Ja, men det är väl lite det jag pratade om precis. Det vi säger, att det är dels enkelt visuellt, men också enkelt, att man har liksom guider i verktyget för hur jag ska använda det. För nu när du scrollar runt, där är rätt mycket menyer, rätt mycket med menyer – att det kanske är svårt att hitta i det, om du inte själv har byggt det.

P: Mm.

X: Så jag som kommer från utifrån, så hade jag behövt ha... ehm, lite det som asså, jag behöver inte se allt, utan anpassa vyn till vad jag behöver i min roll, ehm, och hjälp mig med de här guiderna, för hur jag kan jobba med verktyget.

P: Ja, tack för det svaret och... Du har nämnt lite det här med vyer – att, du har en arbetsroll, CFO, det kanske finns någon annan som är project manager, det kanske finns någon annan som är utvecklare, och... Givetvis behöver dessa arbetsroller att se, olika typer av information, och på något visst sätt abstraheras ifrån... utifrån vad de innehar för arbetsroll. Ehm. Hur hade du velat att den här hanteringen av olika vyer, av olika intressen, utifrån arbetsroller, hanteras utifrån ett mjukvaruanalysverktygs-program?

X: Ja, asså, ja, för min del hade jag kanske bara velat ha access till en viss del. Ehm... Sen kanske det kan vara så att den som är projektledare, och den som är lite mer CTO – de kanske, CTO:n kanske ibland vill dyka ner i lite mer detaljer, och ha möjlighet att ha access till mer. Men för min del, ehm, så tror jag att... Och även för en ledning då kan man väl säga, företagsledning, så tror jag att det är bättre med mycket mycket mer överskådligt, lite detaljer, tydliga grafiska presentationer, och skulle jag liksom ha någon fråga på någonting, så tycker jag i alla fall att det är CTO:n eller projektledaren som ska, gräva vidare i detaljerna. Den rollen vill jag inte ha. Så för min del skulle jag vilja bara, ja, jag skulle bara vilja ha ett skal, medan jag tror för de andra rollerna – vilket jag kanske inte ska uttala mig om – men de kanske ändå vill ha, alla delar. Jag hade varit nöjd med min övergripande, summeringspresentation liksom. För jag har inte kompetensen att, att förklara detaljerna, utan där behöver jag ändå en projektledare eller en CTO som kan hjälpa mig med det.

P: Okej, tack, jättebra svar. Det här skalet, ehm. Ser du liksom någon, ehm, något potential med att ha liksom, färdigställda roller från början? När man

115 första gången öppnar upp CodeScene, att man, liksom att det finns standardvyer, det finns en ekonomisk-vy, det finns en utvecklar-vy, det finns en manager-vy, till exempel. Och att man klickar på det, och har då, redan från början, ett visst skal, men som man sedan, givetvis, ska kunna modifiera till sitt tycke. Liksom så att man inte, ifall man öppnar CodeScene, så att du inte börjar utifrån hela den här tekniska vyn, och måste lägga ner väldigt mycket arbete för att bygga upp det skalet som du pratade om, utan så att det finns fördefinierat i början – hade det kunnat vara någon, en, en bra lösning på det här med att komma ihåg snabbt och ha en lämplig vy? Eller finns det kanske någon annan lösning som du tänker dig, hade varit bra att ha?

X: Nej men, men jag tror att, sätt en standard-vy, precis som jag sa innan, ge mig möjlighet att plocka in om jag vill ha någon annan graf, eller jag vill ha nått annat nyckeltal, lite som man gör i [namn], att jag klickar på en rapport, jag pinnar det till min dashboard, och så får jag upp den på min dashboard. Men jag vill ju gärna ha en början. Ehm, och, ett, smörg... en meny att välj, från. Utefter min roll, så jag tror att du är på rätt spår. Sätt upp roller, ehm, gör en standard men ge mig en möjlighet att anpassa det. Och då kan jag ju göra det genom utbildning, genom att man har någon best-practice som man kan visa, där jag kan få inspiration, för det känner jag mycket med mitt [namn}-verktyg, att man har ett visst sätt att göra saker på, men så ser man ”shit”, det finns detta nyckeltalet också, det hade jag också velat ha in, ehm, att, att ge mig möjlighet att plocka in mer. Ifall jag vill det.

P: Ja okej, tack, tack. Det är så att vi har kommit fram till de 2 sista frågorna, i, i intervjun.

X: Mm.

P: Och det är så att frågorna är kanske speciella på det sättet att de är lite mer öppna, så... Jag kommer att visa, i fråga 1 kommer jag att visa en bild som jag konstruerat ihop lite snabbt, med 3 olika dashboards, i olika program, ehm, där jag helt enkelt vill veta dina åsikter, eller kanske till och med känslor, när du tittar på de olika dashboardsen. Är det någonting som du gillar jättemycket? Finns det någon färg som du gillar kanske, finns det mönster eller kanske sättet som informationen presenteras på – det är en väldigt öppen fråga kring den bilden – jag ska ta upp den nu. Så nu borde den dyka upp.

*Shows the picture*

P: Så vi har då, de lila rektanglarna... presenterar, representerar de olika dashboardsen, - och sen har vi siffror 1, 2 och 3. Och jag har snabbt försökt hitta 3 olika nivåer av dashboards som finns, i olika typer av program idag. Och, som jag sa innan liksom, den här frågan handlar helt enkelt om att titta, och kanske till och med försöka brainstorma och säga det som man tänker och tycker kring varje bild. Finns det någonting som är bra, ”O, det här gillar jag”, ”Det här hade jag velat se på det sättet”, i ett, ett verktyg som CodeScene, eller ”Det här gillar jag inte alls”. Jag vill bara höra dina åsikter, hur de än kommer.

X: Ja, spontant så gillar jag den längst ner (picture 2) – för den kändes renare. Den kändes som lite mindre information. Ehm, och sen hade jag då gärna velat,

116 så klart klicka vidare, men att få en, först, väldigt hög-nivå, är, ehm, och sen möjlighet att gå in på detlajer... Det tycker jag, är, spontant bättre. Jag tycker att de andra två har lite för mycket, i samma. Ehm, på en bild.

P: Mhm.

X: Ehm... Men jag har svårt, jag ser inte riktigt detaljerna, men bara visuellt – så är det min känsla. Och sen så kanske jag hade velat, om det nu är så, att i den längst ner (picture 2), så skulle jag kanske vilja ha tydliga varningsgrejer, ifall det är någonting jag borde uppmärksamma. Ehm, det har jag svårt att se om det finns nu, jag vet inte riktigt, vad, ehm... Sen har jag, jag vet inte riktigt den financial review (picture 3), ehm, den texten där. Den kanske man skulle vilja i så fall ha i ett nästa steg. Att jag börjar här (picture 2), och så klickar jag mig ner, om det nu finns någon form av kommentarer, på ett nästa steg.

P: Ja okej, tack för din input.

X: Ja.

P: Jättebra input. Då ska vi gå vidare till den sista frågan. Och den handlar då om CodeScenes egna dashboard, ehm, jag tänkte ta upp dashboarden, och på liknande sätt liksom, höra dina kommentarer – vad du tycker helt enkelt. Så, det borde funka på detta sättet.

*Shows the dashboard*

P: Så, projektvyn, jag har endast ett projekt – vi klickar in på det. Och då kommer jag direkt upp till dashboarden. Samma dashboard då som jag visade i videon. Ehm, och då måste jag scrolla ner lite, jag kan inte göra liksom så att jag ser allt, på en statisk skärm, utan jag måste scrolla ner och upp - Men så här ser dashboarden ut idag. Och, sen finns det ju så klart lite saker som ”Development Costs”, som kräver integrationer, mot till exempel JIRA, och så vidare för att kunna få upp information här. Men så här ser dashboarden ut idag. Och jag undrar, ehm, vad du gillar, vad du kanske inte gillar, och om det finns ändringar som du hade velat personligen se, som du tänker på...

X: Det är lite det som jag sagt innan, att, att man försöker få in så väldigt mycket, på en sida. Att det finns inte den här övergripande – och sen kan man klicka vidare. Jag gillar ju den där du hade där undertill (picture 3). Ja men då kanske man ska ha, om det nu är 4 olika områden, och sen kan man – då har man ett, topp-nyckeltal, du har samma grafik. Här (dashboard) känns det som att du har lite grönt här, lite rött där, och sen har du en graf... Asså det är väldigt petigt, är min känsla. Att det blir liksom inte enhetligt. Utan jag hade nog hellre, liksom, försökt lyfta det en nivå till – haft en övergripande meny på något vis, där man kanske lyfter fram, 1 KPI – Lite som... Jag tyckte det var snyggt det du gjort där, den nedersta (picture 3). Inte så där hemskt mycket grafik – och sen kan man klicka vidare, och, men försöka hålla det enhetligt. Här är liksom stora... En liten ruta, en stor ruta, och så har man försökt pussla ihop det här. Det är inte riktigt... Pedagogiskt.

P: Ja, ehm. Definitivt.

117

X: Utan man har gjort massor, man har, är lite dålig på att presentera det.

P: Ja, ehm. Okej, [namn] tack så mycket!

X: Ja, det är min synpunkt.

P: Tack så mycket för dina synpunkter, och, och din input.

P and X thank each other and say their farewells.

118

12.6.5. Protocol 5 The interview starts and X grants permission to record the interview.

P: Okay, so let me share my screen and start the video.

*The video plays*

P: So okay, that was the short little video.

X: It was very good – very well put together.

P: Thank you. So, I hope that was, a little bit helpful. So… Okay. And just to say this – I also have CodeScene running in the background, on my computer – so if you have any questions about any part during the video, then you can just let me know and I will arrange, arrange that.

X: Yeah.

P: So okay, we can now proceed to the questions. So, could you start by… Telling me a little bit more about yourself, your work role, and what you, what you basically do in your, in your work?

X: Yeah sure, so, ehm, as I mentioned before I, I came in at the beginning of January – technically as the CFO, but it is a very tiny company so that is a pretty grand title for a, for uhm, you know the guy who looks at everything to do with finance. And… pretty much everything that is not sales, marketing or development. So, uhm, I get involved in some legal work, operational work, and even some facility stuff, you know, sorting out stuff in the office. But my main area of responsibility is everything to do with finance. Given the stage for us, that, that is a bit more nuts-and-bolts stuff, like getting salaries made and doing bookkeeping, and a little bit less of the sort of strategic, financial planning and analysis, but once I get through these first few months of, setting up things in a good way, uhm, it is absolutely intention that I will be spending more of my time on that kind of higher level, analytical, uhm, planning sort of work. A bit less of the time on the, kind of technical bookkeeping, accounting, and all of those kind of things.

P: Okay, thank you, thank you for, for answering to that question. So okay, based on the video, what did you think stood out the most, in the tool, and why do you think that?

X: Well, well I, first thing I should say, obviously I know the tool a little bit it is not the first time I see it, but, as I mentioned before, I have not really been using it, [anonymity]. And the things that… It is not just one thing that stands out to me, well, or maybe the overarching thing I think is, how I feel it takes something which is very complex, and, contains a huge amount of different datapoints that you could potentially look at, at it turns it into something which is visually, and therefore sort of mentally, quite easy to start understanding and, and putting structure around. Uhm, so that, that is the thing that stood out to me from the video, but that is also the thing that stood out to me when I looked at this… [anonymity]

119

P: Okay, thank you for that answer. So okay, how relew… how relevant would you say the functions were… were that were presented in the video, for your work role?

X: Well for my work role, currently, ehm, none of it is particularly relevant, just because I am not operating at that level yet, it is {inaudible}, medial stuff that I got the get done first. But I, to the extend that it sort of helps, focusing on risks, it helps focusing on priorities, uhm, and it starts to give some ability, to kind of rank – things, and therefore make decisions between things, uhm, I could see, that it could be quite useful, uhm, in… Yeah, in a sort of later stage, when we get involved in – when I get more involved in making priority calls, for example – maybe we are only going to have a certain amount of money at a certain stage, and, we need to decide what we should focus on investing, in this bit of development, or in that bit of development, or if uh, one of the members of the development team is getting a better offer from another company, and we are thinking, how much extra package we should give, to try to keep them. I can see, those sorts of things, just, prioritizing, and trying to make sort of value judgements on things, that, that could be quite useful.

P: Perfect. Very good answer, thank you. Ehm, so… If we think about the design, the overall design of the program, what are your thoughts on the design, of, of CodeScene?

X: So overall I think, relatively speaking, so compared to, uhm, other applications – other tools, that I have seen over the years, I think it is, reasonably slick, and the way it tries to represent things graphically… I, I think is, is a very positive thing. So it is – the starting point I think is good, uhm, where I think it could… Do more of this, at the moment, as you mentioned in the beginning, I think it is more intuitive to someone who works as a developer or in a developer organization, okay, even within [name] there are many things you can look at. It might be more intuitive to that sort of a person, how they might use this. Whereas I think I think it can be useful for other kinds of, decision makers, and managers, so maybe… Something that was more use- case, or user profile, uhm, based, could be the next level to take it to {inaudible}. Narrowing down even further, the information, the most likely to be relevant to an analyst {inaudible}.

P: Mm, thank you, thank you. So, okay, we can say that there are, many possibilities of implementing different kinds of improvements, and changing stuff in order…

X: Yeah.

P:… to make the program more suitable for someone like you, at a CFO position. Ehm, so what specific, or concrete improvement opportunities do you see in CodeScene?

X: I think maybe something, uhm… Something more at the entry level, when you sort of first come into CodeScene, that helps, uhm… Differentiate between different parts, that might be relevant for people to take. Because it is always going to be a “I am a developer organization leader and I want to just look at loads of different things, and I know how to do that in CodeScene” – there is

120 always going to be that sort of user. But uhm, I, I think it would be useful, at the sort of point of entry, to always have a choice between - Okay how do you {inaudible} wanting to use, or what are you wanting to use CodeScene for today? And if it is the sort of developer, nitty-gritty, I am happy to, do my own analyses, and I have a deeper understanding etc, then that is kind of one path. But if it is another path, you know I… I am a – want to look at my business from an executive level, and understand, uhm… The, people, risks in my development team – That could be one, there could be another one, you know around what to look at, “It is budget time, and I need to figure out how to prioritize resource, investment, help me understand the different tradeoffs so that I can make, together with my developing team – that could be another one. So just, just something, that would just help, uhm, frame the different kinds of use cases and then, kind of, almost guide – apart from the developer, sort of gurus, for the other ones – guide them through “okay, you can sort of ignore all these other features in CodeScene” and would just present you with these particular things, which we think would be most relevant to answering those questions that you have.

P: Mhm. Thank you, very good answer. Uhm, so, when you talk about something that helps you, in, in… Or something that explains what, what different things can do for you, is… Do you have in mind like a documentation that you will follow, like a piece of document, that you will have up - on either one of your screens…

X: No, I am more thinking of, of like, almost like a guided workflow, so based on what you… Would choose, you would have, sort of bunch of options, that it suggests to you. Uhm, for the most… frequent, use cases that we can think of, and you click on one of those, and based on what you then click, it sort of – then brings up a different screen which kinds of summarizes, the first level down, of “okay, these are sort of the 4 things CodeScene could tell you which, we think are the most relevant to this particular use case, and then, uhm you can sort of click into each one, and, and once again the next level down, it does not show you absolutely everything at that level, it just shows you the – a few things, that, are most relevant, again to that particular line of decision making, or question.

P: Mm, yeah, thank you for that, answer. So maybe, we could… Uhm, just to put a name to what you are referring to – like an interactive walkthrough, maybe? Something in, in, in….

X: Yeah, it is almost like a guided… yeah, interactive – you do need to respond a little bit, feedback…

P: Mhm.

X:… the user says that they are this kind of user, then, we need to adapt to that. But, uhm, yeah, it is basically for all the use cases where the user is not, a sort of person that either is able to navigate, endless amounts of detail, or, maybe even does not want to, navigate all the various different options. For all of those use cases, more this kind of, simpler, less “knowledgeable users”, is to, uhm, kind of make the journey through CodeScene, to get to the information that CodeScene give them, uhm, a guided journey almost.

121

P: Yeah, sure, sure. Thank you, thank you for that. So okay, now, to… some other context, so based on your work role, your work role now, and the things you will be doing in the future – How do you want, uhm, or can you, can you name and explain the things that you want to see in a software analytics tool – like what are the functions, what are the information – how do you want to see it on your screen, and a little bit, stuff like that?

X: Yeah. I think – firstly for a CFO – or even you know, just a finance leader, uhm, the reality is probably that it is not going to be the kind of tool that will be relevant, super super often. It will only be at certain points, in a cycle of managing the business and planning the business – instead of reviewing performance. Although it could be every quarter, it could be every half year, you know maybe in some cases it would be every month. But it is a, it is a starting framework, it is not going to be something that I could see myself… Uhm, needing or wanting to use every day. Uhm, and the – sort of information, that I would like to know, is probably things like… As a finance guy you are very interested in allocation of resources. And things like efficiency. And risks. So I would like to know whatever CodeScene could tell me, actually, about those things for my business, so – What are my… What are my risks, in my development organization, and that could be particularly important for [name], but I think most companies these days, have a sort of software component, so it is probably important to every company, ehm… And then, uhm, what are the, you know tradeoffs… I suppose - if I have X amount of, either development time, or money that I could spend on my development organization, what could that – what could that get me, uhm, and what would CodeScene suggest, sort of better ways, and less good ways to allocating that resource. And I do not even know if CodeScene could do that at this point, I do not know if it can, kind of represent what are riskier areas, and what are kind of high-debt areas etc, so from there, to get to some kind of proposal – that these are the relative tradeoffs you could do, I imagine that is possible. Those are the sorts of things, I would like to be able to see.

P: Okay, okay. Thank you for that answer. Okay, so yeah, different kind of things having to do with resource allocation, and ehm… Maybe somehow, ehm, connect that to, to different finance metrics and stuff that could basically be useful for a CFO. But now comes the question, right, so we were a little bit on WHAT type of information you would like to have,

X: Yeah.

P: But when it comes to the question “HOW this information could be, or should be presented?” – what are your thoughts on that?

X: Well, simplicity is always good, and I kind of tend to, there is a phrase that “Simplicity is not always good, just for itself, but simplicity, the other side of complexity, that, that is normally a good thing” – so if you have gone through a complex process, as CodeScene has done to do the analysis, then you probably have something interesting to say – so be able to present that complexity in a simple way, that is super valuable. So whatever CodeScene aims to present for the non – kind of super-techy developer audience as I think, should not be shy, of making – trying to make it really simple. I think sometimes developers can feel, that if something is really complicated to do, then it is sort of undervalued

122 if you present it in a super simple way. Because then they are missing all the endless, development things you had to do, to create this. But I do think, that for this audience, uhm, that that is actually really important. Ehm, so graphical is good, tables are also good, {inaudible} that is what people tend to like. Numbers, instead of sort of black and white things. So you know some, some relative quantification, ehm, I think would also be useful. But beyond that – because it does not exist yet, it is sort of a little bit hard… at least for me to visualize exactly how I think it should be best presented on the screen.

P: Yeah, yeah very good answer. Thank you, for, for that answer. So you were a little bit in on tables, and different stuff – do you see any value in providing the end user with customizability, for example “Oh okay, I want this information presented in a short, ehm, in a short text manner”, or “You know what I want to see this as a table, or as a circle diagram” etc. Do you find – do you think that would useable, to give a lot of customizability, options for the user?

X: I think… Initially that is probably more “icing on the cake” – I think the initial, first thing to take off would be – be able to present – firstly figure out, what are the, sort of top 3 things, that I should be presenting to this user from CodeScene for the particular thing there, looking at. That is, kind of difficult job number 1, to figure out, ehm, and then after that, it is presenting that information, in a way which, which is intuitive and simple. For me the customization ability that, that is really like the, when CodeScene has done both of those difficult things, then yeah, then that is, probably, something it could offer, but to some extent… As long as it is possible for the user to sort of change… and sort of use whatever standard tables, and standard views they are given, to look at different things – or maybe recalibrate a little bit – I think that is the more important form of customization, than “do I want to have it as a funky pie-chart, or some bar, bar chart” – I am not sure, ehm, I do not think that that sort of changing exactly how it is represented, that type of customization is the critical thing.

P: Yeah, okay, thank you…

X: But I am a bit old school, you know, sort of – would just set the framework and then present the data – but I sort of suspect many finance people might, might actually prefer it that way as well, that, you know, the data is what the data is, standard table, uh, the data is going to change over time but the table does not change, and something like…

P: Yeah, definitely, okay, thank you for that answer. So know I think that, maybe we could zoom out, a bit, zoom out, and, go ahead with this following question – so how would the perfect – the perfect software analytics tool look like, in your opinion? And you can be as creative as you want to, there are no limits for what is possible.

X: Well I, I, I think ehm, so I would, log on… And it would present me with – so that I could choose, what I wanted to use it to do, out of a sort of high level intuitive, kind of real world, type, ehm, decisions and all – things that I wanted to do, like, evaluate the efficiency of my development organization, assess the risk of late delivery of particular projects, ehm… Analyze the, or quantify the different tradeoffs of how I could spent money with my developer organization – those, those kind of high-level things, present me with those, and I can just click

123 on one of them, and it would bring up, the “Ok, here is a… Here is a assess… Or if you just, select these 3 or 4 things, tell us these bits of data that CodeScene needs, then CodeScene kind of populates a bunch of tables, and maybe even writes some stuff – preconfigured text, telling you the answer, or telling you what the data is suggesting to you. So that it actually becomes a, just super simple. Because I do no think that, in the ideal world, I think, for the non-developer users, probably, the successful situation is they do not spend very much time in CodeScene. It is that good - to answer the question, someone wants, CodeScene makes it very quick and easy, to get to that. And that might seem, again, for a developer, that sort of spend their lives creating the product, it might seem like a, “but that is not very good - they are only coming in and going out really quickly”, instead they want to “look at my great bit of software that I have built”, but ehm, I do really think that that is success, if they can achieve that – for those kind of stakeholders.

P: Yea, it, it totally makes sense when you put it that way. That a program, like CodeScene, would ultimately reduce the amount of time that, that higher-level stakeholders need to spend, in that program, because every second longer, that they have to spend in that program, it is, ehm… it could be explained by… By it being, too difficult in some way, so if you have to spend 1 hour – then that probably means…

X: Yeah.

P:… that you could introduce a lot more simplicity and, just, remove…

X: Yeah, yeah yeah yeah.

P:… a lot different stuff – yeah! Thank you for that input, it was very interesting to hear that. Ehm. Ok, so, so this question kind of goes back, maybe overlaps with a previous one, ehm, but just to, just to make it very super clear, and I want to hear your opinion on this – What is your definition of “Usability”, when it comes to software analytics tools?

X: I think it all goes back to fit to the user. Fit to the use case. These ability – how it physically looks, can be very different, depending on the use case, so the… We have done a good job with the usability if, we have made, uhm, the whole sort of flow - super relevant, and tailed it to the particular user case. So that can mean a very detailed flow for a certain techy developer, or a super simple flow, if it is a finance guy who just wants, an answer to just one question.

P: Mhm. Thank you…

X: And maybe another way to say it, is that I think it is actually limiting the options, or removing – uhm, options and sort of noise, uhm… To only present the user with the things that are relevant to them in that particular use case. And I – a parallel that I have in my mind in the moment, is that I am, I am evaluating different finance systems, because we are currently using – what I think is a clunky sort of, 1990’s style finance system – and I am looking at, I really want, I need a different system, and I have really prioritized, looking at system which I feel could have been developed in a much modern way. Ehm… And the big difference I noticed, is actually just that – that they can be equally

124 complicated behind the scenes – but the more modern ones, are a lot more focused on hiding from the user any stuff which they actually do not need to bother about, in certain scenarios, instead of the old system, no matter what you do – you have like 5 million different potential things you could click, or different tabs you could be on. Even if they are totally irrelevant to the task.

P: Yeah, I think you are definitely on to something, with, with that. I mean – this is totally out of context, but even Elon Musk in, in their latest Tesla model…

X: Yeah.

P:… I think that they are going to remove the reverse button – or somehow hide it from the user, so that the car will know, when the user will want to go back. And it sound really crazy…

X: Wow.

P:… It sounds really crazy…

X: It sounds Elon Musk – yeah.

P: But yeah, I guess that… I mean the perfect program would just be, maybe – one button on the screen, you click on it – and it knows exactly everything you want, and just presents it to you. So yeah… But yeah, thank you for that answer. So, okay… And this was a little bit - your answer to, to one of my questions. You mentioned roles in the beginning when you open up the program, it would be nice to, somehow, be able to, separate between developers, and maybe other stakeholders, so that they get…

X: Yeah.

P:… The view that they want to. So this “separation of concerns”, how do you see that being implemented in a, in a software analytics tool, is it like you open up the program and there are different views, and you just click on them, or maybe something else?

X: Well I, that is an interesting question because I almost have a double role here, I am both – maybe I could both talk about what a CFO would want, and I am also the CFO of [name] [anonymity]. I think one of the things CodeScene needs to figure out is that, in a bit more detail, is, beyond developers. Even within developers, there is a bunch of different profiles, who would require slightly different things, from CodeScene. [anonymity]. But to put it, then beyond there, as your asking, I think we still need to get a little bit clearer – who do we think are the different user profiles, what are the use cases. There is definitely one for some sort of executive, who would want to use it to evaluate an investment. [anonymity]. A company looking to buy another software company – they want to know which developers they need to make sure, stay with it, when they buy it, or evaluate. How the quality of the code is, um, so that is absolutely one use case. [anonymity]. Because maybe there is only a developer type use case, and then one sort of non-developer – I do not think it is that way, I think there is a few more, but uhm… That is, yeah. For me that is still a bit work to be done. So, I guess there are two different ways you could filter between

125

– you can either base it on the user profile, so when they set it up, they tell CodeScene that they are a developer, that when they log in, they are sort of automatically guided to that particular view. That is sort of one option. But that sort of seems that people will never really want to, switch, between, different uses, which maybe they will maybe they will not. [anonymity]. But if it would be that people might want to switch between – then it would be better to have it as an explicit, kind of – option, or maybe… 4 tiles or something on the entry screen, and one is for developers, and click on that, and go straight in there, or one for, you know the executive and the other 2 for other stuff. Uhm… I think it is, for me it is, it is one of those 2 options, depending on how many additional use cases really are out there, and how much, sort of multiple use cases there are going to be.

P: Mm. Okay, thank you for that answer. So, okay we have arrived on… To the 2 last questions of the interview. And these questions are a bit more open, maybe, I could… frame it that way. Ehm. So the first question will be about a picture which shows 3 different dashboards – and, the second question will be about CodeScene’s own dashboard. Okay, so I am going to share my screen now, and show you the first picture.

*Shows the picture*

P: Okay, so why did I say that, it is a “open-question”? It is a open question as I want to hear your input on, on the different dashboards, so, it can be everything, it can be emotions, it can be, stuff that you do not like, or stuff that you do like, or maybe stuff, that you really, really like and would like to see in CodeScene, but maybe in another way – So it is not super important – or I will say, it is not important at all, what the different types of things are saying. For example “Catering”, “Cargo”, and “Passenger” (picture 3), like…

X: Yeah, yeah, I get it.

P: It is not important – just the way that information is shown, and as you mentioned, you said something about 4 tiles, here we have 5 tiles (picture 3), for example. And just different visual aspects of the dashboards. I would just like to hear your input, if you have any interesting remarks on something maybe?

X: Well I, I would say – automatically without thinking about it, gravitate to the one at the top right (picture 3), because that is a bit more traditional, ehm… almost like a PowerPoint slide that I might be used to, either looking at or comparing, as a sort of finance guy. Ehm. So for that sort of use case, maybe that is… The more, sort of uhm… View that would be relevant to, uhm, kind of have in the back of the mind. The, ehm, I do like – the other 2 I actually do like them. Because to me they feel a little bit modern – whereas the top right one (picture 3) feels a bit more, traditional so to say. And there are good things, sticking with the tradition. But there is also, sometimes you miss some of the benefits of, kind of looking at it… a bit “fresh”. Uhm. The one at the bottom (picture 2) to me, the number 2, feels more like, uhm, wherever that would fit in, any kind of hierarchy, that feels a bit more lower, lower level to me. Because there is a lot of metrics on there, and lots of information. And it is, not, not presented in a guided way, or a contextual way - the same way the top right one

126 is (picture 3) – so that could be more maybe a bit for like a click-through. In my view. Ehm, and the top left one (picture 1) – I actually almost like that one the most out of all of them, but… It just looks very clean, and it is, um, looks a little bit more modern, but without being too funky, but, but… I, I think whether they are good, bad or ugly, it all comes back to “what is, who is the user and what do they want out of CodeScene”, so… It, could be that the top left (picture 1) type of way of presenting stuff, because it does not have any text that naturally guides you through, and it is, just sort of 6 things, with no obvious priority of… What is the more important table, versus what is less important, and how do they relate to each other – I mean that is not clear. Maybe, maybe that… It is not, the good way to represent stuff, for certain kind of users. So that is the reactions that I have. Kind of spontaneously.

P: Mm. Yeah, very good input. Ehm, yeah…

X: And maybe one, it is a little bit of to the side, but this is context, uhm, working in finance, I have spent a lot of time fiddling around with Excel, um. And over the years – because you can do so many things with Excel, calculations, in… You know clever ways, manipulating the data, or even graphically, and all kinds of conditional, formatting, and all sorts of things you can do. And Excel over the years, have also added lots of bells and whistles to make it possible to uhm, make the graphs and charts even more slick, and mor exciting, but… And I have seen a lot of people over the years, spending lot of time, trying to use and incorporate, these kind of cool new things in how, data is shown, but, but I have actually, generally found that, a bit of, of waste of time, because that, that is not really the thing, uhm – which is important. The thing that is important is the data, and what the data is telling you, that comes out, in a clear way. It does not need to be, sort of super funky, cool looking, cool looking… chart. If the message could, just as well be told, by much simpler charts, with, with some of {inaudible} makes it very obvious what the trend is, or the key data point is. So uhm, I think… Basic ways of representing stuff, as a starting point, are normally the best, and then, only putting the kind of fancy, slick looking touches on, the things that really make a difference. That, that is just my view.

P: Yeah, ok, thank you a lot for that input, ehm… Very good input. So, okay. Last question. Let us share my screen. Where do we have… Okay so we are back, to, to CodeScene.

*Shows the dashboard*

P: I am going to click on a project. And this is how the dashboard, looks today. I am going to scroll, a little bit down. Sometimes a little bit up. But this is how the dashboard looks like today in CodeScene. I would like to hear, very similar input, to, to the previous question. What do you think?

X: So I, spontaneously I think it looks nice. Clean. Ehm, quite slick, but still quite simple – not overly trying to show of lots of clever ways of representing stuff. So that all I really like. What I think is the, the thing CodeScene needs to work on, and particularly for some of these other use cases, but maybe also within the development use cases, ehm… Is, I think it is not… If this is a dashboard, then that is a lot of information – on the dashboard. And in my mind a dashboard should kind of – just be the critical few things, and it should be

127 really obvious, that, you know this is the top level stuff, and if you want to drill down you go to the next metric. So I think helping, helping ehm, the user to understand how do all these different things relate to each other – you know maybe one tile, is showing something which, is not the first thing you should look at, you should probably only look at it if you have spotted something on another thing, which is, sort of a higher level thing. So, sort of filtering, what is, almost what is the connection between the different tiles, if there is any, ehm, and what is the ideal sequence that you should be looking at stuff. What is the kind of - the first level thing to look at. And then, depending what you see then, what could be the, the second, or third level thing to look at. Ehm. So it is, yeah it is actually really that prioritization of what is shown, and in what order. And making it obvious what connects, so what – all the contributions {inaudible} does that have any relation to, delivery effectiveness, or that is like a totally different thing? Ehm, and the “Branch delivery risk” versus the “Interactive hotspots map”, how do they relate to each other – or is that answering two different questions?

P: Yeah. Okay, perfect, so that was the last questions.

X: Yeah.

P: Thank you very much for attending the interview, you have given me a lot of very good input.

Discussions outside the realm of this interview continues for a time.

P and X thank each other and say their farewells.

128