En la víspera del
equipo dirigimos el desayuno “Equipo remoto. Inicio "hablamos con el director técnico de wemake.services - Nikita Sobolev (
sobolevn ). A pesar de que la búsqueda de un desarrollador, especialmente uno experimentado, es una pesadilla de un líder de equipo o gerente de proyecto, pocos aún deciden cambiar a trabajar con trabajadores remotos. Nikita, sin embargo, hace varios años resolvió este problema radicalmente. Como? ¡Vamos a resolverlo!
Más adelante en la entrevista aparecerán dos: el entrevistador (I.) y Nikita Sobolev (N.)
Acerca de los métodos de trabajo en general y el número de puntos de control.
I .: Casi todos los líderes de equipo y gerentes de desarrollo se quejan de que no pueden encontrar un desarrollador en la oficina. Especialmente en las regiones. Toma a Kazán por ejemplo. Durante seis meses no pueden encontrar un desarrollador por sí mismos, pero aún conservan a todos los que están sentados a su lado en la oficina. ¿Esto parece dar un control ilusorio?
N .: Precisamente, la ilusión de control. Probablemente comencemos por definir el trabajo remoto. Y aquí no quiero marcar la diferencia entre el trabajo remoto y el no remoto, pero necesito mirar el trabajo en sí. En el trabajo requieren cosas diferentes. Hay trabajo en el que acabas de llegar, de 9:00 a 18:00, te sientas, haces algo y, en principio, es suficiente. A este enfoque lo llamo "horas": aquí vienes y, en consecuencia, debes sentarte. Eso es todo. No hay más requisitos formales. Los empleadores particularmente astutos pueden crear un KPI ridículo para minimizar la cantidad de errores en el producto. O alguna otra tontería. Y luego no menos astutos programadores aprenderán a optimizarlo sin actividad útil. Y nada cambiará.
Y el segundo método se llama "por el resultado". Cuando comienzas a verificar el resultado, en principio, no te importa a qué hora vino la persona, a qué hora se fue y qué hizo. Es decir, si es importante para usted que el lunes esta característica funcione, y el lunes funciona, en principio, todo lo demás no le interesa.
I .: Bueno, entiendes que entonces debería haber muchos más puntos de control. Porque puedes esperar un mes por el resultado, y luego resulta que la persona no hizo nada.
N .: Absolutamente sí. El resultado no es algo grande. El resultado es algo pequeño. Cuando intentamos lograr un resultado global, tenemos muchos pequeños intermedios. Y estos pequeños resultados intermedios también son valiosos e importantes para nosotros. Y gracias a ellos vemos un proceso claro, cómo una persona va del punto A al punto B, qué decisiones toma, qué código escribe, qué características ve a continuación, en qué orden las toma. Obtenemos total transparencia. Y, en principio, no nos importa dónde se encuentre, ni remotamente ni remotamente.
Tenemos un proyecto, un objetivo global y un cierto ritmo con el que avanzamos hacia este objetivo. Vemos cada resultado intermedio, podemos controlar su calidad, controlar su dirección global. Como puede ver, el trabajo remoto o no remoto no es importante aquí. El trabajo no remoto es importante para las personas que son las primeras.
Sobre las personas, la programación meditativa y los dos principios fundamentales de udalenka
I .: Sé que todo su equipo está distribuido. Parece que crees mucho en las personas, y leí de otro técnico que no cree en las personas, sino solo en el control y los plazos. Le parece que su posición es tal que una persona puede llevar a cabo la tarea de forma independiente sin instrucciones claras y constantes y control de su parte. ¿Qué opinas: pueden todos los desarrolladores trabajar en este modo? ¿Qué tipo de personas se las arreglará y cuáles necesitan un monitoreo constante?
N .: Realmente creo en las personas. Pero hay algunos matices sutiles. Si una persona vino y dijo lo que haría, en ese momento confío en él. Otra cosa es que sería ilógico confiar en él con algo grande y muy importante. No porque sea malo y engañe, sino porque es algo grande, puede contener muchas dificultades que una persona no puede enfrentar físicamente y decepcionarse, el proyecto y yo. ¿Por qué traer a esta situación? Por lo tanto, la idea principal es que las
tareas deben ser pequeñas y comprensibles .
Confío completamente en una pequeña tarea comprensible para una persona y le digo: “Aquí tienes una tarea para una o dos horas. Puedes hacerlo como mejor te parezca. Aquí están nuestros criterios de finalización, aquí están sus herramientas ". Y, en consecuencia, durante estas dos horas nadie lo toca, él es libre de hacer cualquier cosa. Dos horas después trae y dice: "Aquí está mi resultado". O él dice: “Esto no se puede hacer en dos horas, y por eso. Se me ocurrió una solución para el futuro ".
Sucede que acuden a nosotros personas que están acostumbradas a trabajar en la oficina o que están acostumbradas a trabajar en otra subcontratación. Y no pueden ganar nada en un mes. Solo porque en lugar de seguir nuestras simples reglas, intentan trabajar en el modo anterior. Y, naturalmente, no tienen éxito. Además, ignoran mis consejos y recomendaciones de nuestros bots. Y sí, hay problemas. En consecuencia, si una persona es un empleado de oficina tan típico que está acostumbrado a tener tres reuniones al día y 15 minutos de escribir código, probablemente le resulte difícil. Como no hay reuniones ni otras distracciones, solo hay código y documentación. Por lo tanto, nos estamos moviendo hacia la programación meditativa sin distracciones y cambios de contexto.
Y : Una cosa me sorprende en este esquema: cuando le das a la gente pequeñas tareas, debe haber alguien que vea todo el proyecto y comprenda hacia dónde nos estamos moviendo. Resulta que su carga está aumentando. Y tienes que mantener estas cien pequeñas tareas bajo control, ¿verdad?
N .: Una persona debe tener una imagen completa en su cabeza a dónde vamos. Si las personas en el proyecto no entienden a dónde van y por qué están haciendo algo, no podrán dar un resultado normal. Y así está en todas partes: remoto, no remoto, no importa. Pero para compilar esta visión completa, las personas necesitan comprender el área temática, necesitan comprender el problema comercial, necesitan comprender algunos hitos globales y su conexión con las tareas comerciales y el área temática.
Esto se puede hacer con una descripción detallada de lo que hacemos en la documentación. Es decir, la creación de un solo idioma, requisitos comprensibles, la creación de modelos de negocio y escenarios, gráficos y diagramas comprensibles, decisiones tomadas, casos de uso y escenarios de usuario. No es que solo necesitemos dicha característica, no, sino por qué es necesaria, quién la usará, en cuyo caso, cuáles son los escollos de esta característica.
La documentación crea una comprensión completa de hacia dónde vamos . Diré más, porque tenemos todas estas pequeñas tareas conectadas entre sí, obtenemos una "cadena de tareas" y el desarrollador puede entender dónde comenzamos, hacia dónde vamos y dónde estamos.
El código en sí también es muy importante, que no está escrito en el estilo de "aquí tenemos un montón de basura". Y con una arquitectura clara, con reglas claras, con buenos patrones. Y el código está vinculado a lo que hacemos a un alto nivel comercial. Cuando miras una clase, ya ves que esto no es solo una clase, sino una clase que es responsable de un área determinada de negocios: "¡Oh, ahí está!". En este punto, los buenos desarrolladores comprenden lo que están haciendo y luego pueden comenzar a crear tareas por su cuenta. Harán una pequeña parte, y luego entenderán: "Ah, todavía tenemos que seguir adelante".
Mi único papel en todo esto es simplemente controlar la dirección, bueno, una cierta adecuación.
I .: Comprendí su idea de que una visión común es lo más importante para que una persona entienda / realice correctamente las tareas y vea su contribución al proyecto. Pero en su sistema de trabajo, veo 2 principios más: esto es para tomar, en primer lugar, desarrolladores de un nivel excepcionalmente alto, y en segundo lugar, esta es una documentación muy bien escrita. Derecho?
H .: Eso es correcto. Y ahora estamos volviendo al trabajo remoto. Por qué nosotros, en consecuencia, elegimos esta opción, y no la opción de "oficina". Y ahora notó con precisión que estos dos puntos son clave.
El primero es desarrolladores fuertes. ¿Dónde encontrarlos? Los desarrolladores fuertes de todo el mundo están distribuidos de manera desigual. Y hay puntos donde hay desarrolladores más poderosos y al mismo tiempo son más baratos. ¿Por qué deberíamos competir, por ejemplo, con compañías de Moscú, que pueden permitirse pagar mucho dinero por un desarrollador fuerte cuando nuestros recursos son más modestos? Hay un maravilloso mercado regional, el mercado asiático o el mercado africano, o el mercado de otros países postsoviéticos. Hay desarrolladores fuertes allí, pero son varias veces más baratos.
Es importante comprender que no revendemos el tiempo de los desarrolladores baratos por costosos, como suele hacer todo el mundo. Tratamos de encontrar lo mejor por el mismo dinero. Y ofrecemos un
sistema de pago transparente. Cuánto ha ganado, tanto ha recibido. Debido al mercado local, las empresas tienen problemas con buenos desarrolladores, pero nosotros no los tenemos.
Y el segundo punto es la documentación. La buena documentación solo se puede escribir cuando sea necesaria. Porque si está escrito desde debajo de un palo y no se mira, se actualiza, rápidamente se vuelve malo. Buena documentación, por ejemplo, en proyectos de código abierto, ¿cómo se escribe? Ella es la única fuente de cómo las personas pueden aprender y aprovechar este proyecto de código abierto. Si las personas ven que algo no funciona en la documentación, crean una tarea y dicen: "Algo no funciona en su documentación". Usted dice: "Oh, lo arreglaré ahora". Si una persona se sienta a su lado, simplemente le preguntará: "¿Qué se debe hacer en este momento?" Y te ves obligado a responderle. Y en este proceso, la documentación no será buena. Para que la documentación sea buena, las personas deben estar a distancia y no poder comunicarse directamente.
Sobre el sistema de remuneración y el trabajo en equipo
I .: Es curioso, resulta que cuando las personas están a distancia, es más fácil involucrarse en el proyecto, porque pueden leer la documentación, y en la oficina tienen que buscar quién comenzó a escribirla, de dónde vino esta pieza y qué significa.
N .: Sí, se vuelve más fácil para ellos, porque todo el proceso de trabajo remoto se basa en el hecho de que vendrán nuevas personas. Hay dos opciones de trabajo: automatización y documentación. Muchas cosas son más fáciles de automatizar: por ejemplo, implementar. Y cómo funciona algo es más fácil de describir en texto o en un gráfico.
En los equipos que trabajan en la oficina, me parece que esto es imposible de lograr. Muy a menudo escucho que debes dedicar mucho tiempo a esto, y si estás sentado cerca, entonces trabajas más rápido. Si este es un sprint corto, y necesita hacer un prototipo de alguna aplicación en una semana, probablemente será más rápido trabajar cara a cara. Pero si estamos hablando de un proyecto que dura varios años, entonces acumula todos los problemas conocidos muy rápidamente. Y después de algún tiempo es imposible usarlo. Este es el problema de todo el software que vi, que está escrito en un modelo tradicional.
I .: ¿Qué temores y prejuicios tenía cuando cambió a trabajar con un equipo distribuido? ¿O no lo fueron?
N .: Naturalmente, había temores, y nuestros primeros muchachos, a quienes contratamos en un sitio remoto, trabajaban de acuerdo con el antiguo sistema, es decir, por salarios. Y cuando pagas un salario, no te importa. Porque quieres aprovechar al máximo el tiempo que una persona te vendió. Entonces tuve muchas dudas y prejuicios. Y no había control en absoluto. Pronto me di cuenta de que en este formato, el trabajo remoto no funcionaba.
Como resultado, redujimos ese experimento. Y ahora tengo bastante prejuicio hacia la oficina.
Alguien quiere que esté en algún lugar en un punto específico de la Tierra, limitando mi libertad de movimiento. También quiere que pase todo el tiempo con él, limitando mi libertad de actividad. Es extraño que para muchas personas esta opción parezca normal.
Está claro que siempre hay obligaciones. Pero en mi caso, estas obligaciones son sobre el resultado. Es decir, en ese momento, tengo que hacer esto. Y en el trabajo de oficina, tengo la obligación de ir a la oficina todos los días. Y desde arriba vienen con otros requisitos que puedo posponer hábilmente para más adelante.
La respuesta es muy complicada. Si paga dinero por alguna razón, el equipo remoto es un infierno. Porque no puedes controlar nada en absoluto. Y si todo se hace correctamente, entonces el equipo remoto es el siguiente nivel de organización laboral en comparación con lo que es ahora.
I .: ¿Cómo se ve un trabajo remoto correctamente construido desde su punto de vista? Hay un cierto desarrollador que está listo para trabajar en un sitio remoto, ¿qué sucede después?
N .: Hay un muy buen ejemplo para los desarrolladores. Este es un fenómeno de código abierto. Código abierto: son millones de desarrolladores que se autoorganizan remotamente, nadie realmente ayuda. Y hacen cosas increíbles que todo el mundo usa.
Y un buen trabajo remoto se ve exactamente igual. ¿Cómo comienza cualquier comunicación en código abierto? El desarrollador crea una tarea, dice: "Algo no funciona para mí", o "No entiendo la documentación", o "Quiero una nueva función". Miras lo que hay que hacer para satisfacerlo. Lo siguiente es una discusión, algunas preguntas aclaratorias, tal vez esta tarea supera varias tareas. Y luego se envía un código que cierra estas pequeñas partes. El código se verifica mediante pruebas y linters, se produce una revisión. Y luego se lanzará una nueva versión. En realidad, eso es todo.
Y todo el mundo creado artificialmente en torno a los proyectos, que ahora pertenece a la categoría de "tenemos 15 líderes de equipo, 6 gerentes de proyecto y dos maestros de scrum", es necesario para exprimir más a las personas por el mismo dinero. Porque nadie puede verificar el resultado con toda la ficción de importancia y control. Con un enfoque en los resultados, todo funciona sin ellos.
I .: ¿Crees que hay una manera segura de pasar a un modelo así? Imagine que hay un equipo en la oficina, hay líderes de equipo, hay productos, análisis, etc. Carecen críticamente de desarrolladores, o tienen fakaps permanentes, o los plazos están vigentes. En algún momento, concluyen que no se puede vivir así.
N .: Explicaré, yo mismo no he estado en una situación de transición segura. Y no conozco compañías que cambiarían gradualmente a esta opción. Tuve una experiencia muy traumática. Tuvimos un gran déficit de dinero debido al hecho de que trabajamos a la antigua usanza, y de alguna manera todo salió mal. Tuve que despedir a todos los que tuvimos ese momento, y de hecho comenzar de nuevo. Y este momento, por un lado, fue muy difícil, doloroso y, por otro lado, muy simple, porque no tuve que hacer la transformación en el camino. Me corté y comencé de nuevo.
I .: Muchos gerentes creen que el equipo es su principal valor. Y despediste a todos. ¿Y ahora consideras que tus muchachos que trabajan para ti en diferentes partes del mundo son un equipo?
N .: Por supuesto que no. Generalmente estoy en contra del uso de la palabra "equipo" fuera del negocio. Creo que un equipo es realmente algo único. Todo lo que ahora está tradicionalmente en el mercado es un equipo, en el mejor de los casos. Y en nuestro caso, ni siquiera es un equipo, es solo un conjunto de personas que juntas hacen un proyecto y ganan dinero. No son algo que no sea un equipo, ni siquiera son familiares. Básicamente, ahora la palabra "equipo" se usa como otra manipulación de personas.
I .: Interesante. Se sintió como la mitad de los artículos y discursos sobre la gestión de un equipo distribuido sobre cómo reunir a este equipo cuando está en diferentes zonas horarias, habla diferentes idiomas y cómo hacer que la interacción sea efectiva. ¿Es esto un problema para ti?
N .: No vale la pena. Además, estoy en contra del hecho de que las personas se unieron por la fuerza. Creo que muchas personas cruzan fronteras. Hay una frontera de trabajo, y hay una frontera de vida personal. Y en el trabajo, estoy listo para comunicarme con diferentes personas. Debido a que este es un trabajo, no siempre elijo con quién comunicarme. Es necesario, significa que es necesario. Pero cuando la gente comienza a empujarme la nariz a la fuerza con personas que no quiero comunicarme fuera del trabajo, como "ir a reunirse con ellos". ¿Por qué de repente? Tengo mis propios amigos, tengo mi propia familia, ¿por qué pasaré tiempo sin saber quién, cuando puedo chatear con personas importantes para mí? Para mí esto es completamente incomprensible.
“No”, “quizás” y “sí”: dónde buscar desarrolladores
I .: Entiendo correctamente que simplemente no impones una cultura corporativa y no intentas forzar a tu equipo, y a cambio las personas tienen total libertad para elegir qué hacer, a qué hora y con quién comunicarse. Y dar un resultado, por supuesto.
N .: Sí. Y me esfuerzo mucho por diferenciar entre las cosas que puedo hacer, porque pago dinero por ellas, y que no tengo derecho a hacer, porque solo pago dinero.
I .: Sé que para muchas personas su enfoque causa rechazo. Por ejemplo, en el habr de
este artículo hay comentarios de que eres casi cruel, no le pagarás a nadie, y así sucesivamente. Por qué
N .: Realmente hay tal problema. Las personas ven lo que quieren ver y a lo que están acostumbradas. Si las personas están acostumbradas a vivir en una industria donde son utilizadas, engañadas, manipuladas y arrojadas, entonces lo ven. Si las personas están acostumbradas a vivir en una atmósfera de confianza, en un ambiente de trabajo de calidad y equilibrio, lo ven.
La pregunta es, desafortunadamente, en nuestra industria el primero prevalece sobre el segundo.I .: ¿No le parece que, de hecho, el sistema que ofrece resuelve uno de los principales problemas de los desarrolladores que dicen que realmente escriben código 15 minutos al día? Y el resto se lleva a cabo en manifestaciones y quemado, quemado, quemado ...N .: ¡Por supuesto, lo hice por mí mismo! Y sobre todo me gusta escribir código. Era extraño si creaba un sistema en el que no podía escribir código.I .: ¿Pueden sus mayores ganar lo suficiente por su vida? ¿Y cuántas horas al día pasan para ganar tanto como, por ejemplo, en la empresa de informática estadística promedio en su ciudad?N.: Pueden, pero no todos. Solo aquellos que trabajan mucho y de manera eficiente. Pueden ganar mucho. No hay límite superior y no puede ser. Y algunas personas no podían ganar nada de nosotros.Y también tenemos etiquetas de precios ligeramente diferentes. Son varias veces más altos que los de mercado en Rusia. Es importante entender que no estamos vendiendo los mismos relojes. La hora habitual de trabajo no es nada. Te sientas allí, ves YouTube durante una hora y te pagan por ello. Algunas compañías quieren insertar una sonda en usted para ver lo que hace allí. Por lo tanto, el precio de una hora de tan baja productividad también es bajo. Tenemos una hora de trabajo, este es un costo fijo de la tarea.Pero aquí hay otro problema: el tipo de cambio del rublo ha caído muy fuertemente. Y nosotros, por ejemplo, no podemos trabajar con desarrolladores europeos en absoluto. Teníamos tal experiencia, pero solo obtienen algunas migajas según sus estándares. Muchos simplemente participaron porque estaban interesados, pero por el dinero no fue suficiente. Pero resulta que con los muchachos de otras partes del mundo, porque tienen mucho dinero para su nivel de vida.Resulta tres grupos: el grupo "no" (estos son estadounidenses y europeos), el grupo "quizás" (estos son los nuestros, Ucrania, Bielorrusia) y el grupo "sí" (estos son África, Asia, etc.). Aquí la pregunta es específicamente sobre mi implementación: cuánto puedo vender esta idea a los clientes y cuánto están dispuestos a pagar. Nuevamente, trabajamos solo con clientes rusos. Si ingresáramos activamente en el mercado europeo o americano, pagarían más y este problema se resolvería parcialmente. Pero hasta ahora.I .: ¡Has descrito casi todo el mundo! ¿Cuán amplia es la elección de candidatos con acceso al mercado internacional?N .: Se expande mucho. Todavía no hemos tenido tiempo de trabajar activamente con América del Sur. Y allí, como, también hay muchos buenos desarrolladores.I .: Dime, ¿cómo estás buscando desarrolladores?N .: De ninguna manera. Vienen solos. Están interesados en intentarlo.Los principios de trabajo de PS Nikita pueden y causan opiniones controvertidas, pero el sistema está demostrando ser efectivo. ¿Tiene una experiencia alternativa exitosa en la organización del trabajo de un equipo distribuido? Escribe en los comentarios!Y aquellos que estarán en Kazán el 2 de octubre de 2019, vengan a tomar el desayuno del líder del equipo donde pueden discutir este artículo: expresar toda su indignación o aprobación del enfoque de Nikita, así como escuchar otras 3 historias sobre trabajar con remotos y subcontratistas.