"Constitución" para desarrolladores: cómo una página de GitHub nos ha ayudado a no jurar durante un año

Hace un año, mi equipo creció: la lógica de negocio se estaba volviendo más complicada, de hecho, nos dividimos en tres sub-equipos, cada uno de ellos incluía tanto a los recién llegados como a los que habían trabajado en la empresa durante años. Los subequipos se centraron en sus direcciones, y aunque todos aserraron la facturación, el principio de un área común de responsabilidad dejó de funcionar. Y las prácticas que funcionaron para los "veteranos" no siempre encajaron en el nuevo equipo.







Por lo general, para los equipos de rally, practicamos viajes de campo: el resto del tiempo que trabajan de forma remota desde sus ciudades, se reúnen en una parte del mundo. Por la tarde, realizan parte del sprint, por la noche se divierten juntos. Pero los plazos eran ajustados, así que fuimos al revés. Esto es lo que se nos ocurrió, y parece que este enfoque puede ser utilizado por cualquier equipo en el que no haya una gestión autoritaria.



Gracias a Ray por la idea



En la primavera de 2019, solo se habló del libro “Principios. Vida y obra ”de Ray Dalio. Aleksey Kataev también se enteró de ella: también es el "líder del equipo Leonid" y nuestro entonces líder del equipo.



Ray Dalio? ¿Quién es?
1975- Bridgewater Associates. 2010- - . 100 .



, , , , .


Lyosha llegó a facturación para establecer procesos. Tenía una visión clara de lo que debería ser el equipo y la capacidad de persuadir. Cuando todo funcionó, subió. Y antes de irse, se ofreció a formar contratos y consolidar el trabajo de procesos ya depurados en el equipo, escribiendo "reglas de vida" para el equipo de desarrollo. El nuevo líder del equipo apoyó la idea y comenzó.



Para empezar, leemos esos mismos principios de Dalio . Hay 16 de ellos en total, pero para saberlo todo, necesitas comprar un libro, el significado se puede entender a partir de estos cuatro.

  • Acepta la realidad y trabaja con ella.
  • , , .
  • .
  • , .


Patético, por supuesto. Pero decidimos intentar adaptarlos nosotros mismos. Lyosha esbozó una lista de 10 principios y el equipo la complementó, elevando el número total de resúmenes a 43. Creamos un repositorio en github: es simbólico que las reglas de trabajo se alojarán en el mismo lugar que su resultado.





Y, para ser honesto, es más fácil mantener y desarrollar todo este negocio de esta manera.



Luego empezaron a acortar la lista y mejorar la redacción, evaluando cada ítem según tres criterios: concreción, acuerdo con el principio, importancia. Discutida y perfeccionada hasta que la tesis se adapta a todos los interesados.





Estuvimos de acuerdo en la orilla. Esta fue la idea de Lyosha.



En el proceso, quedó claro lo que estamos viendo de manera diferente, pero después de varios días de discusión activa, tenemos un candidato para el lanzamiento.



imagen

La solicitud del grupo tenía que ser aprobada por todos los miembros del equipo.



Después de la votación final, el líder del equipo lanzó la primera versión oficial de las reglas de Team Life.





Anuncie la lista completa, por favor



Hemos dividido nuestra "constitución" en dos partes: 12 reglas generales de vida y comportamiento en un equipo, más 15 principios técnicos. El texto es bastante largo, por lo que ocultaremos su volumen principal debajo de los spoilers. La ortografía y la puntuación se conservan en el original.



Principios de trabajo



1.1. Seguimos principios aceptados, independientemente de si estamos de acuerdo con ellos.

El desacuerdo personal no es una razón para desviarse de los principios. Sin embargo, puede comenzar a discutir cualquier principio si las circunstancias cambian y ya no es útil.



11 puntos más
1.2

— . — . — . , . , .



1.3

- . , . . . , . . . . — .



1.4

: , , , . — . — .



1.5 ,


1.6

— . : , , , .


1.7

. , , . — .



1.8

— , — . , . , .



1.9


1.10 —

, , — , — . : , , , . , , . -, “ ”, “ ” “ ”. , .


1.11 , ,

. — , , , — .


1.12

. .



Principios tecnicos



2.1. Pensamos en las consecuencias

Antes de una implementación o migración difícil, pensamos en lo que haremos si todo sale mal. Hacemos copias de seguridad, rollback scripts, evaluamos los riesgos de una caída. Ahuyentamos los pensamientos "ah, va a volar, todo estará bien".




13 más puntos
2.2 ,

“ ” -.


2.3

, , , . , .


2.4

!= . .



2.5 , —

— , Skyeng. , , .


2.6 ,

, - , - . “ ” “, ”.


2.7

, :

— RabbitMQ: ,

— : ,



— SOLID, DI, IoC



2.8

— , . : . “ ” — . .



2.9 , QA

. — . — QA. “in development”, production : .



2.10

100% coverage , 100% coverage.



2.11

.



2.12

: , .



2.13

, . , .



2.14

, . , phpdoc, , README.



2.15 No reescribimos proyectos desde cero La

posibilidad de que sea una buena idea es mínima. Eliminamos la idea de escribir algo desde cero desechando el código de trabajo que ha sido probado a lo largo de los años. Estamos mejorando y refactorizando constantemente, haciendo del código de mierda el código de los sueños. Nos deshacemos de los sistemas "dobles", pero no los creamos.



Por cierto, Lyosha hizo un informe por separado sobre el último punto .





De acuerdo, ¿cómo funciona?



  • : , , GitHub — , , .
  • . 360, : . - .
  • — : , . (, ) , , . , ( ) « !». , , . , .
  • , . : , , — « ». , .








Después de un tiempo, el equipo se virtualizó en el mitin de Sochi. Luego imprimimos los principios en papel como papiro, los mostramos y todos recibieron un hermoso folleto que se llevaron a casa.





Teamlead dice que quería conseguir nuestros autógrafos en papel con sangre. Está bromeando, supongo.



Los principios se pueden cambiar ahora. Si a alguien se le ocurre una buena idea, no le gusta algo o desea agregar algo, cualquier miembro del equipo puede crear una solicitud y concertar una votación: 100% “a favor” y la enmienda se ha realizado.



imagen

Lo principal es no tener miedo de negociar y discutir los problemas.



Me pregunto cómo funciona contigo.



All Articles