project management - sueldo - ¿Cuántos proyectos simultáneos puede manejar un desarrollador sénior al mismo tiempo?
sueldo de pm jr (13)
Estoy tratando de encontrar modelos razonables de asignación de recursos para desarrolladores. El departamento tendrá muchos proyectos diferentes para diferentes clientes externos, así que necesito hacer algunas pautas para evitar que la gente se enoje debido a la falta de concentración, a no trabajar en las cosas que quieren, etc.
Actualmente tengo una sugerencia para un modelo:
- Desarrolladores junior: solo trabajarán en un proyecto a la vez (razón: principalmente que no pueden controlar su propio uso del tiempo)
- Desarrolladores intermedios: trabajarán principalmente un proyecto a la vez para el 50% o más, pero podrían ser 50-50 en dos proyectos
- Desarrolladores senior: trabajarán como máximo en 3 proyectos a la vez; el porcentaje puede ser, por ejemplo, 50%, 30% y 20%.
Son las personas mayores las que me preocupan. Como los clientes pueden querer comprar solo un grupo junior, necesito proporcionarles un mentor (senior) para asegurarse de que tengan el progreso del conocimiento y la ayuda que necesitan (alguien con experiencia y conocimiento sobre su proyecto). Un grupo de 5 juniors obtendrá un senior al 50% del tiempo.
La pregunta es: ¿puede un directivo manejar 3 proyectos a la vez (será contratado con esto en mente? No engañaré a nadie para que crea que escribirán el código el 100% del tiempo y terminarán con el 20%), o esto demasiado? EDITAR: no se espera que las personas mayores que planeo usar para mentores codifiquen en absoluto. Se centrarán en la tutoría y la capacitación, por ejemplo, en tecnologías nuevas y futuras.
Tengo la sensación de que 2 proyectos es mucho mejor que 3? ¿O? ¿Qué pasa si el senior es necesario el 50% en el "proyecto junior" y el 30% en el análisis y el diseño en otro proyecto. ¿Puede manejar un proyecto más con el último 20%?
(Y no, el tiempo para la capacitación, el café, etc. no formará parte del 100%. Ya he reducido la cantidad "real" de horas de trabajo con eso en mente).
Centrarse en la asignación de recursos afecta solo a uno de los tres aspectos de un proyecto. El número de proyectos en los que un desarrollador senior puede trabajar simultáneamente depende tanto del alcance y el cronograma de un proyecto como de sus capacidades individuales. Cada desarrollador, senior o no, va a perder tiempo debido al cambio de contexto, como dice Andre Bossard.
No creo que haya una fórmula clara o una respuesta estándar para su pregunta porque hay muchas variables a considerar para cada proyecto. Estoy seguro de que quiere que todos sus proyectos sean de alta calidad, por lo que le recomiendo que asigne los recursos correspondientes. Deje en claro a los clientes que intentar ahorrar costos (solicitando un equipo solo para jóvenes) aumentará el tiempo de entrega y puede reducir la calidad. Establecer los costos de cada opción en los recursos, el cronograma y el alcance para que el cliente pueda tomar una decisión informada es lo mejor que puede hacer.
Depende mucho de la persona. Conociendo la naturaleza de los proyectos de software, la mierda golpeará al admirador tarde o temprano, y cuando los tres proyectos de un seniors se vuelven amargos al mismo tiempo, y tres equipos de juniors gritan pidiendo orientación, ¿cómo ayudarás a tu superior a hacer frente? ?
Diría todos los que pueda caber en un disco duro. Aunque eso es subjetivo porque solo estás buceando el tiempo / esfuerzo de alguien entre los proyectos.
El desarrollo de software no es como armar una comida feliz. ¿Por qué exponer a sus clientes a sus calificaciones salariales? ¿Por qué no asignar el mejor equipo para el trabajo y comunicarlo a sus clientes?
En cuanto a su pregunta específica, creo que no es prudente tener personas trabajando en más de una cosa a la vez; los proyectos pueden atraer a las personas en una dirección u otra y un balance de "50/50" o "33/33/33" nunca ocurrirá en la realidad. Los proyectos problemáticos o los agresivos gerentes obtendrán el 100% de los recursos que desean.
En su lugar, puede querer centrarse cuando se necesita cierto talento en un proyecto. Ciertamente, durante el final de la implementación y las pruebas, no necesitará a sus personas mayores. Pero, absolutamente los necesitará durante el análisis, el diseño y la implementación inicial.
Encuentro que puedo estar profundamente involucrado con solo un proyecto a la vez. Puedo tener reuniones y conversaciones con media docena de proyectos donde alguien más es realmente responsable de la entrega.
Puedo ser mentor y entrenador de otros 5-10 proyectos sin ningún problema. Depende de la profundidad de la participación.
Pero cuando soy responsable del producto de trabajo, tengo que centrarme en eso.
Esto realmente depende, si quieres la más alta calidad en la menor cantidad de tiempo, la respuesta es uno.
Desde su publicación, parece que la velocidad de entrega o la calidad no es la principal prioridad, pero el aprendizaje es bastante importante en la lista, y en ese caso un desarrollador senior puede ayudar y asesorar a los desarrolladores Junior en múltiples proyectos. Esta suele ser la compensación que se hace ya que es una forma efectiva de "hacer crecer" la organización, solo asegurarse de que el desarrollador sénior sepa que su rol es el de profesor y mentor (así como el de pares) y no el de código extraordinario . Le ayudará inmensamente a alinear sus prioridades.
Estoy totalmente de acuerdo con la respuesta de Ilya. El cambio de contextos o tareas reduce drásticamente la productividad. Joel escribió un interesante artículo sobre este fenómeno en su sitio web.
Hay una cita que dice que 9 mujeres no pueden producir un bebé en un mes.
Creo que esto aplica aquí. Si un desarrollador está dividiendo su tiempo 50/50 en dos proyectos, ¿podrían programarse los proyectos para que el desarrollador trabaje al 100% en uno y luego, cuando termine, funcione al 100% en el segundo?
Obtiene las ganancias de productividad al tener un desarrollador enfocado, pero el trabajo aún lleva el mismo tiempo.
Si sus juniors carecen de habilidades de gestión del tiempo (no es inusual), necesitan mentoría de todos modos, incluso si solo están trabajando en un solo proyecto. Es fácil dejarse llevar por los "dorados" los módulos menos importantes.
Sugeriría que ninguna persona que esté realmente involucrada en un proyecto deba estar en más de 2 al mismo tiempo. Algo más que eso y obtiene una caída grave en la calidad y la cantidad de trabajo.
Decir que un buen truco que funciona para nosotros es tener personas mayores en proyectos múltiples, pero actuando como mentores / consultores. Ayudan a otras personas, revisan su código, buscan soluciones para los cuellos de botella, participan en picos, etc. Son tremendamente útiles de esta manera, pero su participación no cuenta para la velocidad del equipo y están fuera del equipo del proyecto propiamente dicho.
PD: también ayuda a evitar que las personas mayores se aburran.
PPS Un grupo de gente joven es una receta segura para el desastre. Necesita obtener al menos un senior trabajando a tiempo completo en cada proyecto.
como de costumbre, "depende"
- depende de la complejidad del proyecto; proyectos / problemas realmente difíciles pueden tender a consumir a los desarrolladores principales en cada momento de vigilia, sin importar la distribución teórica que se planifique; algunos problemas son difíciles (o realmente muy interesantes)
- depende del desarrollador principal: algunos pueden prosperar con un rol de mentor solo, otros pueden deprimirse si no se les permite codificar
- también depende de la calidad de los equipos junior -
- jóvenes que preguntan a las personas mayores cada pequeña pregunta que les viene a la cabeza ("¿cómo codigo un bucle en Java? ¿Por qué no aparece mi MessageBox en el navegador? ¿A quién llamo para instalar Internet en mi computadora? ¿contraseña? ") va a drenar el cerebro de incluso el más paciente y benevolente senior,
- mientras que los jóvenes que deben descubrir todo por sí mismos dejarán morir el proyecto silenciosamente mientras se golpean la cabeza contra un error tipográfico que ... simplemente ... no ... vean.
En resumen, todos los desarrolladores sénior no son iguales (lo mismo para junior / intermediate), será mejor que hables con cada uno individualmente y construyas un equipo compatible para cada proyecto. ¿Cuál es una mejor estrategia: dar al cliente un precio que sea atractivo o proporcionar un equipo que pueda hacer el trabajo? La percepción de que todos los programadores son intercambiables es una gran parte del problema de la deslocalización en los EE. UU., Pero si empaqueta a un grupo de juniors en una negociación, continúa esa percepción y probablemente derrota su propósito declarado. Es mejor hacer el trabajo bien, o no hacerlo, para la viabilidad a largo plazo.
Cuántas tareas puede manejar una persona tiene que ver con su disciplina y motivación laboral, no su habilidad de programación.
Él solo puede trabajar en un proyecto en el mismo momento. Cambiar el proyecto te hace perder el contexto, y este problema ocurre con cada ser humano. También con desarrolladores senior.
Los estudios en el diseño de la cabina del avión indican que las personas pueden manejar 5 + o - 2 tareas a la vez. Lo ideal es mantenerlo por debajo de 5 para evitar el riesgo de que el piloto pierda el control de la situación. Creo que este principio se traduce bien en todo, desde el diseño de GUI a la gestión de tareas en otros trabajos.
Creo que el truco para su problema es intentar realizar un seguimiento de la cantidad de tareas que los desarrolladores senior están tratando de administrar. En algunos proyectos más complejos, un desarrollador sénior podría ser completamente consumido por ese único proyecto, donde con múltiples proyectos más pequeños y más simples podría salirse con 3+ a la vez.