Categoría: Marca Personal & Carrera

Una de las cosas a las que más atención presto cuando tengo que diseñar la arquitectura de una aplicación o plantear la industrialización de un desarrollo es el gestionar la capacidad de la gente. No todo el mundo tiene la misma capacidad de «coco», pero si que hay una cosa cierta, nadie la tiene infinita. Así que hay que pensar muy bien con que cosas quieres llenarla.

Normalmente, independientemente de la capacidad natural de cada persona, con el tiempo esa capacidad se va aumentando, porque ya vamos teniendo cimientos sobre los que asentar los nuevos conocimientos.

Como he comentado en alguna otra entrada, llevo en el mundillo del desarrollo de webs con Java, de cuando eran webs y no aplicaciones lo que se hacían. Así que he visto como se ha ido complicando todo. Todavía recuerdo en uno de los primeros proyectos de envergadura en los que participé como un compañero me decía, que para que me preocupaba tanto por el código, si no lo mira nadie.  Hoy día casi todo el mundo tiene controles da calidad en el código.

Alguna vez comentando con compañeros de trabajo sobre estos temas, ponía de relieve que a los programadores se les empezaba a exigir saber de Java, JavaScript, Html, Bases de datos, etc y encima con auditoria de código, normas de base de datos, normas de usabilidad, etc, pero luego se les daba nada de tiempo para que hiciesen el mantenimiento en cuestión.

Así que siempre intento dejar las arquitecturas de las aplicaciones o las metodologías de trabajo lo más sencillas posibles. Recuerdo una presentación que vi en Internet de la arquitectura de Pinterest, en la que recomendaban justo esto mismo. Decían que mejor dejar la arquitectura lo más sencilla posible, porque siempre acabará fallando y cuando más sencilla sea más fácil será de arreglar. Explicaban la arquitectura que habían ido siguiendo ellos y como tuvieron que simplificarla.

Me ha sorprendido lo simple que es la arquitectura de desarrollo que se propone en el Google App Engine. No hay capas y más capas de servicios. Es todo mucho más plano.

Me he dado cuenta también de la cantidad de cosas que hacemos sin reflexionar, dejándonos llevar por lo que se hace en el mercado, sin ser un poco críticos con ello. Montamos arquitecturas aplicando mil patrones para dotarnos de una flexibilidad que luego en la mayor parte de las veces no usamos. Pero lo que si que encarecemos es la creación de las aplicaciones.

Recuerdo en una de las empresas en las que trabajé que se tenia una arquitectura de hacer las aplicaciones en las que se tardaba unos 5 días por mantenimiento, hasta que se marchó la persona que definía esas cosas y le pudimos meter mano. Aligeramos la arquitectura y se dejó cada mantenimiento en 4 días. Habíamos bajado un 25 % el tiempo de desarrollo en cada mantenimiento. Simplemente quitando flexibilidad que no servia para nada.

En este negocio del desarrollo de aplicaciones, cuando te enfrentas tanto a la definición de Arquitecturas Web, como a la Industrialización del desarrollo hay multitud de herramientas y de técnicas disponibles.

Supone un trabajo ingente el valorar y monitorizar la evolución de tal número de herramientas. Yo desde hace mucho tiempo he optado por una estrategia que me ha dado buen resultado.

Normalmente suelo monitorizar algún sitio de referencia para estar al tanto de las novedades que van surgiendo y cuando sale alguna herramienta o tecnología que no conozco y está en el área en el que me muevo le echo un vistazo, para estar al día.

He tenido compañeros que aparte de ir al web y enterarse a nivel teórico, incluso hacían una prueba por ellos mismos. A mi esto me parece dedicar mucho esfuerzo a conocer las interioridades de algo que no sabes si vas a llegar a necesitar en algún momento. Yo prefiero quedarme con el nombre de la herramienta y para que sirve y si en algún momento necesito esa funcionalidad recuperar la información y si procede probarlo, pero ya con un objetivo concreto.

Últimamente sigo bastante a Google, que aparte de tener una multitud de servicios para usuarios finales también tiene una sección de desarrollo con multitud de herramientas, guías, etc.

Son los que tienen la nube más grande y sus productos están diseñados para soportar una carga de trabajo muy alta.

Normalmente no vas a necesitar esos niveles de rendimiento, pero está bien ver como lo han resuelto ellos, para tomar ideas.

Cuando hablamos de industrializar, lo normal es que se nos venga la cabeza la típica imagen de una fábrica de coches, en contraposición a cuando hablamos de la artesanía, en la que lo normal es que se nos venga a la cabeza la imagen de algún orfebre, una encajera, etc.

La principal diferencia es que en la industrialización hay implicadas más de una persona y en la artesanía normalmente solo una.

Uno de los puntos que van a marcar la diferencia en la industrialización es lo ajustado que estén todas las personas involucradas y en lo afinado que esté el procedimiento de trabajo.

Negociar

Hoy quiero comentar respecto a la industrialización del desarrollo la importancia de la negociación y el saber delegar. Ambos son actitudes muy importantes para lograr que la maquinaria de producción vaya fina (No producimos coches ni lavadoras, pero si programas).

En mi vida profesional he tenido jefes y personas a mi cargo de todo tipo.

Con los jefes, hasta los más intransigentes, he procurado negociar las tareas. Digo negociar, no regatear. Me explico.

Puede ser que tu jefe te pida realizar alguna tarea o bien que tu mismo le propongas algún tipo de mejora. Entre dos personas puede suceder que haya un entendimiento a la primera, con lo que no hay nada que negociar, o bien que no lo haya. En este caso lo ideal es que cada uno de sus argumentos para intentar convencer al otro de la bondad de sus planteamientos. Puede ser que uno convenza al otro. Si esto no es así al final se aplica la jerarquía. Cada uno tiene su parcela de responsabilidad, por la que tiene que rendir cuentas, y consiguientemente su autoridad correspondiente. Así que normalmente no es una negociación muy larga.

Recuerdo una conversación que tuvimos un par de compañeros con el jefe, en la que le comentábamos (bueno realmente le recriminábamos) sobre otro compañero, que a nuestro entender no estaba haciendo las cosas bien y nos estaba perjudicando seriamente. La verdad es que era un jefe muy tolerante, que nos dijo algo que me parece muy importante tener siempre en cuenta. «Yo creo que es mi obligación escucharos y tener en cuenta vuestras opiniones, pero al final el que tengo que tomar las decisiones soy yo, porque soy el que tengo todos los datos».

Una vez que se llega a un acuerdo, como he comentado en otras ocasiones, lo que queda es cumplirlo de la mejor forma posible, estés o no de acuerdo. Todo el mundo está en su perfecto derecho de pensar lo que quiera, pero no de hacer lo que quiera.

Es muy raro que alguien confíe en otro si una vez llegado a un acuerdo no lo cumple. Tuve un jefe que nos comentaba que a lo largo de la vida te vas rodeando de la gente que te funciona. Era en medio de una conversación sobre una serie de personas que no le estaban funcionando y que al final acabó despidiendo.

Hay un concepto que es primordial, tanto en tu profesión, como en la vida misma: Cumplir los compromisos

Si no cumples corres el riesgo de que te consideren poco fiable y eso es algo que no es para nada interesante.

Cuando quieres industrializar el desarrollo de software no siempre es fácil de cumplir los compromisos, ya que dependes, de muchos factores que escapan de tu control.

Hoy quiero hablar de uno de los elementos más determinantes, los compañeros, el equipo de trabajo. Con suerte compañeros con experiencia que saben como funciona el negocio y otras veces compañeros con poca experiencia.

Creo que es importante insistir a los compañeros con menos experiencia lo importante que es el hecho de cumplir los compromisos. Y que cumplir el compromiso global de entregar la aplicación se basa en el cumplimiento de todos los pequeños compromisos de cada una de las pequeñas tareas que se van encomendando.

Cuando se acerca tu jefe y te indica que tienes que realizar tal mantenimiento para tal fecha y dices «vale» o simplemente no dices nada, has contraído un compromiso. Puedes tener suerte y que tu jefe esté sentado cerca tuyo y tenga pocas personas bajo su responsabilidad y pueda estar haciendo un seguimiento cercano, para ver que tal vas. Pero puede ser que no sea el caso y no pueda estar (o no quiera) como una madre preocupándose de todo. Pero esta situación no hace que los compromisos desaparezcan, siguen ahí.

Yo he estado en ambas situaciones, siendo responsable de un grupo de gente y poder dedicar tiempo al seguimiento y en otras ocasiones no pudiéndoles dedicar tiempo a ese seguimiento.

En estas ocasiones de falta de dedicación aplico un criterio que me comentó un antiguo jefe: «Mientras no digas lo contrario asumo que todo va conforme al plan y si tienes algún problema levanta la mano y se te ayudará».

Concepto simple, pero ¡que difícil es de llevar a la práctica!. Con suerte te encuentras con compañeros que te avisan justo el día de entrega, cuando ya no tienes margen de maniobra. Sin suerte, tienes que ir tu a preguntar: oye esto que tenias que acabar hace dos días está acabado?

Yo por lo menos nunca me he enfadado con alguien que se ha encontrado con dificultades y ha pedido ayuda cuando ha notado que se atascaba. Otra cosa es que igual no se le ha podido ayudar. Pero si que me molesta mucho los que incumplen sus compromisos y no alertan, porque afectan al cumplimiento de los objetivos del proyecto.

Hay un colateral al tema de levantar la mano y pedir ayuda, y es cuando la gente recurre muy alegremente a pedir ayuda. Hay que tener en cuenta el hecho de que alguien te ayude significa que sumas más horas a la tarea, las tuyas y las de quien te ayuda, y aunque cumplas el plazo no cumples el coste. Y el compañero que te ayuda también tiene compromisos que cumplir y te está dedicando su tiempo.

Es difícil dar una regla de cuando levantar la mano y cuando seguir intentándolo por tus propios medios. Solo dos reflexiones. El plazo de entrega hay que cumplirlo, si ves que no vas a llegar, levanta la mano. A más levantes la mano más van a pensar que no vales para hacer ese trabajo… tu mismo.

Hoy en día cuando te enfrentas al desarrollo de algún proyecto software, por mucho que hayas definido una buena arquitectura de la aplicación y por mucho que tengas industrializado el desarrollo, si alguien rasca, va a encontrar chapuzas.

Salvo que te encuentres en un proyecto en el que la calidad es crítica, por ejemplo en aplicaciones sanitarias, y consiguientemente el coste va aparejado, lo normal es que los clientes no estén dispuestos a pagar la perfección.

Como buenos profesionales que queremos ser, esto es muchas veces duro de asimilar, porque quieres hacer un trabajo redondo, pero tienes el tiempo y el dinero para hacer un proyecto redondeado, que no redondo.

En la carrera tuve un profesor de economía que nos dijo algo palmario. Si tienes un negocio en el que te roban un millón (de pesetas) al año y poner un sistema para que no te roben te cuesta tres millones (de pesetas), prefieres que te roben.

Esto es así, pero lo que no debemos es dejar que se convierta en un coladero, en un planteamiento de como es una chapuza, para que me voy a esforzar. Para ello lo ideal es que esté definido lo mejor posible que es lo que espera el cliente obtener, es decir los requisitos funcionales y técnicos.

La filosofía que intento inculcar a los compañeros es la de: «Si rascan encontrarán, pero por lo menos que se tengan que dejar las uñas rascando» que va un poco en la línea de Pruebas que no podemos fallar

Si atendemos a la filosofía de la marca personal que propugna que cada persona se plantee como una empresa, el CEO ha puesto las pilas al Community Manager por la errática presencia en Internet de la empresa. 🙂

Me recuerda a un profesor de física que tuve en el colegio, que nos dijo una vez: «Ayer por la tarde se ha reunido el departamento de física y hemos decidido, es decir me reuní conmigo mismo y decidí que…»

Este dominio existe desde el año 2001, concretamente el 8 de Agosto. En aquella época si buscabas en google por mi nombre solo tenía que competir con Iñigo Montoya, el personaje de la película La princesa prometida. Así que era fácil.

Hoy día ya no aparezco el primero en Google, aparecen entradas de LinkedIn, un tocayo que ha fundado una empresa y tiene miles de seguidores, un centro podológico en el pueblo de al lado, etc. Menos mal que en Yahoo y Bing si aparece el dominio el primero.

Es normal, la web lleva más de 10 años sin actualizarse. Además es una redirección, el contenido no está directamente en el dominio, sino que ha estado en una URL de mi proveedor de ADSL y últimamente alojado en mi casa, en una RaspberryPi. Que para redondear las cosas en la última actualización del Software ha cambiado la URL externa (tiene un servicio parecido al DynDNS).

Además el Blog no estaba con mi nombre, sino con el de Olmito (tuve un olmo bonsai), así que el poco contenido nuevo que generaba no se asociaba con mi nombre. (Que épocas en las que todavía nos preocupaba la privacidad en Internet)

Así que me he tenido que poner la gorra de Community Manager y poner al día mi presencia en Internet. Afortunadamente las cosas importantes como el dominio y el nombre en Twitter son de mi propiedad.

He redirigido el dominio al blog, dejando en un segundo lugar las versiones anteriores del web, que siguen albergadas en la RaspberryPi de mi casa. También he empezado a darle un aspecto y contenido más cuidado al blog, antes era un mero contenedor de ideas u opiniones sin una estructura y objetivo concreto y con look por defecto.

Es cierto que ya es habitual el ir a google, linkedin y facebook a buscar información sobre alguien que has conocido y que el curriculum como presentación en papel de una persona ha dejado de tener tanta importancia. Pero cuando la gente que propugna la marca personal dice que el curriculum en papel ya no vale para casi nada, que muchos reclutadores lo que hacen es buscar por Internet y ese es tu curriculum real, lo que no se dan cuenta es que es fácil si eres alguien con miles de seguidores, o que estás generando contenido muy a menudo, o tienes un nombre no muy común. Pero no es tan sencillo para un profesional por cuenta ajena.

Espero que os guste el nuevo tema del blog.

En la universidad tuvimos una práctica que consistió en montar un pequeño ordenador, para lo cual teníamos que soldar los componentes a la placa. Me pareció muy entretenido. No se si el estaño contiene alguna sustancia adictiva, pero me encantaba el olorcillo.

El problema fue que te soltaban en el laboratorio y ahí te las apañases. En una de estas casi la lio parda porque se me cruzó el cable de corriente eléctrica con el estañador, que al final es un hierro caliente, y se derritió algo de plástico. Si llega a derretirse todo el plástico, hubiese habido un buen chispazo, a un palmo de mi «careto»…

Le pedí sopitas a mi tío que se dedicaba a esas cosas. Me regaló un estañador y un desestañador que tenia viejos y lo más importante, me explicó como utilizarlos. No tardó nada, pero me explicó las cuatro cosas básicas que tenia que saber. Entre ellas como poner el estañador y el cable para que no me pasase lo que me pasó en el laboratorio.

Cuando empiezas a trabajar te sueltan y ahí te las compongas. Si tienes suerte y te juntas con compañeros que saben, genial, si te juntas con compañeros de estos tóxicos, pues corres el riesgo de aprender cosas equivocadas.

¡ Que importante es enseñar a los compañeros con menos experiencia !. De como lo hagan ellos también depende el éxito personal. Si el proyecto va bien salimos ganando todos, si va mal tendrás que andar dando explicaciones… y no interesa.

Uno de los objetivos de este blog es contar las experiencias vividas para que puedan servir a otras personas. No es que esté en posesión de la verdad absoluta, pero si que es mi experiencia.

Esta entrada la he etiquetado en dos apartados, porque cuanto mejor formados estén los compañeros noveles mejor para el proyecto y eso es importante tanto para la Industrialización del Desarrollo, como para tu propia marca personal. Si el proyecto va bien (o mal) y tu has estado en el, algo habrás tenido que ver. Tiene también mucho que ver la gestión del conocimiento

En esta entrada voy a ponerme un poco en plan abuelo cebolleta, (storytelling si nos ponemos en plan geek) hablando de cuando programaba y de las pruebas de aplicaciones que no podemos fallar. Tiene relación sobre todo con la industrialización de desarrollo, por el impacto que tiene el no probar bien las cosas.

En mis épocas mozas, cuando me dedicaba básicamente a programar, cada vez que le entregaba algún mantenimiento a mi jefa, rezaba (bueno igual es un poco exagerado lo de rezar) para que tardase en encontrarme un fallo. No había cosa que más rabia me diese que tardase poco en encontrarlo, parecía que no le habías puesto interés.

En aquellas primeras épocas programar lo que se dice programar si que sabia, se me daba muy bien, sacaba muy buenas notas en la universidad en las asignaturas de programación. De lo que no tenia ni idea era de trabajar. Es decir de programar en serio, no para una práctica. Bueno el sueldo también iba en consonancia. Por eso me parece importante compartir las experiencias vividas. Es importante «aprovecharse» de los que han recorrido ya antes el camino.

Cuando mas tarde empecé a tener compañeros a mi cargo, he de reconocer que tuve mucha suerte, porque eran muy serias trabajando, les solía decir que había unos errores que no les debía encontrar nunca. Las pruebas básicas, las que alguien sin conocer la aplicación puede realizar.

– Obligatorios: coges cada campo que está marcado como obligatorio, lo borras y le das a buscar, guardar o lo que proceda. Uno a uno y todos juntos.
– Longitudes: coges cada campo y pones el valor máximo. Si es numero todo 9 hasta que no te deje meter más. Si es texto pones una letra, por ejemplo la a, hasta que no te deje poner más y luego dar a buscar, guardar o lo que proceda.
– Formatos: clásico, si es un campo numérico poner letras. Si es un email poner uno inválido, y luego dar a buscar, guardar o lo que proceda.

Estas pruebas como he comentado no las puedes fallar, da una sensación muy mala si el programa falla en cosas como estas. Y creerme, es muy habitual encontrar fallos de estos.

No se quien me comentó que había tenido un jefe que probaba los programas dando teclas sin sentido, casi como lo pudiera hacer un mono. Y conseguía hacer cascar los programas, y el programador de turno se defendía diciendo que no era un uso normal de la aplicación, pero el jefe le contestaba que le daba igual, la aplicación había fallado y no podía fallar.

Muchas veces, por lo menos, a mi me pasaba, que iba probando el programa y corrigiendo errores y cuando ya lo daba por terminado lo entregaba. Como en el anuncio de la tele: ERROR. Cuando creas que lo tienes todo terminado, haz una última prueba global, no sea que hayas arreglado algo y roto otra cosa. Cosa que sucede a menudo.

Hoy día hay técnicas y herramientas para automatizar ciertas pruebas, pero antaño no y cada vez que te encontraban un error y cambiabas el programa las jefas tenían que volver a probar todo y entiendo que se enfadasen porque era un autentico peñazo (Cuando me ha tocado a mi estar en la situación de probador en vez de siendo el probado me he dado cuenta).

Además hay que tener en cuenta una cosa que se nos suele olvidar muchas veces, la «tela». El coste de un analista es mayor que el de un programador. Así que es más barato dedicar un poco más de tiempo del programador para que esté todo mejor probado a entregar algo poco probado y que el analista tenga que dedicar tiempo una y otra vez a probar. Y lo que nos interesa a todos es hacer las cosas lo más económicamente posible, manteniendo los criterios de calidad que se exigen.

A los programadores que he tenido a mi cargo siempre les he dicho que si necesitan más tiempo que lo pidan, siempre que puedan justificar el desvío, pero que no entreguen algo sin probar bien por cumplir las fechas.

Te has esforzado mucho en realizar tu trabajo y luego corres el riesgo de por tonterías dar la sensación de que has hecho un trabajo a la ligera. No es interesante.

Gestión del conocimiento, que gran concepto y cuan difícil de hacer funcionar. De todos los sitios en los que he estado solo funcionaba realmente bien en uno de ellos, a pesar de que el programa que se utilizaba era horrendo, probablemente funcionaba porque era un proyecto muy grande y muy exigente y la gestión del conocimiento era una necesidad.

El objeto de la gestión del conocimiento es el compartir entre todos los integrantes del equipo o de la empresa las mejores prácticas en el trabajo, los trucos, etc, de tal forma que poco a poco se vaya mejorando la calidad del trabajo que se realiza. Es una parte importante de la industrialización del desarrollo, ya que ayuda a que fluya la información en el equipo.

Hay una serie de características que considero son importantes para que la gestión del conocimiento funcione correctamente:

– Facilidad de búsqueda de la información.

La gestión del conocimiento en email o en documentos ofimáticos compartidos en una carpeta de red no suele funcionar bien, ya que suele ser difícil de encontrar el contenido que queremos. Suele funcionar mejor el empleo de Wikis o herramientas de trabajo en grupo, que suelen proporcionar búsquedas por texto libre más eficientes y la posibilidad de clasificar los contenidos para poder realizar una búsqueda más precisa que con la simple búsqueda por texto libre.

Yo suelo utilizar tres ejes de catalogación:

• Cliente
• Tecnología
• Tipo de contenido

– Facilidad de creación de la información.

Cuanto más sencillo sea el poder crear los documentos más fácil será que la gente colabore. Los Wikis suelen llevar una codificación que, aunque más complejo que un documento ofimático, no suele ser excesivamente compleja.

– Hacer participar al equipo

Esta parte es la más complicada de todas. Me he encontrado con varios tipos de actitudes entre los compañeros:

• Los entusiastas que colaboran, que suelen ser los menos, y al final se cansan de solo escribir ellos.
• Los entusiastas que no colaboran, con una actitud de que me cuenten cosas, pero yo no cuento.
• Los neutrales, que ni les va ni les viene.
• Los críticos, estos suelen ser los menos, normalmente es alguien que pierde privilegios o notoriedad.

Es muy importante hacer partícipe a todos los compañeros en la gestión del conocimiento y la mejor manera es reconociendo el mérito y propiciando que se introduzcan contenidos en el gestor. El merito puede ser algo a tener en cuenta en las evaluaciones anuales.

Muchas veces hay compañeros que hacen pequeños documentos que los mueve entre un circulo reducido. Estos documentos hay que propiciar que si hace falta se completen y se pongan en el gestor.

También suele haber situaciones en las que algún compañero pregunta alguna duda, si se ve que esa duda no está resuelta en el gestor de conocimiento y es interesante que esté, se puede dedicar un poco de tiempo a añadirlo, como digo siempre, sin que esto afecte a los compromisos adquiridos.

– Velar por la coherencia

Uno de los problemas de la gestión de contenidos es que se puede convertir en una amalgama de textos sin sentido. Es por ello que es importante que exista la figura del editor, que verifique, de coherencia y oficialice los contenidos introducidos.

En mi vida profesional he estado en varias empresas que querían o necesitaban crecer. No me refiero solo a crecer de tamaño, sino sobre todo crecer en la importancia de los proyectos que realizaba. Pasar de proyecto pequeños, relativamente auxiliares para los clientes, a proyectos más grandes y más críticos (y consiguientemente con más exigencia). En varios casos los objetivos no se cumplieron y las cosas acabaron como el rosario de la aurora.

En uno de estos sitios un jefe me hizo un símil con los equipos de fútbol. Del club que va haciendo bien las cosas y va subiendo de categoría. Según el en cada subida de categoría había que ir desprendiéndose de los jugadores que no tenían nivel para la nueva categoría. No todos valen para jugar en primera.

Yo no voy a ser tan drástico, de decir que hay que despedir a toda la plantilla, pero si que creo que hay que adecuar, tanto el equipo humano, como los métodos de trabajo y los medios materiales a los nuevos requisitos.

Lo que si que me he encontrado en, desgraciadamente, demasiadas ocasiones es que los compañeros no son capaces de asimilar esa nueva situación y lo que implica. Siguen con sus niveles de exigencia habituales, sin darse cuenta que no se adaptan a los niveles de los nuevos proyectos.

Y probablemente por parte de la jefatura, bien de la empresa, bien del proyecto, en esos casos no se fue capaz de hacer ver al equipo que si se seguía por el mismo camino, que efectivamente había venido siendo suficiente, con los nuevos niveles de exigencia, se corría el riesgo de fracasar, como así fue en varios casos.

Me parece de vital importancia el trasladar al equipo de trabajo cuales son los requisitos que se nos va a exigir por cada nuevo cliente o nuevo proyecto, para que todo el mundo, por lo menos sea consciente de por que rasero se les va a medir.

Creo que esto es, cuanto menos, algo menos dramático que el cambio de equipo humano, que es la siguiente opción, bueno o directamente el fracaso colectivo.

Este planteamiento creo que encaja bastante bien con todos los temas de marcas personales o tu modelo de negocio, que se está teniendo cierto auge, sobre todo con la crisis actual, que ha obligado a mucha gente a salir de su zona de confort y tener que replantearse su vida, por lo menos la profesional.