Veo la necesidad de poder asignar un empleado a una tarea o proyecto de trabajo de manera que pueda planificar la asignación de carga de trabajo por empleado de acuerdo a mi capacidad de carga de trabajo por empleado disponible.
Quedo de sus comentarios.
Ya ejecutada si a través de los partes de trabajo… pero previamente no
No. El módulo project_plan que comenta @ced permite introducir los empleados antes de realizar el trabajo.
gracias a ambos… no conocía este modulo… muchas gracias, comentaré cualquier detalle
I do not see any way to find which tasks are allocated to an employee. Is a missing functionality or am I missing something?
I think it is a missing functionality.
That said, in my opinion the module does “too many things”. Or in other words, there are many cases in which you want to have employees allocated but you don’t want to do any planning. We ended up creating a module that only implements the allocation part.
Maybe it’d make sense that the allocation became part of the main project module. AFAIU most companies that want to manage tasks want to assign them to somebody to execute them.
AFAIU the planning is not required, so if you just want to do the allocation you just enter the values on the allocations and ignore the planning part.
It’s a pitty that custom solutions are created instead of improving the existing one’s 
Indeed I’m not sure if assign is the same as allocate. Let me explain:
I will assing the task to someone if he is the responsible of the completing but I may allocate three employees to it and let the assigned employee manage them.
Which of the two concepts are you refering to?
Sure, but it requires to fill in the percentage. And we wanted to get rid of the planning fields.
It’s probably more on the assignment part than the allocation. At NaN-tic we combine that with project_role to have several people assigned (responsible of the task) but depending on the status there’s only when person in charge at any given time.
In other customers it’s just the assignment but without a clear leader of who’s responsible to finish it, I guess.
Indeed it has a default value of 100%, so you can safetly ignore if you prefer to not set them.
I tought so 
Normally it’s better to explain your needs that refer to what solution you implemented.
BTW: I’m not sure what project_role does. Could you please explain the problem that it solves?
Well, basically it solves the problem of the fact that in some cases a task is not owned by a single person but a different person depending on its status.
So one person may be in charge of programming, another of quality control, etc, so the status of the task is the one that “explains” if the current assignee should be the Programmer, The QA Person, etc (those are the roles).
For a given task, you assign each role to a different employee, and thus the different statuses make the current assignee change depending on the current role (indicated by the status) and the employee who is in charge for that role in that task.
From what you explain it seems there is just a single responsible in the task at any time but each time the status changes the responsible is updated.
Indeed this can be easly achieved by adding the responsible on the project but also on the state model. So when the state is updated the responsible is updated also.
Do you think this may solve your problem?
No, the responsible is not at the project level and it is not in the state model either. You need a role concept at the state level (ie Developer) and you need to know who is the Developer of a given task.
The project_role module perfectly suits our needs and I think many other companies too.
So there is a responisble on each task and in your case the domain of this responsible depends on the state.
So we can have the current responisble on the project/task level and then you can customize the domain on your custom module.
That would work because we could change the responsible with on_change_status(), and make the field readonly.
We currently don’t need that because as we only cover our use case, we simply made the responsible (we name it assignee) a Function field with searcher, which is cleaner because we avoid having the same information twice.
But it really depends in what other places that “responsible” field is used. If in core it’s just informative we’ll probably use our own implementation (it does not make much sense to make the logic more complex just to reuse a field). If it ends up having more uses, then we could make it compatible with the core “responsible” field.