Programando con un grupo de personas que nunca conocí

Me asignaron un proyecto grupal de mi clase de informática AP, y estoy obligado a trabajar con otras tres personas. Nunca he hablado con ellos antes, no tengo idea de su nivel de habilidad, y todo lo que tengo es su dirección de correo electrónico. La tarea, resumida, es esta:

"Como equipo completarán un mínimo de tres módulos por clase ..."

Voy a tratar de convertirme en "Capitán del equipo" porque ninguno de ellos ha intentado ponerse en contacto, pero tengo curiosidad: ¿cómo hacerlo? Les envié un correo electrónico y les pregunté si hay algún método de comunicación que prefieran en lugar de enviarse correos electrónicos entre ellos, pero una vez que comencemos el proyecto, tendré que averiguar quién está haciendo qué.

¿Qué tengo que hacer? ¿Cómo "me hago cargo" y dirijo a tres personas que nunca he conocido?

Aquí hay un extracto de la asignación real:

Por lo tanto, deberá analizar los diversos roles que cada miembro del equipo tomará en este proyecto a principios de semana. Puede comunicarse a través de Pronto (o Blackboard IM), correo electrónico, una wiki, un grupo de google, blog o cualquier otro método que considere conveniente. Si un miembro del grupo no se involucra con el grupo al final de la semana, infórmele a su instructor y le brindará orientación adicional.
...
También al final de un proyecto se realizará una evaluación del equipo en la que calificará la contribución de cada miembro del equipo a la finalización de este proyecto junto con una calificación sugerida.

Editar: Muchas personas sugirieron que los conociera en una cafetería, o algo así. El único problema es que todos estamos en estados diferentes. También descubrí que a uno de ellos no se le permite usar Facebook / Skype / Twitter, así que tengo que recurrir a enviarles mensajes a través de Yahoo Messenger y correos electrónicos.

El líder de este proyecto será la persona que avanza y se hace cargo al principio.

Esto se aplica a la mayoría de las cosas en la vida, no solo al desarrollo de software. Cuando todos los demás corren como gallinas sin cabeza, la persona que piensa bien, da un paso adelante y dice: " Esto es lo que vamos a hacer y así es como lo haremos ". generalmente es la persona que se considera líder del resto del proyecto. Tenga en cuenta que al hacer esto, usted se responsabiliza del éxito o fracaso final del proyecto.

¿Quieres liderar este proyecto? Aquí hay un par de cosas que puede comenzar a hacer de inmediato para tener un gran impacto.

1. Use una herramienta de gestión de proyectos como Trello y envíe invitaciones a todos y comience a asignar partes del proyecto a las personas.
2. Genere una base de datos de errores y comience a agregar tareas y errores; nuevamente, simplemente comience a asignar.
3. Configure un repositorio de control de versiones y registre un buen fragmento inicial de código desde el que todos puedan trabajar. Negarse a tratar con cualquier otra forma de control de código.
4. Ofrezca ayudar a las personas a comenzar con el desarrollo mostrándoles cómo usar el sistema de control de versiones y la base de datos de errores.
5. Envíe correos electrónicos semanales que detallen el estado del proyecto y el progreso de la semana anterior.

Ninguno de estos pasos es particularmente difícil o requiere mucho tiempo, pero serán enormes ahorradores de tiempo en el futuro. Además, hará que su equipo hable entre sí y los acostumbrará a verlo a usted a cargo.

La respuesta de Jarrod Nettles resume bastante lo que iba a sugerir, por lo que agregaré algo de lo que funcionó en mis experiencias recientes en una situación similar.

Sugeriría encontrar alguna forma de hablar con ellos vocalmente, en lugar de por correo electrónico. Si no estás en la misma área, consíguelos en Skype. Si estás en la zona, encuéntralos en una cafetería o algo así. Hablar en persona en las reuniones iniciales lo llevará a tomar decisiones y hacer el trabajo allí mismo; los hilos de correo electrónico permiten a aquellos que son tímidos o que a menudo no están en su computadora retrasar el proceso; ¡todos sabemos lo perezosos que pueden ser los estudiantes!

En su primera reunión, trataría de conocer a su grupo y tratar de continuar con el proyecto, ¡pero no lo ignore! Pasar 10 o 20 minutos rompiendo el hielo es probablemente suficiente entre 4 personas.

Cuando se trata de hablar sobre el proyecto, sugeriría analizar lo que cree que implica el proyecto. Creo que es importante que deje en claro que esta es su comprensión, y no un caso de que les diga exactamente qué hacer. Todos deberían poder arrojar sus pensamientos e ideas al ring si tienen alguno, y usted debe salir de esa reunión inicial con una comprensión lo suficientemente decente de lo que usted, como grupo, siente que implica el proyecto.

En futuras reuniones (regulares), puede comenzar a observar diferentes partes del proyecto con más detalle; mire qué necesita hacer exactamente, qué recursos y cuánto tiempo se necesitará y quién puede hacer qué. Divida la pieza aún más si es necesario. Tal vez intente establecer algunos plazos suaves?

¿Alguno de ustedes tiene experiencia trabajando con un grupo de personas que nunca conocieron en línea y no pueden conocerlos en persona, pero deben completar un proyecto juntos?

Agregue presupuestos bajos, plazos ridículos y que se vendan río abajo por marketing y esto parece aproximadamente el 65% de los proyectos de desarrollo de software en el mundo real.

Probablemente sea mejor para usted hacer que la gente se ofrezca como voluntaria para partes que les interesaría hacer en lugar de hacerse cargo unilateralmente y asignar tareas. Probablemente todos estén sentados allí pensando cómo deberían hacerse cargo. O cómo pueden conseguir un pobre pobre que se preocupa demasiado por hacer todo el trabajo en grupo para que puedan subir a su grado.

Lo primero que debe hacer en casos como este es establecer un rastreador de problemas y aprender a usarlo.

Para una introducción más fundamental sobre cómo manejar el desarrollo como usted describe, mi referencia favorita es para el artículo de Martin Fowler Uso de un proceso de software ágil con desarrollo offshore . Este artículo describe conceptos básicos y avanzados para configurar la comunicación distribuida del equipo:

Use Continuous Integration to Avoid Integration Headaches
Have Each Site Send Ambassadors to the Other Sites
Use Contact Visits to build trust
Don't Underestimate the Culture Change
Use wikis to contain common information
Use Test Scripts to Help Understand the Requirements
Use Regular Builds to Get Feedback on Functionality
Use Regular Short Status Meetings
Use Short Iterations
Use an Iteration Planning Meeting that's Tailored for Remote Sites
When Moving a Code Base, Bug Fixing Makes a Good Start
Separate teams by functionality not activity
Expect to need more documents.
Get multiple communication modes working early

Para su proyecto, seguramente no podrá seguir todos los consejos y trucos mencionados allí (por ejemplo, es probable que no haya embajadores ni visitas de contacto para usted :) pero vale la pena estudiar de todos modos.

• Para muchos equipos tener todo lo anterior sería una exageración segura. Aún así, me parece realmente útil tener una lista de verificación completa como esa, de modo que incluso los elementos omitidos se verifiquen y tengan razones claramente documentadas para el rechazo, solo para asegurarse de que no se pierda nada importante.

No nos ha dicho cuánto tiempo tiene para esto, o el idioma en el que está trabajando (diría que una sola clase es muy pequeña, pero tal vez en su idioma es mucho más).

En primer lugar, tenga un producto que funcione a cualquier costo.

Si el proyecto dura dos semanas o menos, suponga que será el único que hace algo y esté muy contento con cualquier ayuda que reciba. Intente programar cosas para todos, pero asegúrese de que si nadie hace nada, todavía tendrá un producto que funcione. Incluso si alguien hace algo, no confíe en que continúe: prepárese para que alguien abandone en cualquier momento.

Si tiene más de una semana, considere programar un día de la semana en el que el producto deba marcarse como un hito y atenerse a eso tanto como sea posible. Asegúrese de tener algo que pueda revisar y verifique las deficiencias de: si lo peor llega a ser peor, esto será lo que entregue. Cada uno que cree, verá cuánto podría mejorar las cosas, lo que lo motivará a ir. en. No planifique demasiado hacia adelante: claro, debe tener una idea de lo que terminará, pero mantenga sus planes más específicos a corto plazo.

Tenga en cuenta que esos dos se superponen un poco: esto es intencional, ya que dos semanas es, en mi opinión, un área gris donde es difícil realizar dos iteraciones, pero trabajar solo en una iteración es arriesgado.

Estoy asumiendo el peor de los casos, donde trabajarás con personas muy nuevas en la programación. Mi consejo general sería:

• Mantenga una lista de características que desea implementar pronto y quién trabajará en ellas. Jarrod sugirió a Trello, y lo apoyo totalmente: si tus compañeros de equipo no tienen mucha experiencia, será de gran ayuda. Podrías intentar mantener los errores allí también.
• En un equipo de cuatro, necesita control de versiones. Puede hacer que otros sean más reacios a contribuir si no saben cómo hacerlo, pero vale la pena.
• Cualquier dependencia externa puede ahuyentar a los novatos. Si escribe pruebas unitarias, dígales a las personas que no deberían preocuparse por romperlas. Dígales a las personas que no deberían preocuparse por romper la construcción, especialmente al principio. Es mucho más difícil corregir a las personas que no cometen ningún código que las que cometen códigos defectuosos.
• Compruebe si las cosas sugeridas aquí realmente se aplican a usted. "Integración continua" es un término elegante: para un programa pequeño, eso podría significar "este programa se ejecuta y se pueden usar todas las funciones". ¿Tienes incluso sitios? ¿Te ayuda dividirte en equipos?
• YAGNI, cien veces más. Si realmente tiene que hacerlo, escriba las cosas con anticipación para las características que creará usted mismo. Haz que funcione, luego refactoriza, o no lograrás que funcione.
• Refactorizador Una vez que esté funcionando, dedica un tiempo a arreglarlo. No olvides que tus compañeros de equipo también tendrán que leer tu código: un día dedicado a arreglar piezas feas y reemplazar soluciones simples por otras de mejor rendimiento no es un día perdido.
• Vigila todas las partes. Ojear los registros de cambios y, ocasionalmente, leer el código de otros ayuda a garantizar que todo cumpla con los estándares de calidad que cree que debe aplicar y asegura que no sea tan difícil sumergirse si la persona abandona.
• No dude en trabajar en lo más importante, en lugar de lo designado. Si alguien se está atrasando, programe una nota por escrito en algún lugar y hágalo usted mismo. Pregúnteles primero, pero continúe si no responden, o si pregunta una o dos veces y luego siente que todavía no lo harán.
• Concéntrate en hacer algo de lo que estés orgulloso. Incluso si se desvía de la tarea. Incluso si tiene que cortar grandes características en favor de hacer que lo que tiene sea más suave. Cada iteración piensa "¿Estoy orgulloso de esto?", Y en la próxima iteración, trata de arreglar esas cosas.

Tuve un proyecto que falló horriblemente recientemente; puedes leer mis pensamientos sobre por qué falló si quieres, pero esto resume cómo haría algo como esto si tuviera otra oportunidad.

La respuesta de Jarrod Nettles es buena. Yo agregaría esto:

1. Espere que al menos una de las otras tres personas sea completamente inútil.
2. Simplemente acepte que sentirá que está haciendo la mayor parte (o la totalidad) del trabajo, pero todos obtendrán el mismo crédito. Cualquier intento de tratar de hacer las cosas "justas" solo causará conflictos innecesarios y lo retrasará.
3. Manténgase en contacto con cualquier miembro del equipo que sea bueno. Es difícil encontrar a esas personas y querrás volver a trabajar con ellas.

He estado en una posición similar algunas veces, ya que estoy seguro de que tengo mucha gente. Sin embargo, lo principal es hacer todo lo posible para mantener a todos contentos y felices, así que creo que es bueno que desees asumir la tarea de líder de equipo, sin embargo, como alguien mencionado anteriormente, esto debe abordarse cuidadosamente como otra persona pueden sentir que deberían hacer el trabajo en su lugar.

Sé que dijiste que nadie se había encargado de contactarse entre sí, pero a veces estas situaciones pueden ser difíciles para las personas, como dijiste que estás trabajando con personas que nunca conociste y que puede ser difícil comunicarse, etc.

Comenzaría con un correo electrónico simplemente dirigiéndome a todos y haciéndoles saber quién es usted cómo siente que debe abordarse el proyecto y le diré que desea liderar el proyecto asumiendo la responsabilidad de establecer roles, objetivos, plazos, tiempo de comunicación, reuniones ( si se desea / desea) y actualizaciones del proyecto.

Aunque no puede influir completamente en otras personas, puede hacer un seguimiento de quién está haciendo qué y quién no. La delegación de trabajos permite que el trabajo se divida de manera uniforme o adecuada entre personas con diferentes niveles o conjuntos de habilidades.

De esta manera, si no se realiza cierto trabajo, puede asumir la responsabilidad de dividir el trabajo entre las personas que realmente desean trabajar en él. De esta manera, no terminará con un proyecto fallido al final y tendrá registros de intentar comunicar fechas, horas y toda la información relevante que puede mostrar al final si las cosas salen mal. Todas las cosas que lo mantienen en lo correcto si algunas personas no jalan su peso.

En términos de consejos:

Personalmente me encanta un entorno de trabajo colaborativo que se encuentra aquí: https://docs.google.com/

Esto le permite compartir documentos de Word, hojas de cálculo, etc. Es una excelente manera de trabajar en colaboración. No puedo enfatizar lo útil que esto es a veces. Lo uso con algunas personas con las que trabajo que no están en el país en este momento.

Espero que esto haya ayudado a alguien, hay tantos aspectos de liderar un proyecto que podríamos continuar para siempre, pero solo depende de muchas cosas. Al menos esto es un poquito para ayudar.