Na primeira edição do
blog de vídeo do
AichiHyp, visitamos o Dodo Pizza, onde discutimos a integração de TI e negócios, programação extrema, Agile, trabalho remoto, a arquitetura de seus sistemas e os recursos de contratação. Você pode ler as citações da entrevista e um pouco de história, ou pode ir imediatamente ao vídeo.
Por que Dodo Pizza?
A primeira vez que notei Dodo foi depois da história de um amigo que teve uma entrevista com eles. Tornou-se interessante e comecei a coletar fatos de várias fontes. Devo dizer que a imagem acabou sendo bastante contraditória. Por exemplo, a história sobre o fato de que na entrada um desenvolvedor deve trabalhar um mês em uma pizzaria, além disso, em Syktyvkar e dentro de dois meses, entrou em foco. Parece que aqui o período de teste já passou e você nem se sentou ao teclado. A questão principal acabou de se tornar essa história e outras como ela.
Você sabe, quando Yegor me contou pela primeira vez sobre o Dodo e o que eles tinham de interessante, eu imediatamente peguei fogo. Havia uma espécie de fonte inesgotável de idéias e abordagens que, sem um indício, pareciam algo irreais e sobre as quais eu queria perguntar. Para mim, pessoalmente, o processo de comunicação com os caras acabou sendo extremamente inspirador, e fui tentar algumas práticas em minha equipe no dia seguinte. Espero que tenhamos conseguido não apenas revelar o Dodo a partir de práticas legais de engenharia, mas também transmitir toda a atmosfera de amor por nosso trabalho e abertura, presente em literalmente tudo!
E abaixo estão citações de uma entrevista com Alexander Andronov, CTO Dodo Pizza. Mas apenas citações não são suficientes - para sentir a atmosfera, é melhor entrar
no próprio vídeo !
Citações de uma entrevista com Alexander Andronov
Por que a Dodo é uma empresa de TI
As soluções de tecnologia e TI são as primeiras em termos de gerenciamento de pizzarias e abordagem de gerenciamento. Contamos com a criação de nosso sistema que ajuda a gerenciar todos os processos de negócios e estágios de preparação de pizzas.
Como exemplo, um sistema de controle de qualidade. Anteriormente, funcionava assim - compradores misteriosos fazem um pedido em uma pizzaria e avaliam-no por vários fatores. Um dos critérios é quão cuidadosamente a pizza é feita, quão redonda é, como os ingredientes estão localizados. Fizemos um piloto do projeto, que nos permite analisar a qualidade da pizza usando o aprendizado de máquina. Sem um foco em TI, ninguém pensaria em tais soluções.
Sobre o experimento salarial aberto
Eu disse às pessoas com antecedência quem e quanto o salário potencialmente aumentaria. Eu falei sobre minhas limitações em porcentagem e números. Expliquei a alguns por que o aumento deles seria menor que o de outra pessoa. Foi perfeitamente, como a abertura decide. Todas as reclamações são devido a omissões. Assim que você começa a dizer algo, o descontentamento surge. Quando você fala abertamente, isso é absolutamente normal.
Sobre trabalho remoto
Uma equipe reunida em um local é a priori melhor distribuída. As próprias pessoas estão mais confortáveis com isso. Mas nós viemos principalmente de pessoas. É provável que tenhamos um desenvolvedor muito legal e disciplinado que queira trabalhar em um site remoto.
Com o crescimento da empresa, chegaremos à conclusão de que nosso trabalho continuará em 24/5 ou 24/7. Isso também se aplica ao desenvolvimento. Existe uma estratégia Follow-the-sun - quando em um lugar as pessoas saem do trabalho, em outro elas já saem na época. Nesse caso, qualquer problema pode ser resolvido muito rapidamente. Quando cada equipe pode entrar em qualquer parte do sistema, aconteça o que acontecer, sempre pode consertá-lo.
Sobre a programação de pares
Não usamos programação em pares 100% do tempo, porque é fisicamente muito difícil. Mas essa é uma prática usada regularmente, conforme necessário.
Quando você tem uma tarefa realmente difícil e precisa de uma revisão constante, senta-se com alguém e trabalha. No processo de comunicação, quando você cria uma solução técnica em conjunto, as melhores ideias aparecem.
Há momentos em que você usa a programação em pares para bombear pessoas em alguma área. Por exemplo, há uma pessoa que vasculha o React e outra nem tanto. Após uma semana de trabalho em pares, o nível será nivelado.
Lições das principais quedas
Essas histórias nos lembraram por que compromissos de qualidade não podem ser feitos. Entendemos que somos todos sobre negócios, temos muitas tarefas e processos que precisam ser incorporados ao Dodo IS. Mas, ao mesmo tempo, nunca devemos sacrificar a qualidade. Essa é a principal idéia que existe em absolutamente todas as frentes - tanto no entendimento de cada pessoa no desenvolvimento quanto no entendimento dos negócios, e no entendimento de todas as equipes que nem sequer estão relacionadas à TI.
Conclusão
Somos um projeto muito jovem e seu feedback é muito importante para nós. Escreva comentários aqui no Youtube e nas redes sociais:
-
Youtube-
Facebook-
Vkontakte-
Instagram-
Instagram-
Twitter