Autor: ecardenas

Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (IV)

Posted on by ecardenas

Pues si, como fue prometido, ya va tocando meternos con el modelo de Builds, pero antes de proseguir respondamos la pregunta que deje en el post anterior, ¿en que parte de la solución estoy grabando los parámetros de conexión a la BD? pues en el archivo PartsUnlimitedWebsite.pubxml ya que es ahí donde el wizard de deploy guardo los datos de la cadena de conexión a pesar de que al final no sobrescribió los valores del web.config, nos corresponde editar las secciones de dicho archivo a fin de que no persistan los valores dentro de nuestra solución.

Curiosamente, debemos agregar este archivo a nuestra solución, para lo cual hacemos clic derecho y ya formara parte de lo gestionado por VSO, ojo esto solo funciona si hemos editado adecuadamente nuestro archivo .gitignore como ya hemos explicado en el segundo post de esta serie.

Clipboard27
Bueno, ahora si, subamos el cambio y volvamos a nuestro Team Project en Visual Studio Online, dirigiéndonos a la zona de BUILD, de momento estará vacía.Clipboard28
Posicionados sobre la zona que dice «Build definitions» (nótese que aparte tenemos una zona correspondiente a las XAML definitions) y presionamos el «+», nos saldrá la siguiente pantalla:Clipboard29
Finish Reading: Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (IV)

Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (III)

Posted on by ecardenas

Bueno, luego de una pausa, proseguimos con esta serie de artículos para establecer un escenario completo de despliegue usando el nuevo modelo de Builds que traen tanto Visual Studio Online como Team Foundation Server 2015, ¡así que manos a la obra!

Para proseguir con el demo de Parts Unlimited, debemos mencionar que en este ejemplo se hace uso intensivo de los Resource Groups que ya conversamos anteriormente, esto permite automatizar la creación del entorno donde se desplegara nuestra aplicación, vale decir que reduciremos nuestras visitas al Portal de Azure para la creación de nuestros recursos.

Para facilitar esto debemos preparar a nuestra maquina para que sea capaz de provisionar directamente en Azure, para lo cual abrimos una ventana de PowerShell (con permisos de Administrador, claro esta) y escribimos Set-ExecutionPolicy RemoteSigned.

5554.image_thumb_6CC60E94

Bien, terminaron los preparativos así que ya con la aplicación cargada en Visual Studio (y bien conectada a VSO) vamos al proyecto PartsUnlimitedEnv, hacemos clic derecho y elegimos New Deployment… Finish Reading: Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (III)

Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (II)

Posted on by ecardenas

Bueno, ya salimos de Fiestas Patrias y toca cumplir lo prometido, ir conociendo el nuevo modelo de Builds que ha sido introducido en Visual Studio Online y en Tean Foundation Server 2015 (que ya esta disponible en su versión final) y como comentabamos, se usara el ejemplo Parts Unlimited, que por tener ya las cosas hechas respecto a integración con BD nos servira para dar una visión integral del despliegue.

Los pasos que seguiremos seran los siguientes:

1) Descargar el código fuente de Github, crear nuestro repositorio en VSO y hacer las pruebas en local.

2) Preparar los Resource Group y todas los recursos Azure necesarios para el despliegue desde Visual Studio, de esta manera no tendremos que crear las cosas manualmente desde el Portal, salvo que sea estrictamente necesario.

3) Preparar la Build propiamente dicha y probarla.

Lo primero es crear un proyecto en Visual Studio Online, nótese que como siempre elegimos Scrum como plantilla y en este caso usaremos Git como modelo de repositorio.
Clipboard04

Luego de esto toca conectarse a dicho proyecto desde nuestro Visual Studio, y luego proceder a clonar el repositorio (que forma parte del proyecto de VSO), en este caso el repositorio aun estará vació (a menos que hayamos creado un readme desde el portal de nuestro proyecto), en mi caso particular edite la carpeta local donde se va a clonar el repositorio pues por defecto Visual Studio intenta crear los repositorios locales de Git en el disco C:

Clipboard05Ahora viene la parte interesante, Parts Unlimited es un proyecto muy interesante que si bien empezo con ASP.NET 4.x ahora están trabajando en una version basada en ASP.NET 5, pero para efectos de esta demo de Integración Continua nos basaremos en la versión 4.X para lo cual deberemos dirigirnos a este branch en GitHub, desde donde podremos bajarnos un Zip con todo el proyecto, lo descargamos luego de lo cual estaremos listos para integrarlo en nuestro repositorio Git de VSO. Finish Reading: Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (II)

Integración Continua con el nuevo modelo de Builds de VSO/TFS 2015 (I)

Posted on by ecardenas

Quienes trabajamos en temas de Integración y Entrega Continua, estamos muy interesados en conocer el nuevo modelo de Builds que incorporan Visual Studio Online y TFS, así como lo que nos ofrece de cara a nuestros procesos de calidad y de despliegue, pero antes de esto es bueno hacer un repaso de como hemos llegado hasta aquí.

Primero que nada ¿qué es una Build? o mas bien una Build Definition, es básicamente un proceso que definimos para nuestros proyectos de software en el cual nos aseguramos de que:

  • Los proyectos compilen
  • Las pruebas unitarias y de integración funcionen
  • Se efectue el despliegue al entorno correcto

Algo de esto hemos visto en artículos anteriores, pero la verdad es que estas cosas no fueron faciles siempre, recordemos:

Las Builds aparecen en TFS 2005, bueno, en realidad ya estaban ahí desde hace un tiempo via MSBuild, que recordemos es básicamente el «motor» detras de Visual Studio y es el que se encarga de efectuar las compilaciones, lo que permitió TFS 2005 fue calendarizar las Builds o vincularlas de manera rápida a nuestros checkins (o protecciones de código) , lo cual ya era bastante frente a lo que teniamos antes (Visual SourceSafe) pero por contra era responsabilidad de los equipos (o los preDevOps como yo entonces) preparar todo lo necesario para que las piezas funcionaran y se lograra un despliegue, para esto había que lidiar mas con MSBuild (editando archivos XML y buscando plugins) que con el propio TFS que a efectos prácticos simplemente lanzaba los proyectos y capturaba cuando había errores.

La situación fue mejorando progresivamente tanto en TFS 2008 como en TFS 2010, pero el verdadero cambio se dio en TFS 2012 (que vino de la mano con las pruebas de lo que entonces se llamo TF Service y ahora conocemos como Visual Studio Online) cuando se introdujo un modelo de Builds basado en XAML (en adelante XAML Builds) que prometía la idea de que el flujo fuera modelado siguiendo lo que ya se conocía de Workflow Foundation, en ese sentido uno modelaba el proceso y secuencia de pasos necesarios para nuestro tipo de proyecto, grababa un Template y el MSBuild era usado como etapa final, de hecho la pantalla que vemos en Visual Studio para editar nuestra Build Definition depende directamente del template usado (en el caso de esta Build Definition el template GitContinousDeploymentTemplate.12.xaml)

Clipboard01

Este modelo permitió colocar de manera explicita los procesos de Test fuera de MS Build y a la vez utilizar otros frameworks de Test (como NUnit) de manera transparente, posibilitando ademas que algunos terceros publicaran algunos template XAML con modelados específicos para ciertas necesidades; a nivel practico lo que ocurrió fue que las templates mas usadas fueron las que Microsoft fue agregando, destacando las que permiten el soporte de Git (que recordemos solo se incorporo a partir de TFS 2013) y Azure, la cual sin darnos cuenta ya hemos usado anteriormente.

A grandes rasgos este ha sido el modelo que se mantuvo en TFS 2013 y las sucesivas actualizaciones de Visual Studio Online, en el ínterin Microsoft abrazo Git, e hizo grandes esfuerzos por acercar TFS/VSO al mundo Java mediante plugins para Eclipse y avances para integrar Builds de Maven dentro de la plataforma Microsoft, la intención era clara: permitir que VSO sea un gran motor de Integración y Entrega Continua no solo para proyectos .Net sino también otras tecnologías como Java, node.js o iOS, pero lamentablemente el modelo de XAML con todas las ventajas que implicó no permite ese soporte de manera sencilla out of the box, así que desde hace unos meses se nos ha estado avisando de que Microsoft esta trabajando un nuevo modelo de Builds, que es lo que vamos a ver en este y los siguientes articulos.

Llegados a este punto, indiquemos los cambios que representa el nuevo modelo de Builds frente a las XAML Builds (que siguen funcionando perfectamente)

– Totalmente basado en Web, antes podíamos gestionar todo el proceso de las XAML Builds desde el IDE de Visual Studio, siendo que ahora para crear nuestras nuevas Build Definitions debemos ir a nuestra web de Visual Studio Online o Team Foundation Server 2015, lo mismo para ver el estado de ejecución e histórico de estas, todo via web.

– Flujo pipeline, simplemente es una secuencia de pasos desenchufables, para de esta manera conectar o agregar el paso que se requiere y de ser necesario eliminar un paso no necesario, en este gráfico los 4 primeros pasos vinieron por defecto y yo agregue el ultimo paso de Azure Web App Deployment (como veremos en el próximo articulo).

Clipboard02

– Modelo extensible, como mencione anteriormente la idea es dar soporte no solo a las tradicionales compilaciones de .Net basadas en MSBuild sino a Gradle, Maven, Ant (y seguro mas por venir) etc… miren nomas:

Clipboard03

– Hay que hacerlo todo explicito, si bien el proceso que conocemos para enlazar directamente nuestras Web de Azure con un proceso de CI en VSO resulta muy practico, a la hora de hacer cosas mas avanzadas (como integración con BD) tenemos que parametrizar MSBuild, asi que en este modelo debemos precisar todas las piezas que formaran parte de nuestro proceso en la sección correcta, pero esto lo veremos con mas detalle en la siguiente entrega.

Bueno, ya tenemos definido el marco teórico para empezar a trabajar, para esto nos valdremos del ejemplo Parts Unlimited que esta disponible en GitHub y que ha sido explicado inicialmente en ingles por Charles Sterling en cuyo trabajo me basare (y al que agradezco por permitirme su uso) y agregare algunas cosas que fui descubriendo en el proceso de implementar el ejemplo, ¡espero sus comentarios!

Empezando bien la 2da mitad del año

Posted on by ecardenas

Este fin de semana pude asistir, por tercera vez consecutiva, al Microsoft Influencers Summit de Perú, un encuentro anual donde nos reunimos quienes en el transcurso del año hemos colaborado en la difusión y el mejor uso de las tecnologías Microsoft.

En esta ocasión el evento fue en el Hotel Las Dunas de Ica, y como cada año fue muy intenso, conociendo a gente y motivandome por las distintas cosas que hacen así como por la capacidad que han tenido para organizar eventos de difusión en las distintas partes del Perú, especialmente (claro esta) los anfitriones, la poderosa comunidad estudiantil de Ica.

Se reviso el plan para el nuevo Año Fiscal que empieza ahora, y estrategias para apuntar mejor en nuestras actividades, pero por sobre todo se compartieron grandes momentos con un grupo muy diverso y a la vez alegre 😀

11709785_885634558178868_2506089030581725766_o

10317608_10152952561132864_4862202713044200559_o

En la noche del viernes tuvimos también la premiación de los Influencers mas destacados del año en las diversas categorías (Academy, IT Pro y Developer), tocándome el inesperado honor de ser designado como Top Influencer 2015, desde aquí mi agradecimiento especial a Microsoft Perú, a Jorge Oblitas y Mauricio Sougarret por esto, que no hace sino motivarme para seguir investigando y difundiendo tecnología como lo he intentado hacer en este modesto blog.

10987714_885632364845754_4509327738474147560_o

Empieza un nuevo FY, un plan de trabajo de difusión en el que espero contribuir con las diversas comunidades en lo que sea posible, y en particular mi reto personal que es mejorar los ciclos de desarrollo y despliegue de aplicaciones así como incentivar la adopción de la nube PaaS.

(Primera y Tercera fotografía gracias a Manuel Miranda del Solar)

Gestión de la Configuración de ASPNET 5 con Azure (y Docker!)

Posted on by ecardenas

Quienes han leído mis anteriores artículos sobre el despliegue en Azure pensaran que uff, ya tenemos todo listo para buscarnos la vida hasta que Release Management de un soporte total a PaaS, pero la verdad es que la cosa tiende a evolucionar y hay que hacer pequeños ajustes de cara a los cambios que se anunciaron en el Build y que vienen con el Visual Studio 2015.

Esto a propósito de la posibilidad que nos ofrece Microsoft de desarrollar aplicaciones .Net que corran tanto en Mac como en Linux, una posibilidad totalmente disruptiva que es todo un ejemplo de los cambios que llegaron de la mano de Satya, pero claro, esto no implica que lo que hemos desarrollado hasta ahora en ASP.NET lo recompilamos y lo subimos a Linux y ya esta… no, claro que no, para lograr el objetivo Microsoft ha sacado una nueva edición del .NET Framework llamada Core, sobre la cual se ha desarrollado una nueva versión de ASP.NET (concretamente la 5) mas modular y ligera, sin las dependencias monolíticas usuales, aprovechando tendencias ya existentes en el mercado: Bower, Grunt, npm…

Genial, pero todo esto viene con un precio, el primero y para mi el mas doloroso es que esta nueva versión de ASPNET no incluye proyectos en WebForms (sniff :'( ), ha habido un reacomodo en algunas librerías (sobre todo de cara a lograr la integración entre MVC y WebAPI), desaparición de global.asax, en fin no doy mas detalle porque para eso mejor leer los artículos de José M. Aguilar que va cubriendo con detalle las cosas que van saliendo.

Pero dentro de todos los cambios habidos hay uno que nos afecta especialmente a quienes trabajamos en la gestión de entornos de trabajo y de despliegue, y es que por defecto al crear un proyecto nuevo ya no hay un archivo web.config, esto debido a que la gestión de configuración ya no esta centralizada en un archivo monolítico sino que puede estar dispersa a lo largo de un conjunto de archivos (de preferencia JSON) o de las variables de entorno del sistema, correspondiendonos a nosotros el elegir que archivos usaremos y en que orden de secuencia y prioridad se van sacando, y claro la forma de acceder a estas propiedades, que vimos anteriormente, han cambiado.

slots29

Si pues, ya no mas ConfigurationManager y similares…

Y por lado de la estructura de los archivos JSON seria de esta forma, mucho ojo a este config.json, lo usaremos mas abajo:

configjson

Ok, entonces ¿como hago para acceder a dichos valores desde mi código? Finish Reading: Gestión de la Configuración de ASPNET 5 con Azure (y Docker!)

Desmitificando la Ingeniería de «Sistemas»

Posted on by ecardenas

El pasado lunes tuve el honor de exponer en la Universidad de Ciencias y Humanidades una presentación titulada «Mercado laboral del Ingeniero de Sistemas a nivel internacional», la idea que me propusieron mis anfitriones era contar a los alumnos mi «visión sobre la Ingeniería de Sistemas en la actualidad» y las diversas tendencias en las que puede ejercer un egresado, lo bueno de la conversación previa es que pude comentarles mi idea de contenidos lo cual derivo en esta presentación que invito a ver mas abajo.

Ahora bien, lo mejor no es la presentación en si misma, sino el proceso de reflexión que me llevo a estructurar su contenido, puesto que una de las cosas que tenía claro desde que fui invitado a la UCH era precisar que en Perú (como en Colombia) se tiene una idea totalmente errónea de lo que es la Ingeniería de Sistemas, que como indica el INCOSE(*)  es «An interdisciplinary approach and means to enable the realization of successful systems«, lo cual nos lleva a la palabra SISTEMAS (cuya definición me permitió dar el punto de partida a la charla) que como se indica en la presentación puede ser un sistema de transporte, hidráulico, hasta el sistema digestivo, en ese punto les comente a los asistentes algo que había escuchado esa mañana: los precios del gas en el Perú vienen dados por diversos factores: el que llegue el gas a Pisco, que a falta de un ducto entre Pisco y Lima el transporte del gas procesado hay que hacerlo en barco, lo cual genera una dependencia del oleaje, y por otra parte los precios internacionales del producto, etc…, así pues el modelado de un sistema que asegure un flujo eficiente y a buen precio del gas seria la labor que le correspondería a un verdadero Ingeniero de Sistemas con visión de los sistemas complejos, pero como era esperable y lo vi en las expresiones de mis asistentes no era eso para lo que habían sido preparados en sus años universitarios.

Durante el resto de la expresión explique como el error había persistido, de como el Dr. Maynard Kong impulso nuestra carrera de Ingeniería Informática en la PUCP, lo hizo con la visión de no persistir en la confusión y como en San Marcos por razones comerciales se había retirado la carrera de Computación para abrir una de… Ingeniería de Sistemas.

Con las bases aclaradas, y dejando indicado el hecho de que puede que en Europa o USA no entiendan la denominación de su profesión(**), ya pude introducirme en las diversas especialidades que la ACM esta reconociendo y promoviendo como vinculadas a la Computación o Informática, para luego explicarles mi perspectiva de los problemas actuales en el mercado laboral peruano y de como va a ir la tecnología para cuando estos jóvenes vayan a empezar su ejercicio profesional, pero…..

Lamentablemente el problema de la confusión semántica es muy grande (y como comente Colombia, al igual que Perú no esta ajeno a esto) tan así que en el Perú existe una Asociación Peruana de Ingeniería de Sistemas y Computación que no tiene ninguna mención respecto al desarrollo del enfoque sistémico, y si mucho de computación, siendo que este año en Arequipa se realizara el XXIII Congreso Nacional de Estudiantes de Ingeniería de Sistemas y Computación en cuya agenda se le ha procurado dar un enfoque basado en el enprendimiento tecnológico, pero ante las preguntas sobre si habría cobertura o no de temas orientados al enfoque sistémico bajo las definiciones de la INCOSE las respuestas fueron cortésmente evasivas:

DialogoIngSistemas

Personalmente creo que para evolucionar hay que tener en claro que cosa se es, que hay detrás del nombre y el contenido intelectual que se defiende con ello, si se va a abrazar la informática pues hacerlo con su nombre y las tendencias que se van estandarizando, pero que en el camino no se olviden que en el Perú si que hace falta la verdadera Ingeniería de Sistemas para ayudar a plantear las soluciones a los problemas grandes de nuestro país.

¿Cual seria el perfil de un Ing. Informático?

(*) Que si, que hay un organismo internacional a cargo de la Ingeniería de Sistemas  y que como pueden ver no tiene un enfoque especializado en computación.
(**) Felizmente en España nunca tuve problemas de identidad profesional, pero en Perú si que muchas veces han creído que yo era Ingeniero de Sistemas, lo cual siempre aclaro oportunamente.

Agregando uno de los primeros pasos a nuestro ciclo de desarrollo y despliegue

Cita - Posted on by ecardenas

Quienes han dedicado un rato a ver mi serie sobre automatización en el despliegue de aplicaciones con Azure habrán notado que había varios pasos manuales a la hora de preparar los entornos en los que íbamos a desarrollar y luego desplegar nuestras aplicaciones.

Pero, ¿nos hemos preguntado que pasa cuando hemos llegado a cierta madurez y nos encontramos con un escenario en que?: siempre creamos nuestros Websites en la misma zona geográfica de Azure, el mismo plan de precios, y… que la organización ya definió cuantos slots (ranuras) de despliegue son requeridos para el ciclo de desarrollo antes de que algo pase a producción.

En ese sentido Azure nos ofrece los Azure Resource Manager templates, que nos permiten definir y usar plantillas para automatizar la creación de recursos y entornos completos dentro de Azure, y ojo esto no esta limitado unicamente a Web Apps, sino también a entornos que involucren VM, Docker, Logic App, etc, en suma algo muy potente si queremos simplificar tareas repetitivas.

Este mecanismo llamo mi atención luego de que la genial GiS (a quien pude conocer de pasada en mi época en España) publicara este interesante articulo sobre como crear las citadas plantillas desde Visual Studio y es a ese articulo a donde deben remitirse para entender con detalle las partes de un proyecto de este tipo, luego de lo cual podemos regresar aquí.

¿Ok? En nuestro caso vamos a definir un proyecto de plantilla de tipo Web App (a diferencia de GiS que eligió la Blank Template para explicar con mas detalle la estructura base), así:

RM1En este caso notaremos que a diferencia del ejemplo genérico, lo que obtendremos serán archivos de nombre WebSite.json y WebSite.param.dev.json, los cuales se corresponden con los DeploymentTemplate.json y DeploymentTemplate.param.dev.json que con tanto detalle se describieron en el articulo de GiS.

RM2Ahora lo que haremos sera configurar los diversos archivos a fin de lograr una plantila que automáticamente nos permita:

  • Crear un Web App que incluya dos slots por defecto: «QA» y «Staging«
  • Localizar esta Web App (y sus slots) en una zona geografica determinada, en mi caso: «East US«
  • Usar siempre un mismo Grupo de Recursos (ya previamente creado en nuestro Portal de Azure, o creado la primera vez que invoquemos la plantilla), en mi caso: «Default-Web-EastUS«

Finish Reading: Agregando uno de los primeros pasos a nuestro ciclo de desarrollo y despliegue

¿Tenemos interés por lograr el cambio en el entorno?

Posted on by ecardenas

El como funciona el sector informático varia por países, y uno de los problemas que tenemos en Perú y España (si, en ambos casos pasa lo mismo con sus respectivos matices) es la posibilidad de realizar una carrera profesional dentro del área técnica sin tener que pasar a «gestionar» para poder evolucionar económica y profesionalmente, siendo que en la mayoría de los casos uno debe dejar la programación para gestionar o … intentar una Carrera en Y para poder ascender (*).

Por contraste veamos este comic de CommitStrip:

Strip-Coder-ou-plus-650-finalenglish

Alucinante ¿no? Preferir seguir codificando en lugar de ascender y ser un manager ¿esta loco? eso es lo que nos diríamos en nuestros países, pues es la verdad, así como están las cosas ese ES el camino de mejora, lo cual trae de rebote otros problemas:

  • Se pierde un buen programador y se corre el riesgo de tener un mal manager
  • Managers que desde que salieron de la universidad han evitado de cualquier forma posible el contacto con la tecnología
  • Un mercado laboral que considera al programador como una etapa en la vida, por lo que no se consideran experiencias mayores a 6 años en las ofertas, total.. todo puede hacerlo un practicante.
  • Egresados de informática quejandose de que en la universidad se les enseño «demasiada programación» y poco de gestión, lo ironico es que los contenidos actuales de programación no tienen la profundidad necesaria para los retos que hay que enfrentar en el mercado global.
  • Una plana gerencial poco receptiva a las innovaciones y buenas practicas como el agilismo, integración continua, etc.

En ese sentido, la innovación en las organizaciones va cuesta arriba, dándose el caso de que muchas veces los cambios en las consultoras vienen dados porque el cliente da el giro hacia el agilismo, obligando a todo el ecosistema de proveedores a dar el cambio y avanzar poco a poco justos en la mejora.

Siendo así, hace poco un amigo comentaba las innovaciones que en la consultora que estaba trabajando se estaban dando: establecimiento de una linea de carrera para los perfiles técnicos, buenas practicas como entrega continua, visual story mapping, y por supuesto: agilismo, todo sonaba bien pero cuando le pregunte si ya iban a empezar a atacar el mercado peruano (su cartera de clientes es remota) dijo «No, no pagan», ahi todo se desbarato, pues se pierde una oportunidad para replicar los cambios y las buenas practicas en nuestro contexto, pues dicho escenario virtuoso se vuelve una isla que no replica lo bueno que esta haciendo a lo que pasa en el país. A seguir buscando los nichos de mejora…

Queda en nuestras manos en seguir evangelizando, y no dejar de apuntar los problemas.

(*) Y el problema no es tan solo de algunos países, algunas corporaciones multinacionales de consultoría tienen muy incorporado en su ADN que si uno entra a la linea técnica nunca podrá acceder al anhelado grado de «socio».

¿Reactivos o proactivos con la nueva tecnología?

Posted on by ecardenas

Cuando se trabaja desde la consultoría a empresas uno debe tener claro la actitud que se debe de tener ante la tecnología emergente y como reaccionar ante ella de cara a lo que se ofrecerá a nuestros clientes, es probable que si nuestro cliente es un banco y aun siguen anclados al COBOL no haya muchos incentivos para proponer cambios y nuevas tecnologías core según que áreas (*), pero si el rubro de clientes apunta a los mal llamados proyectos «llave en mano» o «time and materials» en que se espera colaboración el escenario puede ser muy diferente, y el modo de proceder tiene que ser acorde a el.

Un error demasiado frecuente es dejar que sean las necesidades inmediatas de nuestros clientes las que condicionen la adopción tecnológica en una consultoría, como consecuencia los fichajes se hacen basados en si el desarrollador tiene los skills de los proyectos que se están haciendo en este momento, lo cual permite ir dentro de la ruta segura… por un tiempo, aunque puede generar situaciones extremas en las que por querer atender a un «cliente importante» se realicen fichajes de emergencia, o un aprendizaje a marchas forzadas, sin garantía de que luego de que ese proyecto acabe habrá nuevo uso de esa tecnología, pero bueno… lo importante es que se consiguió llegar a ese cliente (**). Otra situación común es que ante un potencial proyecto nuevo se este preguntando al equipo existente «¿alguien sabe xxx?» lo cual denota una falta de mapeo sobre los skills del equipo, pero eso es otra cosa.

El caso opuesto se da cuando alguien se emociona por una tecnología que se vio en Internet, y no se vio la curva de adopción, por lo que uno puede terminar casi sin soporte en Internet pues eres uno de los pocos que usa la tecnología, paso con lenguajes e IDEs en los 90s y ahora pasa con frameworks de JavaScript.

Entonces ¿que hacer? La respuesta esta tal vez en el medio, pero de una manera proactiva, no dejar de mirar los avances tecnológicos, en lugar de estar pendientes de lo que usa el cliente, apuntar a lo que la tecnología actual y emergente puede hacer por solucionar sus problemas y sus necesidades de crecimiento, investigar y hacer pilotos aun antes de que haya clientes que pidan algo (eso evita que el requerimiento o el boom nos coja desprevenidos) y como decia Eduard no pretender dominar todo y por ende aspirar a todos los clientes.

Adicionalmente, una «ventaja» de no estar en USA es que hasta cierto punto se puede sacar partido del retraso en adopción tecnológica, pues da tiempo para ver por donde se están consolidando las tendencias y ser novedosos (con algo seguro) de cara a lo que se le puede ofrecer al cliente.

¿Que opinan? ¿Reactivos o proactivos?

(*) A pesar de tener el core en COBOL muchas organizaciones han desarrollado productos con nuevas tecnología que llaman a ese backend, así que por ahí pueden salir las innovaciones a proponer.

(**) si a veces se esta en esa tesitura es necesario dedicar buen tiempo al estudio de lo nuevo, y no pretender que todos los desarrollos son similares ni con igual riesgo.