Open way y open source: posibilitando la transparencia y acelerando los negocios

Aquí hay una parábola, y tal vez un ejercicio interesante para su propia organización:

Un nuevo director general llega a una empresa en apuros. El primer día, la directora general le pide a su nueva secretaria que haga que todos los líderes de la empresa escriban la visión de la empresa en un post-it para presentarlo en una reunión por la mañana. El secretario, perplejo, pregunta: “¿Por qué necesita esto? Todos son ejecutivos de nivel C y vicepresidentes senior. Obviamente, todos conocen la visión de nuestra empresa. »

No obstante, insiste el CEO, por lo que la secretaria visita a cada ejecutivo de nivel C y SVP y les entrega la tarea junto con una invitación a una reunión con el CEO a la mañana siguiente. Al día siguiente, los ejecutivos y SVP llegan para la reunión. El director general les pide que pongan sus notas adhesivas en la pared. Sorprendentemente, no hay dos notas adhesivas que coincidan.

Esta historia muestra lo fácil que es para las personas malinterpretar un mensaje común. Cito esta historia cuando quiero explicar por qué la transparencia es importante cuando se trabaja en un proyecto y cómo es esencial para el éxito de cualquier proyecto.

He trabajado en varios proyectos a lo largo de mi carrera. Todos ellos eran proyectos de TI, pero iban desde DevOps hasta ingeniería de back-end, diseño de front-end y arquitectura en la nube. Aunque son equipos diferentes, surgen temas comunes cuando se trata de algunos de los problemas que están tratando de resolver. Desde la perspectiva del proceso, uno de los temas más comunes es cómo hacer que el proceso sea más ágil, fluido y estable. Otra forma de describir esto es que casi todas las empresas sufren de falta de transparencia debido al trabajo en silos.

Creo que ahí es donde la forma abierta de hacer las cosas puede ayudar. Y fuente abierta, que representa una base de código en la que cualquiera puede contribuir, también puede convertirse en el componente clave para permitir la transparencia y acelerar el proyecto.

Abra la ruta n.º 1: arregle un equipo aislado compartiendo

Lo que es "obvio" para una persona a menudo no lo es en absoluto para otra. Si tu profesor de matemáticas de la universidad escribe un montón de ecuaciones en la pizarra y dice: "La prueba es trivial", probablemente abandonarás la clase por miedo a reprobar. Al trabajar en un proyecto, compartiendo tanto como sea posible, con pocas suposiciones sobre lo que es "obvio", ayudas a otros a tener éxito. Y cuando una persona tiene éxito, el equipo tiene éxito.

Casi todos los proyectos comienzan con una prueba de concepto (PoC), seguida generalmente por un producto mínimo viable (MVP). Todo comienza muy simple, pero los proyectos crecen a medida que el equipo encuentra valor en el producto o servicio y la necesidad de evolucionar. A medida que se desarrolla un proyecto, el equipo debe asignar responsabilidades a diferentes grupos de personas. Es la forma correcta de crecer, y la separación de responsabilidades es 100% necesaria. Sin embargo, cuando los grupos comienzan a trabajar en funciones discretas, pueden perder de vista la visión del proyecto como un todo. Esta desalineación, como ocurre con los marcos de los platos, pasa desapercibida porque los equipos no son transparentes, pero persiguen diligentemente la idea de que creen que representan la visión de los demás.

La solución a esto es que cada individuo sea lo más proactivo posible a la hora de compartir su conocimiento y trabajar con el resto del equipo. Esto se puede hacer compartiendo documentación, presentaciones periódicas y tutorías. Los métodos ágiles ciertamente pueden ayudar, pero ningún ciclo de vida de desarrollo de software Agile u otro o proceso comercial puede resolver el problema aislado si las personas no quieren compartir. Al darse cuenta de que ayudar a los demás puede ayudar a todos, nace un equipo exitoso. Permitir la transparencia de forma abierta es fundamental para todo proyecto.

Vía abierta #2: resuelve los problemas de tu equipo contribuyendo al código abierto

Los proyectos de código abierto, o proyectos empresariales basados ​​en código abierto, tienen un concepto interesante llamado upstream. Upstream es cualquier entidad que proporciona a su proyecto los recursos necesarios para una producción exitosa. Por ejemplo, Red Hat tiene un producto en la nube llamado OpenShift, que está dirigido principalmente a las empresas. Pero OpenShift tiene un upstream llamado Aceptar D (La distribución de la comunidad de origen de Kubernetes), y es el lugar donde todos pueden participar y contribuir. Lo importante del código abierto es que, literalmente, todos se benefician cuando se mejora y, al contribuir en sentido ascendente, se rompen todos los silos al enviar los cambios directamente a la fuente común. La contribución ascendente puede servir como un punto de encuentro virtual común para su proyecto, ayudando a diferentes equipos a colaborar contribuyendo a la misma base de código superior. Al identificar los upstream y las comunidades que los rodean, puede hacer un favor a todos los que usan el proyecto (incluido su propio equipo) y, por supuesto, se beneficiará cuando otros hagan lo mismo.

No necesariamente tiene que convertirse en programador para contribuir al proyecto de código abierto. Suponga que está trabajando con un producto y descubre un error potencial o un área de mejora. El primer paso es ponerse en contacto con el equipo de soporte dedicado, pero el problema puede estar relacionado con el producto en sí. En este caso, identifique el proyecto ascendente y verifique si puede presentar un problema allí. Clasificar los problemas en lo más alto posible de la cadena de suministro garantiza la visibilidad y los beneficios para todos los equipos posteriores.

Por ejemplo, participé en un producto de Red Hat llamado Espacios de trabajo CodeReady. El upstream para esto es eclipse che. aquí está un ejemplo de un problema que informé.

Algunos problemas como este pueden tener una solución sencilla que su equipo puede aplicar de inmediato. Sin embargo, algunos problemas pueden estar relacionados con la funcionalidad principal, que puede solucionarse en la próxima versión de GA. Cuando informa un problema como este, el problema se vuelve transparente. Y cuando la solución está disponible para el problema, la solución también se vuelve transparente. Este proceso continúa estableciendo el patrón para las mejores prácticas identificando lo que funciona y lo que no, y luego corrigiendo lo que no funciona, y todos se benefician de este proceso. Si ese no es el verdadero método de código abierto, ¿cuál es?

Como puede ver, el carril abierto puede impulsar el éxito comercial al permitir la transparencia tanto en su equipo como en la comunidad. Esto lo aprendo trabajando a lo largo de una carrera profesional, pero estoy seguro de que se aplica a muchas áreas.

¿Se te ocurre otro camino abierto que pueda contribuir al éxito de la empresa? Siéntete libre de compartir tus ideas con nosotros.

Artículos de interés

Subir