En este momento, estoy cursando mi último año de graduación (licenciatura en ciencias de la computación). No sé si puedo hacer preguntas sobre mis cosas de la universidad, porque nunca encontré mientras navegaba por la pregunta. Aún así, es mi WorkPlace
.
Tengo un grupo de 5 miembros que trabajan en un proyecto basado en Java. Por casualidad, soy el líder del equipo y tengo mucha experiencia con Java. El resto de mis miembros no son tan buenos, de hecho, ni siquiera están en la media. Desde el principio, toda la carga recae en mí, y todo el asunto de la codificación + la documentación. Pero ya es hora. Trabajé día y noche buscando respuestas en Stack Overflow, pero ahora me siento un poco presionado. Yo también tengo un límite. Y necesito hacer que también funcionen ahora.
Pero, mis compañeros me han dado por sentado. ¿No sé qué decir ahora? ¿Cómo decirles que trabajen duro? Y el problema es que, si tienen que contribuir, tienen que saber muchísimo sobre Java, así que tienen que estudiar mucho. Pero, ellos no quieren. ¿Qué tengo que hacer? ¿Cómo manejar esto?
ACTUALIZAR:
Pocos puntos como se solicita en los comentarios.
Bueno, esto puede sonar divertido pero, en las universidades y esas cosas, no hay gestión de proyectos. Esto puede ser impactante, que la estructura del proyecto se complete después de que el proyecto termine.
Esto es común porque esta es la etapa en la que estamos aprendiendo cosas y no tenemos mucha experiencia sobre su implementación. Y no hay división del trabajo. Quien sea bueno en eso, debería intentarlo.
Actualizar2
"Esto suena como un caso clásico de una persona que sale corriendo con un proyecto después de emocionarse mucho y no molestarse en tratar de incluir a sus compañeros de equipo, quienes luego no hacen nada ni se esfuerzan en el proyecto y, en última instancia, fracasan porque uno persona no puede lograr un proyecto completo. Pero el miembro del equipo entusiasta se da cuenta de esto demasiado tarde para cambiar de táctica de manera efectiva y, de repente, todo el equipo se derrumbará como resultado ". por @enderland
Bueno, si, creo que es verdad. Tengo que aceptarlo.
Me di cuenta justo ahora, fue mi error por lo que sea que había sucedido. No puedo culpar a mis compañeros de equipo por esto. Debería haber pensado antes qué hacer y qué no. Pero ahora trato de corregir mi error con la ayuda de comentarios y respuestas, respondidas por personas útiles, experimentadas y maravillosas en este foro. Gracias.
Actualizaré lo que sucedió al final.
"Elegimos Java porque mis compañeros de equipo decían: 'Elige el que te parezca bien' ". Aquí radica la causa principal: no tenían la intención de trabajar desde el principio. Nada ayudará ahora si todo lo que hacen es explotar su arduo trabajo.
Sin embargo, es tu culpa que no lo hayas notado; lo mejor que puedes hacer ahora es disolver el equipo y trabajar tú mismo, para bien o para mal:
Voy a suponer que este es un proyecto universitario, no un lugar de trabajo real. También voy a asumir que el proyecto dura solo unas pocas semanas.
Si este es el caso, no tiene ninguna forma real de hacer que sus colegas trabajen más. Lo que puede hacer es sentarse con ellos y decirles que cree que está haciendo más de lo que le corresponde en su trabajo. Pídeles que den un paso al frente y hagan más. Pregúnteles si hay alguna razón por la que no estén haciendo tanto como usted. Tenga en cuenta que pueden pensar que están trabajando tan duro como usted, pero si no tienen tanta experiencia como usted, o si hay poca comunicación en el equipo, no siempre lo parece.
Dices que tus compañeros de equipo no conocen muy bien Java. ¿Tuviste alguna opción en el idioma? Si es así, ¿por qué eligió Java? Es raro que un curso obligue a alguien a hacer un proyecto en un idioma que no le han enseñado. ¿También tuviste alguna opción en tus compañeros de equipo?
No recomendaría tratar de adoptar ningún tipo de 'metodología' en esta etapa. Si solo le quedan unas pocas semanas, entonces una nueva metodología le costará más de lo que le dará. Sin embargo, debe dejar de dejar que las personas hagan las cosas que les apetece hacer. Asegúrese de que todos tengan una lista de tareas y sepan lo que tienen que lograr para que el proyecto funcione: una persona hace UI, una persona hace algoritmos, una persona hace interacción de archivos: algo así.
Si sus compañeros de equipo no dan un paso adelante y hacen más, le recomiendo reducir el alcance del proyecto a algo que pueda lograr con el nivel de ayuda que están dispuestos a brindar. Incluso los proyectos bien definidos suelen tener algunas características que se pueden omitir, o puede usar una arquitectura más simple.
Finalmente, asegúrese de que su profesor sepa con anticipación lo que está sucediendo. Y cuando termine el proyecto, habrá aprendido mucho sobre cómo funcionan los proyectos de software.
Por favor, asegúrese de que sus compañeros de equipo reprueben la clase. No los queremos en nuestra profesión.
Personalmente, en este caso, hablaría con el profesor, le mostraría lo que ha hecho y qué ha contribuido, si es que ha contribuido, y le pediría ayuda sobre cómo hacer que contribuya con su parte justa o cómo puede sacarlo de su equipo. y ser calificado sólo por sus propios esfuerzos.
En el futuro, nunca dejes que nadie vuelva a jugar contigo de esta manera. Divida el trabajo desde el principio y tenga reuniones diarias donde todos deban describir su progreso. Una de las razones de las reuniones diarias en algunos procesos ágiles es asegurarse de que se está avanzando. Asegúrese de usar el control de fuente para que pueda ver quién ha registrado las cosas. Nunca deje que llegue a esta etapa. En un lugar de trabajo, habría despedido a tus compañeros hace semanas.
Vaya, esto es un poco complicado. Sugeriría tener una reunión de equipo para ver si los otros miembros del equipo comparten la perspectiva de que las cosas se ven mal. Tal vez compartan su punto de vista y tal vez no, pero esa sería una idea. Podría valer la pena saber cómo ven todos la situación actual.
En segundo lugar, considere la idea de adoptar algún tipo de metodología para que las cosas puedan organizarse al menos un poco. Scrum sería una idea, aunque hay otras que podrían ser útiles para que todos estén de acuerdo con lo que se debe hacer dentro de qué ventana y hacer avanzar las cosas. La estructura aquí es clave, ya que sin eso podrías tener 5 personas luchando para hacer el trabajo en diferentes direcciones en lugar de estar unificados. Hay otras ideas ágiles que podrían usarse, aunque la idea aquí es encontrar algo relativamente liviano que sea relativamente fácil de implementar para que pueda comenzar a obtener algo de tracción.
Si desea superar la pereza, le sugiero que encuentre su moneda y la use como palanca. ¿Se preocupan por sus calificaciones? ¿Les importa su reputación? ¿Les importa el dinero? La mayoría de las personas en el mundo tienen algo que valoran mucho, por lo que la clave es encontrarlo y usarlo como una forma de sacar lo mejor de ellos. Si bien esto es manipulación, hay algo que decir: "Oye, voy a sacar lo mejor de ti y así es como lo haremos...", donde puedes encontrar ideas en libros como "Cómo ganar amigos e influir en las personas" o "Drive"si quieres encontrar técnicas de persuasión y motivación. Hay más de unas pocas formas en las que podría hacer esto y sería una habilidad útil tener en el mundo, ya que habrá muchas ocasiones en las que alguien puede decir: "¿Por qué debería hacer eso?" y tienes que encontrar alguna manera de lograr que lo hagan sin un explícito "¡Porque yo lo digo!" eso suena bastante paternal y despectivo para la persona que quiere una razón para hacer algún trabajo.
JB rey
joey rohan
joey rohan
Adán V.
joey rohan
DJClayworth
Adán V.
Adán V.
joey rohan
joey rohan
ArjunShankar
usuario8365
HLGEM
enderland
joey rohan
joey rohan