The human factor remains the strongest but most beneficial risk in software development.

Image from the projectimo.ru website

Even in such a well-thought-out and formalized area as software development, the issue of risk management does not cease to be relevant. Is it possible to control uncertainty, random variables at all?

Optimists argue that they can be classified and learn to predict. In the case of software development, risk managers try to predict which part of the project will cause more problems, at what stage this will happen, who is the weakest link in the team, and what features can give a time delay. It is more difficult to understand what features the customer wants to finalize in the development process - as they say, at full speed. Aerobatics - add to the development plan the functionality that the customer forgot to say or did not know at all that he would need it.

And the risk that key developers will unexpectedly leave the project generally terrifies many risk managers.

If we take into account all kinds of risks associated with the situation in the country, the Earth’s magnetic field, currency fluctuations, a change in the supply and demand balance, closing the client’s company, then each company will have to create its own research center with a high level for accounting and analysis of all these risks. paranoia.

Some of the above problems, one way or another, help solve flexible project management methodologies. But there are still problems associated with the insufficient competence of the risk managers themselves, ALM managers and the low motivation of employees to strictly observe the principles of these methodologies.



Of course, at various stages of development, these problems and risks are manifested to varying degrees: at the stage of formulating a work plan, there is a greater risk of erring with the ratings and priorities of features; at the design stage, developers can make "fatal" errors in the project; in the early iterations, there is a temptation to transfer too many tasks to subsequent iterations; at the deployment stage, you should prepare for the fact that the process will not go smoothly.

It is no coincidence that in describing risks an association with temptation arises. Developers are living people who cannot constantly work with equally high efficiency. The daily temptations to “put off until tomorrow,” “leave early,” “come back later,” and so on, have a cumulative effect. If N employees follow M temptations, this will significantly reduce overall discipline and local productivity.

This story has a continuation: sooner or later, these employees will have to catch up, and here they are in danger of making mistakes due to rush and overwork. It turns out that minor deviations due to "human weaknesses" can lead to significant "subsidence" of the project. How to predict when an employee will get tired? How many risk managers will it take to keep track of everyone?



And if some members of the team just spoil the relationship? Can this be predicted? If so, then the risk manager should be part-time psychologist, or work in conjunction with him. Perhaps in small projects you can keep track of everyone, but will it succeed in larger ones?

Of course, for each IT company in this matter you need to look for a middle ground. But while non-deterministic mechanisms (that is, people) are involved at each stage of the development and implementation of software products, the human factor will remain the main risk.

So we come to the most important question - is it possible to somehow reserve the “human factor” a place in the list of risks and learn how to manage it?

The first decision that comes to mind is, whenever possible, to deprive all employees of the status of “irreplaceable”. We are talking about such approaches as pair programming or, for example, testing, code review, rotation of employees between different types of tasks and other collective creativity. Adjacent to this is the creation of a large reserve of time allocated for tasks, taking into account possible risks. However, this is far from always the case.

The second solution, which does not exclude the first, can be motivational trainings, team building and other events aimed at building a team spirit, communicating company values ​​to each employee and maintaining friendly relations between employees.

The third solution looks even simpler, but a little naive: you need to hire employees who will practically not get tired, will not decompose discipline and conflict. And of course, their professional qualities and effectiveness should be at the highest level, which will allow them to practically avoid mistakes. The combination of positive qualities is not so common, if not rare. For such people, a large-scale “hunt” is usually conducted and they are hired mainly in promising startups with wealthy investors. If specialists of this level work for the idea, then someone is very lucky.

In general, in startups, the attitude to risk is different: often such projects are developed in conditions of maximum uncertainty. Equally, a crash or success of a startup can be caused by written “on the knee”, unfinished software with a bunch of errors, or a finished product developed according to all the canons of progressive methodologies.

More complex decisions to minimize the human factor can boil down to increased surveillance of employees, the introduction of a security system and a system of fines, a tightening of the work regime, and the introduction of strict rules and procedures. For obedience and effectiveness, employees can be rewarded with various “goodies” in the form of ratings, badges, boards of honor, and of course, bonuses. Moreover, unlike the first paragraph, here we are not talking about changing the technical process as such. This refers to a certain totalitarianism, which is usually called corporate culture.


Image from joyreactor.cc

This approach does not allow the employee to think about his mood and condition, does not allow to shift the work regime by one iota, thereby “protecting” him from procrastination and other “temptations”. The formula for success in this case is simple: "Do everything according to the instructions." This approach is more common for large IT companies, where stability is one of the main values. In this context, a serious risk is the likelihood of any employees deviating from the instructions. This is perceived as a direct threat to the integrity of the system, and such an employee is severely punished, or expelled with shame. In such IT companies, the question is usually not that one of the employees is an “irreplaceable” or outstanding personality. Because such a system needs mainly “cogs” to participate in serial rather than piece production.

But, according to the catch phrase, someone else’s soul is dark. In a soft niche there is even less certainty and conditions for formalization than in more material, structured or tangible spheres. Whatever solution is proposed, we will not achieve an unambiguous and predictable reaction of each employee.



Sometimes the very idea that the project is almost threatened with failure almost every day demotivates the team. On the contrary, this thought mobilizes someone. Someone mobilizes the critical situation itself. How many stories we hear about how a certain developer, having tried standard solutions and breaking all the instructions, was forced to “dance with a tambourine” in order to deliver the project on time.

Usually such improvisations are not welcome, but often in such situations there is simply no other way out. But if the final result is achieved and the project is delivered, honor and praise to the hero. Despite the fact that such employees carry potential internal risks for the project, they save the company from very specific financial risks and problems with dissatisfied customers.

Thus, strict methodologies and canons give way to talent and non-standard thinking. From the point of view of risk management, this is insanity: the risk increases even more in order to get an unlikely event, that is, success. But the human factor presupposes, in addition to its negative qualities, the ability to go all the way and believe in the best. Even if the worst happens instead, the company gains valuable experience.

Knowledge and anticipation of risks accumulates in the course of the natural life of the company and is put aside in its “subconscious”. In this case, the natural adoption of proactive decisions and training the company. She, like any living organism, has a certain degree of self-regulation and is capable of evolving. In this, the human factor just helps her.



If the risks are speculatively trying to "manage" a separate, specially designed for this, specialist, then the human factor can play against him. That's because, he is trying to manually control the process, which usually happens automatically. Interfering in the natural course of things, he, firstly, can meet explicit or implicit resistance of the team, and secondly, load hypothetical problems that have never been solved.

The principle "who is warned is armed" does not always work. Knowing about these or those risks, the company can spend a lot of time to model solutions to the corresponding problems. However, having met with them in reality, when there is no time to reason and weigh the situation, the company can “instinctively” choose a solution to a problem that has not been considered at all before. It will be natural, and it may turn out to be the best reaction in the current situation.

Remaining the main risk in software development, the human factor is a good reason for the development of an IT company, for its "growing up". Each employee (regardless of position), overcoming difficulties in solving their own professional tasks, learns to solve them with less risk to harm the entire project. Thus, personal risk management, based on personal experience, contributes to the formation of collective experience.

Of course, we are not talking about the invention of a bicycle. The point is that some part of the experience of others can be appropriated and adapted, while some cannot. Usually, elementary rules and precautions are learned quite simply, and tasks with an unobvious solution often require their own search process and accumulation of their own, if not always successful experience.