Así no se hacen las cosas por Ernesto Kiszkurno

El otro día me dijeron "voy a implementar calidad en mi empresa". “Bárbaro” dije yo y luego pregunté “pero qué significa eso para vos?”. “Certificar ISO 9001” me contestaron. A partir de ese intercambio casual breve me quede pensando y concluí que sí, ciertamente ese es un enfoque posible. ISO 9001 permite organizar y estructurar toda una seria de iniciativas relacionadas con calidad y al final obtener un reconocimiento del logro visible desde el mercado. Igualmente, siguiendo esa línea de pensamiento se me ocurre preguntar con que alcance (algunos procesos o toda la empresa) y para qué (sólo para mejorar, para ganar nuevos mercados, por posicionamiento, para disminuir costos o un poco de todo). Pero implementar calidad puede (o debería?) significar otras cosas también. En realidad a mi me gusta más pensar en gestionar la calidad . Y eso, según la trilogía de Juran significa: Planificar el nivel de calidad al que queremos llegar, controlar la calidad producida y mejorar

El otro día encontré en un libro de ejercicios para aprender inglés que se trataba el tópico de cómo escribir procedimientos claros [en inglés] . En particular hubo un ejercicio que me gustó pues pedía diferenciar los “dos” y los “don’ts” (lo que hay que hacer y lo que no hay que hacer) en esta lista que les transcribo a continuación: Use long sentences Prefer active verbs Be direct – use imperatives Use long words Use abbreviations or acronyms Be consistent with terminology Remember the reader – do not assume they know certain information Put steps in the right sequence Use headings and split information into chunks Use 1, 2, 3, and not one, two, three or first, second, third Pensemos lo que opinamos de estas sugerencias en el contexto de escribir casos de prueba y/o incidentes de prueba claros y simples: ¿Cuales serían para ustedes sugerencias para respetar y cuales no? Seguimos pensando..

Siguiendo con mi movida agenda del segundo trimestre del año, la semana pasada estuve hablando sobre calidad de software en Santa Cruz de la Sierra, Bolivia. Saludos a los participantes y gracias por el interés demostrado. Seguimos pensando.. PD: Aprovecho para agradecer al dios de las cenizas que me permitió ir y venir casi sin contratiempos.

Este post fue escrito para el blog Mejores Proyectos . Imagen de Flickr por DumbleDad . A lo largo de nuestra carrera profesional todos, tarde o temprano, formaremos parte de un proyecto que falla. En algunos casos será solo un pequeño sabor amargo al final del mismo, en otros será una sensación de derrota total. Pienso que es sólo cuestión de tiempo antes de que nos toque y estará en nosotros la forma en la que nos levantamos de esa caída y lo que logramos aprender de ella. Dado que es inevitable que ocurra, la pregunta es entonces ¿qué hacemos para mitigar el impacto de una caída así?  Obviamente, la respuesta dependerá enormemente del contexto de cada proyecto pero hay algo que creo que es universal y que sirve para casi cualquier proyecto donde debamos participar: una vez visualizado el fracaso hay que cortar el proyecto lo antes posible . Hacer esto ahorrará costos tanto para nosotros como personas, para el equipo de trabajo y también para la organización. A partir de esta ide

Hace tiempo en esta ECI escuché decir que mucha gente confunde QA con testing . Coincido. Es común escuchar hablar a las personas de QA cuando en realidad están hablando de Testing de Software solamente (Quality Control). De hecho hay áreas llamadas “QA” que en realidad lo único que hacen es 0testing. Pero la confusión no termina allí, enumero otras que también he visto que se repiten: Testing con Testing Funcional Testing Funcional con Testing Funcional Manual En algunos casos es una forma simplificada de hablar. En otros, refleja una mirada estrecha de lo que en realidad podemos hacer para mejorar la calidad del software: Testear manualmente y automáticamente la funcionalidad. Testear aspectos no funcionales además de los funcionales. Hacer otras actividades para controlar la calidad del producto además de testing. Por ejemplo revisiones por pares. Trabajar sobre la calidad del proceso (QA) además de hacer control de producto. Más allá de la variedad de actividades que hagam

Un colega me pasó el link de este video acerca del costo de la calidad o, mejor dicho, de la no calidad. Estos videos definitivamente nos sirven para seguir pensando .

En el primer capítulo del excelente libro El ejecutivo eficaz , Peter Drucker habla de la necesidad de efectividad en los negocios y en los hombres de negocio. También dice que tanto el conocimiento como la creatividad son características encontrables en los trabajadores del conocimiento (él los llama “ejecutivos”), pero no así la efectividad: "La inteligencia, la imaginación y el saber son esenciales, pero únicamente la efectividad los convierte en resultados." Esta es una época totalmente dirigida por los resultados. Las buenas ideas no traducidas a resultados no sirven. La inteligencia sin resultados no sirve. Aquellos que logren aprender cómo ser más efectivos tendrán un plus grande en la carrera por diferenciarse. Drucker dice en el libro que la efectividad puede aprenderse, yo digo que hay que pensar la efectividad como un hábito a cultivar. Seguimos pensando.. Nota 1: El libro es una excelente fuente de tips para lograr esto último. Nota 2: BJ Fogg, a quien esc

(y siguen los anuncios) Ayer estuve hablando sobre estrategias de armado de áreas de control de calidad en áreas de sistemas en un evento organizado por Pragma en Montevideo, Uruguay. Seguimos pensando..

El lunes pasado tuve la oportunidad de dar una charla sobre Control de Calidad en el posgrado de Tecnología de la Información de la UADE. Fue interesante compartir con los alumnos de allí mis impresiones sobre el nivel de madurez de las prácticas de testing en el mercado argentino. Seguimos pensando..

Cuando uno da una presentación en público debe estar dispuesto a soportar, como mínimo, al público. :-) Sí, un ítem más para la lista de cosas que parecen obvias pero que en realidad no lo son tanto. No se puede pretender que toda la gente asista muda y extasiada a lo que uno dice. En cualquier presentación habrá gente que nos escuchará con interés y otra que no. Y lejos de preocuparnos por el primer grupo, debemos ser cautelosos con el segundo. A continuación menciono 4 arquetipos sobre los que conviene estar prevenido: El preguntón . Como su nombre lo indica esta persona se caracteriza por hacer preguntas fuera de tiempo (a veces sin sentido) durante gran parte de la presentación. El problema con él es que corta el ritmo y a veces exaspera tanto al auditorio como al presentador. Mi consejo aquí es marcar un límite a las preguntas ofreciendo un espacio al final de la charla para conversar. El “figureti” . Esta persona también hace preguntas pero no con el objeti