Pregunta:
¿Cómo podría haber manejado mejor este proyecto problemático?
Nishant
2015-02-22 09:34:43 UTC
view on stackexchange narkive permalink

Estaba trabajando en un proyecto con otras dos personas, una de las cuales no estaba haciendo ningún esfuerzo. Como nuestros módulos eran diferentes, al principio no me importaba su trabajo. Después de terminar mis módulos me fui a casa de vacaciones, ya que había estado fuera de casa 9 meses y mis vacaciones tardaban mucho en llegar.

Cuando regresé, el proyecto estaba en sus últimas etapas y solo el despliegue estaba pendiente. Debido a la escasez de recursos, se me pidió que me encargara de todo el despliegue. Poco después de empezar me di cuenta de lo mal que estaba el proyecto. Por ejemplo:

  1. Lleno de errores.

  2. Sin convenciones de nomenclatura, solo los nombres predeterminados generados por el IDE.

  3. Enfoque de implementación extraño.

  4. Un documento terriblemente largo plagado de errores gramaticales y lenguaje sin sentido.

  5. Pronto estuve dedicando más horas a intentar arreglar el proyecto. Las otras personas en el proyecto solo estaban citando excusas para no ayudar. El despliegue solía llevar 3 horas; charlas con el cliente: 2 horas; tratando de decirle a mi gerente, quien lo manejó terriblemente, lo que hablé con el cliente: 1.5 horas; corregir los errores encontrados después de la última implementación: resto de las horas. Trabajaba más de 13 horas al día.

    Durante este tiempo, el enfoque de implementación se cambió a instancias del cliente. El cliente también cambió los requisitos varias veces. Esto se prolongó durante casi dos meses, después de lo cual se desechó el proyecto. Se me pidió que escribiera un informe sobre las causas y acciones tomadas que, por supuesto, nadie más podría haber escrito.

    ¿Hay algo que podría haber hecho de manera diferente desde el principio o en el medio que podría haber mejorado las cosas antes? ¿Se pudo haber hecho algo durante la implementación de manera diferente?

Solo para puntualizar: el cliente no puede cambiar los requisitos, es la empresa quien decide aceptar las solicitudes del cliente. Y muy a menudo la empresa es increíblemente estúpida, ya que acepta este tipo de solicitudes de forma gratuita. Desafortunadamente, esto es cierto para muchas empresas, aunque, por supuesto, hay excepciones.
¿Cuál es tu rol en el equipo? ¿Qué está diciendo tu líder?
Gran fracaso de liderazgo. Quien fuera el responsable del proyecto en su conjunto dejó caer la pelota, si se trataba de un liderazgo por parte del comité, quien decidió hacer un proyecto sin un líder claro realmente dejó caer la pelota.
"Al principio no me importaba su trabajo" ahí está tu error. Puede ser el carpintero que construye las paredes, pero si el techo es de mala calidad, debe asegurarse de no tener que caminar debajo de él. Entonces es tu problema.
Tres respuestas:
The Wandering Dev Manager
2015-02-22 14:21:42 UTC
view on stackexchange narkive permalink

Aquí hay una gran cantidad de problemas:

  • Sin liderazgo
  • falta de estándares sobre patrones de codificación / diseño, etc.
  • Sin control de calidad o pruebas
  • Sin revisión de código
  • La falta de preocupación, la falta de esfuerzo de la persona no te molestó hasta que tuviste que limpiarlo.

El equipo tiene problemas fundamentales, de hecho, no eres un equipo en absoluto. Un equipo colabora y se cuida entre sí y no deja a los otros miembros en problemas como este.

La mala entrada de la persona es solo un síntoma, no una causa, la raíz del problema está en el nivel del equipo. , y su empleador necesita un líder que venga y lo aborde, alguien debe establecer estándares y asegurarse de que las personas los cumplan, todo lo demás son solo síntomas.

Estoy de acuerdo.Cada uno de los elementos que el OP señaló como problemas podrían haberse resuelto fácilmente desde el principio si los 3 programadores se hubieran molestado en hablar entre ellos.La comunicación debería haber sido manejada por el liderazgo a través de reuniones de estado semanales.Incluso una reunión inicial del proyecto hubiera sido útil.
gnasher729
2015-02-22 19:30:33 UTC
view on stackexchange narkive permalink

Quien fuera el responsable de todo el proyecto cometió un error enorme. Entonces, si entiendo esto correctamente, durante nueve meses tres desarrolladores trabajaron sin ningún tipo de supervisión, uno (usted) hizo un buen trabajo, otro hizo un buen esfuerzo con un resultado desconocido y uno hizo un trabajo basura. El responsable no notó nada. Notaste que una persona visiblemente no hizo ningún esfuerzo.

Suponiendo que usted no era el responsable de todo el proyecto, sino el responsable de su parte, la lección debería ser que si su proyecto falla, no ayuda mucho si hizo su trabajo. El proyecto falló. Cuando eso suceda, todo tu equipo podría ser despedido, incluyéndote a ti, y a nadie le importa quién trabajó duro y quién fue vago. O la persona considerada culpable podría ser despedida, y si ese colega vago es mucho mejor que tú en la política de la oficina, entonces podrías ser visto como la persona culpable.

Entonces, la regla es: haga su trabajo, pero también haga lo que pueda para que todo el proyecto tenga éxito. O intente pasar a un proyecto que tendrá éxito si el suyo va a fallar. Debe nunca ignorar las cosas que harán que su proyecto fracase, porque el resultado no será bueno para usted.

Por lo tanto, debería haber expresado su preocupación cuando vio problemas y no ignorarlos.

A un nivel que es realmente irrelevante para el lugar de trabajo, pero relevante para el desarrollo de software: las revisiones de código son absolutamente esenciales. No habrías tenido problemas con las revisiones de código. Las pruebas unitarias son realmente útiles para asegurarse de que su código funcione (y también deben revisarse para verificar que prueben algo útil).

Strader
2017-12-02 00:14:39 UTC
view on stackexchange narkive permalink

La comunicación es la clave para cualquier proyecto con más de un nivel de responsabilidad en general. Lo primero que debería haber hecho al conseguir un nuevo puesto después de las vacaciones es analizar e informar sobre la situación actual.

Esto habría marcado una clara línea de sucesión entre el liderazgo anterior y usted.

Después de eso, lógicamente, tuvo que crear un plan para cada punto del problema en su informe anterior, tal vez incluso con plazos estimados para corregir

Según el requisito del cliente: ¿Cómo fue la comunicación? ¿Tenía un analista dedicado para comunicarse con él?



Esta pregunta y respuesta fue traducida automáticamente del idioma inglés.El contenido original está disponible en stackexchange, a quien agradecemos la licencia cc by-sa 3.0 bajo la que se distribuye.
Loading...