¿Por qué escalar de abajo hacia arriba? Cómo las interacciones de los equipos deben afectar la estructura organizativa

Rate this content
Bookmark

Todos hemos pasado por reorganizaciones de empresas, probablemente más de una vez. Si algunas son comprensibles y producen buenos resultados, otras no lo son, creando inseguridades, falta de confianza en el liderazgo, cambios innecesarios e incluso caminos de comunicación o toma de decisiones más complejos. ¿Cuál es la diferencia entonces? ¿Existe una forma probada de escalar o cambiar el panorama actual de las organizaciones de las empresas? Sí, la hay. En esta sesión, repasaré, respaldado por un caso de estudio real en la industria, la Ley de Conway y la importancia del panorama y las interacciones de los equipos, y cómo los gráficos de equipos bien diseñados pueden mejorar la independencia, autonomía y motivación de los equipos, lo que conduce a una entrega más rápida y de mejor calidad.

17 min
09 Mar, 2023

Video Summary and Transcription

La charla aborda la importancia del diseño organizativo y las interacciones de los equipos en el desarrollo de software. Explora los desafíos de los fragmentos organizativos y la necesidad de pensar en problemas para optimizar la comunicación del equipo. Se explican los conceptos de acoplamiento suelto, alta cohesión y dominios claros de responsabilidad. La charla también enfatiza los tres modos esenciales de interacción del equipo: trabajar estrechamente juntos, X como servicio y facilitación. Además, destaca la importancia de comprender los dominios, los límites y el diseño impulsado por dominios para un trabajo eficiente y una entrega rápida.

Available in English

1. Teams Interactions and Organizational Layout

Short description:

En esta parte, discutimos la importancia del diseño organizativo y las interacciones entre equipos, así como el impacto de la estructura de comunicación en el diseño de software. Exploramos los desafíos de los fragmentos organizativos y la necesidad de pensar en problemas para optimizar la comunicación entre equipos. El objetivo es adaptar los equipos a la arquitectura de software deseada, mejorar la estructura e interacciones del equipo, y promover la autonomía, el dominio y el propósito. Se explican los conceptos de acoplamiento suelto, alta cohesión y dominios claros de responsabilidad. Finalmente, el libro Team Topology introduce las Topologías Fundamentales y los Modos de Interacción como formas de repensar los fragmentos organizativos.

Hola a todos, estoy feliz de estar aquí hablando sobre las interacciones entre equipos y el importante papel que desempeñan en la escalabilidad adecuada y la reorientación de los procesos. En los próximos 20 minutos, hablaré un poco sobre los equipos como medios de entrega, las interacciones entre equipos y la importancia de DDD para un flujo rápido. ¡Empecemos!

Entonces, la primera pregunta es, ¿por qué? ¿Por qué es importante el diseño organizativo y las interacciones entre equipos? Bueno, el Sr. Mel Conway observó un patrón de comportamiento que terminaría convirtiéndose en una ley. La ley de Conway es la observación de que el diseño de cualquier sistema está significativamente afectado por la estructura de comunicación de la organización que lo desarrolló, y es una consecuencia del hecho de que dos módulos de software A y B no pueden interactuar correctamente entre sí a menos que el diseñador e implementador de A se comunique con el diseñador e implementador de B. Por lo tanto, la estructura de la interfaz de un sistema de software mostrará necesariamente una congruencia con la estructura social de la organización que lo produjo.

Esto tiene un impacto significativo en cómo se construye el software, especialmente si se adoptan microservicios y un diseño más orientado al dominio, y esto está directamente relacionado con los fragmentos organizativos que las empresas suelen tener. El problema con los fragmentos organizativos es que proporcionan una vista única del equipo, con la relación entre los equipos y las líneas de reporte, pero por lo general los patrones de comunicación no son de arriba hacia abajo en la línea de reporte, son paralelos y a lo largo del fragmento, lo que hace que la eficiencia de la comunicación sea clave para los equipos efectivos. Iremos a donde sea necesario para resolver nuestros problemas, y esta creatividad y método de resolución de problemas debe ser aprovechada en beneficio de la organización, no restringida a las líneas de reporte.

Entonces, ¿cómo podemos resolver los problemas de los fragmentos organizativos? El pensamiento en problemas es un enfoque holístico que se repite constantemente, siempre tratando de optimizar el conjunto, considerando el flujo general de trabajo, identificando cuellos de botella y eliminándolos. Y ahora volvamos a nuestro punto inicial de la comunicación. Los cuellos de botella organizativos comunes son estructuras de equipo ocupadas, mala comunicación y ritmo lento de entrega, y creo que todos hemos pasado, si no todos, por algunos de ellos. El objetivo general es que la arquitectura admita la capacidad de los equipos para completar su trabajo desde el diseño hasta la implementación, sin requerir una comunicación de alta capacidad entre los equipos. ¿Y supongo que esto es el nirvana de la organización, verdad? Esto significa que cada organización debe entender qué arquitectura de software se necesita antes, y aquí van en letras mayúsculas, antes de organizar los equipos. De lo contrario, los paquetes de comunicación y los incentivos en la organización terminarán dictando la arquitectura de software, algo que no queremos. Y aquí volvemos al tema de la comunicación. Cuanto más adaptemos los equipos a la arquitectura deseada, y no al revés, más contenida y mejorará la comunicación, mejorando la eficiencia de los diseños de equipo al eliminar la sobrecarga del caos de la comunicación. Reorganizar o escalar una empresa, basándose en esta suposición, aunque obvia, es un desafío para la jerarquía, ya que está intrínsecamente relacionado con las necesidades de colaboración e interacciones de los equipos, su capacidad para ser flexibles y adaptarse al cambio, y los dominios y límites de carga cognitiva del equipo. La carga cognitiva es el límite de cuánta información puede retener una persona, o en este caso un equipo al unir a todos los miembros, en un momento dado.

Entonces, ¿cuál es el objetivo aquí con esta maniobra, cómo podemos mejorar la estructura e interacciones del equipo? Para empezar, debemos pensar en los equipos como organismos vivos dentro del ecosistema, con individualidades que responden a motivadores crecientes. Estos motivadores suelen ser una referencia de tres elementos, y son autonomía, dominio y propósito, que cuando se habilitan dentro de responsabilidades claramente delimitadas, permiten calidad y velocidad de trabajo aumentadas. ¿Por qué? Hago esta pregunta muchas veces. Bueno, cuando los equipos están débilmente acoplados y altamente cohesionados, significa que son autónomos en el contexto en el que trabajan, un contexto que está restringido en responsabilidades y adaptado a su carga cognitiva, limitando los esfuerzos de cambio, aumentando así el enfoque y la calidad. Es posible que hayas escuchado estos términos antes y se aplican de la misma manera. El acoplamiento suelto es cuando los componentes no tienen dependencias fuertes con otras empresas, y la alta cohesión es cuando los componentes tienen responsabilidades claramente delimitadas y sus elementos internos están fuertemente relacionados. Por lo tanto, estos conceptos se aplican de la misma manera en todos los escenarios. Además, el conjunto claro de dominios de responsabilidad rechaza la mentalidad de `hábil en todo, maestro de nada`, evita que los equipos tengan que lidiar con solicitudes y prioridades de múltiples fuentes. En resumen, los paisajes de equipo adecuados que ponen a los equipos en primer lugar influyen positivamente en los límites de responsabilidad, la velocidad de entrega, la calidad del trabajo y la autonomía, lo que a su vez impacta directamente en el software que los equipos producen. Basado en la ley de Conway, el libro Team Topology menciona dos conceptos fundamentales que ayudan a utilizar los paisajes de equipo para repensar los fragmentos organizativos de la empresa, y los conceptos son las Topologías Fundamentales y los Modos de Interacción. En resumen, ¿cuáles son las mejores topologías en las que los equipos pueden trabajar? Los autores sugieren cuatro topologías fundamentales que van desde equipos orientados al negocio hasta equipos orientados a la plataforma.

2. Team Alignment and Interaction Modes

Short description:

Tenemos equipos alineados con el flujo, equipos habilitadores, equipos de subsistemas complicados y equipos de plataforma. La comunicación e interacción entre equipos son fundamentales, y se discuten tres modos esenciales de interacción entre equipos: trabajar estrechamente juntos, X como servicio y facilitación. Estos conceptos promueven equipos con acoplamiento suelto y alta cohesión en un flujo adecuado de cambios.

Tenemos un equipo alineado con el flujo, que se alinea con un flujo de trabajo de generalmente un segmento de un gran dominio empresarial. Tenemos los equipos habilitadores que ayudan a los equipos alineados con el flujo a superar obstáculos, y también detectan capacidades faltantes. También tenemos equipos de subsistemas complicados, donde se requieren matemáticas, cálculos o experiencia técnica significativa. Y por último, pero no menos importante, tenemos el equipo de plataforma, que es un grupo de otros tipos de equipos que proporcionan un producto interno convincente para acelerar la entrega de los equipos alineados con el flujo.

Dado que la comunicación e interacción entre los equipos son los aspectos más críticos del pensamiento organizativo y estratégico, para permitir que estas topologías de equipos interactúen adecuadamente, se sugieren algunos modos de interacción como se presenta en la siguiente diapositiva. Y nuevamente, volviendo a los problemas de comunicación con los que comenzamos, ¿cómo pueden colaborar y comunicarse de manera efectiva los equipos? Existirán dependencias, cuanto menos, mejor, pero existen y no podremos hacerlas desaparecer. ¿Cómo podemos simplificar nuestras vidas? ¿Cómo podemos comunicarnos para construir una buena estructura de equipo? En el libro, nuevamente, los tres modos esenciales de interacción entre equipos son los siguientes. lo que significa trabajar estrechamente juntos con otro equipo, que es el impulsor de la innovación y el descubrimiento rápido, pero tiende a difuminar los límites. Es un modo de comunicación muy bueno para el descubrimiento rápido de cosas nuevas que evita costosas transferencias entre equipos. También tenemos el modo de X como servicio, lo que significa consumir o proporcionar algo con una colaboración mínima, lo que mantiene responsabilidades claras con una entrega predecible, pero necesita una buena gestión de productos. Es una excelente opción cuando hay una necesidad de que uno o más equipos utilicen un componente compartido que se puede proporcionar como un servicio. Y por último, pero no menos importante, la facilitación, lo que significa ayudar o ser ayudado por otro equipo para eliminar impedimentos, lo que detecta y reduce las brechas en las capacidades. Es bueno cuando uno o más equipos se benefician de la ayuda activa de otro equipo que facilita o incluso asesora algún aspecto de su trabajo.

3. Dominios, Límites y Diseño Dirigido por Dominios

Short description:

Todos estos conceptos, topologías fundamentales y modos de interacción son esenciales para equipos con acoplamiento suelto y alta cohesión. Eric Evans destaca los desafíos del flujo cuando los equipos dependen de interacciones complejas. La solución radica en explorar y validar los límites de responsabilidad, priorizando las necesidades del equipo. Las arquitecturas fuertemente acopladas obstaculizan a los equipos autónomos, mientras que los límites poco claros y el alto acoplamiento conducen a problemas de entrega. Para apoyar un trabajo eficiente, es crucial comprender la arquitectura de software requerida antes de organizar los equipos. Los dominios y sus límites desempeñan un papel clave en la minimización de la carga cognitiva y en la habilitación del diseño dirigido por dominios. Este enfoque se alinea con la planificación estratégica, fomenta un lenguaje común y promueve la propiedad del equipo y una entrega rápida.

En resumen, todos estos conceptos, tanto las topologías fundamentales como los modos de interacción, terminan siendo una regla general cuando se trata de pensar en equipos con acoplamiento suelto y alta cohesión que trabajan juntos en un flujo adecuado de cambios. En este punto, hemos comprendido la importancia de tener una visión clara para el diseño de la arquitectura de software y luego ajustar los equipos como organismos tan efectivos como los límites que se les asignan y las estrategias de comunicación que aplican. También hemos discutido los modos de interacción que mejoran la comunicación, pero ¿qué pasa con la carga cognitiva? ¿Qué pasa con los límites y responsabilidades del equipo? Bueno, Eric Evans, que es un conocido arquitecto de software y autor del libro Diseño Dirigido por Dominios, coincide con la observación de que es difícil lograr un flujo cuando cada equipo depende de una complicada red de interacciones con muchos otros equipos. Cuando los límites de responsabilidad asignados a los equipos no son viables o están mal definidos, resulta en falta de propiedad, desvinculación y una baja tasa de entrega. ¿Hay una solución? ¡Sí! Explorar y validar los límites de responsabilidad, teniendo en cuenta primero al equipo, es lo que discutiremos a continuación. La investigación realizada por Accelerate encontró que las arquitecturas fuertemente acopladas influyen negativamente en la capacidad de tener equipos autónomos con responsabilidades claras. Muchos problemas en la entrega de software provienen de límites poco claros entre equipos y sus responsabilidades, lo cual a menudo se ve opacado por una arquitectura de software con alto acoplamiento entre sus diferentes partes, algo en lo que las arquitecturas monolíticas se complacen. El objetivo final de cada arquitectura es apoyar la capacidad de los equipos para realizar su trabajo con un alto rendimiento, desde el diseño hasta el desarrollo, sin requerir una comunicación de alta capacidad entre equipos, lo cual es más difícil de lograr en una arquitectura monolítica. Pero en el proceso de alejarse del software monolítico, ¿cómo consideramos las necesidades de los equipos? ¿Cómo tenemos en cuenta su perspectiva? Pensamos en los dominios, aplicando una estrategia bien conocida que permite la plena propiedad de los equipos. Exploramos y discutimos el diseño dirigido por dominios y luego evaluamos cómo los equipos se ajustarán a eso. Esto significa, nuevamente, aunque parezca que me estoy repitiendo, pero esto es realmente importante, que la organización debe comprender qué arquitectura de software se requiere antes de organizar los equipos. De lo contrario, como ya se mencionó, los caminos de comunicación y los incentivos en la organización terminarán dictando la arquitectura de software. Pero primero, retrocediendo un paso, ¿qué es un dominio? Sabemos que los buenos límites minimizan la carga cognitiva, ¿verdad? Pero, ¿qué son estos límites? Los límites son líneas conceptuales que envuelven a los dominios, y los dominios son conceptos más amplios que los sitios de software, lo que nos ayuda a pensar en general y utilizar heurísticas comunes. El hecho de que proporcionen una visión del problema que se está resolviendo también facilita asignar complejidad a un dominio, lo que a su vez facilita asignarla a los equipos según su carga cognitiva disponible. Esto permite el diseño dirigido por dominios, proporcionando técnicas de desarrollo de software que abordan tanto la planificación estratégica como el diseño estratégico y técnico, manteniendo la alineación con el negocio, fomentando un lenguaje común y una evaluación adecuada de la complejidad, lo cual en última instancia proporciona beneficios claros, propiedad del equipo, compromiso y un flujo rápido de entrega. Dicho todo esto, pasemos a un escenario de caso real, y hablaré sobre mi ejemplo personal en LX. Entonces, cada empresa necesita una estructura organizativa, especialmente las grandes corporaciones que actúan en varios tipos de mercados en todo el mundo. El negocio de clasificados en línea no es una excepción, y en el grupo OLX hay una unidad de clientes específica para representar el mercado de compra y venta de automóviles, que es la unidad de clientes de motores. Esta unidad representa a compradores y vendedores individuales, con el objetivo de unirlos para realizar negocios. Como puedes imaginar, lo que comenzó pequeño ahora es un gran negocio, donde las personas tienen el poder de tomar decisiones más rápidas y mejores y ofrecer mejores funciones de manera más rápida, con bajos índices de problemas para los usuarios. Con más equipos, mercado y competencia, la arquitectura de software de motores llegó al punto en el que el monolito que sirvió y llevó a la unidad hasta este punto ya no funciona. En algún momento, el monolito obstaculizó nuestra eficiencia para ser aún más rápidos y mejores, y, por ejemplo, el alto acoplamiento y los límites difusos constantemente ponían a nuestros equipos en el camino de los demás, lo que exigía un fuerte compromiso de alineación en todo momento. El progreso de las funciones comerciales también se vio afectado, ya que cada cambio provoca impactos en otros equipos, lo que ralentiza la entrega e incluso la calidad, ya que los impactos de estos cambios llevaban a pequeños pasos de entrega o incluso a un compromiso entre las partes. Por todo esto, el ritmo de entrega también se veía afectado por el monolito, ya que cada implementación tenía una alta probabilidad de detener el flujo debido al alto número de cambios que afectaban a todos los que necesitaban entregar. Reconociendo todo esto y en un esfuerzo por mejorar la independencia y la excelencia, el grupo de equipos que trabajan para impulsar el crecimiento del negocio de los vendedores profesionales a través de la adquisición, gestión y venta de vehículos, decidió poner en marcha un plan para alejarse del monolito reuniendo a un grupo de expertos en diseño dirigido por dominios para ayudar a los equipos a tener una mejor comprensión de los límites de responsabilidad y identificar las necesidades para pasar a una arquitectura desacoplada, permitiendo la autonomía, el trabajo independiente y las responsabilidades definidas. Pero una vez tomada esa decisión, ¿por dónde empezar? Bueno, la planificación estratégica ayuda a comprender cuáles son las inversiones de software más importantes que se deben realizar, qué activos de software existentes se deben aprovechar para llegar más rápido y de manera más segura, y quiénes deben estar involucrados. Esta planificación estratégica implica revisar los dominios actuales, utilizar sesiones de event-storming para definir contextos acotados y mapas de contexto, utilizar entidades, agregados y eventos de dominio para redefinir la arquitectura actual y alinear las responsabilidades de cada dominio con la carga cognitiva actual de los recursos del equipo. Basándonos en este trabajo de DDD, estamos logrando una base sólida para revisar nuestra arquitectura actual alineada con los bloques de construcción de DDD y los principios de modularidad, alta cohesión, bajo acoplamiento y ocultamiento de información. Y al final, reorganizamos nuestros gráficos de tribus de acuerdo con los dominios de los equipos y los modos de interacción, de modo que logremos una baja sobrecarga de comunicación, una toma de decisiones más rápida, una entrega más rápida y de calidad, y permitamos que nuestros equipos tengan autonomía, capacidades de salud mental sólidas y experiencia en los dominios de los que son responsables. En definitiva, nuestro objetivo es escalar y reorganizar nuestro gráfico de abajo hacia arriba, teniendo en cuenta nuestros dominios empresariales y sus relaciones de agregados, para establecer nuestra arquitectura del sistema, que a su vez da forma al panorama de los equipos, que a su vez construye una estructura organizativa que valida los principios de la ley de Conway, para influir positivamente en la velocidad de entrega, la calidad del trabajo y la autonomía, y luego impactar directamente en el software que estamos produciendo. Y eso es todo. Gracias por escuchar.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
Top Content
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt. In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.
React Summit 2023React Summit 2023
26 min
Principles for Scaling Frontend Application Development
After spending over a decade at Google, and now as the CTO of Vercel, Malte Ubl is no stranger to being responsible for a team’s software infrastructure. However, being in charge of defining how people write software, and in turn, building the infrastructure that they’re using to write said software, presents significant challenges. This presentation by Malte Ubl will uncover the guiding principles to leading a large software infrastructure.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Top Content
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Top Content
WorkshopFree
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
WorkshopFree
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
WorkshopFree
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
WorkshopFree
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.js backend + Vanilla JS frontend) to authenticate users with One Time Passwords (email) and OAuth, including:
- User authentication – Managing user interactions, returning session / refresh JWTs- Session management and validation – Storing the session securely for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
JSNation 2023JSNation 2023
87 min
Build a Collaborative Notion-Like Product in 2H
WorkshopFree
You have been tasked with creating a collaborative text editing feature within your company’s product. Something along the lines of Notion or Google Docs.
CK 5 is a feature-rich framework and ecosystem of ready-to-use features targeting a wide range of use cases. It offers a cloud infrastructure to support the real-time collaboration system needs. During this workshop, you will learn how to set up and integrate CK 5. We will go over the very basics of embedding the editor on a page, through configuration, to enabling real-time collaboration features. Key learnings: How to embed, set up, and configure CK 5 to best fit a document editing system supporting real-time collaboration.
Table of contents:- Introduction to the CK 5 ecosystem.- Introduction to a “Notion-like” project template.- Embedding CK 5 on a page.- Basic CK 5 configuration.- Tuning up CK 5 for a specific use case.- Enabling real-time editing features.