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

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?

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.

Renombrado de Team Projects en Visual Studio Online

Al parecer si había una característica muy solicitada en Visual Studio Online era la de poder renombrar un Team Project una vez creado, me imagino que por ejemplo, tu cliente ha decidido cambiarle el nombre a todo el proyecto, o peor aun… que este decida cambiar su razon social y tu equipo tiene que alinearse acorde a ello, pues bien eso hasta ahora no era posible pues al momento de crear un Team Project se te indicaba que tu elección de nombre no se podia cambiar.

Lo bueno es que como ya se venia anunciando hace tiempo, desde este 24 de Abril ya es posible hacer dicho renombramiento, para lo cual podemos hacerlo desde la zona de administración de la Collection, como se nos indica en la pagina mencionada:

IC795516

O bien, desde la zona de administración del proyecto, para lo cual simplemente tenemos que editar el Nombre debajo de Project Profile y darle a grabar, en este caso he probado con un Team Project de una demo que realice hace dos años y que se llamaba Summit2013Beta al cual lo renombrare como Summit2013.

RenameTeamProjectNótese de la alerta que nos aparece, se nos indica que esta operación es disruptiva por lo que debería efectuarse fuera de horas de trabajo, lo cual tiene toda la lógica del mundo si es un TP que tiene un equipo que esta trabajando en él, adicionalmente se nos recuerda que:

  1. Las buils corriendo durante el renombrado pueden fallar
  2. Todos los usuarios deben reiniciar Visual Studio
  3. Los repositorios Git remotos deben ser actualizados con el nuevo nombre de Team Project
  4. Los Workspaces (si usamos TFVC) deben ser corregidos mediante un «Get latest versión»
  5. Si estamos usando workspaces locales (introducidos en VS 2012 ¡como pasa el tiempo!) se requiere usar VS 2013 Update 5 o VS 2015 (RC o mas reciente) a fin de que los workspace se actualicen en el siguiente «get», si no se puede hacer la actualización o aun se sigue usando VS 2012 no quedara mas remedio que archivar (shelve) los cambios, crear un nuevo workspace y luego desarchivar (unshelve) los cambios (una razon mas para actualizar ¿no?).

Pues nada una petición de los desarrolladores ya esta disponible, a obrar con cuidado si necesitamos hacer uso de ella, mas detalles aquí.