But not to design for us a system for managing the production of IT products. Part 1. Analysis of boxed solutions

I Introduction

You set yourself an impossible goal and have fun if you can. After all, such an occupation is interesting in itself, since initially you are obviously faced with an impossible task, and what can be more exciting than the impossible
Joseph Alexandrovich Brodsky.

Over my many years of IT practice, I was fortunate enough to participate in projects a couple of times that touched on the automation of the technical process of the production of information systems. For various reasons, the team needed its own unique product that allows them 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, and what’s there, right on the form with specific data, users could personally create messages for developers: about errors, comments, suggestions, etc. And there, at the far end of the communication, in the rear, the programmers in the development management system, in addition to describing the error, could quickly see: the product assembly, the location of the database, the form, and finally the data itself that caused the error. This allowed the developer directly from the task of eliminating the error to go into a productive environment and see firsthand everything that the user saw when creating a message. Agree that it is very convenient. that the user has seen while creating a message. Agree that it is very convenient. that the user has seen while creating a message. Agree that it is very convenient.

In general, the topic of automation of the process control of the development and implementation of IT products is very interesting and ambitious, especially for analysts and architects. After all, they are eager to receive, in “one bottle,” an end-to-end translation of all processes, starting with the collection of requirements, then to design and modeling, and already through them trample the path directly to development. And after all, their own will is not enough for them, because they still inspire project and product managers who open up horizons with such an approach to almost unlimited 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 publication format does not allow a complete TK, so I will try to describe the most important details from my point of view, as well as the reasoning itself for the choice of certain solutions. Anyone interested please with me ...

II Market Analysis Solutions

To explore is to see what everyone has seen, and to think like no one else
Albert Saint-Gyordi

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 harmoniously, it fits into the classification - a system for organizing interaction with users. Still similar systems, from those that are by ear, with different depths 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 solutions can make their way.

1. Standardization of the functions of systems on the market

Aggregating the potential of the above funds, we can distinguish the following required functions:

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

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

2. Disadvantages of existing systems

In fact, most systems of this kind lend themselves well to tuning to the specific needs of teams, but there are still a lot of controversial nuances, which I will briefly mention:

1. The most fundamental constraint in my opinion when using such systems is the delimitation of the entire pool of work on requirements management and task management (trackers and related ingredients). For example, Atlassian company to organize work in these areas, the products are divided into the already mentioned Jira and wiki system - Confluence. Between them, of course, a connection was established using various links, but still this is not enough. Such a separation is quite understandable and justified from a marketing point of view, since it provides the layout of the average system from elements of the product line. But on the other hand, this immediately makes assumptions and restrictions on the output product.
   
   I often observe this situation. For example, the team faces a challenge - to add some new functionality to an existing product. To begin with, a wiki system gets a description of the problem with the proposed solution. Then it gradually grows into a web of dozens of comments with discussions of various parts of this decision. As a result, in order to clarify the picture of what was stopped at the moment, we have to rush between different comments, a description of the problem and solution. Everything becomes more complicated exponentially when clusters of tasks are still hanging on this bunch.
2. Since the main emphasis in such systems is on managing teamwork (tracker), the subsystem responsible for managing requirements is usually very lame compared to 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 most of the project participants are not just not needed, but generally contraindicated. Indeed, for transferring these abstractions to the implementation stage in a specific code, only squeezes are needed, from which all intermediate judgments, obscure diagrams are removed, and descriptions of business processes are normalized and translated into algorithms.
   
   In fact, in a real project there are not so many people who really need an 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, however, 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 taking on additional responsibility and lost nerves irretrievably.
   
   Although, probably, if someone organized such a system, the whole team would have won. After all, this would make it possible to provide detailing of the entire system, into subsystems, them into modules and circuits, them into services and functions, etc. And those, in turn, are associated not only with elements on user forms, but also with specific versions of the product, code branches in which these functions are implemented, etc. With all this, it would be nice to visualize the detail 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 connect each element of this heterogeneous structure with the requirements of different levels, from which you can find out why the product was made in this way and not otherwise, 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 point, which gives slack in the whole concept, of the class of systems that we are considering, is unconditional focus on the task. “Tasks are the central concept of the whole system, describing a certain task that must be completed” (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 evaluation, design, implementation, testing, transfer to the customer, etc. Each of them also has a small description - an excursion into the problem, and in addition to the link to the requirement on the wiki, links to related tasks, the entire garland, at best, is designed as the main task and subtasks (the level of nesting is limited). The tasks themselves may have their own comments, with links to other comments, etc.
   
   In the process of execution, the executors, expected versions of the product, execution priorities, labels, components and so on, so on, so on, can change ... This whole tangle of tasks needs to be somehow synchronized, keeping up to date and ensuring data consistency. Looking at such a variegated picture of diversity, a big, big stretch is felt. Perhaps the word "big" is appropriate to use for the third time.

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

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

In practice, there are two extremes in the construction of such products:

1. Simplification and minimization of requirements and their smearing on tasks. Introduces confusion, inconsistency in the development process;
2. The formation in the system of a huge array of information regarding the requirements for the developed system, with an intricate structure and complex navigation on them. It requires a lot of effort to find the necessary information, understanding the entire context of the project as a whole;

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

The second method is more often used in large long-term projects that are inevitably associated with complex requirements that change during implementation, or when creating a line of replicated products that will need to be customized. Difficulties arise even in the process of filling out requirements in the system, and they increase when they change in different projects, product versions, etc. The difficulties associated with the complexity of perceiving the context of the entire project, its individual parts and their interaction, deepen when trying to connect new artists to the project, and if necessary, develop the product. 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, large, complex projects have a bottleneck - the context of the project. A detailed description of what and how to implement. Sometimes, this is a huge array of information that is only somehow structured. Worse, when this information is spread over heterogeneous artifacts, or the consciousness of interested parties. That is, when setting out a new task for a developer, you need to understand that he will have to spend additional time familiarizing himself with the context of the problem being solved and the current implementation of the components interacting with his solution.

It is precisely these problems that should help to effectively solve the product we are considering, supporting 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 to round out the angularities voiced in the previous part.

In theory, the analysis may begin with a review 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 difficult for the audience to perceive. Moreover, I have already carried out a similar analysis and now I just refer to my publication “Production of information systems” .

1. The division of problems to be solved by type

In order not to sculpt incompatible in a heap, carefully separate the grain from the chaff. Considering the entire process of creating an information system: "Design - Implementation - Implementation", it is convenient to divide the problems into 3 main types associated with:

• Gathering requirements and designing a solution;
• Directly by the implementation of the solution in code;
• Assembling, releasing and deploying the product on the battlefield.

This three-way system identifies the main objects that are the backbone on which the entire process is strung. It:

• User requirement. Initial statement of tasks for automation;
• Specification for development (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;
• Product assembly. Artifacts associated with a ready-to-ship version of a final or intermediate product.

Since we automate the production processes, the link, of course, will certainly be the task, where would it be without it. Thus, it makes sense to introduce three types of tasks, respectively: “Task on demand”, “Task on specification”, “Task on assembly”.
The tasks associated with the organization of the production process itself, its financing, the definition of contractual relations, etc., in this case, we leave outside the scope of consideration.

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


Figure 1. - The task classification model. It is

advisable to inherit all types of tasks from one class on which global attributes of the task can be hung, including a “report” on its implementation.

Based on the foregoing, let us reproduce the whole picture of the process of working with the management system for the development of information systems as a whole.

So first, user requirements arise. They are not on their own, but in the course of performing the tasks set out for this to the performers (analytical group). As a result of the implementation of the same pool of work, specifications are formed for the implementation of the solution in code. With this, leading experts from the development workshop can connect to the process.
Further, according to ready-made specifications, a new pool of tasks is built for executors (programmers), already in the course of solving which, it may be necessary to assemble a finished (or not so) product.

The next step, using the parameters and characteristics of the assembly, as well as the places of their deployment, is pouring in their support and implementation service a suite of tasks, the proper solution of which leads to the full use of the information system by the customer.

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

The task itself is now moved deeper into the system from a central position, since we placed the emphasis on the objects within which this task is carried out, and it remains only the role of appointing an executor and clarifying the action itself. Well, of course, the report will be generated according to the task. Thus, verbs should now prevail in the task title. In my practice, there are managers who, when creating a task (task), do not use a single verb, and each time the question arises to the author: "But what still needs to be done, where is the notorious impulse to action?"

A task during its life cycle goes through different stages, which are projected into the system by status. For example, as shown in Fig. 2.


Figure 2. - Model transition state of the task

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 recouped by reducing chaos in the system and more strict organization of the process itself.

In the next part, we will examine in detail each pool of work separately, “Part 2” .