♌️ 💡 👩🏿‍🤝‍👩🏽 Cómo hacer que los vecinos trabajen en su proyecto, o InnerSource para un banco 🧝🏿 🐦 🏧

¿Qué es el desarrollo en Sber? A los ojos de un especialista de TI común: "¡Aquí es donde se escribió el código, ve allí!" Pero esto ha sido durante mucho tiempo un estereotipo, y no son buenos. El rápido desarrollo del código abierto demuestra que esa cultura se ha vuelto obsoleta durante mucho tiempo, y la empresa (si es inteligente) ha revisado durante mucho tiempo el enfoque de desarrollo basado en silos. Publicar todo el software bancario en código abierto es una ~~forma efectiva de suicidarse, una~~ decisión bastante controvertida y se necesita algún tipo de etapa intermedia. Con la escala del banco, podemos lanzar nuestro código abierto interno, en lugar de intentar verificar lo que podemos mostrar a todos y sacudirnos con miedo por nuestros pequeños grandes secretos.

¿Qué es un InnerSource?

En 2000, Tim O'Reilly describió el término fuente interna como un posible paso hacia una compañía cerrada que ingresa al hermoso mundo de fuente abierta. Esta es la aplicación de las mejores prácticas de código abierto dentro de la corporación: desde la apertura general y la asistencia mutua proactiva hasta la formación de un mercado para las mejores soluciones. La compañía continúa escribiendo código propietario, pero cada uno de sus empleados tiene la oportunidad de refinar cualquier sistema interno.

Las ventajas de InnerSource se pueden enumerar durante mucho tiempo: reducir el tiempo de comercialización, mejorar la calidad del código, reemplazar la contratación externa por interna, mejorar la interacción entre equipos, etc.

La dificultad radica en el hecho de que todo lo descrito anteriormente requiere un cambio en la cultura de comunicación entre empleados y equipos, y esto no es tan fácil de hacer en una organización que ha funcionado de manera diferente durante décadas.

Por supuesto, Sberbank no es la única compañía que ha hecho algo como esto. En 2015, se creó la comunidad InnerSource Commons , que popularizó el enfoque y eliminó la brecha del término para que sea más fácil de encontrar en los motores de búsqueda. Esta comunidad ha reunido la experiencia de docenas de compañías y ha hecho recomendaciones efectivas para implementar InnerSource en su compañía, y realiza una conferencia de intercambio de experiencias dos veces al año. Todavía hay muchas compañías tecnológicas conocidas que han estado haciendo esto ~~desde Pechenegs y Polovtsy~~ antes de que se generalizara.

En Rusia, hasta donde sabemos, solo un gran minorista en el mercado de servicios de construcción con un logotipo verde participa activamente en la implementación intencional de InnerSource, otras compañías no anuncian su experiencia o no participan en la comunidad.

Cada una de estas empresas tiene sus propias experiencias positivas y negativas. La conclusión general en este caso es muy similar: los beneficios más deliciosos solo se pueden obtener con la participación de la gran mayoría.

¿Por qué lo recogería?

Casi todas las conversaciones sobre el desarrollo en Sberbank llegan a la pregunta "¿cuántos programadores tienes allí?". En todo el país, tenemos más de diez mil de ellos, están trabajando activamente en miles de componentes, sistemas, bibliotecas y otros similares. Como consecuencia de tales volúmenes, todos los días tenemos que resolver los problemas de gestión de dependencias en equipos relacionados, la relación de liderazgo y las fases de Mercurio.

Al final de la encuesta sobre lo que lastimó a los ingenieros, a fines de 2018 en Sber, se decidió crear un SberWorks tribal, que se hizo cargo de todo lo relacionado con los procesos y herramientas para producir software en el banco. Las tareas y objetivos de la unidad se siguieron casi por completo de la lista de dolores recopilados de los desarrolladores.

Me da vergüenza admitir que el mayor dolor a finales del año pasado fue la falta de conocimiento de lo que hacen los vecinos en el taller o incluso en el bloque vecino en espacios abiertos. Debido a esto, inventamos no solo la rueda, sino también dos (sustituir el número deseado) de las mismas ruedas en diferentes unidades, tanto en diferentes ciudades como en lugares de trabajo vecinos. Como resultado, al tener grandes recursos en la compañía, a menudo en lugar de volar a Marte, nuestros equipos hicieron rastrillos, sin saber que los rastrillos vecinos habían sido recolectados durante mucho tiempo.

¿Qué hacer con todo esto?

Hora. Para resolver los problemas de integración y encontrar a las personas adecuadas, cree un único registro API para todos los sistemas del banco con una gran cantidad de automatización: generación de llamadas, talones para la próxima versión de la API, versiones y similares. Ahora este registro se ha convertido en un producto genial por separado, que definitivamente es digno de su artículo, pero esa es otra historia.

Dos. Cree una especie de "paraguas" con un único motor de búsqueda sobre todas las herramientas de ingeniería (JIRA, Confluence, Bitbucket, Nexus), combinando los segmentos internos y externos (sí, alfa y sigma infames).

Tres. El código, los atrasos y los artefactos, excepto aquellos que prohíben explícitamente que se abra la seguridad, deben estar abiertos a todos los empleados de la empresa.

¿Qué se sugirió?

En el proceso de comunicación con los desarrolladores, identificamos la razón principal de un equipo tan cerrado dentro de nosotros mismos: las formas actuales de interacción entre productos. Cualquier discusión sobre el refinamiento de los sistemas relacionados se realizó de acuerdo con uno de los tres escenarios.

"Esperar"

La forma más común de interactuar. El equipo adyacente establece una fecha límite, generalmente nos conviene, posponemos la tarea más profundamente en el trabajo atrasado.
En general, una opción aceptable. Pero si la cadena depende de varios equipos, y la característica, como de costumbre, debe mostrarse en producción ayer, entonces debe buscar compromisos.

Compromisos

Popularmente, este método se llama escalada. Lleve a un gerente más importante con usted y acuda a un equipo adyacente para avanzar más en su tarea en la cartera. Las desventajas de este enfoque son obvias: la mayoría de los equipos pueden jugar esta carta solo unas pocas veces, después de lo cual la relación entre los equipos se deteriora.

“Trozo permanente temporal”

Vio su bicicleta Frankenstein con muletas y bazucas temporales que duplican la funcionalidad del sistema en el que apareció la adicción. El más triste, ya que casi siempre permanece durante mucho tiempo (si no para siempre), genera duplicación de código y el equipo se ve obligado a apoyar una solución de muleta.

Propusimos una cuarta forma. Refine la base del código del equipo adyacente bajo su supervisión sensible, reduciendo el tiempo de ejecución.

InnerSource

Una vez completada esta interacción, el equipo "A" de la imagen recibe una valiosa retroalimentación, nutre la experiencia en un campo adyacente y reduce el TTM de su refinamiento. Mirando hacia el futuro, en el banco tales interacciones adquirieron rápidamente formatos de trueque de varios tipos: el equipo "A" cierra las tareas de la deuda técnica del equipo "B" mientras realizan el refinamiento necesario.

Nuestra manera

Al principio, nos parecía que necesitamos encontrar lugares en los que InnerSource tenga la máxima demanda en este momento. Mientras estábamos pensando en cómo hacer esto, sin caer en un ciclo de encuestas interminables, el liderazgo sabio agradeció la idea y propuso garantizar el cien por ciento de preparación del cien por ciento de los sistemas de Sberbank para fin de año. Nos tensamos, nuestro gerente preguntó "¿qué es cien por ciento?", Y la cantidad de sistemas se redujo en aproximadamente 20 veces a moderna y / o crítica para los negocios.

Después de eso, comenzó el proceso rutinario de hacer circular esta práctica en los equipos, al final del cual vimos un prado cubierto con una lista de repositorios y reglas para trabajar con cada uno de ellos.

Tuvimos un montón de reuniones en varios niveles, primero con los líderes técnicos de los departamentos, luego con los líderes del equipo y los propietarios de los servicios, y finalmente con los miembros del equipo. Solicitamos a los representantes de servicio que brinden información sobre el sistema en sí, la pila de desarrollo y los enlaces a repositorios, trabajos pendientes y documentación. En las mismas reuniones, pudimos obtener información de primera mano sobre el dolor: trabajo atrasado interminable, falta de recursos, tecnología antigua (por ejemplo, Delphi).

En el proceso de circulación, hemos formado una comprensión de los enlaces fuertes y débiles en el banco. Había equipos muy maduros (por ejemplo, desarrollo móvil) que ya trabajaban en los principios de InnerSource a escala industrial y compartían una gran cantidad de conos y enfoques. Pero había varios equipos (hola a los Pechenegs) que nos desanimaron por la falta de pruebas automáticas, registro y prácticas de revisión de código.

Entre nuestros equipos hay una gran brecha cultural entre "mi unidad militar está trabajando en las tareas más correctas" y "hagámoslo bien juntos". La mayoría de las reacciones fueron bastante monótonas: "no queremos tomar el código de otra persona y luego responder por él", "no queremos darles a nuestros desarrolladores porque se irán, pero de todos modos no hay recursos". En este punto, se decidió invertir en cultura más que en tecnología:

HR : Google, , 10 % .
PR : Microsoft, open source.
: , - Delphi GraphQL, 10 % , !
, API, JIRA- .

Con algún error, aprendimos a rastrear las interacciones entre equipos que tienen lugar en BitBucket y recibimos información de que tenemos unos 30-50 nuevos autores de cambios de InnerSource agregados cada mes. La cifra en términos del número de desarrolladores en el banco no es muy impresionante, pero estas son solo mejoras en las tareas comerciales.

Como era de esperar, los cambios basados en datos en varios buses de integración y servicios ETL se hicieron muy populares. Esto se explica fácilmente por la gran cantidad de tareas y el bajo costo de las mejoras.

Estudiamos cuidadosamente tales mejoras en el ejemplo de nuestro ESB. Se planea una transición a una nueva solución para ella en el futuro cercano, por lo que no se asignaron recursos adicionales al equipo, mientras que las solicitudes de revisión solo crecieron. En InnerSource, los muchachos vieron la salvación, se inquietaron rápidamente y reunieron un priorizador que plantea su tarea tanto como sea posible si está listo para hacerlo usted mismo. En números, se ve así: en octubre-noviembre, casi la mitad (101 de 209) solicitudes de revisión fueron completadas por los propios equipos. Esto dio como resultado una reducción de cuatro veces en los tiempos de espera de 2.5 meses a 2.5 semanas.

De manera inesperada, los diseñadores tomaron una parte activa, que están felices de ayudar a los equipos relacionados cuando estos últimos carecen de recursos o requieren una nueva mirada. Al final resultó que, hay bastantes equipos que pueden utilizar los diseñadores al 100%, y ellos mismos son creativos y les encanta cambiar el enfoque a algún producto nuevo.

Epílogo

Los primeros pasos para introducir transparencia e interacciones entre los equipos en una empresa que está acostumbrada a vivir las leyes de la empresa son siempre los más difíciles. Podemos decir con seguridad que se han roto los primeros muros y se ha acumulado una cantidad suficiente de historias exitosas de InnerSource para que el movimiento dentro del Sberbank gane impulso.

El principal desafío en el futuro que vemos es evitar la ley de Goodhart . En cualquier empresa mediana y grande, se debe medir la eficiencia: invente un número y haga que crezca. En una conferencia en Baltimore el otoño pasado, se presentaron varios casos en los que establecer objetivos para la preparación de los equipos y la cantidad de mejoras condujeron al sabotaje de las métricas y al agotamiento de los líderes del movimiento.

Creemos que los beneficios resultantes desalientan por completo el esfuerzo invertido, y la apertura en sí misma tiene innumerables ventajas. Estamos listos para contar nuestro camino con más detalle e intercambiar experiencias, escriba a call - innersource@sberbank.ru . Besos, Sberbank.