Organization of information systems production processes. Part 1. Starting point

I Introduction

Out of chaos, order is somehow born.
Some people learn about it from newspapers with a considerable delay, and some from bitter experience on the spot and in the process of creating this order.
Michael Bulgakov.

Looking through the articles devoted to a particular topic related to software development, I often observe the following picture: a narrow topic is revealed interestingly and professionally, but when nuances are touched at the junction, on the other side of the main issue, mismatch and failure are felt in general understanding the process of manufacturing information systems. The cause-and-effect relationships are broken. Sometimes, the lack of understanding of the external environment of the issue under discussion distorts the main topic, or at least, obscures some important points worthy of attention. When you enter into a controversy with the author, it becomes obvious that questions for him that go beyond his observations and experience are absolutely unimportant. He simply mentioned in vain a related topic, and then, as they say, not his problems. The second nuance on which I want to focus attention is the neglect of the scale of the plan. After all, what is good for the implementation of small projects, death for large and vice versa. This fact is often simply discounted by the authors. As a result, there are battles with critics of the decision, in which everyone seems to be right, but only from the point of view of his free-standing bell tower. The points of view themselves are in no way indicated by the parties to the discussion, and therefore are not taken into account.

Based on the foregoing, it seemed to me that it would be very useful to collect and describe the structure of the software production process (well, at least the basic options), without going deeply into specific details, and to set the plot in a format that is extremely accessible to a wide range of people. Naturally, this publication is only my view on the subject.

In order not to miss anything, let's go through the topic slowly, step by step revealing the activities of the process and their probable options that can somehow have a significant impact on the course and result of this technical process. As a result, we will try to build and fix a consistent chain of actions leading to the birth of a new software product. Consider the episodes of the process from different points of view. For example, on the one hand, let's take a look at the person who influences the course of the procedure, and on the other hand, we will show the opinions of those clearly interested in their result, at the junction of whose opinions the notorious conflict of interests arises. And since in our study we touched upon the topic of the process participants, we will also try to understand the variety of job titles, roles, missions, hypostases, etc., which are full of modern publications describing the distribution of functional responsibilities in IT projects.

For a more accurate and visual worldview of the material, we will fill the publication with pictures, diagrams, etc., which will be transformed and disclosed, increasing with details in the development of the topic.
')

II Defining the boundaries of the production process of information systems

As complexity increases, accurate statements lose their meaning, and meaningful statements lose accuracy.
Lotfi Zade

Speaking about the process of production of information systems, we will mean activities aimed at the implementation of really large and complex software systems, rather than efforts, for example, with the creation of a small website for the sale of something. This will allow to cut unnecessary questions, for example, “Why write requirements if you can comment on the code?”. Therefore, let us immediately mark our point of view on a common understanding of what causes the difference between large and small "software and architectural forms." To do this, we outline the inventory of the main problems generated by the scale of the manufactured product.

Firstly , large software systems during their Life Cycle (hereinafter referred to as Life cycle) require the cooperation of a very large number of performers with diverse professional training and areas of competence, including, for example, business representatives. This fact makes it necessary to organize qualitative communication between the participants, for example, in the form of a certain communication platform.

Secondly , such systems, as a rule, have very complex business logic, which is very difficult to grasp at one glance. Knowledge of the rules of functioning of such a system, most often, is spread over the various nodes of competence in the teams that designed and developed different modules and subsystems. And since such systems are quite expensive and are not created at one time, they are most likely in need of modernization and further development. Therefore, they require to themselves as an escort - detailed documentation, including: technical specifications, technical solutions, deployment schemes, user instructions, etc.

Thirdly , the Software (further software) of this level requires the use of equipment to become, including: distributed data storage systems, security tools, etc. To build, deploy and maintain the health of complexes of this scale is necessary and events to organize with the appropriate scale.

Fourth , such expensive systems require adequate funding, cost planning and management. In order for the project not to "stall", you need tools that allow you to flexibly and in a timely manner change priorities, financial plans, investors, etc. Exactly how necessary and tools that allow businesses to confirm the return on project financing. For example, in the form of intermediate results that can be realistically evaluated.

Fifth , a large number of activities, required resources, a long period of creation, consistency and phasing of execution of complex software systems, requires the quality management of project activities to the fullest extent possible.

Sixth , the challenge to the quality of functioning of such systems is much more serious, and the opportunity will provide such - an order of magnitude more difficult. Consequently, more resources and scale of measures are required to ensure the specified quality of the product and the process of its creation.

And finally , most often, large software systems do not function by themselves, but in combination with other similar systems, and therefore require complex integration with each other. It turns out that when designing such software you need to know for sure: points of contact, methods and formats for information exchange, a possible reaction to events accompanying the interaction, and much more. In a nutshell, this can be described as consistency of decisions.

Having defined in brief the scale of the “disaster” and the bottlenecks of the production process of large information systems, we proceed directly to the procedure itself.

III Beginning

The devil knows how it will end, but it's good that at least it starts.
Andrzej Sapkowski (Baptism by fire)

The history of creating a software product may begin in different ways. But in any case, there should be at least three important manifestations:

1. The need to create it (someone really needs it);
2. The possibility of its creation. (someone can implement it);
3. The possibility of financing its creation (someone can pay).

Again, all these components are also very variable and can have multiple shades and nuances of manifestation. Therefore, we turn to their consideration in the list from top to bottom.

1. The need to create a product

The easiest way to start is when the need for a software product arises strongly from the potential user himself, and he is also able to intelligibly express his wishes for this very product. In this case, the analyst comes into play. This employee may be termed as: Business Analyst, Business Architect, or Product Manager. Identifying the wishes of the client, he painstakingly collects them in the description of the concept of the target software product. This is a very difficult task, because in fact, to pull out from the potential user, what does he really need, oh, how it is not easy. After all, you have to confuse, scattered wishful client to subordinate a single meaningful goal, the achievement of which will bring tangible effect from the automation of its activities. To solve such problems, we need both a conditioned warehouse of character and certain professional skills. My recommendations for this procedure can be found in the publication Practice of Forming Requirements in IT Projects from A to Z. Part 1 .

It is more difficult when a potential user already vaguely feels some kind of an insurmountable need for automation, but what exactly he needs is that he is still unable to accurately express in words. Or, for example, a potential user has the opportunity to purchase some kind of software, but he is not sure whether he really needs it. For example, colleagues told that they have such a product and even seemed to be praised. In this case, there are several options for the development of the storyline. Either the customer is treated by the ubiquitous sales department specialists and they are convinced that he simply needs a “sold-out” product, the product they sell, or the business analyst is also working with him and trying to identify his real needs, the automation of which will bring tangible benefits from the implementation. Most often there is a mixed version, first sales sells some product to the client, and only then a business analyst rushes to help and tries to solve the situation, putting the sold decision on the actual needs of the client. But even here it is not so simple, because managers are trying to interrupt the flight of the analyst's improvisation so that the cost of refinement is minimal. There is a struggle between good and evil, and it depends on which of them wins how the product will be useful for the customer.

A very interesting option, when someone is creative, formulates the need for software on behalf of potential users. That is, he dares to believe that the software product will really be useful to some segment of the community. The development of such an alternative is most often called Startup. And this option also requires detailed analysis, since it is usually aimed at the largest possible audience, and the errors of assumptions can cause significant deviations from the real needs of the majority of potential users. Simply put, this majority will not be conquered. For example, for such undertakings it is very appropriate to identify and analyze the chains of dependencies: Stakeholders (stakeholders) and their external challenges -> Problems -> Goals and indicators of their achievement. Such an analysis helps to understand what specific results can be achieved with the advent of the product, and whether they are needed in real-world values, to anyone in general.

In large enterprises, where the intricacies of complex software products are used and the responsibility for decisions made is not at all comical, Enterprise architects (business architects) are involved in the works described above, carrying out operations on a larger scale, starting from the goals of the enterprise, taking into account its strategies development, etc. And for example, in companies focused on the release of a particular product line, a Product manager may be involved, using a slightly different focus, priorities and approaches in the process of forming requirements.

From the foregoing, it turns out that at the initial stage of creating a software product, the role of a business analyst is extremely important, as it is able to identify the needs of its potential users and formalize them in the form of a certain document that will serve as a starting point for further work.


Figure 1. - Identification of customer needs in the production of software

In the figure, a blue rectangle drawn in an arrow indicates a process. Above the processes there is a conditional area defining the domain of problems and representing the point of view of the customer (business). Under the processes, there is a domain with a solution domain, describing the point of view of the team developing the information system. Red dashed arrow shows the impact of the role on the process. The blue thick arrow indicates the resulting product of the process, or the original object being processed by the process.

Further, during the immersion process, we will gradually complement this model.

2. Ability to create a product

When the first step has been taken, and it becomes more or less obvious what exactly the customer should receive as a result of creating a new software product, Solution Architects who deal with the technological aspects of projects enter into the business. They help estimate the estimated time and resources needed to create a software product, outlined in documents at the previous stage of work. In turn, various options are offered for the selection of technological solutions that affect the indicators: quality, resource intensity, implementation dates, etc. These activities, depending on the situation, can also be performed by Team Lead (technical leader of the team) - a playing coach in multidisciplinary teams, or a SEM (Software Engineering Manager) specialized manager, who, as a rule, does not work directly with the code.

The proposed solutions can be fixed in an already more detailed document - Conceptual representation or Vision of the developed information system.

On this segment there can be a selection of teams that will be entrusted with the creation of components of the software product.

Add items to our model in fig. 2


Figure 2. - Formation of a conceptual model for the production of a software product

3. The possibility of financing the creation of a product

And now, when it becomes clear what the customer of a product will acquire with its appearance in its arsenal, and what the approximate amount of resources is necessary for its implementation, a figure emerges “in the eye”, into which this undertaking should result in a monetary equivalent. There are various methods and techniques for carrying out such work, which allow, although with an error, to get an estimate. Moreover, it is important that the error is due precisely to the quality of the initial requirements. Without a doubt, these figures are very conditional and are likely to change more than once. But the order of the numbers is already clear and you can discuss the degree of readiness to get involved in the project, or to abandon its implementation. This is the first preliminary estimate of the cost of the project, in a series of ongoing assessment work.

Naturally, the more precisely the applicants nominated for the role of product creators were able to grasp the needs and moods of the customer and expressively conveyed to his consciousness the picture of his decision, the more chances to get a positive answer. This is the key point of this stage!

So, the main goal of the first stage is to assess the financial costs of implementing the proposed solution in such a way that: on the one hand, not to push the customer away with exorbitant appetites for financing the proposed solution, and on the other hand not to fall into a trap when the requested amount of financial injections is not enough for successful implementation conceived project.


Figure 3. - Evaluation of the design decision in the production of software

4. The possibility of financing startups

Everything is more complicated in the case of a startup, since it is in these circumstances that the customer is not a consumer of the product, and it is not yet clear who these people who are eager for his appearance. Who will pay for all this action is also a mystery. I recall that we are now talking about large-scale and complex software products, and in this context, a startup means creating a groundwork for the implementation of an ambitious, complex project.

Looking at the statistics on the success of startups, at first glance it may seem that this occupation is akin to a lottery. But analyzing the cases, crowned with success, comes the feeling that they still had some kind of magnetism. And apparently, this magnetism can be reproduced including by you. And therefore let us try to understand its nature.

So, the first applicant, which magnetism should influence, is an investor. Yes, yes, not a potential user of the product, but for the beginning it is the investor, since, without going through this furnace, there is no further road. And in this light, a very important task for the creators of a startup is to convey to the investor compelling reasons that the product will be in demand and, accordingly, will be profitable. In this place, it is important to note that the view on good reasons from the point of view of techies and business, as a rule, does not fundamentally coincide. It looks like this: a technical expert avidly tells the breakthrough idea of ​​a startup, how important it is for all progressive humanity, and at the output receives a question from the business: “And ...? Who will really buy all this? ”

The next moment, it is necessary to clearly realize that a startup is only a reproduction, at best, of a prototype - a faint copy of a real product, and at worst - only a set of layouts, models, etc. Therefore, ideally, of course from all sides it is more interesting to present exactly the current product prototype to investors, finishing in their fantasies only a small bit of useful functionality, which potential users will rush with money at the ready, followed by advertisers, accompanying business ideas, etc. Therefore, at the very initial stages of a startup, “as if an investor” is most often his parents. And only by reaching the idea of ​​a presentation format, they can really start looking for further funding and attract real investors. Naturally, the closer the presentation is closer to the final idea, the greater the percentage of revenues from the use of the product can remain in the pocket of its creators. “Maybe” is the key word in the last sentence, since there are still a lot of factors in which creators can only stay with a certificate of honor, well, or warm words of gratitude for ideas that helped other people to become even richer.

5. Section Summary

To start the process of creating a software product, in the same place, in the same time period, a set of three components must be formed:

1. The need to create it (someone really needs it);
2. The possibility of its creation. (someone can implement it);
3. The ability to finance its creation (someone can pay).

As a result of the activities of the first stage of the software product production, the following should appear:

• Understanding the concept of the product, who needs it and why;
• Understanding who and how can implement it;
• Initial assessment of the cost of its implementation;
• Availability of funding sources for its creation and further development.

Figure 4. - Artifacts generated by the preparatory stage for the production of a software product.

IV Legal registration of the relationship between the participants of the production of information systems

An oral contract is not worth the paper on which it is written.
Samuel Goldwyn

When the concept of creating a software product desired by the customer, on the one hand, and the financial claim for payment of the implementation of this product by the contractor on the other hand, is revealed and documented, the basis and subject matter for formalizing relations between the participants of the process appears.

Since in fact the work has already been carried out (at the first stage), the contract could have already been drawn up, and the first part of the work was paid. For example, pre-project inspection agreement. Although this, in my practice, met very infrequently. Often it happens the other way around, the customer, who has felt the first impressions of the new collaboration, comes to understand that he, for one reason or another, is not yet ready for a serious relationship with the performer and for the fruits of this collaboration.

In general, since the work on creating complex software is very long, and it is unrealistic to even approximately identify all the content of tasks and the cost of their execution at the initial stage, they often resort to splitting the contract into execution stages, both from the performer and from customer , , , .

, , . , , .. . - , - , . , , , .

, , , , , . , , . . , , .

, . : .


5. – ,

, , , , . , deadline, . . . !