He estado trabajando en prácticas de forma intermitente durante los últimos 2 años, y al menos dos veces he estado en la situación de tener mi propio proyecto para mí solo.
La primera vez que sucedió, estaba haciendo algo que me gustaba mucho más (desarrollo de software) y tenía un superior con el que podía contar para ayudar con los problemas en cualquier momento.
Después de eso, obtuve un nuevo proyecto en el que estaba haciendo cosas por mi cuenta, pero el proyecto involucró a más personas, por lo que hubo oportunidades para colaborar y ayudar en tareas que inicialmente no me fueron asignadas. A pesar de que tenía quejas sobre la forma en que se manejaban las cosas (no muy organizadas), el hecho de sentir que estaba aprendiendo y que era parte de un equipo lo compensó.
Sin embargo, durante los últimos 4 meses, he estado trabajando en un proyecto que estuvo en un segundo plano durante mucho tiempo, y tengo la tarea de ponerlo en marcha, comenzando con "documentar cosas". Sin embargo, a diferencia de mi primera experiencia, la documentación no es algo que disfrute particularmente hacer (especialmente del trabajo que no he hecho yo ni nadie en mi entorno) y mi jefe siempre parece tener algo más importante que hacer.
Me comprometo a evitar que esto vuelva a suceder, y tengo cubierta la parte de "cosas que disfruto hacer", pero cada vez que trato de pensar en una manera de explicar que trabajo mejor con un compañero, sigo imaginando que la gente pensará que soy tratando de holgazanear en el trabajo de otras personas.
¿Cómo puedo explicar a la gerencia/contratistas que trabajo mejor en un entorno de equipo sin que parezca una excusa para que alguien haga mi trabajo?
Mantenlo muy simple. Muchos de los comentarios aquí son abusivos, sobreanalizados o marginalmente fuera de tema. No necesita articular un manifiesto para la programación en pareja, etc. Sin embargo, sí necesita destilar cuál es su punto y explicar sucintamente a la gerencia por qué les interesa asignarle tales asignaciones. (A ellos no les importa si te estás divirtiendo o no).
Quiere decir 'necesidad de interacción en equipo', no 'trabajo en equipo'. Está perfectamente bien preferir tareas con interacción en equipo, en lugar de sentarse en un rincón trabajando solo en un proyecto que se considera sin importancia.
Su queja no era que usted personalmente considerara que escribir documentación era de poca importancia, sino que la empresa consideraba que esa tarea no era importante y que no obtendría mucho reconocimiento. Además, como dices, encuentras menos satisfactorio documentar el trabajo de otras personas.
Entonces, cuando hable con la gerencia, querrá decir algo como:
> La asignación de proyecto que más disfruté fue un proyecto de equipo en el que podía colaborar y ayudar a otras personas (¿más jóvenes?).
> Sentí que aprendí mucho (¿específicamente qué? ¿Psicología de equipo? ¿Gestión de proyectos? ¿Cómo ser mentor? ¿Cosas técnicas específicas? bueno para ellos , no solo divertido para ti.
No querrás decir simplemente algo vago y que suene flojo como: "Disfruto trabajar en tareas que inicialmente no me asignaron". porque eso te hace parecer difícil de manejar.
Entonces, ¿cuál es tu punto? Redúzcalo a los términos que la gerencia se preocupará por:
Quieres prepararte un poco para esta conversación. Calcule sus puntos, hágalos realmente concisos, luego dígaselos a un amigo o mentor para comprobar que está transmitiendo su punto.
En pocas palabras, "documentar cosas" sucede mucho. La documentación es una parte importante del desarrollo de software ( enlace divertido sobre documentación de software ), por lo que es mejor aprender a hacerlo al principio de su carrera. Además, la mejor manera de manejar este tipo de proyectos (que, por lo que he visto, es algo común) es revisarlo y documentar lo que hace.
En cuanto a tu pregunta específica, creo que te estás perdiendo el punto. No debería estar tratando de encontrar una manera de hacer que la gerencia haga que otra persona haga su trabajo. A medida que progreses en tu carrera, la gente verá que eres esa persona que evita el trabajo real como la peste. Tu carrera estará llena de tareas que no quieres hacer (estoy evitando un par en este momento, por ejemplo). Todavía deben hacerse.
Podría hablar con su gerente y expresar su deseo de probar la programación en pareja , tal vez.
Según su descripción, parece que su organización actual no está siguiendo ninguna metodología de desarrollo particular/estructurada (como scrum o procesos de desarrollo ágiles más generales). Puede usar eso a su favor para evitar "sonar como un holgazán".
Acérquelo de la siguiente manera: "He estado investigando sobre diferentes metodologías de desarrollo y creo que podría aumentar la productividad si adoptáramos la programación en pares. ¿Estaría bien si probara este enfoque durante algunas semanas con <nombre de tu compañero preferido>?". Luego, en lugar de un holgazán, te presentas como alguien que está 1) interesado en ayudar a la empresa a ser más eficiente/productiva/exitosa, 2) conocedor de la industria en general y 3) dispuesto a experimentar con cosas nuevas para ver si funcionan. . Todas esas son cosas buenas, especialmente si está buscando pasar del estado de 'pasante'.
Creo que necesita tener una explicación más clara sobre "por qué". Si bien hay casos en los que la programación en pares se considera la configuración ideal, a menudo no está relacionada con las necesidades de documentación. Y que te asignen el trabajo de limpiar la documentación es un trabajo justo en la industria del software. Por lo general, no es divertido ni glamoroso, y no conozco a nadie a quien le encante, pero es un trabajo necesario en algunos entornos.
Entonces, creo que debe responder por sí mismo, ¿cuál es el beneficio que proporcionará un compañero? ¿Sería alguien que tiene el conocimiento que necesita? ¿Alguien con un conjunto de habilidades diferente que pueda ayudar con un resultado más completo y de mayor calidad? La respuesta está en lo que no se está haciendo, o no se está haciendo bien porque no tiene los recursos (tiempo, habilidades, conocimientos, acceso) para hacerlo.
Desafortunadamente, el "interés" no es una de las cosas que puede citar como razón para necesitar un socio en el esfuerzo. Estar aburrido es parte del trabajo, y el hecho de que no te guste el trabajo o no lo encuentres interesante en este momento no es una razón para dejar de hacerlo. Si eso es realmente lo único que te falta, vas a tener que encontrar una manera de motivarte para superar los momentos aburridos... aunque es justo preguntar - si el trabajo de documentación se vuelve interminable - cuando el alcance estará terminado y cuando podrás pasar a algo más divertido.
El otro truco es poder pedir algo que no sea demasiado difícil de entregar. Si bien tener un escritor técnico para probar su trabajo puede ser una posibilidad en un lugar que tiene una inversión real en personas con habilidades de escritura, en una empresa con solo unos pocos (o ningún) escritores técnicos, esta es una batalla real y no uno es probable que gane. Sin embargo, pedirle a alguien del control de calidad que revise su trabajo u otro ingeniero para asegurarse de que cubrió todos los ángulos es una solicitud bastante fácil en la mayoría de los equipos...
Escribes "backburner durante mucho tiempo, y tengo la tarea de ponerlo en marcha, comenzando con "documentar cosas"" y leo "sin importancia, a nadie le importa, condenado desde el principio".
Desglose de mi argumento (tómalo con pinzas):
"backburner durante mucho tiempo" -> Las cosas importantes tienden a hacerse. Si alguna tarea permanece durante mucho tiempo en un segundo plano, hay algo mal con ella. O no es importante o es aburrido o todo el mundo sabe que asociar sus nombres con él es un cierto asesino de carrera.
"Tengo la tarea de ponerlo en marcha" -> Las cosas importantes no se entregan a los pasantes. Si son importantes, las mejores personas del equipo trabajan en ellos. Es demasiado peligroso correr el riesgo de fallar porque alguien sin suficiente experiencia o conocimiento trabaja en ello.
"documentar cosas" significa "hacer algo. No sé qué ni cómo; lo resolverás. Y si no lo haces, obviamente eres un incompetente, así que debería despedirte".
Si mi suposición es correcta, ninguna cantidad de trabajo en equipo lo salvará.
¿Entonces que puedes hacer? Aquí hay algunas sugerencias:
Lo que no debes hacer:
Lo que podrías hacer:
¿Crear/ser su propio compañero?
Utilice el enfoque ágil, elija un trabajo de documentación, divídalo en tareas hasta que tenga suficiente para un sprint y concéntrese en entregar/terminar el trabajo en pequeños pasos.
Trabajar solo requiere mucha más autodisciplina y es más fácil "vagar" y no concentrarse en lo que se debe entregar. Algo así como la metodología ágil puede ayudarlo a mantenerse enfocado y obtendrá una experiencia valiosa para su CV cuando solicite un nuevo trabajo en el que realmente trabaje como parte de un tiempo y no se siente en la esquina murmurando para sí mismo.
Me resulta frustrante producir documentación para las personas con las listas de verificación cuando dicha documentación probablemente nunca se leerá, tiene un beneficio muy marginal y donde tiene beneficio, la documentación pertenece al código o a la interfaz de usuario.
Y no me hagan empezar con el ruido de comentarios XML producido en masa en el código para indicar lo obvio cuando sus métodos y clases se nombran correctamente.
Solicite la diversificación de su forma de trabajar.
Trabaja en demasiados proyectos por su cuenta y quiere cambiar para experimentar el trabajo en equipo y la interacción con sus compañeros.
Por lo que parece, "iniciar" el proceso de documentación del código significa "nadie realmente quiere hacer esto, así que, POR FAVOR, comience para que otros puedan seguirlo".
Mantengo un documento de todos mis cambios de código actualizado con cada nueva compilación de código que hacemos, y sé que mi compañero de trabajo hace lo mismo. En pocas palabras, esta es una tarea que debe hacer, y muy posiblemente una tarea que SÓLO puede hacer (por cualquier razón que su jefe pueda pensar), por lo que hay varias razones por las que podría necesitar hacerlo solo.
Creo que estás "pensando demasiado" esto. El punto es que usted quiere ser bueno en su trabajo y su gerente quiere ser bueno en su trabajo.
Por lo tanto, debe obtener información que considere relevante para el trabajo del gerente. Estás pensando en cómo endulzarlo.
Las métricas del administrador involucradas aquí son las siguientes:
A y B juntos logran más cosas que A y B en tareas separadas. Esa es la métrica para permitir que las personas unan sus fuerzas.
La diferencia entre lo que A logrará junto con B sobre lo que A puede lograr solo vale más que el salario de B. Esa es la métrica de si no es más fácil simplemente dejar ir a B.
Tienes experiencia relevante para eso. Obtener esa información oportunamente para el gerente lo ayuda a contratarlo de manera más eficiente. Es posible que aún se arriesgue, y debes asegurarte de no convertir tus predicciones en profecías autocumplidas al convertirlas en un "te lo dije".
El problema es que no siempre está claro que haya un A real que prefiera este estilo de trabajo. Hay gente que se empantana en el trabajo en equipo sin que eso venga provocado por tener que tomar relevos.
Así que es una buena idea encontrar a alguien que realmente aprecie la idea del trabajo en equipo aquí.
Una vez que tienes la reputación de trabajar duro, es mucho más fácil no ser etiquetado como un holgazán o ser perezoso cuando pides trabajar en un tipo diferente de proyecto o entorno. La mayoría de la gente piensa que el perezoso es alguien que no trabaja duro en nada. Solo estás pidiendo trabajar en cosas que disfrutas. Los buenos empleadores siempre deben buscar personas que disfruten de las tareas que deben realizar, pero rara vez es una combinación perfecta para todos. Tomaste el relevo y asumiste un proyecto que nadie más quería. Deben considerarse afortunados de que lo estés haciendo, no hay razón para esperar que quieras este tipo de trabajo todo el tiempo.
Hubo un proyecto que te gustó y ahora tienes uno que no te gusta. No tiene nada de malo hacerle saber a tu jefe que te gustaría tener la oportunidad de trabajar en más proyectos como el primero. Con suerte, podrían encontrar personas que prefieran escribir documentación o al menos considerar esto con su próxima contratación.
ryans
ravemir
Martín F.
jueves
smci
david johnson
ravemir