The human factor remains the strongest, but profitable risk in software development

Image from projectimo.ru

Even in such a thoughtful and formalized area as software development, the issue of risk management does not cease to be relevant. Is it even possible to manage uncertainty, random variables?

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 it will happen, who in the team is the weakest link, which features can give a time delay. It is more difficult to understand what features the customer wants to modify 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 that he would need it.
')
And the risk that key developers unexpectedly leave the project, generally horrifies many risk managers.

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

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



Of course, at various stages of development, the indicated problems and risks manifest themselves in different degrees: at the stage of forming a work plan, there is more risk of making mistakes with the assessments and priorities of the features; at the design stage, developers can make "fatal" errors in the project; in the early iterations there is a temptation to move too many tasks to subsequent iterations; during the deployment phase, it is worth preparing for the process to not go smoothly.

It is no coincidence that when describing risks, an association with temptation arises. Developers are real people who cannot constantly work with equally high efficiency. Everyday temptations “postpone for tomorrow”, “leave early”, “come back later”, and so on, have a cumulative effect. If N employees go in the wake of M temptations, this will significantly reduce overall discipline and local labor productivity.

This story has a sequel: sooner or later, these employees will have to catch up, and then they face the risk of making mistakes due to haste and overwork. It turns out that minor deviations due to "human weakness" can lead to a significant "subsidence" of the project. How to predict when an employee gets tired? How many risk managers will need to keep track of everyone?



And if some team members just spoil the relationship? Is it possible to predict this? If yes, then the risk manager should be part-time psychologist, or work in conjunction with him. Perhaps in small projects it is possible to keep track of all, but will it be possible in larger ones?

Of course, for each IT company in this matter you need to look for a middle ground. But while at each stage of developing and implementing software products non-deterministic mechanisms (that is, people) are involved, 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, if possible, 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. This is also adjacent to the creation of a large reserve of time allocated for the tasks, taking into account possible risks. However, this is not always the case.

The second solution, which does not exclude the first, can be motivational trainings, team building and other activities aimed at building team spirit, conveying the company's 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 never tire, will not disrupt discipline and conflict. And of course, their professional qualities and performance must be top notch, which will allow them to practically avoid mistakes. The combination of positive qualities is not so often, if not rarely. For such people, a large-scale “hunt” is usually conducted and they are hired mainly for promising start-ups with rich investors. If specialists of this level work for the idea, it means that someone is very lucky.

In general, in start-ups, the attitude to risk is different: often such projects are developed under conditions of maximum uncertainty. Equally, the collapse or success of a startup can result in both writing “on the knee”, an unfinished software with a lot of mistakes, and a finished product developed according to all the canons of progressive methodologies.

More complex decisions on minimizing the human factor can be reduced to increased surveillance of employees, the introduction of a checkpoint system and a system of fines, toughening of labor conditions, the introduction of strict rules and procedures. For obedience and efficiency, employees can be rewarded with various "buns" in the form of ratings, badges, honor boards, and of course, awards. Moreover, unlike the first paragraph, there is no discussion here of a change in the technical process as such. This refers to a certain totalitarianism, which is usually called the corporate culture.


Image from joyreactor.cc

This approach does not allow the employee to think about his mood and condition, does not allow him to move the labor regime 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 characteristic of 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 instructions. This is perceived as a direct threat to the integrity of the system, and such an employee is severely punished or expelled in disgrace. In such IT companies, there is usually no question that one of the employees is “irreplaceable” or an outstanding personality. Because such a system needs mostly “cogs” in order to participate in mass production, not piece production.

But, according to the catch phrase, the alien soul is darkness. There is even less certainty and conditions for formalization in a soft niche 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 idea that a project almost every day is at risk of failure demotivates the team. Someone this thought, on the contrary, mobilizes. Someone mobilizes the critical situation itself. How many stories we hear about how a certain developer, having tried standard solutions and violated all instructions, was forced to “dance with a tambourine” in order to deliver the project on time.

Usually such improvisations are not welcome, but often there is no other way out in such situations. But if the end result is achieved and the project is handed over - honor and praise to the hero. Although such employees bear potential internal risk for the project, they save the company from very specific cash risks and problems with disgruntled customers.

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

The knowledge and foresight of risks is accumulated in the process of the company's natural life activity and is put off as if in its “subconscious”. In this case, there is a natural proactive decision-making and company training. She, like any living organism, has a certain degree of self-regulation and is able to evolve. The human factor helps her in this.



If the risks are speculatively trying to "manage" a separate, specifically designed for this, specialist, then the human factor can play against him. All because, he is trying to manually manage the process, which usually happens automatically. By interfering in the natural course of things, he, firstly, may encounter an explicit or implicit resistance of the team, and secondly, he cannot load with hypothetical problems that have never been solved.

The principle “who is forewarned is forearmed” does not always work. Knowing about these or other risks, the company can spend a lot of time to simulate solutions to relevant problems. However, having met them in reality, when there is no time to reason and weigh the situation, the company can “instinctively” choose a solution to the problem that had not been considered before. This will be natural, and may be the best reaction in the current situation.

Being the main risk in software development, the human factor serves as a good reason for the development of an IT company, for its “maturing”. Each employee (regardless of position), overcoming difficulties in solving their own professional tasks, learns to solve them with a lesser degree of risk of harm to the entire project. Thus, managing your own risks based on personal experience contributes to the formation of collective experience.

Of course, we are not talking about the invention of the bike. The point is that some part of the experience of others can be assigned and adapted, and some - not. Usually, elementary rules and precautionary measures are assimilated quite simply, and tasks with an unobvious solution often require their own process of searching and accumulating their own, if not always successful, experience.