Así no se hacen las cosas por Ernesto Kiszkurno

En el libro Estrategia Competitiva Michael Porter, hablando de barreras de entrada y competencia, dice Falta de diferenciación o costos cambiantes . Cuando se percibe al producto o servicio como o casi sin diferencia, la elección por parte de los compradores está basada principalmente en el precio y el servicio (en el caso de la consultoría yo me permito reemplazar servicio por disponibilidad), y da como resultado una intensa competencia por precio y servicio. Estas formas de competencia son en especial volátiles, como ya se ha dicho. Por otra parte, la diferenciación del producto crea capas de aislamiento contra la guerra competitiva debido a que los compradores tienen preferencias y lealtad por proveedores particulares. Los costos cambiantes, descritos con anterioridad. tienen el mismo efecto. Veo claramente estos procesos en el mercado argentino de servicios de consultoría. La competencia está dada fuertemente por el precio y la disponibilidad de recursos. El juego es cubrir posic

En mi paso por la escuela fui sometido a distintos sistemas de medición. Desde las clásicas notas de 1 a 10, hasta los "alcanzó", "no alcanzó" y "superó". En todos los casos, más allá de los cambios de letras a números y de escalas de diez valores a escalas de menos valores, una cosa permanecía constante: Si todos estudiábamos existía la posibilidad de que todos saquemos 10 (diez)! La nota dependía del alumno exclusivamente y no de los demás . Luego cuando le llegó la hora al MBA, el sistema cambió. Aquí se utilizaba un método conocido como grading on a curve . En este sistema no solo es necesario saber y satisfacer un nivel mínimo de conocimiento, sino que la nota depende también de cómo le vaya al resto . Para ser concretos, hay una determinada cantidad de notas 10 que pueden asignarse y ya no existe la posibilidad de que todos la logremos. Todo este preámbulo viene a cuento de que, a mi entender, la dinámica del mundo de los negocios debe interpret

La aplicación de métodos ágiles, en particular Scrum , a la actividad de desarrollo de software es un tópico hot desde hace tiempo. También se ha escrito bastante sobre el uso de SCRUM en la actividad de testing. Sin embargo, poco se ha hablado del uso de Kanban como forma de organizar la actividad de los equipos de testing. En este post me propongo dar algunas razones y consejos relacionados con la aplicación de Kanban a la dinámica de pruebas de un área o un equipo de testing. Mis razones Respecto del proceso.. #1 Es posible organizar el trabajo en proceso (WIP) de testing en términos de la capacidad operativa del equipo . La limitación del WIP permite transformar el flujo de las pruebas en un sistema pull y no push (en función de lo que “podemos” - equipo disponible - y no de lo que “queremos” hacer). Esto evita mucho esfuerzo de planificación y priorización que la propia dinámica de la tarea de testing vuelve obsoleto. #2 El proceso canónico de testing funcional

En 10 cualidades de un buen consultor describí ciertas características que creo importantes para los profesionales que se desempeñan en esta noble tarea. Ahora quiero comentar algunas cuestiones de índole práctica a tener en cuenta. En particular quiero hablar de algo tan mundano como el ambiente de trabajo (ojo, no el clima de trabajo!). En la actualidad la herramienta de trabajo por excelencia del consultor es la notebook. Tenerla permite llevar el ambiente de trabajo a cualquier lugar donde vamos y minimizar el tiempo de "set up" cuando debemos trabajar con un cliente. El tiempo que se perdía poniendo en condiciones el ambiente en una PC de escritorio en cada cliente era considerable (créanme, lo sé por experiencia). Cuando nuestro ambiente de trabajo (nuestro mundo) es la notebook, hay dos cuestiones importantes a tener en cuenta: El peso. Dado que llevamos “el mundo a cuestas”, debemos evaluar el costo - beneficio de una notebook liviana y una buena mochila ve

Resulta raro que en esta época, donde la complejidad y el tamaño de los sistemas informáticos aumenta exponencialmente, todavía sea necesario explicar por qué hay que preocuparse por la calidad. En nuestros días no es imaginable desarrollar software sin pensar en controles de calidad independientes que disminuyan los riesgos de fallos en los ecosistemas informáticos de las empresas. Es por eso que si tenemos un área de desarrollo de software en nuestra empresa debemos tener un área de QA. A continuación 4 razones por las que esto resulta fundamental: Para conocer la inversión que hacemos en Calidad . Al tener recursos asignados es posible determinar claramente cuánto se invierte en la tarea. En organizaciones donde no está claro quien prueba, en el mejor de los casos (suponiendo que realmente se está testeando) el esfuerzo estará mezclado con otros y será imposible de separar. Para tener una medida independiente de la calidad de nuestros desarrollos . Al ser un equipo con

No nos engañemos. Muchas veces en el día repetimos la frase "esto me interesa" o "lo tengo como objetivo para este año/mes/semana" pero a la hora de dedicarle tiempo, no lo hacemos. Obviamente la excusa está y es buena (justificada). Hay razones de peso por las cuales no logramos hacer eso que nos interesa. No somos vagos (o por lo menos somos efectivos convenciéndonos de que no lo somos :-)). Pero la verdad es que no nos interesa. Tal vez debería interesarnos porque alguien en nuestra situación (o de nuestra posición o de nuestra reputación, etc.) debería hacer esto o aquello, por tal o cual motivo. Pero a la hora de la verdad el resultado es nada. Hay una diferencia entre lo que nos interesa y lo que debería interesarnos. Y es que cuando algo nos interesa, hacemos. Poner en la agenda significa planificar acciones concretas, en momentos concretos y luego cumplir con el hacer. No necesariamente es dejar todo y sólo pensar en eso. Puede ser un hacer lento.