¿Cómo asumir la tarea de un pasante sin que se sienta derrotado?

Antecedentes: Fui pasante en mi lugar de trabajo actual durante un año, hasta mayo cuando me contrataron a tiempo completo. Soy programador y desarrollo principalmente aplicaciones móviles, pero también algunas aplicaciones web. Desde entonces, hemos contratado a varios pasantes, y 2 de ellos están bajo mi mando. El razonamiento aquí es que mi jefe quiere que aprenda a delegar y solidificar lo que he aprendido enseñándoselo a otra persona.

Entonces, el contexto es que le di a mi pasante una tarea importante pero pequeña. Iba a programar algo en el proyecto en el que estoy trabajando. O malinterpretó la tarea o no lo expliqué lo suficientemente bien, pero lo hizo mal. Su trabajo está incompleto hasta ahora, pero puedo decir por lo que ha escrito que no funcionará y que malinterpretó la tarea (o no se explicó lo suficientemente bien) y la forma en que completó la tarea incorrecta no es buena. En su defensa, él está en su segundo año de universidad y yo me gradué, así que tengo algunos años de educación y todo un año de experiencia laboral por delante. Quiero desechar su código, escribir el mío propio y explicarle cómo y por qué lo codifiqué de esa manera, pero no quiero que se sienta tonto o derrotado por la falla. La razón por la que me preocupa que se sienta tonto es porque no tengo idea de cómo pretendía que funcionara y también porque me parece una forma tonta de hacerlo, pero soy muy consciente del hecho de que también escribí cosas tontas. durante mi pasantía y sigo escribiendo estupideces en comparación con muchas otras personas. Sin embargo, fracasó. Todos fallamos en algún momento u otro.

Entonces, ¿cómo me hago cargo de su tarea y le explico cómo hacerlo bien sin que se sienta derrotado por el fracaso?

¿Has probado el desarrollo basado en pruebas? Si puede codificar contra un conjunto de pruebas, entonces hay muy pocas posibilidades de comunicar mal la tarea.
@StevenGubkin: ¿quién escribe la prueba? Si lo va a hacer él mismo, simplemente escribirá pruebas incorrectas.
@Davor Una forma común es que los desarrolladores escriban pruebas unitarias, pero que el propietario/jefe/cliente del producto escriba pruebas de aceptación. El código tiene que pasar estos para ser considerado "hecho".
@Angew - Sí, eso suena bien. Estaba pensando solo en pruebas unitarias.
"Quiero desechar su código, escribir el mío propio y explicarle cómo y por qué lo codifiqué de esa manera": la peor forma posible para que él aprenda a codificar y que tú aprendas a delegar. Por favor evite.
Cuando se trabaja con personas menos capacitadas, es mejor acortar el ciclo de retroalimentación. Revise su trabajo con frecuencia y asegúrese de que estén en el camino correcto. Al final del día, usted es responsable de su trabajo. Si están codificando algo incorrecto, solo lo retrasarán.
@FreeAsInBeer Lo tendré en cuenta. Trabajaremos en la revisión del código antes de que salgan por la puerta.
@coredump definitivamente es demasiado tarde para eso. Me dijo que entendía que teníamos limitaciones de tiempo y quería enseñarle una nueva forma de hacerlo. Nos sentamos y repasamos mi forma de hacerlo y la suya. Le expliqué por qué no era bueno (ya que tenía cosas codificadas, cuando queremos que nuestro código sea más robusto y flexible), le enseñé técnicas para retener datos y le expliqué cuándo y dónde estaba en el camino correcto. y tenía la idea correcta pero necesitaba algo más. No sé si fue la MEJOR decisión, pero no siento que haya sido la equivocada.
@TomSterkenburg Estoy feliz de que haya ido bien, parece que ha adoptado un buen enfoque. Me preocupaba que comenzaras a ser condescendiente con el pasante y lo microgestionaras (sí, tiendo a ser pesimista). Gustoso de trabajar para ti.
@coredump Entiendo sus preocupaciones, yo también las tendría. FreeAsInBeer sugirió bucles de retroalimentación más pequeños, así que revisé su código hoy para una tarea diferente antes de que se fuera. Definitivamente fue una gran idea, pude señalar pequeñas fallas en su diseño general (no usar captadores, cambiar variables globales innecesariamente) y asegurarme de que supiera por qué querríamos hacerlo de otra manera. Esto suena un poco a microgestión, pero creo que este tipo está justificado porque parte de mi trabajo es enseñarle porque solo es un estudiante universitario de segundo año. Creo que salió bien, gracias a todos por la ayuda!
Tratas a las personas como si fueras responsable de ellas. Bien en ti. Te compraría una cerveza si pudiera.

Respuestas (7)

Es mejor preguntarle al respecto: "Veamos qué has hecho para la función X. ¿Cuál era tu plan general? ¿Cómo estabas recopilando datos, procesándolos y produciendo resultados? ¿Por qué hiciste ABC de esta manera?". Como supervisor, esto no tiene que ser acusatorio. Crea un diálogo mediante el cual puede ver cuál es su plan y le permite preguntarles sobre su solución a los obstáculos que encontrarán.

Tal vez tengan una solución brillante que no puedes ver, tal vez no se den cuenta del obstáculo que se avecina. No puedes saberlo hasta que hablas con ellos.

Si no tienen una solución satisfactoria para el marco de tiempo dado, entonces no tiene por qué ser duro. "Nuestro cronograma es ajustado, así que me encargaré de esto. Fue un buen intento, cometí un error similar cuando era pasante. Por favor (indique alguna otra tarea)".

En última instancia, elegí esta respuesta porque estaba más en línea con la pregunta y mi marco de tiempo. Está en 2 días a la semana y preferiría pasar su último día de esta semana haciendo una tarea diferente. En el código, a menudo es aconsejable comenzar de nuevo en lugar de trabajar con un sistema roto y creo que este es uno de esos momentos. Es mejor que comience una nueva tarea después de que le explique cómo y por qué eliminé su tarea actual en lugar de perder el tiempo tratando de administrar su código actual en lo que realmente quise decir. Definitivamente trabajaremos en la comunicación.
@TomSterkenburg Tenga en cuenta que delegar trabajo también implica liberar el control. El único punto es que el código tiene que hacer realmente lo que se supone que debe hacer (la falta de comunicación probablemente sea una falla de su parte, pero no se preocupe, delegar correctamente es una habilidad bastante compleja, lleva tiempo aprender). Agregar restricciones adicionales también está bien, pero debe ver la línea entre "una restricción importante" y "No lo haría de esta manera". De lo contrario, la delegación es simplemente una pérdida de tiempo.
@TomSterkenburg Ha declarado que solo ha sido desarrollador a tiempo completo desde mayo. Creo que es demasiado pronto en su carrera para hacer generalizaciones amplias como "En el código, a menudo es aconsejable comenzar de nuevo en lugar de trabajar con un sistema roto..." Lo que encontrará es que, a menudo, no estará trabajando. en proyectos totalmente nuevos, sino trabajando con sistemas antiguos y código antiguo, que de hecho podría estar roto. No podrá simplemente deshacerse del código antiguo y escribirlo desde cero.
@Moss Pero la mayoría de las veces deshacerse de él habría sido mejor aún ;-) El hecho de que tenga que trabajar con un sistema heredado horrible la mayor parte del tiempo no significa que sea bueno o inteligente ... A veces es necesario
@Falco ¿La mayoría de las veces abandonarlo sería mejor aún? Derecha. Intente decirle eso a una empresa con un sistema grande, complejo y establecido con muchos usuarios que dependen de él. Si es tu proyecto favorito en el que has estado trabajando en casa, está bien. En lo que se refiere a empresas, presupuestos, finanzas y reputaciones reales, no es algo fácil de hacer. Además, decidir hacerlo podría ser catastrófico .
Pruebe la programación en pareja. Todavía puedes hacerlo bien, y él aprende a medida que lo haces paso a paso.
@Moss De cualquier manera, no estamos trabajando con un sistema heredado, estamos trabajando con un código escrito hace 3 días. Tal vez no "a menudo", tal vez una palabra mejor sea "a veces", pero no nos obsesionemos con la semántica. No creo que nadie esté en desacuerdo con que a veces es necesario empezar de nuevo. Esto es cierto para muchas cosas en la vida también. Tal vez no esta vez, pero de todos modos es demasiado tarde para eso.

En una palabra... no. (Sí, está bien, eso es una contracción).

Dijiste que supervisas a estos pasantes porque tu jefe quiere que aprendas a delegar. Hay más en eso que simplemente "Aquí hay algo de trabajo, hazlo". Si te haces cargo del trabajo del interno ahora, me parece que no has aprendido lo que tu jefe quería que aprendieras.

Has reconocido que hubo problemas de comunicación. Para aprender a delegar, necesitarás aprender a comunicarte de manera más efectiva. El ciclo de comunicación implica contar, escuchar, retroalimentar y corregir/volver a contar; en esta última parte el ciclo comienza de nuevo y continúa tanto tiempo como sea necesario. Parece que hasta ahora has intentado usar solo las dos primeras partes. Sin embargo, necesita las dos segundas partes para garantizar comunicaciones precisas.

Mi sugerencia es volver al interno y hacerle saber que ustedes dos se comunicaron mal. Revise lo que se supone que es el proyecto y asegúrese de que el pasante lo entienda bien; no le dejes simplemente decir "Sí, lo entiendo". Pídale que vuelva a exponer (en sus propias palabras) lo que se supone que debe hacer y haga las correcciones necesarias. Luego pídale que elabore un plan y revíselo antes de comenzar a codificar. Además, mantenga una mente abierta; su enfoque no es necesariamente incorrecto, solo porque no es lo que hubieras hecho; por supuesto, es posible que su enfoque no funcione, pero es su trabajo guiarlo a una solución que funcione, no hacerlo usted mismo.

Lo único que agregaría a esta respuesta es: en el futuro, no delegue tareas importantes a los pasantes. Los pasantes solo deberían trabajar en cosas que no tienen importancia si no funcionan.
Además, creo que debería tratar con menos pasantes (uno para el trabajador senior debería ser más que suficiente) para poder asesorarlos adecuadamente y poder hacer algún trabajo por su cuenta.
@NotMe No estoy de acuerdo con ese sentimiento, al menos por cómo mi lugar de trabajo maneja a los pasantes. Se les paga y están aquí para obtener una experiencia valiosa, estoy tratando de asegurarme de que la obtengan. Realmente no hay tarea que pueda darles que no sea importante
@TomSterkenburg, parece que la cultura de su empresa tiende a dar a los pasantes un poco más de responsabilidad de lo habitual (actualmente estoy en un entorno similar). Tal entorno probablemente acepta el hecho de que el trabajo en prácticas puede no funcionar y comprende el riesgo que esto podría tener para los proyectos. Creo que el propietario del proyecto debería opinar sobre si asesora a su pasante para que vuelva a encarrilar la tarea o si se hace cargo de ella. No publiqué como respuesta porque esto no da consejos sobre su pregunta real. :)
@blaughw cierto. Bueno, en este caso, soy el director del proyecto. No es un gran proyecto, pero básicamente estoy a cargo de todo, incluida la interacción con el cliente y todo eso. Decidí revisar su código y mi nuevo código y ver qué estaba haciendo.
@TomSterkenburg Si realmente quiere que aprendan, puede pedirles que reescriban su código, esta vez de acuerdo con sus estándares. Nunca aprendí de las personas que escribieron código para mí, aprendí de las personas que me dijeron en qué dirección ir (usar una lista para recorrer, usar la técnica-x, etc.). Además, no digas trampas, como "verificar nulo aquí". Esos son los más valiosos. Además, dijiste que tienes interacción con el cliente. Incluya a los internos en esa parte, si es posible. Siempre disfruté momentos como esos.
@EdwinLambregts Buen consejo, pero lamentablemente no está en mis manos si interactúan o no con los clientes. Sólo están autorizados a hacer tanto. Solo los empleados de tiempo completo interactúan directamente con los clientes, aunque pueden ver los errores registrados del cliente.
Este. Si el becario no ha entendido la tarea y no haces un segundo intento de comunicarla mejor, ¿cómo no te vas a sentir derrotado? Los pasantes hacen las cosas más lentamente que los empleados experimentados, pero aun así debe seguir todas las etapas de la tarea si es posible, y "desecharlo y comenzar de nuevo" es una etapa de cualquier tarea en la que el primer intento es completamente inútil.

Nunca deseche y reescriba el código para otra persona. Si la persona trabaja para usted, siéntese y explíquele qué estuvo mal y qué es exactamente lo que quiere y luego oblíguelo a reescribir hasta que lo haga correctamente.

De lo contrario, estarás haciendo tanto tu trabajo como el de ellos y seguirán sin ser competentes. Muchas personas se frustran cuando esto sucede porque no ven por qué se reescribió y simplemente asumen que todo lo que hacen se reescribirá porque Joe es un fanático del control, no porque tenga problemas.

No mejoran cuando haces esto y les hace un gran flaco favor. También significa que no está delegando correctamente y que se sentirá abrumado y ellos seguirán felizmente pensando que son geniales y que usted es un idiota. Es más difícil entrenar a alguien que reescribir. Pero una vez que te hayas tomado el tiempo un par de veces. entonces obtendrá una mejora porque muy pocas personas disfrutan de tener que rehacer su trabajo.

Ahora puede ser que necesites sentarte con esta persona y programar parejas si realmente tienen muy poco conocimiento. Pero en este caso específico, les haces encontrar una solución y simplemente detienes al interno cuando comienza a ir en la dirección equivocada. Sigues haciendo preguntas como "¿Por qué elegiste este método? ¿Has considerado... la biblioteca? ¿Cuál crees que sería el impacto con el tiempo de hacer esto?", etc.

Y recuerda que esto no es solo culpa del interno. Si no tenía claro lo que estaba pidiendo y si no los revisaba todos los días y miraba partes provisionales de su código, entonces tenía tanta culpa como el pasante. Así que no haga de esto una sesión de culpa, hágalo una crítica productiva y constructiva.

En resumen, siéntese con el pasante y pídale que observe mientras codifica el proyecto, explíquele por qué está codificando el proyecto de la forma en que lo hace y enseñándole buenas prácticas de codificación en el camino. En lugar de reflexionar sobre el fracaso del pasante, puede convertirlo en una experiencia de enseñanza. El fracaso es realmente una de las mejores maneras de aprender lo que no funciona, y aunque no debe ser grosero al golpear al pasante en la cabeza con su código incorrecto, debe ilustrar por qué su código no funcionará, y por qué el mejor plan en este punto es empezar de nuevo.

Si el interno se siente derrotado o no, depende de ese interno. Tendrán que ser capaces de aprender a lidiar con el fracaso de todos modos, si es que aún no lo han hecho. Sin embargo, si trata la situación correctamente, al menos el pasante debería salir con haber aprendido algo. En esta situación, eso es mucho más importante que preocuparse de que se sienta ofendido o humillado.

Definitivamente codificaría con él si estuviera disponible hoy, pero hay limitaciones de tiempo y desafortunadamente necesito hacerlo hoy.
Si se trata de un problema de tiempo, este es otro recordatorio para asegurarse de que conoce las expectativas de tiempo. ¿Supongo que estás trabajando hasta tarde y él ya se fue? No hay mucho que hacer en este caso, entonces hágalo usted mismo. Perderá la oportunidad de verte codificarlo.
@TomSterkenburg: si la fecha límite es hoy y el pasante no completó la tarea y no está en la oficina hoy, parece que no le dio al pasante suficiente tiempo para completar la tarea, y/o no No detectar el error del pasante lo suficientemente pronto como para que se recupere. Todo esto es parte de su educación, por supuesto, debe permitir que los internos sean lentos. Estas cosas pasan.
En ningún caso se debe codificar la tarea. Debe pedirle que codifique la tarea mientras observa y proporciona orientación verbal. Nunca mejorará si rehaces su trabajo.

Considere la programación en pareja con el pasante. Cualquiera de los programas emparejados recorre su código incorrecto e intenta arreglarlo, o recorre su código, explica sus fallas y discute y programa el emparejamiento con un código nuevo y mejor. Pair Programming es la mejor herramienta de aprendizaje, transferencia de conocimiento, revisión de código, control de calidad, ¡todo en uno!

A veces, con limitaciones de tiempo, es posible que deba simplemente desechar sus cosas y hacer el trabajo. He hecho esto antes, y fue con un desarrollador senior. Se notaba que se sentían un poco derrotados, pero sabían que necesitábamos hacer un trabajo.

si el tiempo lo permite, aproveche la oportunidad de aprender juntos. ellos aprenderán a programar mejor, usted aprenderá dónde ocurrió la falta de comunicación. Aprenderá a explicar y escribir historias para las tareas mucho mejor si ve cómo otros interpretaron la solicitud.

La programación en pareja es genial, pero si la haces, el interno debe ser la persona que realmente maneja el teclado.
Totalmente de acuerdo @HLGEM

Quiero desechar su código, escribir el mío propio y explicarle cómo y por qué lo codifiqué de esa manera.

¡Sí! ¡Hazlo!

Err, tal vez.

He leído las objeciones muy sensatas a este enfoque. Ahora que acabo de verter un barril lleno de gasolina en este fuego, sé que tengo algunas explicaciones que dar. Mi resumen rápido es que este enfoque tiene potencial para ser bastante útil.

Un ejemplo ampliamente citado es el entrenamiento del gobierno de los EE. UU. para detectar dinero falso. A las personas se les ha enseñado esta habilidad familiarizándose con lo que está bien, en lugar de estudiar lo que está mal. Si el código creado por su compañero de trabajo es lo suficientemente deprimente, la mejor opción puede ser eliminar lo que es inútil y demostrar lo que es bueno, discutir lo que es bueno y asegurarse de que él pueda hacer lo que es bueno.

Entonces, a pesar de las objeciones que otras personas han planteado, sugeriría que su plan puede tener mérito e incluso podría ser el mejor plan. Sin embargo, también podría no serlo. Cuando mi carrera asumió el papel de ser un instructor universitario, pude ver la calidad del trabajo que creaban un grupo de estudiantes. También vi cuán efectivamente las personas estaban aprendiendo algunas cosas y otras no. Empecé a ver realmente cómo los diferentes estilos de enseñanza son efectivos para diferentes personas.

También aprendí que delegar con éxito implica darle a alguien una tarea que pueda hacer con éxito, y eso implica determinar su nivel de habilidad. Caso en cuestión: algunas personas son reacias a tomar decisiones, pero saben cómo deben hacerse las cosas. Podrías preguntarles: "Bueno, ¿qué crees que debería hacerse?" Al presionarlos para que tomen la acción necesaria, puede hacer que comiencen a darse cuenta del poder que podrían estar utilizando y pueden prosperar. Sin embargo, si le hace la misma pregunta a una persona que acaba de unirse a una organización, y esta persona no conoce suficientes detalles para tener una base para tomar una decisión sensata, la insistencia idéntica solo puede tener el efecto de ser desastroso.

Si está tratando de capacitar a alguien, asegúrese de hacer preguntas (al principio del proceso) para verificar la comprensión y determinar qué enfoque funciona de manera útil y qué enfoques no. Concéntrese en brindarles la estructura que necesitan, con resultados deseados claramente definidos y tal vez incluso enfoques claramente definidos, y luego déjelos con la tarea de lograr el objetivo fácil de lograr que estableció. En cuanto a proporcionar ejemplos (hechos por usted y hechos por él) y proporcionar instrucciones, la utilidad de un enfoque específico variará según el individuo.

En el futuro, debe informar a los pasantes que están asumiendo una tarea crítica, pero si no puede aprobar su trabajo en un momento determinado, alguien más lo hará. Esto es justo, abierto y honesto. Esto no significa que no deban tomarlo en serio porque quieres poder darles una buena recomendación. Los pasantes no deben cargar con la presión de misión crítica.

Trate de hacer algún tipo de informe para que pueda entender dónde falló al explicar este problema al pasante o qué suposiciones hizo sobre su nivel de habilidad. No hay razón para no hacer de esto una experiencia de aprendizaje para usted y su empresa también.

Como no hiciste eso, comenzaría con esta explicación y me disculparía por no decir esto en primer lugar. Supongo que el interno lo entenderá. Manténgalos informados sobre su enfoque. Tómese el tiempo para explicar tanto como sea posible. Si es posible, no rehagas todo. Con suerte, hay algún código canjeable allí.

Dale algo al interno tan pronto como sea posible. Déjalos volver a subir al caballo después de que se caigan. Tal vez puedan reescribir este proyecto con sus últimas sugerencias.

Solo creo que si lo abordas con calma y profesionalidad, el interno no se castigará demasiado. Es importante que entiendan que desea ampliar su conjunto de habilidades y que debe haber un nivel realista de fracaso, pero no un fracaso total. A veces simplemente te quedas sin tiempo.

¿Cómo asumir la tarea de un pasante sin que se sienta derrotado?
RespuestasAquíPolítica de privacidad1y, 1v