¿Cómo salvar un proyecto joven y moribundo?

Estoy publicando esto de forma anónima porque no quiero tener problemas potenciales.
Tengo un gran problema.
Recientemente me uní a un equipo que tiene menos de un año. He estado aquí desde un mes en que comenzó el proyecto. La estructura de la compañía se ve así:

• Propietario (no técnico)
  • Gerente de proyecto (no técnico)
    • Desarrollador principal (técnico, pero malo)

Este proyecto es un sitio web que utiliza ASP.Net para el que el desarrollador principal diseñó una arquitectura horrible. Tendrás que confiar en mi palabra, pero básicamente, la forma en que estamos obligados a crear páginas web nos da tiempos de carga de más de 3 minutos en una sola página web a través de VPN en modo de depuración.

Se ha disparado hasta el punto en que otros compañeros de trabajo están de acuerdo en que pasan más de su día esperando que se carguen las páginas que el desarrollo real.

Ahora el gran problema es este. Project Manager no conoce la tecnología y lo admite. Él ha declarado específicamente que confía en el desarrollador principal para tomar las decisiones correctas en la arquitectura de la aplicación.

Nadie en el equipo sabe cuál sería la opinión de los propietarios, pero todos tienen miedo de hacer olas en esta economía (especialmente yo).

¿Qué harías?

Este problema puede demostrarse al gerente del proyecto en términos muy poco técnicos. Coloque su sitio en una ventana del navegador frente al primer ministro y pídale que juegue un rato con él. Después de aproximadamente dos páginas cargadas, se debe llamar al desarrollador principal en la alfombra, si las cosas están tan mal como usted dice.

Puede que el primer ministro no tenga el conocimiento de desarrollo especializado para comprender por qué es malo, pero puede ver por sí mismo como un usuario general del sitio web que lo es. Otros sitios que muestran información similar se cargan en una fracción del tiempo que el suyo, y el suyo se está cargando a través de la red local desde el servidor de la sala contigua.

Si esto no vuela, entonces ve al dueño. El propietario es un tipo de dinero, pero muy pronto podrá ver que un sitio web lento que nadie visitará == sin dinero. Configure la misma demostración, y antes de que se cargue la primera página, debería llamar a AMBOS PM y al Plomo en su alfombra mucho más lujosa.

Si le preocupa que un tipo haga olas, entonces obtenga más de un desarrollador dispuesto a expresar sus preocupaciones. Honestamente, en una empresa tan plana como la suya, si el producto que está desarrollando es una bomba, no tiene trabajo, ya sea que hable o se quede callado. Mirándolo de esa manera, no tiene nada que perder, sino un par de semanas o meses adicionales con la compañía. Si eso es un problema, programe algunas "citas con el dentista" y busque un nuevo empleo antes de expresar sus preocupaciones, por lo que si pierde este trabajo, comenzará el próximo lunes.

Suponiendo que sus declaraciones sean precisas, tiene un Desarrollador Líder que es incompetente y un Gerente de Proyecto que es incompetente (al menos en la medida en que no pueda evaluar las habilidades del equipo). Multa. Tiene exactamente las mismas opciones que los desarrolladores en cada equipo en cualquier parte del mundo.

1. ¿Trabajas sin preocuparte por la salud de la empresa?

2. Busca trabajo en otro lado.

3. Haga sugerencias razonables al Líder, PM y Propietario y espere que sean adoptados.

Eres libre de hacer cualquier combinación de lo anterior simultáneamente.

Si desea asegurar agresivamente la salud del proyecto, tendrá que trabajar con los otros desarrolladores para crear un nuevo marco en su tiempo libre y demostrar al resto del equipo por qué es superior y el trabajo anterior debería ser abandonado a su favor.

Trabajé en una situación similar, donde el desarrollador principal que en realidad era socio de la compañía había creado el "núcleo" del software y, a excepción de un amigo cercano que trabajó directamente con él, a otros desarrolladores no se les permitió tocar el núcleo.

Los "poderes fácticos" también crearon reglas como cada módulo solo podría tener una tabla de base de datos, porque es más limpio de esa manera. Y como resultado de eso, los menús desplegables existentes se crearon seleccionando "DISTINCT" de las tablas en la base de datos, en lugar de tener una tabla separada.

Hubo una serie de parches malos flotando porque el equipo de implementación tuvo que hacer el trabajo, y el producto no funcionaría de fábrica. Estos parches causaron tantos problemas como se solucionaron y se personalizaron (piratearon) para cada instalación.

Mi enfoque consistía en tomar una pequeña parte de la especificación que el núcleo no soportaba y escribir un parche pequeño, bueno y genérico para él. Algo que satisfizo al equipo de implementación, pero que no fue tan amenazante como "Necesitamos cambiar completamente nuestro pensamiento". Debido a la animosidad entre el equipo de implementación y los desarrolladores principales, llevó meses convencer al equipo de implementación de que mi enfoque era mejor que sus ataques. Pero una vez que vieron que los escucharía e implementaría ajustes adicionales para apoyarlos, quedaron encantados y de mi lado. Al desarrollador principal le tomó otro mes aceptar el parche, pero una vez que lo hizo, realmente abrió la comunicación entre todos nosotros sobre mejores formas de diseñar otras partes del sistema.

Nunca es un camino corto para cambiar el pensamiento de las personas, especialmente si necesita mantener una relación civil con ellos. Pero si lo enfocas bien, puedes ganar respeto sin insultar a tu jefe.

¡Espero que ayude!

Muy simple respuesta y solución. Parece que todos son conscientes del problema. Por lo tanto, andar señalando el problema no tiene valor para nadie. De hecho, solo te hace ver como un llorón. Si desea agregar valor, entonces necesita señalar la solución y construir el caso de negocios para cambiar a su solución. Luego puede señalar el problema con una solución correspondiente. Una demostración también contribuiría en gran medida a probar su solución. Por supuesto, esto puede significar trabajar en su propio tiempo, pero todo depende de lo importante que sea para usted.

En primer lugar, sugeriría encarecidamente que se asegure de sus hechos, ya que es un problema de arquitectura de la aplicación y no algo en la configuración de VPN. He visto que las VPN mal configuradas causan este problema exacto. ¿Sabe con certeza que la aplicación es tan lenta dentro de la oficina?

Si ha descartado la red, iría con la sugerencia de KiethS y pediría al primer ministro que abra la página.

Suena como el negocio, o al menos el proyecto va a terminar en algún momento pronto. Antes de dejar de fumar, trataría de distanciarme de él lo más rápido posible, por ejemplo. voluntario / solicitud de trabajo en otros proyectos en marcha. Con suerte, con el tiempo, pasará menos tiempo en este desastre, y más en otros proyectos que tienen la posibilidad de funcionar. No querrás ser considerado como "el tipo que trabajó en el proyecto que no funcionó". Se trata de proteger tu reputación.

¿El propietario quiere un buen producto o no? Sospecho que la respuesta es "Sí" ... y, por lo tanto, debe hablar. Debe documentar la arquitectura actual y luego (con buenos datos imperiales), mostrar cómo el producto no cumple con las expectativas de rendimiento adecuadas. Dices que todos tus compañeros de trabajo saben que funciona mal, bueno ... ¿qué pasa con el cliente? ¿Qué están diciendo? Use una herramienta de medición de rendimiento y determine qué está tomando tanto tiempo. Muchas herramientas incluso le mostrarán cuánto dura cada llamada de función. De todos estos datos, debe tener suficiente munición para hablar con su gerente de proyecto y el líder técnico sobre por qué las cosas no son como deberían y cómo puede ser necesaria una refactorización importante para acelerar el producto.

Luego (solo después de hablar con el primer ministro y el líder), esto DEBERÍA ser suficiente para comenzar a hacer algunos cambios. Si el primer ministro no está convencido en ese momento, entonces debe decidir si este es realmente un lugar en el que desea estar. Si es así, entonces posiblemente una reunión con el propietario. Si no, prepare ese currículum.

Asegúrese de documentar cada paso del camino.

En términos técnicos, estoy de acuerdo con las sugerencias anteriores. Por otro lado, creo que es más un problema de relación que un problema técnico.

Si desea tomar la ruta sin problemas, hablar con el desarrollador principal será una opción adecuada. Sin embargo, no hablaría en la oficina. Tomar un café afuera hará las cosas un poco informales y más relajadas.

Si eso no funciona, puede intentar hablar con el primer ministro y luego con el propietario.

Si ninguno funciona, le sugiero que busque un nuevo trabajo.

Honestidad, y tanto tacto como puedas reunir.

Comience con el desarrollador principal y avance si es necesario. Trate de involucrar a los mejores lados de su personalidad: si dirige a los desarrolladores les gusta resolver problemas / le gusta salvar el día / le gusta ser eficiente / etc. haber tenido éxito en el pasado como motivación adicional.

Si no estás haciendo olas, probablemente estés muerto en el agua.

¿Sería posible devolver los problemas a un nivel que sea medible y de una manera no técnica para que el gerente y el propietario del proyecto puedan entenderlo?

Por ejemplo, mencionó el tiempo de carga lenta de más de 3 minutos, supongo que hay un requisito de rendimiento en algún lugar de la especificación, algo tan simple como "página para cargar en 1 segundo". Algo como esto es medible y no puede ser refutado. Si se descubre que la causa raíz de este problema es la arquitectura dudosa, entonces el gerente del proyecto y / o el propietario deberían intervenir para forzar algunos cambios.

De lo contrario, tiene un problema sistemático en su empresa en el que el análisis inicial se realizó mal y no hay suficiente proceso para detectar este tipo de problemas. ¡Considera saltar el barco!

Los hombres de verdad hablan sin resentimiento ni emoción. Ese es el truco.

La única razón válida por la que alguien podría estar en desacuerdo contigo por hablar es si te encuentras tan resentido:

El desarrollador líder no tiene idea de lo que está haciendo. Sabía que esto iba a suceder, pero nadie me escuchó, bla, bla, bla.

donde como

El modelo de código es incorrecto porque es difícil de mantener y lento. Necesitamos ser estratégicos sobre este avance y solucionar estos dos problemas.

La primera es una batalla para destruir, la segunda es una batalla por la paz y, a largo plazo, te ganará el respeto que una persona recibe por ser honesto.

Si el líder del proyecto toma esto como una afrenta, lo que ciertamente podría considerar que podría ser despedido, simplemente diga:

No me hagas responsable de las cosas que no fui responsable de implementar. Solo estoy siendo honesto.