Arquitectura de software puertas afuera

 

Hace ya algunas semanas que me cambié de trabajo.
Los motivos de alguna manera se fueron desglosando desde hace algún tiempo, y obviamente desde la parte de arriba de la pirámide hay cosas entre que se desconocían, que nunca se vieron (o no se quisieron dar cuenta), o que simplemente no se entienden, en fácil sería bueno que analizaran porque se va la gente y en que parte de la historia los stock options perdieron su atractivo inicial y su poder de retención.

Voy a reciclar un artículo que  ha envejecido bastante bien (no ha dejado de perder sentido): La necesaria mirada hacia adentro de la propia organización

La cosa es que entre las cosas que tuve que hacer antes de mi salida, aparte de tener que entrevistar a mi futuro reemplazo y revisar desafíos técnicos, fue proponer un plan de trabajo futuro, porque "me siguen necesitando" sea para  atender consultas varias o para optimizar algunas cosas, pensemos que el "desarrollador senior" de la empresa "que se encargaba de sacar los cachos (desafíos con dificultad mayor a la habitual, y que nadie quiere hacer)" ya no está, y alguien tiene que encargarse de "hacer lo mismo".
Después de una breve negociación llegamos  a un acuerdo que de alguna manera busca ser conveniente para todas las partes. No es un número de horas fijas al mes, el valor HH es menor a mi "precio habitual" pero mayor al propuesto inicialmente; lo que si hay un límite máximo de horas al mes, y precisamente por eso es conveniente para las 2 partes.

Por un lado no me  voy a inventar horas ni sobrecargarme con horas de trabajo, por el otro se pagan solamente las horas consumidas. Es como un plan de telefonía móvil, pero de los viejos, o con tarjetas de minutos.

El escenario de "ponerse precio" nunca ha sido  sencillo. Lo que no se debe perder de vista es que la HH fuera de un contexto de contrato jornada completa debiera ser mayor a la HH bajo contrato.

Hasta el momento aquí no hay nada de arquitectura.

La cosa es que de las tareas que me han sido encomendadas, no hay mucho de lo que no haya hecho en mi tiempo bajo contrato jornada completa. Y estas actividades más que apuntar a la resolución de bugs, apuntan a la la toma de ciertas decisiones de como debiera resolverse un problema, o bien optimizaciones generales a ciertos procesos de los sistemas de la organización, así como a la atención de consultas de temas que pueden exceder la complejidad habitual.
Al final es algo como una consultoría interna con matices de arquitectura de software.

Aquí es donde empezaron ciertos cuestionamientos existenciales respecto a lo que estoy haciendo, y  respecto a como veo el camino que está tomando la organización que  dejo detrás:

• La organización crece, y el crecimiento nunca debe ser interpretado como algo negativo, salvo cuando descuidas tu activo más valioso, que NO son tus datos, NI tampoco tus aplicaciones, sino las personas que  le dan valor a tu organización. Si como líder olvidaste eso, estas condenado a perder gente, y como me dijeron en otra empresa en la que trabajé "Son los buenos los que se terminan yendo".
• Quedan cabos sueltos, o cosas de las que nadie  se va a encargar, y no por falta de capacidad, ni porque se  carezca de las competencias adecuadas. Solamente porque nadie tuvo la voluntad para involucrarse en ciertos procesos, o si queremos ser menos pesimistas en la repartición de culpas responsabilidades, ha sido el día a día el que ganó esta batalla en la que ojalá hubiera alguien más que se dedicara a cubrir requerimientos de la organización que no son otro bug en el sistema.
  Entre estas:
• Actualización y mantención de SW anexo a los desarrollos locales, utilizado para algunas parte  "no tan críticas del sistema".
• Actualización de las versiones de las librerías utilizadas en el desarrollo. De aquí lo que más sufre es Angular, que se va a quedar un buen tiempo  estancado en la versión 15, ya que  demanda que haya otras librerías que se actualicen previamente.
• Actualización de las herramientas utilizadas en el Monorepo. De alguna manera relacionado con lo anterior.
• Control de calidad del desarrollo, buenas prácticas, etc. El tiradero de orejas claramente va a disminuir, porque no hay un área, o simplemente alguien que esté constantemente velando por esto.
• Promoción interna, a modo de publicidad gratuita. Yo siempre dije que la organización estaba haciendo cosas interesantes que iban al menos un par de pasos más adelante que varias de las organizaciones que me ha tocado conocer. Difícilmente habrá artículos técnicos que promocionen lo que están haciendo. ¿Podría hacerlo? ciertamente, pero esa no es la pregunta correcta...
• Desarrollo de nuevas librerías de uso general para simplificar el desarrollo futuro. Sin ir más lejos, un mantenedor de formularios dinámicos. Ese es uno de los grandes temas que se dejó pendiente. 
• Automatización de tareas recurrentes, sea mediante  algún script o desarrollo de alguna herramienta.
• Charlas de buenas prácticas, o show-off de proyectos, librerías o simplemente cosas que tecnológicamente tengan alguna relación con lo que se hace, o que puedan servir en algún desarrollo.

Entonces ¿la organización realmente necesita de un desarrollador senior? ¿o de un arquitecto de SW?
Y aquí es donde voy a opinar en más de un par de párrafos.

¿Qué necesita una organización?

¿Desarrolladores seniors? ¿un arquitecto de software? ¿un área de "arquitectura/infraestructura" (o invento afin)? 

Según yo, una organización que basa su funcionamiento en sistemas de SW que hayan sido desarrollados internamente y que pretenda escalar (léase por lo bajo como atender más clientes), NECESITA que alguien defina el cómo debiera solucionarse el desarrollo, siempre  aspirando a no hacer más complejo el ejemplo de tutorial o del curso online, sino sentarse y pensar en como hacer una mejor implementación, sobretodo si el problema dejó de ser simple.

Y eso normalmente es lo que hace un arquitecto de SW, ojalá en coordinación con los líderes de equipo, quienes normalmente son desarrolladores senior.

Aquí podría surgir otra pregunta, ¿este tipo de organización (mediana empresa con olor a startup), necesita un arquitecto de SW?
Y la respuesta es complicada. Quizás con la llegada de un senior, que viene con una experiencia y una visión mucho más acabada de ciertos flujos, la organización "se ordene", al menos en el sentido del desarrollo. De seguro va a ser  un poco menos "echarle para adelante" y pensar un poco más las cosas antes de sentarse a  vomitar líneas de código y a copiar ejemplos de StackOverflow; quizás... 

Ya sobrevivieron una etapa sin alguien que los ordenara, obviamente eso  se tradujo en código legacy, y una deuda técnica espantosa, pero "echarle pa' delante" funciona, igual que afirmar el acelerador de un auto con un alambre. Funciona...

Volviendo a mis dilemas existenciales, y a ciertas conclusiones que ya he sacado, lo más seguro es que  esta empresa nunca haya necesitado un arquitecto de software, ni un desarrollador senior con  demasiada experiencia.

Claramente no necesitaban, y probablemente nunca necesiten un evangelizador de software que  escriba artículos de que tan interesantes pueden ser los desarrollos internos. Menos a alguien que a través de esos artículos intente convencer a quienes postulen al área de desarrollo  que esta es la empresa en la que pueden crecer profesionalmente. El nivel de valor agregado que esto en particular agrega a una organización va a depender principalmente de cuanto les interesa destacar en el círculo de desarrollo de SW en el que se mueven, o si eventualmente te interesa  destacar en un círculo más grande.

Una vez que probaron tener a alguien experimentado probablemente se despierte esa "comezón" de tener a alguien que te diga "por ahí no, que hay muchas piedras y espinas" y que te mande por un camino más largo, de seguro más empinado, pero con cierta garantía de  poder llegar a destino sin muchos contratiempos, y con la suficiente energía para poder seguir adelante.
O probablemente no, y todos sigan picando piedras igual que siempre.

Es de aquellas cosas donde,  en lo personal, no me queda tan claro que tan compatible con el negocio sea darle cierto énfasis a la calidad del desarrollo de SW. A mi parecer sería lamentable que el time to market siempre fuera prioritario por sobre la calidad del producto entregado, y que tener algo bien hecho sea solamente parte de la esperanza  positiva del flujo de desarrollo. Aquí es donde se sopesa  el  hacer algo bien hecho en 1 semana vs sacar a flote una espantosidad en 3  días; ¿qué tan caro sale no hacer las cosas bien hechas? 

Quizás, bajo determinados enfoques,  hacer las cosas bien esté demasiado sobrevalorado y realmente no valga la pena el esfuerzo.

Entonces lo que quizás siempre  fue mejor era tener un arquitecto de  software puertas afuera, alguien fuera de  empresa a quien puedas consultar sólo cuando consideras que es estrictamente necesario; y asumir el costo de esta consultoría externa.

Con la absoluta  ausencia de humildad de este artículo: 

• ¿Cómo veo mi futuro? Espero que no sea una muerte lenta con buen sueldo, tal y como me  comentó un colega. Pero el salario es competitivo internacionalmente,  y es se nota más porque en general el empresario chileno prefiere profesionales menos experimentados que ojalá salgan baratos. Un gran amigo me dijo que trabajar para una empresa extranjera era algo que yo debí haber hecho hace muchos años atrás.
• ¿Cómo veo el futuro de la organización que dejo a un lado? Les toca un camino de maduración posiblemente algo agreste, lleno de aprendizaje. Ojalá las jefaturas se involucren con lo que se hace, sino esa desconexión les va a penar y pesar. Falta cambiar el lente para mirar desde una perspectiva diferente a la de una jefatura ya que no todo es "el negocio".

Reclutadores, LinkedIn, y los cargos de papel

Imagen sacada desde http://howtosavetheworld.ca/2018/08/29/hierarchy-is-the-enemy-of-learning/

Hace algunas semanas atrás apareció en la empresa para la cual trabajo un nuevo personaje. Su misión encubierta: gerenciar los proyectos en curso de una empresa "hermana". Su misión real, o más bien como la estamos percibiendo, hacer sonar los tambores y dar golpes de látigo de cuando en cuando, y paquear, como decimos en Chile a los que hacen de policia.

Eso, junto al cambio de oficina, definitivamente vino a quebrar el "equilibrio espiritual" que nos envolvía. Poniéndolos en contexto queridos lectores, el área de desarrollo se encontraba literalmente en el último rincón de la oficina, donde estábamos muy cómodos y tranquilos, con todo lo que necesita un área de desarrollo, agua, cafetera, fruta, dulces, pizarra, panel Kanban, mucho espacio y juguetes. Nos forzaron a mudarnos literalmente al frente de la oficina, detrás de la secretaria de recepción, totalmente expuestos, y obviamente con la absoluta carencia de  muchos de los elementos que nos mantenían cómodos y a ratos felices; sabiendo que las áreas de desarrollo tienen que mantenerse escondidas de los clientes (digamos que el orden diferente de estás áreas siempre es por lo bajo disrruptivo, y tiende a ser confundido con desorden).

Pero no, no voy a hablar de mis descargos, sino de cierta peculiariad que me hizo recordar cuando traté con un personaje que al irse de la empresa para la cual trabajábamos en ese entonces,  puso en su LinkedIn que había sido el arquitecto Java. El nuevo personaje en cuestión aparece con el original cargo de "Sub-gerente de desarrollo de negocios y estrategia digital" . Esto nos hace pensar varias cosas:

• ¿Se puede ser sub-gerente de una gerencia que no existe en la empresa? Para LinkedIn y para los miles de "reclutadores" que se fían de  estos antecedentes, claramente.
• Nadie nos informó que este personaje venía como sub-gerente. De hecho si no es por LinkedIn nadie se  entera del supuesto cargo que detenta.
• ¿Las gerencias estarán enteradas de esto? La lógica nos indicaría que si, al menos por un tema ético, pero nuevamente, nadie nos ha informado al respecto. Uno esperaría que los amitos se dirigieran a la plebe con un "Hola. Les presento a Pepito TeVe , que va a er nuestro sub-gerente de blah... y se va a encargar de bleh.." Contra el como nos lo presentaron "Hola, él es Pepito TeVe y nos viene a apoyar en la gestión de los proyectos de blih...". Entre ambos discursos veo perturbadoras y no tan sutiles diferencias.
• Finalmente surge la pregunta ¿porqué? y aquí es donde entran los "reclutadores" de LinkedIn.

Reclutadores de LinkedIn

Típico que cuando uno anda merodeando por LinkedIn, y sobretodo si uno se ha encargado de hacerse cierta publicidad llenando bien el CV, uno recibe algún mensaje de algún reclutador. Este tipo de reclutadores es como a quien encargan a leer los avisos económicos de los periódicos. Buscan algo que se ajuste a lo que se necesita, y después alguien más se encargará de llamarte o contactarte para una conversación más seria.

El problema es que puedes haber puesto "Jefe supremo del mundo mundial de todo el universo" y si el título pareciera ser lo suficientemente convincente nadie, y digo NADIE,  se encargará de verificar si efectivamente fuiste el Jefe supremo del mundo mundial. El papel aguanta mucho, entonces si el reclutador hiciera bien su trabajo harían un mínimo de trabajo de contactar a alguien (ojalá al azar) de estas empresas y hacer las averiguaciones básicas.
Esto sería la misma cuota de azar para bien o para mal, pero también  una ganancia para las empresas que no estarían perdiendo el tiempo con quienes mienten en sus cargos actuales, y un incentivo para los empleados para ser honestos en su CV. ¿Muy utópico? Probablemente, soy de la filosofía de que si no quieres hacerte cargo de tus mentiras, ni de las mentiras ajenas, entonces mejor no mientas.

Yo esperaría que en el futuro cuando Pepito TeVe sea un cesante más y un reclutador vea su CV en LinkedIn alguien verificara si efectivamente ejerció el cargo de "Sub-gerente de desarrollo de negocios y estrategia digital", o si solamente fue el cargo de papel que probablemente le valga la posición de Gerente de proyecto/producto en alguna startup, lo que siendo realista, como posición  es bastante más cercano  a lo que actualmente cree que está haciendo.

Palabras al cierre del artículo: Por si notó cierto malestar y una importante carga de ironía, si. Efectivamente. Al menos mi malestar, a modo personal, es evidente; sin embargo claramente importa un pepino. Peeeero... así como tienen personajes imaginarios en sub-gerencias imaginarias, lo siempre lógico es gerenciar sobre un equipo también imaginario.

La entrevista de 5 minutos

Original de https://www.flickr.com/photos/visualpunch/7245652114

Hace algunos días atrás LinkedIn me envió un listado de "atractivas" ofertas laborales, entre ellas una que particularmente me llamó la atención. Se trataba de una startup, con cierta antigüedad (pero sigue siendo startup, como los autos usados con olor a nuevo), que buscaban un profesional más o menos con mi perfil. Dado que la curiosidad fue más fuerte postulé, y no les miento, en menos de 5 minutos me estaban llamando por teléfono.

Haciendo caso omiso de la calidad de la llamada, porque se escuchaba como si mi interlocutor estuviera encerrado en un bunker bajo tierra, la llamada comenzó con casi un "¿Cuándo puedes partir?". Mi enfoque habitual es de "Por favor, cuéntame más de que se trata la oportunidad, qué es lo que están haciendo, y qué es lo que necesitan". Siempre procuro hablar de "oportunidad" contra hablar de "ofertas", ya que una oferta siempre va con el monto visible para los interesados. Por otro lado las oportunidades son comparables a ver el aviso de venta de una casa, no necesariamente  van con el precio.

El resumen corto, empresa "joven"; información corroborable en Internet; con pocos empleados, varios clientes "grandes/importantes" del rubro retail (lo que no es mucho decir considerando la cantidad de proveedores de servicios que manejan las multitiendas), más un par de organizaciones sin fines de lucro. El proyecto era para alguna multitienda, y la intención era hacer un cambio completo de arquitectura, de modo de irse por el camino de los microservicios , usando Java. La necesidad puntual, un arquitecto Java con, digamos, "destrezas" en "otras áreas".

Conversamos un rato, le conté que estaba haciendo, que había hecho, y llegamos a la parte siempre dolorosa para los entrevistadores, las pretensiones de sueldo. Le señalé que mis pretensiones se ajustaban acorde  a los más de 15 años de experiencia que tengo, y empezamos con problemas. Mis pretensiones obviamente no estaban acorde a los montos que la empresa consideraba para el cargo, me ofreció 2 montos, uno inferior a mi sueldo actual, y otro al nivel de mi sueldo actual. Consideren  que los cambios laborales, salvo circunstancias demasiado particulares, siempre debieran ser por mejores condiciones; si no hay mejora aparente mejor sigan donde están. Después de "aceptar" a regañadientes mis pretensiones, me consultó cuál era mi disponibilidad, a lo que repliqué que necesitaba al menos 2 a 3 semanas para poder cerrar los temas que tenía a cargo. La idea al cambiarse, es siempre salir por la puerta ancha; el mundo es demasiado pequeño para salir "en mala" como decimos en Chile, lo que eventualmente puede cerrarnos algunas puertas en el futuro.
Eso tampoco prosperó, la necesidad para esta nueva posición era inmediata, dadas las fechas cercanas del inicio del proyecto. Finalmente le dije que me mandara un correo; cosa que no hizo; con esos mismos antecedentes de modo de poder manejar mis tiempos y ver  la posibilidad de irme a su empresa.

Consejo gratuito a los reclutadores: NUNCA, pero NUNCA NUNCA NUNCA, revelen la urgencia de su necesidad de contratación. Es un antecedente que se va a volver en "su contra" (léase a favor de uno) al momento de las negociaciones. En fácil: Las urgencias siempre son más caras.
Corolario de lo anterior: Eviten que el rol del reclutador lo lleve un líder técnico.

Eso fue la llamada. Obviamente después hice un breve análisis de la situación. En lo personal me pasa algo cuando se me presenta un proyecto, donde el interlocutor habla con cierta propiedad de conceptos como microservicios, APIs REST, metodologías ágiles, TDD, devops, big data, business intelligence y otras "palabras de moda" en el contexto TI. 

Mi primera reacción es cuestionar la real comprensión de cada uno de los términos, porque por ejemplo para el caso de los microservicios, no es llegar y cambiar hacia una arquitectura a microservicios, sobretodo si inicialmente es un monolito. Eso aparte de una gran consideración que todos quienes hemos querido jugar con microservicios tendemos a olvidar: efectivamente hace que las capas de tu arquitectura se vuelvan modulares, "más sencillas" (es un gran es relativo), ya que van a resolver funcionalidades/servicios puntuales más pequeños; sin embargo tu arquitectura inmediatamente gana más componentes, lo que se traduce en más componentes para mantener. Esto sumado a que además debes hacer "conversar" los componentes entre si (aunque en rigor al menos esta parte es transparente, ya que la capa de orquestación se encargaría de esto).
Piensen en un monolito como bloque de piezas de Lego, pero uno donde pasarlo a microservicios implica desarmar el bloque y agregarle piezas nuevas para sostenerlas por separado. En el suelo es más fácil clavarse los pies al pisar muchas piezas pequeñas que clavarse pisando un bloque grande (un monolito).

Y esto no quiere decir que los microservicios sean intrínsecamente malos, sino que la labor del arquitecto de software (obviemos la etimología del concepto arquitectura) no es sólo velar por la correcta implementación e implantación de los microservicios, sino además saber y hacer saber si efectivamente son la mejor solución para el problema.

Entonces tomando como antecedentes la urgencia del requerimiento, el rango salarial ofrecido, la experiencia y perfil de la empresa, y la cantidad brutal de conceptos de moda que lleva el proyecto, mi conclusión; en un lenguaje bastante coloquial; es que esta startup se está tirando los peos más arriba del poto (literalmente en español no-chileno, y usando el verbo peer conjugado correctamente, peyere más arriba del trasero). Una empresa con pretensiones excesivamente altas para un equipo que sospecho (arriesgo equivocarme) aún no tiene las competencias para un proyecto con microservicios. Y de paso les cuento algo: Yo tampoco tengo esas competencias, en un contexto práctico no académico-teórico.

La necesaria mirada hacia adentro de la propia organización

by https://www.flickr.com/photos/144152028@N08/33772074972

Mañana se cumple exactamente un mes desde que dejé mi antiguo trabajo. Por esas cosas del destino ahora estoy en una empresa que ya conocí, sacando cuentas he vuelto después de 5 años.
No puedo negar que ahora me siento bastante más cómodo, la dinámica de trabajar por proyectos versus trabajar en torno a un producto que está posicionado en el mercado hace más de 20 años es muy diferente. Proporcionalmente hablamos de una empresa con un área de desarrollo mucho más pequeña, por ende mucho más especializada, contra una empresa que es derechamente de desarrollo, donde el área encargada es bastante más grande, y consecuentemente más heterogénea. Pero no quiero referirme a eso, sino a una reflexión que tuve antes de cambiarme de trabajo.

Desde el punto de vista de la empresa, ahora se fue uno (en rigor hace un mes), un recurso menos, un elemento reemplazable, con más o menos dificultad, pero siempre reemplazable. La pregunta a hacerse desde dentro es ¿porqué? ¿qué pasa en MI organización, que la gente piensa en irse a otra empresa?
El que tan indispensables somos depende de las estrategias de cada empresa. Si cada desarrollador es "dueño y señor" de los desarrollos que se le encomiendan, y si no existe un equipo de más de un solo hombre (o mujer) encargado, entonces se vuelve más complicado reemplazar a alguien que se va. Pero ¿porqué se va la gente?

¿Mejores condiciones? ¿salarios más atractivos? ¿mejores proyectos? ¿mayor proyección profesional?
A mi parecer, y un poco lo que personalmente me motivó, es una mezcla de factores, donde claramente el salario fue el 1er elemento a considerar, pero no el único.
Cuando día tras día la rutina de ir a trabajar se empieza a volver tortuosa por la percepción de una falta generalizada de voluntad por hacer cosas, y cuando empiezas a darte cuenta de una inusual venta de humo, de la que alguien (probablemente uno) tendrá que hacerse cargo, con requerimientos imposibles y en plazos irreales, entonces hay algo que dispara todas las alertas en tu interior. Si a eso sumas que la organización difícilmente ajustaría las condiciones y el equipo conforme a estos nuevos "desafíos", o simplemente ves que  te estás condenando profesionalmente a "seguir picando piedras", las señales no pueden ser más claras.

Entonces desde dentro probablemente van a ver todo bonito y tu partida será injustificada. Aquí es donde es importante no perder la objetividad.
¿Qué está pasando en MI organización? Si tu administración es desde el desconocimiento, entonces puedes esperar que muchos se vayan y no vas a entender porqué. La mirada hacia adentro debe ser crítica y siempre objetiva. No es pecado ni mal visto bajar del Olimpo a ver que pasa en la Tierra.

Las tropas no se mueven si no hay un liderazgo claro, pero tampoco dejan los puestos de batalla por nada.

Nota: Este artículo probablemente se lea como una contradicción (en algún grado) a este otro artículo . Si y no. Como mencionaba más arriba, las condiciones (entorno) pueden ser  muy buenas y atractivas, incluso mejores que las de cualquier otra empresa, y seguramente es eso lo que va a ver un jefe. Pero la informática es dinámica, y no se alimenta sólo de juguetes, vestimenta informal, pizza, café, golosinas y bebidas energéticas. El problema esencial es cuando el líder no se da cuenta (o no quiere darse cuenta) que las tropas están inquietas, ya sea por ese constante picar piedra o simplemente por la incertidumbre frente al futuro; y frente a eso por muy buenas que sean las condiciones del entorno la gente se va a ir.

El miedo a avanzar al mismo paso que las empresas que SI avanzan

Mirando una realidad que no me resulta ajena, y a punto de emprender un nuevo viaje laboral, me parece oportuno reciclar el artículo que escribí en Agosto de 2013:

Porqué usar herramientas obsoletas puede perjudicar tu empresa 

No es que estar en el leading edge/bleeding edge sea siempre lo mejor, pero cuando constantemente hablas de innovación y tu estrategia es apostar sobre seguro con la fórmula de siempre, al menos a mi se me genera una contraposición de ideas importante.
En TI a veces es bueno ver regularmente que se está haciendo hoy en día para hacer que las ruedas giren más rápido. Es altamente probable que lo que aprendimos de nuestra escuela madre haya quedado obsoleto  al menos hace una década atrás, y actualizarse pase a ser un deber más que una necesidad.

Para avanzar hay que caminar hacia adelante (idealmente de frente)

Empresa no encuentra informáticos ¿de qué estamos hablando?

Créditos para lun.com

Hace unos días mi madre me remite un artículo de un periódico que dado el matiz de su "periodismo" derechamente no lo leo. No encuentran chilenos: empresa decide importar informáticos
Yo soy informático, conozco a muchos informáticos de una calidad profesional a lo menos destacable. Entonces, fuera del clásico amarillismo del titular ¿de qué estamos hablando?

Leo el artículo y esbozan algunos motivos digamos clásicos:

• ¿Falta de talento? Por favor, ¿dónde están buscando? ¿en Laborum, o en Kibernum, o en alguna otra "joya" del reclutamiento?
• Manejo de inglés. OK, esta se las concedo. De mis conocidos, con suerte un 20% maneja inglés a un nivel de soporte telefónico Indio.

El resto del artículo, literalmente challa (para los no chileno-parlantes, challa es el confeti, circulos de papel peforado que se lanzan en festividades), el gerente de la ACTI entregando cifras que no condicen la realidad de la saturación del mercado informático chileno.
Si, hablo de saturación, ya que hay demasiados universitutos; muchos sin ningún tipo de acreditación; que dictan pobremente carreras de informática (análisis, técnicos, "ingenierías" varias), con aranceles muy atractivos, y que finalmente entregan al mercado "profesionales" con muy mala preparación. Este tipo de desempleados buscará cualquier tipo de oferta laboral, y presentará unas pretensiones de sueldo bajas, que finalmente hacen que las empresas de reclutamiento manejen un concepto absolutamente errado de lo que realmente es el famoso "sueldo de mercado" (más considerando que el mercado no es único, pero anda a explicarle eso a una empresa de reclutamiento).

Entonces, ¿porqué Nisum no encuentra informáticos en Chile?

1. Tratemos de entender a que apunta la empresa, y cuál sería el perfil que requieren. Nisum es una consultora internacional, cuyas especialidades distan de cualquier malla de cualquier institución académica, y digo cualquier, incluyendo las universidades tradicionales que tendrían más prestigio en carreras TI. Bajo ese esquema, y de acuerdo al casi de seguro distorcionado discurso de empresa transmitido por LUN, es una empresa que no tendría la disposición de entrenar o preparar  profesionales conforme a sus necesidades, sino que optaría por la contratación de informáticos con más experiencia (algo así como "Se busca recién egresado de carrera de informática, con al menos 10 años de experiencia"). Pero ahí es donde surgen los otros puntos de mi análisis.
2. Si una empresa delega sus contrataciones en empresas de outsourcing, lo más seguro es que NUNCA (sí, con mayúsculas y en negrita) encuentre profesionales de buen nivel. Y soy radical en esto, ya que el perfil de profesional que aún prefiere buscar trabajo a través de empresas de outsourcing bordea con suerte la cota inferior de un informático semi-senior (por ponerle un nombre). Profesionales con más experiencia (léase seniors) van a preferir la contratación directa.
3. Finalmente, si lo que la empresa necesita es un profesional "senior" ¿qué rango de sueldo es el que se debe ofrecer? Si nos remitimos únicamente a la internacionalidad referida por el artículo, veamos también el costo de un informático extranjero (sin xenofobia, simplemente vean las caras de la gente en la imagen, sospecho que todos son indios). ¿Creen que es azar que las más grandes empresas estén contratando extranjeros? En Chile un informático senior, salvo casos extremos de desesperación por cesantía, no debiera aspirar a un sueldo de menos de USD$ 3500. Es muy raro que una empresa de outsourcing TI maneje sueldos sobre los USD$ 3000 .

No es solamente un tema de preparación de los profesionales, que sin duda es un elemento primordial al buscar profesionales bien capacitados. También hay un tema del mercado de profesionales, una cosa que cualquier empresa seria debiera estudiar antes de decidir poner una filial en cualquier  país, no se trata de solamente ver las posibles oportunidades de negocio.

Así como hay empresas de outsourcing que tienen un ejercito de nuggets y esclavos inexpertos dispuestos a trabajar por poco, también hay algunos sitios que buscan ofrecer buenas oportunidades y armarse de redes de profesionales bien capacitados. Get on board es uno de estos sitios. Como en todos lados se puede encontrar de todo, pero la mayoría de las veces se trata de avisos que requieren de perfiles bastante específicos, y con una oferta salarial casi siempre adecuada.
También hay algunas instituciones académicas que están enfocando la preparación de profesionales de carreras TI, desde una perspectiva más ad-hok a las necesidades de la empresa actual.

Así que no me vengan con que no pueden encontrar informáticos, sean al menos honestos y digan "No podemos encontrar informáticos que se ajusten a nuestro presupuesto", que es lo que realmente creo que sucede.

Nota al margen, ¿sitio web basado en Flash? Estimados señores de LUN.com , aparte de propiciar la envoltura de pescado con su diario, tampoco están haciendo (a nivel general) un mínimo de investigación. Flash está a la baja, digamos desde hace casi 10 años, pronto su sitio web va a quedar obsoleto (y esa asesoría es gratis).

Letra chica
IMPORTANTE: Se vuelve necesario aclarar que ni el autor, ni este blog no tienen afiliación con ninguna de las empresas ni organizaciones mencionadas.

Te tengo una oferta de trabajo: No gracias

Búsqueda de imágenes por Currículum vitae en Google

Este va a ser un artículo arriesgado, lleno de varias verdades, de esas que nos cuesta admitir, incluso quizás toque la fibra sensible de gente ligada a empresas de headhunting, siempre  pensando en ingeniería informática. No se cual sea la realidad de otras especialidades, probablemente sea muy diferente.

Trabajo como ingeniero informático en una empresa chilena, vengo haciendo desarrollos desde  1995 y algo creo haber aprendido en todos estos años. En una sola oportunidad (hace ya varios años) me vi en una especie de urgencia por buscar trabajo, y estuve cesante 2 semanas, gracias a una estrategia sincera-agresiva de postulación (postulaba por lo bajo a 30 ofertas cada día). He ido a muchas entrevistas, y después de algún tiempo me he dado cuenta que todas fallan en lo mismo:

Prueba de conocimientos técnicos

A veces te avisan, otras veces te  toma de sorpresa. Cuando saliste recién de la universidad, o cuando aún estás estudiando, tienes todos los conocimientos frescos. En ese entonces, si me preguntaban de SOLID, el principio de sustitución de Liskov, Dijkstra, algorítmos de búsqueda eficiente de texto, como recorrer un árbol binario de manera inversa, probablemente  sabría como responder. Curiosamente Amazon, Google y Facebook (entre las grandes empresas que recuerdo) basan buena parte de sus procesos de selección en pruebas técnicas de un nivel medio-alto, alto. Tanto así que hay libros completos que explican como prepararse para esas pruebas.

Si quiere leer un artículo que apunta sus dardos directo sobre ese asunto lea: https://medium.com/@evnowandforever/f-you-i-quit-hiring-is-broken-bb8f3a48d324#.98cfx1v4a

Si a mi me toca una prueba técnica, respondo con lo puesto, con imprecisiones, no de memoria. En una oportunidad perdí 2 horas de mi vida respondiendo un test para una postulación que iba desde comandos básicos de Linux, hasta SQL. Daba la impresión que ni siquiera los reclutadores sabían que necesitaban. De esa sospecho que aún habiendo contestado casi todo bien (eran preguntas insultantemente fáciles), finalmente no me llamaron ni para si ni para no por el rango de sueldo que estaba pidiendo (todo el perfil de empresa  penca que busca un mono que las haga todas por poca plata).

Yo ya no estoy para esos trotes, a mis casi 40 años he hecho cosas importantes, trabajado en proyectos grandes, resuelto problemas complejos, creado productos (desde cero), ya he dejado una huella. Eso ya aparece en mi Curriculum (en adelante CV), y no me da miedo que llamen por teléfono a esas empresas preguntando si lo que puse en mi CV es o no es verdad. Pídanme que resuelva problemas, pero no las recetas universitarias que uno se aprende de memoria para pasar el ramo.

Tengo la fortuna de haber construido una discreta red de contactos que sabe que es lo que soy capaz de hacer, y que en ocasiones requiere de mi experticia. Y soy de la postura que  si ellos confiaron en mi no puedo menos que  hacer bien mi trabajo. ¿Pruebas técnicas o sicológicas? ¡Si claro!, las hubiera reprobado todas.

Tengo amigos cercanos que estuvieron en procesos de selección, incluso me han ofrecido incorporarme a los equipos donde ahora trabajan, pero "Gracias, pero no gracias". No estoy para esos procesos.

¿Qué pasa con las empresas en Chile?
Quisiera pensar que  tratan de imitar a las grandes empresas TI de USA, es cosa de ver algunos procesos, como el del Banco de Chile, jornadas de semanas enteras 3 o 4 horas diarias enfrentándose a pruebas técnicas, o los avisos de Get on board buscando ninjas y superhéroes en X tecnología. Y eso descartando las pruebas sicológicas que determinan que eres el inepto técnico chuper-buena-ondi  más adecuado para el cargo.

Seguro que debe haber pruebas para determinar la capacidad de los postulantes para resolver problemas, ojalá relacionados de alguna manera con el cargo ofrecido. Todavía no veo pruebas de ese tipo.

Otras empresas funcionan en base a las recomendaciones, un criterio dado por nuestros propios pares, que determina si uno puede potencialmente servir para una posición. Y no es que por ser "cercanos" a quien te recomendó tienes tu puesto asegurado, la entrada viene con el ticket de recomendación, pero si te  echan de la fiesta es porque tu mismo te lo buscaste: uno tiene que saber hacerse valer.

¿Sirven los expertos en el "Libro de Petete"?
Mi respuesta es radical: Sirven sí y sólo sí son capaces de resolver problemas.
La capacidad de aprender a usar una herramienta desconocida en poco tiempo (no más de un par de horas) y construir una prueba de concepto funcional, que resuelva un problema específico (planteado como requerimiento), no es algo que te enseñen en los libros. O viene en la sangre o lo aprendiste con los años de circo.

Un experto de libro no necesariamente es un buen profesional, y ya escribí un poco sobre expertos/especialistas.


Mi experimento
Hace  algunos meses me contactaron unos ex-compañeros de Universidad. Sólo me sonaban de nombre de la Escuela. La oferta era trabajar para un banco internacional. Me entrevisté con un indio, en inglés. Con la dificultad que tuve para comunicarme respondí conforme a lo que me preguntó. Lo sentí incómodo, como molesto por tener que entrevistarme.
Como una semana después me entrevisté con un chileno, y al ver el matiz de la entrevista decidí explicarle que  si me iba a hacer preguntas técnicas en realidad los 2 estábamos perdiendo el tiempo, ya que yo soy más de resolver problemas mediante la aplicación a repetir lo que aparece en el libro. El enfoque de mi entrevistador cambió, me preguntó sobre los proyectos en que había participado, mi actual experiencia y obviamente sobre que áreas dominaba mejor.
De todas formas tuve que responder un test técnico, pero bastante aplicado.

Después de esa entrevista supe que mi decisión final ya no pasaba por un tema de lucas (que tan 'bien' me iban a pagar), sino por un tema de cultura de empresa. No me veía trabajando en una empresa donde tuviera que ir con  zapatos, pantalón de vestir y camisa, llegar a las 8 AM todos los días y sin un espacio para investigar sobre nuevas tecnologías. Menos ver ciertas complicaciones para poder llegar en bicicleta a esa oficina.

Las lucas pueden ser muy buenas, pero, como dijo un caído en batalla, "Hay cosas que no se transan". Y son precisamente esas cosas las que hacen que una oferta deje de ser atractiva para un ingeniero informático. Finalmente, después que me informaron que   iba a tener otra entrevista con otro indio decidí dar un paso al lado del proceso. "Gracias, pero no gracias".

¿Experimento?
Si, experimento. Después de un tiempo sin pasar por procesos de entrevista y ajustes de CV, me plantié seguir un proceso de selección, ver hasta donde llegaba, que tan "blando" estaba para enfrentar entrevistas y pruebas técnicas.
La verdad es que siento que tan mal no estoy, y enfrentarme nuevamente a un proceso que no destacó precisamente ni por su agilidad ni por su enfoque, hizo que valorara mucho más la oportunidad que se me ha brindado para trabajar donde estoy. Enumerando puntos no sacrificables:

• Puedo llegar en bicicleta
• Horario semi-flexible
• Posibilidad de trabajar desde la casa
• Ropa informal (zapatillas, jeans y polera)
• Espacios para la investigación (en todo caso esto es por lo que estoy resolviendo puntualmente, pasaron algunos meses antes de poder llegar a esto)
• Beneficios de salud
• Equipo no muy grande y de muy alto nivel técnico
• Metodologías de trabajo establecidas (quizás no las mejores, pero  con espacio para mejorarlas)
• Escritorio cómodo, ventana y juguetes (parece chiquero, pero trabajo feliz)

Imagen real de mi puesto de trabajo

Si su oferta puede igualar estas condiciones, quizás la piense.

El preocupante nivel de profesionales: La búsqueda fallida

Hace ya algunos meses comencé a trabajar en una empresa con un equipo de MUY alto nivel, gente que realmente sabe de que se tratan las cosas, gente que SABE. Todos, sin excepción, destacan en su especialidad, sin embargo la demanda del proyecto exige que el equipo crezca. Y es ahí donde el propio mercado de "profesionales" informáticos chilenos ha fallado.

Preocupante...

Luego de agotar los pocos contactos que todos aquí dentro teníamos, procurando siempre considerar que la naturaleza del proyecto requiere de gente buena en lo suyo, recurrimos a una conocida empresa de outsourcing. El fracaso fue exitoso.
Para poder poner un primer filtro se preparó un cuestionario de 7 preguntas, la premisa es:

Si usted pone que maneja (digamos) JavaScript y jQuery a nivel  "experto", deberá saber responder una pregunta de JavaScript y/o jQuery de nivel "experto"

Moraleja de esto: No mientan en el Currículum Vitae

Debo reconocer que las preguntas no son tan sencillas, sin embargo para poder "pasar" se solicitaba contestar bien al menos 4. La empresa de outsourcing informó que los "mejores candidatos" contestaban a lo sumo 3 preguntas.

Preocupante...

Entonces, ¿dónde está la falla?

Quisiera creer que la línea de corte que definió el equipo está demasiado alta, pero tampoco es tan así, los problemas a resolver no distan de problemas reales a los que alguna vez hemos enfrentado.

¿Es el nivel de los postulantes?

Sería muy radical responder que sí. Tristemente todo apunta a ello. Quizás sea un tema de manejo de presión (lo que tampoco favorece al proceso de selección, ya que es una realidad que trabajamos bajo presión), o simplemente falta de preparación para enfrentar una entrevista técnica.

Escuchar respuestas como:

• "Si me enfrento a un problema que no puedo resolver, espero que otro compañero más calificado lo resuelva."
• "No tenía idea que eso se podía...."  en relación a llamadas síncronas usando JavaScript
• o que no leen artículos de tecnología/codificación o afines

es desmoralizante cuando buscas "gente buena".

Sólo queda culpar a la formación. Las instituciones educacionales ya no forman profesionales con esa inquietud innata que los hace buscar y mirar más allá de la caja. Ser mediocre es aceptable y políticamente correcto (consideremos que como estudiantes se busca aprobar asignaturas con el mínimo).
Claro que se debe hacer una importante distinción. La excelencia no es algo que se enseñe, va en cada uno decidir ser uno más del montón u optar por destacar en lo propio. 

Pero la pregunta inicial sigue sin respuesta

En MHO hay responsabilidades compartidas, por un lado probablemente el enfoque de la búsqueda no sea el adecuado. Si bien se requieren profesionales de alto nivel, no necesariamente expertos, en realidad se debiese apuntar a ver el potencial de un postulante. Ligado al nivel de experticia, debe ir el potencial de cada postulante, donde se hace una apuesta por el compromiso, la capacidad de trabajar en equipo, bajo presión, etc. etc.

De los postulantes podría referirme a lo que se esperaría (que a lo largo de este artículo debiera haber quedado claro), pero nuevamente caigo en lo mismo: Depende de cada uno.
Puedes decir tener 10 o más años de experiencia laboral, pero puedes haber estado 10 años marcando el paso. Más años de experiencia no  nos vuelven   necesariamente buenos en lo que hacemos.

Y ¿dónde están los profesionales de alto nivel?

1. ¿En algún emprendimiento?
2. Fuera de Chile
3. Siguen estudiando
4. No existen
5. Ninguna de las anteriores

Personalmente  seguiré dejando esa pregunta en particular sin responder.

¿Qué tan frágil es tu organización?

Hace aproximadamente un mes atrás conversaba con mi ahora ex-jefe sobre que tan frágil es una organización. Básicamente porque mi rol en la empresa tenía cada vez más responsabilidades, y en caso de irme reemplazarme no sería tan sencillo. Hoy estoy trabajando en otra empresa, y créanme que la últimas semanas en mi antiguo trabajo fueron intensas.

Un artículo atrás hablaba del costo de la especialización, y la importancia de poder desempeñarse como un profesional versátil (busquen por fullstack developer para más referencias al respecto).
Si bien es cierto un fullstack developer resulta muy valioso para la organización, es también un riesgo, tan grande como su valor como profesional, puesto que inevitablemente habrá muchas tareas que le serán confiadas. Muchas veces, por no decir la mayoría, este tipo de profesional será el único quien se puede hacer cargo de muchas de las ya mencionadas tareas, o bien será el único que las puede resolver de manera rápida y eficiente.

Cuando se dió esta conversación con mi antiguo jefe, me señaló que si yo me iba, le sería muy difícil encontrar a alguien que pudiera cubrir mi posición. Similarmente si se iba otro compañero que se ha involucrado más en actividades de gestión que de desarrollo, la empresa se tambalea.
Paradojalmente unas semanas después recibí una oferta de aquellas que no esperas que se repitan, y la acepté. Es complejo ver como la empresa en la que has trabajado tiene que empezar a considerar el plan B para todas las actividades en las que estabas involucrado.

¿Ustedes tiene un plan B en caso de?

¿Qué tan frágil es tu organización?

Habitualmente se dice que una organización es tan fuerte como su eslabón más débil, pero ¿qué tan frágil es?
La fragilidad de una organización, empresa, e incluso emprendimientos ligados al desarrollo viene dada por cuántos son los soportes que sostienen las actividades clave/sensibles/de vital importancia, y cuanto es el riesgo que se debe asumir si alguno de estos pilares ya no está en el equipo.

Por ejemplo: Un emprendimiento cuyo norte es entregar un producto de software no debiera depender de una sola persona para hacerse cargo del desarrollo (o de la parte TI si quieren ampliar el concepto). Si esta persona decidiera no seguir, si no hay como reemplazar sus experticias, es probable que tengan que replantear el emprendimiento en si.

Si miramos a las empresas como el juego de la Yenga, la fragilidad podría verse como  cuantos palitos puedes sacar antes que la torre de derrumbe. Mejor aún, dependerá además de que tan abajo o arriba estén los palitos que sacas (obviando el hecho que una torre no representa precisamente una pirámide organizacional).

Y claramente hay muchísimos otros factores que influyen.

Porqué usar herramientas obsoletas puede perjudicar tu empresa

Hace poco más de medio año que estoy trabajando en una transnacional que ha cambiado su nombre 3 veces. La promesa inicial era innovación, proyectos atractivos y proyección a futuro. La triste realidad es que todos los desarrollos son sobre una plataforma tan probada y archi-probada que estancó su evolución.

El escenario:

• Un equipo de ingenieros, programadores y desarrolladores, con buena formación académica.
• Una empresa, con promesas muy atractivas
• Proyectos de diversa índole (siempre en el contexto TI)
• Una  plataforma históricamente probada

La combinación de estos  elementos, no debiera ser mala, y no debiera NO funcionar... PERO:

• Cada nuevo proyecto demanda funcionalidades que no necesariamente están cubiertas por la plataforma base.
• Los componentes de la plataforma base se van actualizando con el paso del tiempo, mejorándose y corrigiendo errores.
• La oferta laboral siempre ofrece propuestas que SI tienen innovación.

El éxito de un proyecto, y por transitividad de la empresa, no radica en la capacidad de cautivar a tus clientes con una plataforma que solo la empresa puede manejar y mantener. Radica en la capacidad de poder sacar adelante los desafíos a los que se enfrenten, de manera eficiente (ya definiré eficiente), y poder responder a los requerimientos del cliente.

¿Qué entendemos por eficiente? EFICIENTE  es no reinventar la rueda. la rueda ya existe y lo más probable es que el problema base que se resuelve esté solucionado de mejor manera de lo que se podría conseguir. Claramente hay cosas que hay que desarrollar, pero en lo relativo a los componentes base ya existen muchos productos con una madurez no despreciable y comunidades sólidas que los respaldan.

¿Qué sucede cuándo usas herramientas obsoletas?

• La mayoría de los errores que se puedan detectar se solucionan con alguna actualización de versión.
• Agregar nuevas funcionalidades implicará repetir un desarrollo que ya se incorporó en nuevas versiones.
• Te enfrentas a problemas no menores de rendimiento.
• Limitas el crecimiento de tus desarrollos, sobre todo si los niveles de acoplamiento de la plataforma son muy altos.
• No existe una comunidad que ofrezca soporte a tu plataforma.
• Basta un cliente que haga una auditoría sobre los códigos y la plataforma para poner en tela de juicio la filosofía de desarrollo.
• Y finalmente, si tu equipo abre los ojos, probablemente se dé cuenta que si no se mejora ese esquema "seguro y probado", se estancará profesionalmente. Y una empresa sin un equipo  que la sostenga no funciona.

Dejemos la resistencia al cambio a los clientes, y no como una constante dentro de las propias empresas, menos si son las propias jefaturas las que la amparan escudándose en tener al cliente cautivo.

Si insisten en sobrevivir en torno a desarrollos sobre plataformas obsoletas háganlo en caso que estén prontos a jubilar (y en realidad poco les interese la continuidad de la empresa), o si la vida útil de los proyectos desarrollados es baja (menor a un año).

En materia de TI, y siguiendo una línea de tiempo, se avanza hacia adelante. No te quedas estancado en un punto fijo, ni tampoco caminas hacia tus espaldas.

Web 2.0 y tus clientes - Parte 1

Hay empresas y particulares que captan clientes, promocionan sus productos y servicios, y han hecho su reputación en función de la llamada Web 2.0 , y que sin embargo no entienden, ni saben aprovechar su intrínseco aspecto social.

Lo ejemplificaré con 2 casos a los que me enfrenté, ninguno relacionado con el otro, con la salvedad de haberme afectado a mi.

Primer caso) Luthier del Sur

Uno de mis hobbies es tocar guitarra y bajo, y tengo a mi haber algunos instrumentos que por un tema de espacio tenía que almacenar en otra disposición. Navegando por internet encontré un luthier de la VIII región de Chile, Lutheria Vettan.
Debo reconocer que Víctor Rivera hace un trabajo increíble con la madera, y ha sabido sacar un enorme provecho del aromo australiano, árbol que crece casi como la maleza en la VIII región.

Mi requerimiento, comparativamente a lo que es construir un instrumento, era sencillo, un soporte de muro para 5 guitarras (en rigor 3 guitarras eléctricas, una guitarra acústica y un bajo). Algo como esto:

Lo contacté por primera vez el 5 de abril (fecha de mi cumpleaños) del 2011, y en esa oportunidad Víctor había ganado unos fondos concursables y debido a todo lo que estaba realizando no pudo atender mi requerimiento.
Comprendiendo la situación dejé pasar un mes y le recordé el tema. En esta oportunidad Víctor me solicitó comprar unos soportes metálicos para guitarra que encontré en una empresa llamada Vroka y lo hice. Esto fue la última semana de mayo de 2011.

A eso de mediados de junio, envié los soportes y supuestamente ahí empezaría el trabajo.
Después de darnos cuenta que estábamos pensando en soportes distintos determinamos que le enviaba los soportes, ya que él podría darles un mejor uso que yo, y que me depositara el costo. Siempre de buena fe. Como de todas formas yo necesitaba un soporte seguí confiando en el profesionalismo de la cabeza de Luthería Vettan. Durante Julio fueron varios correos del tipo "Estoy avanzando", "Ya te envió fotos de lo que llevo", etc. Finalmente en Agosto hice mi última consulta y me dijo que no había podido avanzar.

Decidimos dejarlo en nada, y sólo en enero de 2012 le consulté si podía visitarlo, ya que estaría de visita en la región, para hacerle nuevamente el encargo. Ese correo NO recibió respuesta.

¿Qué tiene que ver esto con la Web 2.0?

La Web 2.0 es la visión social de Internet, te haces de una reputación, muestras tus productos, haces de tu negocio algo con integración social.
Si como empresario, proveedor o emprendedor, adoptas esto como parte de tu negocio, mínimo que respondas acorde, y que no mates esta vía.

Ya que nuevamente me quedaba sin soporte en marzo de 2012 decidí intentar nuevamente, pero con otro luthier. Mestizo Luthier de Valdivia (al sur de Chile) había comentado en un foro que disponía de herramientas para hacer trabajos de tipo CNC en madera, y también tiene trabajos muy lindos.
Lo contacté, le envié un plano bastante rudimentario de como quería el soporte, confié en la experticia Luis Carrasco, el luthier, y cuento corto, los primeros días de abril tenía un hermoso soporte en mi poder.

Aquí la galería de fotos

Comunicación constante y transparencia desde el principio. Sin tanta promoción, Mestizo sabe como fidelizar a sus clientes.

Al poco tiempo, y dado que las redes sociales son bastante gritonas, y dado también que mi soporte de guitarras causó cierta revolución, Vettan publicó un comentario tipo "me copiaron el diseño/este diseño me resulta familiar", y yo, con cierta molestia arrastrada por casi un año, le dije que él mejor que nadie sabía porque las cosas se habían dado de esa manera. Por interno tuvimos réplicas, pero finalmente le pedí disculpas por el impasse.

Quiero dejar claro que no me cabe duda que Víctor Rivera, de Luthería Vettan, es un excelente luthier y artesano, por eso fue que lo elegí como primera opción y confié en el trabajo que ví en fotos y en su sitio web . En esta oportunidad simplemente no se dieron las cosas, y no se supo manejar a un cliente que se mostró más que paciente.
Culpemos a la distancia y al conocimiento informal del manejo empresarial y del marketing.

La Web 2.0 es un tema complejo, y no estoy hablando de diseño con brillos y reflejos, sino de la parte social intrínseca a la definición. Si adoptas este aspecto de la "mal-llamada" Web 2.0 entonces tienes que entender que si no eres el único proveedor, y no cumples, las mismas redes que te han hecho increíble publicidad pueden generar un innecesario ruido negativo.