Geekly Articles each Day
📜 ⬆️ ⬇️

Ideal requirements, and how to deal with it

In past parts


In the first part of the cycle, I announced a series of articles on the work of the analyst in the pre-project. It lists the problems, solutions and some principles to keep in mind when starting an IT project.

In the last, second part, I told about the frequent problems of the pre-project and received regular comments in the comments: “It is well written about the problems, everything is as in reality. But the solution is offered in the style of “Do not do badly, and you will do well” neskazhui , “But this is life, it is generally written in the article. And how should something be? ” Other_letter .


The story of how to, I will divide into parts:
')
  1. How correctly: that is, it would be good to do so, but usually this is only partially obtained. These will be the next two stories.
  2. What tips can be given for each phase of working with requirements: to ease the situation when something went wrong to fit into real constraints.

For the next two notes, I will describe a number of simple principles relating to the design of IT systems, their life cycle, the organization of analytical work and the building of relations around the project. Many know them, but do not always apply in reality.

Among them:


I repeat for those who do not want to wait for the following parts of the cycle. There is a video of my report from mitap, which served as the impetus for writing these notes. At the same time, I want to not only rewrite the theses of the speech, but also go out of the time frame of the report, adding to what has already been said, what did not fit in time or arose from the discussion afterwards.

IT Product Classification


Regardless of what class of product the IT project produces, you need to remember that the ultimate essence of automation is the transfer of mental work from people to machines.

For whatever small part of the system we answer, the final result will be obtained after connecting the person, technical devices, software and information into a single whole, called an automated system.

The launch of an automated system, in addition to obtaining and combining all components, includes the reorganization of automated activities. And in the last five years, such a reorganization has been increasingly accompanied by a restructuring of the administrative, legal and financial relations of the parties around the system. In the latter case, we are already dealing with an IT service, in which the line between the business process and automation is erased.

The complete hierarchy of IT products is as follows:


If we go deeper and take into account that solutions for scenarios of interaction between parts and solutions for connecting parts create an independent added value, we must take into account all types of software that can be ordered separately:


The subject of delivery of an IT project can be any of the listed types of products, their part, combination, as well as services for changing / servicing all of the above.
It would seem that the described principle is impossible to break. If all components of the system do not approach each other and to automated activities, then a miracle will not happen. This "lack of ignition" occurs by itself due to various problems with requirements, communication, design, and simply because of errors.

At the same time, project managers often deliberately remove uncomfortable parts of the system from their volume. For example, “supplying equipment is not our task,” or “do it yourself”, or “forget” to include data migration, user training and trial operation in the plan. This happens for various reasons: there are no relevant resources, non-core works or products, it is not clear, there are fears that it will be expensive and the customer will refuse to start the project.

In any case, every element of the system outside the scope of your project is an external uncontrollable stakeholder who will provide the missing part, communication channel and the need to agree on what you are doing with what the subcontractor will do.

Communication itself, coordination of design decisions with adjacent parts - these are works and risks that should clearly appear in the project plan.



The main answer to the question “what to do?” Is “to understand the class of your item of supply and to see how it is entered into the higher-level system”.

Extended V-model and system life cycle


In fact, doing different parts of the system work by different contractors or different subgroups of the project is a normal situation. In order for the parts to be coordinated among themselves, a number of technical solutions are singled out separately and are called solution architecture in Western terminology or technical design - in domestic.
Solutions are not only technical.

To illustrate the nesting of IT products, the order of making / checking decisions and the interaction of their life cycles, you can use the V-model. It reflects two simple facts: it is better to design from large to small, and to assemble into a coherent whole and to test it is necessary to reverse it.

For the hierarchy of IT products shown in the previous section, we can build an extended V-model.



If we are working on Agile, then all these steps are performed within each user story. If we have longer iterations, then an entire queue or subsystem runs through these phases at once.

On the V-model, depending on the type of IT product, you can see how much design should be done before the start of our project. On the other hand, it is clear what actions will be taken for the final validation of our item of supply.

Accordingly, the results of the previous design should come to us at the entrance (and, not always “by gravity”), and validation actions will cause requests for changes, support or defects identified after delivery.

Classification of IT projects


From the understanding of the IT product structure, the V-model concept and its connection with the life cycle of our product and its parts, another conclusion follows: before you “write off” a project plan, a risk register or some work practices with colleagues or from the Internet , you need to make sure that the configuration of our project is close to the “donor project”.

At each of the above levels and types of solutions a different number of changes is planned.

There are projects to replace the server with a more productive one. There are projects for moving from one data center to another. There is a change in the language of the system or just a service provider.
There are projects that create an IT service for the mass consumer from scratch. There are projects that change business processes and some software. All these are different projects with their own specifics. And there are a huge number of options.

To see how big the distance between two projects is, you can apply a map of design decisions reflecting the degree of change for each type of decision and the limits of our responsibility.

Here is an example of a design decision map for one real IT project, the purpose of which is deep refactoring and replacing mass service software, which should accelerate the development of the service, new features, replace the visual style solution, and some other improvements.



The second column shows the change profile by the type of decision that can be used to compare the project with other projects.

The third column adds the degree of controllability of solutions in the “as is” situation. That is, it is important for us whether there is a place to look or ask how this or that aspect of the service is arranged.

Combining data on the scale of changes and the degree of uncertainty of the current state of affairs, we received risks from the scale of changes in an object that was initially unmanaged. The risks from decisions and objects that are not in our power and are not in a manageable state are also added here — these are solutions for which we are completely dependent on subcontractors and customers.

This map can be clarified: disclose in more detail the types of decisions, add columns responsible for fixing sources of information and responsibility for decisions, add data on decision-making for the “how-to” state, and analyze relevant risks.

System as a financial asset


The last thing I want to tell today is the principle that plays the role of the universal capital formula of Karl Marx for the economy or the Shewhart-Deming cycle for managing processes for building IT systems.



The sponsor gives money under the guarantee of the customer to convert the expected effect into a return on investment.

The customer gives the requirements on the system, guaranteeing the creation of the expected effect.
The performer based on the requirements makes the system.

Users use the system, it brings the expected effect, which is converted into a return on investment.

This circle must be closed. If something does not come out: the system cannot be used, the effect is not achieved, the return on investment does not work - this is a problem project. If we cannot even predict the return on investment, the effect or order of use - this is a time bomb.

At whatever level of the V-model we enter the project, we must understand how the return on investment cycle is configured:


A picture for a particular system can usually be estimated on a piece of paper in one or two conversations. All clippings, questions, and ambiguities should be converted into risks. While clarity on the financial cycle does not come, you can not run the project.

Here I am the first (but not the last) time I want to approve the main goal of the analyst in the pre-project: it is necessary to close ten unprofitable projects in order for one profitable to receive sufficient funding.

Eventually


Above, we looked at the principles for determining the context of a project:


Just knowing the spaces and inconsistencies of the context allows you to eliminate the fatal problems and not to begin the failed project.

In the next article we will finish discussing the basic principles of the ideal launch of the project, to further proceed to the discussion of what to do with imperfect situations.

Source: https://habr.com/ru/post/351214/

More articles:


All Articles