Categoría: Marca Personal & Carrera

El otro día una amiga y compañera de trabajo me comentó que escribía cosas muy raras aquí. Esta entrada no le va a defraudar…

A veces es curioso el mecanismo que tiene el cerebro para asociar ideas. Resulta que estaba buscando por Internet información sobre productos de «grooming», vamos el aseo personal de toda la vida, ya que aparte del tema del afeitado, tengo un problema para encontrar un desodorante que no me irrite la piel, sea efectivo y no me destroce las camisas.

Acabé en el web de Lóccitane . No he probado todavía ninguno de sus productos, pero me gustó el planteamiento que exponen. Viene a ser un preferimos productos naturales, pero en algunos casos como no hay un equivalente natural de calidad, usamos productos sintéticos. Digamos que un naturismo/ecologismo práctico.

Eso me hizo recordar una vez, al principio de mi carrera profesional, que tuve el privilegio de tener una entrevista, casi una clase particular, con uno de los profesionales de la zona más respetados en la selección de personal.

Me comentó muchas cosas, una de ellas es que había que intentar ser lo más normal del mundo, y concretamente me dijo que nada de enviar los curriculums en papel reciclado, porque corría el riesgo de que el destinatario se pensase que era un ecologista que le iba a andar luego con que la moqueta de la oficina no era ecológica y cosas de esas.

Este planteamiento va en contra de los planteamientos de marca personal, de diferenciarse para aportar valor y no ser un profesional de marca blanca.

Los curriculums contestan a tres preguntas (Esto también me lo contó el):

• Quien soy, es decir mis datos personales.
• Que se, es decir mi formación académica y no académica.
• Que he hecho, es decir los trabajos y las tareas que he realizado.

Suelo seguir a Andrés Pérez Ortega, me parece que tiene ideas interesantes, algunas un poco radicales, pero que te hacen replantearte tus ideas y mejorarlas u otras veces simplemente reafirmarte.

Así que estaba leyendo una entrada en su blog sobre el decir lo que piensas y me ha venido automáticamente a la mente una serie de situaciones que he vivido de seguidismo tecnológico.

Esto de la arquitectura de aplicaciones web va por modas. Por ejemplo con EJB, que era la solución a infinitos problemas. Yo he desarrollado algún proyecto con EJB, en las que no usábamos nada de lo que proporcionaba los EJB, eso si pagamos el sobrecoste en comunicaciones y en velocidad de desarrollo (eran tiempos en los que no existía el debug en remoto).

Tres cuartos de lo mismo con los servicios SOA o el JPA o etc…

No es que sean malas herramientas o especificaciones, el problema suele venir cuando se utilizan para cosas que no son.

Creo que es labor de un arquitecto el pensar muy bien que necesidades reales tiene el proyecto a corto y medio plazo. Hacer una lista y ver que herramientas o tecnologías son las necesarias. La arquitectura tiene mucho de pensar y buscar, buscar y pensar.

Aveces nos ofuscamos con pensar a muy largo plazo, que es una excusa perfecta para justificar grandes inversiones en tecnología, y no nos damos cuenta que lo más probable es que ese planteamiento suponga un gasto real a corto, pero un incierto rendimiento económico a largo plazo.

Como se comenta en la programación extrema lo más probable es que cuando llegues a necesitar esa flexibilidad, si es que la necesitas, probablemente hayas aprendido cosas y seas capaz de hacerlo de mejor forma que la que lo harías hoy.

Son pensamientos que van muy en la línea de mantener las cosas sencillas

Las empresas y los proyectos software no son sistemas democráticos, son más bien jerárquicos, más o menos rígidos. Es una estructura de delegación. Sobre todo en proyectos grandes y muy industrializados. Cada persona tiene una responsabilidad sobre la que se le va a exigir y sobre la que tiene autoridad. Cuantas más responsabilidades tienes, normalmente más necesidad tienes de delegar ciertas tareas o áreas en otras personas.

En esta entrada quiero hablar sobre la defensa de esa jerarquía. A veces te encuentras con problemas o divergencias con compañeros, vamos a poner por ejemplo un programador, que se quejan de, vamos a poner su analista (o superior o responsable o jefe o supervisor o …) y recurren a ti como, vamos a poner jefe de proyecto (o superior de su superior).

Puede ser que tu opinión concuerde con el criterio del analista, con lo que lo que haces es refrendarlo. Pero puede ser que no coincida.

Esta situación puede ser delicada ya que se puede entender como un cuestionamiento del criterio del analista.

El problema viene porque si socabas la autoridad o criterio de ese analista puedes encontrarte con que lo anulas, ya que el programador ve que el jefe de proyecto no respalda al analista, con lo que cada vez el programador se siente con más libertad para no seguir los criterios del analista, pensando que cuando se monte lío, recurrirán al jefe de proyecto y este le dará la razón.

Siempre que he me he encontrado en una situación de estas he procurado no socabar el criterio o autoridad, ya que eso se acabaría volviendo en mi contra. Pero tampoco refrendando al analista incondicionalmente.

He estado en alguna situación rocambolesca en la que he sido yo el que ha estado en medio, no siendo respaldado por mi jefe, y lo más curioso es el motivo, por un afán de mi jefe de ir de colega con los programadores… Menos mal que mi jefe a su vez tenia un jefe que puso un poco de cordura.

Hay que tener mucho tacto en este tipo de situaciones, en las que se pone en cuestión la jerarquía.

Uno de los principales factores para que un proyecto vaya bien es el factor humano. La industrialización del desarrollo de software se puede apoyar en herramientas y procedimiento o normativas, pero al final lo que marca la diferencia es la gente.

Hay metodologías como el scrum que propugnan el crear equipos pequeños y darles libertad, pero anteponen una condición que me parece sustancial: ten gente buena.

Ahí es donde creo que radica la cuestión. Si tienes gente buena las cosas suelen salir bien sin mucho esfuerzo, sino es mucho más complicado. El problema es que normalmente todo el mundo cree que es buena en lo suyo. Otra cosa es que lo sea.

Soy un ferviente defensor del dar libertad a los compañeros, pero con criterio. Es decir, dar el grado de libertad que cada uno pueda asumir sin pegarse un batacazo grande. Pequeños sustillos controlados no está mal que se lleve la gente, así ven donde están sus límites y van ampliando progresivamente su zona de confort.

Yo he estado en creo que casi todas las situaciones. Tanto en las de dar libertad a compañeros bajo mi responsabilidad, tanto compañeros competentes como no competentes. Y por supuesto he tenido jefes que me han dado más o menos libertad.

Alguno no sabia delegar y te daba muy poca cuerda y otros si que sabían delegar y valoraban bien las posibilidades que les podía aportar, así que lo único que hacían era supervisar que no me pegase un castañazo muy grande. También tuve un jefe que tenia un curioso concepto de lo que era un pequeño sustillo… mejor no pensar que sería para el un gran susto…

Estamos en una época en la que el método Lean, directa o indirectamente, está a la orden del día, ya que hay que reducir gastos superfluos y centrarse en generar valor.

Hay una cosa que desde hace mucho tiempo me parece, en general, una pérdida de tiempo. Son las típicas reuniones en el cliente, en las que dedicas más tiempo en ir y volver que en la propia reunión, sobre todo para reuniones rutinarias. No me refiero a las reuniones en las que el cliente te quiere tener delante para metafóricamente partirte la cara.

Además el hecho de no dedicar tiempo a viajes te facilita que puedas incorporar a más personas a la reunión, personas que de otra manera no hubiesen asistido, porque significa duplicar el costo en horas improductivas.

En una empresa en la que trabajé pedí que comprasen un manos libres en condiciones, no el típico teléfono con función de manos libres, en el que tienes que estar acercándote al aparato para que te escuchen y que tu no escuchas a los otros del todo bien.

La verdad es que el aparato se escuchaba estupendamente y los otros también nos escuchaban muy bien. Era una comodidad y por un precio que para una empresa no es descabellado. En una docena de viajes que te ahorres ya lo has amortizado. En concreto era un Polycom SoundStation 2

Además para los clientes que venían a la oficina daba una cierta imagen de disposición de medios. Y esto también es importante.

Desde entonces a todos los sitios que voy a trabajar recomiendo el tener un buen manos libres.

Estaba leyendo el libro Negociar es fácil si sabe como, cuando me he encontrado con una reflexión que me ha parecido muy acertada, sobre todo para la gente que es reacia a dejar las cosas por escrito, como normativas, guías, etc.

«Moises no descendió del monte Sinaí con las manos en los bolsillo a contarnos los diez mandamientos. Los llevó escritos en las tablas sagradas.»

Esto me parece importante, sobre todo cuando te dedicas a temas como la industrialización del desarrollo del software o a la arquitectura de aplicaciones web. Ambas son cosas importantes porque fijan los criterios de todo un proyecto o toda una empresa. Estas cosas deben quedar por escrito en un lugar accesible, sino como dice la sabiduría popular, las palabras se las lleva el viento. De esta parte de la accesibilidad ya he hablado en la entrada sobre gestión del conocimiento.

Una vez que tienes razonablemente controlado que la aplicación hace lo que tiene que hacer el siguiente paso es un poco más complicado.

La aplicación que tienes que reconducir cuando tiene que grabar lo hace correctamente, pero y cuando tienen que grabar 100 a la vez, ¿aguanta la carga funcionando bien?

Este debiera de ser el segundo punto en tu lista de objetivos. Pero es un punto delicado. Automatizar todo tu plan de pruebas para ver que la aplicación soporta la carga y que bajo esa carga funciona correctamente, puede consumirte mucho tiempo. Además probablemente te requiera de infraestructura para ejecutar esas pruebas.

Debieras de valorar si te merece la pena o por el contrario te conviene el dedicarte a arreglar otras áreas en las que puedas obtener una mejora más rápidamente.

En esta fase, puedes recurrir a herramientas como JMeter, JUnit o Selenium.

Cuando te dedicas a estos temas de la industrialización del desarrollo de software y temas de arquitectura de aplicaciones web, normalmente sueles elaborar muchas guías, procedimientos o en general «cosas» que se entienden como normativas. Algo que me obligan a cumplir.

Recuerdo que cuando implantamos el CMMI en una empresa en la que trabajé, el auditor me llamó para preguntarme sobre el repositorio de código. Me preguntó si teníamos algún criterio fijado de como utilizarlo. Le dije que no, que era la realidad, cada jefe de proyecto se lo gestionaba como quería. Me dijo muy respetuosamente que eso no podía ser, que debíamos juntarnos y decidir un criterio, luego plasmarlo en un documento y a partir de ahí seguir ese criterio.

Creo que esa es la actitud que se debe de tener con respecto a las normativas. Nadie, o por lo menos en mi caso, va a trabajar pensando en como va a hacer la vida más difícil a sus compañeros. Hay que buscar la forma de trabajo más efectiva, documentarla y a partir de ahí seguirla.

Las normativas deben responder a una forma de organizar el trabajo teniendo una visión completa de todo el proceso. Igual un compañero no entiende porque se le pide hacer algo, que probablemente le parezca una pérdida de tiempo, pero normalmente está ahí por algo. Probablemente porque esa información se necesite en un paso posterior que el no realiza. Y si sobra, ya se valorará el modificarlo, pero eso no debe ser escusa para saltárselo. Las cosas que hoy son adecuadas puede que no lo sean dentro de un tiempo. Pero hay que cumplir los compromisos, la anarquía suele llevarse mal con la eficiencia, y a todos nos interesa hacer las cosas lo más eficientemente posible.

En esta entrada quiero hablar sobre los problemas que podemos encontrar a la hora de industrializar el desarrollo de software, sobre todo cuando estás en un entorno de una subcontrata.

El industrializar el desarrollo de software ya es de por si complicado ya que, a diferencia de otros sectores donde hay más estabilidad, en el de la informática las cosas cambian con mucha rapidez.

Yo sigo usando un coche de hace 10 años, una cocina de no recuerdo cuanto tiempo, etc.

En cambio por ejemplo la raspberryPi (un ordenador del tamaño de una tarjeta de crédito) se considera que tiene una potencia equivalente a un ordenador de hace 10 años. Un ordenador de hace 10 años tiene problemas para mover simplemente las webs de hoy día.

Luego si nos introducimos en el mundo Java la cosa se complica todavía más, porque cada cliente tiene una combinación de herramientas diferentes. En casi quince años he trabajado con servidores de aplicaciones tales como: Java Web Server, JRun, Tomcat, Weblogic, JBoss, WebSphere, Glassfish,…

Esto hace que salvo que trabajes para pocos clientes sea muy complicado el poder definir procedimientos y automatizar cosas. Porque esta procedimentación conlleva un coste de tiempo no menor que hay que diluir entre todos los proyectos.

Aunque solo trabajes para pocos clientes, si eres una subcontrata tampoco tienes control sobre la tecnología, ya que va a ser algo que va a controlar tu cliente. Así que si dedicas esfuerzo a automatizar o procedimientar cosas que controla tu cliente te puedes encontrar que no lo puedes amortizar como tu preveías, porque hay un cambio en el cliente.

Por eso creo que la forma más segura de industrializar el desarrollo de software es hacerlo sobre las cosas que puedes controlar y no tanto las que no dependen de ti.