Marco zero

O início da nossa aventura começa passando por pontos mais relacionados a soft skills, que são mais valorizados, do que as technical skills na Vizir.

O que mais buscamos no nosso processo seletivo

Se você está na Vizir, provavelmente passou pelo nosso processo seletivo (sim, há alguns Vizires que não passaram, por já termos trabalhado antes). Nosso processo não é o mais rígido, mas há dois pontos base que buscamos, ao contratar:

  • Ser uma pessoa legal: mais subjetivo que isso, impossível. Mas tem a ver com as soft skills que comentamos, que abrange o trabalho em equipe, postura, gostos, e principalmente se a pessoa compartilha os mesmos valores que temos na Vizir;

  • Saber programar: na maioria das vagas buscamos muito mais alguém que tenha uma boa fundação, do que um especialista em tecnologia X. Isso deve-se a natureza dos nossos projetos e desafios, onde a especialidade muda com frequência, e ter uma base sólida é muito mais importante, e isso em termos mais objetivos passar por: modelagem de Software, como usar os tipos corretos, abstração, separação de responsabilidade; saber criar testes unitários e que cobrem cenários de negócios.

Nossos princípios

  • Feito é melhor que perfeito

    • desenvolver software é um trabalho criativo, portanto, como todo trabalho criativo se não colocarmos uma restrição de tempo, pode tomar o tempo "infinito". Diante da restrição do tempo, este princípio precisa ser adotado a cada tarefa, por isso, é importante trabalharmos em sprints de X semana (geralmente 1 ou 2 semanas), estimarmos as tarefas, e a cada execução colocarmos metas "pessoais", pois essas restrições irão nos ajudar a chegar no "feito é melhor que perfeito", e ao fim do nosso trabalho ter ele entregue, rodando em produção.

  • Deixe o código melhor do que você encontrou

    • é uma das formas de aplicar o kaizen, que significa "melhoria"/"mudar para o melhor" em japonês. E também uma forma de não deixar janelas quebradas.

  • Quando estiver travado, busque ajuda

    • desenvolver é uma tarefa complexa, portanto é comum ficarmos travados em certas tarefas, principalmente quando é a primeira vez que estamos realizando. Por isso, pedir ajudar é a melhor forma de superar esse "travamento", que tem impacto tanto na auto-estima, como no andamento do projeto. Como recomendação, ao ficar mais de 2 horas travado, é bom pedir ajudar seja para o(a) Vizir do lado, ou no Slack da Vizir.

  • Compartilhe o seu conhecimento

    • além de ser um ótimo exercício para solidificar conhecimento, é fundamental para termos uma equipe produtiva e estarmos sempre aprendendo algo novo.

  • Entenda o contexto

    • Mais do que codificar, precisamos estar sempre pensando e utilizando o nosso conhecimento, de acordo com a realidade do cliente/projeto. Isso nos ajuda tanto ao arquitetar uma solução, como ao resolver problemas.

Boas práticas

Boas práticas pessoais

  • Tenha sempre o mindset de resolver problemas. Na nossa área é comum termos pessoas que gostam de problematizar e complicar, por isso o simples ato de focar em resolver o problema, é um baita diferencial, tanto que é uma das práticas que mais nos diferenciou perante outras consultorias, e times

  • Aprender, aprender e aprender. Use a nossa biblioteca, cursos, e o principal, aproveite o seu projeto atual para se aprofundar mais ainda na stack e em práticas que deseja aprender/aperfeiçoar, pois o melhor momento de aprender é o agora

  • Não se limite. Mais um da série "top bullets subjetivos". Mas deixando a brincadeira de lado, o importante é não achar que algo é impossível pra ti, ou muito difícil, afinal se você for pensar, o simples fato de você trabalhar com TI, não é tão simples assim, pois a cada dia o leque de skills e conhecimentos aumenta.

Boas práticas de equipe

  • Esteja sempre aberto a críticas e sugestões, o código que você cria, é do coletivo;

  • Somos no geral péssimos piadistas, porém o bom humor é uma ótima ferramenta para criar um ambiente saudável e prazeroso de se trabalhar (ahh q delícia cara!);

  • Saiba respeitar as diferenças. Na Vizir a diferença sempre foi bem-vinda, e está mais que provado em vários ramos, que a diversidade traz inovação e bons resultados as empresas e pessoas;

  • Seja um guardião da saúde e eficiência da equipe, seja durante as retrospectivas ou no próprio dia-a-dia. Lembre-se que o entregue é sempre melhor que o perfeito, porém, o entregue de hoje, é bom ser melhor do que o de ontem;

  • Aceite falhas, programar é um esforço grande cognitivo e assim, fadado ao erro, então use eles para melhorar, e não para te deixar pra baixo.

Boas práticas com o cliente

  • Impor mais o nosso jeito e o que acreditamos. No geral na Vizir somos péssimos em falar "não", por isso que esse tópico aqui é importante. Já que muitas vezes fazemos algo, de uma forma que o cliente quer, mas não é a que acreditamos, ou pior, já fizemos de uma forma melhor, mas pra não discordar ou criar um "mal-estar". Temos que lembrar que se o cliente nos contratou, é justamente porquê conhecemos mais do que ele, principalmente no que tange o desenvolvimento de software. E aqui cabe alguns exemplos, pra dar uma noção de momentos que erramos ao não impor o nosso jeito:

    • Prazo da sprint especificado pelo cliente. No caso era o prazo de 1 semana, quando para o time era melhor 2 semanas, já que o escopo estava bem definido e durante as planning, não havia mudança de escopo ou repriorização, e assim, é mais importante manter o ritmo e termos menos cerimônias, do que encurtar a sprint pra reagir a mudança;

    • Recomendar o uso de uma tecnologia, que se apresenta como um "canhão" para o problema que resolve. No caso era o uso do Redux (biblioteca de gerenciamento de estado em React) em todo o site, ao invés, de usarmos apenas na parte que fazia sentido, onde realmente havia um estado a ser gerenciado (carrinho de compra).

  • Antes de propor uma tecnologia, entender melhor o problema do cliente. A discussão de qual tecnologia utilizar, deve vir após o entendimento do problema, isso ajuda a focar mais no problema, do que na solução, pois em alguns casos até o cliente está mais interessado e como resolver, do que em porquê ou o que precisamos resolver.

Last updated