Tengo una gran admiración por aquellas personas que en las empresas ejercen el rol de “los de calidad”. Aquellos sufridos profesionales a los que se les asigna la ardua misión de conseguir, y mantener, decenas de normas, ISOs con multitud de números, los CMMis, etc.
Los admiro por su dedicación, pasión y por saber soportar, y tener el tacto, de ir persiguiendo a media empresa para que las múltiples auditorías anuales consigan superarse con éxito y, además, aguantar a los auditores.
Pero lo que más me duele es verlos solos.
Me duele cuando vas a una empresa que te dice “queremos mejorar la calidad de nuestro software” y sólo hablas con “los de calidad”, pero… ¿y el equipo de desarrollo? ¿y los jefes de proyecto? ¿y el director de desarrollo? ¿y hasta el presidente de la compañía? ¿dónde están?
Las personas dedicadas a la calidad, pueden formar, ayudar, facilitar, orientar, motivar, etc., pero la calidad en el software la pone quien hace el software, quien lo programa, y la calidad en la gestión software la pone quien gestiona el software, y la calidad como objetivo estratégico – ventaja competitiva la pone el director de informática (sí, porque calidad software, la de verdad, implica productividad, ahorro de costes, etc., véase aquello de que mirar sólo la rentabilidad, y olvidar la calidad, puede arruinarte. Caso práctico, la desaparición de Xerox o lo de cosas que deberías saber si no quieres tirar dinero (o tirar el mínimo) manteniendo software o lo de que no tener un diseño de calidad cuesta dinero (si lees esto no me creo que sigas gastando en malos diseños)).
En mi caso, siempre que alguien me pide ayuda para mejorar la calidad software, y me huelo que solo voy a hablar con “los de calidad”, intento por todos los medios hablar con desarrollo, programadores, jefes de proyecto, directores, y hasta donde llegue.
Claro que, hay veces que llego y veces que no.
Eso sí, te puedes hacer una idea de la calidad del software que acabará desarrollando una empresa viendo solo si cuando llegas por primera vez te recibe calidad con todo el equipo de desarrollo o si te tienes que pelear para que te reciba de mal agrado un director de informática.
- Quieres que tus equipos cambien, pero pasan de ti + Nuevo video OKRs con IA + Cumplo 24 años de Doctor en Informática #LaNewsletterdeJavierGarzas - 26 septiembre, 2024
- Amazon: la IA nos ahorra 4.500 años de programación + 3 familias de ESTIMACIÓN + Video creando Videojuegos con Hija e IA #LaNewsletterdeJavierGarzas - 19 septiembre, 2024
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
En la primera empresa en la que trabajé en serio hicieron muchas cosas mal, pero la implantación del sistema de calidad no fue una de ellas. Hubo mucha inexperiencia y mucho parcheo por desconocimiento, pero se tenía claro que la calidad debe ser algo transversal en la empresa, aunque hubiera algún responsable.
Yo creo que quién implanta (o cree que implanta) sistemas de calidad porque crea o mejora un departamento de calidad, no sabe de qué va la película. Incluso me atrevería a decir que lo hace fruto de la burocracia (en grupos empresariales o alianzas) o de la moda.
No estoy de acuerdo en que sea exclusivamente el equipo de desarrollo, porque entiendo que hablamos de empresas y de negocio. El concepto de la calidad debería existir en todos los departamentos, porque si sólo te centras en la calidad del producto pero no hay una relación buena con clientes, con potenciales clientes, con proveedores, entre departamentos, etc., te comes tu software de altísima calidad y se lo enseñas a mamá en casa para que vea lo buenos que sois.
El software de calidad lo hace el equipo de desarrollo, pero el producto software de calidad lo hace la empresa.
Dani,
Realmente coincido con lo que dices. Yo lo que quería resaltar principalmente, aunque no se si me ha salido muy bien, es el caso en el que desarrollo pasa de calidad, donde ocurre que por mucho dto. de calidad que se ponga, si hay gente metiendo lo que no debe en el código… el software seguirá siendo malo.
A los chicos de calidad les pasa lo que a los de testing, pueden detectar problemas… pero debe ser desarrollo quien los soluciones y quien no los genere.
Gracias por el comentario!
Pues hay algo en tu razonamiento que no me cuadra y que está en la raíz de la manera de entender el problema: dices que en tu primera empresa hicieron mal un montón de cosas menos el sistema de calidad.
Bueno, esto es lo que se llama un «oxímoron», una contradicción en los términos. ¿Cómo es posible que se hicieran mal las cosas y bien el sistema de calidad? ¿Para qué servía vuestro sistema de calidad? ¿Acaso no sirve para detectar cuándo las cosas no se están haciendo bien? Y si vuestro sistema de calidad era buena y por tanto se detectaba cuándo las cosas se hacían mal, ¿por qué se seguían haciendo mal?
En cuanto a lo que dices de que la calidad no es una cosa exclusiva de desarrollo: no sé si estás diciendo que debe haber un departamento de calidad o algo así, que controle la calidad de todos los demás, por ejemplo, del de financiero, del de desarrollo, etc. Mi pregunta es: ¿Cómo es posible que un señor sea capaz de saber cómo se hacen las cosas bien en ámbitos tan diversos? Volviendo al tan usado ejemplo de las ingenierías tradicionales: el inspector de edificios que dice si un edificio está bien hecho o no, tendrá que ser arquitecto o perito o algo así, digo yo, ¿no?
Por otro lado dices que puedes tener un software bien construido y comértelo. Bueno, mi conclusión es que probablemente se está confundiendo la calidad de los que construyen un determinado software con la calidad de algún otro departamento que tiene que decir qué software hay que construir. Si el software está bien hecho pero no te sirve para tu negocio, no creo que eso sea problema de los ingenieros que lo han hecho sino de los que han dicho qué es lo que se necesitaba en ese ámbito particular.
En general creo que Javier hablaba de algo más concreto, básicamente que los empresas «de desarrollo» ven lo de la calidad como algo que no tiene que ver con el día a día de construir software sino que es una especie de subproducto colateral que se puede «externalizar» a otro departamento. Al final, que no se entiende que calidad es básicamente profesionalizar e industrializar el proceso de producción de software.
A ver si no me pierdo 😀
Mi primera empresa hizo muchas cosas mal porque no todo lo que acontece en la vida diaria de una empresa está sujeto a los criterios de calidad necesariamente. Si mi jefe tomó malas decisiones o nos trató de cierta manera más o menos correcta, eso no hace ningún oximoron con lo bien implantado que estuviera el sistema de calidad.
Un sistema de calidad, si las cosas no han cambiado demasiado desde entonces, es un conjunto de procedimientos, normas e indicadores que te permiten fijar objetivos de mejora en intervalos de tiempo (o algo así). Es decir, no se necesita a un experto en el campo en cuestión para llevar el día a día de la calidad. El experto en el área junto con el experto en calidad deciden los indicadores y las actuaciones. Una vez establecido el sistema, los trabajadores del área concreta se acogen a las normas y procedimientos y el responsable de calidad se encarga de monitorizar y recomendar mejoras según lo estipulado inicialmente.
El caso del software bien hecho «que te comes» es representativo del concepto de que la calidad debe existir en toda la empresa, como un framework uniforme, consensuado y burocráticamente eficiente (o casi). De nada sirve tener muy monitorizada la generación de software y el ratio de incidencias a cero si no hay otros indicadores equivalentes en ventas, marketing o hasta en la manera de subcontratar a los de la limpieza. A eso es a lo que me refiero.
Si un software magnífico no es lo que quiere el cliente, debe haber un indicador en el sistema de calidad implantado que refleje numéricamente como de bien se está atendiendo a esas necesidades y, en este caso, debería indicar un mal resultado. Cuando se analiza la actuación tras un proyecto fallido, por ejemplo, y se ve que los indicadores de desarrollo son buenos pero que los de trato con el cliente no, se puede tener claro el diagnóstico y se pueden rediseñar los procedimientos entre los expertos en ventas y los de calidad, para que la calidad global de todo el sistema (según los criterios internos de lo que es la calidad) tienda a ser mayor.
Y claro que Javier habla de algo más concreto, pero para eso están los comentarios: para divagar 😀
Aparte, discrepo muchísimo de la definición que propones sobre calidad. ¿Qué es profesionalizar? ¿Qué es industrializar? ¿Que es un proceso de producir software? Son el tipo de preguntas que surgen y que complican más el concepto. Calidad es lo que una empresa busca según sus criterios, experiencia y capacidad técnica. Saber si se consigue más calidad con el tiempo es un puro ejercicio de coherencia con lo establecido al implantarse.
Hala. Vaya chapa.
Por alguna razón no puedo contestar a tu respuesta, Dani, así que contesto a mi mensaje anterior.
Empiezo por el final: hay muchas definiciones de lo que es profesionalizar o industrializar el proceso de producción de software, básicamente se llama «Ingeniería del Software» y es toda una disciplina de la que nuestro querido Javier no sólo nos podría dar lecciones sino que, de hecho, las da todos los días en la Universidad.
En cuanto a los valores numéricos de los que hablas para saber que un software magnífico vale o no vale para el cliente, vuelvo a insistir que tiene que ver con la captura y gestión de requisitos que, de nuevo, es una parte de la ingeniería del software y hay técnicas a porrillo. De nuevo eso no se mide al final del proceso sino que se hace en todo momento. Una empresa que dedica a la producción de software ha de tener un método de captura y de gestión de los requisitos más allá de que el comercial los recoja en su bloc de notas y los «lance» a los desarrolladores sin hacer más seguimiento ni comprobación. Entre otras cosas, por ejemplo, los tests de aceptación deberían hacerse en base a esos requisitos y comprobarse con el cliente que esos tests (de una manera muy práctica y a ser posible visual) reflejan el funcionamiento del sistema que espera. La cuestión aquí es que la calidad aquí consiste en que las partes involucradas sepan hacer ese trabajo, que se compruebe que se hace y que se hace conforme a lo que la empresa ha establecido que es su método para ello.
Siguiendo con el mismo ejemplo de los requisitos y de la comprobación de que son lo que quiere el cliente y a modo de contestación de tu primer párrafo. Si el sistema de calidad, como tu dices es un conjunto de elementos burocráticos (eficientes) y la persona que las comprueba no es tiene conocimientos técnicos para diferenciar un test o ejecutarlo o entender un requisito y se limita a comprobar que determinados «papeles» se han escrito, pues se las van a colar todas, que es lo que suele pasar.
De nuevo, la calidad no es «un conjunto de procedimientos, normas e indicadores» que un lego puede comprobar. Esos «procedimientos» son procedimientos técnicos y se tienen que comprobar en todo momento, en el momento en que se están llevando a cabo y del primero al último tiene que poder levantar la bandera y decir «señores, que aquí se supone que tenemos que utilizar esto y no lo estamos haciendo»
Gracias por lo que me toca 🙂
Pingback: Bitacoras.com
Hola,
Dicho de otra manera, los de calidad estamos muchas veces para cubrir el expediente, hacer papelitos y que se superen las auditorías, para tener certificaciones que poner en las ofertas. Punto.
Luego si el software sale un churro, eso no va con nosotros, ni con nadie, mientras se venda.
Enhorabuena por los post
¡That’s it! Esto es precisamente lo que no pasaba en mi empresa, como comento más arriba, a pesar de que otras cosas se hicieran mal. Claro que se buscó obtener certificación pero luego, a diario, el sistema de calidad era útil para darnos cuenta de qué hacíamos mal y que eslabones de la cadena eran los débiles.
Es una lástima que una herramienta tan potente hoy en día (gracias a la automatización posible de la burocracia en mi opinión) se limite a lo que comentas que hacéis en el departamento. Si el software es un churro (me encanta medir las incidencias ocurridas desde el ultimo despliegue :D) debería reflejarse en esos papelitos del expediente.
De acuerdo completamente, Javier…como Ishikawa recomendaría…
(post repetido…olvidé identificarme)
De acuerdo completamente, Javier, y bueno de tu parte tratar de remediar la desconexión…Como en otros aspectos, si no existe compromiso de la dirección, si no se extienden y discuten las actividades, el resultado será parcial o nulo. Siempre vuelvo a los refundadores japoneses, como Ishikawa. Éstos no hubieran tomado seriamente el esfuerzo de sólo un departamento.
Buenas Tardes.
Alguien me podría indicar cuanto cuesta implementar la calidad del software aproximadamente dentro de una empresa. Estoy investigando pero no encuentro información concreta sobre esto.
Gracias.
Pues en mi empresa al departamento de Calidad lo llamábamos «asuntos internos». En sus charlas de presentación intentaban convencerte de que eran tus amigos, pero realmente nadie los percibía así, porque, en el fondo, funcionaban como evaluadores de tu trabajo capaces de hacerte «repetir» si suspendías sus exámenes, comprometiendo así tus tiempos y objetivos. Sin duda era un problema cultural/ organizativo, no personal de los individuos que formaban ese equipo.
jejejeje muy bueno lo de «asuntos internos»
Felicidades por tu blog Javier.
A mi me ha tocado estar en proyectos en donde además de que la calidad la rige el área de calidad, ésta considera la calidad del software como todo excepto el código fuente. Por ejemplo que los documentos de análisis, diseño, datos, etc cumplan con la plantilla, formatos, tipografías, etc.
Veo mucha razón en sus comentarios, pero qué hacer cuando el Gran Jefe Indio Toro Sentado (el jefe de los jefes de informática) le dice al resto de la tribu que «le interesa más entregar ‘algo’ al cliente para cumplir con la fecha de entrega y que le interesa poco la calidad del producto»? Ahí es cuando «los de calidad» nos preguntamos ¿qué pito tocamos en todo esto? O si en realidad la empresa tiene un compromiso serio hacia la calidad…En mis últimas experiencias laborales, en donde he estado del lado de Calidad, esa ha sido la tónica siempre…Saludos.
La gestión de la calidad permite en primer lugar que el producto que llegue al cliente sea precisamente de calidad aumentando la satisfacción, si se deja a los «perrogramadores» a su libre albedrío es un hecho que su «producto» no será de calidad porque estará hecho a la rápida.
La gestión de la calidad permite en primer lugar que el producto que llegue al cliente sea precisamente de calidad aumentando la satisfacción, si se deja a los «perrogramadores» a su libre albedrío es un hecho que su «producto» no será de calidad porque estará hecho a la rápida.