<\/a><\/noindex><\/p>\nUn grupo de estudiantes linuxeros<\/h2>\n \nDmitry Stolyarov (director t\u00e9cnico) durante su presentaci\u00f3n<\/i><\/p>\n
\u2014 (Dima Stolyarov)<\/b> Siempre hemos trabajado con Linux y c\u00f3digo abierto, pero comenzamos con un tema muy gracioso, del que ahora nos da un poco de verg\u00fcenza. Por alguna raz\u00f3n, pens\u00e1bamos que ten\u00edamos que implementar Linux en las oficinas en lugar de Windows. El primer nombre de la empresa fue TrueOffice \u2014 'oficina verdadera'. Luego entendimos que a nadie le interesaba eso. Fue en 2006, ten\u00eda 19 a\u00f1os. Solo alrededor de 2012-13 lleg\u00f3 la comprensi\u00f3n de c\u00f3mo hacer negocios, qu\u00e9 tecnolog\u00edas necesita el mundo.<\/p>\n
Alexander Batalov (director general) en el stand de la empresa en la conferencia<\/i><\/p>\n
\u2014 (Sasha Batalov)<\/b> Adem\u00e1s de las tecnolog\u00edas, hay una enorme \u00e1rea en marketing, ventas y econom\u00eda, que nadie nos ense\u00f1\u00f3 jam\u00e1s, excepto en los cursos de la universidad, pero no s\u00e9 cu\u00e1n aplicables y \u00fatiles son realmente. <\/p>\n
Al principio pensamos que todo esto no era necesario, pero luego tuvimos que aprender en la pr\u00e1ctica, leer libros, a veces ya despu\u00e9s de haber cometido errores. En general, transitamos por un camino largo y espinoso, probando un mont\u00f3n de cosas equivocadas. <\/p>\n
\u2014 (\u0414\u0421)<\/i> Pero poco a poco, a medida que aumentaba nuestra calificaci\u00f3n, nos especializamos cada vez m\u00e1s en Linux, y ahora solo nos dedicamos a proyectos web de alta carga. Y cuando apareci\u00f3 Kubernetes, entendimos r\u00e1pidamente que era la base que tanto necesit\u00e1bamos. <\/p>\n
\u2014 \u00bfPor qu\u00e9 hab\u00eda tanto inter\u00e9s en Linux? \u00bfIdeol\u00f3gico o tecnol\u00f3gico?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> La empresa tiene dos fundadores: Dima Shurupov y yo. A Dima Shurupov le interesaba m\u00e1s el c\u00f3digo abierto. A m\u00ed me gustaba espec\u00edficamente Linux, tecnol\u00f3gicamente, c\u00f3mo est\u00e1 todo organizado. Y result\u00f3 una combinaci\u00f3n: a Dima le atrae la ideolog\u00eda, y a m\u00ed la tecnolog\u00eda. Me gusta el c\u00f3digo abierto como idea, pero siempre me ha importado m\u00e1s el aspecto tecnol\u00f3gico.<\/p>\n
Einstein dijo: \"Hay que hacerlo tan simple como sea posible, pero no m\u00e1s simple\". As\u00ed es como est\u00e1 construido Linux: tan simple, confiable y transparente, que lo disfruto. A todos nos gustaba, y pasamos de ser un grupo de estudiantes a una gran empresa. Ahora somos 70. Para TI, para servicios especializados, eso es bastante.<\/p>\n
\u2014 \u00bfC\u00f3mo era todo durante la \u00e9poca del grupo de estudiantes?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Como suele ser en la vida estudiantil, divertido y animado.<\/p>\n
\u2014 (\u0421\u0411)<\/i> Una enorme cantidad de altruismo, el deseo de conquistar internet, de alcanzar cumbres tecnol\u00f3gicas. Nos involucramos en tareas muy complejas: a veces asum\u00edamos proyectos serios (pero muy interesantes) de integraci\u00f3n de sistemas, realiz\u00e1ndolo por poco dinero. Intent\u00e1bamos crear nuestros propios frameworks, absorb\u00edamos todas las tecnolog\u00edas que conoc\u00edamos y busc\u00e1bamos aplicaciones para ellas de inmediato.<\/p>\n
\u2014 \u00bfY comercialmente c\u00f3mo les fue?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> S\u00ed, pero en las primeras etapas no necesit\u00e1bamos nada. En esos tiempos, para m\u00ed, 40 mil rublos era un ingreso absolutamente normal, me daba ciertos lujos.<\/p>\n
\u2014 (\u0421\u0411)<\/i> Yo pensaba que con mil d\u00f3lares se pod\u00eda hacer cualquier sitio que se te ocurriera.<\/p>\n
\u2014 (\u0414\u0421)<\/i> En 2013 no ten\u00edamos dinero para contratar libremente en Mosc\u00fa. Ya hab\u00edamos contado con todos los conocidos que pod\u00edamos. Decidimos abrir una oficina en Nizhni N\u00f3vgorod. Fuimos all\u00ed, la abrimos, empezamos a contratar. Luego nos dimos cuenta de que era dif\u00edcil vivir con dos oficinas y decidimos vivir sin oficinas en absoluto.<\/p>\n
Por supuesto, hemos enfrentado muchos desaf\u00edos. Solo en 2016, para mi verg\u00fcenza, le\u00ed Remote. Llor\u00e9 y re\u00ed porque nuestro camino fue exactamente el mismo. Cada p\u00e1rrafo se cruzaba con mi experiencia personal. <\/p>\n
\u2014 (\u0421\u0411)<\/i> En cada p\u00e1rrafo estaban nuestras cicatrices.<\/p>\n\nQu\u00e9 hace Flant<\/h2>\n \n
Para lograr una operaci\u00f3n de producci\u00f3n de calidad, se necesitan de 15 a 20 DevOps, especialistas en bases de datos, expertos en Kubernetes, soporte t\u00e9cnico, y as\u00ed sucesivamente. Y si la empresa es peque\u00f1a, donde solo hay un par de docenas de desarrolladores, esto no es posible. Ah\u00ed es donde entramos nosotros y ofrecemos nuestra ayuda. Por unas 150,000.<\/p>\n
Antes ten\u00edamos la misi\u00f3n de crear una empresa donde nosotros mismos quisi\u00e9ramos trabajar, por m\u00e1s tonto que suene. Ahora que lo hemos logrado, nuestra misi\u00f3n es hacer tecnolog\u00edas a nivel de Google y Facebook accesibles para peque\u00f1as empresas y startups en etapas iniciales.<\/p>\n
Las personas pueden concentrarse en su producto, y no en superar problemas que no deber\u00edan afrontar.<\/p>\n
Muchos de los que vienen a nosotros se sorprenden de cu\u00e1n diversas son las cargas y cu\u00e1ntos proyectos diferentes tenemos. Gestionamos m\u00e1s de 50 proyectos en producci\u00f3n, m\u00e1s de 70 cl\u00fasteres de Kubernetes. Se puede complicar siempre. Abres un diagrama, trazas una arquitectura de microservicios, haces una lista de 200 tecnolog\u00edas y vamos. Pero siempre eso lleva a problemas y consecuencias. <\/p>\n
La clave es proporcionar, por un lado, la m\u00e1xima estabilidad, fiabilidad y simplicidad, y por otro lado, un alto nivel de innovaci\u00f3n. Nos enorgullece que sabemos hacer eso. Lo hacemos en todas partes y a gran escala, como una Ikea condicional.<\/p><\/blockquote>\n
\u00bfQui\u00e9n necesita DevOps subcontratados?<\/h2>\n \nMe parece que las grandes empresas prefieren tener DevOps en su plantilla.<\/b><\/p>\n
\u2014 (\u0421\u0411)<\/i> Es evidente que los grandes actores, como Avito o Badoo, pueden contratar a su propio personal de DevOps. Las peque\u00f1as empresas con enormes inversiones tambi\u00e9n pueden hacerlo, pero aunque pueden contratar, no es seguro que tengan la fuerza suficiente para gestionarlo.<\/p>\n
Creemos que incluso las grandes empresas es mejor que se dirijan a expertos que realmente saben del tema. Para las peque\u00f1as empresas, que dependen de soluciones web, es absolutamente necesario acudir a personas con experiencia. Porque cualquier error en un sistema clave significa perder dinero.<\/p>\n
\u2014 (\u0414\u0421)<\/i> Sabemos que la gente en Rusia tiene miedo del outsourcing, debido a experiencias negativas y otras razones personales. Pero nuestros clientes no se van. En diez a\u00f1os, s\u00f3lo se han marchado por dos razones. O nos han superado (por ejemplo, han sido adquiridos y todo se reorganiz\u00f3), o se cerraron porque la idea no funcion\u00f3.<\/p>\n
\u2014 \u00bfY qui\u00e9n viene a ustedes m\u00e1s a menudo \u2014 las peque\u00f1as empresas o las grandes?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Ahora es igual. Pero las peque\u00f1as simplemente nos temen, piensan que somos... <\/p>\n
\u2014 (\u0421\u0411)<\/i>... grandes, complicados, inalcanzables y estamos en las nubes. <\/p>\n
\u2014 (\u0414\u0421)<\/i> S\u00ed, pasas junto al concesionario con un Maybach y no entras, no preguntas el precio, porque no puede ser que un Maybach cueste 500 mil rublos. <\/p>\n
\u2014 Claro que no puede.<\/b><\/p>\n
\u2014 (\u0421\u0411)<\/i> Pero en cuanto aparece en un servicio de carsharing, uno puede permitirse un paseo en \u00e9l. <\/p>\n
\u2014 (\u0414\u0421)<\/i> S\u00ed, por supuesto, no somos un Maybach \u2014 somos Ikea. Tambi\u00e9n hemos conseguido que sea simple, fiable y accesible. En general, el n\u00famero de empresas de las que nos contactan, tanto de la lista TOP-50 como peque\u00f1as empresas, es igual para nosotros. Pero nos enfocamos principalmente en las peque\u00f1as empresas y trabajamos principalmente con ellas, mientras que tratamos de evitar colaborar con las grandes. <\/p>\n
\u2014 \u00bfPor qu\u00e9?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Mucha burocracia.<\/p>\n
\u2014 (\u0421\u0411)<\/i> En una gran empresa hay muchos niveles, donde se distribuye la responsabilidad, la retroalimentaci\u00f3n es muy lenta, y a menudo las personas comienzan a jugar con la tecnolog\u00eda: '\u00bfY si pesamos, escribimos una estrategia, un plan para un a\u00f1o adelante, hagamos esto de manera m\u00e1s bonita para la cultura empresarial, as\u00ed es como ha funcionado nuestra pr\u00e1ctica'. Y as\u00ed comienzan a complicar cosas que se podr\u00edan resolver de manera sencilla y r\u00e1pida, de forma que el 80% del resultado podr\u00eda estar listo ma\u00f1ana. Siguen un camino largo donde no se sabe si funcionar\u00e1 o no. <\/p>\n
Como resultado, en lugar de pr\u00e1cticas maduras, estamos reinventando la rueda, y el costo de la soluci\u00f3n tecnol\u00f3gica se vuelve incomparablemente m\u00e1s alto. Al mismo tiempo, la calidad no es un hecho que mejore. <\/p>\n
\nCosto del outsourcing<\/h2>\n \n
Todos en la empresa contribuyen de una u otra manera, ya sea con comentarios, documentaci\u00f3n o c\u00f3digo. Creemos que esta es nuestra forma de retribuir al rico mundo de utilidades de c\u00f3digo abierto que utilizamos. Y considero que lo hacemos de manera digna.<\/p>\n
Lo llamamos condensaci\u00f3n de experiencia. Originalmente, una persona aprendi\u00f3 algo, lo comparti\u00f3 con colegas y la experiencia se convirti\u00f3 en folclore. Luego documentamos todo y, finalmente, lo convertimos en utilidades, olvidando su existencia porque ya no pensamos en ello; todo se contabiliza autom\u00e1ticamente.<\/p><\/blockquote>\n
La popularidad de las tecnolog\u00edas y la toxicidad de los desarrolladores.<\/h2>\n \n\u2014 \u00bfPor qu\u00e9 exactamente Ubuntu? Antes de elegirlo, \u00bfqu\u00e9 m\u00e1s consideraron?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> \u00c9ramos un grupo de estudiantes a los que les gustaba Linux. Usamos Gentoo durante mucho tiempo, que es una distribuci\u00f3n basada en fuentes y que requiere compilarse desde cero cada vez. Cuando tuvimos unas cientos de servidores, las actualizaciones tomaban meses. Por supuesto, inicialmente automatizamos y optimizamos todo, pero al final entendimos que hab\u00eda que cambiar algo y, sabiendo los pros y contras de diferentes soluciones, simplemente elegimos la m\u00e1s popular. En ese momento, fue intuitivo: si es la m\u00e1s popular, significa que se desarrollar\u00e1 mejor y todos los defectos se corregir\u00e1n tarde o temprano. <\/p>\n
Hab\u00eda una base de datos llamada Resync DB. Compet\u00eda con MongoDB y comenz\u00f3 aproximadamente al mismo tiempo. Durante mucho tiempo, Resync era tecnol\u00f3gicamente superior.<\/p>\n
Cuando llegaban los usuarios, intentaban resolver problemas internos del sistema, mientras que en MongoDB los resolv\u00edan mucho menos, pero pod\u00edan, en teor\u00eda, imponer condiciones para lucir mejor en pruebas sint\u00e9ticas. Por eso crec\u00eda la popularidad de MongoDB. En los casos m\u00e1s simples se mostraban mejores, pero por dentro eran defectuosos. Resync DB, en cambio, era bueno por dentro, pero no lograba crecer en popularidad.<\/p>\n
Al final, por dentro MongoDB se volvi\u00f3 bueno, mientras que nadie recuerda a Resync DB. La compa\u00f1\u00eda se declar\u00f3 en quiebra. Con Ubuntu hay una historia similar. Este sistema tiene mucho enfoque, as\u00ed que decidimos utilizarlo.<\/p>\n
\u2014 \u00bfQu\u00e9 opinas de los recientes cambios pol\u00edticos, el CoC y todo eso?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Bueno... no hay nada negativo, todo est\u00e1 bien, todo es claro. Yo mismo sufro a veces porque lastimo a las personas. A veces, una cosa me parece obvia, y me irrita mucho que la gente no la entienda. Me enfado y eso genera un ambiente negativo (pero estoy trabajando en ello).<\/p>\n
Linus es muy inteligente, despu\u00e9s de todo ha estado trabajando en esto durante 30 a\u00f1os. Es evidente que es una persona directa, no tiene problema en expresar lo que piensa. Su cortes\u00eda se resiente, y la comunidad est\u00e1 trabajando en eso. \u00c9l lo entiende y lo acepta. <\/p>\n
\u2014 Pero, por lo que comprend\u00ed de la reacci\u00f3n en las discusiones, muchas personas apoyan la idea de hablar de manera directa y contundente, y si a alguien no le gusta, pues que no le guste.<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> No, no es as\u00ed. Yo, como persona que carece de cortes\u00eda, entiendo que eso es muy malo. Da\u00f1a a la comunidad. Hay personas a las que no les importa, pero a la mayor\u00eda de la gente le importa tener comodidad emocional.<\/p>\n
Aqu\u00ed hay un error tonto en el c\u00f3digo. Se podr\u00eda escribir: \"Chicos, es malo que nos saltemos cosas tan simples, hay que corregirlo\". Pero se puede escribir: \"\u00bfQu\u00e9 idiota hizo esto?\". Una frase. La persona que cometi\u00f3 este error puede ser incluso m\u00e1s inteligente y experimentada que t\u00fa, pero simplemente no estaba de buen humor cuando se equivoc\u00f3; puede haberle pasado algo. Y para \u00e9l ser\u00e1 una ofensa directa. \u00bfPor qu\u00e9 necesitamos eso?<\/p>\n
Es necesario hablar las cosas directamente, pero no hay necesidad de decir \"\u00bfQu\u00e9 idiota escribi\u00f3 esto?\". No tiene sentido ocultar y envolver, pero tampoco hay que ofender a las personas.<\/p>\n
\u00bfPor qu\u00e9 los DevOps tienen que reunirse todos los d\u00edas?<\/h2>\n \n(\u0414\u0421)<\/i> Ahora tenemos una peque\u00f1a oficina donde hay documentos y un gerente de oficina que se ocupa de esos documentos.<\/p>\n
En la empresa hay 70 personas. 20 son del equipo de OPS. 30 son tres equipos de DevOps de aproximadamente 10 personas cada uno. Los otros 20 son desarrolladores y ventas. Hay 8 desarrolladores y el departamento de I+D tiene 4 personas. En toda la empresa hay 5-6 personas que no son t\u00e9cnicas.<\/p>\n
El dinero clave lo generan los tres equipos de DevOps. Los procesos son iguales en todas partes: cada d\u00eda hay una larga reuni\u00f3n de una hora a hora y media. All\u00ed se abordan todas las cuestiones t\u00e9cnicas, y los chicos deciden qu\u00e9 hacer a continuaci\u00f3n. Y como todos est\u00e1n trabajando de forma remota, esa es una oportunidad para comunicarse adecuadamente.<\/p>\n
\u2014 \u00bfEs realmente necesario hacerlo cada d\u00eda?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> S\u00ed.<\/p>\n
\u2014 \u00bfTodos est\u00e1n de acuerdo con esto?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> S\u00ed, todos est\u00e1n de acuerdo, todos est\u00e1n c\u00f3modos. Pero en algunos d\u00edas, la reuni\u00f3n puede durar incluso 30 minutos. A pesar de la intensa comunicaci\u00f3n en Slack, a\u00fan queremos sincronizarnos bien y entender qu\u00e9 sucedi\u00f3 ayer. Queremos entendernos entre nosotros, no solo hacer clic en tareas. Este es un aspecto culturalmente importante.<\/p>\n
\u2014 (\u0421\u0411)<\/i> En cualquier momento, puede suceder algo, la situaci\u00f3n puede cambiar. Se requiere un ajuste constante. <\/p>\n
\u2014 (\u0414\u0421)<\/i> \u00bfTienes un buen chiste sobre este tema?<\/p>\n
\u2014 (\u0421\u0411)<\/i> S\u00ed. Un cirujano card\u00edaco llega a un centro automotriz, y el mec\u00e1nico le dice: 'Mira, hacemos lo mismo, solo que t\u00fa operas el coraz\u00f3n de una persona y yo opero el coraz\u00f3n de un autom\u00f3vil. T\u00fa recibes 10,000$ por una operaci\u00f3n, mientras que yo solo 100 rublos por un servicio.'<\/p>\n
El cirujano pregunta: '\u00bfQuieres tambi\u00e9n ganar 10 mil por reparaci\u00f3n?' El mec\u00e1nico dice que por supuesto. El cirujano se sienta en el auto, lo enciende y dice: 'Hazlo.'<\/p>\n
Igual que nosotros. En desarrollo, puedes tomar una tarea y traer el resultado despu\u00e9s de dos semanas. Luego, todo se puede corregir, porque m\u00e1s o menos tres d\u00edas no influyen en nada. <\/p>\n
En nuestro caso, cada alerta perdida o decisi\u00f3n incorrecta sobre una alerta puede convertirse en un problema muy grande. Para evitar esto, necesitamos una comunicaci\u00f3n estrecha, r\u00e1pida y constante.<\/p>\n
\n\u00bfEs dif\u00edcil pasar al trabajo remoto?<\/h2>\n \nEs dif\u00edcil gestionar personas de forma remota. Pero esto es dif\u00edcil mientras est\u00e9s en una oficina y ellos en otra, ya que hay una falta de claridad. Est\u00e1s en Mosc\u00fa y te parece que los chicos de Nizhni Novgorod trabajan mal, ineficazmente. En Mosc\u00fa ves el esfuerzo de la gente a tu alrededor, pero no ves el esfuerzo de los remotos. Solo aceptas el resultado. <\/p>\n
En la oficina, muchas comunicaciones se dan de manera informal: alguien le dice algo a otro en el camino a la cocina. Las personas en otra oficina no ven eso, no lo sienten, y se pierde el contexto.<\/p>\n
Para cuando ya est\u00e1bamos listos para renunciar a la oficina, todas las comunicaciones (incluso entre empleados en el mismo lugar) se realizaban a trav\u00e9s de Google Meet. Y cuando organizamos toda la comunicaci\u00f3n de forma remota, funcion\u00f3 al 100%, se eliminaron todas las barreras de malentendidos.<\/p>\n
Es complicado organizarlo todo, pero si se hace correctamente, funciona y no causa ning\u00fan inconveniente.<\/p><\/blockquote>\n
\u00bfC\u00f3mo gestionan sus finanzas los equipos por s\u00ed mismos?<\/h2>\n \n\u2014 El trabajo remoto es un tema controvertido. A veces, las empresas temen dejar que las personas trabajen desde casa porque piensan que perder\u00e1n el control sobre ellas. Pero aquellos que lo permiten tambi\u00e9n dicen que hay que trabajar de una manera completamente diferente.<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Hemos resuelto este problema al estar dispuestos a compartir el dinero con los equipos. Toda nuestra econom\u00eda y sistema de motivaci\u00f3n est\u00e1n construidos casi como una franquicia. Los salarios son bastante altos, adem\u00e1s dejamos a los chicos un margen de dinero.<\/p>\n
El equipo se encarga de un conjunto de proyectos. Saben cu\u00e1nto est\u00e1 generando cada uno de estos proyectos. Conocen exactamente su parte de ese dinero. Todo el dinero que queda m\u00e1s all\u00e1 de sus salarios se queda en el equipo y se distribuye entre ellos seg\u00fan un sistema determinado. La motivaci\u00f3n es absolutamente directa: si obtuvieron un proyecto adicional por 200 mil, se a\u00f1ade un extra a su salario. Si cometen un error, deben compensar al cliente.<\/p>\n
\u2014 (\u0421\u0411)<\/i> Si comienzas a fallar en tu trabajo, eso se siente de inmediato. Te quitas la oportunidad de obtener ingresos adicionales. Y nuestra sistema resuelve completamente el problema del control. Cada persona hace su propio plan diario, y las reuniones diarias son suficientes para entender qui\u00e9n est\u00e1 haciendo qu\u00e9.<\/p>\n
\u2014 (\u0414\u0421)<\/i> En tiempos de conflicto, los compa\u00f1eros de trincheras no se mienten entre s\u00ed. <\/p>\n
\u2014 Entonces, \u00bftienen salarios abiertos? \u00bfTodos saben cu\u00e1nto gana cada uno? <\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Cerramos los salarios hace alg\u00fan tiempo. Hay diferencias regionales. A pesar de que buscamos pagar salarios de Mosc\u00fa en otras regiones, siempre hay cierta disonancia.<\/p>\n
\u2014 (\u0421\u0411)<\/i> Ahora todos saben cu\u00e1nto dinero tiene el equipo en total. Pueden ver qu\u00e9 parte de los bonos reciben. <\/p>\n
\u2014 (\u0414\u0421)<\/i> El l\u00edder del equipo de cada grupo decide cu\u00e1nto ganar\u00e1n sus chicos y c\u00f3mo se distribuir\u00e1n los bonos. Nos involucramos en esta cuesti\u00f3n \u00fanicamente para dar consejos; la decisi\u00f3n siempre queda en manos del l\u00edder del equipo.<\/p>\nPor qu\u00e9 la gente teme a las ofertas laborales<\/h2>\n
\nCelebraci\u00f3n del d\u00e9cimo aniversario de la empresa en 2018<\/i><\/p>\n
\u2014 \u00bf70 personas son suficientes para ustedes?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> No. Nuestro plan es contratar al menos 20 ingenieros DevOps en un a\u00f1o. Pero es muy dif\u00edcil. Tenemos un grupo bastante grande de candidatos, todos saben sobre nosotros de alguna manera. Pero aqu\u00ed la historia es como con los clientes. Muchos dicen, 'tenemos miedo de trabajar con ustedes, quiz\u00e1s no lo logremos'. Pero no consideramos que tengamos tareas extremadamente complejas.<\/p>\n
Correspondencia con un candidato<\/i><\/p>\n
\u2014 \u00bfC\u00f3mo deber\u00eda ser uno para poder con esto?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Te\u00f3ricamente, una persona debe estar igualmente desarrollada en el desarrollo y explotaci\u00f3n. En la pr\u00e1ctica, hay muy pocos de esos en el mundo, sin mencionar Rusia. Especialmente aquellos que son seniors en ambos campos. Ni siquiera me considerar\u00eda uno de ellos.<\/p>\n
En nuestras ofertas siempre est\u00e1 bien especificado qu\u00e9 se necesita saber. Trabajamos bastante en ellas y tratamos de ser concretos.<\/p>\n
\u2014 \u00bfPueden las ofertas realmente asustar si se detalla cu\u00e1nto hay que saber?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> No, no, no, no creemos que sea necesario saber mucho. <\/p>\n
\u2014 (\u0421\u0411)<\/i> Nos interesa m\u00e1s el pensamiento, la capacidad de la persona para buscar soluciones.<\/p>\n
\u2014 (\u0414\u0421)<\/i> Buscamos experiencia en Linux, y la evaluamos con tareas bastante simples, pero en gran cantidad. Nuestra prueba es bastante larga, para un candidato promedio, toma 8 horas. Y al final, observamos c\u00f3mo enfrenta los problemas, c\u00f3mo busca en Google y cu\u00e1l es su perspectiva.<\/p>\n
Es muy f\u00e1cil adquirir conocimientos aqu\u00ed, porque hay muchos proyectos diferentes y colegas experimentados que siempre pueden ayudar. Por lo tanto, principalmente buscamos que los chicos sean r\u00e1pidos en comprender y tengan experiencia.<\/p>\n
\u2014 \u00bfAdem\u00e1s de la prueba, c\u00f3mo lo identifican?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Tenemos tres fases. Primero, habla el reclutador, quien pide que cuenten sobre su experiencia. Luego, aquellos que le han gustado al reclutador pasan a una tarea de prueba. Al final, hablan los l\u00edderes del equipo y le dan su opini\u00f3n al reclutador, y si est\u00e1n un\u00e1nimemente de acuerdo en que son buenos, eso es un motivo para hacerles una oferta.<\/p>\n500 mil rublos para contratar al futuro superh\u00e9roe.<\/h2>\n
\n\u2014 (\u0414\u0421)<\/i> Tenemos una relaci\u00f3n muy inusual con las finanzas, compartimos con los equipos y no somos codiciosos. Adem\u00e1s, asignamos a los equipos 500 mil rublos para ampliar su plantilla. Es un subsidio para que puedan encontrar a alguien, ense\u00f1arle todo mientras se integra.<\/p>\n
\u2014 \u00bf500 mil por persona?!<\/b><\/p>\n
Para que el equipo gane mucho dinero, necesitan tomar m\u00e1s proyectos. Para eso, necesitan m\u00e1s personas. Y para contratar m\u00e1s personas, necesitan m\u00e1s dinero. Es un c\u00edrculo vicioso. Para romper este c\u00edrculo, ofrecemos dinero para una nueva persona. Mientras se integra, pueden asumir m\u00e1s proyectos y pagarle su salario con ese dinero. Es decir, es una compensaci\u00f3n hasta que el nuevo aporte beneficios. <\/p>\n
\u2014 \u00bfNo es demasiado para los DevOps? Est\u00e1n ocupados todos los d\u00edas, en condiciones de batalla, y adem\u00e1s deben manejar la gesti\u00f3n financiera.<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Esto lo maneja el l\u00edder de equipo, que ya no es del todo DevOps. Los l\u00edderes de equipo tienden m\u00e1s hacia la asociaci\u00f3n para tener opciones. Por eso creemos que es normal para ellos. Y esto no afecta a los miembros comunes del equipo.<\/p>\n
En t\u00e9rminos simples, saben que si un colega se va, el pr\u00f3ximo mes recibir\u00e1n su salario. Por supuesto, tendr\u00e1n que trabajar m\u00e1s. Y cuando encuentran un reemplazo, devuelven ese dinero. <\/p>\n
Y cuando damos a los l\u00edderes de equipo 500 mil, no quieren contratar a alguien que no resulte. A veces les resulta m\u00e1s f\u00e1cil descartar a 20 personas y elegir a una. Hubo un caso en que hablaron con 100 personas, 30 de ellas pasaron a la prueba t\u00e9cnica, 20 aprobaron, y el l\u00edder de equipo descart\u00f3 a todos menos uno. Es incre\u00edble. Los l\u00edderes de equipo tienen mucho miedo de arriesgar. Discutimos el tema, y todos parec\u00edan entender que era un error. Muchas personas se presentan en las entrevistas de una manera diferente a c\u00f3mo trabajar\u00e1n despu\u00e9s. Por lo tanto, hay que dar una oportunidad y arriesgarse.<\/p>\n
\u2014 \u00bfY los l\u00edderes de equipo no empiezan a abusar? Recibes 500 mil, no contratas por mucho tiempo, y recibes otros 500 mil.<\/b> <\/p>\n
\u2014 (\u0414\u0421)<\/i> Reciben dinero una vez. Decimos: \u00abAhora tienen diez personas, pero necesitamos 11. Hay un plan de ventas, llegar\u00e1n m\u00e1s proyectos y tenemos que estar listos. Aqu\u00ed est\u00e1n 500 mil para la und\u00e9cima posici\u00f3n\u00bb. La segunda vez ya no los recibir\u00e1s. Y si alguien se va, ese es un problema del equipo, ellos lo resuelven dentro de su presupuesto. <\/p>\n
Es como jugar al Monopoly.<\/p>\n
\u2014 (\u0421\u0411)<\/i> Creemos que el l\u00edder de equipo debe estar involucrado en las finanzas. Aqu\u00ed, las personas reciben su salario de los ingresos que generan. Y el grado de gastos en el proyecto es muy importante. Un cliente llega con una infraestructura, y despu\u00e9s de un a\u00f1o, su infraestructura es diez veces mayor. Y si el l\u00edder de equipo no participa en las finanzas, no podr\u00e1 evaluar adecuadamente el costo del mantenimiento.<\/p>\n
\u2014 (\u0414\u0421)<\/i> A veces, el equipo lucha durante meses con los problemas del cliente, se da cuenta de que les pagan 100 mil, y eso no corresponde a lo que est\u00e1 sucediendo. Y aunque duela, deben o aumentar el precio o separarse. Y los chicos toman esas decisiones por s\u00ed mismos. A pesar de que todos trabajan de forma remota. Y creemos que esa es nuestra mayor logro. Tenemos equipos realmente aut\u00f3nomos y motivados.<\/p>\n
\u2014 S\u00ed. Y de ello suena como si tuvieras que ser superhombre para trabajar aqu\u00ed. Necesitas habilidades t\u00e9cnicas, autodisciplina y conocimientos financieros.<\/b><\/p>\n
\u2014 (\u0421\u0411)<\/i> Aqu\u00ed puedes convertirte en superhombre. Pero incluso los l\u00edderes de equipo que saben hacerlo comenzaron como ingenieros normales. A una persona le toma uno o dos a\u00f1os convertirse en un superhombre as\u00ed.<\/p>\n
\u2014 Los l\u00edderes de equipo asociados crecieron a partir de ingenieros comunes. \u00bfPueden ser contratados directamente para una posici\u00f3n as\u00ed?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> No hemos tenido eso antes, todos han crecido a partir de ingenieros. Pero estamos considerando la posibilidad de unirnos a una peque\u00f1a empresa que se convertir\u00eda simplemente en otro de nuestros equipos. Nos gustar\u00eda intentar eso.<\/p>\n
\u2014 \u00bfPuedes contratar a una persona si es un buen ingeniero pero no est\u00e1 lo suficientemente organizada para el nivel de tales equipos?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> No tememos a las personas desorganizadas, tenemos un flujo de tareas. Se identifica muy r\u00e1pidamente si se puede ayudar a la persona a organizarse. Si cada d\u00eda cuenta lo que hace sin realmente hacer nada, le dar\u00e1 verg\u00fcenza. <\/p>\n
Cuando ves que todos est\u00e1n en el mismo barco y remando, te resulta inc\u00f3modo dejar de remar. En tales condiciones, incluso las personas desorganizadas en la vida se vuelven organizadas. Y si no, pues no.<\/p>\n
No toleramos en absoluto la superficialidad \u2014 en las personas, en los asuntos y en nosotros mismos. Y al entrar aqu\u00ed, las personas se desarrollan muy r\u00e1pidamente, tres veces m\u00e1s r\u00e1pido que en cualquier otro lugar. Aqu\u00ed realmente un a\u00f1o de experiencia y habilidades equivale a tres. <\/p>\n
Nos desagradan mucho los mid-level superficiales. Desde nuestro punto de vista, un mid-level es alguien que ya puede hacer mucho. Te lo dir\u00e9 como es: el mercado de DevOps est\u00e1 extremadamente desnaturalizado. Hay mid-levels que se consideran juniors. Hay juniors que se consideran seniors. Cuando una persona llega a nosotros, r\u00e1pidamente entiende su nivel real.<\/p>\n
Esto no significa que no contratemos juniors \u2014 lo hacemos con gusto y seguiremos contratando m\u00e1s. Ya estamos creando un equipo especial de \"Acelerador DevOps\" y asignando proyectos para los que podemos arriesgarnos, donde el cliente est\u00e1 dispuesto a que arriesguemos. Probablemente incluso surgir\u00e1n servicios especiales para esto. Algo como \"Flant-lite\".<\/p>\n
\u2014 \u00bfTe gustar\u00eda convertirte en una gran corporaci\u00f3n?<\/b><\/p>\n
\u2014 (\u0414\u0421)<\/i> Nos gustar\u00eda, pero con una condici\u00f3n. No queremos perder nuestra cultura. Definitivamente creceremos, pero preservar la cultura t\u00e9cnica y laboral es a\u00fan m\u00e1s importante que el desarrollo mismo.<\/p>\n
Solo tenemos una vida, no se puede ganar todo el dinero del mundo, pero queremos vivirla junto a buenas personas. Nos oponemos rotundamente a la burocracia y a la simulaci\u00f3n de trabajo \u00fatil. Nuestras relaciones son completamente horizontales. Se puede comunicar incluso en los t\u00e9rminos m\u00e1s duros lo que uno piensa a la direcci\u00f3n: el contenido es m\u00e1s importante que las formalidades.<\/p>\n
\u2014 (\u0421\u0411)<\/i> Pero para eso hay que tener muy buenos argumentos.<\/p>\n
\u2014 (\u0414\u0421)<\/i> \u00a1Sin duda! Y el trabajo remoto tambi\u00e9n es necesario, porque as\u00ed es como vivimos, as\u00ed es como vemos el mundo. Dima Shurupov vive en Tailandia, yo en Alemania. Sasha Batalov est\u00e1 en Mosc\u00fa, el director de recursos humanos en Tyumen. <\/p>\n
Creemos que, viviendo en este planeta, es importante experimentar la vida y conocerlo. No hay que vivir en circunstancias en las que no te apetezca ir al trabajo. Por lo tanto, queremos que se desee ir a trabajar. Tener conflictos en el trabajo es definitivamente desagradable, as\u00ed que hacemos lo posible para que no haya conflictos. Tenemos debates y discusiones, pero no conflictos. <\/p>\n
\u2014 \u00bfNo creen que hacerse grandes significa no solo ofrecer servicios, sino tambi\u00e9n producir? Que no solo hay que vivir la vida y ver el planeta, sino tambi\u00e9n dejar algo atr\u00e1s?<\/b> <\/p>\n
\u2014 (\u0414\u0421)<\/i> Este es un tema muy sensible para nosotros, porque somos una empresa de servicios. Pero hacemos mucho software y, en esencia, nuestro producto son servicios con una eficiencia completamente diferente. Nunca hemos vendido horas o personas a nadie. Siempre llegaban los clientes y preguntaban: '\u00bfse pueden comprar cien horas?' No, no se puede, no vendemos horas. <\/p>\n
Vendemos resultados. El resultado es que hemos aliviado el dolor, hemos resuelto el problema. Y lo hacemos no como nos dijeron, sino como sabemos. Nuestro producto es nuestra experiencia. Y definitivamente haremos soluciones listas, productos SaaS, hay muchas ideas. Pero no hay apuro. Nos esperan muchas d\u00e9cadas.habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412 \u043c\u0438\u0440\u0435, \u0433\u0434\u0435 \u0442\u043e\u043b\u044c\u043a\u043e \u0441\u0432\u043e\u0439 \u0431\u0438\u0437\u043d\u0435\u0441 \u043c\u043e\u0436\u0435\u0442 \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0442\u0435\u0431\u044f \u043f\u043e-\u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u043c\u0443 \u0431\u043e\u0433\u0430\u0442\u044b\u043c, \u043b\u044e\u0434\u0438 \u0434\u043e \u0441\u0438\u0445 \u043f\u043e\u0440 \u0438\u0434\u0443\u0442 \u0440\u0430\u0431\u043e\u0442\u0430\u0442\u044c \u043f\u043e \u043d\u0430\u0439\u043c\u0443. \u0412\u043e-\u043f\u0435\u0440\u0432\u044b\u0445, \u043d\u0435 \u0432\u0441\u0435 \u0441\u0447\u0430\u0441\u0442\u043b\u0438\u0432\u044b \u0431\u044b\u0442\u044c \u0431\u0438\u0437\u043d\u0435\u0441\u043c\u0435\u043d\u0430\u043c\u0438, \u0430 \u0436\u0438\u0442\u044c \u043d\u0430\u0434\u043e. \u0412\u043e-\u0432\u0442\u043e\u0440\u044b\u0445, \u043d\u0430 \u0440\u0430\u0431\u043e\u0442\u0435 \u0432\u0441\u0435 \u043f\u043e\u043d\u044f\u0442\u043d\u043e \u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e \u2014 \u0442\u044b \u0432\u044b\u043f\u043e\u043b\u043d\u044f\u0435\u0448\u044c \u0441\u0432\u043e\u044e \u0444\u0443\u043d\u043a\u0446\u0438\u044e, \u0430 \u0431\u043e\u043b\u044c\u0448\u0438\u043d\u0441\u0442\u0432\u043e \u0440\u0438\u0441\u043a\u043e\u0432 \u0431\u0435\u0440\u0443\u0442 \u043d\u0430 \u0441\u0435\u0431\u044f \u0434\u0440\u0443\u0433\u0438\u0435. \u041e\u0442\u0441\u044e\u0434\u0430 \u0440\u0430\u0441\u0442\u0443\u0442 \u0441\u0442\u0430\u0440\u044b\u0435 \u0437\u0430\u043c\u0443\u0441\u043e\u043b\u0435\u043d\u043d\u044b\u0435 \u043a\u043e\u043d\u0444\u043b\u0438\u043a\u0442\u044b: \u0432\u043b\u0430\u0434\u0435\u043b\u044c\u0446\u044b \u0445\u043e\u0442\u044f\u0442, \u0447\u0442\u043e\u0431\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-30046","post","type-post","status-publish","format-standard","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"\u00abUna](\"\/wp-content\/uploads\/2019\/03\/0ee82b86e0cbe70d8a1aff2db82c47cd.png\")