Are they resources?

We often name resources anything we can use to solve a problem. So much so that we end up naming the people who work with us like resources. And as you can imagine, we are not just another resource.
We should name resources only our supplies, a pen, a notebook, a computer, or a keyboard. But a person is much more than that, and I want to show it by reviewing only one facet of the problem.

Over time I have worked with people from different fields, with different profiles, professions and specializations. And what strikes me most of all is its uniqueness. We are all unique in the world, and much more in a small work environment.
When we talk about a resource that knows .net we are limiting ourselves to only one facet of that person. And even worse, we are falling short because we do not know how to deepen their knowledge and we are not even talking about this person's ability to resolve. We are only talking about an immeasurable characteristic and we are encompassing that person in that characteristic, as if it were all of it.

But let's clarify something, I'm not talking about a gantt organization. I'm not talking about the methodology, be agile, cascade, etc. I'm talking about organizing people into what they do best: being people. Any organization that only measures post-its, hours or points, is cold in terms of the value of people.
To give an example, I worked on a team where a person was technically great, investigating, digging, documenting. It was incredible the level of detail he had for everything he did. The problem is precisely that we couldn't ask him to summarize. It was difficult to ask him to roughly estimate a project or functionality. If we asked him, he analyzed it to such a level that he practically ended up doing the work himself, which took much longer than we had to estimate. On the other hand we had a partner who was technically good, but did not excel, and yet was very good at analyzing. He could very well balance the time required between research, evidence, documentation and doubts.
In this example it is simple to see that a typically organized team can have two tasks: one of analysis and the other of implementation. Any of our "resources" can take these tasks and carry them out without problem. We can estimate the number of hours each one takes us and believe that at the end of the week everything reaches a happy point. But this is not true if we forget that they are people and not just resources.

If the team is poorly organized they can take the tasks in the wrong order and take twice as long, end up frustrated and with something that does not help us. The most technical took the estimate into detail and we did not meet our dates to look to the future or to solve what the client asked us, and the most analytical struggled for a long time to solve something that was at a higher level, something that did not enjoyed it and you almost certainly would not have the most suitable solution.

If on the other hand we had gone directly to the analyst to estimate the functionality and to the technician to solve the other problem, we would have everything resolved in a short time and with good quality.
Of course, this leads to thinking of a new problem: specialization.
In general, and even more so in agilism, we try to avoid specialization because teams must be self-managed, full stack, etc. But in reality what I want is something else, I want that in this self-management we know who we work with, know the limitations and the likes of others. Precisely because we are human beings we have specializations, because we have tastes that lean us more to one side than the other. And the best thing for the team itself is to get the most out of it, because even so, each member will be doing what they like best.
This does not imply, and we must be careful, that we should classify each person in their best ability because they would end up being “resources” of that ability. When we need a technician we will always call the same person and when we need one analyst we will always call the other. Although we know the specialization of each one, their tastes, and their abilities, we must also seek the balance of the entire team so that each member is nourished by the others.
In short, a well-organized team knows what each person they work with is like and gets the best out of it, for the good of each and the team as a whole.