Más de 24 = dinosaurio. Net Generation

30 septiembre 2008

Tengo 39 años y me gano la vida con las tecnologías de la información, incluso dentro del mercado estoy más o menos al día. Esto debería servirme para poder lanzar algún tipo de predicción sobre como será internet en el futuro, ¿verdad? No

Veamos este gráfico. los datos corresponden a  España (INE 2007). Muestran los Servicios de Internet usados por motivos particulares en los últimos tres meses.

Fijaos, donde están las mayores diferencias. Son en el uso de la mensajería instantanea y en las descargas.

La mensajería instantanea me interesa especialmente. Quiero resaltar dos cuestiones:

La edad de los directivos es más habitual que esté por encima de los 40 que por debajo de los 30. En el segmento de 35 a 44 solo un 35% usa mensajería instantanea, el porcentaje disminuye al 29% en el segmento que va de 45 a 64 años

Tenemos un segmento de la población (de 16 a 24 años) que utiliza de forma masiva el chat y el SMS, por encima de otros medios de comunicación. Este segmento acaba de entrar en el mercado laboral, o pronto lo hará, lo que significa que comenzará a tener ingresos y a ser un target más que interesante para las empresas.

Y nuestras empresas no están preparadas para comunicarse con ellos…


Es la economía, estúpido.

25 septiembre 2008

En cierta ocasión, Alan Greenspan le dijo al CIO de Intel:

No dejes que la gente de tecnologías de la información te engañe con sus historias de hacer a la gente más productiva. Al final del día si tus ingresos no suben y/o tus costes no bajan, nadie ha sido más productivo. (Don’t let the IT folks fool you about making people more productive! At the end of the day, if your revenue doesn’t go up and/or your costs down, no one has been more productive).

Lo simple suele ser una buena solución. Hablar de dirección estratégica, mision, vision, valores, alineación con el negocio, orientación al cliente, mejoras de procesos, excelencia, empowerment, disrupción…, y demás zarandajas está muy bien, pero…, antes de todo esto, es necesaria una línea a seguir que sea simple y clara , y que todo el mundo entienda.

Greenspan lo  expresó perfectamente, y Bill Clinton también lo hizo de un modo aún más simple, en su campaña de 1992: Es la economía, estúpido.

Porque ese, es el primer objetivo de cualquier empresa, el beneficio económico, ¿o no es así?

Sí, sí que lo es incluso, para nosotros, la gente de tecnologías de la información.

 


Algunas referencias sobre metodologías de desarrollo de software

23 septiembre 2008

 

La mayor parte de las visitas (son muy pocas todavía) que entran al blog buscan información sobre metodologías de desarrollo de software (podeis ver mi opinión sobre el tema en este post). Hoy contaré cuales han sido algunas de mis fuentes. Os facilito unos cuantos enlaces y lecturas que a mí me han resultado útiles:

RUP (Rational Unified Process) y UML (Unified Model Language)

Mis aprendizajes sobre RUP y UML se basaron en dos libros, estos son los títulos:

  •  Unified Modeling Language User Guide
  • The Unified Software Development Process

 Los dos son de los mismos autores, los padres de UML y RUP: Ivar Jacobson, Grady Booch y James Rumbaugh. Y los dos son de 1999, ya ha llovido desde entonces, RUP ha evolucionado y creo que también hay libros más adecuados, pero las bases de UML y RUP pueden verse en estos dos títulos. En la web, yo buscaría en los white papers y red books de IBM, podeis usar este enlace:  http://www.google.es/search?hl=es&q=rup+redbook+site%3Aibm.com&btnG=Buscar&meta=MSF (Microsoft Solution Framework)

Sobre MSF en el Download Center de la web de Microsoft, podéis encontrar todo sobre MSF: http://www.microsoft.com/downloads/results.aspx?pocId=&freetext=MSF&DisplayLang=en

Las dos últimas versiones son “MSF for Agile Software Development” y “MSF for CMMI”, cada una con orientaciones diferentes, pero ni mucho menos puede decirse que la versión anterior a estas dos (MSF v3), esté ya caduca, es muy recomendable también su lectura y, por qué no, su aplicación, quizás MSF v3 se adapte mejor a tu equipo…

SCRUM

Para Scrum, esta es la página que visitaría, www.controlchaos.com, con cuidado de no tomarlo de un modo ortdoxo..

LEAN

Para aprender Lean, os puedo recomendar que leais “Lean Thinking” de James P. Womack y Daniel T. Jones. En internet, podeis visitar www.lean.org, y la versión de Lean aplicada al desarrollo de software que propone Poppendieck http://www.poppendieck.com/

Métrica

Los manuales de métrica pueden descargarse de la web del Consejo Superior de Informática, un organismo dependiente de la administración española, esta es la página: www.csi.map.es/csi/metrica3/index.html

Six Sigma

No os puedo dar una buena referencia sobre Six Sigma, por suerte para mi pude contar con los manuales de una empresa que aplica Six Sigma, y nunca me preocupé demasiado buscando por internet.

 

Acabo con algunas consideraciones que deben estar por encima de la metodología que utilicemos. Si no sois nuevos desarrollando software, posiblemente no sean más que obviedades, pero si no llevais mucho tiempo, quizás os convenga leerlas.

  • Las metodologías no solucionan problemas, los problemas los solucionamos las personas. Está bien contar con un método que normalice el trabajo y sirva como guía, pero no hay una relación directa entre utilizar determinada metodología y tener éxito en un proyecto.
  • Una comunicación correcta es fundamental. Durante el proceso de desarrollo de software generaremos mucha documentación dirigida a distintas personas con distintos roles. Es vital utilizar un lenguaje y un nivel de detalle adecuado para cada persona. Antes de empezar a elaborar cualquier documento, debemos pensar para quien estamos escribiendo.
  • La utilización de una metodología es un medio, no un objetivo. El objetivo será mejorar determinado proceso de negocio, y nuestra solución debe cumplir este requisito, hacerlo bajo cierto método es un solo un aspecto secundario.
  • Trabajar con una aplicación informática que nos permita gestionar  todo el proceso desarrollo de software, es fundamental para tener control sobre lo que estamos haciendo. Los informáticos somos un ejemplo constante de que “en casa del herrero, cuchillo de palo”. Nos vamos apañando para las tareas de gestión del área con Excel y Project, sin embargo nos escandalizamos cuando uno de nuestros clientes ( no técnico) hace lo mismo con sus procesos de negocio.
  • Contar conocimientos de varias metodologías es positivo. Como en todos los órdenes de la vida, cuanto más conocimientos tengamos, más recursos tendremos y más aportaciones podremos hacer. Posturas anti (ej.: AntiMicrosoft, AntiLinux,…) no aportan nada. No olvidemos que hablamos de tecnologías de la información y no de política o religión.

Acabo con una pregunta, ¿cómo lo veis vosotros? ¿Por donde irá el mercado en el futuro?


Alineación con el negocio. Asumiendo el verdadero rol de las TI.

17 septiembre 2008

Hoy toca hablar de la alineación con el negocio, que quizás no sea lo que esté más de moda en las últimas “temporadas”, pero es un clásico que siempre se puede sacar.

Empezaré echando piedras sobre mi tejado, los informáticos no somos tan importantes como nos creemos. Y esto es una de las cosas que hay que tener muy claro, antes de ponerse a hablar de alineación.
Tan importante como lo que hacemos o como lo que somos para la compañía, es la visión que tienen los demás de nosotros.

Me explicaré. Hasta la crisis de las .com, tuvimos nuestra etapa dorada en que estuvimos presentes en cualquier planteamiento de desarrollo de negocio, con crecimientos del sector año tras año de dos cifras.

¿Por qué? Porque la tecnología de la información podía dar ventajas con las que mejorar los procesos empresariales de manera muy importante, y había enormes diferencias tecnológicas de unas empresas a otras. Estas diferencias, ya no existen o al menos no son tan acusadas (quizás, llegue alguna tecnología que cambie todo el orden establecido y nos devuelva a una nueva época dorada, pero eso es algo que está por ver).

Y puesto que ya no está tan claro que podamos aportar ventajas competitivas con tanta facilidad como ocurría hasta finales de los 90, nos hemos convertido en departamentos de servicios. (Ojo: no confundamos, no comparto las tesis que planteaba Nicholas Carr en “IT Doesn’t Matter”)

Así es como nos perciben normalmente, como departamentos de servicios y en muchos casos como vendedores de humo. Siendo conscientes de esto, ya podremos comenzar a alinearnos con los objetivos de la compañía.

Y debemos tener claras un par de cosas:

1. Nosotros no sabemos más que las áreas de negocio:

Son comunes los comentarios, “…el usuario no sabe lo que quiere…” Mentira, lo sabe perfectamente, otra cosa es que no nos lo cuente, o no nos guste lo que nos cuente. Recuerdo otro comentario (sic): “No necesitamos al usuario conocemos el negocio lo suficiente como para no tener que preguntarle”, ..y luego nos quejamos de que pidan cambios o de que no usan los sistemas…

2.Las aplicaciones no son nuestras, y mucho menos la información:

Por qué añadimos nuevas funcionalidades a las aplicaciones si nadie lo ha pedido, y peor aún porque reorganizamos los formatos en que se muestra la información. Tenemos la obligación de proponer mejoras y de aportar ideas, pero nunca de hacer algo que no sabemos si nuestro cliente quiere.

Bien, en este punto ya somos conscientes de que, salvo excepciones, somos un departamento de servicios, ni más, ni menos importante que cualquier otro; y no decidimos que necesita nuestro cliente, eso lo decide nuestro cliente, que lo sabe perfectamente.

Y tras esta cura de humildad, debemos continuar hacia nuestro objetivo, alinear los sistemas con los objetivos de la empresa. Pero como lo hacemos, pues pensemos en el departamento de IT como si fuese una empresa.

Si el departamento de IT fuera una empresa, estaría obligado a conocer a su cliente. Estudiaría el mercado en que se mueve, ¿cuál es su tamaño? ¿quién es su competencia? ¿en qué parte del mercado se va a desarrollar su actividad? Y después de conocer “El Mercado”, habría que investigar sobre los clientes. ¿qué quiere mi cliente? ¿qué es lo realmente importante para él?

Con todo esto ya podríamos tener a la cúpula del departamento “alineada”: comprendemos para quien trabajamos, comprendemos en que entorno nos movemos y comprendemos que es lo que quiere nuestro cliente y el porqué.

Falta ahora, comunicar internamente de manera correcta. Todo esto ha de ser comprendido por todo el departamento de TI. Si el personal comprende el problema y le damos suficiente confianza, no solo se sentirá cerca del cliente, sino lo que es mucho más importante, el equipo se atreverá a pensar y a tomar decisiones por si mismo, y ese, es el mejor camino hacia la alineación con el cliente

Termino con un enlace a un famoso artículo escrito en 2001, su contenido sigue vigente: CEOS are from Mars, CIOS are from Pluto


Metodologías, frameworks y estándares para el desarrollo de software. ¿Cómo lo he visto y cómo lo veo?

12 septiembre 2008

Mi primer contacto profesional con una metodología estándar, en este asunto de desarrollar software, sería allá por el 96 o 97. Nuestro cliente planeaba usar Métrica, la metodología de desarrollo de software de la administración española. Y nosotros nos adelantamos, utilizándola en todos nuestros trabajos. Yo creo que con ello abrimos cierto escalón de calidad entre nosotros y el resto de proveedores de nuestro cliente con los que competíamos, y eso nos hizo crecer de manera importante.

Este hecho, creo que me influyó decisivamente, y me hizo tener una visión, al menos durante unos años, bastante ortodoxa en el desarrollo de software.
Desde entonces, he tenido tiempo de conocer y trabajar con otras metodologías. He tenido tiempo creer en determinados planteamientos, y más tarde de abandonarlos y creer en los contrarios. Así que sirva mi experiencia personal, para contar un ejemplo de cómo se ha movido el mercado en estas cuestiones en la última década.

Como decía allá por el 97, comencé con métrica v2, el nivel de detalle de esta metodología permitía casi, poner el manual encima de la mesa y comenzar con el análisis de los sistemas. Fue necesario un esfuerzo importante en el primer proyecto, pero después solo había que seguir el manual punto a punto. Creo que lo mejor de métrica, además de que ofrecía un perfecto guión para todo el análisis era, que sus resultados eran comprensibles prácticamente para cualquiera, sin necesidad de ser técnico.
De este periodo de métrica, me quedo con dos cosas, por una parte, el orden y la calidad que aportaba el método, y por otra, con un comentario que uno de los clientes nos hizo y que ahora detallaré. Habíamos desarrollado un análisis que superaba el millar de páginas, durante la implantación del sistema, el cliente se quejó del funcionamiento de un módulo, y yo le dije “el módulo funciona según se recoge en el capítulo tal del análisis”. Nuestro cliente cogió uno de los volúmenes en los que habíamos encuadernado nuestro trabajo y mientras lo levantaba mostrándomelo, me dijo “¿tú crees que yo tengo tiempo para leerme esto?”
En aquel momento me resultó insultante, más adelante me pareció una estupenda lección que, como ahora hago, he citado en más de una ocasión.

Más tarde en el año 2000, en otra compañía y en otro negocio, tras decidir que los futuros sistemas irían hacia un entorno web, hubo que definir y decidir cómo se trabajaría. El análisis y la programación estructurada ya no nos servía. Después de estudiar cual debía ser el camino, elegimos RUP (Rational Unified Process) como framework para nuestros desarrollos. Realmente, mirándolo con la distancia que da el tiempo, el principal motivo de la elección fue que era lo que todo el mundo estaba haciendo: todo el mercado no podía equivocarse. Elegimos un proveedor para hacer un importante desarrollo, nuestro planteamiento fue, nosotros haremos un análisis utilizando las “antiguas” técnicas de programación estructurada y nuestro proveedor debía “traducirlo” a orientación a objetos utilizando RUP y Rational Rose. Ellos eran expertos y nosotros no. De la etapa de RUP, también me llevé varios aprendizajes:

RUP no solo era un framework para el desarrollo de software, se había convertido también en una “buzzword” (termino que utilizan los anglosajones para aquellas palabras rimbombantes que se ponen de moda y están en boca de todo el mundo), y como tal todo el mundo se proclamó defensor, conocedor y experto de RUP. Yo no tenía intención de aprender RUP, pero como el proyecto fue mal, no me quedó más remedio. Fue entonces, después de días y días de estudio de UML y RUP, cuando me di cuenta de que todo el mundo hablaba de RUP pero pocos sabían de lo que hablaban y muy pocos estaban capacitados para trabajar con esta metodología, en mi opinión, tremendamente compleja, pesada y difusa. Primera enseñanza, cuidado con los expertos, si realmente no lo son, sus efectos pueden ser nocivos, y segunda enseñanza, en ocasiones la marcha atrás no es posible. Cuando esto ocurre, caben dos posibilidades seguir hablando de las excelencias de la decisión que se tomó, o bien, admitir que la decisión no fue la mejor. La situación no es buena con cualquiera de ellas, por que lo esencial es que la decisión fue equivocada. Pero esta es otra historia, yo estaba hablando de metodologías.

La cuestión en aquel punto es que necesitaba reorientar los análisis y puesto que había aparecido la versión 3 de métrica, que soportaba orientación a objetos, esta fue la elección. Al menos, métrica centraba más las cosas, y era más sencillo implementar el análisis que con RUP.

Y así seguí hasta 2005, pensando que RUP continuaba siendo el estándar, aunque a mí me resultaba tremendamente pesado y complejo. En verano de 2005 comenzó una temporada en que tuve tiempo para reflexionar sobre todo esto (acababa de ser despedido). Me venía a la cabeza aquel comentario que antes citaba, realizado 6 años atrás y referido a un tocho de análisis de más de mil páginas. “¿Tu crees que tengo tiempo para leerme esto”?. Por otra parte pensaba en lo poco explicativos que resultaban para los usuarios los diagramas de casos de uso (de utilización extensiva en RUP), y me pregunté, por que narices los informáticos obligábamos a nuestros clientes a que utilizasen nuestras técnicas de diagramación, en lugar de ser nosotros quienes utilizásemos las suyas. Hablé con unos cuantos compañeros y amigos (Gente de empresariales, económicas, ingenieros, MBA’s) y les pregunté que tipo de técnicas os han enseñado para definir procesos de negocio. La respuesta fue unánime: ninguna. Así que me dije a mi mismo, debes salvar al mundo de los sistemas de información (entiéndase el tono jocoso) y crear una metodología basada en las necesidades de los clientes y no al revés.

Comencé a esbozar algunas ideas al respecto, hasta que di con la palabra clave: “Ágil”, es sabido que las cosas no existen, hasta que no das en en Google con la palabra adecuada, y una vez que la encontré me enteré de que hacía no mucho, que se estaban iniciando con fuerza lo que se venían a llamar “Metodologías ágiles” de desarrollo de software, mas o menos en línea con las ideas que yo tenía. Mi primer sentimiento, fue de rabia, ya estaba inventado lo que yo iba buscando. El segundo fue de todo lo contrario, me sentí satisfecho por evolucionar hacia una tendencia relativamente nueva, luego mis ideas y mis planteamientos eran buenos.

No obstante, en ese momento, no quise aprender nada más sobre “métodos ágiles”, pensé que si leía más al respecto, me condicionaría y no me permitiría ser creativo.

Entre notas y notas sobre el tema, iba haciendo algunos cursos dirigidos a emprendedores, un compañero de curso me dijo sobre mi idea. Lo que dices, suena muy bien, pero, ¿alguien te lo comprará? Tras resistirme durante unos días a reconocerlo, finalmente me di cuenta de que la respuesta era muy simple: NO, así que…, abandoné la idea.

Sería principios de 2006, y ahí se inició un paréntesis en mi relación con las metodologías de desarrollo de software, que duraría hasta verano de 2007, cuando comienzo un periodo como consultor y he de trabajar con la metodología utilizada por una gran empresa para la que trabajaba.
En aquel momento, su metodología me parece un refrito de UML con algunas técnicas de modelado de procesos, donde habían quitado protagonismo al modelo de casos de uso. Pero, hace muy poco que he leido algo sobre UML 2.0 y también sobre el estándar de OMT para la definición de procesos de negocio (BPM) y pensándolo, quizás se hubiesen basado en ello al definir esta metodología.
El caso es que me seguía pareciendo compleja, no me parecía que se hubiese evolucionado y pensaba que no aportaba gran cosa respecto a RUP.

Así que, me interesé de nuevo por lo que había en el mercado, y descubrí Microsoft Solutions Framework (MSF) en su version 3.0 (que no era novedad, pero sí para mi). Me pareció excelente, potenciaba el trabajo en equipo y la creatividad, promovía que cada etapa fuese dirigida por quien más capacidad tuviese para ello, había oido hablar y algo había leido también sobre “empowerment” y equipos de alto rendimiento (perdón por los palabros), pero no tan en detalle como MSF lo proponía y por supuesto no aplicado al desarrollo de software. Así que estuve durante un tiempo interesándome por el tema. Leí también sobre eXtreme Programming, que basa sus técnicas en el desarrollo entre pares y la velocidad de proporcionar al cliente prototipos tan rápido como sea posible. Y también sobre Scrum, excelente para plantear la estrategia de los proyectos a corto plazo. XP no es demasiado de mi agrado, si lo es sin embargo Scrum, al igual que las nueva versión de MSF para entornos “Ágiles” (la versión para CMMI me resulta pesada).

Paralelamente a esto, un día curioseando en una librería, hojee “Lean Thinking”. El “Lean Thinking” basado en el sistema de producción de Toyota, tiene como máxima el evitar desperdiciar tiempo y recursos, haciendo solo aquello que realmente sea necesario (¿Software en producción que nunca ha sido utilizado? ¿Le suena a alguien?), así que lo incorporé a mi pensamiento actual.

Por otra parte también tuve la oportunidad de aprender algo sobre Six Sigma, un método orientado inicialmente a garantizar la calidad en procesos industriales. Aunque 6 Sigma me resulta demasiado pesado, me quedo con su método para definir objetivos, centrado en las necesidades del cliente (“la voz del cliente”) y la percepción que el mercado tiene de nuestros productos y de los de nuestra competencia. A partir de aquí obtendremos objetivos mensurables que llama CTQ’s (Critical to quality)

Sinceramente, creo que pretender continuar con metodologías “pesadas” es un error, y comprendo que en grandes empresas prescindir de ellas es complicado. Pero creo que es el camino a seguir, sirva el ejemplo de los padres de UML y Rational, moviéndose hacia lo “ágil”

Así pues, si tuviera que elegir escogería algo así como el Framework”de Microsoft, tomando planteamientos e ideas de Scrum, Lean y Six Sigma. Pero sobre todo me quedo, como decía en un post anterior, con el “Think” que Thomas J. Watson llevó primero a NCR y después a IBM. Cada problema, cada proyecto, cada empresa son diferentes y no hay ningún guión escrito para ellos, esto no significa que los procedimientos y métodos no nos ayuden, todo lo contrario, pero debemos tener siempre presente que lo realmente importante es la resolución del problema, y no la metodología, que solo será un medio para conseguir el objetivo.


Definiendo Objetivos

4 septiembre 2008

Cuenta Jack Welch en Winning (hablo de memoria, así que la cita no será demasiado precisa), que en cierta ocasión en un evento que organizaba GE con los trabajadores de una fábrica, un operario le dijo: “durante veinte años me han pagado por el trabajo de mis manos, si me lo hubieran pedido, además de mis manos, hubieran tenido mi cabeza por el mismo precio”.

Es más que habitual que a la hora de comunicar los objetivos al equipo, hablemos de llevar a cabo determinado proyecto o determinadas acciones, con tal presupuesto, en un determinado tiempo, con un equipo… Pero muchas veces se nos olvida explicar el objetivo más importante y es el que responde a la pregunta de ¿para qué? El “para que” nos explicará cual es la verdadera utilidad de nuestro trabajo.

El operario de GE que mencionaba antes, pedía a su máximo jefe que le dejara pensar, pero es difícil pensar y es difícil involucrarse en un problema, si realmente no se sabe cuál es el objetivo que se persigue, si la información no se comparte procurando la máxima transparencia posible.

Me viene a la cabeza el famoso “Think” de IBM, introducido por Thomas J. Watson, aún en sus tiempos de NCR. Quizás la consecuencia del “Think”, fue la impresionante cantidad de innovaciones e ideas que IBM aportó a lo largo del pasado siglo.

Evidentemente no estoy contando ningún misterio ni nada nuevo tampoco, pero es que en la práctica, es tan poco habitual encontrar un entorno de trabajo en el que se promocione, algo que da tan buenos resultados y que cuesta tan poco: pensar.


Genial, fácil, simple: Scratch

2 septiembre 2008

Si buscais un entorno de programación simple e intuitivo, Scratch es lo que andabais buscando. Solo tiene un problema, esta pensado para los niños, habrá que esperar que alguien haga algo así para uso profesional.

En lo que yo conozco, las herramientas de programación, como mucho contaban con editores que añadían algun color en el código del programa para identificar ciertas estructuras y facilitar de esa forma la lectura.

El MIT ha hecho algo tan simple y fácil como sustituir los comandos escritos de un lenguaje de programación por formas y colores, con los que solo hace falta pinchar y arrastrar. El objetivo de los programas realizados con Scratch, de acuerdo con el público al que va dirigido, son animaciones y juegos.

Para que os hagais una idea, un niño de nueve años  sin ningún conocimiento previo de programación, en cinco minutos ha realizado su primer programa, que puede subir a la web de Scratch pulsando solo un botón. Y lo mejor de todo, durante todo el tiempo lo único que ha hecho ha sido jugar.

Espero que en el futuro podamos decir: Me voy a la oficina a jugar con Scratch