domingo, 26 de mayo de 2013

Deloitte University

Pues ya hemos vuelto de Texas, y en realidad a pesar de mi entrada anterior, la Deloitte University estaba más propiamente en WestLake, no en Dallas. De hecho, estábamos tan al norte, que el famoso desastre de los tornados en Oklahoma nos afectó y bastante. Pero bueno, eso ya es otra anécdota.

Sobre el evento, he de comentar varias cosas:
  • Formación. El enorme esfuerzo que se hace en las compañías americanas en formación. En este lugar privilegiado no sólo había directores, gerentes y responsables en general (por algo le llaman el Leadership Learning Center), sino que cantidades ingentes de nuevos y jóvenes empleados (auténticos yogurines de apenas 20 o 23 años), llegaban a cientos a este centro formativo.
  • Lujo, belleza y tecnología. Los mejores materiales, un cuidado diseño que hace pensar que estamos en un hotel de cinco estrellas en lugar de un centro formativo, eso sin olvidar que hay un cyber-center donde cualquier cosa que necesitemos, está a nuestra disposición para comprar: iPhones, iPads, portátiles, otros móviles, adaptadores, cables, etc, etc. Wi-fi gratis en todo el complejo, incluyendo la conexión inmediata de los empleados al usar sus portátiles o móviles de empresa.
  • Gourmet ¿Alguien tiene hambre? Es difícil salir de este centro formativo sin unos kilos de más. Salas repletas de comida de todo tipo se reparte por las 5 plantas del complejo de habitaciones. Pensado para los que no tienen tiempo para bajar, o simplemente quieren picar algo sin alejarse de la habitación. Después, los restaurantes con buffet o los múltiples espacios para picar habilitados junto a las salas de formación, hacen que el día se pase sin sentir (salvo en el estómago!).
  • En forma. Para compensar lo anterior, existe un gimnasio gigantesco: DTFit. En este lugar podemos encontrar desde decenas y decenas de máquinas de todo tipo, gran cantidad de actividades diarias programadas para que nadie tenga que aburrirse por su cuenta, hasta un exterior de varias hectáreas de terreno verde con árboles y muy cuidado para facilitar el running. Doy fe: no es extraño ver a la gente corriendo por las distintas pistas, especialmente a primera hora de la mañana o por la tarde.
  • Relax. Un exterior cuidado, con árboles, pistas verdes, zonas ajardinadas con iluminación nocturna, un lago con aves, tortugas, peces...
  • Sostenido. Un equipo de alrededor de 200 personas cuidan y mantienen el complejo: seguridad, camareros, cocineros, jardineros, mantenimiento, dependientes, limpieza, etc.
Así que tras este ajetreo, me pongo a pensar en lo importante que es la formación, y lo importante que es cuidar a los empleados. La mentalidad de que para rendir como los mejores, hay que invertir en nuestros empleados dándoles lo mejor, puede ser chocante. Pero no debería ser así, ¿verdad?

viernes, 17 de mayo de 2013

Nos vemos en Dallas

Bueno, aprovecho un breve hueco para comentar que estaré en Dallas (Texas, USA) la semana del 20 de Mayo, más concreto en la Deloitte University, recibiendo formación.

Y bueno, a ver si da algo de tiempo para ver alguna cosa, aunque viendo la programación del curso, me temo que veré muy pero que muy poco de Dallas.

Me parece una oportunidad increíble para aprovecharla en muchos sentidos:
  • Un viaje al extranjero. Oportunidad de practicar (aún más) el idioma cara a cara.
  • Un curso de formación. Aclarar dudas es fundamental para hacer las cosas bien.
  • Una formación a la americana. La forma de llevar los cursos en otros países es mucho más participativa, y a pesar de que inicialmente puedas pensar que distraen, la realidad es que es al revés: te involucras mucho más y se asientan los conocimientos mucho mejor.
  • Participar activamente en las políticas de calidad de una empresa, ser partícipe de muchas cosas que nos involucran después en el día a día, como son las metodologías de trabajo, plantillas. entregables...
Nos vemos en Dallas.
Un cordial saludo

sábado, 11 de mayo de 2013

El tamaño importa

He leído recientemente en algún blog, sobre la forma adecuada de medir el tamaño del software, y que ésta, debe ser contraria a la que se usa en construcción de casas.

Vaya con la maldita manía de que como se supone que el software y las casas son distintos (según algunos, radicalmente opuestos), pues las formas de trabajar, medir, etc, deben serlo también. Esto ya es incluso un caldo de cultivo para los defensores del "agilismo porque sí", ya que como una casa se hace por fases, y esto se asimila a un método de desarrollo en cascada, está claro que eso es algo obsoleto y por tanto, la forma de trabajar en el software ha de ser distinta. Interesante, pero absurda conclusión.

Para medir el tamaño del software, podremos usar Puntos Función (PF), o cualquier otra medida. En la construcción de casas, esa medida no es válida, claro está.

Tambien se suele afirmar que en la construcción de software, la unidad de medida habitual sigue siendo en esfuerzo: se paga por la cantidad de esfuerzo empleado en lugar de por lo efectivamente producido (valor). Aquí sí que tienen ventaja las metodologías ágiles, ya que se centran en el valor incorporado en cada iteración.

Creo que tenemos un problema. Somos nosotros, los desarrolladores, los que pretendemos que nos paguen por esfuerzo. No es que sea la medida habitual: es lo que habitualmente pretendemos. Los clientes no quieren saber si nos costó 1000 ó 1050 horas hacer su programa de facturación, o su sistema de control de fábrica. El cliente quiere saber lo que realmente necesita para su negocio que es:
  • Fecha: ¿Cuándo estará el software disponible? ¿Cuándo podrá integrarlo con otros productos? ¿Cuándo tendrá que tener lista la formación para su personal? ¿Cuándo tienen que estar disponibles los responsables de sistemas para su puesta en marcha? ¿Llegará el producto a tiempo para hacer lo que tiene comprometido por contrato en una fecha concreta?
  • Coste: ¿Cuánto dinero va a costar? ¿Se puede pagar a plazos? Los clientes no tienen un baúl como en los dibujos animados lleno de dinero. El dinero en las empresas, no suele estar disponible en todo momento. Depende de la facturación, de si toca o no pagar impuestos, etc. Muchas empresas necesitan pedir un préstamo para acometer pagos, incluso los previstos.
  • Calidad: ¿se cumplirán las necesidades y requisitos establecidos? ¿estarán todas las normas obligatorias recogidas? ¿Hay criterios de calidad adicionales que aporten valor (usabilidad, etc)?
Si os fijáis, estos factores son significativos. El negocio del cliente es directamente dependiente de estos factores. Un pequeño cambio en cualquiera de los tres, y podemos hacer que la empresa del cliente se arruine, y sus trabajadores acaben en la calle. Y esto sirve para todo, no solo para el software.

El coste, por otro lado, estará marcado por el mercado. Habrá productos, que si no sabemos desarrollarlos por un coste inferior al precio de mercado, tendremos un problema. Aquí está la clave: ser competitivos.

¿Entonces porqué esa manía de medir el software en esfuerzo? Pues porque es lo único que nos importa, en un entorno todavía inmaduro que parece no querer ver más allá y no involucrarse en satisfacer al cliente.

Se está huyendo de dos premisas, muy integradas culturalmente en otros sectores, pero que parece que en el software nos negamos a asimilar:
  • Compromiso. Los acuerdos se hacen mediante contratos. Y los contratos están para cumplirlos.
  • Disciplina/Ingeniería: debemos tener las herramientas y procesos adecuados para estimar y reestimar progresivamente si vamos a terminar en fecha y con el coste pactado. Y por supuesto, con la calidad pactada como mínimo.
Se oye hablar de que las casas se venden por metro cuadrado, y que esto no es válido para el software, ya que las casas siguen un método industrial (supuestamente radicalmente diferente del desarrollo software). De nuevo, otra falacia interesada.

Las casas, si se fabrican iguales, costarán un precio similar. El problema no es el método, sino que los materiales, mano de obra, etc., están muy estandarizados en la construcción de casas. Pero siempre existirán casas hechas a medida, con piezas no estándar, y que costarán un ojo de la cara (es decir, su precio por metro cuadrado, se dispara). De todas formas, si nos fijamos en las casas estándar normales...¿habéis comprado alguna casa? ¿Os habéis fijado que en mismo edificio de casas, donde dos de ellas supuestamente deberían ser iguales...no han salido igual? ¿Verdad que todas las casas no salen con los mismos fallos? ¿Verdad que si medís los metros cuadrados de todas las viviendas...ninguna cumple exactamente con lo que dicen los planos?

Por tanto, llegamos a la conclusión de que las casas no son iguales, no se construyen iguales (sencillamente porque es imposible), y se requiere una ingeniería detrás para poder conocer cuándo podrán estar terminadas, y cuánto dinero van a costar. Eso se hace con planificación y gestión. ¿Por qué no hacemos lo mismo con el software? ¿Porqué seguimos renegando de los métodos de ingeniería, pero no estamos dispuestos a que dejen de llamarnos ingenieros?