Entre los años 2006 y 2007, me tocó trabajar por primera con un profesional freelance. Estaba yo trabajando en la empresa Kepler como jefe del área de operaciones. Kepler se dedicaba a la recuperación de información desde dispositivos de almacenamiento digital, y para ese entonces éramos especialistas en la reparación de discos duros. Podíamos reparar placas de circuitos integrados (PCB), reemplazar los cabezales mecánicos de los discos, y reconstruir configuraciones de servidores con discos en RAID5.

Sin embargo, no éramos capaces de reconstruir la información de algunos pendrives con fallas en su placa electrónica. Podíamos sacar de la placa el chip flash NAND, que era donde se almacenaban los datos, y luego lo leíamos en un “flash NAND reader”. Pero los datos eran ilegibles, sólo eran números hexadecimales escritos en formato little endian sin estructura ni orden aparente.

Buscando la forma de solucionar el problema, fue que encontramos —no recuerdo como— un profesional en Rusia que decía ser capaz de resolver nuestro problema. Lo contactamos, y pudo acceder a la herramienta de manejo de datos —Winhex— a través de una sesión de “escritorio remoto”. No recuerdo exactamente cuando se demoró, pero no debe de haber sido más de un par de horas. Él definitivamente tenía los conocimientos necesarios para recomponer la estructura de datos, y así poder extraer los archivos y documentos del usuario.

Este episodio nos abrió los ojos en cuanto a la posibilidad de subcontratar profesionales hyper-especialistas en distintas áreas. En aquel entones, la plataforma que lideraba este servicio se llamaba Elance, seguida muy de cerca por la competencia oDesk. Finalmente ambas empresas se unificaron para formar Upwork, empresa actualmente valorizada en +1670 millones de dólares.

Outstaffing

A diferencia del modelo de Outsourcing, en el modelo de outstaffing es el cliente quien mantiene el control sobre los equipos externos. Esto claramente tiene ventajas y desventajas (leer más abajo), por lo que dependerá de la estrategia que se adecúe mejor al contexto de la empresa la que aportará mayor valor al desarrollo de software.

UPWORK

Upwork cotiza en bolsa de nueva york desde el 2018 bajo las siglas UPWK. El año 2019 la empresa reportó más de 14 millones de profesionales registrados.

Desde nuestro primer contacto con el profesional ruso, nos ha tocado contratar más 200 profesionales a través de Upwork. Existen 2 tipos de servicios de contratación a través de la plataforma: a “suma alzada” y por “hora”. Todas las personas “freelance” están obligadas a definir un precio por hora, valor que es visible para los clientes que deseen contratar. La siguiente imagen muestra en su lado izquierdo el perfil del profesional Ruslan Mukhatvov, su tarifa por hora (200 USD) y una breve descripción de su experiencia (como que tiene un Ph.D. en matemáticas ?). A la derecha se pueden revisar los comentarios de otros clientes en sus más de 70 trabajos, y el detalle del trabajo realizado y la tarifa acordada. Podemos ver que entre el 2020 y 2022, Ruslan trabajó 203 horas en un proyecto de integración, por el que facturó más de 200k USD.

Caso de Negocio

Debo confesar que me tocó trabajar con Ruslan, y soy definitivamente un admirador de su trabajo. Fue el 2016. Un conocido de la Universidad supo que yo estaba trabajando en proyectos de desarrollo utilizando este modelo de apalancamiento con personas freelance. Mi amigo trabajaba en una empresa de retail B2B, y tenía un problema grave de performance en su plataforma de ecommerce. El tiempo de carga del carro de compras era superior a los 2 minutos —los carros tenían en promedio más de 90 SKUs—. Habían tratado de solucionar el problema con 2 agencias de desarrollo de software, y no había sido posible. El código de la plataforma era inentendible, y el desafío era enorme.

Fue entonces que conocí a Ruslan a través de Upwork. Yo buscaba una persona con alto talento y experiencia en desarrollo en esta plataforma en particular. Ruslan, en menos de 1 mes, fue capaz de reescribir todo el código que estaba generando problemas logrando reducir el tiempo de carga desde los 2 minutos a 15 segundos. Fue maravilloso ver la felicidad de los interesados. Quedaron tan contentos con la forma de trabajar, que propusieron reemplazar parte de su equipo interno de desarrolladores por profesionales externos. Y así fue. Al poco tiempo se implementó una plataforma de gestión del conocimiento y de gestión de tareas, y se incorporaron, poco a poco, más de 15 profesionales en forma de freelancers.

Beneficios del outstaffing

Esta metodología de trabajo con profesionales freelance, tiene múltiples beneficios. Aquí les dejo lo que me a juicio son las principales ventajas:

Alcance

Acceso a hiper-especialistas. Actualmente son muy diversas las áreas de especialización en el desarrollo de software, que es imposible contar con perfiles expertos “a tiempo completo”. Un experto tiene al menos 5 años de experiencia en un área en particular. Muy pocas empresas van a contar con expertos para cada lenguaje de programación (Rust, Go, Ruby, Java, Flutter, Phyton, etc) o ingenieros certificados en cada área, como redes, infraestructura cloud, machine learning, data pipelines, inteligencia artificial, seguridad, etc. Sin embargo, una Pyme sí puede subcontratar pocas horas de cualquier profesional experto. Y ya lo están haciendo.

Profundidad

Para un mismo rol, existe cientos de candidatos. Algunos con poco experiencia, y otros con mucha experiencia. Algunos certificados, otro no. El precio por hora por tanto, varía según el expertise de cada profesional. Así para un mismo rol, he visto profesionales Junior que cobran alrededor de 20 USD/hora, mientras que Ingenierios más Senior puede cobrar más de 100 USD/hora para el mismo rol.

Esto es muy bueno para las empresas, ya que les es posible adquirir el nivel de profesional que mejor se adecúe a su contexto y/o presupuesto. Algunas empresas prefieren contratar varios profesionales Junior para que sea supervisados por 1 profesional Senior, o bien otros prefieren contratar sólo profesionales Senior. Cada empresa puede conformar el equipo de desarrollo según las capacidades y experiencia que requieran. ¿Que mejor?

Pago por horas.

Si bien existe el modelo de contración por "suma alzada", diría que es más eficiente el modelo de contratación "por hora". Si bien las personas tenderán a sobretrabajar para cobrar más horas, la calidad de los productos y servicios será la que defina la empresa. Es decir, la empresa (o el cliente) mantendrá el control del desarrollo, ya que las personas trabajarán en lo que se les solicite.

En el modelo a "suma alzada" en cambio, las personas trabajarán en entregar el producto con el menor tiempo trabajado posible. Y esto muchas veces significa una menor calidad de desarrollo.

Control de Tiempo

En efecto, al contratar a un profesional por hora, éste marcará el inicio y fin de su trabajo a través de un herramienta de reloj control. Si por algún motivo la persona no está utilizando el mouse o el teclado, el reloj se pondrá en pausa automáticamente. Además, la herramienta de control tomará capturas de pantalla cada cierto tiempo, lo que permitirá validar que la persona haya estado efectivamente trabajando en mi proyecto en las horas que esté cobrando. Con todo este control, al final sólo estaremos pagando las horas reales trabajadas, y evitaremos pagar por horas no trabajadas..

Escalamiento ilimitado

A través de la red de profesionales de Upwork es posible acceder a millones de perfiles de profesionales, lo que permitirá agrandar o achicar los equipos de desarrollo según las necesidades.

Estabilidad

La relación en el largo plazo, es más estable y duradera con personas freelance que con personas in-house. Cuando trabajas con un profesional freelance, tú eres su cliente. La retención de los profesionales freelance es mayor que la de los asalariados, debido, entre otras cosas, a que el especialista se transforma en un proveedor del cliente, y, por consiguiente, obtiene mayor libertad de acción, puede trabajar con múltiples clientes y obtiene mayor valor por sus servicios sin un intermediario. Está feliz. Por el contrario, la competencia por la retención de talento de profesionales in-house es altísima. Literalmente las empresas se pelean por el talento adecuado. Y varios reportes muestran que las “big tech” se llevan gran parte de la torta ofreciendo jugosos estímulos. Y esto, sin considerar el “hoyo” que dejan los profesionales cuando abandonan un proyecto.

Desventajas del Outstaffing

También hay desventajas en el modelo de trabajo con Freelance:

• Toda la comunicación debe realizarse en inglés y por escrito. Si bien hay profesionales de habla hispana, para extender y potenciar el trabajo de los freelance es necesario que todas las comuniciones y requerimientos se realicen en inglés. Esto aumentará el número de interesados para trabajar en el proyecto.
• No funciona bien con una baja cantidad de horas. El modelo de outstaffing está pensando para proyectos de mediano y largo plazo. En general, el costo de capacitación inicial es alto en cualquier proyecto de tecnología, y, por lo tanto, no conviene para proyectos de pocas horas.

Tendencias del mercado

Vale la pena destacar brevemente algunas tendencias de mercado respecto del desarrollo de tecnología y el rol de los profesionales freelance. Algunos datos:

• Ya en el 2020, el 43% de los dueños de empresa en USA planificaba la contratación de profesionales freelance para cubrir el “gap” de talento.
• El 2022, una encuesta de MassChallenge mostraba que el 73% de las empresas de tecnología operaba con un modelo híbrido entre desarrolladores in-house y freelance. Además, el 71% consideraba que los profesionales freelance habían aumentado su agilidad.
• Un reporte de la empresa Upwork el 2022, mostró que el 79% —de los más de 1000 empleadores encuestados— estaba de acuerdo en que el trabajar con profesionales freelance promovía la innovación dentro de la empresa, y el 85% de que accedían a expertise y talento calificado. El 66% de los empleadores planificaba aumentar su dependencia de freelancers para los años 2023/2024.

Por otra parte, la “batalla” por la búsqueda y retención de talento altamente especializado ha mostrado que las grandes empresas de tecnología superan a las pequeñas con mejores salarios y beneficios.

Asimismo, los profesionales de tecnología ya no están cómodos con un trabajo fulltime. El 60% cree que disminuirán los empleados fulltime en el corto plazo. De acuerdo a PwC:

“Las grandes empresas se han visto superadas por un mundo digital repleto de pequeños emprendedores. Las plataformas digitales permiten juntar a ‘trabajadores con empleadores’, ‘capacidades con demanda’, ‘capital con innovadores’ y ‘consumidores con proveedores’. Esto permite a los pequeños emprendedores llegar mucho más lejos que su tamaño en términos de influencia y escala.”

En definitiva, los profesionales freelance están para resolver problemas bien definidos, acotados, y para el cual son expertos. Por el contrario, si le pedimos apoyo en otra área, seguramente accederán, pero sería como pedirle a Iván Zamorano que jugara de defensa. Sin duda podrá hacerlo, y hasta podría parecer que lo hace bien, pero ese no es su expertise.

Por otra parte, tampoco es aconsejable usar el precio más económico como criterio de adjudicación por un profesional. ¿Acaso preferirías contratar a Ben Brereton en vez de Erling Haland ? Ambos son futbolistas profesionales, y juegan en el mismo puesto, pero el precio de Brereton es muchísimo más bajo que el precio de Haland. El punto es, que existe una gran dispersión de precio por la contratación de un talento especializado, y un menor precio típicamente está representado por un profesional con menos experiencia y capacidades.

El diseño de servicios o aplicaciones considera muchísimas variables. Algunas dependen de la cultura de la empresa, otras de las capacidades del equipo técnico y otras de los procesos de negocio, entre otras. ¿Pero qué capacidades hacen que un equipo de desarrollo de software sea exitoso? Este tema ha existido desde hace mucho tiempo, y por lo mismo existen innumerables estudios al respecto.

Por ejemplo, un estudio de Google del 2015 entrevistó a más de 200 personas de 180 equipos distintos de desarrollo. Buscaba comprender cuáles eran los atributos determinantes de los equipo de alto rendimiento. Se pensaba que encontrarían un receta con las características y capacidades individuales que formaban un equipo exitoso. Algo así como profesionales excepcionales, como un Messi o un Cristiano Ronaldo, pero computín.

El resultado mostró sin embargo, que más que la nivel o capacidad de una persona en particular, los equipos que destacaron debían su éxito a la colaboración y dinámica de los equipos.

—“Who is on a team matters less than how the team members interact, structure their work, and view their contributions.”, Google, 2015

En definitiva no sirve un jugador extraordinario que juega sólo, por bueno que sea. Si un desarrollador es algo así como el Chino Ríos de la programación, no sirve de nada si no va a trabajar en equipo.

Así como el estudio de Google, han existido muchos otros en busca del Santo Grial; la receta ideal que conforman equipos de desarrollo de excelencia.

Uno de los tantos estudios, pero muy respetado y sugerido, es el que comentamos en el capítulo previo: el estudio sobre el desarrollo de software de excelencia de Nicole Forsgren y su equipo, que analizaron, entre los años 2017 y 2021, a más de 2000 empresas. Usaremos entonces este último estudio como la receta ideal para construir equipos de desarrollo de alto desempeño.

Bueno, el estudio de Nicole encontró 24 ingredientes o capacidades que compartían aquellas empresas de alto rendimiento en el desarrollo de software. En mi experiencia personal, comparto 100% los hallazgos de dicho estudio, y por lo mismo creo conveniente y necesario conocerlos.

A continuación revisaremos las 24 capacidades que tienen las empresas de alto rendimiento agrupados en 5 áreas: cultura organizacional, Continuous Delivery, Arquitectura, Producto, y Gestión eficiente.

1/5 Cultura Organizacional

5 principios o buenas prácticas para lograr una buena cultura organizacional, en pos de un mejor desarrollo de software.

Patagon ConsultingNicolás Mella

2/5 Continuous Delivery

8 buenas prácticas de Continuous Delivery presentes en las empresas líderes de desarrollo de Software.

Patagon ConsultingNicolás Mella

3/5 Arquitectura

Capacidades necesarias en torno a la arquitectura para un mejor desarrollo de software.

Patagon ConsultingNicolás Mella

4/5 Producto y procesos

4 buenas prácticas en torno a Productos y Procesos encontradas en las empresas líderes de desarrollo de software.

Patagon ConsultingNicolás Mella

5/5 Gestión eficiente

5 buenas prácticas presentes en las empresas líderes de desarrollo de software en cuanto a la gestión de proyectos.

Patagon ConsultingNicolás Mella

1. Cultura Organizacional

Ufff... La cultura organizacional es una pieza clave, si es que no la “piedra angular” que provee el espacio y entorno adecuado para que las personas puedan desarrollar su máximo potencial para un mejor desarrollo de software.

Existen muchos estudios respecto de los distintos tipos de culturas empresariales, pero aquí utilizaremos el del psicólogo Ron Westrum. Si bien su estudio de cultura organizacional (1998) estaba enfocado en el contexto de accidentes y sus riesgos, ésto se realizaron principalmente en empresas tecnológicas de industrias como la aviación y la salud. Westrum definió 3 clases de empresas:

• Orientadas al poder, —patológicas.
• Orientadas a la regla, —burocráticas.
• Orientadas al desempeño, —generativas.

Las empresas orientadas al poder se caracterizan por ejercer el temor y las amenazas. Aquí las personas tienden a acaparar o retener la información por razones políticas. O la distorsionan para quedar en mejor posición y ventaja que el resto.

La empresas burocráticas en cambio, se mueven por la regla. Típicamente cada área o departamento protege su “reino” con sus propias reglas. Es fácil de diferenciar este tipo de empresa; es cuando la regla es más importante que la misión. Hay que destacar que la burocracia en sí no es mala, pero su estructura inhibe y complejiza la colaboración de los equipos.

Por último, la empresas orientadas al desempeño o rendimiento están enfocadas en cumplir la misión a toda costa. Todas las decisiones están subordinadas al cumplimiento de los objetivos y al desempeño de los resultados.

Cada uno de estos 3 tipos de cultura empresarial tiene un efecto brutal en el flujo de la información. La información correcta, a tiempo y entendible, es crítica para la velocidad del desarrollo tecnológico, además de ser un indicador de que se prioriza la confianza y la colaboración entre los equipos. Al mismo tiempo, con mejor información se toman mejores decisiones, o, dicho de otra forma, cuando hay problemas éstos se levantan y resuelven más rápido.

Además, Westrum encontró como estas topologías de cultura organizacional estaban directamente relacionadas con el rendimiento de las empresas, y, por lo tanto, pueden considerarse como un excelente predictor sobre los resultados de la organización. Y esto aplica 100% al desempeño de las empresas en cuanto al desarrollo de software.

En definitiva, la cultura organizacional debe estar orientada al desempeño. Es evidente también que, en un buen ambiente empresarial, en que existe una cultura colaborativa y enfocada en el cumplimiento de la misión, los niveles de satisfacción laboral de los trabajadores son más altos que en aquellos organismos enfocados en la cultura orientada al poder o en el cumplimiento de las reglas.

2. Aprendizaje

Una cultura empresarial con foco en el aprendizaje se caracteriza por:

• Habilitar las instancias de aprendizaje.
• Apoyar las iniciativas de innovación.
• Aprender de los errores buscando la causa raíz —y no culpables—.

Una empresa pro aprendizaje estará continuamente apoyando el crecimiento personal de los profesionales. Se permite y fomenta la asistencia a seminarios o charlas sobre nuevas tecnologías. Se apoya a cada profesional con un programa de crecimiento o ampliación de capacidades a nivel individual. Los procesos de satisfacción laboral incluyen el seguimiento y cumplimiento de los objetivos de crecimiento planteados. En el fondo existe un plan para hacer que cada profesional adquiera las capacidades necesarias para llevar adelante su trabajo.

En paralelo a este programa de crecimiento personal, las empresas fomentarán los procesos de innovación para proyectos piloto o MVP. Promover la innovación implica muchas veces no inhibir o coartar las iniciativas o esfuerzos de las propias personas. Por el contrario, los líderes o jefes de área deberán motivar y promover las ideas innovadoras. Esto fomentará la curiosidad de los equipos, y al mismo tiempo generará un valioso aprendizaje. Y esto redundará en personas más motivadas.

No podemos quedarnos con frases como “No sé como solucionarlo”, porque siempre hay formas de buscar salidas. Hay que que buscar maneras de resolver, y no quedarnos atascados con lógicas como “siempre se ha hecho así”. Se trata de avanzar y no quedarse estancado. Siempre existirán oportunidades de mejora, y hay que estar conscientes de qué cosas nos gustaría mejorar.

—Si estuvieras a cargo de Clave Única, ¿que te gustaría mejorar?
“Me gustaría que también sirviese para registrarse en sitios privados, no sólo del Estado”
—Ok bien, ¿qué más?
<<pausa>> “Mmm.. no, nada más”

No es suficiente. Existen decentas si es que no centenas de funcionalidades o mejoras que podrían implementarse en un producto como Clave Única. No podemos contentarnos en dejar las cosas como están, al menos debemos tener en consideración posibles características que podríamos incorporar en  nuestro producto.

Hay que pensar y buscar ideas. Se trata de ser busquilla y analizar qué solución le dieron otras empresas a un problema similar al nuestro. Hay que leer documentación técnica e informarse. No basta con adoptar la idea o consejo que nos dieron. Se debe comparar y analizar.

Por último, la innovación no siempre implica “rocket science”. La innovación puede ser sumamente simple, como eliminar una reunión que aborda temas que ya están en la plataforma de tickets. Eliminar un proceso redundante es simple e innovador —además de ser gratis.

El principio KISS —“Keep It Simple Stupid”— busca resolver los problemas de forma SIMPLE y no rebuscada. Pero muchas veces, hacer las cosas más simples cuestan más. Hoy en día hay exceso de información, y a muchos les cuesta tomar decisiones porque esperan tener aún más información.

Por último, cuando se produce un error o un incidente, las empresas procurarán aprender y buscar soluciones a la raíz del problema, y no buscar culpables. El aprendizaje de los errores es parte del proceso de una cultura que aprende. Y, por lo tanto, las responsabilidades no deben ser individuales, sino compartidas.

Evidentemente que las iniciativas pro aprendizaje requieren de tiempo y recursos, pero por sobre todo, requieren un acto de fe, ya que los frutos los veremos más adelante —similar a la educación de un niño—. Y, por lo mismo, en paralelo con la formación y aprendizaje, se deben buscar los incentivos adecuados para la retención del talento.

3. Colaboración entre equipos

Como mencionamos al principio, la cultura de la organización debe enfocarse en el cumplimiento de los objetivos y la misión de la empresa. La motivación debe abarcar el equipo completo, y no grupos aislados.

Se debe evitar la trinchera del área o departamento. A veces es fácil caer en la tentación de retener información con tal de mantenerse útil e imprescindible. El ser humano tiende de forma natural a acaparar cosas y a no compartirlas. Excepto si ve un beneficio mayor, con lo que se abre a colaborar de forma proactiva. Por lo mismo, es importantísimo que existan los incentivos adecuados.

Estos incentivos deben estar planteados de forma grupal y no individual. Ello potenciará la colaboración entre los equipos y áreas, lo que mejorará el flujo de información, y, por ende, aumentará la eficiencia. Disminuirán las fricciones, mejorará la cohesión, y en definitiva aumentará motivación de los equipos al perseguir de forma conjunta una meta común.

4. Satisfacción laboral

La motivación, optimismo y energía de un equipo de trabajo no se alcanzan por la fuerza bruta, o por mandato real. Por el contrario, hay ciertas prácticas o procesos que generan ansiedad, estrés y agotamiento, y evidentemente, ello incide en la perdida de productividad.

Son muchas las variables que inciden en la satisfacción laborar. Pero en particular, el proceso de paso a producción de un servicio o aplicación es el mayor dolor de cabeza de los equipos y profesionales. Cuando un código pasa a producción, si no existe un proceso de integración continua, los equipos llevan sobre sus hombros la responsabilidad de los posibles errores. Y cuando estos procesos se realizan en horarios no hábiles, se genera una carga de ansiedad y estrés importante.

El burnout o agotamiento, es el cansancio mental, físico y emocional causado por el exceso de trabajo o estrés. No se trata simplemente de una sobrecargar laboral, sino de una especie de fatiga mental y física que impide al profesional mantener su trabajo. A veces viene con una sensación de desamparo, ya que no tiene el apoyo necesario para salir de donde está.

El proceso para alcanzar el burnout típicamente avanza lento, ya que no es algo que se gatille de un momento a otro.

Evidentemente que una persona en un estado de burnout es totalmente improductiva y golpea directamente el desempeño de la empresa. Cuando se presenta una licencia por estrés, la empresa debe asumir un costo altísimo para reemplazar al profesional.

En la industria tecnológica existe muchos casos de profesionales que literalmente “abandonan” el trabajo. Y no es por voluntad, es por un cansancio y estrés que van acumulando.

Por eso, el burnout debe prevenirse. Una práctica frecuente y necesaria, es la de limitar la carga trabajo, como se verá en el punto 21 de este listado.

Para cerrar el punto, la satisfacción laboral debe ser una métrica que se mida y se controle frecuentemente. Y, evidentemente, la empresa deberá tomar las acciones necesarias para habilitar las condiciones de un ambiente laboral seguro y atractivo para las personas.

5. Liderazgo

“The only way to do great work is to love what you do.”
—Steve Jobs

Aquí queremos mencionar algunos reconocidos principios sobre el liderazgo, rol clave que debería poner en práctica quien desee ser un buen jefe de proyecto. Antes que nada, un buen líder en ningún caso representa una “bala de plata” para el éxito de un proyecto, pero sí aumentará al máximo las probabilidades de llegar lo más alto posible.

Existe muchas definiciones de las capacidades que debería tener un buen líder, que no sería lógico abordar aquí, por lo que sólo me referiré a unas pocas que me a juicio son esenciales.

Cada cual, según su contexto y realidad, podrá poner en práctica estas habilidades, que, a diferencia de otras, son factibles de adquirir a través de la práctica. Este talento se desarrolla y se trabaja a nivel individual, pero a nivel grupal estará contagiando y motivando al resto de forma positiva y optimista.

Propiedad

Quiénes lideran un proyecto, deben ser y sentirse propietarios de él. Así, un buen líder pensará en el largo plazo y no sacrificará resultados de corto plazo por el valor del largo plazo.

A veces perdemos el sentido de propiedad cuando nos desligamos de problemas que puedan estar fuera de nuestro alcance. Si se “cayó” el servidor, no podemos pensar “es un problema de operaciones”, sino más bien debemos poner todo nuestro apoyo en solucionar el problema, entender qué fue lo que ocurrió, y buscar soluciones para prevenir que vuelva a ocurrir. Estamos presentes, activos y tomamos acciones que buscan obtener lo mejor para el proyecto.

El sentido de propiedad también implica ir más allá de lo estrictamente necesario. A veces nuestro aporte será simplemente llevar una taza de café para apoyar a alguien, a quién queremos decirle “me preocupa, y estoy contigo”.

Esto también significa que a veces debemos tomar decisiones duras y complejas que no a veces no son bienvenidas, como echar personas. Y, por lo tanto, nos tocará presentar y transmitir los hechos objetivos para explicar adecuadamente nuestro razonamiento y el porqué de nuestra decisión.

Por supuesto que para que exista una verdadera propiedad, esto implica que debemos estar totalmente empoderados y contamos con el apoyo de nuestros superiores. Debemos contar con la libertad de tomar la mejor decisión según nuestro parecer, sin mediar los intereses y objetivos de otros. De lo contrario, la propiedad se diluye.

Por último, el sentido de propiedad no sólo le corresponde al líder del proyecto, sino también a quiénes participan de él. Un ejemplo de propiedad es el siguiente comentario de un profesional “secundario”:

"Yo era su QA y no debían confiarme demasiado el código porque apenas sé lo que hago, pero cuando tuvieron unas semanas malas y nos estábamos retrasados con errores, sentí que tenía que ayudar. Empecé a pasar unas cuantas horas al día arreglando errores en vez de hacer pruebas. Eran bugs bastante simples, pero sentí que era un mejor uso de mi tiempo, en lugar de encontrar bugs que nadie tenía tiempo de arreglar. Hice todo lo posible por documentar las cosas con mucho cuidado para asegurarme de que mi ayuda fuera un real beneficio".

Comunicación

La comunicación, como en todo tipo de relaciones, debe ser abierta, segura, respetuosa, paciente y empática. Todos los integrantes del equipo deben poder expresar sus opiniones sin miedo a ser ridiculizados. Un buen líder guiará principalmente a su equipo en esta dirección a través del ejemplo, pero además,  habilitando las condiciones y espacios necesarios para que cada uno se pueda expresar de forma libre y segura.

Desarrollo profesional

Otra cualidad de un buen líder es la preocupación real por los integrantes de su equipo. Esto significa un honesto apoyo para que cada uno de los miembros del equipo pueda crecer y desarrollarse profesionalmente.

Y esto implica muchas cosas. Proveerá un feedback constructivo respecto de las mejoras y objetivos que las personas deben alcanzar. Priorizará, en la medida de lo posible, los espacios de aprendizaje e innovación. Cultivará una relación amable y respetuosa, que habilite un sano ambiente laboral. Pero al mismo tiempo deberá ser exigente y riguroso para que cada uno pueda dar el máximo de su potencial. También deberá saber delegar y confiar en el equipo, de tal forma de transmitir confianza y empoderamiento.

Continuación ...

Puedes seguir leyendo la continuación en el siguiente post:

2/5 Continuous Delivery

8 buenas prácticas de Continuous Delivery presentes en las empresas líderes de desarrollo de Software.

Patagon ConsultingNicolás Mella

6. Control de versiones

Si bien hoy en día la gran mayoría de las empresas utiliza herramientas para control de versiones como GIT, SVN o Mercurial, GIT es sin duda la más utilizada. Y en cuanto a las plataformas de gestión de versiones, destacan Gitlab, Github y  Bitbucket entre otras.

Ahora bien, seguro usted está ahora pensado... —nosotros ya usamos GIT para gestionar las versiones de nuestra aplicación—. Sin embargo, debe recordar que el control de versiones no sólo se refiere al código de la aplicación o servicio, sino también para la configuración del sistema, configuración de la aplicación, scripts de automatización y despliegue, y últimamente, infraestructura como código.

En la mayoría de las empresas no se suele versionar la configuración del sistema, o los scripts que ejecutan, sin embargo, se ha visto que las empresas líderes sí llevan el registro versionado de todos los elementos que componen sus servicios. De esta manera, tienen la historia e información completa de sus proyectos, haciendo que el seguimiento y gestión sea más sencillo.

7. Automatizar los pasos a producción

Esta práctica se refiere a la implementación de un proceso de despliegue automatizado a los ambientes productivos. Cualquier cambio en la aplicación, ya sea la incorporación de nueva funcionalidad, un cambio en la configuración, un corrección de un error, o un experimento, debe ser llevado a los ambientes productivos de manera segura, rápida y confiable, sin la intervención manual de una persona.

Para ello, el proceso, debe ser transparente para el usuario final, en la medida de que no exista una interrupción del servicio en ningún instante. Además, el proceso debe tener un bajo costo de ejecución, lo que habilita o permite que se realicen iteraciones de forma frecuente a lo largo del día. Al final y al cabo, son las herramientas y los computadores los ejecutan este tipo de tareas, liberando el tiempo de las personas.

8. Integración Continua (CI)

A veces es difícil entender un proceso sin ver lo que hace. La integración continua es de esos procesos que al verlo funcionar uno dice: guauuu, porque es ahí, donde “las papas queman”, donde se dimensiona lo importante y crítico de este proceso. Sobre todo cuando uno ha tenido que lidiar con engorrosos procesos de integración y pruebas de código.

Para poner el proceso de integración de código en perspectiva, es bueno conocer los dolores y problemas cuando el proceso es deficiente, es decir, el método antiguo de integración.

Durante las distintas etapas del desarrollo de software, los ingenieros al finalizar una nueva funcionalidad, deben mezclar —merge— el nuevo código con el código de la rama principal. Este proceso es lento y a veces complejo, sobre todo cuando la rama principal también ha sido modificada por otros profesionales. Cuanto más tiempo pasa, más complejo suele ser. El proceso puede tomar horas o incluso un par de días a una persona.

Una vez mezclado el nuevo código a la rama principal, el desarrollador deberá compilar el código para construir la aplicación. Este proceso de construcción es generalmente rápido, aunque dependerá del lenguaje y del tamaño del repositorio. Una vez compilado el código, la persona deberá ejecutar una serie de tests o pruebas, para validar que el nuevo código no afecte otras áreas del software.

Esta etapa de testing puede durar días o semanas. Sí, semanas; incluso con el apoyo de un equipo de 4 a 6 personas. Lo he visto en varios proyectos. Cuando la aplicación es muy grande, también lo es la cantidad de flujos y funcionalidades. Si a eso le sumamos la inexistencia de pruebas automatizadas, tenemos el escenario perfecto de ineficiencia. Sólo se validará el nuevo código implementado mediante la ejecución de un sin fin de pruebas funcionales. Este set de pruebas lo ejecuta entonces un pool de usuarios que realiza uno a uno los flujos o historias de usuario. Y así, después de una par de semanas, —y sólo cuando el resultado de las pruebas haya sido exitoso—, podremos estar seguros de que la aplicación funciona correctamente. Cualquier error implicará suspender las pruebas y devolver el problema al desarrollador para que sea corregido.

Todo el proceso de integración, construcción y testing que acabamos de ver, se puede empaquetar y automatizar. Eso es Continuous Integration o CI. Una vez implementado, el proceso de CI comienza a ser una rutina que también conlleva un componente cultural: los desarrolladores aprender a integrar con mayor frecuencia, lo que les permite encontrar y corregir errores más rápidamente. También mejoran la calidad del software y reducen el tiempo necesario para validar y publicar nuevas actualizaciones.

Por último, y para cerrar este punto, no siempre es factible implementar un proceso automatizado de CI. Se requiere tiempo. Tiempo para la construcción de pruebas unitarias y de integración, es decir, tiempo de calidad. Pero también este tiempo lo debe dedicar, idealmente, la misma persona que escribió el código. Es mucho más difícil escribir las pruebas de testing cuando ya ha pasado el tiempo.

Además, cuando no existen pruebas de testing, o éstas son muy pocas, tiene poco valor escribir una prueba que sólo cubrirá un bajo porcentaje del software. Aquí entra el concepto de teoría de la ventana rota.

En definitiva, la implementación de la Integración Continua debe darse desde un comienzo, y debe ser una práctica necesaria y obligatoria dentro el proceso de desarrollo, de tal forma que las pruebas tengan un porcentaje de cobertura mayor al 70%. Es un camino que se debe recorrer a través del aprendizaje e iteración. Por eso es que en software legado o en proyectos de desarrollo en que la práctica de CI nunca se ha ejercido, es que prácticamente imposible de implementar.

9. Desarrollo en rama troncal (master)

GIT es una herramienta para control de versiones de código, y hoy en día es indispensable. Todo el mundo la utiliza —o al menos debería, es lo mínimo. Pero, existen múltiples formas de trabajar las “ramas” con GIT. En algunas empresas se utiliza el estándar gitflow, en otras se crean nuevas ramas por cada nueva funcionalidad —“feature branch”—, pero las empresas líderes utilizan la opción de “trunk-based” o rama troncal.

Tanto el estándar de gitflow como feature branch requieren de un engorroso proceso de revisión o code review, ya que el incorporar las nuevas ramas en la rama principal muchas, a veces requiere de un buen tiempo de un ingeniero para resolver los conflictos entre la distintas versiones del código.

Por el contrario, el estándar de utilizar una única rama troncal o trunk-based, es la preferida por las empresas líderes. Cada profesional trabaja en ramas de corta duración, —de 1 o 2 días— que luego es incorporada en la rama principal. Este proceso sin embargo, requiere “pasar” un extenso proceso de testing automatizado, de tal forma que ante cualquier error, el desarrollador lo puede arreglar al momento.

En todo caso, vale la pena destacar que para pequeños equipos de desarrollo, —5 personas o menos— no importa mucho qué estándar estén utilizando. El estándar de trunk-based será realmente útil y eficiente cuando sean muchas las personas trabajando en un mismo código.

10. Automatización de pruebas (tests)

Dentro del flujo de integración contínua, o CI, existe un especial foco en la automatización de pruebas unitarias y pruebas de integración.

Es importante distinguir entre pruebas manuales y automatizadas. Las pruebas manuales las realiza una persona, haciendo clicks en la aplicación o interactuando con el software y las APIs. Las pruebas manuales son de alto costo, ya que requiere que alguien configure un ambiente y ejecute las pruebas por sí mismo. Esto queda expuesta a errores humanos, ya que la persona puede cometer errores tipográficos u omitir pasos en el flujo de prueba.

Las pruebas automatizadas, en cambio, las realiza un servicio o proceso que ejecuta un script de prueba escrito en el código. Estas pruebas pueden variar en complejidad, desde la comprobación de un único método en una clase hasta asegurarse de que la ejecución de una secuencia de acciones complejas en la interfaz de usuario retorne los mismos resultados. Las pruebas automatizadas son mucho más robustas y confiables que las pruebas manuales, pero la calidad de las pruebas automatizadas depende de lo bien que se hayan escrito los scripts de prueba.

A veces el conjunto de pruebas automatizadas no son confiables, ya que generan falsos positivos o negativos. Así, no sirven las pruebas automatizadas. Las pruebas deben ser confiables, y, por lo tanto, se requiere invertir tiempo de forma constante para mejorar y optimizar el conjunto de pruebas.

Cuando el conjunto de pruebas es confiable, y las pruebas pasan todos los controles, el equipo estará tranquilo y confiado de que pueden liberar la nueva versión del software a producción. Y al mismo tiempo, si la prueba falla, es porque existe un defecto real que debe ser corregido.

Como recomendación, si las pruebas no son confiables, deben sacarse del repositorio. Las buenas prácticas sugieren y fomentan que la construcción de las pruebas de aceptación las realicen las mismas personas que escribieron el código y no personas externas o de QA. Quienes desarrollan, conocen el código, y, por tanto, sabrán qué funciones o métodos son importantes de validar. Esto genera dos efectos. Por una lado se crea un sentido de responsabilidad, que hará que el desarrollador invierta tiempo en la mantención y corrección de las pruebas. Y por otra parte, el código tendrá una mayor cobertura de las pruebas realmente importantes.

Vale la pena mencionar que muchos jefes de proyecto, product owners, e incluso los mismos desarrolladores, desdeñan y minimizan esta práctica, considerándola muchas veces una pérdida de tiempo. Esto se da generalmente cuando las personas no conocen los beneficios y ventajas de las pruebas automatizadas, por lo que será importante capacitar y educar al equipo respecto de esta.

11. Test Data Management

Otro elemento que puede parecer burdo pero que en ocasiones es complejo, es la utilización de buenos datos para las pruebas automatizadas. Un buen conjunto de pruebas, requiere de un buen conjunto de datos. Aquí nos estamos refiriendo a los valores de entrada o “inputs” que nuestras funciones o módulos deberán testear.

La mayoría de las empresas utilizan los mismos datos del ambiente productivo, pero esto puede tener varias desventajas como el manejo de información sensible o pruebas acotadas.

Un buen conjunto de datos será mejor construirlo, y debe incluir no sólo valores de entrada, sino también condiciones y escenarios útiles que permitan validar el funcionamiento de nuestro código.

Además, los datos de pruebas no sólo se construyen para validar los escenarios positivos de nuestro software, sino también se deben testear posibles valores erróneos para probar el comportamiento de las excepciones de la aplicación. Por ejemplo, se suelen probar valores vacíos o en la blanco, o bien distintos a lo que solicita. Si en un campo se le pide al usuario ingresar su teléfono, ¿cómo se comporta si ingresamos sólo texto? También existen los casos de borde, como por ejemplo, la edad de un usuario de más de 100 años.

En definitiva, los datos deben ser de calidad y representativos, de tal forma de evaluar casos de uso real. ¿Tiene usted un buen conjunto de datos de prueba?

12. Seguridad

El tema de seguridad puede ser inagotable, tanto por la cantidad de elementos, como por la profundidad de cada uno de ellos. Dado que son muchas áreas, sólo se abordarán algunos conceptos básicos.

Otras áreas de seguridad que no abordaremos acá son: Cloud (redes, accesos, permisos), infraestructura (hardware, sistemas operativos, Privileged Access Management, etc).

Cyber amenazas

Los riesgos en materia de seguridad son diversos y evolucionan constantemente. Pueden ser muy básicos, o muy sofisticados. Los siguientes amenazas son bien comunes —casi diarias en algunos casos—:

• Ataques de phishing
• Malware
• Fuerza bruta
• Packet sniffing
• DDoS o  Denegación de Servicio Distribuido

El phishing consiste en engañar a las personas para que revelen información sensible haciéndose pasar por una entidad de confianza. Por ejemplo, enviando un email para que respondas una encuesta del ambiente laboral de la empresa en que trabajas. Un link al dominio “encuesta-laboral.tuempresachile.com” muestra una página con los colores corporativos y logo de tu empresa. Parece real. Pero al iniciar la encuesta te piden tu login y password corporativo para validar tu identidad. Sin embargo, lo que busca es recolectar tus datos para luego usarlos para acceder a los sistemas de tu empresa.

Las personas son típicamente el eslabón más débil de la cadena. Para empresas que tienen miles de usuarios, es altamente probable que varios de ellos “caigan” en la trampa. Por eso, para protegerse del phishing se sugiere:

• Capacitar a los empleados para que sean escépticos con los emails no solicitados. Si pide información sensible, lo mejor será desconfiar.
• Capacitar a los empleados para que verifiquen la legitimidad de los enlaces antes de hacer clic comprobando la URL.
• La empresa debe implementar filtros avanzados de email para identificar y filtrar posibles intentos de phishing.
• La empresa debe realizar pruebas de phishing, para validar la preparación de los usuarios.

Respecto del malware, este suele ser un virus que se infiltra en los sistemas para comprometer los datos o exigir un rescate por su liberación. El más famoso es el randomware, que ha afectado a cientos de miles de usuarios. Estos virus se suelen esconder bajo la apariencia de un archivo normal, por lo que se les conoce como “troyanos”. Básicamente se camufla como archivo adjunto o descargable, esperando ser ejecutado por el usuario. Para prevenir, las empresas suelen:

• Implementar soluciones de antivirus corporativos en todos los equipos.
• Actualizar frecuentemente los sistemas para parchear vulnerabilidades.
• Capacitar a los usuarios para evitar descargar archivos o hacer clic en enlaces de fuentes desconocidas.

Los ataques de fuerza bruta son repetidos intentos por ingresar a un sistema o aplicación probando distintas combinaciones de password. Para protegerse, las empresas deben obligar a sus empleados a:

• Utilizar contraseñas complejas y únicas para cada cuenta.
• Habilitar la autenticación de dos factores (2FA).
• Requerir la actualización de la contraseña cada cierto tiempo.

El packet sniffing es un método de detección y evaluación de paquetes de datos enviados a través de una red. Cuando nos conectamos a un red Wifi por ejemplo —en un cowork, en el metro, etc—, estamos transmitiendo nuestra información por el aire. Si dicha información no está encriptada, entonces cualquier persona podría ver dichos paquetes y acceder a información sensible. Básicamente nos estarían espiando y accederían a toda la información que transmitimos. Se recomienda:

• Utilizar conexiones seguras y cifradas (HTTPS).
• Evitar el uso de Wifi públicas para transacciones sensibles. Utilizar VPN.

Por último, el ataque de denegación de servicio distribuido (DDoS) es un intento malicioso de interrumpir el tráfico normal de un servidor, servicio o red con una avalancha de tráfico de internet. Los ataques DDoS logran su eficacia utilizando múltiples sistemas informáticos infectados como fuentes del tráfico de ataque. Desde un alto nivel, un ataque DDoS es como un gran taco vehicular que obstruye la autopista, impidiendo que el tráfico normal llegue a su destino. Estos ataques son dirigidos para botar un servicio en particular. Existen múltiples ataques famosos a empresas como AWS, Google y Github. Se sugiere:

• Habilitar herramientas de mitigación de DDoS.

Application Security — AppSec

Antes que nada, la seguridad de una aplicación no puede ser una actividad que se realice al final de un proyecto de desarrollo, sino que debe ser una parte integral durante el proceso de construcción y diseño.

Ahora bien, ¿que hacen los ingenieros de seguridad para prevenir las amenazas? O más bien, ¿que hacen para construir y desarrollar soluciones y aplicaciones seguras? Típicamente el diseño y construcción se evalúa de acuerdo a estos términos:

• Vulnerabilidad: Debilidad explotable en el diseño de un sistema.
• Amenaza: La posibilidad de que un agente explote una vulnerabilidad.
• Riesgo: Pérdida o daño que puede producirse cuando se materializa una amenaza.

El responsable de la seguridad de un software debe encargarse de:

• Prevenir y detectar de riesgos: Defiende los activos de la empresa: sus datos, aplicaciones, código, infraestructura, etc.
• Respuesta y recuperación: Reacciona rápidamente ante las amenazas y remediar los ataques.

Por último, una práctica muy común en aplicaciones de uso masivo, es contar con un programa de incentivos para la detección de errores o brechas de seguridad. Comúnmente se les conoce como “Bug bounty program for getting bugs”.

Zero Trust

La ideal del modelo Zero Trust no es otra que tratar a los usuarios internos como si fuesen usuarios externos. No se les entregan privilegios de accesos a los usuarios internos, ni tampoco éstos podrán saltarse los controles de seguridad. Bueno, claramente el diablo está en el detalles, pero en pocas palabras de eso se trata.

13. Continuous Delivery (CD)

El Continuous Delivery, o CD, es el conjunto de características que permiten que los cambios de una aplicación o software en su ambiente productivo sean de manera rápida, segura y confiable. Visto de otra forma, cualquier cambio al software, ya sea en su configuración, corrección de un error o en la incorporación de una nueva funcionalidad, que no interrumpa del servicio en ningún momento. Y por lo mismo, el CD es algo que puede ser realizado dentro del horario normal de trabajo, como parte de las rutinas diarias. Esto reduce tanto los dolores de los pasos a producción, como el burnout —agotamiento— de los equipos.

En el pasado era común reiniciar los servicios, o esperar que la nueva versión del software terminara de compilar, lo que inevitablemente implicaba una interrupción del servicio. Y por lo mismo, el proceso se realizaba en horarios no hábiles y se comunicaba a los usuarios respecto de la indisponibilidad de la aplicación en una “ventana de mantención” programada. Era una especie de evento tipo “big-bang”.

Como dijo W. Edward Deming en su popular libro “Out the Crisis” sobre los principios de gestión eficiente, “elimina la dependencia de la inspección para lograr la calidad”. Esto, llevado al concepto de CD, implica que a través de la inversión en la construcción de herramientas de testing —continuous integration—, es posible encontrar los errores rápidamente, y así éstos pueden se resueltos inmediatamente.

Por otra parte, se busca iterar en bloques pequeños, cambios de uno o dos días trabajo que puedan ser incorporados lo antes posible en la rama troncal —rama “master” típicamente—. Esto, que parece sin importancia, es vital para obtener feedback rápido de los usuarios. Así, evitamos un desvío, como realizar trabajo que no aporta valor para los usuarios, y podemos corregir el curso lo antes posible.

Todo este proceso de construcción, pruebas y despliegue a producción, debe ser un proceso automatizado que “vive” en el repositorio. Cualquier cambio en el repositorio gatillará el ciclo completo de revisión y testing, y ante una falla, el desarrollador lo podrá resolver inmediatamente.

Como las pruebas o testing son esenciales, deben trabajarse siempre como parte integral del proceso de desarrollo. La automatización de las pruebas unitarias y de aceptación deben ejecutarse cada vez que se realiza un nuevo commit (cambio) al repositorio.

La implementación del Continuous Delivery implica crear múltiples loops de revisión para asegurar una alta calidad del software que se está distribuyendo frecuentemente a los usuarios. Cuando se implementa correctamente, pasa a ser un rutina. Por lo demás, los procesos de pruebas son tareas que pueden y deben realizar los computadores por sí mismos, y así liberan de tiempo a los ingenieros, que podrán aportar valor en el diseño y construcción.

Mirado desde la perspectiva de los equipos de ingeniería, el Continuous Delivery debe entregar a los desarrolladores las herramientas para encontrar los problemas al momento, además del tiempo y recursos para invertir en la calidad del desarrollo, y la autoridad para corregir los problemas inmediatamente. Se crea un ambiente en que el profesional acepta la responsabilidad de su trabajo reflejada en la calidad y estabilidad de la solución.

Continuación ...

Puedes seguir leyendo esta serie de posts relacionados con la incorporación de las capacidades para un mejor desarrollo de Software. El siguiente post habla de las capacidades de arquitectura:

3/5 Arquitectura

Capacidades necesarias en torno a la arquitectura para un mejor desarrollo de software.

Patagon ConsultingNicolás Mella

Típicamente las discusiones en torno a la arquitectura tienden a enfocarse en el uso de tal o cual herramienta o tecnología. ¿Debería la empresa adoptar una solución de microservicios o arquitectura serverless ? ¿Usaremos Kubernetes o Apache Mesos?¿Qué framework o lenguaje de programación será el estándar de la empresa? Perdón pero, me parece que todas ellas son preguntas incorrectas...

Definir qué herramienta o tecnología deberá utilizar un equipo es irrelevante si las personas que la usarán la detestan. O sería intrascendente si la herramienta escogida no aporta en el cumplimiento de los objetivos que esperamos para la empresa.

14. Loosely Coupled Architecture

Lo que realmente es importante es que los equipos pueden realizar los cambios a sus productos y servicios sin depender de otros equipos o sistemas. Los arquitectos deben apoyar y colaborar a los equipos de desarrollo para alcanzar los objetivos de la empresa, proporcionándoles las herramientas y tecnología necesaria que les permita alcanzar dicha meta.

Por lo demás, los objetivos que deberían estar buscando las áreas de arquitectura son en torno a la escalabilidad, resiliencia y eficiencia. Y todo eso se logra en la medida en cómo se comunican los componentes y servicios entre sí.

Algunas prácticas comunes de los arquitectos deben ser:

• Definir los principios y prácticas recomendados para el desarrollo.
• Sugerir la tecnología adecuada para los proyectos estratégicos. O bien de qué tecnologías deberían abstenerse. Ojo, no se está imponiendo, sólo recomendando.
• Conocer y promover nuevas tecnologías que sean un incentivo para los MVP o experimentos.
• Generar instancias de colaboración con los equipos de desarrollo en donde se pueda dialogar y comentar abiertamente como se han tomado las decisiones de arquitectura.
• Tener todo el contexto del negocio para tomar buenas decisiones. Esto implica conocer en profundidad los procesos y flujos de negocio.
• Escribir documentación —RFC o RFC— referente a las decisiones que se tomaron para el diseño de la solución.
• Entregar ayuda y apoyo a los distintos equipos de desarrollo.

Por último, destacar que el costo es un aspecto sumamente relevante. No tiene sentido construir un tanque para matar una mosca. El diseño de la arquitectura debe ser proporcional al desafío.

Si implementamos una arquitectura independiente del resto de los sistemas, suceden 2 cosas. Primero, se optimiza los pasos a producción y aumenta la frecuencia y estabilidad del servicio, y a la vez disminuye el burnout del equipo. Segundo, el número de profesionales podrá aumentar, y así también aumentará la productividad.

15. Equipos empoderados

En la mayoría de las grandes empresas en Chile, los ingenieros deben escoger las herramientas y el framework de una lista de tecnologías pre-aprobadas. Esta lógica tiene los siguientes propósitos —loables pero erróneos—:

• Reducir la complejidad de los ambientes de desarrollo.
• Asegurar que todas las capacidades para administrar la tecnología estén disponibles en la empresa.
• Estandarizar procesos de capacitación, mantención y documentación. Lo mismo para la configuración de ambientes y la gestión de  infraestructura.
• Asegurar que toda la tecnología cumple con los criterios de seguridad y licenciamiento.

Sin embargo, existe una gran desventaja a este modelo de “camisa de fuerza”: impide que los equipos escojan las tecnologías adecuadas para el cumplimiento de los objetivos, y sobre todo, inhibe la innovación y experimentación con nuevas tecnologías que permitan resolver sus problemas.

El estudio realizado por el equipo de Nicole demostró y validó que la elección de la tecnología es una aspecto clave del trabajo técnico. Cuando los equipos pueden decidir que herramientas van a utilizar, contribuyen a mejorar el rendimiento del desarrollo de software, y por ende, en el rendimiento de la empresa. También otros estudios sugieren lo mismo, las ventajas de delegar la elección de la tecnología a los equipos supera sus desventajas.

Ahora bien, dicho lo anterior, sí hay un plano de estandarización necesario: la infraestructura. Facilita mucho la gestión de la operación de las aplicaciones una definición común en torno a construcción de los contenedores, un formato común de registros de errores, un formato común de “salud” de la aplicación, etc.

Continuación ...

Si quieres seguir leyendo esta serie de 5 posts, a contiuación seguimos con las 4 capacidades sobre el producto y los procesos.

4/5 Producto y procesos

4 buenas prácticas en torno a Productos y Procesos encontradas en las empresas líderes de desarrollo de software.

Patagon ConsultingNicolás Mella

Intro

Y bueno, si pretendemos un bueno desarrollo de software, no podemos dejar de hablar de lo crítico que resultan las buenas prácticas en torno a un buen desarrollo de producto.

¿Se está construyendo el producto adecuado para los usuarios?

Generalmente estas capacidades son de responsabilidad del profesional que lleva el rol de Product Owner, o dueño del producto. Esto rol típicamente lo desempeña un profesional del equipo Comercial o de Negocios, aunque en ocasiones también lo lidera un profesional del área técnica.

Podríamos decir que capacidades aquí descritas fueron “levantadas” de las mejoras prácticas de un desarrollo de producto “Lean”.

Las principales características y capacidades de un desarrollo de producto son 4:

• Levantar e implementar los comentarios de clientes.
• Visibilizar todos los flujos de negocios.
• Trabajar sobre funcionalidades pequeñas.
• Permitir la experimentación de los equipos.

El análisis de las empresas pioneras en el desarrollo de software encontró 4 características que vemos a continuación.

16. Feedback de los usuarios

Esta práctica implica que la organización o empresa esté activamente buscando el feedback de los usuarios. Idealmente debe ser un hábito frecuente y no aislado, que típicamente se realiza a través de encuestas de satisfacción, focus groups o a través de la mesa de ayuda. Pero existe una cultura —y proceso— que escucha y lleva “ese” comentario de cliente hasta el product owner. Luego se ponderará y priorizará el requerimiento levantado por el usuario de acuerdo a sus méritos.

Por supuesto que lo más importante es que se incorpore la perspectiva de los usuarios en el diseño de los productos. Tampoco se trata de realizar todo lo que pidan los usuarios, pero sí de escuchar, entender y evaluar constantemente al cliente como parte de un proceso de retroalimentación frecuente.

17. Visibilidad de los procesos y flujos de negocio

Los equipos de desarrollo deben tener un completo entendimiento de los flujos y procesos de negocio. Deben conocer —y entender—, todo el proceso por lo que circula un usuario, tanto los procesos actuales, como las ideas futuras del negocio. Por el contrario, muchas veces los equipos de desarrollo desconocen la lógica completa del negocio, o bien no están informados respecto de futuros proyectos. Las decisiones de diseño y construcción de aplicaciones, deben tomarse con toda la información necesaria.

Es importante destacar que los procesos de negocios deben estar escritos y documentados en una plataforma de fácil acceso. Sirve poco, que la información circule en un archivo word. Idealmente la documentación de negocios deberá incluir diagramas o videos que expliquen mejor los procesos actuales, pero también los desafíos o puntos de mejora.

Con información visible y entendible del negocio, será más fácil para los equipos de desarrollo hacer mejor su trabajo, y, por ende, tendremos un producto de mejor calidad.

18. Trabajo en lotes pequeños

Esta práctica implica la necesidad de trabajar en lotes de trabajo pequeños, idealmente en “ramas” de no más de 1 semana. Ello implica que las historias de usuario o funcionalidades que se desean implementar deben descomponerse en pequeñas historias. Por pequeño me refiero, a características que puedan ser desarrolladas en menos de 1 semana. Y luego, habilitando cada uno de estos lotes en producción, nos permitirá generar un loop rápido de retroalimentación de los usuarios.

Es esencial y clave este enfoque, ya que conoceremos rápidamente los resultados de nuestro trabajo, y, si estamos mal, lo podremos corregir cuanto antes. Es como el barco que navega en el mar, que si se desvía tan sólo 1 grado, nunca llegará a su destino. De igual forma, al iterar constantemente nuestros cambios a producción, tendremos antes el feedback de nuestros usuarios, y así podremos ajustar con mayor precisión nuestro desarrollo.

Visto del otro extremo, si nos demoramos 1 año en lanzar nuestra aplicación, 1 años nos tomará conocer comentarios reales de los usuarios. Si nos equivocamos en algunas funcionalidades del producto, “sólo” habremos perdido 1 año.

19. Experimentación en equipo

Esta práctica se refiere a entregar la debida autoridad a los equipos de desarrollo para que puedan crear y cambiar las especificaciones de requerimientos como parte del proceso de desarrollo sin la necesidad de aprobación. Esto es innovación y experimentación, ya que los equipos podrán poner probar ideas en base a sus descubrimientos o a los comentarios de los usuarios de forma rápida.

Por el contrario, cuando se obliga al equipo a construir los requerimientos al “pie de la letra”, muchas veces el resultado son productos poco atractivos. Si no hay espacio para mejoras rápidas, y para todo se requiere reuniones y autorización, se inhibe la iniciativa y decae la motivación.

Tampoco se trata de otorgar libertad total para que desarrollen cualquier cosa que se les ocurra, pero sí una combinación que permita a los equipos de desarrollo tomar decisiones de forma rápida y eficiente.

Contiuación ...

Y el último post de esta serie, son las capacidades para un gestión eficiente... ?

5/5 Gestión eficiente

5 buenas prácticas presentes en las empresas líderes de desarrollo de software en cuanto a la gestión de proyectos.

Patagon ConsultingNicolás Mella

20. Visualización del trabajo

Una gestión eficiente se sustenta en plataformas que permitan dar una visibilidad en 360° de todas iniciativas del proyecto. Esta visibilidad debe ser compartida con todo el equipo, y, obviamente, debe ser de fácil acceso. Si bien hay muchas plataformas que ofrecen este servicio, se deben privilegiar aquellas que puedan integrarse con el repositorio de código, de forma de asociar el trabajo técnico a la historia o requerimiento del usuario.

¿En qué tarea está trabajando el nuevo desarrollador?, o ¿qué tarea deberá realizar al terminar la actual?, o ¿qué bloqueos hay? son preguntas sumamente básicas, pero que en contadas ocasiones no están visibles.

Además de la visualización de las tareas y el trabajo individual de cada profesional, también deberá existir un canal de comunicación de calidad que permita que la información fluya de forma ágil y rápida. Si la herramienta cobra por el historial de las conversaciones u otra característica relevante, la empresa deberá pagar la tarifa del servicio para no restringir o limitar la comunicación.

21. Limitar la carga de trabajo

Es necesario establecer límites para regular la capacidad de trabajo. Es a través de estas restricciones las que habilitan las condiciones mejorar el proceso, y, eventualmente, aumentar la capacidad o límite.

Es uso de límites a la capacidad de trabajo es una practica común en el mundo Lean. No sólo existe, sino que es completamente visible para todos, y se utiliza generalmente para evitar el agotamiento o el exceso de carga de trabajo de los equipos. También permite exponer los obstáculos en la planificación.

Cabe destacar que el sólo hecho de definir un límite a la carga de trabajo no afecta el rendimiento de los equipos. Sólo cuando este límite se incorpora en los tableros de visualización —en un kanban o en el tablero de historias— y forma parte del proceso de retroalimentación con el equipo de negocios, es cuando se genera un efecto positivo en el rendimiento del desarrollo de software.

Por el contrario, cuando no se define un límite a la carga de trabajo —o WIP (work in progress), lo que sucede es que todos los indicadores de desarrollo comienzan a declinar. Sólo imaginen que el equipo de desarrollo está sobrecargado. Los tiempos de entrega aumentan, las revisiones son menos rigurosas y por lo tanto, más riesgo de errores. Como hay poco tiempo y mucho por hacer, se toman “atajos”. Finalmente se genera lo contrario de un círculo virtuoso.

Por último, señala que es difícil implementar un límite a la carga de trabajo en la cultura de las empresas de hoy, ya que es frecuente que éstas busquen aumentar la eficiencia en el uso del tiempo de los ingenieros. Y esto típicamente implica que los ingenieros no pueden tener tiempo libre, y que en todo momento deben tener “algo” que hacer, y por lo tanto, se le solicita todo el trabajo posible.

22. Notificación proactiva

Existen varias maneras de enterarse de un incidente en un servicio o aplicación. Por ejemplo, cuando son los mismos usuarios los que se comunican con la empresa para reportar un problema con el software. Otras formas de notificación son por medio del mismo data center o por nuestro propio servicio de monitoreo  y alertas. Todas ellas son notificaciones reactivas.

Las notificaciones proactivas en cambio, son advertencias previas al incidente. Generalmente corresponden a parámetros o métricas que superan cierto umbral que nosotros mismos hemos definido. Por ejemplo, cuando los CPU del servidor superen el 90%, o cuando el almacenamiento del disco supere el 95%, o cuando la memoria RAM exceda el 60%. O bien pueden ser métricas de nuestros servicios o aplicaciones; cuando el número de queries a la base de datos supere cierto número, o cuando el tiempo de respuesta de un API supera los 10 segundos, etc.

Adicionalmente, a alguien le deben llegar las alertas. Por lo mismo, es frecuente definir un equipo de “guardia”, que idealmente esté compuesto por los mismos miembros del equipo de desarrollo de la plataforma que estén soportando, de forma que cada persona tenga asignado un día de la semana para dar soporte en horarios no hábiles.

23. Monitoreo

Cuando existen muchas plataformas, aplicaciones y servicios distintos, y que, —en el mejor de los casos—, cada cual tiene se propia plataforma de monitoreo y registros, la visualización, alertas, notificaciones y registros se complejiza.

Y como no estamos aquí para reinventar la rueda, este mismo problema lo han tenido Uber, Google y todas las grandes empresas. La solución pasa por la estandarización de los volcados de registros (logs) y de la publicación de las métricas bajo una misma estructura. Luego todas las aplicaciones y servicios, independiente del lenguaje y sistema, podrán ser monitoreados bajo un mismo panel.

Existen varios estándares de publicación de métricas, pero me parece que esta carrera la está ganando Prometheus mediante la publicación de un endpoint por HTTP para la recepción de las métricas y registros. Así, cada servicio deberá publicar e informar sus métricas cada cierta frecuencia, las que luego serán consumidas por la plataforma de monitoreo de forma consolidad.

En este último grupo están herramientas como Kibana o Grafana, que por las métricas que llegan a través de Prometheus, permiten crear dashboards preciosos.

Todo esto sin duda se simplifica bastante con la utilización de contenedores y un sistema de orquestación de contenedores como Kubernetes.

24. Cambiar los procesos de aprobación

Todos las organizaciones tienen algún tipo de proceso para autorizar los cambios a los ambientes productivos. En los casos más simples, bastará con la revisión o aprobación de un colega para empujar los nuevos cambios. En los casos más complejos, existe un equipo, —distinto del que desarrolla—, que valida y certifica los nuevos cambios, que puede demorar días o semanas.

¿Qué funciona mejor? Bueno, de acuerdo al estudio en cuestión, las empresas líderes son aquellas en que no existe un proceso de revisión formal, o bien tienen un proceso sumamente simple —como la validación de un compañero—. Por el contrario, aquellas empresas en que sí hay un proceso de revisión y aprobación formal, aumenta el tiempo de puesta en producción, y por ende, no se genera el loop virtuoso de retroalimentación. Al mismo tiempo, tampoco existe una correlación en que las empresas con un proceso formal de revisión tengan una menor tasa de error como cabría esperar.

La recomendación entonces es tener un proceso simple y sencillo de aprobación para los cambios a producción. Basta con que sea validado por un compañero o par, que, combinado con la pruebas automatizadas de la integración continua, detecte y rechace los errores.

Al fin y al cabo, es el equipo que desarrolla quien tiene el conocimiento necesario para entender los riesgos y validar nuevos cambios. Delegar la aprobación a otro equipo sólo complejizará y retrasará el flujo de desarrollo.

¿Docker? ¿Kubernetes?

Todo el mundo hace un tiempo viene hablando de Kubernetes... hasta Dilbert:

En Chile también está de moda. Al menos podemos decir que suena moderno e inteligente, ? ¿Pero de qué se trata?

Contenedores ? Docker ?

Cualquier aplicación moderna debe ser posible encapsularla en un contenedor. Docker fue el pionero y es la solución que lidera la construcción y alojamiento de contenedores, pero también existen otras herramientas Podman y ConteinerD.

Un contenedor, es de modo muy básico, una alternativa a una máquina virtual. La gran diferencia es que en el caso de las máquinas virtuales, cada una necesita su propio sistema operativo (Guest OS en la imagen) y sus propios recursos de CPU y memoria RAM. Los contenedores en cambio, comparten el sistema operativo base (Host OS en la imagen), y por lo mismo, comparten los recursos de CPU y RAM. Luego un contenedor es mucho más pequeño que una máquina virtual, y eso lo hace mucho más flexible y eficiente de mantener. La siguiente imagen ilustra las diferencias entre una máquina virtual y una solución con contenedores:

Gestionar los servicios y aplicaciones con contenedores tiene sólo beneficios para la empresa. Algunos de ellos son:

• Menores tiempo de implementación y/o habilitación. ¿Se necesita desplegar la solución en otro Data Center? Bueno, con contenedores sólo debería ser cosa de minutos.
• Estandarización del ambiente entre los equipos de desarrollo. Sin contenedores cada desarrollador debe habilitar las mismas versiones de programas en su ambiente local, lo que muchas veces no ocurre. Con contenedores, los ambientes se levantan en los equipos de los desarrolladores en cosa de minutos.
• Mayor facilidad en la implementación de las prácticas de Continuous Deployment.
• En comparación las máquinas virtuales, los contenedores son más eficientes ya que comparten los recursos de CPU y memoria con la máquina base (host). Es decir, con contenedores se requiere menos costos de infraestructura.
• La estandarización de las aplicaciones en contenedores hace que sea más sencillo el uso de las herramientas de monitorización y notificaciones.
• Las aplicaciones cuando están en contenedores son más estables y resilientes, lo que les otorga confiabilidad al sistema, y por ende, tiene menor tasa de caídas o interrupciones.

Hoy en día la gran mayoría de las empresas utilizan contenedores para la administración de sus servicios y aplicaciones, por lo que se considera una tecnología mínima que todas las empresas deberían utilizar. En EEUU la adopción y migración a contenedores Docker ha crecido sustancialmente:

Orquestación de contenedores ? Kubernetes o K8s

Sin entrar en mucho detalle, Kubernetes es una herramienta gratuita desarrollada por Google para la orquestación de contenedores. ¿Y esto que significa? Básicamente que Kubernetes se encarga de mantener, soportar y gestionar los distintos contenedores. Luego Kubernetes será responsable de las tareas típicas que requiere la administración de contenedores, como por ejemplo:

• Reiniciar un contenedor cuando éste no responda.
• Apagar un contenedor cuando una nueva versión esté disponible.
• Escalar un grupo de contenedores cuando exista un peak de consultas.
• Asignar y administrar las IPs de los contenedores. Balanceo de carga.
• Monitorear el consumo de recursos de cada contenedor.
• Mover contenedores entre nodos cuando un nodo falla.
• Montar los volúmenes asignados a cada contenedor.
• Gestionar las variables de entorno que les corresponden al contenedor.

Y cientos de otras características que permiten otorgar confiabilidad y escalabilidad a los servicios. En pocas palabras Kubernetes es una solución moderna para la operación y administración de los contenedores. También hay otras herramientas para la gestión de contenedores como OpenShift o Docker Swarm, pero Kubernetes es las más utilizada.

Kubernetes es hoy en día un estándar y es altamente recomendable que todas las empresas lo adopten e implementen. Claramente habrá que buscar y desarrollar las capacidades para que los equipos puedan administrar esta herramienta, costos que sin duda se pagarán con sistemas más confiables y duraderos.

Migración a Kubernetes?

En Patagon, apoyamos a nuestros clientes en la migración de sus sistemas a contenedores y Kubernetes. Típicamente el servicio se desarrolla en 4 fases:

1. Discovery. Análisis de solución actual y levantamiento de información.
2. Diseño de propuesta de solución según los objetivos definidos.
3. Desarrollo y testing. Migración de aplicaciones a contenedores.
4. Implementación, puesta en marcha y capacitación. Monitoreo y soporte inicial.

Discovery ?

La primera etapa es esencial para evaluar la factibilidad y complejidad del proceso. El siguiente custionario lo utilizamos en el proceso de levantamiento de información:

Cuestionario migración a Contenedores

Cuestionario Cloud / Servicios ¿Cual es su proveedor de servicios Cloud? ¿Cuál es el costo mensual de facturación por los servicios Cloud? (Aprox.) Equipo Capacidades Roles Máquinas ¿Cuántas máquinas posee? (físicas y virtuales?) Separar el detalle por ambien...

Google Docs

Existen muchas variables y condiciones que deben ser evaluadas. Si las capacidades están presentes en el equipo, como están construidas las aplicaciones, si existen triggers en alguno horario, cuál es el número de usuarios concurrentes máximos, etc. Toda esta información es relevante para dimensariar y planificar correctamente la migración.

Por supuesto que también es clave definir objetivos claros y precisos. Se trata de alinear las expectativas y no creer que por migrar a Kubernetes se solucionarán otros problemas. Por ejemplo, muchas veces se piensa que el performance y velocidad de las aplicaciones y servicios aumentará con la nueva tecnología, lo que es totalmente falso. O que desaparecerán ciertos errores, o que se acabará la saturación a la base de datos. No, Kubernetes no arregla problemas de las aplicaciones.

Las siguientes fases del proceso de migración dependerán del contexto de la empresa y de la arquitectura de los sistemas. Si bien los plazos dependen de múltiples factores, en el 80% de los casos todo el proyecto de migración se realiza en 9 meses o menos.

Diseño de propuesta

Según los objetivos definidos en la fase previa, y de acuerdo al análisis de la situación actual de los sistemas y el contexto de la empresa, se realiza una propuesta de diseño con la nueva arquitectura y la planificación correspondiente.

Hay que considerar muchos aspectos: seguridad, storage, networking, pipeline de desarrollo, gestión de permisos a usuarios y sistemas, bóveda para almacenamiento de credenciales, DNS y dominios, puertos y accesos, etc.

Además de lo anterior, y lo más complejo de estimar, es el trabajo que se necesitará para migrar cada aplicación y servicio a su ambiente dockerizado. Esta tarea es más dificil porque se debe evaluar en detalle cada solución (software), y se debe dimensionar los esfuerzos de desarrollo para transformarlo en contenedor.

Desarrollo y testing

Esta es la fase más entretenida, y que más tiempo toma. Corresponde al trabajo duro en que se moverán los servicios y aplicaciones a contenedores en un ambiente de pruebas controlado.

Y por supuesto, está la fase de pruebas que corresponderá a una evaluación intensa del comportamiento de las funcionalidades de nuestros sistemas. Estas pruebas también consideran pruebas de carga o estrés, para validar que nuestra nueva plataforma soporte el flujo de carga definido.

Implementación

La última fase contempla la implementación de la nueva arquitectura en los ambientes de producción. Esto típicamente requerirá una "ventana" de mantención que permita migrar los datos desde las bases de datos antiguas a las nuevas.

Se realizarán los cambios de redirección en el DNS y con ello se desvía a los usuarios a la nueva solución.

Las primeras 48 horas hábiles son escenciales para adaptar y corregir pequeños cosas en la configuración de los ambientes, cambios que son necesarios para el óptimo funcionamiento de todo el conjunto de servicios. Al mismo tiempo se definen SLAs y todo el flujo de soporte que sustentará la nueva infraestructura. En algunos casos se sugiere implementar un plan de recuperación de desástres (DRP).

Finalmente queda lo mejor, apagar la infraestructura antigua... y mirar en la siguiente factura la reducción sustancial de costos.

Caso de Negocio ?

Felizmente nos tocó apoyar el 2021 a una empresa en la reducción de sus costos fijos operacionales relacionados con el pago de los servicios de AWS. Esta empresa, tenía un costo mensual promedio de ~5.000 USD por el uso de los servicios, es decir, 60 mil dólares anuales.

Hicimos nuestra tarea, y estimamos que podríamos habilitar una solución utilizando infraestructura propia en modalidad housing en un cloud privado, que a diferencia de un servicio cloud público como AWS, requerirá la mantención y soporte de los equipos.

Luego compramos los servidores, la memoria RAM y el almacenamiento. Implementarmos un cluster de Kubernetes y sobre él desplegaríamos las aplicaciones y servicios del cliente. El proyecto tuvo una duración de 6 meses.

• 3 x Servidores DELL PowerEdge R6515 48 vCPU: 8915 USD.
• 12 x Memorias RAM Kingston de 64GB c/u: 3.800 USD.
• Disco NVMe PCIe de 4TB como storage: 1600 USD.
• Profesional DevOps con certificacion en Kubernetes  – Habilitación de cluster de Kubernetes: 1600 USD.

Luego, la infraestructura y la implementación del cluster tuvo con único costo de implementación de 15.915 USD. No existió ningún costo de licencia. El valor mensual del housing en un data center en EEUU para los 3 servidores es de 200 USD/mes. La habilitación de los servidores fue relativamente rápida y menos de 4 semanas ya estaban operativos.

Ahora bien, el resto del proyecto fue la migración de las aplicaciones del cliente a ambientes dockerizados (en contenedores). La mayoría de las aplicaciones del cliente corrían directamente en en máquinas EC2, por lo que se debió refactorizar varias de ellas para llevarlas a Docker. Si bien este desarrollo fue parte del proyecto, no tiene sentido incluir dicho costo en la comparación ya que es parte de una modernización del diseño de las aplicaciones.

Queda un punto muy relevante, el soporte o mantención de los equipos. Alguien debe hacer los upgrades y aplicar los parches de seguridad a los servidores. Este servicio fácilmente se encuentra con profesionales freelance a costos relativamente bajos (~30 USD p/h), y no se requieren más de 10 horas mensuales. Es decir, el costo de mantención no debería ser mayor a los 3600 USD anuales.

En definitiva, la inversión de 15.915 USD en infraestructura se pagó con los ahorros en menos de 4 meses. A partir del segundo año, la reducción fue de un 90% (de 60k bajó a 6k). ¿Que tal?

Para mayor información respecto del servicio de migración, puede consultar el siguiente link:

Conclusión

Quizás faltó hablar un poco de los casos y excepciones en que no es conveniente migrar a contenedores. Si bien son pocos, hay escenarios en que la gestión con contenedores podría sería más dificil que con máquinas virtuales, o bien el performance podría verse degradado. Esto puede ser cuando los sistemas operativos de las máquinas virtuales tienen condiciones y características muy específicas y están adaptadas para corregir ciertas faltas en las aplicaciones.

Al margen de lo anterior, si bien la migración a contenedores puede ser dura y compleja en un principio para los equipos de desarrollo, los beneficios y ventajas no tienen comparación. Y la adquisición de las capacidades para adminsitrar contenedores deben traerse o enseñarse, pero son capacidades que deben estar presenten en las empresas de hoy.

Si están en proceso de migración, mucha suerte y éxito ! Esperamos que este tema se vuelva cada vez más recurrente en nuestro país.

Últimamente hemos recibido mucho interés y consultas respecto de cómo salirse de Oracle. Esta idea mucha veces es un deseo que tiene poco análisis y profundidad.
Oracle tiene más de 1000 productos...¿Cuál de todos? Bueno, típicamente se refieren a la base de datos -que es más que una base de datos-.

La migración de la base de datos es un proyecto factible, pero la segunda pregunta es: ¿Es factible que la aplicación utilice otra Base de Datos? Existen aplicaciones como PeopleSoft o Oracle E-Business Suite en que no es factible reemplazar la BD.

Si la aplicación soporta otro tipo de base de datos, entonces sí sería válido evaluar un proyecto de migración.

¿Porqué salirse de Oracle?

Si bien son varios los factores, el principal suele ser el alto costo de licenciamiento y la dificultad de negociar y encontrar soluciones con el equipo de ventas y soporte. A menudo Oracle se percibe como una empresa rígida, inflexible, y arrogante. Y no quieres hacer negocios con una empresa que te trata así.

Cuando Amazon anunció su interés de migrar y salirse de Oracle, esta fue la respuesta de su CEO Larry Ellison:

"Déjenme decirles quién no se está moviendo de Oracle, una compañía de la que han oído hablar que nos dio otros 50 millones de dólares este último - este trimestre para comprar Oracle Database y otras tecnologías de Oracle. Esa empresa es Amazon. No se están moviendo fuera de Oracle. Salesforce no se está moviendo fuera de Oracle. Nuestros competidores, a los que no tenemos ningún motivo para caerles muy bien, siguen invirtiendo y gestionando todo su negocio con Oracle. No sé quién está dejando Oracle. Tal vez Mark lo haga. Tal vez Safra. Pero Amazon - uno pensaría que Amazon realmente querría moverse".

Por otra parte, las cláusulas y políticas de Licenciamiento son vagas y poco claras. Clientes que han querido disminuir el cobro de licenciamiento reduciendo el número de CPUs (según se basa el modelo de pricing), terminan pagando lo mismo por "ajustes" de precio.

Casos de éxitos ?

Y bueno, finalmente llegó el día (2019) en que Amazon pudo migrar todas sus más de 7500 bases de datos de Oracle a Redshift, Aurora y DynamoDB, y el CTO de Amazon Werner Vogels señaló:

Ha sido el día más feliz del año.

Asi como Amazon logró salirse de Oracle, decenas de grandes empresas han logrado lo mismo. Sin duda que no es sencillo, pero la recomensa llega.

¿Hacia donde migrar?

Bueno, dependerá del contexto de la empresa y sus aplicaciones. Ha diferencia de hace 30 años en que Oracle era la única solución de alta disponibilidad, hoy existen decenas de proyectos de código libre como MongoDB, PostgreSQL y MariaDB.

Si bien hay casos de éxito de clientes migrando a soluciones como SQL Server, donde se han visto menos riesgos ha sido a la base de datos PostgreSQL.

¿Porqué migrar a PostgreSQL ? ¿Cuáles son los beneficios?

Antes que nada, si  bien PostgreSQL es una solución de código libre hay que destacar que recibe financiamiento y apoyo de empresas como Microsoft y Google.

Podemos destacar 7 ventajas o beneficios de PostgreSQL:

1. API. Los desarrolladores pueden acceder directamente a cualquier componente de la base de datos a través de la interfaz API.
2. Autenticación. Postgres admite una amplia gama de métodos de autenticación. Esto proporciona una mayor flexibilidad para la autenticación de usuarios y procesos.
3. Extensiones. Al ser de código abierto, existe miles de extensiones por parte de la comunidad que extienden las funcionalides y características de la solución a los más diversos ámbitos.
4. Languaje. Mientras que Oracle tiene un lenguaje de programación integrado llamado PL/SQL, Postgres no sólo tiene PL/pgSQL, sino muchos otros, así como un sistema de extensión que permite a los usuarios crear procedimientos adicionales como plug-ins, además de bindings para aún más lenguajes de programación.
5. Localización. Los servicios del sistema de localización de Postgres están integrados para proporcionar codificación automática de caracteres y métodos de colección.
6. Performance. Dado que PostgreSQL puede crear un número ilimitado de nodos en un clúster de lectura, el costo de cualquier operación de lectura puede reducirse a casi nada. Y por eso, es posible ajustarlo de forma diferente para cada carga de trabajo. En Oracle también se puede hacer esto, pero cada nodo tiene un costo adicional.
7. Escalabilidad. Postgres puede crear un número prácticamente ilimitado de nodos en un cluster de lectura, lo que generalmente es suficiente para soportar una gran cantidad de consultas.

¿Cuales son las fases de una migración?

Bueno, cada proyecto tiene sus características, pero en general hemos agrupado el proceso de migración de Oracle en las siguientes 5 fases:

1. Assessment. Fase de levantamiento y "discovery". Se revisa la compatibilidad de las aplicaciones, se revisa el código y la arquitectura de los distintos servicios que utilizan la base de datos.

Se evalúan los datos, procedimientos almacenados y funciones que puedan existir. Además se levantan la información historica respecto de usabilidad y performance. Esta etapa dimensiona la dificultad y esfuerzos que requerirá el proyecto, además de una estimación de los costos, y el equipo necesario para llevarlo adelante. También se diseña y propone la arquitectura de nueva solución de Postgres.

2. Migración de Schema. Se analiza la conversión de la estructura de datos o schema. Se requiere probar y evaluar las distintas herramientas disponibles para la conversión de la estructuras. Esta fase es larga y compleja por cuanto existen cientos de situaciones en que la transformación de la estructura de datos es sutil y no perceptible. Las relaciones entre tablas y la definiciones de los campos a veces parecen iguales pero no lo son.

3. Testing Funcional. Antes de seguir adelante, es importante probar el schema convertido en un conjunto de datos de muestra. Un enfoque recomendado es cargar algunos datos de muestra en Postgres desde un entorno de desarrollo o prueba  donde haya datos de muestra de producción y, a continuación, configurar una conexión de aplicación utilizando el acceso a datos (controladores) adecuado. Una vez que la aplicación se haya conectado a la base de datos, permítale realizar pruebas funcionales completas en los objetos convertidos con DML.

El testing funcional se itera y repite continuamente con el mismo conjunto de datos de muestra, tanto en la base de datos Oracle como en la Postgres y, hasta asegurarse de que los resultados SQL sean idénticos.

4. Testing de Performance. Las pruebas de rendimiento son importantes en la fase de migración porque algunas de las transacciones incorporadas en Oracle o la funcionalidad de las características pueden ser ligeramente diferentes en Postgres y la aplicación puede ver alguna diferencia. En esta fase, podemos capturar todas esas diferencias y solucionarlas a nivel de aplicación, acceso a datos (controladores) y base de datos con el ajuste adecuado.

5. Migración de Datos. Hay muchos métodos o prácticas respecto de la migración de datos. La más compleja es la "zero downtime" o réplica, en que ambos servicios de base de datos (Oracle y Postgres) están funcionando en paralelo. Pero también existe el "snapshot" en la que los se mueven sólo una vez durante una ventana de mantenimiento o interrupción del servicio.

Aquí se deben analizar los PROS y CONTRAS de cada uno, ya que son estrategias muy distintas.

Conclusión

Afortunadamente existen en el mercado más y más clientes que ha decido migrar desde Oracle a alguna solución de código libre. Estos casos de negocio confirman y validan que en la gran mayoría de los casos la migración son factibles, y que no existe inmedimentos para llevar a cabo la tarea.

En Chile existe pocos casos de migración de Oracle hasta otras bases de datos, principalmente por que muchas veces las empresas no tienen la capacidad de hacerlo, o porque no existen servicios profesionales que tengan las competencias. Afortunadamente en Patagon Labs trabajamos con Ingenieros DBA certificados, tanto en Oracle como en Postgres, profesionales que cuentan con experiencia en este tipo de proyectos.

¿Es factible medir la calidad y productividad de un equipo de desarrollo? Esta pregunta es de las más difíciles de responder ya que existen muchas variables y consideraciones que la mayoría de las veces son subjetivas. Algunos dicen que se puede, otros dicen que no.

Muchas empresas suelen medir parámetros asociados a la productividad y eficiencia de los equipos. He visto por ejemplo, número de líneas de código o pull requests por profesional, puntos de historia semanales (velocidad), número de errores reportados, encuestas de satisfacción de clientes, etc. Pero ninguna de dichas métricas se enfoca en los resultados de la empresa, y, por lo tanto, no dicen nada respecto del impacto sobre el negocio. Existe un foco individual o local, cuando realmente debería sería global.

Por el contrario, sí se puede medir la calidad y productividad de un equipo de desarrollo cuando existe un foco en los resultados —entre otras cosas—. Lo que definitivamente es más complejo de medir es el desempeño individual de un ingeniero de desarrollo.

Para abordar lo que llamaríamos un desarrollo de excelencia, tomaré como base el estudio que realizó Nicole Forsgren y su equipo en su libro Accelerate, que encontró 24 capacidades claves que mejoran el rendimiento del desarrollo de software.

Nicole realizó una investigación durante 4 años (2017-2021) para determinar las capacidades y prácticas importantes que aceleraban el desarrollo de software y entregaban valor a sus empresas. La evidencia se basó en la rentabilidad, productividad y valor de mercado de las empresas. Es decir, se correlacionaron esta 24 capacidades con los resultados de la empresa.

A través de rigurosos modelos estadísticos, se estudiaron más de 2000 empresas a través de más de 23.000 respuestas de usuarios. El estudio abarcó desde pequeñas startups, hasta empresas multinacionales con +10.000 empleados. Además se incluyeron empresas de todas las industrias, tanto del borde de la innovación tecnológica, como de sectores financieros regulados o de gobierno.

Midiendo el rendimiento del desarrollo de software

Algo ya hemos hablado de lo complejo que resulta medir el desempeño de un equipo de desarrollo de software. Generalmente las empresas se enfocan en medir la eficiencia y productividad de los equipos, y no en el impacto sobre la empresa. Veamos dos ejemplo comunes: número líneas de código y velocidad.

A diferencia de un escritor de novelas, el escribir más líneas de código no significa que exista un avance. Incluso, una persona podría eliminar líneas de código para simplificar una función o método, lo que sería mucho mejor. ¿No es preferible una solución de 10 líneas de código a una de 500 líneas ? Obviamente que sí. Luego, no podemos medir a los ingenieros de software por el número de líneas que realizan. Por el contrario, deberíamos premiar a aquellos que resuelven un problema con el mínimo código posible.

Por otra parte, el método de gestión ágil —muy de moda actualmente—, promueve la medición de la velocidad de desarrollo a través de los puntos de historia. A cada tarea o requerimiento se le asigna un número de puntos de acuerdo a la dificultad o esfuerzo que representa. Así, podemos medir la capacidad de nuestro equipo, y enfocarnos en como aumentar nuestra velocidad de desarrollo. Como las mismas personas que desarrollan son las que estiman el esfuerzo, éstas tienden a sobre valorar o inflar los history points.

Además, al ser una medición por equipo (local), desincentiva la colaboración con otros equipos de desarrollo.

El mismo estudio de Nicole Forsgren definió 4 variables que determinan el rendimiento del desarrollo de software: (No es parte de este libro validar la metodología o el análisis que utilizó Nicole y su equipo que determinaron como estas 4 variables miden el performance del desarrollo de software de una empresa. Para ello, sugiero remitirse al libro)

- “Lead Time for changes” —Tiempo para habilitar cambios en producción.
- “Deployment Frequency” —Frecuencia de pasos a producción
- “Mean Time to Restore” (MTTR) —Tiempo de reposición del servicio.
- “Change Fail Percentage” — Tasa de error en pasos a producción.

La primera métrica —Lead Time for changes—, es bastante común en la metodología “Lean”, y corresponde al tiempo desde que el cliente realiza un requerimiento, hasta que éste es satisfecho. Sin embargo, para el desarrollo de software, no se considerará toda la etapa de diseño, construcción y validación del requerimiento, sino sólo la etapa posterior, es decir, la de implementación, pruebas —o testing—, compilación y la subida al ambiente de producción. (Básicamente desde que se "empuja" el nuevo commit hasta que éste llega a producción)

La siguiente variable, “Deployment Frequency”, corresponde a la frecuencia con que nuevas características de software pasan al ambiente productivo. Una mayor frecuencia es mejor, dado que implica tener una retroalimentación más rápida de los clientes sobre la nueva funcionalidad recién implementada, y a la vez nos permitirá corregir el curso del desarrollo en caso de tener algún desvío.

Luego está el “Mean Time to Restore”, que es el tiempo promedio que toma a los equipos restaurar un servicio caído o con falla. Hoy en día, todas las aplicaciones de software moderno —desde Google para abajo— fallan en algún momento. Es inevitable. Luego, esta métrica permite medir el tiempo de respuesta de los equipos frente a un incidente.

Por último está el “Change Fail Percentage”, que es el porcentaje de falla de los pasos a producción. No sólo aplica a errores en los cambios del software, sino también es común presenciar fallas cuando se realizan cambios a la configuración de la infraestructura.
Bajo estás 4 variables, el equipo que realizó el estudio encontró los siguientes resultados (2017) para los distintos tipos de empresas:

Así, podemos agrupar claramente a las empresas sobre el rendimiento del desarrollo de software y su impacto en el valor de la empresa. Si no está claro, en el grupo de empresas de alto rendimiento están Amazon, Apple, Google, Meta, Netflix, Spotify, etc, pero lo más importante, también están pequeñas startups, empresas de gobierno, empresas antiguas. Es es decir, un desarrollo de alto impacto no depende tanto de los recursos de la empresa o del conocimiento de los equipos, sino más bien de si las condiciones y capacidades se pueden desenvolver adecuadamente.

El impacto del desarrollo de software en los resultados de la empresa

Bueno, todo el análisis de métricas que estamos viendo tiene un sólo sentido: ¿Cuánto afecta al desempeño de la empresa? El mismo estudio les preguntó a los encuestados que evaluaran el desempeño de la empresa en 3 dimensiones: rentabilidad, participación de mercado y productividad. Esta escala se ha utilizado en múltiples estudios para medir el rendimiento de las empresas, y está altamente correlacionado con las métricas de Retorno de la Inversión o ROI —Return Over Investment—.

En paralelo, también se abordó como impactaba un mejor rendimiento del desarrollo de software para alcanzar los objetivos de la empresa; objetivos que muchas veces no tienen relación con la rentabilidad o las ventas —para el caso de las empresas sin fines de lucro—.
Hoy en día cualquier tipo de empresa —privada, pública, sin fines de lucro—, depende de la tecnología para cumplir su misión y dar valor a los clientes de forma rápida, confiable y segura. Entonces, independiente de los objetivos de la empresa, el cómo funciona su proceso de desarrollo tecnológico será un buen predictor del desempeño de la empresa.

Luego, el hecho de que el rendimiento en el desarrollo de software incide directamente en el rendimiento de la empresa, es un fuerte argumento para no externalizar el desarrollo de software que sea estratégico para la empresa, sino que por el contrario, se deberán incorporar las capacidades en el corazón de la organización.

Similarmente, todas las herramientas y aplicaciones no estratégicas podrán ser adquiridas bajo la modalidad SaaS, como las herramientas de ofimática, sistemas de pago de remuneraciones, mesa de ayuda, etc.

En definitiva, es clave distinguir qué sistemas son estratégicos para la empresa, ya que ellos deberán ser gestionados con equipo “in-house”, y no con terceros.

Jean-Michel Lemieux, CTO de Shopify/Atlasian, twiteó en febrero del 2024:

“Me he retirado del proceso de software. Nada de scrum, DDS, TDD, standups, DevOps, SRE, microservicios, retrospectivas, pre y post mortems... En lugar de eso, simplemente construimos y ejecutamos software juntos. Utilizamos un gestor de incidencias y un buen Readme. Todos publican una actualización diaria a nuestro grupo con una demo o ideas sobre su día. Simple y sencillo. Es pura felicidad”

Es muy bueno este tweet del entonces CTO de Shopify Jean-Michel Lemieux. Jean-Michel notó una enorme disminución en la velocidad de desarrollo para liberar nuevas actualizaciones en Shopify. Por eso, durante 6 meses eliminó muchas de las actividades típicas en la gestión de proyectos, y, como era de esperar, su velocidad de desarrollo aumentó considerablemente.

En esta entrevista, él mismo señaló:

“La lentitud en los equipos de desarrollo se debe muchas veces a la gran cantidad de procesos no técnicos. Teníamos mucha gente ocupada en la planificación que demandaba actualizaciones de avance, estar alineados con el roadmap, etc. Así, teníamos más y más reuniones que no eran de desarrollo de producto. En el fondo, teníamos personas responsables de la planificación, juntándose con los ingenieros que construían el producto, para que éstos les explicaran cuando iba se iban a demorar, generando un cuello de botella por la excesiva planificación para la capacidad de desarrollo. En definitiva, estábamos sobreplanificando.”

Esto no quiere decir que no haya que planificar, sólo planificar lo suficiente. Tener solo las conversaciones sobre lo que construiremos el siguiente mes podría ser un punto de partida. Fijar sólo 1 hora a la semana con los bloqueos.

De cierta forma, los ingenieros tendemos a creer que un proceso siempre será mejor. ? Es decir, debe existir una forma “correcta” de trabajar y queremos apuntar a ella. Con los años, hemos sido adoctrinados en que la planificación reduce el riesgo, sin embargo, según Jean-Michel, es la velocidad del delivery la que reduce el riesgo.

En pocas palabras, estando en Shopify, Jean-Michel llegó a la conclusión de que lo que realmente importaba para mejorar la velocidad de desarrollo, eran las decisiones —importantes— que hacían los ingenieros al escribir el código. En el fondo, la arquitectura de las soluciones que implementan los ingenieros representaba la estrategia de la empresa. Luego, ¿porqué no pasar más tiempo conversando sobre los desafíos técnicos, que haciendo seguimiento a las personas, contando las historias de usuarios, etc?

Ufff, tengo que decirlo, aunque no les guste, pero en un 90% de los casos lo mejor será desarrollar una plataforma monolítica. Por favor olvídense de los micro servicios. Ya está, fue dicho.

No se trata de gustos o de la moda, sino de ser eficientes y abordar los problemas con soluciones prácticas. Actualmente se escucha mucho acerca de implementar proyectos utilizando microservicios, incluso en empresas pequeñas que están comenzando nuevos negocios.

Haciendo un poco de historia, el 2014 fue el año en que Martin Fowler y James Lewis publicaron un artículo muy innovador en cuanto a un nuevo concepto de arquitectura: microservicios.

Muchas empresas adoptaron esta estrategia, entre ellos Uber y otros grandes de la industria. Sin embargo, al poco tiempo (2016) ya se comenzaron a escuchar charlas como “Lo que me hubiera gustado saber antes de ampliar Uber a 1.000 servicios” por Matt Ranney. Así, el 2020 Uber ya anunciaba su plan para reducir la complejidad de sus servicios. Este plan estaba orientado a agrupar decenas de servicios bajo un mismo dominio para reducir el número de solicitudes entre servidores, y al mismo tiempo migrar los pequeños servicios en unidades de mayor tamaño.

Por otra parte, hace poco (2023), Amazon Prime reemplazó su aplicación de microservicios por una aplicación monolítica reduciendo sus costos en un 90%. ¿Qué tal?

En síntesis, podemos decir de los microservicios. Lo bueno:

• Permitió que distintos equipos de ingeniería y departamentos trabajaran sin estar alineados. Tal cual. Cada equipo podía desarrollar en el lenguaje que más le acomoda, sin importar cómo están trabajando los otros. Este enfoque podría tener sentido cuando existen múltiples equipos de desarrollo.
• Disminuyen las reuniones entre equipos. En lugar de juntarse con otro equipo para integrar tu funcionalidad en un servicio que pertenece a otro equipo —y las inevitables negociaciones, solo creas el nuevo servicio, sin necesidad de coordinarte con otros equipos.
• Puede haber equipos con ingenieros menos experimentados. Un equipo nuevo tiene pocos desarrolladores, así que no es el fin del mundo si los servicios no son muy estables. Los profesionales menos experimentados aprenden y mejoran a base de ensayo y error.

Lo malo:

• Duplicación de servicios. Muchos servicios hacen cosas similares, y al principio esto no es un problema. Pero con el tiempo, puede convertirse en una fuente de frustración constante cuando un equipo construye otro micro servicio para desbloquearse, en lugar de tomarse un día o dos para integrar su caso de uso en el servicio que ya existe.
• Gestión de los servicios. Cuando se tienen de miles de servicios, cuestiones tan sencillas como quién está de guardia para un servicio, la ubicación del código de un servicio o cómo desplegar un servicio se vuelven más complejas. Las pruebas de integración de múltiples servicios no son triviales. Spotify compartió su plataforma Backstage justamente para ordenar la gestión de sus cientos de servicios.
• Complejidad del soporte de los servicios. Cuando un equipo de 7 ingenieros es responsable de 20 servicios, las guardias suelen ser estresantes y difíciles de gestionar.

Un divertido resumen de lo que pueden ser los microservicios lo pueden ver en este sketch de Krazam. Y dicha parodia no se aleja mucho de la realidad.

En pocas palabras, los beneficios de los microservicios sólo son visibles cuando la empresa tiene “hipercrecimiento”, pero no cuando está tratando de alcanzar dicho peak. En las etapas previas conviene consolidar los servicios, sobre todo cuando sólo hay un equipo de ingenieros.

Por el contrario, las aplicaciones monolíticas pueden significar una apuesta más segura cuando no se espera crecimiento, o el tráfico no es del 1 millón de usuarios concurrentes. Las ventajas y desventajas de las soluciones monolíticas suelen ser opuestas a las de los microservicios. Las plataformas monolíticas funcionan mal cuando se incorporan un gran número de nuevos desarrolladores, porque todos se pisan los unos a los otros. Pero funcionan bien cuando hay un buen ritmo de desarrollo y despliegue, siempre que el equipo no crezca demasiado rápido.

He escuchado relatos sobre el dolor de tener demasiados microservicios después de profundos recortes de personal. Una Fintech que contaba con +800 empleados en su mejor momento, incluidos 200 ingenieros, realizó despidos masivos y redujo su plantilla a unos 500 empleados, con menos de 150 ingenieros. Hoy en día, los microservicios son un gran problema operativo. De un ingeniero de esta empresa:

"Todavía tenemos unos ~400 servicios que mantener, ¡a pesar de que ahora tenemos menos de 2/3 de los profesionales que teníamos en 2021, cuando construimos todos estos! Hace poco le dijimos a la Gerencia: "No tenemos suficientes personas ni siquiera para operar estos servicios: necesitamos contratar más". La respuesta fue: "Arréglalo. ¿Quizá usar IA?".

Por supuesto que nadie debería optimizar una plataforma para luego despedir al 40% del personal, pero las empresas con arquitecturas más simples ven la sobrecarga operativa como un problema menor cuando hay menos personal, que aquellos que deben mantener miles de microservicios.

Para que quede claro, un sistema que está siempre creciendo traerá dolores de cabeza, y modularizar un sistema monolítico si es un desafío. Khan Academy invirtió 3,5 años en dividir su monolito en varios microservicios. En el fondo, el enfoque es introducir una arquitectura de microservicios cuando ya existe la necesidad, más que comenzar con la complejidad porque espero que en el futuro sea útil.

Si necesitas integrar Clave Unica con tu aplicación, te recomendio hacerlo con Keycloak, y luego realizas la integración entre Keycloak y tu aplicación.

¿Porqué ?

Bueno, múltiples motivos. Algunos:

• Es altamente probable que los usuarios de tu aplicación también requieran acceder a otras aplicaciones (mesa de ayuda, ERP, soporte, facturación, tienda, etc). Luego, por cada aplicación tendrás que hacer una integración con Clave Única, lo que resultaría tremendamente engorroso. Por eso, se acuño el concepto de "Single Sign On", para que los usarios no tenga que autenticarse a cada rato. El mejor ejemplo es Google, que sólo te autentificas 1 vez, y luego puedes acceder a las distintas aplicaciones (Gmail, Google Drive, Google Sheets, Youtube, etc).
• Keycloak es una aplicación opensource que se dedica exclusivamente a la gestión y autentificación de identidades. A través de Keycloak puedes administar mejor todo el flujo de login. Tiempo máximo del token, emails de recuperación, logs, flujos para nuevos usuarios, etc. Además, de ser necesario, puedes integrar otros mecanismos de login además de Clave Única.
• La integración con Clave Única y Keycloak es sumamente sencilla, no toma más de 5-10 minutos.

Clave Unica

Primero debes gestionar el formulario de solicitud en Clave Unica para obtener el "client_id" y el "client_secret". Una vez que tengas dicha información, ya puedes configurar Clave Unica en Keycloak

Configuración de Keycloak en Clave Unica

Una vez que tengas instalando Keycloak (se recomienda la instanción via contenedor), primero debes crear un reino (o realm).​

Crear nuevo Idp

Luego, en Keycloak vas a la sección de "Identity Providers" y seleccionas la opción "OpenID Connect 1.0". En la sección de "Discovery Endpoint" debes colocar la siguiente URL:
https://accounts.claveunica.gob.cl/openid/.well-known/openid-configuration

Y luego, sólo colocar las credenciales que te fueron proporcionadas por Clave Unica:

Y con eso ya estará funcionando la integración con Clave Unica ! Antes eso sí, haremos 2 configuraciones opcionales.

Redirección automática (opcional)

En este proyecto, no habrán otras opciones de autentificación, por lo que queremos que cuando un usuario sea redirigido a Keycloak, éste automáticamente se redireccionado a Clave Unica.

Para ello, se debe ir a la sección de "Authenticacion" y luego ir a flujo de autenticación "browser" y seleccionar la configuración para el elemento "Identity Provider Redirect".
Ahi se debe colocar el alias de tu Idp, que este caso, se utilizó el alias "oidc" para Clave Única:

Evitar completar campos adicionales (opcional

Una vez que el usario esté autentificado en Clave Única, éste será devuelto a Keycloak y se le presentará una formulario para completar algunos campos como "Nombre", "Apellido" e "email". Para evitar este formulario, se puede deshabilitar en la sección de "Authentication" y deshabilitamos la opción para el campo "Review Profile" dentro del flujo "first broker login" :

Adicionalmente, en la sección "Required Actions", se debe deshabilitar la opción de "Update Profile".

Prueba final

Para el ambiente de desarrollo de Clave Unica, se puede probar con estos usuarios:

RUN: 44.444.444-4 contraseña: testing
RUN: 55.555.555-5 contraseña: testing
RUN: 88.888.888-8 contraseña: testing
RUN: 99.999.999-9 contraseña: testing

Se puede usar esta URL de pruebas en Keycloak para probar la integración con Clave Unica: (Sólo debes hacer click sobre "Sign in" y será redirigido")

https://login-dev.cenabast.gob.cl/realms/cenabast/account/#/

Conclusión ?

Ya saben, la integración con Clave Unica deben hacerlo con alguna aplicación de Single Sign On, sea esta Keycloak u otra. Keycloak es preferible, al ser de código abierto y altamente escalable.

Buen día !

En el sector de Gobierno, hemos visto frecuentemente que la mayoría de los proyectos de desarrollo de software son bajo la modalidad de "suma alzada" o "llave en mano". Este es un buen método para conocer el precio final a pagar, y sólo se debería utilizar cuando las especificaciones del requerimiento están sumamente detalladas. Por eso, se utiliza siempre industrias como la Construcción, Minería, etc.

Sin embargo, también existe varias desventajas con este formato. Sobre todo en la industria de desarrollo de Software. Entre ellas:

• El incentivo para el proveedor es desarrollar la funcionalidad al menor costo posible. No hay incentivo a desarrollar una funcionalidad de buena calidad. Si mayor calidad implica mayor tiempo de desarrollo, entonces definitivamente el proveedor privilegiará desarrollar minimizando su tiempo de desarrollo.
• Es más dificil o complejor incluir la revisión "cruzada" (o code review). Si la funcionalidad hace lo que se especifica en el requerimiento, entonces no importa que el código esté desordenado y poco claro. (A no ser que en el requerimiento se especifique claramente las guías y estándares de desarrollo.).
• La documentación típicamente será muy simple y reducida. ¿Como se puede especificar en un documento de requerimientos que se requiere documentación completa y de alta calidad ?

Desarrollo de software... ¿un arte?

El desarrollo de software debe ser considerado más como un Arte. Usted puede levantar un requerimiento sumamente detallado de que desea una pieza de arte similar a un Van Gogh o Picasso. Puede especificar el escenario ideal, colores de preferencia, estilo de dibujo, etc, con el máximo de detalle.

Luego, deberá considerar unos buenos criterios de selección, ya que de lo contrario, el proveedor que oferte al menor costo se ganará el proceso de licitación. Y sabemos muy bien que la calidad es muy distinta según la experiencia y conocimientos del artista. Hasta un niño podría hacer un cuadro siguiendo las especificaciones.

Es por eso, y los motivos previamente descritos, que si lo que se desea es construir un software con una alta calida de diseño, lógica y arquitectura, lo mejor será trabajar en un formato de pago por horas.  

Le propongo al lector que hagamos el siguiente ejercicio práctico y liberemos nuestra imaginación  —hay que ser creativos, ¿no?—.

Requerimiento Presidencial

El presidente de la república ha solicitado una pintura de arte de su equipo ministerial. El mismo presidente señaló que el cuadro debe ser excepcional, ya que será puesto en unos de los pasillos del palacio de la moneda. Sencillamente no puede ser un trabajo mediocre, sino que debe apuntar a lo más alto.

Obviamente no se puede hacer un trato directo como nos gustaría, ya que nos rige la ley de compras públicas, y, por lo tanto, estamos obligados a realizar un proceso de licitación pública —al menos, me parece que el servicio no califica dentro de las causales para un trato directo—. Con una licitación pública, todos los pintores —proveedores— del país estarán invitados a participar en un proceso abierto y transparente. Excelente, sigamos.

Desde el punto de vista del comprador, la licitación debe incluir una serie de elementos como criterios de selección, estado de avance, entregables, forma de pago, multas y un serie de condiciones contractuales para prevenir un escenario adverso. Respecto de los requerimientos técnicos mínimos, éstos podrían ser:

• Licenciatura en diseño, arte o similar.
• Al menos 5 años de experiencia demostrable.

Respecto de los criterios de selección, se me ocurre algo así —más bien es lo que típicamente se utiliza en proyectos de desarrollo de software—:

• (40%) Experiencia.
• (30%) Plazo de entrega ofertado.
• (30%) Precio ofertado.

¿Tiene sentido pedir título profesional? Quizás sí, pero con ello también podríamos excluir a grandes pintores que no tienen título.

Respecto de la experiencia, ¿cómo la medimos?, ¿según años de trabajo?, ¿por cantidad de exposiciones?, ¿por número de obras de arte realizadas?, ¿por monto de facturación a clientes? ... Nadie dijo que sería sencillo este proceso.

Por el plazo de entrega, ¿tiene sentido premiar al pintor que entrega el producto antes ? ¿en 1 día? La verdad es que no tengo la menor idea cuanto se demora un gran artista en terminar un trabajo. Imagino que algo dependerá el tamaño del cuadro, pero nada más.

En cuanto al precio, ¿tiene sentido calificar mejor a la oferta más económica? Pensando en el mejor uso de los recursos públicos, imagino que sí.

Bueno, todas estas ideas se asemejan bastante al área de desarrollo de software. Si bien puede sonar un poco ridículo, es lo que realmente sucede con muchas de las licitaciones de software. En muchas de ellas se adjudica al proveedor más económico y al que entregue antes. ¿Se imaginan la calidad de esos productos?

Quizás la mayor diferencia es en cuanto a la utilidad o funcionalidad del producto entregado. En el caso del software podemos fácilmente validar que cumpla el objetivo por el cual fue solicitado, mientras que para un cuadro de arte no imagino como validar su función u utilidad. Pero a diferencia del arte, validar la funcionalidad de una aplicación de software es una prueba limitada e imprecisa. La mayoría de los productos de tecnología nunca finalizan, y están continuamente adaptándose a los nuevos desafíos. ¿Acaso Amazon ya dejó de desarrollar? Claro que no, lo llevan haciendo por más de 30 años, y seguirán haciéndolo por muchos años más. Por lo tanto, una correcta evaluación debe incluir otras dimensiones como escalabilidad, seguridad, confiabilidad y mantenibilidad, —entre otras—.

Por otra parte, desde el punto de vista del proveedor, también es un desafío poder participar de este negocio. Cabe recordar que el incentivo para cualquier proveedor es maximizar su beneficio propio —exposición, rentabilidad, etc—. Ahora bien, la incertidumbre de este proceso implica riesgos para el proveedor.

Para hacer más compleja la historia, pensemos que el desarrollo de la pintura fue adjudicada al pintor Juan Pérez. La pintura se hizo y se entregó según los plazos establecidos. El cuadro cumple con lo especificado en las bases técnicas de la licitación. El presidente, o la figura de lo que parece ser el presidente, está representado en el centro del cuadro. ¿Cómo sabemos si la calidad del cuadro es buena o mala? ¿No será necesario que una contraparte técnica externa evalúe el trabajo? Así, tendremos una opinión válida de un pintor externo que sustente el trabajo realizado. Con el software pasa algo similar. Las mejores prácticas de un buen proceso de desarrollo de software incluye una revisión cruzada entre pares o profesionales de la misma especialidad.

Ahora bien, continuando con nuestro proyecto de arte, pasado el tiempo se nos solicita realizar unas pequeñas modificaciones al cuadro. Faltó un pequeño detalle que ahora necesitamos incorporar —alguien olvidó mencionar en el requerimiento inicial que la pintura debía incluir la bandera de Chile en el fondo—. Entonces debemos realizar un nuevo proceso del licitación ya que no es factible realizar un trato directo con el proveedor adjudicado del primer proceso. Esta vez sin embargo, el proceso de licitación se adjudicó a un proveedor (pintor) distinto, quién será responsable de incluir la bandera chilena en la obra de arte.

Mmm... Esto último me suena conocido. Lo he visto no una, sino varias veces. Distintos proveedores de desarrollo de software se deben hacer cargo del mismo proyecto en tiempos distintos. En particular recuerdo un proyecto en PHP sobre el framework Zend que en 5 años tuvo 7 proveedores distintos. ¿Se imaginan como es la calidad del código? ¿Qué incentivo tienen el séptimo proveedor para mejorar la calidad de la aplicación si más adelante ya no será responsable, sino que posiblemente habrá un nuevo proveedor? Mal.

Además este sin fin de proveedores abre la puerta para las típicas excusas del tipo “el anterior proveedor era inexperto y dejó la embarrada”. Y no sólo eso, sino que a medida que acumula errores y deuda técnica, se hace más difícil de mantener y soportar, lo que termina aumentando los costos de desarrollo y soporte. Se transforma en un proyecto cacho.

Si bien toda esta historia parece muy alejada de la realidad, puede que no sea tanto. Podríamos asimilar varios aspectos de esta historia a los mismos desafíos en el desarrollo de software.

• Es difícil evaluar y comparar la calidad entre distintos desarrolladores de software. Muchas veces el título, o los años de experiencia no son representativos del nivel profesional del individuo.
• No es fácil medir o controlar la calidad de un desarrollo tecnológico. Un sistema puede funcionar bien por “fuera”, pero también es necesario revisarlo “por dentro”. ¿Sobre qué fue construido? ¿Que diseño consideró? Muchos problemas de software se conocen con el tiempo, cuando escalan —se saturan— o cuando se deben implementar nuevas funcionalidades.
• Es complejo mantener y soportar un servicio o aplicación cuando distintos proveedores intervienen el código. Cada uno tienen sus propios estándares, experiencia y calidad de profesionales.
• El desarrollo de software no sólo está enfocado en algo puramente funcional, sino también debe ser atractivo, simple y fácil de usar. El software debe ser un aporte para el usuario final.

Gracias por leer ! :-)

Ciertamente no todos los emprendimientos son exitosos, y un alto porcentaje falla en el camino por distintos motivos. Aquí queremos hablarles brevemente del proyecto de MercadoTech, un marketplace B2C de tecnología que hizo su aparición en Agosto del 2019:

A diferencia de otras empresas del rubro, mercadotech puso sus fichas en la automatización del flujo de ventas con una baja estructura comercial y operativa, logrando con ello un menor costo de gestión y administración (menor comisión que otros Marketplaces).

La Tecnología

El proyecto fue desarrollado sobre la solución de Spree Commerce, aplicación de ecommerce de código libre en Ruby and Rails (RoR). Sobre dicha base, se realizó un trabajo de +6000 horas de desarrollo, que entre otras cosas implicó el desarrollo de las siguientes características:

• Sistema de login unificado vía SAML sobre Keycloak.
• Sistema de facturación utilizando la API de Superfactura.
• Sistema de etiquetado y delivery a través de Envíame y Moova.
• Integración con 4 proveedores mayoristas para sincronización de stock y compra automatizada (Ingrammicro, Intcomex, Tecnoglobal y Quintec)
• Integración con Etilize para la construcción del catálogo (o ficha) de producto.
• Módulo de Marketplace o Seller Center.
• Stock the múltiples bodegas por Proveedor.
• Integración con Transbank a través de sus productos "Webpay Plus Mall" y "OneClick Mall". Dicha solución permite subdividir el pagó de múltiples empresas.
• RMA (o flujo de devolución inversa) totalmente autogestionado por el usuario. (esta característica funcionaba increíble).
• Uso de la Gema Searchkick, para optimizar el motor de búsqueda de ElasticSearch
• Integración con Sendy Newsletter para la subscripción de usuarios.
• Integración con AWS Bucket S3 para el guardado de las imágenes.
• Aplicativo construido sobre Docker y montado en un cluster de Kubernetes, para su escalabilidad.

A continuación les dejamos algunas imágenes del proyecto:

MultiVendor Catalog:

Shipping por cada Vendor:

Código libre (opensource)

El 2022 se decidió liberar el código, quedando disponible acá:

https://github.com/patagon-dev/mercadotech

Suerte a quién desee utilizarlo !