¿Cómo debo gestionar un equipo con diferentes niveles de habilidad?

Trabajaré en un proyecto de software con algunos amigos míos y me nombraron jefe técnico. Ninguno de estos tipos es un mal programador, pero tengo mucha más experiencia que ellos. Necesito poder distribuir el trabajo entre todos en el equipo, al mismo tiempo que me aseguro de no pisarnos los pies; que cumplen con los estándares relativamente altos de calidad y escalabilidad que necesitamos para que este proyecto sea exitoso, sin requerir que revise todo lo que se comprometen.

¿Cómo debo mantener los estándares evitando la microgestión? ¿Es suficiente hacer algunos diagramas, programar algunas revisiones de código y confiar en que podré arreglar cualquier cosa que puedan romper, o debo seguir la ruta TDD y escribir pruebas explícitas para que el equipo las satisfaga?

Debe revisar algunos de sus códigos y dejar que se revisen entre ellos. No es que quieras ser la Policía de Check In, sino que quieras dar tu opinión con la mayor frecuencia posible. Ser un revisor puede reforzar su comprensión. Permítales revisar su código también. Se el modelo.

Nota al margen: no debe haber sorpresas durante una revisión anual.

Sobre todo : comunique sus expectativas y diseño de tantas maneras diferentes como sea posible. Los diagramas son buenos para algunos; las interfaces definidas funcionan para otros; la programación por pares también funciona; Las revisiones formales de códigos también pueden ayudar a algunas personas.

Yo también recomiendo el uso de la automatización tanto como sea posible:

• Obtener el equipo para utilizar una herramienta como NDepend o ReSharper si estás en el reino .Net. Ajusta las reglas estándar si no te gustan.
• Automatice sus pruebas tanto como sea práctico.

Es difícil discutir con un caso de prueba fallido o una herramienta de inspección automatizada, siempre que estén bien configurados.

Si realmente está trabajando con una gran variedad de niveles de habilidad en el mismo proyecto, habrá algunos problemas. La pregunta es ¿cuándo lidias con ellos? ¿Van a escribir un código tan malo que podría ser mejor no tener su ayuda? ¿Esto va a crear tensión personal? ¿Vas a terminar las amistades? Estas preguntas nadie puede responder excepto usted.

Suponiendo que todos permanecerán en el equipo, recomiendo dividir las tareas en pequeños trozos (los más grandes van a tipos más hábiles) y dejar que los desarrolladores más hábiles refactoricen cuando haya terminado. Asegúrese de ejecutar el control de calidad en intervalos ajustados y regulares. Esto está bastante cerca de lo que sucede en realidad de todos modos.

En la medida de lo posible, manténgase alejado de las malezas. En cualquier equipo, si usted es el líder, debe ahorrar una cierta porción de su ancho de banda para las crisis y el panorama general. Los diagramas son buenos y los estándares de codificación siempre son razonables, pero establecer procesos en los que las personas verifiquen el trabajo de los demás es aún mejor (pruebas cruzadas, revisiones por pares, programación de pares). No todos en el equipo necesitan ser una estrella: el equipo en conjunto generalmente puede superar cualquier debilidad en las personas.

Lo que recomendaría es que resista el impulso, tanto como sea posible, de decirle a la gente qué errores ve en su codificación; en su lugar, guíelos a verlo ellos mismos. Permanezca como parte de la revisión colaborativa del trabajo de desarrollo, pero asegúrese de no contribuir más que otros miembros. En cambio, haga un esfuerzo adicional para alentar a las personas a ver lo que ve y dar muchas explicaciones de por qué importan las cosas que ve.

No se preocupe demasiado por la superposición: más allá de una interrupción sensata del trabajo, puede pedirles a los miembros del equipo que se registren entre ellos y luego simplemente verifiquen que la comunicación haya sucedido. El equipo comenzará a verse rápidamente como una forma de lograr el consenso, y eso hace que su trabajo sea aproximadamente 20 veces más fácil; luego, todo lo que tiene que hacer es deshacerse cuando las áreas principales no están de acuerdo.

Luego ahorre su esfuerzo para mirar al equipo colectivamente. Cada persona tendrá algunas fortalezas increíbles y algunas debilidades fascinantes. Idealmente, comenzará a ofrecer trabajo a las personas que se adapten a sus fortalezas y al mismo tiempo les dará la oportunidad de superar sus debilidades de manera que no desactiven la productividad del equipo.

La mejor estrella de oro del liderazgo del equipo es hacer que las personas sean conscientes de sus debilidades de tal manera que estén motivadas y lo suficientemente informadas como para comenzar a solucionarlas.

Siéntese y discuta sobre las tecnologías y los conjuntos de herramientas con los que todos en el equipo están de acuerdo. Algunas personas pueden tener más experiencia en las herramientas acordadas que otras en el equipo, por lo que los que tienen más experiencia deben estar dispuestos y dispuestos a compartir la experiencia y el conocimiento con el resto.

Discuta, acuerde, escriba, modele y comunique los estándares (como la convención de nomenclatura, las mejores prácticas de codificación y las estructuras de carpetas).

Realice pruebas continuas y regulares y control de calidad. Notifique a la persona lo antes posible cuando vea inconsistencias.

Iba a decir 'haz que la persona más experimentada del equipo lo organice', pero parece que eres esa persona.

Si puede, divida el proyecto en dos niveles. La capa de aplicación / capa de controlador es una buena división. Forme dos subgrupos dentro de su equipo y haga que una persona en cada uno sea responsable de ese nivel. Eso puede funcionar extremadamente bien.

Resígnate a ello. Tendrá que revisar todo lo que cometen, especialmente desde el principio. Si todo va a las mil maravillas, solo mirarás el código. Revisar no te llevará tanto tiempo, y te dará mucha confianza en que las cosas van bien. Lo más probable es que descubras que alguien está usando semáforos incorrectamente, o está escribiendo su propia versión de una función de biblioteca o alguna locura. Mi experiencia es que tienes que estar mirando el código, ya que está siendo escrito para cortar problemas de código de raíz.

¿Qué se espera normalmente de un líder técnico en su empresa? Soy gerente y he estado en este lugar varias veces y estoy a punto de hacerlo nuevamente a partir de esta semana (contratando novatos y otros para que se unan a un equipo de personas con experiencia de 20 y 4 años).

Soy gerente y puedo ser un líder técnico (en los últimos años, he minimizado el último rol para aumentar el liderazgo dentro del equipo. En cualquier caso, algunas ideas:

• Evaluar habilidades y debilidades de todo el equipo.
• Cree un plan de crecimiento: si bien su enfoque es hacer crecer a los miembros más débiles, realmente debe enfocarse en hacer crecer a todos como individuos y como equipo.
• Comunique este plan y establezca las expectativas de todos.
• Distribuya el aprendizaje y la validación en todo el equipo. Si bien usted, como líder, es el propietario del trabajo compartido, distribuir el trabajo ayudará a los miembros de su equipo de mayor jerarquía a ser líderes.
• Crea un ciclo de retroalimentación regular. Reúnase con los miembros del equipo para evaluar el progreso y proporcionar comentarios
• Ajuste el plan, según sea necesario, para asegurar el éxito.
• Si alguien no está trabajando y no lo hará, incluso con ayuda razonable, esté preparado para expulsarlo. Esto es complicado, pero si ha establecido un plan, expectativas y proporciona un ciclo de retroalimentación, estará en una posición mucho mejor para hacerlo.
• Vigila la moral del equipo. Este tipo de situación puede hacer grandes cosas para hacer crecer un equipo o destrozarlo. Sus habilidades de liderazgo e inversión en el equipo ayudarán en gran medida a establecer el resultado.

Intente investigar lo que implica definir una "arquitectura de software". La creación de módulos que se pueden desarrollar por separado es una de las principales razones para realizar un diseño y análisis por adelantado. Sé que hacer este tipo de trabajo está pasado de moda, pero funciona en todos los casos, a diferencia de algunos casos que los métodos de desarrollo más nuevos adoptan.

Como el desarrollador más experimentado en el equipo, esperaría de su gran entrenamiento .

Deje que el equipo se asigne trabajo a ellos mismos usando kanban y luego pase todo el día haciendo programación en pareja con cada uno de ellos.

Cuando vea un mal hábito o algo que (todos) deben tener en cuenta, pare todo y dibuje en la pizarra.

Después de unas pocas semanas, podrá reducir la velocidad del entrenamiento intensivo a medida que las habilidades generales del equipo se acerquen a las suyas.

Hay un par de listas diferentes que estaría tentado a revisar desde su posición:

1. ¿Qué tan bien conozco a este equipo? ¿Conoces las fortalezas y debilidades de todos en el equipo? ¿Sabes cómo sacar lo mejor de cada persona? ¿Sabes cómo dividir el trabajo de una manera relativamente justa para todos? Ese tipo de preguntas son algo que debe hacerse y comprender que puede haber cambios en estas listas con el tiempo, ya que algunas personas pueden desarrollar algunas habilidades que pueden cambiar la forma en que se ven. Cuando lo nombraron, ¿había expectativas de usted en el equipo? Esa última pregunta puede ser difícil de hacer que la gente responda honestamente, pero puede ayudar mucho si eso se puede revelar y discutir de una manera significativa sin provocar ofensas o resentimientos, lo que puede ser bastante fácil si lo que se está discutiendo es muy personal para algunos personas. No intente obtener opiniones personales en una reunión grupal,

2. ¿Qué tan bien me conozco? ¿Qué elementos de sus antecedentes está utilizando para reclamar alguna autoridad técnica aquí? ¿Qué fortalezas y debilidades aportas al equipo? ¿Se espera que entres en las trincheras regularmente? ¿Hay prácticas que haya visto que le gustaría presentar a este equipo para ayudar a dirigirlas? ¿Hay signos de advertencia que recuerde de experiencias anteriores que puedan ser útiles para ver si alguno de estos está comenzando a aparecer en el trabajo que está haciendo el equipo?

En cierto modo, todo se reduce a la comunicación. ¡Buena suerte!

tener una presentación regular (semanal) de algún tema tecnológico y hacer que gire alrededor del grupo. De esa manera todos aprenderán algo. Y que los miembros más jóvenes también se presenten, no hay mejor manera de entender realmente algo que enseñándolo. Puede que tenga que ayudarlos a elegir temas.

Algunos entrenamientos sobre cómo dar una charla pueden ser para todos. Tenía un profesor en la universidad que lo hizo por mí y fue muy útil.