¿Cómo convencer a la gerencia de que la garantía de calidad es importante?

Question

Trabajo para una pequeña compañía de software con menos de 10 programadores. Nuestro software está instalado en docenas de lugares en todo el mundo. Nuestra base de código es enorme, debido principalmente a un diseño deficiente y cantidades masivas de duplicación de código (IMO). Tenemos aproximadamente 30 proyectos diferentes, cada uno con un total de aproximadamente 600 KLOC, de los cuales aproximadamente 200 KLOC son nuestro código propio. Cuando llegué allí en 2006, este código ni siquiera estaba bajo control de revisión. Logré convencer a los poderes que es importante, y ahora usamos un sistema de control de código (cs-rcs, no es mi elección, pero es mejor que nada), y un sistema de seguimiento de errores. La gran pieza faltante es la falta total y total de control de calidad en el proceso. Nuestro proceso de lanzamiento no existe en el papel, y en la práctica consiste en "presionar ctrl-F9, copiar el binario al cliente, declarar el problema solucionado".

¿Alguien me puede señalar algunos documentos oficiales o documentos de PHB o artículos que pueden explicar la flagrante locura en este proceso? Estoy seguro de que el jefe podría contratar a un consultor para que le cuente esto, y entonces él podría creerlo. Pero solo soy un modesto mantenedor con una licenciatura en Ingeniería de Software. Y mi origen étnico tampoco me sirve. ¿Cuál es la mejor munición para usar en este caso?

Answer 1

Tautológicamente, la única forma de convencerlos es ponerlos frente a algo que sea convincente. Esa cosa podría extraerse de una lista como:

• La cara desastres predijo que solicita la adopción de la solución presentada anteriormente
• El desastre unforetold con una solución de nunca volver confeccionada
• una predicción brillantemente persuasiva de un desastre
• un brillante recurso persuasivo a la codicia (ahorro el coste de oportunidad de un predicho d isaster)

O algo más. En todos estos casos, alguien tendrá que presentar el caso en algún momento para la solución de garantía de calidad que usted propone, y que alguien, por lo que se vea, tendrá que ser usted. Entonces comenzaría a aprender sobre ser persuasivo.

How to Win Friends and Influence People debería costarle algunos dólares como máximo. Getting To Yes también es barato.

¿Cómo se llegó al acuerdo con el control de origen? ¿Puedes seguir eliminando, mejorando el proceso un pequeño incremento a la vez?

Prueba Google "change your organization", parecía haber algunos enlaces prometedores.

Y en última instancia, recuerde que (como dijo una vez un sabio) si no puede cambiar su organización, entonces debe cambiar su organización. Realmente siempre hay una alternativa.

Answer 2

Quizás si consigue que algunos de sus colegas programadores lo respalden, la administración estará un poco más dispuesta a escuchar. No es necesario ser un genio para darse cuenta de que una base de códigos enorme e inmanejable es indicativa de mucho margen de mejora.

Answer 3

Su mejor munición en este caso es esperar el desastre inevitable. Una vez que sucede, tenga todos sus patos en una fila con un plan que hará que este desastre nunca vuelva a ocurrir, uno que hace hincapié en que los costos de implementación son mucho más bajos que el costo del desastre en sí.

Ninguna cantidad de conversaciones hará que los PHB "lo obtengan" si no lo quieren "en primer lugar". Solo una gran bofetada de esa dura maestría, la realidad, los persuadirá al final.

Ah, y mientras lo haces, actualiza tu currículum y busca. Los desastres que tienden a convencer a las personas de que necesitan control de calidad son muy similares a los tipos de desastres que matan a las empresas.

Answer 4

Consulte de Joel book

Answer 5

Si su gestión no piensa control de calidad es importante, algo tan obvio y "sentido común" hasta el punto de que cualquier profano estaría de acuerdo con el, entonces no creo que poner un montón de documentos académicos, o cualquier otra cosa para el caso, para ellos hará la diferencia.

Su única esperanza es probablemente intentar armar un documento que muestre los ahorros de costos, pero dudo que eso ayude en este caso.

Answer 6

El dinero es su mejor apuesta, duele más cuando se trata de pagar.
creo que la siguiente imagen lo dice todo: Cost of bug http://www.developertesting.com/images/entryimages/paradox-figure3.jpg
(La imagen es de www.developertesting.com)

Answer 7

Administración no va a entender nada, pero dos cosas: (1) costo beneficio & (2) La satisfacción del cliente. El segundo es difícil de cuantificar, pero el primero es fácil. Puede gastar $ 40k a $ 60k en un ingeniero de control de calidad decente que pueda entrar y comenzar a darle sentido al desastre y comenzar a desarrollar un plan para solucionarlo. El costo beneficio viene de asegurarse de que un ingeniero más capacitado no tenga que pasar 2 meses rastreando un error oculto en 100k líneas de código.

Hay otra manera de hacerlo ... Puedes hacer lo que estamos haciendo donde trabajo.Comienza a escribir pruebas para el código al principio y luego, cuando hayas terminado con el código si la prueba pasa, entonces estás dorado. Una vez que la prueba haya pasado, se realizará una prueba que garantizará que si alguna vez descifra ese código, lo sabrá casi al instante. Y si logra que sus compañeros programadores participen de esa acción, al menos todo el nuevo código se desarrollará bajo un marco de prueba. Test driven development no solo hace que el proceso sea más rápido (usted ya sabe lo que quiere que sea el resultado antes de comenzar a codificar), sino que también ayuda a refinar sus requisitos a toda prisa. Lo más importante es que con un poco de ingeniería social (trabajando con sus pares) puede cambiar la cultura de desarrollo poco a poco hasta que el proceso esté completo.

Answer 8

Puedo recomendar The Toyota Way. La versión corta a menudo es posible ordenar gratis en los sitios web de toyota. La gerencia ya debería haberlo leído, pero aparentemente no lo han hecho. Léelo, digerirlo, haz que la administración lo lea. Como fuente de inspiración, realmente puedo recomendar leer Lessons from Toyota's Long Drive (vale la pena conseguir algunos dólares para obtener el PDF).

Answer 9

Trabajé en un departamento donde un grupo común rotaba entre las tareas de desarrollo y las pruebas. Esto logra dos cosas:

• , probadores eficientes altamente cualificados, que en el peor, sabía lo que el código estaba tratando de hacer, y cómo
• desarrolladores que conocían su vez venía a hacer la prueba, o que acababa de regresar de las pruebas. Así que el dolor de probar el código malo era conocido, como era el placer de probar un buen código.

El tipo más respetado en todo el grupo era un tester despiadado, y al desarrollarse produciría software de cero defectos.