What threatens long-term construction in development and what difficulties to face on this path? As a business analyst at a company that has been developing and supporting a single product (SED) for 15 years, I decided to share my thoughts and examples from practice. The issue of requirements management in any software products with a long period of implementation is a pressing issue for analysts, project managers and product owners. And, perhaps, for direct partners and customers of Docsvision, who are awaiting new versions and are interested in the appearance of new functionality.

What are the results of the race for the terms and when flexible methodologies do not fit

Why is there a tendency among vendor companies to abandon short-term projects (in our understanding, these are products with a release period of up to 1 year) and the policy of private releases, as well as flexible methodologies in development?
It clearly gives an answer to the question of the picture, in which you can choose only one intersection:


')
As a rule, in a short-term project there is no possibility to implement a large amount of new functionality while maintaining the proper level of quality, therefore, customers often do not see for themselves the benefits of switching to a new version (any update contains a certain amount of risk, and they wonder if it is worth it?) . And for a vendor, any release is an expensive pleasure, since the full version is a set of installation, documentation, performance testing, regression testing, update and compatibility testing, and a whole range of measures that need to be completed in a relatively short time. Returning to the picture above, we find ourselves at the intersection of Qualitatively-Quickly or Quickly-Cheaply. Since the resources are not unlimited, this will be the second intersection (read, crookedly). The conclusion suggests itself: frequent updating of the product version is unprofitable for both parties.

After analyzing these factors, we at one time came to the decision to change the policy of product release: to pay attention, first of all, to quality, and not the pursuit of terms. As a result, with the same resources, we get long-term construction (however, instead of full-fledged releases, we began to release packages of cumulative updates to fill the waiting time for the next version).

One way or another, many vendors who have been on the market for years are coming up with similar solutions: this approach is also used in companies of such a scale as Microsoft or Adobe. But at the stage of development or because of small scale, in a number of products you should not refuse from the policy of frequent releases.

Development Methodologies

We now turn to the development methodology. Flexible methodologies that are popular today, known to all of Scrum / Kanban by their principles, for example, did not suit us, since not designed for the volume and time required for all phases of the implementation of features. In addition, they do not take into account the specifics of the distribution of work within our team. We did not completely reject these methodologies in the company; they found application in other Docsvision projects.

I will not discover America if I say that in a pure form no one uses this or that methodology. As for the Platform development project, I can say that recently we have used our own, mixed methodology. This may be a topic for a separate article, but within this framework it is worth noting that this is to some extent Waterfall with Agile elements (yes, it happens!): On the one hand, the project stages are clearly defined in the long term, there is a detailed project documentation for each stage, quality has top priority compared to resources and time, and all of these are integral features of the cascade development model. This allows us to streamline the production process and make it more manageable. On the other hand, there is a moving list of requirements, change management, which is characteristic of a flexible methodology.

The policy of cumulative updates allows you to provide ready-made functionality until the release of the main version. Attracting end customers to the process allows you to make changes to the version based on the data obtained. We could not afford it, using the classic Waterfall, because in it the requirements are strictly defined and the end user gets a working product only after the release version. At first glance, we used the advantages of each of the approaches, and upon closer inspection, we also received problems.

Protracted problems

1. A large number of requirements, the final list of which was not originally approved
On the one hand, by increasing the time of implementation, it is possible to increase the number of requirements included in the version. Some numbers: in the short-term (on average, semi-annual cycle) release, we released about 35 features in the version, in the latest version with a long-term period, so far about 100 were announced. At the same time, in 10 years, the database of requirements contained almost 1600 potential features that customers expect to see in the product, and the list of scheduled for the next version is gradually growing. A logical question: how long will this go on?

2. Prioritization and evaluation
The solution to the question voiced in the previous paragraph is in the prioritization among the requirements selected by the product owner, taking into account the estimates obtained (development, testing, documentation and risks), which are made on the basis of the specification provided by the analyst. Each company has its own approach to setting priorities. This may be the study of statistics on the request for the implementation of a particular feature, the results of competitive analysis, partnership obligations, and common sense has not been canceled. We regularly conduct surveys among customers and partners, trying to get as much information from the outside (for example, we have an “Ideas and suggestions” portal where everyone can leave a request or vote for existing proposals). Methods of obtaining information are also seminars, webinars and other public events. Based on all the data obtained, priorities are set, but they can change, this has to be monitored in real time. In our practice, the greatest influence on the position of a feature in the list of requirements is its criticality for projects and the general demand: first necessary, then desired. The overall effect of the implementation of functionality can contribute to increasing priority - this is wow / killer features.

For example, in one of the versions of Docsvision, the status management system in the system (active / on vacation / on a business trip) was declared by the employee himself, indicating the period of absence and the deputy. Those. the employee, going on leave on Monday next week, can indicate on Friday the time of his absence and the employee replacing him. The latter, when working in the system, starting from Monday, receives a notification that he has been appointed as deputy during the designated period. This feature eventually received a higher priority than the functionality required by many users to control the uniqueness of documents registered in the system.

3. General and particular



This problem occurs for the first time in any product at the time of the formation of the list of requirements, regardless of the period of its implementation. Unlike the design solution, where the movement goes from the general to the particular, in the product the opposite is true. We receive individual requests from outside, while customers often describe each of their specific tasks, and there may be several wishes on a similar topic. The key task is to reduce and take them all into account in a specific requirement. But the problem may arise both repeatedly and for the period that the version is being developed (hello, long-term construction), interested parties may propose new solutions or clarify the nuances. Sometimes it is necessary to make adjustments for these proposals in the form of change requests, which may eventually result in a shift in the Stop Development point. It is not always possible to reduce it simply to the record "1601st wishes for the development of the system."

As a business analyst for a product, I have to find a compromise in every such case - a universal solution that would suit everyone.

I will give an example: a scenario for processing negative decisions (refusals) when coordinating documents. Initially, simple logic was implemented in the system, when, when a negative decision was received from one of the participants, the agreement simply went on to other matching persons. Then they realized the possibility, upon receipt of a refusal, to return the agreement to the state of preparation, so that the initiating employee had the opportunity to make adjustments to the document and start the coordination again. After the proposals for revisions came: “make it so that the agreement is continued, but it was possible to make changes to the document by running a consolidation upon refusal”, “but we only need the gene. Director canceled coordination. " As a result, there appeared a setting-switch of different modes of processing a negative decision, and this setting can be used differently for each separate stage.

4. Icebergs problem



Speech in this case is not about the unfortunate passengers and the team of the legendary "Titanic", perished in the Atlantic. I call icebergs simple at first glance requirements (“add a check mark / button / line”), which, as it turns out on closer examination, affect other components of the system and require additional modifications. True scales, as a rule, come to light at the time of design, but sometimes it happens during development. Therefore, it is better to highlight such requirements immediately and consider more closely what needs to be done, what impact the revision will have on the existing functionality, and adjust the estimates. After all, the sooner an iceberg is noticed, the more chances to avoid a collision, and in long-term projects with a large number of interrelated requirements, the likelihood of such a situation increases several times.

Not so long ago, I was working on an on-demand specification rated at just a couple of hours of development. The requirement was reduced to the fact that you need to display the search string in the open directory of choice. This string and search functionality was already implemented, it was simply not displayed when the directory was opened to select a value. At first glance, nothing complicated. However, at the same time, a requirement was made that allows us to limit the search for values ​​from the controls in the cards that work with this directory. Implemented several modes that limit the choice. But the search string in the directory has always worked on all values ​​and did not know anything about the new modes, which, as it turned out, must also be supported. It was necessary to increase the functionality, the evaluation, of course, increased.

But it is not always possible to detect the requirement-iceberg in the early stages.

It happened in our practice to encounter such a thing already under active development. Then the implementation received a requirement to refine the localization (choice of value depending on the interface language) of the general properties of the controls: labels, alignment, etc. According to our primary estimates, the work was reduced to the implementation of a general algorithm for all controls, but in reality it turned out that each of the controls has its own characteristics and had to be done separately for some. The total difference in implementation costs compared with the initial estimate was about 45 hours.

5. "Heavy" features: to divide or not to divide?
In a long-term project, we can afford to implement not only relatively simple requirements, but also more complex features, one development of which requires 80 hours to complete. As a rule, for each such refinement, detailed and extensive TZ, a lot of test cases, etc. are needed. Here it becomes necessary to divide the requirement into several parts, because it is easier to perceive a smaller amount of information. But, first, with the separation of requirements, the “picture as a whole” is lost. Secondly, the total number of version requirements is increasing, which affects the effectiveness of control, assessment and change management. In our case, if we divide the voiced above 100 features, we will get about a threefold increase in the number of requirements. Of course, this is not a reason to refuse to separate certain requirements into components. It’s worth sharing, but where it’s really necessary: ​​for example, if there are independent improvements within the same feature, for example, in a situation where the scenario is common, but to implement it, you need to implement new functionality in different parts of the system.

Or in the case of simplification of the implementation: if you need to start to make the necessary minimum, and the rest to plan for the future.

An example where the requirement can be divided.
The initial requirement is: “Support integration with Microsoft Lync 2013 in card controls with the ability to save the history of dialogs”.
After separation: “Maintain integration with Microsoft Lync 2013 in card controls” and “Implement the ability to save the history of Microsoft Lync 2013 dialogs in a card”.

Example, when the requirement is better not to divide, despite the fact that different objects are being finalized.
“It is necessary to make a mapping by digits in the controls Number and Integer. For example, instead of 1230,000, show 1,230,000. If possible, make the same improvements for the Table. ”

Release close

Imagine that all requirements are implemented, recent errors are corrected, documentation is about to be ready, and everyone is looking forward to the end of the project and release. At this stage, we can look at the results of their work and take stock. The main task of the final stage is to identify design errors and shortcomings “without a hitch”, to review the re-implementation of all requirements, especially interrelated, as well as those implemented at the very beginning of the project. For long-term projects, this voluminous task is better to break into iterations. This will be the preliminary acceptance of the product. Our preliminary acceptance work is performed by the analyst and the owner of the product. Some developers fix bugs as errors (before the main product acceptance and release), and significant flaws and design errors can be fixed as requirements for the next versions (with the prospect of being included in cumulative updates). Thus, as we approach the release date and the beginning of the official acceptance of the product by management and technical support, we get a comprehensive assessment of the results and, in part, a list of requirements for the next version.

Thank you for your attention, dear readers! In this article, I voiced the main problems that we face when managing requirements in long-term projects, but this is not a complete list. What problems did you have to deal with?

Anna Kurmanova, business analyst at Docsvision.