Products, in my opinion, have an interesting history with both hard skills and soft skills. If earlier hard skills prevailed in the world, employees were chosen precisely for hard skills (for example, how a person cuts metal), now more T-shaped specialists are chosen. These are people who know a certain area well, they are professionals. For example, analytics is your hard skill. In addition, T-shaped specialists have a bunch of other small skills: basic programming, marketing, advertising, and the like. As for soft skills, the main product skill is communication, persuasiveness and interaction with the team. I did not name five, but these are the main skills that must be. For a junior product, by the way, one of the main skills is communication skills: if he does not quarrel with the developers, then everything is fine, he already keeps his soft skills at a good level.

I would add that we talk a lot about communications. Yes, this is definitely one of the most important skills, in my opinion. In addition, soft skills can also include self-improvement, learning, the desire to learn, the ability to learn, find information, and plan. All this is necessary and important for many people. By the way, the question is, is it possible to learn soft skills, what do you think?

Undoubtedly! They not only can be learned, but you also need to constantly learn, this is a constant work on yourself. You need to learn to talk with the team, constantly try. You can even just sign up for some kind of circle where you will sit and discuss. And the podcast that we are recording now is also a training in soft skills, that is, the development of communication skills and the ability to convey an idea. This is a constant work that you have to do in order to improve your soft skills.

So, if, ideally, a programmer would spend 4 hours on the implementation of a certain task, then, using a focus factor of 0.55, we get the actual duration of work on the task of almost 7.5 hours. The difference is significant and must be taken into account.

I note that the focus factor of 0.7 is achieved in ideal teams consisting of very experienced specialists who have a very high-quality development process and work for a long time within the subject area known to them. The value of 0.6 is achieved with pair programming in average teams, but this development mode is very exhausting for developers, so it will not work to constantly keep the bar high. Therefore, the value I have taken of 0.55 is generally more in line with the needs of advance planning.

It is convenient to express the duration and dependencies of tasks using the Gantt chart [4]. This will give an idea of ​​which tasks can or should be performed in parallel (and, accordingly, they need different performers), and which ones should be performed sequentially.

But there are other project-specific activities that are much more difficult to evaluate. I usually divide such tasks into several activities. For example, for the task of implementing an algorithm for processing large amounts of data, I can single out subtasks that provide the search and testing of solutions, creating a prototype for testing under load, and integrating a debugged solution into a project. Decomposing complex tasks into subtasks reduces uncertainty and improves the quality of planning and estimates.

It is reasonable not only to define a list of tasks, but also to indicate their approximate duration, dependencies and performers, as well as the required infrastructure.

The duration of the task should take into account the time actually spent on its solution, and not the "ideal" hours. Good results are obtained by using the focus factor when obtaining real estimates. In this case, I borrow the focus factor from agile practices, where it is defined as the number of “ideal” hours devoted to solving a set of problems, divided by the amount of time actually spent on solving an account.