The most interesting reports from Analyst Days 2015

On April 17-18, 2015, the 4th International Conference on Systems and Business Analysis Analyst Days 2015 was held in Minsk. In many ways, thanks to this event in the CIS countries a vibrant and active community of analysts has been formed, where everyone is ready to share his valuable experience. This year the conference was attended by more than 300 industry professionals, including our company's employees. Despite the fact that the overall level of reports this year is quite high and each of them deserves attention, we would like to highlight those that are more concerned with the practical aspects of the analyst’s work.

Method "Value Conflict Mapping +"

In the work of the analyst, situations are not uncommon when, for various reasons, important business requirements or contradictions in the requirements of interested parties are found out after the development of functional requirements. At best, the matter is limited to minor changes in the design of the solution. However, it happens that the introduction of new conditions leads to the need to return to the stage of clarifying business requirements and, possibly, subsequently designing the system from scratch. Naturally, this causes a rise in the cost of the project and a shift in deadlines, which leads to a well-founded dissatisfaction of the customer.

Andrei Kuryan, in his report, presented a rather interesting method “Value Conflict Mapping +” (hereinafter - VCM +), designed to identify contradictions in the requirements of stakeholders, as well as to search for hidden requirements. That is, this method is designed to solve the above problem at the initial stage. Each system is divided into two parts - the "useful" and "harmful" subsystems. Useful is the one that is designed and developed to benefit. Harmful subsystem - one that arises from the creation of a useful system and has an undesirable effect. Such a system arises by itself and is an integral part of a useful system. As a rule, this is the result of inconsistency of the requirements of the interested parties. In other words, the same decision may be beneficial to one representative of the customer, but harm to another. The essence of the VCM + method is to identify the harmful system and take steps to eliminate it or minimize the negative effect.

Using knowledge of harmful and useful systems, the analyst should perform the following actions when designing solutions:

1. Identify solutions for the most important business requirements.
2. For each solution, determine the so-called “main parameter” and its value.
3. Invert the parameter value and form an inverted solution.
4. Finally, find those stakeholders for whom the inverted solution is more important than the original one.

Andrei demonstrated a real case of co-existence of harmful and useful systems. One logistics company installed GPS sensors on their cars to monitor the location of cargo. The data that the managers received could be used to monitor real-time fuel consumption. After some time, the sensors began to fail. As a result of the check, it turned out that the drivers of the cars deliberately broke the sensors. Using the VCM + method, it would be possible at the very beginning to reveal a contradiction in the interests of two parties: the managers demanded clear data on fuel consumption, and the drivers were extremely disinterested in that someone would find out about cases of fuel theft.
')
In the above example, the value of this method is clearly visible: after identifying inconsistencies, the analyst gets enough information to improve the solution. And for the previously uninterested party, the flaw will turn into dignity. To resolve a conflict of interest, it was decided to reward drivers in the amount of fuel saved, and the business ceased to incur losses related to the repair or replacement of sensors.

Let us examine this example in more detail with steps. The main business requirement (1) is the desire of managers to obtain accurate information on fuel consumption in real time. The solution (1) is the use of those sensors. In this case, the main parameter (2) is already formulated in the requirements - the amount of fuel actually consumed. The main participants - managers - are interested in spending as little as possible. Inverting the value of the parameter (3), we determine that the reverse value is a high level of fuel consumption. Finally, we begin to look for (4) those who are interested in having managers receive information about high fuel consumption, i.e. false, and could not verify this information. Having an idea about the circle of persons interacting with the decision, the conclusion suggests itself.

Despite the obvious usefulness of VCM +, it has one drawback - the impossibility of using it at the early stages of requirements collection, before creating functional requirements. The fact is that the identification of serious contradictions may lead to the need to return to the stage of developing a new version of the solution or even to the stage of collecting requirements. This is especially painful for large systems, where the full picture can often be seen only after designing a large part of the solution. For this reason, the use of the technique seems to be more efficient when developing small and medium-sized systems from scratch, where solution design takes less time and, accordingly, the cost of error is less. When developing large systems from scratch, other methods will need to be applied, which allow to identify inconsistencies at the requirements gathering stage; Nevertheless, the use of the method in the refinement of existing systems can also be very effective.

In connection with the specifics of one of our projects, we plan to use the VCM + method to search for contradictions in requirements between customers and end users of the internal automated system, which will go into operation in the next six months. We will write a separate article about the results of our research.

Method “Customer Journey Mapping”

Also, it is worth mentioning the report by Yuri Vedenin, in which the Customer Journey Mapping method (hereinafter - CJM) was considered. CJM is designed to identify the user experience gained from interacting with any system (including informational) from the moment of the first contact, in the process of using and further servicing. In general, the method allows you to understand at what points the provided service causes the user positive emotions, and at which points it still needs to be improved. The method does not have a strictly regulated notation, which provides the possibility of rapid development and space for customization for a specific project.

Building a CJM consists of the following basic recommended steps:

1. The choice of the user and its detailed description. It is necessary to put here any information about users of the system that may be useful: age, status, gender, marital status, what they love or hate, etc.
2. Fixing user and business goals. When building a map, it is necessary to determine how easily the user achieves his goals and how the business goals are achieved.
3. Description of the sequence of steps that the user goes through before reaching his goals.
4. Fixation of specific steps at each stage.
5. Plotting user satisfaction with each of the steps on any rating scale. This chart allows you to visualize all the pain points that you need to go through in order to achieve this goal.

Below are a few sample maps.

Figure 1. CJM from Temkin Group:



Figure 2. Example CJM in uxpressia.com online service:



The card can and should be used in the following cases:

• When you need to understand the experience of different user groups.
• When it is necessary to find and eliminate the causes of user dissatisfaction when working with the system.
• To explore opportunities to improve the efficiency of the system.
• When setting development priorities or improving the system.
• When you want to provide the user with a visual result of what was and how the process has improved. In this case, the imposition of two cards - "was" and "became".

Thus, CJM has the following advantages:

• Allows you to identify the most painful for the user points in the use of the system.
• Provides a single user experience when in contact with the system
• When engaging end users and / or customer, reduces the likelihood of designing the wrong decisions.

One of our large-scale projects on automating business processes is approaching the implementation stage. And we plan to use the CJM method, namely the construction of a graph of user satisfaction. Thus, we want to visually compare the problems that users faced without having a system, and how we solved these problems.

In our opinion, at the initial stage of the project, the CJM method can be effectively used in conjunction with the reverse analysis of the requirements of the developed HTML prototypes.

Reverse HTML Prototype Analysis

The report of Nikolai Kireev also seemed to us noteworthy. It raised the topic of developing dynamic HTML prototypes for reversing requirements analysis , used instead of creating functional specifications or coding.

According to the author of the report, identifying and detailing functional requirements at the start of a project is fraught with significant risks: omitting requirements, adding unnecessary functionality to the solution, inconsistency of requirements after a certain period of time due to changes in processes. For this reason, the final verdict on the completeness of the decision is actually made at the stage of system implementation. In this case, the cost of the error may be enormous. To solve this problem, Nikolai proposes an alternative system design: using the Axure tool, create a dynamic prototype that mimics the functionality of the system.

Prototype development begins with defining user roles and business requirements that users will perform in the system. Then the system is designed by developing a prototype according to the priorities set at the stage of determining business requirements. Testing the developed prototype, the designer himself first, and then with all interested parties, works out the main and alternative flows in the system. Thus, at a very early stage, ineffective solutions are identified when the cost of the error is less. Only after creating the prototype is the minimum required functional specification. This approach provides an opportunity, if necessary, to return back to business requirements, refine them and identify new ones. And this, in turn, allows to reveal the imperfection of existing business processes during their automation.

Dynamic prototypes are most appropriate when identifying requirements in the following cases:

• When creating applications with high-loaded graphical interfaces.
• When designing systems where the price of a user error is very high and it is necessary to eliminate the risks of such errors.
• When designing systems that have no close analogues.
• With unclear, unstable and frequently changing requirements.

The use of a dynamic prototype can significantly reduce the cost of such projects, eliminating the processing system at a later stage, when the customer finally gets the system in use and his expectations do not coincide with reality.

The considered method of system design has its drawbacks:

• Compared with the creation of static layouts, the development of the prototype takes considerable time.
• It is quite difficult to “sell” to the customer a prototype, which, in his opinion, will practically bring no benefit in the future.

However, in our opinion, these disadvantages overlap with tangible benefits:

• The prototype gives users or the customer the opportunity to “touch” the system at a very early stage, which contributes to obtaining valuable feedback. In addition, the process of interaction with the prototype involves the user in the project and increases its loyalty.
• The relative ease of making changes after customer reviews or users.
• Early UX design reduces user errors.

If kept up to date during project implementation, the prototype can be used to train first users.

Our experience confirms this; earlier we used reverse analysis based on HTML prototypes in one of the automation projects within the company. The main problem of the project was the presence of a large number of stakeholders and the inconsistency of their requirements, which, moreover, changed quite often. A special place in this process was occupied by the coordination of requirements with the end users of the system.

Since the process of approving functional specifications turned out to be not sufficiently effective - interested parties did not have the opportunity to get a handle on large volumes of documentation - we decided to create a dynamic prototype in Axure and continue to identify and approve requirements with its help. Thanks to the opportunity for stakeholders to “touch” the product at an early stage, we were able to identify many hidden requirements and coordinate the details of the solution among all the project participants. However, this is a topic for a separate article.