archivo

Archivo de la etiqueta: Tecnología

El premio Nobel de medicina en 1937, el húngaro Albert Szent-Györgyi, tiene una cita que habla de descubrimiento, pero que realmente encierra tras ella, la clave de lo que resulta realmente la innovación: “El descubrimiento consiste en ver lo que todo el mundo ha visto y pensar lo que nadie más ha pensado”.

Muchas veces vemos un app nueva para dispositivos móviles, un producto software, una idea materializada que triunfa y que provoca que irremediablemente nos hagamos la pregunta de: ¿cómo es posible que no se me hubiera ocurrido a mi?.

Y es que esto funciona así, no basta solo con observar, se trata de interpretar lo que ves y tratar de llegar más allá. Es cierto que muchas veces se alcanza ese punto y lo que sucede es que no se termina materializando o se llega demasiado tarde porque ten en cuenta que no eres, ni mucho menos, el único gallo de este corral.

No siempre vamos a tener la oportunidad de trabajar con tecnologías conocidas, pese a que siempre que sea posible resulta lo más recomendable ya que siempre será más fácil ofrecer resultados de calidad si estamos cualificados y experimentados en una determinada materia.

Sin embargo, puede resultar interesante aceptar determinados tipos de trabajos, ya sea porque el cliente y/o por la tecnología.

Ante esta situación se plantea la cuestión de cómo llevar a cabo la formación del equipo de personas que va a trabajar en el proyecto (o incluso ampliarlo a otras, aunque en principio no vayan a trabajar en él).

Este antipatrón hace referencia a determinadas malas prácticas que se realizan en este contexto (como he comentado, en algún artículo, como por ejemplo, “Desarrollo de software. Buenas prácticas y antipatrones“, lo que puede resultar algo positivo o negativo en general puede resultar todo lo contrario en una circunstancia determinada, lo importante es tener en cuenta esta información que procede de la experiencia y analizar si en tu contexto resulta adecuada o no):

– Contratar una formación sin haber precisado con cierta exactitud la materia sobre la que se desea la misma. Esto puede provocar que la formación no se enfoque de manera adecuada, tratando aspectos que no son necesarios en el proyecto o dejando fuera aspectos fundamentales.

– Contratar una formación sin tener referencias del formador, ya que lo mismo su nivel de conocimiento no es el adecuado a la naturaleza de la formación a impartir.

– Formar al equipo de proyecto completo de una sola vez.

Sobre esta última mala práctica se considera que lo ideal es formar a a pocos miembros del equipo y que estos sean los que trasladen la formación al resto de componentes.

Hacer predicciones y acertar sobre prácticamente cualquier sector es ciertamente complicado. Si fuera fácil todos alcanzarían el éxito constantemente y no es así.

En un mundo como el de la tecnología que cambia de manera vertiginosa, donde desde cualquier sitio puede aparecer un software o un hardware revolucionario, las predicciones son, si cabe, todavía más complicadas de hacerse realidad.

Ahora bien, Alan Kay, probablemente basado en la experiencia de las empresas en la que ha trabajado y en la labor desarrollada en las mismas (centrado fundamentalmente en la investigación y el desarrollo), realiza una reflexión muy interesante para todos aquellos que quieran hacer realidad sus expectativas: “La mejor manera de predecir el futuro es inventarlo”.

Scott Guthrie es vicepresidente de la división de desarrollo de Microsoft, algo que tiene bastante mérito para una persona que tiene en la actualidad 36 años. Además fue, junto a Mark Anders, el creador de ASP.NET.

Guthrie, realiza la siguiente reflexión (traducción libre):” Los programadores por naturaleza están enamorados de la tecnología. Esto es una fortaleza cuando se abandonan viejas, ineficientes soluciones y se adoptan otras nuevas que son más eficientes. Sin embargo es una debilidad cuando las nuevas herramientas software llegan más rápido que nuestra capacidad de utilizarlas efectivamente y perdemos demasiado tiempo en el lado equivocado de sus curvas de aprendizaje”.

¿Es esta visión incompatible con ser un early adopter? No siempre y cuando, la elección de la tecnología sea correcta y se haga con cabeza. Adoptar nuevas tecnologías en el desarrollo de software sin un plan lleva consigo mucho riesgo (no se puede entrar un carrusel sin sentido de aprendizaje de nuevas tecnologías), como también lo es quedarse estancado en el uso de determinadas soluciones obviando la aparición de otras que pueden proporcionar una ventaja competitiva y unos mejores resultados en los proyectos.

Considero importante que los desarrolladores de una organización sean especialistas en la tecnología utilizada mayoritariamente en los proyectos en los que participa la misma, ya que les permitirá ser más eficientes, productivos y obtener software de más calidad, por ese motivo la irrupción de nuevas soluciones debe ser controlada y hacerse desde la perspectiva del beneficio que proporciona la nueva tecnología, para ello se ha debido reflexionar previamente sobre sus pros y sus contras y en algunos casos sería recomendable incluso realizar proyectos piloto para calibrar su impacto.

Lewis D. Eigen es autor, articulista, con experiencia docente y de investigación en el ámbito universitario y también como consultor y responsable de empresas en el ámbito privado.

Este autor realiza la siguiente reflexión la cual, desde mi punto de vista, es cada vez es más real, independientemente de que sintamos o no que esa división existe o que le demos una visión más o menos conspiranoica: “Los trabajadores y profesionales del mundo pronto se dividirán en dos grupos. Aquellos que controlarán los ordenadores y aquellos que serán controlados por ordenadores. Lo mejor para ti será estar en el grupo adecuado”.

Tanto si tienes externalizadas las tareas de programación, como si no o tu empresa se dedica al desarrollo de software, resulta esencial la existencia de un libro blanco de desarrollo que marque una línea tecnológica y de arquitectura para los sistemas de información.

De esta forma el desarrollo de los proyectos es homogéneo y facilita las tareas de mantenimiento. Además, supone un ahorro de costes, ya que el desarrollo bajo un paraguas común facilita la existencia de un framework y de una colección de componentes estable.

El libro blanco de desarrollo supone también una métrica cualitativa de medida de la calidad de los desarrollos en cuento a lo que a tecnología y arquitectura se refiere, algo que resulta fundamental.

El libro blanco de desarrollo debe centrarse en la selección de buenas prácticas, tecnologías, patrones y arquitecturas para el desarrollo de software para cada uno de los paradigmas de sistemas de información en los que se desarrolle. El libro blanco debe marcar un camino y digo camino y no línea, ya que es recomendable ser flexible para determinadas soluciones, dando la posibilidad de utilizar distintas alternativas. Además debe huir de soluciones “propietarias” (en el sentido de que sean soluciones particulares de una empresa en cuestión) a nivel de framework y adoptar componentes que resuelvan problemáticas funcionales recurrentes sean o no “propietarios” en el sentido indicado anteriormente.

Evidentemente si trabajas en una empresa de desarrollo de software debes desarrollar según las directrices tecnológicas que te marque el cliente, pero en el caso de desarrollos internos, desarrollos I+D o desarrollos para clientes que no te marquen una directriz tecnológica sí que resulta muy interesante el uso de un libro blanco de desarrollo.

Otros aspectos importantes que debe cubrir un libro blanco debe ser la organización del software y el procedimiento de entregas, es decir, qué sistema de control de versiones utilizar, cómo utilizarlo, cuál debe ser la política de etiquetado, qué solución utilizar para automatizar la realización de pruebas unitarias, despliegues, cuál es la política a seguir para el paso a pruebas y/o producción del sistema, etc…

Como se puede apreciar, un libro blanco de desarrollo bien hecho, no está al alcance de cualquiera, de hecho se escapa, en mi caso, varios millones de leguas de mi capacidad técnica. La persona o personas que lo realicen deben tener un gran conocimiento de arquitecturas y tecnologías software, estar muy al día de todas ellas y tener una gran experiencia en el desarrollo y gestión de proyectos de desarrollo de software.