Em um mundo onde apenas o seu próprio negócio pode realmente torná-lo rico, as pessoas ainda continuam a trabalhar para outras. Em primeiro lugar, nem todos são felizes em serem empresários, e é preciso viver. Em segundo lugar, no trabalho, tudo é claro e seguro — você desempenha sua função, enquanto a maioria dos riscos é assumida por outros. Daí surgem antigos conflitos: os proprietários querem que os funcionários estejam motivados como se o trabalho fosse o seu próprio negócio; os funcionários querem fazer apenas o que recebem para fazer, e nada mais.
Essas relações clássicas têm variações — opções, percentuais, bônus que lembram um pouco que proprietários e funcionários estão no mesmo barco. Mas há também situações mais atípicas.
A empresa Flant é composta por várias equipes de DevOps que atendem produções terceirizadas completas. Elas surgiram de um grupo de estudantes entusiastas e fãs do Linux, e agora construíram uma estrutura de "negócios dentro de negócios", simplesmente porque é mais confortável e justo. Dima Stolyarov e Sasha Batalov nos contaram como isso funciona.
A Flant entrou na lista dos melhores empregadores de TI de 2018 com 4,68. De acordo com as avaliações da empresa no 'Meu Círculo', os funcionários acreditam que a empresa torna o mundo melhor, e também valorizam a Flant por seus desafios interessantes, boas relações no grupo, tecnologias modernas e a conexão com a alta administração.
Um grupo de estudantes lunixos
Dmitry Stolyarov (diretor técnico) durante sua apresentação
— (Dima Stolyarov) Sempre trabalhamos com Linux e código aberto, mas começamos com um tema bastante engraçado, pelo qual agora nos sentimos um pouco envergonhados. Por algum motivo, achávamos que era necessário implementar o Linux em escritórios no lugar do Windows. O primeiro nome da empresa era TrueOffice — 'escritório verdadeiro'. Depois percebemos que ninguém precisava disso. Isso foi em 2006, eu tinha 19 anos. Somente em 2012-13 veio a compreensão de como fazer negócios e quais tecnologias o mundo precisa.
Alexander Batalov (CEO) no estande da empresa na conferência
— (Sasha Batalov) Além das tecnologias, há uma enorme camada de marketing, vendas e economia, que ninguém nunca nos ensinou, exceto em aulas da universidade, mas eu não sei quão aplicáveis e úteis elas realmente são.
No início, parecia que tudo isso não era necessário, mas depois tivemos que aprender na prática, ler livros, às vezes já depois de termos enfrentado dificuldades. No geral, seguimos um caminho longo e árduo, tentando muitas coisas erradas.
— (DS) Mas gradualmente, à medida que nossa qualificação crescia, fomos nos especializando cada vez mais em Linux, e agora nos dedicamos apenas a high-load, projetos web de alta demanda. E quando o Kubernetes surgiu, rapidamente entendemos que era a fundação que tanto nos faltava.
— Por que havia tanto interesse em Linux? Ideológico ou tecnológico?
— (DS) A empresa tem dois fundadores — Dima Shurupov e eu. Dima tinha um interesse maior por open source. E eu gostava especificamente do Linux, da maneira como tudo funciona tecnologicamente. Assim, conseguimos uma combinação: Dima gosta da ideologia, e eu da tecnologia. Eu amo open source como ideia, mas sempre valorizei mais o lado tecnológico.
Einstein disse: "Devemos fazer as coisas tão simples quanto possível, mas não mais simples." É assim que o Linux é tão simples, confiável e transparente, que eu realmente aprecio. Todos nós gostávamos disso, e nos tornamos de um grupo de estudantes em uma grande empresa. Agora somos 70. Para TI, para serviços especializados — já é um número considerável.
— Como era a vida na época do grupo de estudantes?
— (DS) Bem, como costuma ser com estudantes — divertido e animado.
— (SB) Uma enorme quantidade de altruísmo, o desejo de conquistar a internet, de alcançar novos patamares tecnológicos. Envolvíamos em tarefas muito difíceis — muitas vezes nos engajávamos em projetos sérios (mas muito interessantes!) de integração de sistemas, fazendo isso por migalhas. Tentávamos criar nossos próprios frameworks, absorvíamos todas as tecnologias que conhecíamos e imediatamente buscávamos aplicá-las.
— E comercialmente, tudo funcionou?
— (DS) Sim, mas nas fases iniciais, não precisávamos de muito. Naquela época, para mim, 40 mil rublos era uma renda absolutamente normal, eu me sentia bem com isso.
— (SB) Eu achava que por mil dólares poderia fazer qualquer site que imaginasse.
— (DS) Em 2013, não tínhamos dinheiro para contratar livremente em Moscovo. Todos os conhecidos que poderíamos contratar, já tinham sido contratados. Decidimos abrir um escritório em Nizhny Novgorod. Fomos para lá, abrimos, começamos a contratar. Depois percebemos que viver com dois escritórios era difícil e decidimos viver sem escritórios.
Claro, batemos a cabeça muitas vezes. Só em 2016, para meu constrangimento, li Remote. Eu chorei e ri, porque percorremos o mesmo caminho. Cada parágrafo se cruzava com a minha experiência pessoal.
— (SB) Em cada parágrafo havia nossas cicatrizes.
O que a Flant faz
Prestamos serviços para produção de alta demanda. Isso é diferente da terceirização comum, porque convivemos com os clientes por muito tempo e interagimos muito de perto; as pessoas confiam em nós uma de suas coisas mais importantes. A forma como trabalhamos afeta muito o negócio deles.Para estabelecer uma operação de produção de qualidade, são necessários de 15 a 20 devops, especialistas em bancos de dados, em Kubernetes, suporte técnico e assim por diante. E se a empresa é pequena, com apenas duas ou três dezenas de desenvolvedores, isso é impossível. E aqui entramos nós, para salvar. Por cerca de 150 mil.
No passado, nossa missão era criar uma empresa onde nós mesmos nos sentíssemos confortáveis para trabalhar, por mais bobo que isso pudesse parecer. Agora que isso foi alcançado, a missão é tornar as tecnologias de nível Google e Facebook acessíveis para pequenas empresas e startups em estágios iniciais.
As pessoas podem se concentrar em seu produto, em vez de superar problemas que não precisam ser superados.
Muitos dos caras que vêm até nós ficam surpresos - quanta variedade há, como as cargas estão por toda parte. Temos mais de 50 projetos em produção, mais de 70 clusters Kubernetes. Sempre é possível complicar as coisas. Abri um editor, desenhei uma arquitetura de microserviços, fiz uma lista de 200 tecnologias - e vamos lá. Mas isso sempre traz problemas e consequências.
A essência é garantir, por um lado, a máxima estabilidade, confiabilidade e simplicidade, e, por outro, um alto nível de inovação. E nós nos orgulhamos de saber fazer isso. Fazemos em todo lugar e em grande escala, como uma IKEA condicional.
Quem precisa de devops outsourcing
— Me parece que grandes empresas preferem manter devops internamente.
— (SB) É claro que grandes players, como Avito ou Badoo, podem montar uma equipe de devops. Empresas menores com grandes investimentos também podem - mas podem montar, não é certo que terão força suficiente para lidar.
Acreditamos que mesmo as grandes empresas se beneficiam ao recorrer a especialistas que realmente conhecem o assunto. Para pequenas empresas cujo negócio depende de soluções web, é essencial buscar pessoas experientes. Qualquer falha em um sistema crítico pode resultar em perda de dinheiro.
— (DS) Sabemos que as pessoas na Rússia têm receio de terceirização — devido a experiências negativas e por outros motivos pessoais. No entanto, nossos clientes não nos abandonam. Em dez anos, só saíram por duas razões: ou cresceram (por exemplo, foram adquiridos e tudo foi reestruturado) ou se fecharam, porque a ideia não funcionou.
— E quem é que mais frequentemente procura vocês — pequenas ou grandes empresas?
— (DS) Atualmente, temos uma distribuição igual. Mas as pequenas empresas temem nos procurar, acham que somos...
— (SB)... grandes, complicados, inalcançáveis e que estamos nas nuvens.
— (DS) Sim, você passa pela loja de um Maybach e não entra, não pergunta o preço, porque não pode ser que um Maybach custe 500 mil rublos.
— Claro que não pode.
— (SB) Mas assim que aparece no serviço de compartilhamento de carros, você pode se permitir dar uma volta nele.
— (DS) Sim, nós não somos um Maybach — somos Ikea. Conosco, o que oferecemos é simples, confiável e acessível. De modo geral, o número de empresas que nos procuram entre as TOP-50 é igual ao das pequenas empresas. Mas nossa principal expectativa é no mercado de pequenas empresas, com as quais trabalhamos principalmente, enquanto tentamos evitar parcerias com as grandes.
— Por quê?
— (DS) Há muita burocracia.
— (SB) Em uma grande empresa, há muitos níveis onde a responsabilidade é distribuída, o feedback é demorado e frequentemente as pessoas começam a complicar processos: "Vamos avaliar, vamos escrever uma estratégia, um plano para um ano à frente, vamos fazer de uma forma que pareça melhor para a cultura empresarial, pois assim tem sido nossa prática". E então eles tornam problemas simples em algo complexo, onde 80% do resultado poderia ser obtido já amanhã, seguindo um caminho longo, onde não se sabe nem se isso realmente funcionará.
Como resultado, em vez de implementar práticas consolidadas, reinventamos a roda, e o custo da solução tecnológica se torna incomparavelmente maior. Além disso, a qualidade não é garantido que melhore.
Custo da terceirização
Temos muitos projetos no GitHub, e todos nós contribuímos ativamente para o mundo open source. Não apenas para os nossos, mas também para os de outros. Fazemos questão de compartilhar as ferramentas que usamos todos os dias. Acreditamos que isso é nossa obrigação e é um prazer fazê-lo.Todos na empresa contribuem de alguma forma — seja através de feedback, documentação ou código. Acreditamos que essa é nossa forma de retribuir ao rico mundo das utilidades open source que utilizamos. E considero que fazemos isso de forma digna.
Chamamos isso de condensação de experiência. Inicialmente, uma pessoa aprendeu algo, compartilhou com os colegas, e a experiência se tornou folclore. Depois, registramos a documentação e, em seguida, transformamos isso em utilidades e esquecemos a existência, pois já não pensamos — tudo é contabilizado automaticamente.
A popularidade das tecnologias e a toxicidade dos desenvolvedores
— Por que escolheram o Ubuntu? O que mais foi considerado antes de tomarem essa decisão?
— (DS) Fomos um grupo de estudantes que gostava de Linux. Usamos o Gentoo por um longo tempo — é uma distribuição baseada em fonte e precisa ser compilada do zero a cada vez. Quando adquirimos algumas centenas de servidores, as atualizações levavam meses. Claro que, a princípio, automatizamos e otimizamos tudo, mas no final percebemos que precisávamos mudar. Sabendo das vantagens e desvantagens de diferentes soluções, escolhemos simplesmente a mais popular. Naquela época, foi instintivo — se é a mais popular, deverá evoluir melhor, e todas as falhas serão corrigidas cedo ou tarde.
Havia um banco de dados chamado Resync DB. Eles competiam com o MongoDB e surgiram mais ou menos ao mesmo tempo. Por muito tempo, o Resync era tecnologicamente melhor.
Quando os usuários chegavam, eles tentavam resolver problemas internos do sistema, enquanto no MongoDB isso era feito com muito menos frequência. No entanto, podiam, por exemplo, implementar ifs para serem melhores em testes sintéticos. Por isso, a popularidade do MongoDB crescia. Em casos mais simples, eles se destacavam, mas internamente eram fracos. Já o Resync DB era bom internamente, mas não ganhava popularidade.
No final, tudo melhorou para o MongoDB, enquanto ninguém lembra do Resync DB. A empresa faliu. A história do Ubuntu é um pouco assim. Nesse sistema, há muito foco, e por isso decidimos usá-lo.
— O que vocês acham das últimas mudanças políticas, CoC e tudo mais?
— (DS) Bem… não há nada negativo, tudo está normal, tudo é claro. Eu mesmo sofro por, às vezes, magoar as pessoas. Para mim, por exemplo, uma coisa parece óbvia, e isso me deixa extremamente bravo por as pessoas não entenderem. Eu fico irritado, e isso gera um sentimento negativo (mas estou trabalhando nisso).
Linus é muito inteligente, afinal, ele trabalha com isso há 30 anos. É claro que ele é um cara contundente, não se contém nas palavras. A polidez dele sofre, e a comunidade trabalha nisso. Ele mesmo entende tudo e reconhece.
— Mas, pelo que entendi da reação nas discussões, muitas pessoas apoiam a ideia de falar diretamente e de forma firme, e se alguém não gosta disso — que se danem, não são feitos de açúcar.
— (DS) Não, não é assim. Eu, como pessoa que sofre pela falta de polidez, entendo que isso é muito ruim. Isso estraga a comunidade. Tem pessoas que não ligam, mas a maioria das pessoas ainda considera importante ter conforto emocional.
Aqui no código há um erro bobo. Pode-se dizer: 'Pessoal, é ruim que nós deixamos passar coisas tão simples, precisamos corrigir isso'. Mas pode-se também dizer: 'Que idiota fez isso?!'. Uma frase. Aquela pessoa que cometeu esse erro pode até ser mais inteligente e experiente que você, mas simplesmente não estava bem quando cometeu o erro — vai saber o que aconteceu com ela. E para ela isso será uma ofensa direta. Para que isso?
É preciso dizer as coisas diretamente, mas não se deve dizer 'Que idiota escreveu isso'. Também não há sentido em esconder e confeitar, mas não se deve magoar as pessoas.
Por que os DevOps precisam se reunir todos os dias?
— (DS) Atualmente, temos um pequeno escritório onde ficam os documentos e um gerente de escritório que cuida desses documentos.
Na empresa, há 70 pessoas. 20 delas são da equipe de OPS. 30 pessoas são três equipes de DevOps, aproximadamente 10 em cada. As restantes 20 são desenvolvedores e vendas. Temos 8 desenvolvedores, e o departamento de pesquisa e desenvolvimento — 4 pessoas. Pessoas não técnicas na empresa são 5-6.
As principais receitas vêm das três equipes de DevOps. Os processos são os mesmos em toda parte — a cada dia há uma longa reunião de uma hora e meia. Lá, discutem-se todas as questões técnicas, e os caras decidem o que fazer a seguir. E como todos estão remotos – é uma oportunidade de se comunicar normalmente.
— É realmente necessário todo dia?
— (DS) Sim.
— Todos concordam com isso?
— (DS) Sim, todos estão de acordo, todos se sentem confortáveis. Mas em alguns dias a reunião pode durar 30 minutos. Apesar da comunicação intensa no Slack, ainda queremos nos sincronizar bem, entender o que aconteceu ontem. Queremos nos entender, e não apenas clicar em tarefas. Este é um aspecto culturalmente importante.
— (SB) A qualquer momento algo pode acontecer, a situação pode mudar. É necessária uma constante correção.
— (DS) Você tem uma boa piada sobre isso.
— (SB) Sim. Um cirurgião cardíaco chega a uma oficina mecânica e o mecânico diz: "Ei, estamos fazendo a mesma coisa, você opera o coração humano e eu, o coração do carro. Você recebe 10.000 dólares pela cirurgia, e eu recebo 100 rublos pela manutenção."
O cirurgião pergunta: "Você também quer ganhar 10.000 pela reparação?" O mecânico diz - claro. O cirurgião se senta no carro, liga e diz - "faça a sua parte."
Assim como nós. No desenvolvimento, você pode pegar uma tarefa e trazer o resultado em duas semanas. Depois, tudo pode ser ajustado, porque mais ou menos três dias não afetam em nada.
E no nosso caso, cada alerta perdido ou decisão errada sobre um alerta pode se tornar um grande problema. Para que isso não aconteça, uma comunicação próxima, rápida e constante é necessária.
É difícil fazer a transição para o trabalho remoto.
É difícil gerenciar pessoas à distância. Mas isso é difícil enquanto você está em um escritório e eles estão em outro, e há uma certa falta de clareza. Você está em Moscou e sente que o pessoal de Nizhny não está trabalhando bem, de forma eficaz. Em Moscou, você vê o esforço das pessoas ao seu redor, mas não vê o esforço dos remotos. Você só avalia o resultado.
No escritório, há muita comunicação acontecendo de maneira informal - alguém disse algo a alguém no caminho para a cozinha. As pessoas em um escritório diferente não veem isso, não sentem e o contexto se perde.
No momento em que estávamos prontos para abrir mão do escritório, toda a comunicação (mesmo entre funcionários no mesmo espaço) estava ocorrendo através do Google Meet. E quando organizamos toda a comunicação remotamente, funcionou a 100%, todas as barreiras de incompreensão foram superadas.
Configurar tudo é difícil, mas se tudo for feito corretamente - isso funciona e não causa nenhum desconforto.
Como as equipes gerenciam seu próprio dinheiro.
— Trabalho Remoto — uma questão controversa. Às vezes, as empresas temem liberar as pessoas para casa, pois acreditam que perderão o controle sobre elas. Mas aqueles que permitem dizem também que o trabalho precisa ser feito de maneira completamente diferente.
— (DS) Resolvemos esse problema ao estarmos dispostos a compartilhar dinheiro com as equipes. Nossa economia e sistema de motivação estão estruturados quase como uma franquia. Os salários são bastante altos, além de deixarmos uma parte do dinheiro livre para a equipe.
A equipe gerencia um conjunto de projetos. Eles sabem quanto cada um desses projetos gera de receita. Eles sabem exatamente qual é a sua parte desse dinheiro. Todo o dinheiro que sobra além dos salários fica com a equipe e é compartilhado entre eles de acordo com um sistema definido. A motivação é absolutamente direta — trouxeram um projeto de mais 200 mil, aumentaram o salário em mais dez. Cometeram um erro — precisam compensar o cliente.
— (SB) Se você começa a decepcionar a equipe, isso se torna imediatamente perceptível. Você se priva da oportunidade de obter uma renda adicional. E o problema do controle é totalmente resolvido pelo nosso sistema. A pessoa faz seu plano para cada dia, e as reuniões diárias são suficientes para saber o que cada um está fazendo.
— (DS) Em tempos de combate, não se mente aos companheiros de trincheira.
— Então vocês têm salários abertos? Todos sabem quanto cada um recebe?
— (DS) Fechamos os salários há algum tempo. Existe uma diferença regional. Apesar de procurarmos pagar salários de Moscovo em outras regiões, ainda assim há algum descompasso.
— (SB) Atualmente, todos sabem quanto dinheiro a equipe possui no total. Eles veem qual a sua parte nos bônus que recebem.
— (DS) O líder de cada equipe decide quanto seus membros receberão e como serão distribuídos os bônus. Nós nos envolvemos nesse processo apenas com conselhos, a decisão sempre permanece com o líder da equipe.
Por que as pessoas têm medo de vagas de emprego?
Celebração do 10º aniversário da empresa em 2018.
— 70 pessoas são suficientes para vocês?
— (DS) Não. Temos um plano de contratar pelo menos 20 engenheiros DevOps ao longo do ano. Mas isso é muito difícil. Temos um número considerável de candidatos, todos sabem sobre nós de alguma forma. Mas aqui a história é parecida com a dos clientes. Muitas pessoas dizem: "tememos trabalhar com vocês, talvez não consigamos acompanhar". Porém, não acreditamos que temos coisas super complexas aqui.
Correspondência com um candidato.
— Como você deve ser para lidar com isso?
— (DS) Teoricamente, um ser humano deve ser igualmente desenvolvido em desenvolvimento e operação. Na prática, esses indivíduos são raros no mundo, sem mencionar a Rússia. Especialmente aqueles que são seniores em ambas as áreas. Eu não me consideraria um deles.
Em nossas ofertas de emprego, sempre está bem claro o que é necessário saber. Trabalhamos muito para escrever de forma objetiva.
— As vagas podem realmente afastar candidatos se detalham tudo que precisam saber?
— (DS) Não, não, não, não achamos que seja necessário saber muitas coisas.
— (SB) Estamos mais interessados no raciocínio, na capacidade da pessoa de buscar soluções.
— (DS) Estamos interessados na experiência com Linux, e verificamos isso através de tarefas simples — apenas com uma grande quantidade delas. Nosso teste é bastante longo, levando em média 8 horas para candidatos. E ao final, analisamos como a pessoa lidou com os problemas, como pesquisa, qual é seu conhecimento geral.
O conhecimento pode ser adquirido rapidamente, pois temos muitos projetos diferentes e colegas experientes que sempre estão dispostos a ajudar. Portanto, focamos em encontrar pessoas que raciocinem rapidamente e tenham experiência.
— Além do teste, vocês identificam isso de alguma outra forma?
— (DS) Temos três fases. Primeiro, um recrutador conversa e pede para a pessoa contar sobre sua experiência. Em seguida, os que se destacam na conversa inicial passam por uma tarefa de teste. Por fim, os líderes de equipe discutem suas opiniões e, se concordarem que são bons, isso é um sinal para fazer uma oferta.
500 mil rublos para contratar o futuro super-homem
— (DS) Temos uma abordagem muito atípica em relação a finanças, compartilhamos com as equipes e não somos mesquinhos. E também alocamos para a equipe 500 mil rublos para expandir a equipe. Ou seja, esse é um subsídio para que eles possam encontrar alguém e ensiná-lo enquanto ele se integra.
— 500 mil por pessoa?!
Para que a equipe ganhe muito dinheiro, eles precisam assumir mais projetos. Para isso, precisam de mais pessoas. E para contratar mais pessoas — precisam de mais dinheiro. É um ciclo vicioso. Para quebrar esse ciclo, fornecemos dinheiro para contratar uma nova pessoa. Enquanto ele se adapta, eles podem pegar mais projetos e pagá-lo com aquele dinheiro. Ou seja, é uma compensação até que o novato comece a gerar receita.
— Isso não é demais para DevOps? Eles estão sobrecarregados todos os dias, em condições de batalha, e ainda têm que lidar com a gestão financeira.
— (DS) Isso é responsabilidade do time lead, que já não é exatamente um devops. Os leads tendem mais ao partnership para ter opções. Portanto, consideramos que isso é normal para eles. Já os membros comuns da equipe não estão envolvidos nisso.
De forma simplificada, eles sabem que se um colega se afastar, no mês seguinte eles recebem o salário dele. Claro, terão que trabalhar mais. E quando encontram uma substituição, devolvem esse dinheiro.
E quando damos aos leads 500 mil, eles não querem contratar alguém que não tenha grande potencial. Às vezes, é mais fácil para eles rejeitar 20 candidatos e escolher um. Já aconteceu de conversar com 100 pessoas, 30 foram para a prova técnica, 20 passaram, e o time lead rejeitou todos, exceto um. É intenso. Os leads têm muito medo de arriscar. Discutimos isso e todos pareceram entender que é um erro. Muitas pessoas se apresentam de forma diferente na entrevista do que realmente trabalham depois. Portanto, é necessário dar uma chance e correr o risco.
— Mas os leads não começam a abusar? Você recebe 500 mil, demora muito a contratar, recebe mais 500 mil.
— (DS) Eles recebem a verba uma única vez. Dizemos: "Vocês têm dez pessoas agora, mas precisam de 11. Há um plano de vendas, mais projetos estão por vir e precisamos que estejam prontos. Aqui estão 500 mil para a décima primeira posição". Na segunda vez, não se consegue mais isso. E se alguém sai, é um problema da equipe, que resolve isso dentro do seu orçamento.
É como jogar Monopólio.
— (SB) Acreditamos que o lead deve estar envolvido nas finanças. Aqui as pessoas recebem seus salários do dinheiro que geram. O nível de despesas do projeto é muito importante. O cliente chega com uma infraestrutura, e um ano depois, sua infraestrutura é dez vezes maior. E se o lead não participa das finanças, não consegue avaliar adequadamente o custo da manutenção.
— (DS) Às vezes, a equipe passa meses lutando com os problemas de um cliente, percebe que está recebendo um valor simbólico por isso, e isso não condiz com o que está acontecendo. E, por mais difícil que seja, precisam ou aumentar o preço ou se separar. E eles tomam essas decisões sozinhos, mesmo trabalhando remotamente. E consideramos isso uma grande conquista. Temos equipes verdadeiramente autônomas e motivadas.
— Sim. E isso faz parecer que é preciso ser um super-homem para trabalhar aqui. Tanto habilidades técnicas, quanto autocontrole e alfabetização financeira.
— (SB) Aqui, você pode se tornar um super-homem. Mas mesmo os líderes de equipe que conseguem isso vieram como engenheiros comuns. Uma pessoa leva um ou dois anos para se transformar em um desses super-homens.
— Os líderes de equipe parceiros se originaram de engenheiros comuns. Eles podem ser contratados para essa posição diretamente?
— (DS) Nunca tivemos algo assim, todos vieram de engenheiros. Mas estamos considerando a possibilidade de nos unir a uma pequena empresa que se tornaria apenas mais uma de nossas equipes. Gostaríamos de tentar isso.
— Você pode contratar uma pessoa se ela for um bom engenheiro, mas não é suficientemente organizada para o nível dessas equipes?
— (DS) Não temos medo de pessoas desorganizadas, pois temos um fluxo constante de tarefas. É rapidamente identificado se conseguimos ajudar uma pessoa a se organizar. Se ela disser todos os dias o que fez, sem realmente fazer nada, ficará envergonhada.
Quando você vê que todos estão na mesma canoa remando, é desconfortável parar de remar. Nessas condições, até mesmo pessoas desorganizadas se tornam organizadas. E se não, então não.
Nós não toleramos superficialidade — nas pessoas, nos negócios e em nós mesmos. Ao entrar aqui, as pessoas se desenvolvem muito rapidamente, em três vezes mais rápido do que em qualquer outro lugar. Aqui, um ano vale por três em experiência e habilidades.
Nós realmente não gostamos de profissionais medianos superficiais. Na nossa visão, um médio é alguém que já pode fazer muitas coisas. Para ser honesto — o mercado DevOps está extremamente confuso. Existem médios que se consideram juniores. Há juniores que se acham seniores. Ao chegar aqui, uma pessoa rapidamente entende seu verdadeiro nível.
Isso não significa que não aceitamos juniores — aceitamos com prazer e vamos aceitar ainda mais. Já estamos criando uma equipe especial chamada 'Acelerador DevOps' e designando projetos que podemos arriscar, onde o cliente está disposto a correr riscos. Provavelmente, até mesmo um serviço específico surgirá para isso. Algo como 'Flant-light'.
— Você gostaria de se tornar uma grande corporação?
— (DS) Nós gostaríamos, mas com uma ressalva. Não queremos perder nossa cultura. Com certeza vamos crescer, mas preservar a cultura técnica e de trabalho é ainda mais importante do que o próprio desenvolvimento.
A vida é uma só, não dá para ganhar todo o dinheiro do mundo, mas queremos vivê-la ao lado de boas pessoas. Rejeitamos categoricamente a burocracia e a simulação de trabalho útil. Temos relações absolutamente horizontais. É possível expressar suas opiniões de forma bem direta à liderança: o conteúdo é mais importante que as formalidades.
— (SB) Mas para isso é necessário ter argumentos muito bons.
— (DS) Certamente! O trabalho remoto também é necessário, porque é assim que vivemos, assim que vemos o mundo. Dima Shuropov mora na Tailândia, eu na Alemanha. Sasha Batalov está em Moscovo, e o diretor de RH em Tyumen.
Acreditamos que, vivendo neste planeta, queremos experimentar a vida de verdade. Viver em condições em que você não quer ir trabalhar não é bom. Por isso, queremos que as pessoas tenham vontade de vir trabalhar. Conflitar no trabalho é definitivamente desagradável, então fazemos o possível para que não haja conflitos. Temos discussões e debates, mas não conflitos.
— Você não acha que crescer significa não apenas prestar serviços, mas também produzir? É preciso não apenas viver a vida e ver o planeta, mas também deixar algo atrás?
— (DS) Esse é um tema muito delicado para nós, porque somos uma empresa de serviços. Mas fazemos muitos softwares e, de certa forma, nosso produto são serviços com uma eficácia completamente diferente. Nunca vendemos horas ou pessoas. Sempre chegavam clientes e perguntavam - 'é possível comprar cem horas'? Não, não é possível, não vendemos horas.
Vendemos resultados. O resultado é que aliviamos a dor, resolvemos um problema. E resolvemos não da forma que nos disseram, mas da maneira que sabemos. Nosso produto é nossa experiência. E definitivamente faremos soluções prontas, produtos SaaS; temos muitas ideias. Mas não há pressa. Temos muitas décadas à frente.
Fonte: habr.com
