Archivo de la categoría: Proyectos

¿Cómo que falta personal técnico?

Hace unas semanas, Rodolfo Carpintier expresaba su opinión (e insistía) sobre los profesionales del sector informático. Antes lo hizo Enrique Dans aquí y aquí.

Yo, que pertenezco a ese selecto grupo de privilegiados de los que llegan a afirmar que no conocen el paro, no puedo más que sentir indignación. Trabajo en este sector desde 2000 y he visto de todo, incluídas las colas del INEM. Tal como indica Rodolfo, yo soy de los que se creyeron muchos de esos proyectos y terminaron en esas colas.

Ahora bien, cuando hablan de que nos sobra trabajo se refieran a esos de 850 euros mensuales, bueno vale, o 900 (en 12 pagas). Así claro que no hay paro, pero también podemos prostituirnos, bueno, yo lo dudo :). De ahí a los 30.000 euros anuales que comentan creo que hay un largo trecho, y más teniendo en cuenta que hay más país mas allá de Madrid y Barcelona. Yo vivo en Valencia y no he visto una oferta de programador por ese salario nunca, acaso alguna oferta de analista con mucha experiencia.

También habla Rodolfo acerca de startups y equipos de trabajo de horas y horas sin apenas sueldo, a cambio de participaciones en el proyecto. Supongamos que me creo el proyecto y que estoy dispuesto a ello. ¿De qué se supone que voy a vivir los próximos 12 o 24 meses? ¿De lo que he ahorrado los dos años anteriores? Me invade la risa, pero a mi hipoteca todavía más.

Me hace mucha gracia que hablen de que los profesionales con experiencia considerable son cada vez más inalcanzables. ¿Acaso los buenos economistas no lo son? ¿Y los abogados? ¿Y los gestores? Cualquiera de ellos probablemente estará por encima de los buenos técnicos en materia de sueldo.

Enrique comenta que falta personal, mucho personal, y desesperadamente. Que esto está bloqueando el desarrollo de nuevos proyectos en Internet. A esto sólo cabe una respuesta. Mira los salarios que pagan. Él piensa que no puede ser así, por que dada la escasez que existe los precios subirían. Pues no. Hasta hace menos de un año se han cubierto sin problema las demandas de trabajadores a bajos sueldos y siempre había remplazo para ellos. Pero muchos se han cansado. ¿Por qué vas a programar tu por 900 euros si el de al lado, el comercial, que hace bastante menos que tú, se lleva 1800? ¿O acaso en el periodo 2000-2007 no han salido cientos y cientos de programadores? Suma ingenierías técnicas, superiores y ciclos de grado superior. Cientos de profesionales anualmente. La mayoría trabajando por sueldos ridículos en un trabajo altamente especializado. Es indudable que, como bien argumenta Enrique, la profesión sufre de un desprestigio brutal. Pero es un desprestigio provocado por la situación laboral del sector en el periodo 2001-2007.

Todos hablan de la falta de compromiso del profesional y de que quieren hacer sus 8 horas y cobrar su sueldo. ¿A alguien se le ha ocurrido pensar en el compromiso de la empresa para con el trabajador? Osea, queremos pagarles poco y que se comprometan. La empresa para qué se va a comprometer, ya le da trabajo, ¿qué mas quiere?. Pues quiero salir a las 5 de la tarde. Quiero que no me programes una reunión a las 6 de la tarde. Quiero que pienses que soy una persona y necesito mi tiempo libre, que trabajo por necesidad, porque necesito el dinero para vivir. Quiero que entiendas que, si yo estoy contento, mi trabajo será mucho mejor y estaré mas comprometido e integrado y aceptaré más retos y responsabilidades. ¿No lo ves? Además, ahora quieren profesionales comprometidos, que sepan reaccionar y con capacidad de solucionar problemas. Pero, por otro lado, una inmensa mayoría quieren programadores mandados, tú tienes que hacer esto, tú aquello y el otro lo de más allá y lo tenéis que hacer así. A picar código y me avisas cuando termines. Me quedo con esta frase de Enrique Dans:

Y es que pasar de obrero a arquitecto no sólo requiere un nivel superior de cualificación. Supone, además, que existan incentivos para ello.

Ahora está muy complicado el mercado, eso es indudable. Nuestros últimos procesos de selección se han alargado meses y meses y seguimos sin encontrar gente válida. Ya da igual que busques gente con experiencia o comprometida, es que apenas encuentras gente de ningún tipo. Es el precio que nos toca pagar de años de maltrato al profesional.

Personalmente creo que la discusión no debería ser si hay o no gente cualificada sino ¿dónde están todos los profesionales graduados los últimos años? Sencillamente resignados. El que más y el que menos ha pasado por varios trabajillos de esos de sueldos míseros. Para el que se ha pasado estudiando hasta los 23 o 25 años (en el mejor de los casos) es algo frustrante ver que no hay salida. Se han resignado y prefieren un trabajo de esos que les permite vivir tranquilamente y sin agobios esas 8 horas por un sueldo mediocre porque se han dado cuenta que no encontrarán algo mejor, y aunque lo hagan llegan al momento de creerse milongas, aún recuerdo la última vez que oí hablar de incentivos. La situación es el clásico más vale malo conocido que bueno por conocer.

Por favor, dejémonos de quejarnos de una vez. El personal técnico es, en general, gente muy preparada, capaz, profesional y, lo más importante, les encanta su trabajo. Tratémosla como tal y démosle lo que se merece. A fin de cuentas, tal como dicen todos estos gurús, en sus manos está el desarrollo de tu negocio. Recuperemos el valor de nuestra profesión.

Otro día hablaremos de la parte de culpa de las cárnicas consultoras, de las subcontratas y de la situación del sector en las Pymes, mayoría de empresas en este país.

Ajax vs. Flex

O Flex vs. Ajax. O Silverlight. O JavaFX. Menudo debate. A muchos no les gustará y sé que generará mucha controversia. Yo hablaré de Flex pues es el que conozco, pero podríais hacer la misma comparación con los otros dos.

Para el que a estas alturas no lo sepa, FLEX es la tecnología Flash orientada a programadores. Tradicionalmente Flash ha sido una herramienta de animación y diseño, la que conoces de toda la vida. Después de un primer intento más o menos fallido con Flex1 y 1.5, Adobe, tras adquirir Macromedia, decidió reorientar el rumbo, construyendo algo auténticamente revolucionario con Flex2. Las secuelas, además de Flex3, han sido AIR (para aplicaciones de escritorio) y próximamente Thermo (diseño de R.I.A.). Con Flex2 han conseguido crear una herramienta para la construcción de interfaces de usuario en Flash.

No cabe duda que las R.I.A. están de moda. Da igual la tecnología utilizada, cada día aumentan las aplicaciones online. Desde sistemas operativos online hasta aplicaciones de edición de fotografías o vídeos pasando por aplicaciones corporativas de gestión de cualquier tipo.

Pero ¿qué es mejor para construirlas? La respuesta es sencilla: depende de para qué. No me sirven argumentos sobre plugins (¿Javascript funciona en Lynx?) o software libre vs. privativo (¿acaso al usuario habitual le importa o sabe lo que es?) o SEO (¿Javascript es search engine friendly?). Hablemos mejor de utilidad y de conveniencia para el desarrollador y el usuario.

Lo primero que deberíamos preguntarnos es

¿Qué voy a hacer?

No es lo mismo hacer una web o una aplicación que va a utilizar mucha gente que hacer una aplicación de gestión para una empresa de seguros o un banco. ¿Alguien se imagina a una aseguradora haciendo su software de gestión en Javascript? Pero sí en Flex como de hecho están haciendo ya. Por otro lado a nadie se le ocurriría hacer una web en Flex, no tiene sentido, no es su cometido. Pero sí que harías una aplicación como la de Flickr para editar fotografías online o la de Youtube para hacer montajes de vídeo. O pequeños módulos concretos que no podrías hacer de otro modo o que te costaría demasiado, o widgets varios como está haciendo mucha gente utilizando feeds, mapas, etc. Este creo que sería el punto clave diferenciador. Con Ajax hacemos complementos para aplicaciones web o pequeñas aplicaciones, con Flex hacemos aplicaciones completas. Lógicamente estoy generalizando y cada uno puede pensar y hacer lo que quiera, hay aplicaciones completas realizadas 100% en Javascript, no hay ningun inconveniente, para ejemplo EyeOS. ¿Por qué opino esto entonces? Sencillo, por una simple cuestión de ingeniería del software y productividad. Flex es un lenguaje orientado a objetos 100% y con todas las ventajas que aporta. Crear interfaces de usuario con Flex es impresionantemente sencillo. ¿Alguien puede decir lo mismo de Javascript? Que se puede hacer es indudable, pero a costa de convertir la aplicación en una auténtica telaraña de Javascript‘s. ¿Qué ocurrirá cuando otro programador deba tomar esa aplicación y modificarla? Cualquiera que haya hecho lo más mínimo en Ajax sabe que es una locura. No hay un patrón MVC y la interacción con la interfaz de usuario (html) es harto difícil, innerHTML está muy bien y es muy rápido, pero siendo puristas deberíamos utilizar DOM, a medio plazo lo agradeceremos, y sino intenta modificar atributos de código insertado con innerHTML :P.

Mejor aún, encontremos un responsable de proyectos, director técnico o el cargo que se os ocurra que se comprometa a realizar un proyecto medianamente importante en Ajax. Si conoce Flex verá las similitudes con Java, de hecho se hizo con Java en mente. Si no lo conoce pensará directamente en Java, difícilmente se le ocurriría pensar en Ajax, su cuello es el que está en juego en definitiva.

¿Para qué hemos utilizado nosotros Flex?

Hemos hecho widgets de distintos tipos, paneles de control y gestión, aplicaciones de audio/vídeo multiusuario (chat, audio-chat y vídeo-chat). Ahora mismo trabajamos en un cliente IRC en colaboración con una de las principales redes de IRC.

En backoffices y otros paneles administrativos hemos comprobado que para el usuario la comprensión y utilización de la aplicación es muy superior a interfaces html puesto que son más parecidas a una aplicación de escritorio tradicional y tienen más interactividad, algo que el usuario agradece.

En artículos posteriores os expondré algunos ejemplos de cosas que hemos ido haciendo a lo largo de los dos últimos años, aunque también veremos cosas en Ajax, no son tecnologías excluyentes.

Añadir que Flex ya es de código abierto, el SDK es libre y hay un excelente plugin para Eclipse. Lo único que es de pago es el Flex Builder de Adobe, la aplicación oficial, pero puedes hacer tus aplicaciones con el plugin de Eclipse del mismo modo.

Por cierto, Adobe no me paga nada por este post :P.

¿Por qué nos siguen enseñando gestión de proyectos en cascada?

Cada día que pasa lo entiendo menos. Cualquiera que haya participado en algún proyecto de software, da igual el tamaño del mismo, se habrá dado cuenta que los patrones a seguir que nos enseñan a todos en las asignaturas de ingeniería del software y gestión de proyectos ya no tienen sentido. De hecho hace mucho tiempo que dejaron de tenerlo. Toma de requisitos, análisis, desarrollo, pruebas, implantación… Y cuando los usuarios finales comienzan a utilizarlo te das cuenta de que la usabilidad es nula (no es lo mismo como piensan los técnicos que los usuarios finales), faltan funcionalidades básicas, determinados procedimientos cotidianos se han complicado tanto que el trabajo diario se alarga… ¿Solución? O bien se aumenta el presupuesto para contemplar las modificaciones (suele ocurrir con las administraciones públicas) o bien el cliente no te paga hasta que el software funcione como él y sus empleados necesitan, con lo cual tu estimación de tiempo/recursos se ha quedado corta y empiezas a perder dinero sobre el plan inicial.

¿Por qué ocurre esto? Sencillo, por que es muy difícil contemplar todas las necesidades del cliente en la fase inicial del proyecto. Pensar que con las notas que se toman durante esas semanas va a ser suficiente lleva a ocultar las potenciales carencias. Sí, hablas con el personal de tu cliente, ves como trabajan, te lo apuntas todo. Pero tú no eres el que trabajará con la aplicación, son ellos, pero vas a plantear el proyecto desde tu punto de vista, no desde el del cliente. Cuando les enseñas el producto aparecen los problemas.

¿Y si, en vez de eso, implantas en tu equipo de desarrollo técnicas de desarrollo ágil? Podríamos decir que sería un método de desarrollo orientado a producto, periódicamente se liberan versiones funcionales del software, con más o menos funcionalidades, pero que funcionan y permiten al cliente toquetear y jugar con su compra.

El ejemplo más evidente lo tenemos en el desarrollo de webs. Cualquiera que haya trabajado en ese campo se habrá topado con el momento en que el cliente empieza a ver lo que hay hecho (es una web, puede verla en cualquier momento ¿no?) y comienza a pedir cambios y a decir cosas que no le gustan. Para nosotros, que tenemos nuestra idea clara del desarrollo lineal, que sabemos que teníamos tres meses para hacer el desarrollo y vamos a cumplir ese plazo, comienzan los problemas. Pierdes la línea de tus planes y comienzas a centrarte en lo que el cliente ha dicho al ver cosas, en cambios, en errores, olvidándote de todo lo planificado que te queda por hacer porque mañana volverá a ver la web y querrá ver los cambios solicitados, tu mente en cascada no es capaz de verlo de otro modo.

En vez de eso vamos planteando pequeños desarrollos cada tres o cuatro semanas. Cada periodo se presenta algo nuevo que funciona, es decir, comenzamos por una pequeña porción del sistema, siempre funcional, y la vamos aumentando poco a poco en periodos posteriores teniendo siempre en cuenta los errores detectados y las impresiones del cliente, sin olvidarse de las funcionalidades pendientes. Estaríamos, por tanto, ante un desarrollo adaptativo en función de las necesidades que se van viendo sobre la marcha. Por esta misma razón comenzamos a tirar líneas de código mucho antes que en los procesos tradicionales ya que apenas nos preocupamos por concretar todos los detalles al inicio, lo vamos haciendo sobre la marcha y con una idea inicial bastante general es suficiente. El objetivo es algo siempre complicado, que el cliente se implique en el proyecto y aporte continuamente su feedback.

Puedes comenzar con el Manifiesto ágil y buscar documentación y bibliografía sobre desarrollo ágil y SCRUM (una de las técnicas más utilizadas). Ya de paso no estaría de más echar un vistazo a Xtreme Programing (no, no es trabajar 15 horas diarias).

A los desarrolladores, en general, nos cuesta mucho asimilar los conceptos ágiles. Nos enseñaron a ser mecánicos en los procedimientos de desarrollo de software y este tipo de técnicas se basan más en ir sobre la marcha, y cuidado, esto no significa ni mucho menos que sin planificación, al contrario. La primera pregunta del director de proyectos la primera vez que oye hablar de desarrollo ágil será: bueno, pero así ¿cómo hago las estimación del tiempo necesario? Pues igual que lo hacías hasta ahora, estamos proponiendo nuevas técnicas de desarrollo, pero la estimación tienes que seguir haciéndola igual: piensa en las tareas que hay que hacer y estima el tiempo necesario para realizarlas, compáralo con la cantidad de recursos (personas) de tu equipo y obtén las estimación, o mejor aún, ya que hablamos de técnicas ágiles, deja que sea el propio equipo el que estime la duración de las tareas, a fin de cuentas son los que las van a hacer.

Subversion, ese gran desconocido

Equipos de varias personas, proyectos sin fecha de finalización, corrección de bugs, nuevas funcionalidades… ¿cómo gestionáis todos esos cambios?

Me resulta difícil de creer, por no decir incomprensible, que, en la época en que vivimos, la inmensa mayoría de empresas de desarrollo de software no utilicen un mínimo sistema de control de versiones (CVS, Subversion, Sourcesafe…). Y no hablamos sólo de pymes, hablamos también de grandes consultoras con grandes proyectos de las administraciones públicas. Y es que no hay mejor cara que aquella que se te queda cuando haces update y te contesta file merged. O mejor aún, cuando has metido la pata hasta el fondo y recurres al superhéroe de la película, a revert.

Algunos pensarán, cuando hablamos de desarrollo de software, que hablamos de grandes aplicaciones o proyectos, pero están equivocados, hablamos de cualquier cosa que se programe, incluida una web.

Subversion es lo que se conoce como un sistema de control de versiones (del inglés Control Version System). Control de versiones es la gestión de los cambios y modificaciones en el código fuente de un proyecto, es decir, cada cambio que se hace en el código queda registrado de manera que en cualquier momento se puede saber quién hizo qué. Pero eso no es todo. ¿Qué ocurre cuando dos o más programadores trabajan sobre la misma aplicación y sobre los mismos ficheros de código? En un escenario normal no podrían. Uno tendría que esperar a que terminase otro para obtener la última versión, hacer sus modificaciones y pasárselo al siguiente. Obviamente eso no es ni óptimo ni deseable, tendríamos programadores esperando para poder trabajar. Subversion soluciona esto permitiendo que varios programadores trabajen sobre el mismo proyecto simultáneamente. Llegado el momento de unir todas las piezas, él lo hace por ti, es lo que se conoce como merge.

¿Qué ocurre cuando el cliente solicita cambios en tu proyecto y, cuando lo tienes terminado, da marcha atrás y prefiere que todo vuelva a estar como antes? Como no has hecho copia de seguridad del código en el estado anterior tendrías que volver a rehacer tu código para quitar lo nuevo y ajustar lo anterior. Con Subversion es tan sencillo como recuperar la versión anterior.

Lo más sorprendente es buscar gente para tu equipo de desarrollo y encontrarte con que a ninguno les suena ni CVS, ni Subversion ni nada similar. ¿Tan poco profesionalizado está el sector? Dá igual los estudios, nadie sabe lo que es y siempre les cuesta adoptar el cambio de filosofía ftp/Subversion.

Lo mejor de todo es que hoy en día no tienes que saber ningún comando manual, está todo automatizado. Eclipse tiene integración plena con Subversion, de manera que hacer commit, update o cualquier otra cosa son unos simples clicks de ratón. Pero eso no es todo, con TortoiseSVN tendremos integración plena con el explorador de archivos de Windows. De un vistazo podrás ver qué archivos has modificado, cuales están sincronizados, etc…

¿Aún no ves las ventajas?