Jummp’s Blog

Una cosa que he aprendido desde que comencé a trabajar es que la productividad crece si se consiguen introducir períodos de descanso y de desconexión a lo largo del día y de la semana. He tardado mucho en aprender la lección y todavía sigo cayendo en muchas ocasiones en el error de no parar y tener siempre en la cabeza tareas que tengo pendientes de realizar o problemas sobre los que hay que intentar buscar una solución. Cuando esto sucede la culpa es exclusivamente mía, aunque mi profesión dificulte en demasiadas ocasiones el proceso de desconexión.

Es necesario para poder renovar las ideas y para fomentar la creatividad tener períodos de descanso, no puedo dar una fórmula sobre cuando es más apropiado tomar esos descansos, ya que cada persona es un mundo y conoce cuáles son sus límites y cuáles son sus necesidades. Acumular horas y más horas de trabajo sin dedicarnos un mínimo de tiempo, termina tarde o temprano pasando factura y cada vez se es menos productivo debido al cansancio y porque el trabajo cada vez más genera más ansiedad y menos satisfacción.

Es cierto que no siempre somos dueños de nuestro tiempo y que las circunstancias laborales y el entorno pueden provocar que buscar esos oasis de tiempo sea complicado, pero aunque sea difícil necesitamos buscar ese resquicio de aire fresco que proporciona descansar y desconectar, ese oasis permitirá que al ser más productivos y saber valorar mejor el tiempo, se consiga cada vez encontrar con más facilidad ese paréntesis tan necesario para cada uno de nosotros.

La respuesta a muchos problemas que se presentan en el trabajo se resuelven a partir de la creatividad, si ésta se ve anulada por el cansancio quiere decir que no seremos capaces de resolver esos problemas, que los resolveremos peor o que tardaremos más en resolverlo, lo que a su vez genera más trabajo y se cae en un círculo vicioso de difícil salida. Si echar más y más horas no permite salir de esta laberinto, ¿por qué no probar a descansar y desconectar un poco más y ver cuáles son los resultados?.

Dentro del proceso de aprendizaje uno de los factores más importantes son los errores, siempre y cuando se sea consciente y se admita la equivocación (si se ha fallado y no se admite, no se habrá aprendido nada).

De la misma forma que nosotros nos equivocamos (y nos equivocamos todos, algunos con más frecuencia y otros con menos, porque nadie es infalible), tenemos que admitir que los demás, nuestros compañeros, nuestros superiores y las personas que están a nuestro cargo se equivoquen. Evidentemente ni todos los errores son iguales ni tampoco puede haber barra libre, el umbral estará en el impacto del error, en el número de errores previos, la responsabilidad de la persona en el mismo y el puesto que ocupe dentro de la organización.

Siendo conscientes de la existencia de límites si queremos que nuestro equipo de trabajo evolucione, hay que darle la oportunidad de que además de desempeñar su trabajo habitual asuman decisiones, realicen tareas de una complejidad mayor a las que venían realizando y/o efectúen actividades complementarias. Estos saltos, estas salidas de la rutina generarán sin dudas errores y equivocaciones, pero hay que entender que éstos son consecuencia de una evolución normal del personal en la organización y ya es tarea de los responsables de dichas personas impedir el error antes de que se produzca o paliar los efectos si no se detecta a tiempo. Si no se permite esta evolución por miedo a los errores se estará tirando, desde mi punto de vista, piedras contra nuestra propio tejado, ya que la experiencia también se mide en responsabilidades y en vivencias y si nuestro equipo de trabajo no las tiene, está condenado a madurar mucho más lentamente, a acomodarse y a tener menos posibilidades de crecimiento en la organización, ya que se tenderá a buscar en el mercado lo que no se ha podido generar dentro de la misma y en mi opinión debe existir un equilibrio entre los fichajes (muchas veces necesarios y otras porque el mercado permite acceder a un recurso o a unos recursos muy valiosos) y la promoción interna del personal, ya que si los trabajadores ven pocas posibilidades de evolucionar, surgirá desmotivación y una reducción de la productividad, además de una posible marcha de algunos de ellos buscando otras alternativas.

Otro error muy común en el proceso de desarrollo de software (y en el que yo también he caído) es olvidar que el producto que se está implementando no es para nosotros sino para el usuario final e independientemente de que tengamos la sensación de que conozcamos perfectamente lo que quiere el usuario o que dominamos la materia, tenemos que buscar hasta donde sea posible la implicación del usuario, no solo durante el proceso de definición del sistema, sino durante el proceso de construcción.

Si los que nos dedicamos al desarrollo de software, que ya tenemos una cierta experiencia en abstraer problemas, nos encontramos con dificultades en numerosas ocasiones para llevar a un programa de ordenador un determinado proceso y nos damos cuenta muchas veces cuando se está construyendo que hay piezas que no encajan, ¿podemos pedir al usuario que tenga esa misma capacidad de abstracción?, algunos pensaréis: “era obligación del usuario leerse el análisis”, ¿de verdad pensáis que el usuario puede llegar mucho más allá del análisis de requisitos, de la descripción de casos de uso, de la revisión de las interfaces de usuario y su navegación?, salvo que el sistema no sea excesivamente grande, que los entregables que acabo de indicar se realicen de la forma más completa, exacta y clara posible, y que el usuario se esmere en repasarlos (y aún así), quedarán resquicios que cuanto más se tarden en corregir más costosos serán para el desarrollador.

Lo que acabo de comentar en el párrafo anterior no es un vale todo para el usuario, es decir, éste debe asumir su responsabilidad en el proyecto y de alguna u otra forma se lo tenemos que hacer ver. El desarrollo de software no se hace con una pizarra y una tiza, donde se puede borrar y volver a escribir libremente, es un proceso tan complejo en el que no vale la barra libre. Lo que vengo a comentar es que en el desarrollo de software se debe ser consciente de que cuanto más se tarde en detectar un error más vale corregirlo y que los usuarios en la mayoría de los casos no toman conciencia del programa y de los problemas hasta que se enfrentan a él. Como podéis ver se trata prácticamente de dos extremos, de hecho cuanto peor se hagan las cosas (por parte del desarrollador y del usuario (por no hacer frente, este último, a su responsabilidad)) se cumplirán ambos extremos, lo que provocará que el proyecto salga caro (lo cual puede repercutir sobre el usuario o sobre el desarrollador (más bien, sobre este último)) y que la calidad del mismo se vea muy perjudicada.

Por tanto, es importante que no olvidemos que las aplicaciones se desarrollan para los usuarios y que por tanto hay que buscar la mayor implicación posible por parte de los mismos en todo el proceso de desarrollo de software. ¿Qué el usuario no se implica? Hay que intentar que siempre quede patente este hecho (evidentemente hay que saber hacerlo con tacto), ya que más adelante si el proyecto no ha salido como debía y hay que empezar a parchear, que todo el gasto de ese parcheo no repercuta directamente sobre el desarrollador.

Hay un dicho muy utilizado que dice que si algo funciona no hay que tocarlo (muy usado en el mundo del desarrollo de software y con mucho acierto) y puede ser válido en la mayoría de los casos en el mundo de los negocios.

No obstante, el mercado tiene a no permanecer estático ya que su equilibrio depende de un gran número de variables y además ese movimiento puede realizarse a distintas velocidades. Esto implica que si una determinada forma de hacer negocio funciona en un momento concreto del mercado, no tiene por qué funcionar en otro, de manera que si se quiere seguir funcionando con un nivel de éxito similar es necesario adaptarse al mercado (y cuanto antes comience ese proceso de adaptación, por la detección temprana del cambio de marco, menor será el impacto que sufrirá la empresa).

Con el cambio de mercado (y/o de las reglas del juego del mismo) se produce una adaptación de su ecosistema al mismo, en el que los que hayan conseguido evolucionar antes y darse cuenta de las nuevas variables tendrán más posibilidades de tener éxito en este nuevo entorno, los que no evolucionen o evolucionando lo hagan más tarde también tendrán dificultades al existir otras empresas ocupando su hábitat y que se han convertido en tan fuertes o más fuertes que la suya y con las que tendrá que competir para conseguir alimento (negocio).

Un ejemplo de lo que acabo de comentar lo tenemos en Microsoft que no se llegó a subir a tiempo a lo que es Internet y la WWW y tras muchos años y muchísimo dinero invertido sigue sufriendo a día de hoy las consecuencias de su inmovilismo inicial ante el mercado y su ecosistema.

La evolución del mercado crea oportunidades y puede provocar problemas, todo depende de la capacidad de poder predecir sus movimientos, de detectar cuando comiencen a hacerse, de las decisiones que se tomen y de lo que se tarde en aplicarse.

En un mercado tan inestable (ante la continua evolución de la tecnología y la innovación) como es el TIC en general y el desarrollo de software en particular, la capacidad de adaptación resulta esencial para poder sobrevivir. Es cierto que las empresas fuertes, con una red de clientes sólida y solvencia técnica son más estables a estas oscilaciones que las pequeñas, pero nunca deben olvidar por un lado lo que le pasó a Microsoft y por otro de que la competencia con otras empresas fuertes desgastan y que la tendencia de este tipo de empresas es hacerse con todo el negocio posible y que evidentemente el mercado es finito y la parte de su pastel que se coma otro es una parte del pastel que no te comes tú.

Desde hace años tengo la práctica de anotar las tareas que tengo pendientes de realizar y reconozco que a día de hoy no podría trabajar de manera adecuada sin hacer uso de esa técnica.

¿Qué me aporta?

1) Recibo peticiones de diferentes personas y temáticas, las cuales en su mayoría requieren un tiempo moderado para su realización. La anotación de las mismas permite, reducir el riesgo de que se me olvide hacer algunas de las tareas y me permite priorizarlas.

2) Tener las tareas anotadas y poder verlas en su conjunto favorece el proceso de priorización que he comentado en el punto anterior y además simplifica la agrupación de tareas y la reflexión sobre las mismas, lo que permite tomar mejores decisiones sobre las mismas.

3) La anotación de tareas y la señalización de las que están hechas, es un elemento de motivación muy importante.

4) Disminución del tráfico mental. Si tengo la tarea anotada, disminuye o desaparece la necesidad (sensación) de tener que recordar que hay que hacerla, ya que si se olvida está registrada en un sitio que voy a mirar seguro.

Me he referido en este post a lo que es el hecho de anotar las tareas sin indicar qué instrumento utilizar para realizar dichas anotaciones, ya que entiendo que lo importante es el hecho de la anotación en sí, por encima de la herramienta que se utilice, aunque el uso de una herramienta adecuada puede hacer todavía más productivo si cabe el proceso de la anotación de tareas.

En mi caso utilizo un método un tanto rudimentario, como es un cuaderno. He hecho algunas pruebas con algún software pero no han sido positivas por falta de disciplina por mi parte, ya que como me muevo mucho, me resulta mucho más cómodo anotar las tareas en mi cuaderno y no tener que trascribirlas a continuación a una aplicación. En cualquier caso reconozco que tengo que evolucionar en este sentido e ir más allá al uso del cuaderno, pero independientemente de eso, también tengo que reconocer que desde hace mucho tiempo, el uso del cuaderno me ha traído muy buenos resultados.

Otro aspecto que considero también importante es el repaso semanal de las tareas pendientes, ya que favorece esa visión global de las tareas que comenté anteriormente y por consiguiente ayuda a la priorización, agrupación y reflexión sobre las mismas.

Ya nos pasó a todos cuando estudiábamos. Cuando más conseguíamos rendir era en los días previos a los exámenes. Muchas veces ese sprint final permitía que llegásemos al aprobado o consiguiéramos mejores notas, pero si se dejaba todo en manos de ese último impulso podría ocurrir que no diera tiempo de estudiarnos todo el temario con la suficiente profundidad y suspender (o no sacar la nota que nos habíamos marcado como objetivo).

Los seres humanos somos así, la cercanía del momento decisivo hace que nos pongamos las pilas y empecemos a rendir con el nivel que hubiéramos deseado desde el principio.

En el proceso de desarrollo de software se repite, como no podría ser de otra forma, esta máxima, normalmente la proximidad de una fecha de entrega mejora el rendimiento y productividad del equipo (por regla general, también la cantidad de tiempo que se dedica al proyecto, empujado por la necesidad de querer cumplir los plazos). También es cierto que la mala evaluación de las fechas de entrega, siendo demasiado exigentes en muchos casos, obliga en gran cantidad de ocasiones a hacer este sprint final por mucho que se apriete o se mantenga un nivel alto de rendimiento en todo el proyecto.

Por tanto, el sprint final va a ser necesario en la mayoría de los proyectos de desarrollo de software (esos famosos picos de trabajo), que va a durar más cuanto peor esté estimado el proyecto en tiempo y/o recursos (picos de trabajo continuos (y que darán lugar además de tener quemado al equipo del proyecto a una merma en la calidad del producto y a un más que probable retraso en la entrega)) pero que en cualquier caso es necesario mantener un ritmo constante para terminar el proyecto en fecha, ya que si no se ha avanzado lo suficiente antes del sprint final será muy complicado que se puedan cumplir los plazos con un nivel de calidad aceptable.

Pero necesario.

Si tienes un puesto de responsabilidad y la carga de trabajo es superior a lo que puedes soportar y/o rompe el equilibrio que te permite hacer tu trabajo correctamente, es necesario delegar.

Delegar supone dar responsabilidades y confiar en el trabajo de la persona en quien se delega (importante es que la empresa u organización en la que trabaja te de medios para poder delegar, es decir, en primer lugar recursos humanos suficientes y en segundo lugar recursos humanos que respondan), delegar no es llevar un control exhaustivo de la persona en quien se delega, porque de lo contrario no se consigue el objetivo que se persigue con la delegación de responsabilidades que es principalmente tener más tiempo para desempeñar otras, tan importantes o más que la que has delegado.

Creo en las aplicaciones beta en producción, la web 2.0 ha demostrado que se pueden tener productos accesibles al ciudadano de muy buena calidad en fase beta.

Eso sí, creo en las betas con calidad, en betas que funcionan aunque tengan alguna funcionalidad que todavía quede por implementar o incidencias que haya que corregir, pero que unas u otras no impidan un desempeño eficiente del usuario con la aplicación.

No hay que confundir las betas con las famosas versiones 0. Cuidado con las entregas de aplicaciones basadas en el concepto de versión 0 que consiste en: “ahí te entrego el producto, le faltan funcionalidades, no es robusto (estas dos cosas evidentemente no te la dicen), y…, este…. funciona”. Cuando la aplicación empieza a hacer aguas y te diriges a quien lo ha desarrollado para solicitar cambios y la corrección de las incidencias, ya te están poniendo el cazo, para la versión 1 o la 0.5.

Atacar directamente a un modelo de datos de otra aplicación incrementa el grado de acoplamiento entre sistemas y cuando este modelo se extiende a la mayoría de sistemas de información de una organización, se entiende que está implantado lo que se denomina modelo en spaghetti.

La teoría dice que hay que intentar reducir al mínimo el nivel de acoplamiento y que una de las posibilidades para reducirla se encuentra en el uso de APIs que utilizarán la tecnología que se elija en cada caso para suministrarle a una aplicación la información que necesita de otra.

Hasta ahí todo bien y estoy de acuerdo. La reducción del nivel de acoplamiento minimiza impactos en terceras aplicaciones que consumen o graban datos ya que si se conserva el API (los cambios son internos (principio de caja negra)) las aplicaciones que hacen uso del mismo no se enteran.

Me considero bastante ortodoxo (muy teórico) en el desempeño de mi labor profesional y en consecuencia eso se traduce en muchas de las decisiones que tomo, que como ya he dicho muchas veces en este blog, a veces son acertadas y otras equivocadas, ya que la teoría no vale para todos los casos o bien porque la teoría no se ha aplicado o interpretado correctamente. Lo que me enseñaron en la facultad era teoría (por muchas prácticas que tuvieran las asignaturas) y es lo que aplico, aunque afortunadamente la experiencia y tropezarse contra muchas piedras (alguna de ellas más de una vez) permite que donde han habido errores intente abordar el problema de otra manera.

En el asunto de las API podemos realizar la siguiente clasificación: las APIs que se utilizan porque no hay otra forma de obtener/grabar información en otro sistema (es decir, aquellas en las que no tenemos acceso al modelo de datos) y aquellas que se ponen por encima de un modelo de datos al que sí podemos acceder. En el primer caso, no hay más remedio que utilizar el API. En el segundo tenemos la posibilidad de elegir y si tenemos la posibilidad de elegir no hay que caer (yo he caído), en el error de aplicar la teoría a rajatabla y si el API no está bien construido o no es lo suficientemente eficiente, utilizar el API por narices. Si el API original está en nuestra manos mejorarlo y en un tiempo razonable sí que puede ser solución continuar con su uso, en caso contrario yo recomiendo una implementación alternativa o atacar directamente al modelo de datos, ya que lo primero es que las aplicaciones funcionen de forma eficiente y con usabilidad para el usuario, la ortodoxia viene después.

No es este un post en contra del uso de APIs, en absoluto, antes al contrario, ya he comentado que estoy totalmente de acuerdo con su uso (y que en ocasiones no hay otro medio para acceder/grabar la información) y en sus fundamentos teóricos, lo que quiero decir con este artículo esta expresado al final del párrafo anterior: lo primero, el usuario.

Este término lo podréis encontrar en muchísimos libros.

La diferencia muchas veces entre un trabajo correcto y un trabajo excelente está en dedicarle esa porción de tiempo de más (la milla extra) para cuidar los detalles y minimizar el número de errores.

En mi opinión la diferencia no está solo en el talento, sino en las personas y organizaciones que son capaces de aplicar esta milla extra, ese factor diferencial que permite llegar más allá en el trabajo (en volumen y calidad) y/o en la evolución personal (autoformación).

La milla extra supone un esfuerzo, supone ir más allá del trabajo convencional. Esto implica un sacrificio, ya que estás cambiando tiempo libre por tiempo que estás dedicando a una ocupación. No obstante, esa milla extra es la que marca la diferencia, la que te permite subir escalones más deprisa y la que sin duda te devolverá con creces todo ese esfuerzo y sacrificio de más que has invertido.