project management - soho - ¿Cómo recuperas un proyecto fallido?

software para project manager (21)

1) Lo primero que evaluaré es si las personas del equipo están comprometidas con el proyecto o no. Si no, no tiene valor hacer otra cosa. Nada puede evitar el desastre a menos que consiga un equipo dedicado y comprometido. 2) Me aseguraré de que haya un QA en el equipo. 3) Proponer un plan razonable de lanzamientos iterativos e incrementales para el cliente. Con el desastre en el que nos encontramos, no hay forma de que el cliente pueda obtener todo pronto. En función de las prioridades del cliente, le proporcionaremos pequeños incrementos de funcionalidad con frecuencia. Esto mantendrá al cliente involucrado, un poco menos nervioso ya que está viendo que algo está sucediendo.

Debes haber escuchado la historia arquetípica de un proyecto fallido / fallido:

Un equipo de programadores inexpertos trabaja 24x7
Los errores se solucionan solo para introducir nuevos errores
El cliente está gritando que ni siquiera podía hacer las cosas básicas (Ahorro / Consulta), etc.
Los programadores solían tener la dificultad especificada para improvisar
Ninguna prueba unitaria automatizada agrava la situación
El documento de arquitectura que se veía bien en el papel no se siguió en la práctica
Los componentes de terceros utilizados se convierten en cuellos de botella que no han sido probados para la aptitud en primer lugar
Hito después de un hito perdido
El equipo no puede presentar una fecha de entrega ya que nadie está de acuerdo con la cantidad de trabajo que realmente se debe hacer
Sin liderazgo técnico / o un codificador de vaquero que pueda asumir los problemas técnicos

Ahora, si te trajeron como # 10, ¿cuáles serían tus primeros pasos?

Actualización: Antes que nada: Gracias a todos ustedes por participar. Bueno ... Me trajeron como # 10. Fui el Arquitecto original que ancló la solución cuando hicimos la propuesta al cliente. Entonces, lamentablemente, no pude asumir las responsabilidades de entrega ya que me asignaron otro lugar. :)

Digamos que es una webificación de una aplicación de escritorio existente. Ahora me traen como # 10. Huir, por desgracia, no es una opción. Estoy seguro de que esto se puede revertir siguiendo las mejores prácticas ágiles y solo quería aprovechar las ideas de la comunidad.

La pregunta más importante quizás sea esta: si el equipo de desarrollo no tiene especificaciones, sino solo el código (en línea) para una aplicación en ejecución, la solución original requería ver el código y extraer las reglas de negocio sobre la marcha. ¡Ahora, los programadores inexpertos son reacios a mirar el código de VB 6.0 y quieren documentos! Entonces, ¿cómo luchas contra esto si instalas procesos ágiles?

Aquí está el resumen del aprendizaje clave después de leer sus experiencias:

Máxima
1: Asegúrate de que esto no sea un "Marcha de la Muerte"

Ellie
2: Asegúrese de que lo entregado funcione 3: Base de código Refactor & Realgin a Arquitectura / Mejores prácticas 4: Observe cuáles son los problemas reales: ¿Es técnicamente competente para el equipo?

Kendall
5: Asegurar disponibilidad de Liderazgo Técnico

Bill K
6: Implementar procesos ágiles (al menos pruebas unitarias automatizadas si no TDD, iteraciones cortas que hacen que el progreso sea visible) 7: Obtener la aceptación del cliente 8: Prepárate para descartar lo que no funciona (ilusión)

Madriguera
9: Asegúrate de que los miembros del equipo que permanecen tengan la oportunidad de volver a empezar

Tim
10: motivar al equipo y a medida que la mejora se vuelve visible, recompénselos

jsl4980
11: Necesita que el equipo lo admita a tiempo (la mayoría imp.) Y el cliente [Esto genera más preguntas. ¿Qué sucede si su cliente pregunta si el equipo es lo suficientemente competente como para cumplir con su cronograma? ¿Qué pasa si usted mismo sabe que las líneas de tiempo que el equipo propone solo muestran su falta de comprensión?

Ather
12: ¿Está el equipo comprometido?
13: ¿formalmente QA?

Patricio
14: Comience, rediseñe y reconfigure las mejores prácticas de Arquitectura / Diseño para los módulos que aún no se han desarrollado.

El sentido común ya te ha sido señalado por Maxim (Salir de la marcha de la muerte). Pero si por razones desconocidas desea persistir, permítame que lo regale con mi experiencia en una situación similar, tal vez podría ser útil.

Era mi primer trabajo en un viejo y soñoliento pueblo donde los buenos trabajos en computación eran difíciles de conseguir y necesitaba uno inmediatamente después de la universidad. Me contrataron porque la gerencia pensó que yo era lo suficientemente entusiasta y podría ser mejor que nada (me ofrecí a traer mi propia compilación para ahorrarles el costo de darme una PC y me ofrecieron trabajar solo para la experiencia)

El proyecto había sido abandonado por sus creadores debido a la situación de la marcha de la muerte y se había ido después de eliminar todos los comentarios en el código y realizar otras ofuscaciones. Nadie sabía cosas de win32 / MFC tampoco.

Simplemente comencé a estudiar el código en papel viejo y lápiz (muchos frotamientos y correcciones) hasta que en 20 días supe el código completo, incluidas las variables de memoria, y qué y dónde estaban sucediendo las cosas.

Armado con este conocimiento, pude hacer una pieza crítica que ya había eludido a todos. Por supuesto, esto no era más que una gota en el océano, pero le permitió a la gerencia comprar la confianza de los clientes "compañero inteligente - lo consiguió con gran dificultad - ya funcionó x - tendrá que trabajar duro todo el tiempo".

Una vez que el cliente se convenció y pudimos comprar algo de tiempo, se nos quitó algo de presión. Esto me dio un poco de esperanza al equipo y empezamos a luchar para siempre. 6 meses después me promocionaron para liderar el proyecto y 9 meses más tarde tuvimos nuestro envío de reparación (muchas demostraciones de progreso y un cliente visiblemente más y más satisfecho en el medio).

Como puede ver, los elementos de éxito no se pueden duplicar directamente. Pero resumiría que necesita inspirar un poco de esperanza en el proyecto primero, mostrar un poco de progreso y ganar confianza, la de sus pares, la administración y el cliente. Una vez que esté en su lugar, las cosas técnicas también deberían corregirse; no hay nada que reemplace esta parte de la ecuación.

Si eso no parece probable, todo ese trabajo duro (oh, sí, montones y montones de trabajos como nunca imaginaste, ¿por qué crees que se llama una marcha de la muerte?) Sería un desperdicio y será mejor que lo dejes incluso antes de que comiences.

No tenía otra opción y tenía mucha sangre y necesitaba desesperadamente un trabajo. Los detalles técnicos donde algo podría funcionar mágicamente, y todo acaba de hacer clic en su lugar. Realmente gané mucha buena voluntad y respeto por mí mismo con ese trabajo, pero a la larga es solo una historia que puedo narrar con gran aplomo y nada más, excepto por aquellos pocos que saben.

Las cosas pueden ser diferentes para ti, pero es para que tú lo decidas.

Buena suerte

Si puedes, escapa.

De lo contrario, debe detener todas las actividades que hacen que el proyecto sea inestable, incluida la codificación y la reparación de defectos.

Evaluar dónde estás

Divida los requisitos en "hitos" mucho más pequeños

Lea algunos libros prácticos (me viene a la mente la "Guía de supervivencia de proyectos de software" de Mcconnell).

Identifica todos los problemas y riesgos. Comuníquelos a todos los involucrados.

Trabaja en cada pieza de a una por vez.

Celebre mejoras e hitos a medida que se alcanzan.

Buena suerte. Tu escenario suena bastante mal. Puede no ser rescatable, y las cosas tienen que cambiar para mejorar.

Si realmente tuvieras que ponerlo en marcha (si no es una opción optar por rescatar)

Comience aceptando que es un fracaso en la administración. Es posible que desee continuar implementando un proceso estricto pero ligero.

Sugeriría alguna forma de Agile, ya que es la más fácil de implementar sin GURU, pero tienes que ser MUY estricto al respecto, incluido el Emparejamiento, la Refactorización despiadada, Revisiones, la funcionalidad de Spiking, Visibilidad, TDD, Ciclos de una semana, Jornadas de trabajo de 8 horas (Sí, más de 8 tiende a dañar la productividad más que a la ayuda, como parece haber notado) ...

No corte nada tampoco. Las partes de Agile dependen de otras partes: sin el emparejamiento, refactorización y prueba, no se puede eliminar el diseño inicial (uno de los mayores fallos ágiles).

No te olvides del lado de la administración. Una semana de iteraciones para comenzar (demo CADA semana). Adaptación constante Muy cortos stand-ups todos los días para abordar problemas. (Manténgase en un máximo de 15 minutos, planifique problemas más largos, etc.) Gráficos de Burndown, equipo central con un cliente en él.

No puedes tener una reunión de 15 minutos cada semana y iteraciones de 2 semanas y llamarla Agile, pero si lo haces bien, simplemente PODRÁS darte una oportunidad. Puede obtener un BUEN consultor ágil para que lo capacite para comenzar.

Además, evalúe constantemente qué funciona y qué no. Prepárate para arreglar lo que no funciona. Reuniones semanales para analizar los éxitos y fracasos de desarrollo de esa semana.

En general, PUEDE funcionar, y puede alinear a un equipo agitado, pero no es trivial. La mejor parte es que puede implementarlo sin tomar grandes cantidades de tiempo de su desarrollo actual. Simplemente continúas desarrollándote, pero lo haces mejor.

Situación difícil, no tiene confianza del cliente cero y, básicamente, no puede tener éxito en esa situación, pase lo que pase.

Para todos los efectos, el proyecto necesita un reinicio; el desafortunado hecho es que las tiendas incumbentes usualmente no tienen esta oportunidad para comenzar de nuevo y reevaluar todo lo que está allí.

Odio decirlo, pero debes detener el desarrollo y pasar un mes resolviendo lo que salió mal ...

El resultado debe ser un plan para una entrega factible de 6 meses a 1 año, realmente haciendo que se concentren en lo que se debe tener y en los estudios de comercio real sobre los componentes de terceros. Y destrozar la base de código debe ser una opción; Comience un nuevo proyecto de control de fuente y cuando llegue a un módulo en particular, explótelo y deje la basura atrás.

Agile es genial y todo, y un enfoque válido una vez que se establece un plan real; pero no va a arreglar una relación rota con su cliente ... o toda la basura que ya está allí.

Usted se detiene y se toma el tiempo necesario para llegar a una especificación completa que usted y el cliente acuerden.

Luego, evalúa las especificaciones reales y crea un cronograma realista. Si no puede ponerse de acuerdo sobre el cronograma, debe decidir qué se cortará del primer lanzamiento.

Luego, priorice todas las tareas, comience a delegar el trabajo y, finalmente, deje que sus programadores lleguen a lo que son buenos.

Haga un seguimiento de todo el progreso y asegúrese de que todo el equipo y el cliente sepan dónde se encuentra en su nuevo horario.

Si empuja a su equipo basado en líneas de tiempo poco realistas, su equipo comenzará a buscar nuevos empleos. Tus mejores codificadores encontrarán nuevos trabajos y te quedarás con los que nadie más quería contratar, y estarás atrapado en la situación descrita anteriormente en cada proyecto.

Asegúrate de no ser el chivo expiatorio
Cortar alcance fluencia
Recortar los "requisitos" de funcionalidad
Implementar un ciclo de desarrollo más rápido (tal vez Agile / Scrum / XP / lo que sea)

Lo que sea que hagas, hazlo paso a paso.

Primero, no se trata de las características de addind, se trata de arreglar la aplicación. No agregue nada nuevo. Sólo refactor. Di no a las cosas nuevas que alguien te pida que introduzcas en el sistema.

No intentes mejorar toda la aplicación. Lleve a su equipo, haga que se enfoque en un aspecto a la vez, con las mejores prácticas que pueda, especialmente al usar la prueba unitaria.

Utilice el desarrollo impulsado por prueba solamente. En ese caso, le mostrará de inmediato qué parte del comportamiento no comprende (no puede codificar una prueba si no sabe qué evaluar).

Así que aquí está el mapa de ruta:

Identifica la parte crítica que necesitas para cambiar
Aislar el código que implica este comportamiento
Encuentre cualquier ocurrencia de este código en el resto del código
Refactor usando este conocimiento y TDD masivo
Integre, pruebe y corrija hasta que esta pieza en particular funcione
Volver al paso

Haga que la situación sea clara para su jefe: tomará tiempo, dinero y será doloroso. Explica por qué, qué harás y que no tienes otra opción o fallará OTRA VEZ.

A sobre todo, no trates de hacerlo limpio la primera vez. Refactorice lo que pueda, pero no espere cambiar toda la arquitectura de la pieza en la que está trabajando la primera vez. Tendrá que repetir el proceso en toda la aplicación varias veces.

Sin milagro Solo método y paciencia.

Huir o encontrar un nuevo trabajo. Esta es una marcha de la muerte y necesitan un chivo expiatorio.

A menudo, la marcha de la muerte implicará intentos desesperados de corregir el curso del proyecto pidiendo a los miembros del equipo que trabajen horas especialmente agotadoras, fines de semana o intentando "arrojar (suficientes) cuerpos al problema" con resultados variables, que a menudo causan agotamiento.

Vyas, siento que podría haber escrito esta pregunta. Mi trabajo anterior consistió en resucitar un proyecto de KVM que había fallado después de un año de desarrollo. Las especificaciones tenían forma de manual de usuario y la experiencia de los desarrolladores con productos similares. Terminé enseñando C a 3 programadores de ensamblaje y redefiniendo desde cero. Trajimos el producto con éxito al mercado en 4 meses. (Entonces renuncié. Ve a la figura)

Algunas de las cosas que haría de nuevo, particularmente con un equipo inexperto:

1. Un equipo de programadores inexpertos trabaja 24x7
10. Sin liderazgo técnico / o un codificador de vaquero que pueda asumir los problemas técnicos

Deles un (¡corto!) Descanso del proyecto para "recargar". Tal vez un día, tal vez una tarde, o tal vez un almuerzo largo contigo. Marcará el final del "viejo" proyecto y el comienzo del éxito.
Obtenga su consentimiento para trabajar hasta el final cuando regresen, y prometa que usted será su compañero, animador y chaleco antibalas. Ustedes, colectivamente, son un equipo, y su trabajo es forjar su camino, eliminar las distracciones y liderarlos.
Planifique un éxito inmediato, sin importar cuán pequeño sea, y mantenga una actitud de "poder hacer".

8. Hito después de un hito perdido
9. El equipo no puede presentar una fecha de entrega ya que nadie está de acuerdo en cuanto a la cantidad de trabajo que realmente se debe hacer
3. El cliente está gritando que ni siquiera podía hacer las cosas básicas (Guardar / Preguntar), etc.

Toma pequeños bocados! Rompe cada pieza lo más posible, luego trata con los componentes pequeños. Identificará los "errores" temprano y estará en mejores condiciones para abarcar todo el proyecto.
Define tus interfaces Cada vez que pueda aislar un trozo, hágalo. Esto permite el desarrollo paralelo, porque ya ha decidido los parámetros, precondiciones, suposiciones, lo que sucede dentro y los valores de retorno. Puede anularlo y crear otros módulos y pruebas de forma independiente.
Priorizar Enfóquese primero en los defectos y problemas que afectan al cliente. Las nuevas funciones son las últimas. Si es necesario, difiera las funciones en lugar de enviar código con errores.
Asignar responsabilidades. Se prefieren los voluntarios, cada uno en su área de experiencia, pero una persona debe ser responsable de cada tarea.
Haga un seguimiento de los defectos y registre todo lo que le ayudará a reproducirlos, ubicarlos y solucionarlos. Documente cualquiera que permanezca en el momento de la entrega, para que el cliente no se sorprenda.

4. Los programadores solían tener la dificultad especificada para improvisar
6. El documento de arquitectura que se veía bien en el papel no se siguió en la práctica

Creará los detalles de las especificaciones a medida que avanza, cada pieza justo antes de que se necesite. No es necesario que sea bonito, completo o incluso escrito, siempre y cuando todos entiendan la tarea actual y tengan una idea general.
Discuta la implementación, de a una por vez, cuando el desarrollador esté listo para codificarla. Escriba el esqueleto usted mismo si es necesario, y deje que el equipo complete las "agallas". Desea mantenerlos enfocados en cada tarea, sin "improvisar".
Estar disponible para responder preguntas a medida que surjan. Tu objetivo principal es mantener productivo al equipo.

2. Los errores se solucionan solo para introducir nuevos errores
5. No hay pruebas unitarias automatizadas que agraden la situación

Planifique y comience las pruebas unitarias lo antes posible. Si es posible, aliste recursos fuera del equipo.
Solucione pequeños problemas antes de que crezcan o se oculten. La confianza en cada pieza pequeña genera confianza en el conjunto.

7. Los componentes de terceros usados se convierten en cuellos de botella que no han sido probados para la aptitud en primer lugar

Haga una lluvia de ideas sobre soluciones cuando no está codificando. No dejes que detengan tu progreso si es posible. ¿Puedes encapsular o codificar a su alrededor? ¿Sustituirlos?

Sugerencias generales:

Mantente al frente del equipo. Anticipa e intenta resolver problemas antes de que tu equipo los golpee. Reúna toda la información necesaria antes de que sea necesaria.
Comunícate constantemente. Deje en claro que no desea sorpresas y solicite inquietudes, preguntas, estado, controles de carreteras, etc. a lo largo de cada día. Aliente la colaboración y comparta "descubrimientos" en todo el equipo.
Celebra cada éxito. Complemente una solución inteligente, traiga rosquillas cuando se resuelva un problema, demuestre una nueva característica de trabajo ... cualquier cosa que demuestre que el equipo las aprecia.
Realice cada tarea, luego avance. No pierda el tiempo ajustando, mejorando o retrabajando nada que no sea una barrera directa para el éxito.
Cumpla sus promesas con el equipo, el cliente y su administración.

Buena suerte, ¡por favor mantengannos informados!

Ya no se trata de liderazgo técnico, ahora se trata de gestión de proyectos.

Usted, como líder técnico, solo cambiará de tumbonas en el Titanic. Así que esto es lo que haría si fuera el administrador de proyectos de facto.

1) Identifique los patrocinadores y partes interesadas del proyecto, tanto los oficiales como los reales .

2) Vaya a ellos y solicite que el proyecto "se apague" durante una semana.

3) Si no están de acuerdo, aléjate de este proyecto.

4) Si lo aceptan, llame a un tiempo de espera del proyecto por una semana: todo se detiene.

5) Pasar toda la semana hablando con las personas importantes del proyecto para identificar el estado real del proyecto.

6) Mientras participa en esas discusiones, comience a formular un plan de recuperación del proyecto, enfatizando las posibles compensaciones entre el alcance, el cronograma, el presupuesto y el personal.

7) Al final de la semana, decida cuáles (si corresponde) de sus posibles escenarios de proyectos son factibles.

8) Devuelva lo mejor de estos escenarios a los patrocinadores y partes interesadas del proyecto, y comience a negociar.

9) Cuando se acuerde un camino a seguir, reinicie el proyecto y ore, posiblemente no en ese orden.

Aquí hay un buen libro sobre el tema:

Desenredamiento de catástrofes: volver a poner en marcha los proyectos de software

Estado allí, siguió estos pasos:

Estabilizar

reúna la historia real: qué tan bueno / malo es el código base, qué tan buenos / malos son los desarrolladores, qué es lo que realmente se debe hacer (mínimo básico), cuando se debe hacer por
reducir las horas extraordinarias (personas cansadas, buenas o malas, no funcionan bien)
elimine lo malo, ingrese nuevo / bueno - err en el lado de reemplazo (muchos podrían quemarse y apreciar incluso un cambio forzado)
eliminar el acceso al código incorrecto / no requerido (céntrese en el 20% de la base de código que proporciona el 80% del valor)
ponga las prácticas del código de base en su lugar asegurándose de que solo ingrese un código bueno (no dañe la base)

Controlar

implementar equipos enfocados en los componentes de la aplicación (desacoplar tanto como sea posible)
poner la gestión del código, la gestión del lanzamiento, la gestión de riesgos, QA, etc. en su lugar (construya su entorno para que pueda tener éxito)
ponle a tus clientes / patrocinadores un buen lado - entrega una ganancia, incluso si es una versión muy pequeña muy estable - y luego pon la administración del cambio (controla lo que se solicita)

Seguir adelante

desarrolle un plan (la planificación es esencial, los planes son inútiles según Ike: debe planear encontrar lo que falta y establecer un objetivo, pero no prever el futuro) - se requiere una planificación continua
administre agresivamente a su gente - las buenas personas hacen un buen producto - asegúrese de obtener y retener lo mejor
Refactor a lo largo del tiempo: limpie el código sobre la marcha. Es posible que no tenga el lujo de arreglar todo a la vez, hágalo horas extras para proporcionar una base de código más limpia.
avance valientemente: las horas extras sean más agresivas con su prueba de entregas (pero no el estrés) de su equipo

Espero que te paguen muy bien. En cualquier caso, mi plan sería algo así como estos pasos en el siguiente orden:

0) Deja de agregar funciones o funciones en todo el equipo. Permita que se solucionen los errores mientras se siguen los pasos siguientes hasta el paso 5, luego detenga la reparación de errores y el desarrollo de funciones de reanudación:

1) Aplicar lo que llamo la Ley de personal inverso : los miembros del equipo más débiles reducen la velocidad de los mejores y más rápidos y, en general, un proyecto de software tardío necesita personas eliminadas, no agregadas. Por lo tanto, debe evaluar la calidad de los miembros del equipo como contribuyentes individuales. Elimine al personal más débil del equipo porque presumiblemente hay algunos. Esto se hace mejor revisando su código y examinando las correcciones de errores, averigua quién está empeorando el código y mejorando, y córtalo para el equipo. Este no es un momento para ser mentor, vas a necesitar a las mejores personas para tener un cambio de "arreglar" la situación en un período de tiempo óptimo. Si no puede despedirlos o reasignarlos, haga que tomen café o algo para todos los demás.

2) Evaluar el código en sí. Identifique las áreas del código que no están bien construidas y / o no bien abstractas. Si un código de área no está bien construido y / o es obviamente frágil en lo que se supone que debe hacer, apúntalo para volver a escribirlo. Esto se siente doloroso en este punto, pero le ahorrará tiempo a la larga. Errores recurrentes y / o historial de correcciones ayudarán a identificar el código que no se puede salvar. Si un área o módulo de código está construido fundamentalmente bien, pero no se abstrae bien en el nivel de interfaz, debería ser adecuado para volver a factorizar. Esto ahorrará mucho tiempo y es un código útil. Mantenga una lista de las áreas de reescritura, las áreas de reajuste y las áreas adecuadas.

3) Defina una nueva arquitectura razonable que crea que dará como resultado una solución robusta y completa hacia donde desea estar eventualmente en características y funciones. La arquitectura puede no ser óptima, ya que comienza limpio, pero de hecho hace coincidir lo que tiene con dónde le gustaría estar.

4) Trabajar con los interesados para decidir qué hará una primera publicación aceptable intentando incluir tantas características como sea posible para lanzamientos "posteriores". Tal vez no puedas cortar nada, pero si puedes, ahora es el momento de hacerlo.

5) Detenga los esfuerzos de reparación de errores de fondo y asigne el trabajo definido al equipo (restante) para estimar un nuevo plan de implementación razonable del resto de la funcionalidad. Necesitan tener el horario. Completa el horario y sé bastante conservador. Ahora tiene una predicción razonable de cuándo podría tener algo realmente viable y robusto.

6) Implementa las características restantes y luego fortalece la liberación atacando los errores restantes. Estoy asumiendo que todas las buenas prácticas normales de desarrollo de software se observan aquí como control de fuente, pruebas unitarias, etc.

7) Elimine la mayor cantidad posible de barreras para que el equipo pueda generar cosas lo más rápido posible.

8) Controle los problemas y ayúdelo ensuciándose las manos donde sea que pueda. Ofrézcase para abordar los asuntos más desagradables en la medida en que pueda ayudar y aún así mantener a todos los miembros del equipo como productivos.

¡Buena suerte!

Refactorización ágil.Identificar y priorizar lo que el cliente quiere y luego crear el material más importante en carreras cortas de código existente. Buena suerte :)

En primer lugar, resuelva que puede fallar; si no puede aceptar eso, no acepte el desafío. Y eso incluye ser un chivo expiatorio (sucede). La gerencia no lo verá en esos términos (es decir, no lo están "configurando intencionalmente / conscientemente"). Pero esa es una realidad de un entorno corporativo; si asumes la responsabilidad (a menudo con más paga que aquellos que no lo hacen), tu cabeza es para el bloque si las cosas no funcionan. Tienes que estar listo para seguir con esto a largo plazo también. Una vez me colocaron en el sitio de un cliente durante 8 meses para arreglar un proyecto en decadencia. Y como viste, uno de los otros carteles de blog pasó 9 meses antes de que la versión de lanzamiento estuviera lista.

Ahora, suponiendo que estés de acuerdo con la posibilidad de que tenga forma de pera a pesar de tus esfuerzos, esto es lo que sugiero:

un sistema de seguimiento de errores va a ser tu mejor amigo número uno, te permitirá recuperar el control. no puede esperar comprender un sistema complejo como un todo, por lo que ''fragmentarlo'' ayudará. y un sistema de seguimiento de errores le permite unificar problemas y distribuirlos a otros tipos con los que está trabajando.
tienes que enfrentar desafíos tanto técnicos como políticos. los técnicos generalmente no son tan malos porque eres un codificador y sabes cómo hacer esto. los políticos son mucho más complicados, usted está a la cabeza de un barco que se ha ido completamente fuera de curso, y usted está en el triángulo de las Bermudas. el mayor desafío es a menudo frenar la ola de sentimientos negativos entre el cliente (por ejemplo, el cliente: "estos vaqueros no saben lo que están haciendo", "me lo prometieron y no cumplieron", "no tengo confianza"). en estos chicos a más ").
para empezar, discúlpese con el cliente y cuéntele en términos concretos lo que está haciendo para volver a corregir su proyecto, por ejemplo, usted: "Lamento el retraso en su proyecto, ahora me estoy quedando atrapado". He visto la historia del proyecto, y personalmente, también me enojaría si estuviera pagando un buen dinero por este sistema. Lo primero que voy a abordar es ... "<- bingo, acabas de tomar responsabilidad del proyecto, lo que significa que no hay vuelta atrás, es todo o nada ahora.
algunas otras personas lo han dicho aquí, y estoy de acuerdo; deja de agregar nuevas funciones. lo que no han mencionado es que quizás tenga que hacer esto para mantener feliz al cliente (recuerde, hay un lado técnico y político para el desafío).
comprenda el dominio comercial lo mejor que pueda. lea todos los documentos de requisitos que pueda tener en sus manos. estás en una desventaja masiva al llegar tarde al proyecto ya que no sabes lo que se discutió originalmente. El diablo está en el detalle. esto es lo que me hundió en proyectos tardíos que no pude salvar, todos estaban nerviosos y me perdí un requisito menor. en ese momento, no era un gran problema y podría haber sido corregido fácilmente, pero políticamente hablando, fue la gota que colmó los camellos. Una táctica que puede ayudar es salir en el sitio del cliente por unas semanas.
entiendo que el tiempo es dinero no es solo un problema técnico. el cliente ha pagado por algo que no está bien o que no ha sido entregado. su compañía ha gastado recursos, posiblemente ya haya agotado todo el presupuesto del proyecto; el negocio ahora está perdiendo dinero. y aquí es donde vuelve a aparecer el tema de las nuevas características, sí, la gente dice que no las agregue, establezca. pero agregar nuevas características puede ser una táctica políticamente útil, la administración estará contenta porque habrá dinero nuevo para el trabajo fuera de especificaciones.
Recomiendo en contra de usted o su equipo de codificación que trabajan horas ridículas para entregar. Si normalmente sale a las 5 p. m., salga a las 6.30 p. m. o a las 7 p.m. en su lugar. usted y sus chicos de codificación pueden mantener consistentemente una o dos horas de trabajo extra durante muchas semanas seguidas y tal vez de 4 a 5 horas durante el fin de semana. trabajar hasta las 9 p.m. o las 10 p.m. todas las noches provocará agotamiento en aproximadamente 2 semanas (algunas pueden durar más). después de ese punto, su tiempo extra en el proyecto le está haciendo más daño que bien. en el caso improbable de que su jefe tenga problemas con esto, haga una elección; hagan lo que piden (es decir, trabajen más horas), o digan "Ya he dedicado horas extras para trabajar en este proyecto: estoy aquí por mucho tiempo y voy a terminar este proyecto si es mi muerte". pero ese es el límite de cuánto tiempo estoy dispuesto a aportar. Tengo otros compromisos para mantenerme fuera del trabajo "<- pero prepárate para las consecuencias (recuerda, tanto la situación política como la técnica).
Hay personas aquí que dicen: "deténganse y escriban una especificación, deténganse y hagan esto ..." - Lo siento muchachos, simplemente no puedo estar de acuerdo con ustedes aquí, es poco realista. el proyecto ya está estancado, lo último que la gerencia o el cliente quiere es "tenemos que parar todo y ...". Lo he intentado antes, cuando le dije al cliente y a la gerencia "los errores seguirán llegando hasta que nos detengamos y escriba un plan detallado de prueba del sistema. Me llevará dos semanas": el cliente no quería para pagar esto, y la gerencia no estaba dispuesta a usar el costo. como sucedió, los errores seguían llegando.
aprende a ''hacer malabarismos'' - tienes que trazar las tareas antes de tiempo para que los programadores no te estén esperando. esto generalmente significará que usted hace menos codificación usted mismo. en general, esto se logra mejor teniendo un cronograma del proyecto antes de que comience la codificación. los programadores deberían saber lo que están haciendo después de terminar lo que están trabajando actualmente, y no deberían venir a preguntarte "¿en qué trabajo trabajaré ahora?", ya deberían saber.
utilidades de recuperación incorporadas, especialmente si el software tiene problemas recurrentes que son difíciles de precisar. por ejemplo; puede llevar 12 horas rastrear un error y arreglarlo, puede tomar 2 horas ponerle utilidad (léase ''piratear'') para arreglar el problema por el momento. el tiempo y el momento son del essessen, y desafortunadamente se pueden necesitar correcciones de bandaides.
ser muy observador del estado de ánimo de los clientes. necesitan saber que estás "de su lado" (por ejemplo, cliente: "el producto es inaceptable", tú: "estoy de acuerdo, me gustaría patearnos el culo si estuviera en tu posición. Todo lo que puedo decirte es que estoy en ello" y no descansará hasta que todo funcione "). cuando el cliente vuelva a su sitio, en realidad comenzarán a ayudarlo. por ejemplo, pueden protegerte de la presión de tu gestión.
guía a tus hombres con el ejemplo. algo como "me quedo un poco para trabajar en el proyecto, agradecería la ayuda si estás dispuesto a quedarte también" y "sé que no es nuestro problema, pero aún vamos a limpiar" de todos modos. Quiero que el cliente obtenga un software de buena calidad ". los programadores generalmente se preocupan menos por la compañía que los metió en esta situación, pero les puede importar si se trata de uno propio o del cliente (''puede'').

muchas de las sugerencias que he visto aquí suponen un grado bastante alto de potencia (por ejemplo, "detener el proyecto para reiniciarlo correctamente" o "decir no a las nuevas funciones"): está comenzando el proyecto ya bloqueado, y como programador, Tradicionalmente tendrá menos poder para afectar el cambio que un verdadero administrador. esto no significa ''renunciar / no intentar'' - solo significa que vas a tener que ser creativo y hacer cosas que normalmente no haces (es decir, usar habilidades ''suaves'' o de personas).

Mucha gente aquí está diciendo fianza en el proyecto, corre por las colinas. He estado en 3 proyectos irremediablemente retrasados hasta la fecha. Logré arreglar 2, y 1 no pude arreglarlo personalmente, no me molesta tomar un proyecto retrasado. después de todo, lo peor que puede pasar es que te despidan :)

Congele los lanzamientos y comience a solucionar los problemas del programa ... trate las quejas de los clientes por prioridad (el lado comercial de la empresa puede priorizar) y ejecute el programa. Una vez que obtenga los mayores problemas fuera del camino, comience a limpiar el código. Asigne tareas a otros desarrolladores y comience a aplicar prácticas de codificación en todos los códigos nuevos.

Si puede hacer lo que quiera, observe cuáles son los problemas reales y trátelos. Si eso significa armar un nuevo equipo para desarrollar el software desde cero, que así sea. Pero deberías intentar al menos arreglar los principales errores. No se moleste en introducir nuevas funciones, solo agravan el problema, y un programa que no funciona y los problemas no se solucionan lo hacen perder clientes.

El número 10 es obviamente el peor problema, o al menos la raíz de todos los demás. Encuentre a alguien con cierta creatividad y capacidad para realizar un proyecto, y dele un reinado libre para hacer cualquier cosa, incluso comenzar de nuevo.

Si estuvo involucrado en el proyecto desde el principio, odio decirlo, pero la compañía debe reemplazarlo a usted (y a todo el equipo).

Se debe volver a analizar con un equipo competente con procesos de gestión de proyectos reales y dirigido por un gerente de proyecto con experiencia en esta situación.

Ninguno de los codificadores originales debería trabajar en el ''nuevo proyecto'' de guardarlo. Pueden pasar a otros proyectos (no tienen que ser despedidos), pero para obtener una nueva visión del proyecto, todos deben ser reemplazados.

Y, por supuesto, la gerencia debe comprender y estar de acuerdo con el hecho de que el proyecto va a ser mucho más tarde de lo esperado. Si la gerencia no está de acuerdo con esto (reemplace al equipo, encuentre un liderazgo experimentado, dé un paso atrás y vuelva a comenzar), entonces @Maxim tiene razón: salga de allí.

El resumen tiene 14 elementos. No puedes hacerlos todos. Entonces, ¿cuál es el primer paso?

Esto es lo primero que debes hacer: mejorar algo.

Tienes problemas de calidad fundamentales. (# 2-5)
Tienes problemas de arquitectura y componentes. (# 6, 7)
Tienes problemas de horario (# 1, 8, 9)

Puedes abordar la calidad. Las pruebas de unidad formal, dirigirse hacia TDD pueden ayudar. Esto puede ser difícil porque los problemas de arquitectura ralentizan las pruebas.

Puedes abordar la arquitectura. Esto podría ser más difícil porque probablemente implicará un retrabajo que no aparecerá como entregable. Pero puede solucionar problemas de calidad. O bien, se puede agravar por problemas fundamentales de prueba.

Puede abordar el cronograma. Sin otras correcciones (es decir, calidad o arquitectura) es posible que no obtenga ninguna tracción con la fijación de problemas de programación.

Creo que las mejoras generales en las actitudes de las personas provienen de comenzar con un éxito, cualquier éxito, tan pronto como sea posible. ¿Cuál es la fruta más baja?

¿Un error de larga data? Suite de prueba de una unidad para encontrar y corregir ese error.
¿Una característica arquitectónica principal? ¿Un diagrama que todos puedan publicar en su cubo ayudará? ¿Qué tal una presentación aclarar las cosas?
Un nuevo caso de uso? Una nueva característica que realmente funciona?