What threatens a long-term construction in development and what difficulties will you encounter along the way? As a business analyst at a company that has been developing and supporting one product (EDS) for 15 years, I decided to share my thoughts and case studies. The issues of requirements management in any software products with a long implementation period is an urgent issue for analysts, project managers and product owners. And, possibly, for direct partners and customers of Docsvision, who are waiting for the release of new versions and are interested in the emergence of new functionality.

What the race for timing leads to and when flexible methodologies do not fit

Why is there a widespread 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 frequent release policies, as well as flexible development methodologies?
Visually gives the answer to the question a picture in which you can choose only one intersection:



As a rule, in a short-term project it is not possible to implement a large amount of new functionality while maintaining the proper level of quality, so customers often do not see the benefits of switching to a new version (does any update contain a certain amount of risk, and they wonder whether it is worth it?) . And for a vendor, any release is a costly pleasure, since a full version is a set of installation, documentation, performance tests, regression testing, updating and compatibility testing, and a whole range of measures that need to be done in a relatively short time. Returning to the picture above, we find ourselves at the intersection of Qualitatively-Fast or Fast-Cheap. Since the resources are not unlimited, this will be the second intersection (read, crooked). The conclusion suggests itself:

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 deadlines. As a result, with the same resources, we get a long-term construction (however, instead of full-fledged releases, we began to release cumulative update packages to fill the waiting time for the next version).

One way or another, many vendors who have been on the market for more than a year come to such decisions: this approach is also used in companies of such scale as Microsoft or Adobe. But at the development stage or due to its 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 methodologies. The flexible methodologies that are popular today, known to all Scrum / Kanban by their principles, for example, did not suit us, because not calculated on the volumes and terms necessary for carrying out all stages 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 abandon these methodologies at the company, they found application in other Docsvision projects.

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

The cumulative update policy makes it possible 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 received. We would not be able to afford it using the classic Waterfall, because in it the requirements are tightly defined and the end user receives a working product only after the release of the version. At first glance, we used the advantages of each of the approaches; upon closer examination, we got problems.

Problems of long-term construction

1. A large number of requirements, the final list of which is not initially approved.
On the one hand, by increasing the implementation time, you can increase the number of requirements included in the version. A few figures: in the short-term (on average, half-year cycle) release we released about 35 features in the version, in the latest version with a long-term period so far about 100 are announced. At the same time, over 10 years, the requirements database recorded nearly 1600 potential features that customers expect to see in the product, and the list of plans for the next version is gradually growing. A logical question: how long will this continue?

2. Prioritization and assessment
The solution to the issue discussed in the previous paragraph is to prioritize the requirements selected by the owner of the product, taking into account the assessments (development, testing, documentation and risks) that are made on the basis of the specification provided by the analyst. Each company has its own approaches to setting priorities. This can be a study of the statistics of a request for the implementation of a particular feature, the results of a competitive analysis, partnership obligations, and common sense has not been canceled. We regularly conduct surveys among customers and partners, try to get the most information from the outside (for example, we have the Ideas and Suggestions portal open, where everyone can leave a request or vote for existing offers). Seminars, webinars and other social events are also ways to get information. Based on all the data received, priorities are set, but they can change, you have to follow this in real time. In our practice, its criticality in the list of requirements is most affected by its criticality for projects and general demand: first necessary, then already desired. The general effect of the implementation of functionality can contribute to raising the priority - we are talking about wow / killer features.

For example, in one of the versions of Docsvision, functionality was announced to manage the status in the system (active / on vacation / on a business trip) by the employee himself, indicating the period of absence and deputy. Those. the employee, on vacation 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 on Monday, receives a notification that he has been appointed deputy for the indicated period. This feature ultimately received a higher priority than the functionality required by many users to control the uniqueness of documents registered in the system.

3. General and private



This problem first appears 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 general to particular, the product is the opposite. We receive individual wishes from the 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 can arise both repeatedly, and during the period that the version is being developed (hello, unfinished), interested parties can propose new solutions or clarify the nuances. Sometimes you have to make adjustments to these proposals in the form of change requests, which may eventually cause a shift in the Stop Development point.

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

Let me give you an example: a scenario for processing negative decisions (failures) when approving documents. Initially, a simple logic was implemented in the system, when upon receiving a negative decision from one of the participants, the approval simply went on to the other coordinating parties. Then they realized the possibility, upon receipt of a refusal, to return the approval to the state of preparation so that the initiating employee had the opportunity to make adjustments to the document and start reconciling. Then came suggestions for improvements: “make sure that the coordination continues, but you can make changes to the document by running consolidation in case of failure”, “and we need the gene only in case of failure. Director canceled approval. " As a result, there was a switch-setting of various processing modes of the negative decision,

4. The problem of icebergs



In this case, it is not about the unfortunate passengers and the team of the legendary Titanic, which vanished in the Atlantic. I call icebergs simple, at first glance, requirements ("add a tick / button / line"), which, as it turns out upon closer examination, affect other components of the system and require additional improvements. True scales, as a rule, are revealed at the time of design, but it happens that during development. Therefore, it is better to immediately highlight such requirements and consider more carefully what needs to be done, what impact the revision will have on the existing functionality, and adjust estimates. Indeed, the earlier an iceberg is noticed, the greater the chance of avoiding a collision, and in long-term projects with a large number of interconnected requirements, the likelihood of such a situation increases significantly.

Not so long ago, I was working on a specification on demand, estimated at just a couple of hours of development. The requirement was that you need to display the search bar in a directory of your choice. This line and search functionality was already implemented, it simply was not displayed when the directory was opened to select a value. At first glance, nothing complicated. However, a requirement was made in parallel, allowing to limit the search area for values ​​from controls in cards working with this very directory. Implemented several modes that limit the choice. But the search string in the directory always worked for all values ​​and did not know anything about the new modes, which, as it turned out, needed to be supported as well. I had to increase functionality, ratings, of course, increased.

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

It happened in our practice to encounter something like this already at the stage of active development. Then, the implementation received a requirement to refine localization (choosing a value depending on the interface language) of the general properties of controls: labels, alignment, etc. According to our initial estimates, the work was reduced to implementing a common algorithm for all controls, but in reality it turned out that each of the controls has its own characteristics, and for some it was necessary to do it separately. Total difference in implementation costs compared with the initial assessment was about 45 hours.

5. "Heavy" features: to share or not to share?
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. As a rule, for each such refinement, a detailed and voluminous ToR, a lot of test cases, etc. are necessary. Here the need arises to divide the requirement into several parts, because it is easier to perceive a smaller amount of information. But, firstly, when the requirements are divided, the “picture as a whole” is lost. Secondly, the total number of version requirements is increasing, which affects the effectiveness of control, evaluation and change management. In our case, if we divide the voiced above 100 features, we get an approximately three-fold increase in the number of requirements. Of course, this is not a reason for refusing to separate certain requirements into components. It’s worth sharing, but there,

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

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

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

Release close

Imagine that all the requirements are implemented, the last errors are fixed, the documentation is about to be ready, and everyone is looking forward to the end of the project and release. At this stage, we can take a look at the results of our work and take stock. The main task of the final stage is to identify the design errors and shortcomings “in hot pursuit”, to review the implementation of all requirements, especially the interconnected ones, as well as those implemented at the very beginning of the project. For long-term projects, this volumetric task is best broken down into iterations. This will be the preliminary acceptance of the product. Our preliminary acceptance work is carried out by the analyst and product owner. Developers correct part of the shortcomings as errors (before the main acceptance of the product and release), and significant design flaws and errors can be fixed as requirements for the next versions (with the prospect of inclusion in cumulative updates). Thus, as we approach the release date and begin official acceptance of the product by management and technical support, we get a comprehensive assessment of the results and partly 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 in managing requirements in long-term projects, but this is not a complete list. And what problems did you have to deal with?

Anna Kurmanova, Docsvision Business Analyst.