Archivo de la categoría: Uncategorized

Serias un piloto de pruebas?

 testpilot

La gestión de proyectos en software es un desafío. Se trata de una disciplina relativamente nueva, con apenas poco mas de un siglo de existencia (y si hablamos de software “en serio”, hablamos de 50 o 60 años a lo mucho.) La verdad es que es corta vida, para una industria que es la que mas crece, la que menos base de profesionales tiene y la que mas necesita el mundo para progresar en el siglo XXI.

Desde sus comienzos, la ingeniería de software, ha intentado emular la construcción otras disciplinas: de la ingenieria civil, de la investigación y desarrollo de productos (prototipado), de la investigación científica (modelo “espiralado” incremental), etc.   Al final, llegamos al siglo XXI, con  normas como las del PMI, que intentan reglamentar y certificar la forma en que se gestionan proyectos de software. Siempre con niveles extremos de documentación y controles, y tan seguido con proyectos fallando. Es que no es tanto la metodología que utilicemos o la norma de calidad que certifiquemos. Gran parte de la magia de hacer buen software, son la calidad con la que se ejecutan las pruebas. Parece una pavada, pero pocos son los creadores de software que prueban correctamente el software que se codifica. No se invierte dinero en serio en probar lo que se escribió, y no se hace esfuerzos significativos en tener Testers profesionales.

De hecho, un tester, cobra mucho menos que un desarrollador. Como si fuera que unas buenas pruebas no deberían estar certificadas por las manos de un profesional competente. Y es que, para el colmo, cuando las empresas invierten en testing y aseguramiento de calidad, hacen lo siguiente:

  • Ponen procesos y burocracia que no atiende a hacer que el desarrollo fluya.
  • Los testers que incluyen en el proyecto son en realidad power users que solo testean la funcionalidad.
  • No creo que haya Testers que hayan sido hackers que continúen siendo testers; y ser hacker, es la base del buen testing.

No me mal interpreten.

No se trata de tener un equipo súper caro de hackers seniors con PhD’s en ciencias de la computación. Nah. Se trata de tener equipos conscientes de la parte funcional, de negocio y tecnológica. Se trata de tener por lo menos esos tres roles. Y luego, por supuesto, se trata de dedicarle tiempo en serio a testear; caja negra y caja blanca!

En la empresa que trabajo ahora, estoy dirigiendo un proyecto en el cual pusimos todo lo que había que poner en el testing: involucramos usuarios, programadores senior, hackers, analistas funcionales  y power users. Y luego, pusimos una segunda ronda de pruebas (eh! Como? No habíamos probado ya? SI, segunda iteración); ademas hubo ejecución de pruebas de usuario, con usuarios diferentes pero con los mismos analistas y programadores de siempre. Cada iteración, supuso nuevos errores, nuevos fix, y nuevas lecciones aprendidas. Hace un mes, pusimos en producción el primer release para mas de 300 usuarios en mas de 30 sites en Argentina.

En lo que va de ese tiempo, tuvimos menos de 30 defectos reportados en producción…

Pero para! ¿acaso después de todo lo que hicieron siguen teniendo errores? Imposible. Nunca hay “cero defectos” en producción; si ocurre, es que los usuarios no están utilizando el sistema.

Fue un éxito que podamos hacerlo de esta manera; probar importa, y mucho.   Esta es una lección que los informáticos aprendemos muchas veces de la forma mas amarga, y que a veces, tampoco aprendemos: el software nace con errores y defectos, vulnerabilidades y problemas. No probar o probar poco antes de salir en producción y poner al usuario mano a mano con un trabajo que no paso por los procesos de control de calidad correspondientes, es como subir a 200 personas a un Boeing al que nunca se subio antes un piloto de pruebas; es signo de baja calidad en lo que hacemos.

Quizás, esa, debería ser la mayor lección aprendida en todos estos años que llevo de carrera: PROBAR CUENTA, Y MUCHO.

My two cents.

A veces mas es menos.

chess

Este fin de semana lleve a mi hija al club Argentino de Ajedrez. Resulta ser que en este club juega Alan Pichot, el actual campeón mundial en la categoría Sub 16, y un crack. La idea era introducirla al deporte, nada muy complejo. Como siempre, la incentivamos a probar cosas nuevas. La regla es: “la primera vez, es obligatorio, después decidís vos si querés volver”.

Mas allá de que le gusto la experiencia y quiere regresar el próximo sábado, me llamo la atención la clase: el profesor en un punto dado les daba “acertijos” de ajedrez; es decir, te arman una situación y vos tenês que pensar como resolverla.

Los chicos se enfrentaron a un puzzle en el que tenían mas piezas que su adversario y debían dar mate al rey; o sea, ganar.

El ajedrez es un juego complejo, no voy a entrar en tecnicismos; solo voy a decir que es fácil ir ganando bien y que por cuestiones de reglamento y despiste termines empatando un partido que estaba servido.

La cuestión que los chicos jugaron y terminaron en empate. Tenían todo para ganar, pero el problema fue simple: en vez de concentrarse en liquidar al rey enemigo, se pusieron a conseguir mas piezas aun, como para “asegurar” una victoria “total”. Un empate, cuando tenés todo para ganar, tiene un fuerte y amargo sabor a derrota.

Como evitar esta situación en los negocios?

Hace años escribí una tesis sobre unos emprendedores que lo tenían todo: equipo, presupuesto, mentores, sinergías, producto, etc. En seis años no calzaron una venta. Enfocarse en lo importante, no perder de vista el objetivo y optimizar los recursos es siempre mas valioso que contar con Venture Capital, dinero y materia gris en lo que menos rédito nos da.

La victoria llega a quienes saben que es lo importante y que es lo accesorio.

My two cents

Etiquetado , ,

Cerrado por vacaciones

“Cerrado por vacaciones….del 31 de diciembre al 15 de enero”

Esto rezaba un cartel a pocas cuadras de casa, en una de esas tantas parrillas, con poca o nula ventaja competitiva en un “barrio de parrillas y parrilleros” como es Villa Urquiza.

Y luego, vino la reflexión…

Se van todos? Los meseros, los chicos del delivery, los muchachos que limpian el piso, el contador, el cocinero, etc…todos, todos de vacaciones y al mismo tiempo? que coordinación!…o solo se va el dueño

Este resulta ser un problema recurrente en las empresas de todos los tamaños: el líder que lo sabe todo, el único capaz de “entender” el negocio, el dueño de la pelota y de la cancha; tanto, que cuando falta, mejor “cerrar que perderlo todo”.

Y si, digo “perderlo todo”, es porque no se me ocurre ningún motivo mas extremo, que ese miedo visceral a la muerte que tanto nos paraliza. Que otra cosa podría impedirle a un gerente general dejar a un lugarteniente sino es: la falta de controles sobre la operación del negocio, el no poseer procesos o la acumulación de todo el know-how de la empresa en una sola persona? 

Ocurre seguido, que este gerente general, es además, el padre del “niño prodigio” que es su negocio; ergo, no piensan en dejarlo solo y casi nunca se toman vacaciones.

La pregunta es:

Es buena la centralización de poder?

Bueno, ha habido muchos autores que han hablado sobre el tema, entre ellos Charles Handy, quien ya hablaba  de “la cultura Zeus” en su libro “Los dioses del management”:

“Zeus, patriarca y rey de todos los dioses griegos, gobernaba desde el Monte Olimpo enviando rayos a quienes lo enojaban y lluvias de oro a quienes quería seducir. Era temido, respetado, y en ocasiones amado. Era el soberano patriarcal, impulsivo, poderoso, carismático y benevolente, todo al mismo tiempo.“ 

Zeus representa la cultura del liderazgo carismático que busca el poder por encima de la gente y los acontecimientos. No tanto por egoísmo, como por empowerment de los empleados. Muy bueno para situaciones de crisis, muy malo a la hora de crecer.  Muy bueno a la hora de iniciar una nueva empresa, muy malo a la hora de establecer procesos.

En definitiva, la cultura Zeus, no es solo culpa del “jefe”. También se la denomina “cultura de club”, porque es precisamente eso lo que parece la empresa en cierto punto: un club de amigos con un solo tomador de decisiones. Cuando es pequeña se trata de una empresa: dinámica y efectiva. Es una cuestión cultural

Esto que funciona tan bien al principio, pone seriamente palos en la rueda a la hora de crecer y dar el próximo salto. De hecho, este tipo de centralización en la toma de decisiones, es precisamente lo que hace que la empresa quede estancada en algún punto: la continua start-up que se sostiene en el tiempo, el empresario-empleado die hard que nunca deja de trabajar, y el socio irremplazable porque es el único que “sabe como funciona el servidor VAX que instalamos en el 86′”.

Es necesario revalorizar y entender que los recursos humanos no existen porque si como disciplina. A toda empresa, tarde o temprano, le llega el turno de cambiar su cultura. Cuando eso llega, es mejor estar preparados y contratar un buen gerente de HR y un CEO abierto al cambio; es mas, quizás hasta sea tiempo de que el co-fundador ese que tiene todo el know-how, pase a formar parte del directorio y deje en su lugar a un gerente “de profesión”; los fundadores deberán convertirse en agentes de cambio o abandonarse al estancamiento.

Todas decisiones, difíciles de tomar. Como las vacaciones, para un emprendedor crónico… 

My two cents.

Bibliografía

Gods of Management,  C. Handy (1996), Oxford University Press, 272p, Ingles http://www.amazon.com/Gods-Management-Changing-Work-Organizations/dp/0195096177

 

 

 

 

 

Etiquetado , ,

Resistencia al cambio

El desarrollo de software hoy ha cambiado mucho.

Hace algunos años, desarrollar suponía un esfuerzo continuo de prueba y error, para el cual se debía contar con un IDE poderoso que nos permitiera “debuggear” la aplicación mientras la íbamos escribiendo. Esto, si bien útil, terminaba por ser una tediosa tarea; aveces terminabas de escribir un método o procedimiento e inmediatamente buscabas que la aplicación compile, la ejecutabas, ponías “breakpoints” y “watchlists” de variables y te fijabas si la estructura de datos que habias armado se estaba llenando bien, si el reporte traia los datos correctos, o si el algoritmo funcionaba como debia.

Y gracias a dios; porque antes de eso, los programadores mas viejos te contaban “que en sus tiempos” los buenos programadores eran los que hacian las mejores “pruebas de escritorio”…y claro, compilar nomas, en la época de Fortran, Cobol y los disquettes de 5 1/4, y capacidad de 360kb…era un parto.

(Tiempos que se fueron y no vamos a extrañar…)

Pero hoy el desarrollo es inclusive mas distinto: ya ni siquiera es necesario ejecutar todo el programa, las pruebas unitarias hacen que el desarrollo sea un deleite: tenes una clase recién hecha o no sabes si el algoritmo lo codeaste bien? No hace falta compilar toda la app, correrla, hacer el camino hasta donde sea que se ejecute el código y ver por que “no anda como esperabas”, no…

Ahora, creas un nuevo caso de test, ejecutas el plugin de JUnit y san se acabo!

Todo ese lío de compilarlo todo y correr todos los pasos, quedaron restringidos a la integración o a la prueba del frontend…una delicia y un gran avance, porque ademas de desarrollar mas rapido te quedan luego los casos de test ya armados! con lo cual la aplicación (e inclusive el proyecto) en si termina siendo mas robusto. ( y ni te cuento si contas con Selenium o similares…)

Una belleza…

Sin embargo, aun hoy, ya a las puertas del 2014 y bien metidos en la panza del siglo XXI…sigo viendo desarrolladores en Argentina que continúan con practicas de los 90′. O peor, que asocian este tipo de desarrollo con sofisticadas practicas de agilismo a las cuales ellos no serian adeptos, como TDD o XP. (Y luego no te ponen un puto comentario en el código porque ellos son “agiles”)

Mmmmm…no.

La forma de trabajar evoluciono, es mas fácil, es mejor, pero nos resistimos al cambio. Como podes decirte informático y tecnólogo si lo nuevo te da miedo?

My two cents.

Ezequiel

Etiquetado , , ,