 |
| 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.
