Cómo mantener a un compañero de equipo irresponsable alejado de un proyecto de software

Si soy el líder, o tengo algún otro razonamiento de por qué está bien que hable con esa persona, los invitaré a una reunión privada para discutir temas y cómo mejorar. Pero voy a asumir que esta no es una opción en su caso (porque no está permitido, o no está funcionando, o algo más). También tuve ese problema.

Si se da el caso de que el proyecto está mejor sin él que con él, puede ser útil para el equipo dirigirlo hacia tareas que

  • Están fuera del camino crítico
  • Son un módulo lo más independiente posible para no afectar demasiado a otros miembros del equipo durante la integración
    • Controlador LED o RTC y código de prueba para un proyecto integrado
    • Ventana de alerta de uso general para una aplicación de interfaz de usuario
  • Son útiles sin ser requeridos
    • Agregar un módulo que admita el registro de depuración del sistema desde cualquier módulo podría ser útil, sin importar cuán feo sea por dentro
  • Son de investigación
    • Pídale que escriba un código conceptual para las piezas de tecnología que deben usarse (datos a través de un bus I2C o acceso C ++ a una base de datos remota de MySQL)
  • Son investigativas y no están relacionadas con el código.
    • Si tiene pruebas de aceptación funcional, podría definirlas mejor y crear los escenarios de prueba. Tenga en cuenta que esto es importante, así que vigílelo.
    • Podría ingresar sus requisitos en un sistema de gestión para el seguimiento, si aún no están allí
      • Mejor aún, si su empresa no tiene un sistema de control de versiones (me refiero a todo, documentos, cambios de requisitos, etc., no solo cambios de código), pídale que investigue soluciones y cree un resumen de las opciones.