As pessoas costumam me chamar apenas de "Ibra". Fique à vontade. Diretor de tecnologia no Nexo.
Profile no GitHub /ibrahimcesar
Twitter @ibrahimcesar
Site pessoal ibrahimcesar.cloud
Você não precisa me seguir em nenhuma plataforma, apenas uma referência para ver temas que eu abordo, se achar necessário.
Este documento se aplica a mim e de nenhuma forma pode ser considerado como aplicável a qualquer pessoa de qualquer outro time ou do Nexo.
Este é o meu Manager README. Este documento é para você. Dediquei um tempo especial para escrevê-lo por que eu me importo com quem eu trabalho e gostaria que cada pessoa esteja o melhor contextualizada e equipada. Use este documento como uma introdução à forma como eu trabalho; meus frameworks mentais e operacionais e meu mapa mental. Este documento será bem sucedido se nos ajudar a ter um melhor relacionamento de trabalho.
Como Diretor de Tecnologia eu:
- Sou responsável pela acessibilidade, disponibilidade e experiência das publicações e os sistemas que dão suporte aos modelos de negócio.
- O principal fator de otimização de entrega de software é Segurança psicológica. Isto sempre vai estar na balança de qualquer decisão.
- Sou responsável pela continuidade, melhoria, manutenção e acesso à todo o stack de tecnologias.
- Permitir uma melhor eficiência e crescimento da empresa, sempre buscando atender as expectativas de negócio demonstrando claramente os trade-offs relevantes.
- Criar o contexto ideal para que tenha sucesso, conectando o que precisamos como organização e o que cada indivíduo precisa.
- Meu primeiro mandato é servir você, não o inverso. Estou sempre aqui para auxiliar. Me pergunte.
- Alinhar o time na mesma direção.
Tendo a ser mais produtivo durante as manhãs. Meu período de trabalho costuma ser entre 8h00 e 19h00, com uma parada de 2 horas de almoço em que geralmente leio e faço uma descompressão para voltar ao trabalho.
Se você receber um email ou mensagem de mim à noite, ou fora de seu horário de trabalho o padrão sempre é "ele me mandou isso para não esquecer ou está trabalhando em um outro horário" e você pode completamente ignorar e responder apenas em seu período de trabalho. Eu nunca espero respostas imediatas a não ser (e se acontecer) tivermos alguma situação crítica de resposta imediata que está comprometendo nossa infra-estrutura, mas para isso mantemos um calendário rotativo on call e mantemos uma forma estruturada e definida para isso.
Eu recomendo que reservem blocos em suas agendas para períodos de trabalho que preferem não ter interrupção alguma. Isso dá visibilidade a todos e mantém sua produtividade, todos precisamos desse tempo reservado.
Por favor, não confunda minha timidez com frieza ou desinteresse. Eu levo um tempo para me acostumar com novas pessoas e aprecio muito e me engajo a ajudar em qualquer momento que eu possa, mas eu dificilmente fico chamando as pessoas para falar ou checar como as coisas são. Por favor, me chame!
Eu não costumo aderir a nenhuma Metodologia Ágil®. Mas eu sou extremente fã e aplico princípios ágeis a tudo o que faço. O primeiro princípio do manifesto ágil é "Indivíduos e interações mais que processos e ferramentas". Eu jogo SCRUM pela janela a qualquer momento se for o melhor para as pessoas do time. Também acredito que SAFe® faz Waterfall parecer uma boa ideia.
Eu encorajo todos a sempre pesquisarem e trazerem novas formas de trabalho e tecnologia. Para isso, sempre acho que a melhor forma é por escrito. Criando um documento, uma espécie de RFC, simplificada, ajuda a estruturar melhor os pensamentos, a forma prática de implementar e é claro, os trade-offs.
A maioria de nosso trabalho é organizado ao redor do GitHub. Parte do mesmo princípio que tenho para testes, documentação e outros: o mais próximo do código possível, um "único repositório da verdade" – single source of truth.
Para uma melhor descrição de todos rituais, ferramentas e processos, cheque o nosso guia no repositório.
O próprio SCRUM® Guide define que "Scrum's roles, events, artifacts and rules are immutable and although implementatting only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirely". Vários outros frameworks ágeis possuem o mesmo tipo de declaração.
Preferimos uma tática se algo funcionar, ótimo. Se não, continuamos a experimentar e a otimizar. Sermos ágeis antes de qualquer classificação Ágil®. Entendendo ágil, como um espectro:
Fonte da ilustração: Sooner, Safer, Happier
Compartilhamos novidades, atualizações uns com os outros. E então avaliamos baseado nas necessidades e particularidades de cada pessoa em como se desenvolver, sempre mantendo um histórico de cada conversa para termos uma evolução de cada um.
O que eu espero da primeira semana de cada pessoa ao entrar no time: conhecer um pouco mais e construir confiança. Nada mais. Não espero que coloque nada em produção, apenas tome seu tempo explorando nossa base de código.
Ao final dos primeiros novento dias espero que sinta-se parte do time no sentido em que está colaborando, tem segurança psicólogica e está crescendo e se desenvolvendo. E isto é um diálogo. Ao longo do tempo vamos conversando e ajustando.
Palavra forte. Eu, honestamente, nunca gostaria de passar por essa situação. E acredite, é de quebrar o coração para ambos os lados. Eu nunca comemorei nenhuma demissão. Mas resolvi compartilhar o contexto em que elas ocorrem. Basicamente: em um primeiro momento, a esfera do time e em um segundo, a esfera organizacional.
- Esfera do time: Eu sigo a "The No Asshole Rule". Que traduzo como a "Regra da Civilidade". Insultos, deixar alguém incomodado, interrupções frequentes de outras pessoas, sarcasmo exacerbado, humilhação, discriminação por qualquer motivo: raça, filiação partidária, religiosa ou de linguagem de programação preferida. Ausências sem explicação – não está se sentindo bem? Mande um "Não trabalhei hoje". E tudo bem, sério. Não reconhecer ideias de outras pessoas e tratar do tema como novidade, se "apropriando". É uma lista resumida mas não exaustiva de atitudes quando regulares, frequentes, minam o time, de tão tóxicas podem levar as pessoas a evitarem reuniões e quebrar o time - viramos apenas um grupo de pessoas trabalhando juntos. Nesse caso eu sempre escolho o time, não importa a proeficiência técnica da pessoa.
- Esfera organizacional: Já tive no passado que realizar cortes por conta de reestruturação da empresa. Esta não tenho muito o que comentar. Qualquer decisão nesse contexto sempre deixa as pessoas desligadas da empresa na posição mais frágil, que eu nunca gostaria de ter que fazer, mas faz parte do trabalho.