Agregar temporalmente desarrolladores independientes externos a un equipo de desarrolladores existente (también conocido como equipo híbrido). ¿Pros y contras?

¿Cuáles son los pros y los contras de agregar desarrolladores de software externos a un equipo de desarrolladores existente para un proyecto pequeño? ¿Cuáles son los pros y los contras?

Para mi:

Ventajas:

  • En teoría, el desarrollo debería ser más rápido en general que el equipo existente.
  • Como los buenos desarrolladores son difíciles de encontrar para el empleo, es una opción para obtener el poder del desarrollador rápidamente
  • Tal vez una buena contribución constructiva de los desarrolladores externos, ya que son nuevos en el producto.

Contras:

  • Costoso
  • No estoy seguro de quién será el responsable del código de los desarrolladores externos.
  • Los desarrolladores externos necesitan aprender sobre el código existente. Alguien necesita verificar constantemente lo que está produciendo, para que no construya su propio producto paralelo en el producto existente.
  • Mucha más necesidad de revisar el código, hablar, reunirse, refinar conceptos de productos

Entonces, en general, creo que podría funcionar para partes nuevas y más grandes del producto. Para algo pequeño que le toma a un desarrollador existente de 2 a 4 días, no valdrá la pena instruir a los desarrolladores externos sobre cómo hacerlo.

¿Cuáles son sus pros y sus contras? ¿Tiene alguna experiencia de la vida real con este tipo de 'equipos híbridos'? ¡Por favor comparte!

Por favor, deja lo que sea que estés haciendo y lee "The Mythical Man-Month" de Fred Brooks.
Brooks Law ha hecho que la gente deje de analizar, asumiendo que es una verdadera ley natural que afecta todo el trabajo todo el tiempo. Muy triste.
@DavidEspina Es discutible que uno deba observar la Ley de Brook como tal hasta que pueda proporcionar el análisis necesario para demostrar que no es correcto para su situación. La Ley de Brook suele ser muy precisa cuando el alcance del problema no se ha refinado lo suficiente como para mostrar específicamente cómo se pueden hacer efectivos los recursos adicionales.
El trabajo tiene diversos grados de elasticidad de recursos, que van desde extremadamente altos, como mover cajas, hasta cero, como agregar otro neurocirujano en la sala de operaciones. Si se mueve solo después de demostrar que se equivocó es estrictamente su grado de apetito por el riesgo y experiencia en su campo. Pero lo que he observado principalmente con Brooks Law, en este foro y en el trabajo, es que la mayoría de la gente lo trata como si fuera la gravedad: cierto en todos los casos... no vale la pena investigarlo. Y eso es simplemente triste.

Respuestas (2)

El mayor problema es la Ley de Brooks.

No dijo por qué está tratando de agregar desarrolladores independientes al pequeño proyecto temporalmente. Si su proyecto está retrasado y espera colapsar la línea de tiempo, recuerde la Ley de Brooks, "agregar mano de obra a un proyecto de software retrasado lo hace más tarde".

  1. Se necesita algo de tiempo de "aumento" para que los recursos agregados al proyecto se vuelvan productivos.

  2. Reduce la contribución del equipo interno debido a la necesidad de capacitar a la nueva persona, así como de revisar el código, etc.

  3. Los gastos generales de comunicación pueden no ser un problema para usted porque dijo que es un proyecto pequeño.

Además de la Ley de Brooks, en su caso el factor más importante es la posible frustración de su equipo interno. Tienen que tomarse mucho de la mano para que el freelancer comience. Esto es durante el tiempo que están bajo presión de tiempo en un proyecto tardío. Después de que hayan ido y venido, el equipo interno tiene que lidiar con las consecuencias de cualquier problema que surja de su código.

Entonces, mi recomendación es:

  1. No agregue un trabajador independiente temporalmente.

  2. Si debes agregar un freelancer:

    una. consulte primero con los desarrolladores internos.

    b. Permítales participar en la selección del trabajador independiente y establecer las reglas básicas.

    C. Permítales revisar y aceptar todo el código del freelancer con el entendimiento explícito de que tomarán posesión de ese código cuando el freelancer se vaya.

    d. Pídale a su evaluador que pruebe el trabajo del freelancer más a fondo.

Inicialmente leí "con" como "Juego de confianza", no como "implicación adversa". Pensé que iba a leer un artículo muy diferente.
@ MarkC.Wallace Gracias por señalarlo. Lo cambie. Fui con el término del OP sin darme cuenta de cómo salió :(

Depende de tu equipo, si son capaces de delegar tareas puede ser de ayuda tener mano de obra adicional, de lo contrario el mantenimiento de los autónomos consumirá muchos recursos y el beneficio total puede ser incluso negativo.

Hable con los desarrolladores sobre qué tareas podrían entregar con poco esfuerzo, así que simplemente explíquelo rápidamente, deje que el trabajador independiente trabaje y tal vez responda algunas preguntas. Luego haz una estimación de cuánto tiempo te tomará terminar esas tareas solo y con el freelancer y luego decide.

Y el hecho de que alguien se llame a sí mismo trabajador independiente no significa que sea realmente un experto, por lo que agrega el riesgo de introducir problemas que su propia gente no crearía.

¿Puedes invertir el dinero en tu gente también? Enséñeles alguna tecnología nueva que los haga más eficientes, por ejemplo, al desarrollar para Apple, podrían aprender Swift en lugar de ObjectiveC.

Agregar temporalmente desarrolladores independientes externos a un equipo de desarrolladores existente (también conocido como equipo híbrido). ¿Pros y contras?
RespuestasAquíPolítica de privacidad1y, 0v