Different Projects Explanation in IT Skills

But even apart from those cases where the technical task itself requires a mixture of soft and hard skills, many of the soft skills that are now in price are directly related to community management. This area has historically had a bad reputation among programmers, because it (again, according to the old tradition) has always employed people who understand nothing about programming, and, more importantly, relate to it and those who do it without a hint of respect. The reason is that most of these managers came from the 20th century industrial management school, which is the field that gave us expressions like "human resource." Workers for them are unnecessary troubles and expenses, a mass that must be “managed” in order to maintain high production rates.

This type of “management,” if you can even call it that, also has nothing to do with soft skills. It was created by people who often thought that they had mastered the art of working with people, although in reality they did it very badly, in some cases to a pathological degree. The very fact that people feel a lack of respect from managers should be very alarming. After all, a manager's job is to coordinate people and set them up for teamwork. If they are not able to build relationships of mutual respect between employees and themselves at the most basic level, others should definitely not expect them to help in this regard.

The bottom line is that those soft skills in question do not come from nowhere. They are not taught in "etiquette classes" or "hanging out." They consist of observing people, studying their characteristics, the ability to understand their needs, even when they themselves cannot clearly articulate what they want - and, accordingly, it is unimaginably difficult to work them out, no easier than professional skills. Our habit of talking about them as if they were not skills at all, denying them value and taking them outside the professional sphere only harms us: when it comes to performing the corresponding tasks ourselves, it quickly turns out that everything is not so primitive there.  Specialists from our field have been struggling with this problem for many years.
They don't need to fight anymore! I'm here to solve it with algorithms!
*Six months later*
- Wow, this is complicated.
— What are you talking about?

(This reminds me of the story of One Engineer I Know. When his team moved to another building, he uttered the fateful words: they say, organizing the space is easy, he can handle it himself, he is an engineer. The results were, let's say, amusing. Programmers, scientists and directors seem to suffer from the same malady: the belief that all other professions are trifling.)
 

Good news: there is a way out
I think the situation can be corrected in a very “simple” way: start treating soft skills as serious professional skills, value them along with the latter, train people and hire those who have already mastered them - in general, do everything that we do in relation to all other fundamental skills. As a first step, it wouldn't hurt to make sure we have a common vocabulary to discuss them. It's hard to appreciate something that doesn't have a name. Typical tasks that often fall outside of our scope include: “enable everyone to have a general idea of ​​what is going on with the project at the moment”, “develop a common vocabulary for the main technical concepts so that anyone can explain them”, “make sure that everyone has a voice, and important concerns are not left unspoken simply out of fear" and "make it so that all participants feel a personal interest in the project and consider its success as their own" (and that's not all). Typical metrics we often overlook include: “how often will users experience irritation or other negative emotions while using the product, and how will this affect retention in the long term?” or “how does the next session go after a negative experience and how will this affect the overall impression of the product?”. I didn’t list anything new in the previous paragraph: these are all standard questions in various professional specialties, from project management to user experience research. But if the team as a whole treats them as side considerations rather than key success factors, things can end in disaster: deadlines are missed; different groups are working on slightly different versions of products that will only conflict at the final stage when they are integrated; one of the teams subtly sabotages the product because they don't want it to be successful; users stumble upon some "minor" bug and are horrified (this can lead to anything from an exodus to a lawsuit); customer confidence is slowly eroding. I watched with my own eyes how each of these reasons led to the collapse of the project.