And if we do not design a system for managing the production of IT products. Part 1. Analysis of box solutions

I Introduction

You set yourself an impossible goal and have fun with it, if you can. After all, such an activity is interesting in itself, since initially it is a knowingly impossible task before you, and what could be more interesting than the impossible?
Joseph Aleksandrovich Brodsky.

During my many years of IT practice, I was fortunate enough to take part in projects involving the automation of the technical process of the production of information systems a couple of times. For various reasons, the team needed its own unique product, allowing it to perform similar tasks. For example, in one interesting project on the 1C platform, organizing the process of managing the development and implementation of software that requires prompt action (if something goes wrong), in addition to generally accepted activities, we created a subsystem that automates the collection of user comments directly in the product itself. so to speak at the tip of the attack. Directly in their working environment, yes there is an environment, right on the form with specific data, users could personally create messages for developers: about errors, comments, suggestions, etc. And there, at the back end of the communication, deep in the rear, programmers in the development management system, in addition to describing the error, could quickly see: the product assembly, the location of the database localization, the form, and finally the data itself, with which the error occurred. This allowed the developer to move directly from the problem to eliminate the error into the production environment and see firsthand what the user saw when creating the message. Agree that it is very convenient.

In general, the topic of automating the management of the development and implementation of IT products is very interesting and ambitious, especially for analysts and architects. After all, they are eager to get in "one bottle", through the broadcast of all processes, starting with the collection of requirements, then to design and modeling, and through them, to tread the path directly to the development. And after all, it’s not enough for them to have their own desire, as they still podzadorivat project managers and products, opening up horizons with this approach to almost limitless possibilities for evaluating and planning project work.

In this publication, I want to once again summarize my experience in this matter and design the elements of the system, as I see it. The format of the publication does not allow to give a complete TZ, so I will try to describe the most important from my point of view details, as well as the very reasoning on the choice of those or other decisions. Who cares please with me ...

II Market Analysis Solutions

To explore means to see what everyone has seen, and to think like no one thought
Albert St. Gyordy

Probably one of the most popular systems of this class is Jira, which is sometimes claimed as a project management system. Although in my opinion, it is far from reaching that level. Maybe if only, as part of the system, together with Confluence, MSProject and other tools. Much more harmonious, it fits into the classification - a system for organizing interaction with users. Still similar systems, from those that on hearing, with the different depth of the provided functions: Redmine, MeisterTask, Zoho, TaskWorld, MantisBT.
')
And there are repository management systems, supplemented by the ability to manage tasks and maintain a simple knowledge base. For example, GitLab. There are other niches from which such decisions can make their way.

1. Standardization of system functions on the market

By aggregating the potential of the aforementioned funds, the following popular functions can be identified:

• Accounting for a variety of projects;
• Role-based user access system support;
• Organization of work with tasks for performers;
• Accounting time performers;
• Visualization of works on the Gantt chart and calendars;
• Consideration of requirements for developed products that can be associated with the tasks of users for their implementation;
• Organization of discussions of problems, tasks, etc. between users;
• Document accounting and file management;
• Notification of project participants about changes;
• The organization of custom arbitrary details for incidents, time costs, projects, users, etc .;
• Organization of versioning and product releases;
• Formation of various reports for analysis.

How many times I looked through the draft of this list, made so many changes or added something. The process is almost endless ...

2. Disadvantages of existing systems

In fact, most systems of this kind are quite amenable to customization for the specific needs of teams, but still there are a lot of controversial nuances, which I will mention in brief:

1. The most fundamental thing from my point of view is the constraint when using such systems - this is the delimitation of the entire pool of works for requirements management and task management (trackers and related ingredients). For example, the company Atlassian for the organization of work in these areas, the products are divided into the already mentioned Jira and wiki system - Confluence. There is a connection between them, of course, with the help of various links, but still this is not enough. This separation is quite understandable and justified from a marketing point of view, since it provides the layout of the average system from the elements of the product line. But on the other hand, this immediately introduces assumptions and limitations in the resulting product.
   
   I often observe this situation. For example, a team faces a challenge - add some new functionality to an existing product. To begin with, a description of the problem with the proposed solution is entered into the wiki system. Then it gradually grows into a web of a couple dozen comments with discussions on various parts of this decision. As a result, in order to clarify the picture of what stopped at the moment, we have to rush between different comments, a description of the problem and a solution. Everything is complicated in a geometrical progression, when clusters of tasks are still hung on this bouquet.
2. Since the main focus in such systems is on managing the interaction in a team (tracker), the subsystem responsible for managing requirements is usually lame in the background of products specializing in this field. This moment is also easy to explain, for example, by the fact that the analytics segment is very specific, saturated with subtleties, familiarity with which to most of the project participants is not just unnecessary, but generally contraindicated. After all, to transfer these abstractions to the implementation stage in a specific code, only squeezes are needed, from which all intermediate judgments, incomprehensible diagrams are removed, and descriptions of business processes are normalized and translated into algorithms.
   
   In fact, in a real project there are not too many people who really need end-to-end tracing of information from user needs to implemented functions in a specific version of the product. Most often, such persons are architects and system analysts, who, incidentally, are not always ready to actively fight for their interests in the project management system. After all, this is not only time consuming, but also requires sacrifice, in the form of putting on additional responsibility and irreversibly lost nerves.
   
   Although probably, if someone would organize such a system, the whole team would benefit. After all, this would allow to provide the detailing of the entire system, on subsystems, on modules and circuits, on services and functions, etc. And those, in turn, associate not only with elements on user forms, but also with specific versions of the product, code branches in which these functions are implemented, etc. At the same time, it would be good to visualize the detailing in the form of diagrams (solution architecture), with transitions plunging deep into the levels of the structure.
   
   But perhaps the most significant profit is getting the opportunity to link each element of this heterogeneous structure with the requirements of different levels, from which you can find out why the product was done this way and not differently, and whose interests are behind it. For example, you can track the variation of solutions of the same top-level requirements in different projects.
3. The next moment, which gives slack in the whole concept, the class of systems we are considering, is an unconditional focus on the task. “Tasks are the central concept of the whole system, describing a certain task that must be performed” (1). What does this lead to?
   
   For the requirements described in the wiki system, a set of tasks with different types appears in the tracker: for assessment, for design, for implementation, for testing, for transfer to the customer, etc. Each of them also has a small description - an excursion into the problem, and in addition to the reference to the requirement on the wiki, references to related tasks, the whole garland is, at best, framed as the main task and subtasks (the nesting level is limited). In the tasks themselves may be their comments, with links to other comments, etc.
   
   In the process of execution, performers, expected product versions, execution priorities, labels, components, etc., etc., etc. can be changed ... This whole tangle of tasks needs to be somehow synchronized, maintaining up to date and ensuring data consistency. Looking at a similar motley picture of the variety, one feels a big, big stretch. Perhaps the word "big" is appropriate to use a third time.

All of the above and some other points reveal wormholes in seemingly beautiful and “juicy” solutions.

3. Challenges in creating a support system for the production of information systems

In practice, one can observe two extremes in the construction of similar products:

1. Simplifying and minimizing requirements and spreading them according to tasks. Makes confusion, inconsistency in the development process;
2. Formation in the system of a huge array of information relating to the requirements for the developed system, with an intricate structure and complex navigation on them. It requires a lot of effort to find the right information, understanding the whole context of the project as a whole;

The first method is most often used in small projects requiring quick solutions with poorly formalized requirements. The shortcomings of the approach are smoothed out by holding a large number of meetings and discussions, ensuring the constant drawing of attention to problems and current topical solutions. But in this regard, there is a large amount of additional information, which remains behind the system for managing the development process and settles in the heads, mail, messengers, code comments, etc. If the project is suspended for some time, and later requires development, big problems may arise with a lack of understanding of the context of the implemented decisions, their relevance, etc. Often there are risks associated with the lack of technical capacity to scale.

The second method is more often used in large long-term projects that are inevitably associated with complex, changing requirements during implementation, or when creating a line of replicable products that need to be customized. Difficulties appear even in the process of requirements registration in the system, they increase with their changes in different projects, product versions, etc. The difficulties associated with the complexity of the perception of the context of the entire project, its individual parts and their interaction, deepened and when trying to connect to the project new artists, and if necessary, product development. Such an approach requires the involvement of highly qualified specialists, additional training, considerable time costs. The cost of supporting such a system can be high.

In general, in large, complex projects there is a bottleneck - the context of the project. A detailed description of what and how to implement. Sometimes, it is a huge array of information that is only somehow structured. Worse, when this information is spread over dissimilar artifacts, or the minds of interested parties. That is, exposing a new task to a developer, it is necessary to understand that he will have to spend extra time familiarizing himself with the context of the problem being solved and the current implementation of the components interacting with his decision.

These are the problems that should help effectively solve the product we are considering, which supports the process of developing and implementing an information system.

III Designing the basic structure of the system

- I will create an ideal society, create a world in which only responsible and kind people will live!
“And in this ideal world you will be the only villain ...”
(Death note)

Let's start rounding the angles voiced in the previous part.

In theory, the analysis can begin with consideration of the processes that we will automate. But if their description is pushed into this article, it will turn out to be too cluttered and will be hard for the audience to perceive. Moreover, I have already conducted a similar analysis and now I simply refer to my publication “Production of Information Systems” .

1. The division of problems to be solved by type

In order not to sculpt an incompatible pile, carefully separate the wheat from the chaff. Considering the whole process of creating an information system: “Design - Implementation - Implementation”, it is convenient to divide the problems into 3 main types related to:

• Requirements collection and solution design;
• Directly by the implementation of the solution in the code;
• Assembly, release and deployment of the product on the battlegrounds.

This three-way operation reveals the main objects that are the backbone, on which the entire process technology is strung. It:

• User request The initial formulation of tasks for automation;
• Development Specifications (Software Requirements Specification, SRS). Formalized customer requirements, transformed into the format most suitable for their effective implementation in the code, as well as testing and acceptance;
• Build the product. Artifacts associated with the final or intermediate version ready for delivery.

Since we are automating production processes, the task of the link will be the link to the whole structure, but without it. Thus, it makes sense to introduce respectively three types of tasks: “Task on demand”, “Task for specification”, “Task for assembly”.
The tasks related to the organization of the production process itself, its financing, the definition of contractual relations, etc., in this case, we leave out of consideration.

The data model can be organized as shown in Figure 1.


Figure 1. - Task classification model

It is advisable to inherit all types of tasks from a single class, on which it is possible to attach global attributes of a task, including the “report” on its implementation.

Based on the above, let's reproduce the whole picture of the process of working with the information system development management system as a whole.

So, first arise user requirements. They are not in themselves, but in the course of performing the tasks set for this (the analytical group). As a result of the implementation of the same pool of works, specifications are formed on the implementation of the solution in the code. With this sim, leading experts from the development department can join the process.
Further, according to ready-made specifications, a new pool of tasks is built up for executors (programmers), already in the process of solving which, assembling of a ready (or not) product may be required.

The next step, using the parameters and characteristics of the assembly, as well as their places of deployment, has its own retinue of tasks for support and implementation, the proper solution of which leads to the full use of the information system by the customer.

Thus, starting from the tasks, or from the main objects themselves: Requirement, Specification, Assembly, we can trace all the way from the problem to the specific solution in the product, as well as all the activities promoting this solution in a difficult, thorny way.

The task itself is now relegated inward from the central position, since we put the emphasis on the objects within which this task is being performed, and the role of appointing the performer and clarifying the action itself remains. Well, the report will of course be formed by the task. Thus, verbs should now prevail in the task header. In my practice, there are managers who, while creating a task (task), do not use a single verb, and each time a question arises to the author: “But what does one have to do, where is the notorious impulse to action?”.

The task during its life cycle passes through various stages, which are projected in the system by status. For example, as shown in Figure 2.


Figure 2. - Model of task transition

Perhaps this approach will make you spend a little more time in the project, but this is only at the initial stage. These costs will be more than redeemed by reducing the chaos in the system and more stringent organization of the process itself.

In the next part we will consider in detail each pooled work separately “Part 2” .