10 máquinas de escribir para 30 equipos. Estas loco

Hola a todos! Mi nombre es Kostya y encabezo el departamento de diseño de Wrike .
Hay 10 personas trabajando en nuestro departamento ahora, y todos estos tipos vinieron a la compañía en diferentes momentos, tienen diferentes experiencias y tareas en equipos separados. Al mismo tiempo, todos los empleados son excelentes especialistas, que junto con diez logran cubrir las necesidades de diseño de todo el producto.

En este artículo, quiero hablar sobre qué prácticas nos ayudan a alinear el nivel técnico general del equipo, adhiriéndonos a los mismos enfoques en el trabajo, y darles a los chicos oportunidades de desarrollo para que ellos mismos puedan ser mejores y mejorar la interfaz de nuestro producto.

Para aquellos que tienen muchas letras, hay un video .



Y ahora un poco de contexto. Somos una empresa de productos Wrike dedicada al desarrollo de un solo producto. Esta es una aplicación de página única (SPA) para colaborar en tareas y proyectos. En total, la compañía tiene más de 700 personas, y más de 300 ingenieros están trabajando en el desarrollo. Todos los empleados están divididos en 30 equipos de productos: cada uno de ellos trabaja de acuerdo con la metodología Scrum y está formado por diferentes especialistas: back-end, front-end, probadores, diseñadores de diseño, diseñadores de UX, etc. Cada equipo trabaja en su propia pieza de producto. Todas estas piezas se ensamblan en un gran producto, que es utilizado por más de 16 mil empresas en todo el mundo.

El producto es tan grande y complejo que es importante para nosotros distinguir claramente entre los desarrolladores de Frontend que crean lógica de negocios en el cliente y los desarrolladores de UI, en esencia, los codificadores que solo se ocupan del diseño de las interfaces, pero lo hacen con la máxima inmersión y, en consecuencia , con maxima calidad.

Al mismo tiempo, no creemos que el diseñador de diseño sea una etapa intermedia de desarrollo en el desarrollador Frontend. Para nosotros, esta es una rama de desarrollo separada con su propia pila de tecnologías y sus propias complejidades. No todos los diseñadores de maquetación deberían poder programar, pero no todos los desarrolladores de Frontend deberían poder componer.

A pesar de que solo 30 equipos trabajan en Wrike, los codificadores de diez cubren las necesidades de solo 20. El hecho es que no todos los equipos trabajan en tareas para cambiar la interfaz, por lo que solo 20 de ellos están "armados" con su diseñador de diseño permanente.

El equipo de Wrike se distribuye, tenemos varias oficinas en todo el mundo: desde San Diego hasta Voronezh. El principal centro de desarrollo se encuentra en San Petersburgo, parte del desarrollo se encuentra en Voronezh, y ahora se abre una oficina en Praga, donde se trasladarán algunos de los equipos de productos.

Cuando una cantidad tan grande de personas trabaja en un producto en diferentes equipos, ciudades y países, puede ser difícil mantener un enfoque uniforme, los ingenieros tienen el mismo nivel y, en consecuencia, consistencia e igual calidad del código. Si no presta especial atención a esto, pueden surgir una variedad de problemas.

Imagine que es un tipográfico y trabaja en su equipo de producto. Un buen día de mayo, los chicos de otro equipo acuden a ti y te piden ayuda urgentemente: su diseñador de diseño se enfermó unos días antes del lanzamiento importante y necesita ser reemplazado rápidamente, después de haber completado todo lo que no tenía en el camino. En este momento no está muy ocupado y acepta ayudar: solo le llevará un par de días. Luego, descargue el repositorio en el que trabajó su colega y ... se ahogue en él durante una semana, solo para descubrir qué está sucediendo allí. Las noches de insomnio, los plazos de entrega rotos y un tic nervioso se le otorgan como bonificación.

O peor aún: eres el mismo codificador enfermo. Y, al salir de la lista de enfermos, actualiza su repositorio y obtiene 28 confirmaciones de su colega, que destruyen por completo la esbelta arquitectura establecida desde el principio. Por qué Porque tu colega trabajó duro por la noche sin conocer tus ideas y la capacidad de sincronizar con el autor. Y, al parecer, la tarea actual se realiza de alguna manera, pero desarrollar este código aún más será una pesadilla. Todo debe rehacerse, y es bueno si puede explicarlo al equipo y dedicar otra semana de trabajo a lo que parece haberse hecho.

He estado en desarrollo web durante bastante tiempo: trabajé como desarrollador y gerente. Trabajó en estudios web, agencia, producción de outsourcing, y ahora trabajo en un equipo de producto. He visto todo, he visto situaciones similares con el apuro y en compañías mucho más pequeñas que Wrike. Y, por lo tanto, estoy muy contento de que en Wrike, al menos en términos de desarrollo de UI, no existan tales situaciones y no puedan existir, y estoy listo para compartir prácticas que nos ayuden a evitar esto.

En general, si lo piensas, está claro que todo está en las personas y los procesos. Son las personas quienes escriben el código, son ellos quienes construyen los procesos e interactúan de alguna manera. Las personas son tanto una fuente de soluciones como una fuente de problemas. Y si estamos hablando de ingenieros, entonces todo parece ser simple. Para no tener problemas, se deben observar algunas condiciones:

1. Todos los chicos deben ser igualmente de alto nivel. Todos utilizan el conjunto completo de tecnologías necesarias, conocen todas las fortalezas y limitaciones, conocen bien los procesos y se adhieren a los mismos enfoques. Entonces, de hecho, puede asignar la tarea a cualquier ingeniero, y él la resolverá tan bien como a cualquier otro colega;
2. Todos escriben el código igualmente bien. Bueno, o al menos igual. Entonces, de hecho, cuando se combina con el primer párrafo, obtendremos un código consistente y bien mantenido con el que cualquier miembro del equipo puede trabajar;
3. Todos saben quién hace qué. Esto reduce el umbral de entrada cuando se cambia de una tarea a otra, y luego, de hecho, incluso si alguien se enferma o "se cae" del flujo de trabajo por cualquier otro motivo, cualquiera de los colegas estará presente: esto reduce la probabilidad del llamado Factor de Bus;
4. Los miembros del equipo "comparten brotes". El número de equipos está creciendo, al igual que la necesidad de ingenieros. Ya es difícil contratar a esas personas que corresponden a los primeros tres puntos, por lo que sería bueno si los chicos existentes pudieran compartir la incipiente o la clonación, manteniendo el conocimiento actual. Entonces sí, no habrá problemas con el escalado;
5. Enseñar a todos a volar. Para una empresa con varias oficinas en diferentes países, es necesario poder reunir a personas de diferentes oficinas en un solo lugar, porque el valor de la comunicación no verbal para establecer la comunicación difícilmente puede sobreestimarse. Y sería bueno si los chicos, cuando necesitan sincronizarse con alguien, simplemente pueden "volar" a otra oficina, como en los cómics. Entonces, tal vez, no habrá problemas con la distribución de equipos en todo el mundo.

Y si de alguna manera todo esto se implementa en un ingeniero, entonces llamarlo "diseñador de diseño" es de alguna manera incorrecto, y un título como "diseñador de diseño universal en el vacío" es mejor.

Parece que es imposible cumplir con todos estos puntos, especialmente los dos últimos. Pero nosotros, en el departamento de diseño de Wrike, estamos cerca de eso. Y ahora te contaré sobre 7 prácticas que nos ayudan a estar lo más cerca posible del ideal al que nos esforzamos.

1. Lista actual de competencias

Si sabemos qué tareas resolver, debemos entender qué competencias se necesitan para resolverlas. Por supuesto, sería bueno para todos saber todo en el mundo, pero objetivamente esto es imposible y vale la pena resaltar la lista mínima de conocimiento que al menos alguien del departamento debería tener, y mejor para todos.

Que da Requisitos claros para los candidatos: cuanto más cerca esté su conocimiento de la lista de competencias requeridas, mejor.

¿Cómo inventarlo? En algún momento, nos reunimos en todo el departamento y en algunas reuniones escribimos en papel todas las tecnologías que ya estamos usando o que nos gustaría estudiar y comenzar a usar en el futuro. Y con la ayuda de la facilitación llegamos a una lista de competencias con las que absolutamente todos están de acuerdo.

Como resultado, nuestra lista de competencias contiene cosas muy abstractas, por ejemplo, la capacidad de encontrar rápidamente información y tecnologías muy específicas, hasta los comandos específicos de la utilidad de consola git, que creemos que debería ser capaz de usar.
Al mismo tiempo, es completamente normal que en un momento solo una o dos personas en un departamento tengan una de las competencias: en esta etapa, lo principal es que al menos alguien posee este conocimiento, de lo contrario resulta que el departamento enfrenta tareas que nadie en absoluto No es capaz de resolver.

Habiendo terminado con la lista completa de competencias, las hemos agrupado convenientemente en 13 direcciones. Aquí están:

• La capacidad de googlear;
• Medio ambiente (herramientas, git, servir, etc.);
• HTML
• CSS
• Enfoques generales (HTML / CSS);
• UI-kit;
• Scrum
• Angular + Dart;
• Revisión de código;
• JS;
• Conceptos básicos de programación;
• UI / Interfaces;
• Teclas de acceso rápido

Y si el mismo HTML / CSS son estándares comunes de la industria, y podemos esperar que los candidatos estén familiarizados con ellos, entonces había cosas bastante específicas. Por ejemplo, nuestra biblioteca interna del kit de interfaz de usuario. O nuestras herramientas específicas internas, características del entorno, características de enfoques para resolver problemas particulares, etc. El mismo Dart Angular (escribimos la parte delantera del producto en Dart) es algo bastante raro, pocas personas trabajaron con él y esperan que al menos uno de estos estándares sea familiar para un candidato potencial, al menos ingenuamente. Resulta que incluso si contratamos a un especialista experimentado, él todavía no sabrá una buena mitad de lo que consideramos necesario para completar con éxito nuestras tareas. Resulta que contratar y adaptar una nueva persona a un equipo siempre es un poco de entrenamiento. Y cuanto más conocimiento se acumula, la capacitación es más compleja y larga.

Resulta que es simplemente imposible encontrar una persona que cumpla al 100% con nuestros requisitos de experiencia técnica, y tendremos que aprenderlo. Entonces, un principiante debe tener ciertas habilidades de aprendizaje. Y estas son características personales, las llamadas Soft Skills.

Cuando el departamento y el producto son pequeños, y el conocimiento acumulado es pequeño, es ventajoso contratar personas con alta experiencia para compartirlo en un equipo. Y aquí ya las Hard Skills salen a la cabeza.

Cuando el departamento crece, y al mismo tiempo aumenta la cantidad de conocimiento acumulado sobre el producto, no resulta rentable contratar a niños con una amplia experiencia, porque será más difícil para ellos adaptarse a nuevas realidades que son difíciles de cambiar rápidamente. Y aquí es útil contratar a personas que, incluso si no tienen mucha experiencia técnica, pero que pueden adaptarse rápidamente y aprender las tecnologías necesarias. Y las habilidades blandas se destacan, es decir, la alta capacidad de aprendizaje, las buenas habilidades de comunicación. Y es importante que una persona comparta valores ya establecidos y fortalezca al equipo, y no comience a luchar con él. Se trata del llamado Ajuste Cultural.

Es importante que, una vez que se haya unido a un equipo, una persona lo antes posible comprenda las tecnologías y los procesos y comience a aportar beneficios. Y esto nos lleva a una segunda práctica importante:

2. Incorporación con formación integrada

Ya hemos decidido que simplemente contratar a muchachos experimentados no es suficiente e, inmediatamente después de que una persona se va a trabajar, necesitamos enseñarle de manera rápida y efectiva lo que no sabe actualmente. Y no importa si esto es algo mundano, como flex o grid, o alguna herramienta específica con la que simplemente era imposible encontrarse fuera de Wrike.

Para hacer esto, utilizamos Onboarding, del inglés "a bordo", el proceso de adaptar una nueva persona a un equipo. Pero en Wrike, esta no es solo una historia sobre dónde un recién llegado tiene un trabajo, y dónde mirar sus tareas. Nos dimos cuenta de que para nosotros la incorporación es como cursos de educación continua: una especie de capacitación durante varios meses: con una evaluación del nivel actual, un plan de capacitación, un mentor-mentor, varias capacitaciones sobre el producto, las tecnologías y los procesos. De acuerdo con los resultados de la incorporación, esperamos que una persona aprenda todo lo necesario para completar sus tareas y se acerque lo más posible a sus habilidades incluso a los muchachos más experimentados del departamento.

En general, el proceso de nuestra incorporación es un tema para un artículo separado, pero por ahora quiero detenerme en una cosa clave: la rosa de las competencias.

Según los grupos de competencias que hemos formulado anteriormente, podemos evaluar a cualquier empleado o incluso a un candidato en cada dirección y construir un diagrama radial de este tipo:



Cada rayo es un cierto grupo de habilidades. El punto es el porcentaje de tecnologías y enfoques dominados inherentes a este grupo. Cuanto más una persona sabe y sabe cómo, más se acerca su diagrama al círculo ideal. El que tiene absolutamente todas las habilidades de nuestra lista de competencias es el diseñador de diseño muy esférico en el vacío que necesitamos.

Es importante comprender que dicho gráfico (también conocido como la rosa de las competencias) no se usa para la evaluación del desempeño, es decir, no lo usamos para entender quién es un buen diseñador de diseño y quién es malo. No hay un nivel mínimo en cada una de las áreas debajo de las cuales es imposible caer. Este cuadro da una idea de dónde una persona tiene fortalezas y dónde están los puntos de crecimiento. Estamos preparados para el hecho de que todos en el departamento no saben algo, especialmente si es un principiante. Pero, mirando la rosa de las competencias, es bastante fácil entender qué cosas se deben sacar en primer lugar.

Cuando un recién llegado se acerca a nosotros, se construye una rosa para él, y ellos, junto con su mentor, elaboran un plan de capacitación durante 2-3 meses, avanzando para que una persona sea bombeada y se acerque al ideal deseado.

Y, según los resultados, después de realizar esta capacitación, la rosa se está reconstruyendo y el progreso se está haciendo evidente.



No esperamos un resultado del 100% en cada dirección, es importante para nosotros que haya un progreso significativo. Y, de hecho, este diagrama se puede utilizar incluso después de completar la incorporación, para no quedarse quieto y seguir desarrollándose. Alguien puede bombear sus propias direcciones de interés hasta el 100% e incluso más, y alguien puede agregar una nueva dirección y desarrollarse desde una máquina de escribir en un área adyacente. También tenemos tales ejemplos y prácticas.

Que da Un plan de desarrollo claro para principiantes. Por lo tanto, todos llevamos a un solo nivel, minimizando la brecha entre los "viejos" y los "recién llegados".

Además, esto reduce los requisitos para los candidatos: si aún entrena, ¿no es lo mismo para qué? Como resultado, no tenemos requisitos realmente obligatorios para las habilidades difíciles para los candidatos. Está claro que no podemos contratar personas sin conocimientos básicos, pero se puede aprender mucho en la etapa de incorporación. Lo principal es que una persona es capaz, y el resto es un negocio.

Entonces, sabemos a quién estamos buscando, qué habilidades se necesitan y cómo capacitarlos, pero este conocimiento es relevante hoy en día. Y el tren delantero se apresura a toda velocidad, manchando a todos los que tropezaron y siguieron los rieles. Y necesitamos algún tipo de proceso de introducción de nuevos conocimientos para que todo el departamento no se quede atrás de los requisitos modernos. Y eso nos lleva a una tercera buena práctica:

3. Actividades regulares de entrenamiento

Para mantenerse al día con el mundo moderno, es importante controlar lo que está sucediendo en él. Vaya a conferencias, lea artículos especializados, pruebe nuevas tecnologías e impleméntelas en su trabajo.

Sería extraño arrastrar a todos a todas las conferencias y cursos disponibles, esto no es efectivo. Pero uno de los muchachos, de una forma u otra, está estudiando algo por su cuenta o con el apoyo de Wrike: enviamos a conferencias, pagamos cursos especializados y, en general, apoyamos en todos los sentidos a aquellos que quieren bombear. Y si en todo el flujo de información es posible obtener algo útil para sí mismo, entonces sería bueno llevarlo al departamento y compartir conocimientos con todos. Para esto, los eventos regulares de capacitación interna nos ayudan. Pero, ¿cómo entender quién y qué puede enseñar todo el departamento? La misma rosa de competencias nos ayuda en esto. Pero no en el contexto de cada empleado, sino en el contexto de todo el departamento.



Mirando un cuadro así, es fácil identificar a un experto en alguna área y pedir compartir su conocimiento con todos los demás.

También puede ver que, a pesar de que nosotros mismos hemos determinado un cierto nivel de conocimiento en una de las áreas, nadie en el departamento tiene el 100% de conocimiento. Y esta es una ocasión para atraer a un experto externo que realizará un taller o conferencia para nosotros y elevará el nivel general de conocimiento en todo el departamento. Por ejemplo, debido a la necesidad de aprender los conceptos básicos del lenguaje Dart, encontramos un mentor en la empresa, un desarrollador fuerte que realizó un curso de conferencias sobre Dart para todo el departamento de diseño. Esto no nos hizo desarrolladores, porque no había tal tarea, pero al menos ahora entendemos mejor el front-end. O tal vez alguien, después de haber sentido la nueva tecnología, piense en cómo volver a entrenarse en FE, que también es bueno.

Todo lo que nos queda es revisar periódicamente la lista de nuestras competencias, complementando con nuevas tecnologías relevantes. Luego, la rosa será reconstruida, y veremos el nivel general del departamento, podremos administrarlo y nunca nos quedaremos atrás del motor de la parte delantera.

Por lo tanto, tenemos un conjunto de especialistas geniales que tienen aproximadamente la misma fuerza y ​​no se quedan atrás de las tendencias actuales. E incluso sabemos cómo reponer sus filas. ¿Cómo sincronizar ahora su trabajo? La cuarta práctica importante nos ayuda con esto:

4. Revisión cruzada obligatoria

Permítame recordarle que todo nuestro trabajo se lleva a cabo en equipos de productos. Y cada equipo cuyas tareas están asociadas con el cambio de la interfaz tiene su propia tipografía permanente. Un tipo de letra puede tener varios comandos, pero solo si uno no lo carga al 100%. Y si deja al especialista solo consigo mismo, tarde o temprano, él diseña su propia forma de escribir, que el resto nunca sabrá.

Para que esto no suceda y las mismas tareas sean resueltas por todos aproximadamente lo mismo, cada tarea y solicitud de fusión pasa por un código de revisión obligatorio.

Es importante mirar la revisión del código no tanto como la función de control para que nadie ponga algo malo en el maestro, sino más bien en la etapa en la que dos ingenieros de diferentes equipos, con diferentes antecedentes y tareas, acordaron cómo resolverlo. uno u otro problema

¿Qué da una revisión cruzada?

En la etapa de revisión, puede obtener una vista externa: cómo se puede hacer mejor la tarea, lo que reduce la cantidad de errores y hace que el código sea coherente. También es un proceso de aprendizaje mutuo: el autor del código no solo pasa la "validación" del revisor, sino que también puede ver cómo se resolvió el problema y ponerlo en servicio. Y así, a través del proceso de revisión cruzada, se desarrollan y distribuyen viajes comunes en toda la empresa.

Habiendo desarrollado enfoques comunes, sería bueno guardarlos en algún lugar, para que los principiantes puedan obtener este conocimiento no solo de sus colegas, sino también de forma independiente. Esto nos lleva a la siguiente práctica importante:

5. Código de estilo y revestimiento automático

Es importante que el código sea consistente y consistente con las reglas generales desarrolladas en el departamento. Lo más básico es Codestyle común a todos. Es importante que estas reglas estén claramente fijadas y disponibles públicamente para cualquier persona de la empresa. Porque nunca adivinará de antemano quién tendrá que trabajar con su código.

Mejor aún, asegúrese de que el código coincida con las reglas dadas automáticamente por el linter: las máquinas deberían sufrir, no las personas. Por ejemplo, hemos desarrollado e implementado el linting para plantillas de marcado y el linting de menos archivos.

¿Qué da el revestimiento automático?

Bueno, en primer lugar, es banal escribir código: todos los errores se resaltan directamente en el código, mientras aún está en contexto. Y no hay necesidad de distraerse comprobando el estilo del código: esto lo hará el complemento para el IDE.

En segundo lugar, es más fácil realizar y aprobar una revisión de código: en MR simplemente no hay errores y no puede haber errores de estilo de código y puede concentrarse en la esencia de la tarea.

En tercer lugar, la alineación automática en el proceso de escribir código también es una forma de estudiar el estilo del código. No importa si está familiarizado con el estilo del código o no, ya en el momento de escribir el código, y más aún cuando intente confirmar el código, el linter mostrará una lista de errores y enlaces a las reglas que violan exactamente en la cantidad que necesita aquí y ahora . Y así, inevitablemente aprenderá el estilo del código por prueba y error.

Parece que a pesar del hecho de que todos trabajan en diferentes equipos y en diferentes tareas, hay muchos puntos en común. Y deben poder coordinar: quién, qué y cuándo revisar, quién, cuándo, qué, qué reglas agregar al estilo de código y cuáles no, etc. Todas estas actividades necesitan poder sincronizarse. Otra práctica importante nos ayuda con esto:

6. Stand-up diario

El departamento no tiene sus propios sprints y planificación (solo los equipos de productos que tienen diseñadores de diseño trabajan para ellos), pero de todos modos aprendimos algunas de las prácticas de Scrum. Es decir, el stand-up diario es una reunión para la que nos reunimos y discutimos temas urgentes: discutimos las tareas completas y actuales, y las futuras. Esto es importante solo en el contexto de la secuencia de tareas para la revisión, y como beneficio adicional, puede discutir los problemas que surjan, pedir consejo a sus colegas o compartir noticias de sus equipos.

Es importante que el stand-up pase rápidamente, no más de 15 minutos al día. Porque incluso 15 minutos al día, multiplicados por 10 personas, cuestan entre 40 y 50 horas hombre por mes. Es como una semana entera del trabajo de una persona. Por lo tanto, el rally en sí debería ser lo más corto y efectivo posible. Y solo si hay problemas que requieren una discusión por separado, quedan fuera del marco del Daily y las personas interesadas los discuten por separado, sin perder el tiempo de los demás.

Utilizamos una pizarra interactiva con tareas con las que cualquier diseñador de maquetación puede trabajar en cualquier momento desde cualquier ciudad. En el Daily, todos los que se reúnen en San Petersburgo en un gabinete en el televisor donde se muestra este tablero, y aquellos que trabajan en otras ciudades se conectan a través de Zoom. Además de las cámaras web, esto da el efecto de problemas de presencia y distribución que no experimentamos.

El stand-up diario nos brinda un cierto espacio de información común donde cualquier pregunta relacionada con el diseño puede resolverse, solo pregúntelo en voz alta y la mente colectiva sintetiza la respuesta, porque alguien ya se ha dado cuenta de esto. O algún grupo de chicos interesados ​​puede ayudar a encontrar una solución para una nueva tarea extravagante.

Entonces, sabemos cómo contratar y capacitar a especialistas geniales, sabemos cómo coordinar sus acciones para mantener un código de alta calidad. Pero hay una emboscada: si una persona quiere desarrollarse como especialista y hacer bien su trabajo, lo hará sin importar qué. Incluso si todos estos procesos no existen. Solo ayudan. Y si no quiere, incluso los procesos ideales y el super entrenamiento no harán que una persona se mueva. Todos deberían estar realmente involucrados e interesados ​​en el destino futuro propio, y la compañía, y el producto. Y esta es la última en la lista, pero en realidad la práctica más importante:

7. La participación de todos en los proyectos del departamento.

Idealmente, cada empleado debe tener un plan comprensible para el desarrollo de sí mismo y del departamento al menos para el próximo trimestre. Y es bueno si todos lo tienen en su cabeza. Pero el flujo de tareas actuales no siempre tiene tiempo para pensarlo.

Para que nadie se quede en el nivel actual y no se "agria" en su equipo, hemos introducido la práctica de reuniones regulares "uno a uno" con el líder o líder de su equipo. Estas son reuniones en las que puede hablar sobre su desarrollo, el desarrollo del equipo, el departamento y la empresa, y lo que puede hacer para esto en este momento. En la reunión, puede obtener comentarios sobre usted y coordinar acciones, o puede dar comentarios sobre sus tareas, sobre los procesos en el equipo o departamento y, por lo tanto, influir en ellos.

Además del 1: 1 regular, los "proyectos" nos fueron bien. De una forma u otra, los procesos y tecnologías en el departamento necesitan ser bombeados, se debe introducir algo nuevo y se debe eliminar lo viejo e irrelevante. Todos en el departamento tienen la oportunidad de proponer tal cambio, por ejemplo, introducir una nueva tecnología. O elimine un enfoque heredado que interfiere con la vida.

Y, si tal cambio es realmente útil, cualquiera puede asumir el proyecto para su implementación. Esto significa que usted realiza un trabajo de investigación o trabajo de manera independiente, o reúne un equipo de proyecto y administra sus actividades para lograr los objetivos del proyecto. A menudo, esto requiere un estudio en profundidad de las nuevas tecnologías o la búsqueda de respuestas a preguntas que antes no se podían resolver.

Todos pueden elegir por sí mismos el proyecto que le interesa. Por lo tanto, una persona se desarrolla en un área de interés para él y bombea todo el departamento.

Y una vez al mes, para que el trabajo en los proyectos sea transparente para todos, reunimos a todo el departamento en estilo retro y compartimos nuestros éxitos u ofrecemos nuevos proyectos.

Estas siete prácticas nos permitieron contratar e integrar 6 diseñadores de diseño en el departamento y los equipos en un año. Por el momento, esto es casi ⅔ de todo el departamento. Buen resultado

¿Y los vuelos?

No podría prescindir de la magia, todo gracias a la magia de la automatización y a nuestra hada de viaje Ane.
Si por alguna razón de trabajo necesita estar en otra oficina, por ejemplo, chatear con alguien en persona, entonces todo lo que se necesita es completar un formulario especial directamente en Wrike, indicar las fechas y el propósito del viaje. Y en el momento adecuado en el correo habrá boletos de avión. Todo lo que queda es tomar una computadora portátil, pasaporte y no llegar tarde al vuelo. Entonces nuestras máquinas de escribir vuelan sin problemas :)

¿Pero qué pasa si su empresa aún no tiene esas prácticas?

Si usted es un líder de equipo o líder, entonces el consejo es muy simple: "Aquí está la lista de verificación, tómala e impleméntala". Creo que cada líder está interesado en el crecimiento de sus empleados y la calidad del código.

¿Y si usted es un tipográfico simple o incluso un profesional independiente, no tiene que depender del soporte "desde el aire"? Por extraño que parezca, el consejo es exactamente el mismo.

El truco es que la implementación de todas estas prácticas no requiere grandes inversiones o costos laborales, puede promoverse "de abajo hacia arriba" por iniciativa de los empleados comunes. Lo principal es que hay un deseo de bombearse y mejorar el mundo que te rodea.