SCRIPT
Olá pessoal Fabio Akita
Se tem um papel que é difícil de definir e também de evitar em qualquer empresa de tecnologia é o do famigerado "gerente", seja um product owner, seja um scrummaster, seja um chapter leader ou seja lá que nome andam inventando agora. Todo mundo reclama quando eu fico cagando regra, mas já aviso que esse episódio vai realmente ser uma grande cagação de regra. Esse episódio é pra você que é gerente, ou quer ser gerente ou se viu obrigado a atuar como gerente. Todo mundo, em algum momento, vai passar por isso. Depende de você decidir se vai abraçar a oportunidade ou fugir. Porque sempre é mais fácil ser o reclamão do grupo, mas ninguém quer ser o cara que vai realmente resolver o problema.
O objetivo deste episódio não é ser um guia definitivo de tudo que existe sobre gestão mas só apresentar alguns pontos que eu pessoalmente considero importantes quando se discute esse assunto. Pontos que se você já não gerenciou diversos tipos diferentes de projetos, talvez não seja tão óbvio.
(...)
Tenho que deixar claro que tudo que eu disser hoje não são verdades absolutas. O problema de projetos e administração em geral é que a gente vê resultados ao longo do tempo. E durante esse tempo prestamos atenção em alguns poucos pontos que parecem importantes pra gente e ignoramos dezenas de pequenos pontos que pra mim pode não parecer importante porque são coisas que eu faço sem pensar, mas pra outras pessoas não são óbvias porque elas não estão acostumadas a fazer. Daí eu conto uma história que vai ser incompleta e por isso é difícil de replicar. O mesmo vale pra versão de outras pessoas. Por isso que ninguém vira gerente só assistindo videos ou lendo meia dúzia de histórias.
Se duas pessoas contarem a mesma história sobre um mesmo projeto, as histórias vão ser diferentes e ambas vão ser incompletas. É impossível resumir tudo que realmente foi importante num projeto que durou 12 meses em 12 minutos. Por isso valorizamos a tal da experiência. Parte da experiência são items que são fáceis de explicar, outra parte é implícito e difícil de colocar em palavras. São as várias pequenas decisões invisíveis que podem fazer a diferença no final. Portanto não, não tem nenhum livro que você possa ler que vai te ensinar essas coisas, só prática real, várias vezes, em cenários diferentes, prestando atenção em tudo que está fazendo e quais as consequências. Algumas vezes foram ações específicas que levaram ao sucesso, outras vezes foi literalmente a sorte de estar no lugar certo na hora certa. Não dá pra prever.
Falando em livros e teoria, uma cena que ficou famosa do meu video sobre o Guia de Aprendendo a Aprender foi quando rasguei meu certificado de PMP. Eu acho que expliquei isso lá mas vale repetir: eu quis dizer que certificados não significam nada. Colecionar papel pode ser um hobby, mas na prática é inútil. Porém não significa que eu não respeite o PMBOK.
Pra quem não sabe, existe um corpo de conhecimento documentado no Project Management Body of Knowledge, que é o PMBOK. É o material ensinado pelo PMI pra quem quiser se certificar como gerente PMP. É como se fosse uma enciclopédia e dicionário dos principais temas e termos de gestão como custos, escopo, comunicação. É o básico de conhecimento pra quem tem intenções sérias de se tornar um bom gestor. Mas como todos os cursos, ele não ensina como se tornar um bom gestor.
Pense no PMBOK como uma caixa de ferramentas. Só um bom carpinteiro sabe como usar quais ferramentas pra fazer bons móveis, mas só o manual de cada ferramenta nunca vai te tornar um bom carpinteiro. O PMBOK é a mesma coisa, tem chave de fenda, tem martelo, tem alicate, e como usar cada uma. Mas só isso é inútil pra você se considerar um gestor de verdade. Mas, vale a pena estudar pra saber o que todo mundo já sabe e não ficar tentando reinventar a roda.
No mundo de agilidade existem até alguns frankensteins como Agile PMI. Pelo mesmo motivo, isso não quer dizer muita coisa. Só misturar vocabulário de PMI com de Agile. E só mais um produto de marketing que consultorias tentam empurrar goela abaixo dos desavisados. O famoso “se der certo, é porque a metodologia é boa, mas se der errado, é porque você não seguiu exatamente como a gente falou, então paga a gente de novo pra corrigir”.
Eu falo disso no episódio de "Esqueça Metodologias Ágeis" onde explico como o termo Agile foi sequestrado e diluído por consultorias tentando vender a próxima grande moda da vez. E no episódio "O Guia Definitivo de Organizações" explico porque se você usa o tal modelo do Spotify, você não entendeu o modelo do Spotify. Em ambos os episódios explico o básico sobre a evolução e filosofia de organizações, então recomendo que assistam depois de terminar aqui porque não vou repetir o que já expliquei lá.
As maneiras formais de aprender sobre gestão é fazer faculdades como de engenharia de produção ou administração ou um MBA. E antes que comecem a me perguntar qual deveriam fazer, já respondo: tanto faz. Varia de pessoa pra pessoa e eu não te conheço pra dizer o que é melhor pra você, só você sabe disso e já digo que se você sequer consegue decidir o que é melhor pra você, como acha que vai decidir o que é melhor pro projeto dos outros? Já começa aqui o indicativo que você talvez não tenha inclinação pra ser um gerente.
Falando em MBAs, muita gente faz pelo prestígio do papel. Poder dizer que é um MBA. Tem quem coloque “virgula MBA” depois do nome no LinkedIn. Não posso criticar demais porque eu também colocava “virgula PMP” no meu, mas a vergonha alheia me fez tirar rápido. Também era 2003. Em 2022 já fica ridículo. Aproveite que ninguém viu e tira o seu porque é cringe. Nos anos 90 até 2000 alguns consideravam grande coisa. Hoje nem tanto. E se alguém se exibe por ser MBA, é um sinal vermelho. Que nem foto de Tinder com carrão atrás.
Tem quem confunda ser MBA com ser um bom gestor, e não existe correlação. Fazer MBA em instituições renomadas tem o objetivo maior de criar networking, não muito mais que isso. Se você está nesse caminho recomendo ler livros como do professor Henry Mintzberg e seu clássico “Managers, not MBAs”. Se certificar como PMP ou se formar como MBA é só mais uma forma de colecionar papel, e não garantia de se tornar um bom gestor. Eu ainda acho que se você puder estudar o material deles, é super válido. Só não pode achar que já sabe tudo e sim que pelo menos sabe o básico do básico.
Se eu fosse resumir o que é gestão em poucas palavras diria que é a capacidade de tomar decisões na hora que precisa, mesmo tendo informações incompletas. Alguém que não consegue tomar decisões e assumir responsabilidades nunca deveria gerenciar nada. Ser gerente não é obedecer ordens e preencher planilhas e relatórios sem fim. Qualquer idiota pode fazer isso. Isso não é um talvez, se seu dia a dia é só checar o backlog, checar as métricas, preencher nas suas planilhas e reportar, isso não é ser um gerente, é só ser um burocrata. E sim, existe a necessidade de burocratas em empresas grandes, mas não se iluda achando que está gerenciando porcaria nenhuma.
Vamos voltar ao conceito mais básico. Qual é o objetivo de uma empresa? Você pode inventar que é inovação, que é fazer diferença social e todo bla bla, mas isso é marketing. Não há nada de errado nisso porque toda empresa precisa construir sua marca em torno de algum tipo de marketing. Mas vamos tirar o marketing do caminho e ir na realidade nua e crua. O objetivo de toda empresa é dar lucro de forma sustentável. Nada mais, nada menos. Empresas que não dão lucro e ficam vivas ao custo de investimento é o que chamamos de “empresas zumbi”.
Mas não é “lucro a qualquer custo” como amadores pensam. Se o objetivo for dar lucro rápido sem nenhuma preocupação com futuro é simples: venda drogas. Dá muito mais dinheiro com muito menos trabalho do que tentar fazer uma tech startup. Só que o risco de você acabar preso ou morto é muito alto, por isso eu enfatizo o "sustentável". Não é difícil ter lucro de vez em quando, é muito difícil sustentar esse lucro por anos a fio. Crescer 10%, 20%, todo ano, anos seguidos.
Outra definição importante é que projetos tem começo, meio e fim. Muita gente esquece disso, mas se alguma coisa não tem objetivo bem definido e não tem uma data final, não é projeto, é operação. Não existe projeto que não tem fim. E mais importante: na prática nem todo projeto precisa ir até o fim. Saber quando cancelar um projeto e não insistir numa coisa que não vai dar certo é uma arte. Não existe nada de errado em descobrir que as premissas iniciais estavam erradas e reajustar. Mas tem muito problema em insistir num erro depois de descobrir que estava errado.
Na verdade, em cursos e em guias sobre gestão se dá muita ênfase em como documentar as coisas, como fazer métricas, e muita coisa que, francamente, é bem inútil. Eu quero começar falando sobre o que quase nunca vejo ninguém discutindo fora de happy hour e conversa de bebedouro. Como dizer "não". Ser um yes man ou yes woman é muito fácil. O cachorrinho abanando o rabo quando o superior manda fazer alguma coisa. Um yes man nunca vai ser um bom gestor porque um bom gestor é aquele que sabe dizer não quando precisa.
Por outro lado, alguém que só diz não e nunca entrega nada, é igualmente inútil. Um bom gestor é como um bom general, ele sabe escolher quais batalhas vai investir. Porque batalhas custam seu batalhão, custam tempo. Só lute batalhas que sabe que vai ganhar, e espere ter condições mais pra frente de lutar as batalhas que hoje iria perder. E só assim, escolhendo certo uma batalha de cada vez que se vence uma guerra. Sabedoria militar é especialmente interessante em empresas. Não a toa todo mundo fala sobre Sun Tzu e sua arte da guerra, mas ninguém sabe o que ele quer dizer, porque seu livro não pode ser lido literalmente. São alegorias inúteis pra qualquer um que já não tenha lutado uma guerra. E de fato, eu mesmo lá no começo era estilo mais kamikaze, ficava pegando briga que não era minha, e perdendo tempo com batalhas inúteis. Demorei anos pra aprender isso.
Um gestor ou um general só precisam existir porque lidamos com recursos escassos. Não existe dinheiro infinito, não existe tempo infinito, porque se existisse, ninguém precisaria gerenciar nada, era só gastar eternamente. É por isso que eu sempre acho que toda tech startup unicórnio e essa idéia maluca de só crescer fatia de mercado sem se preocupar em dar lucro tem como consequência gerar pessoas fracas. Porque muito pouca decisão precisa ser tomada, o problema sempre pode rolar pra frente, até o próximo round de investimentos. É viver a ilusão que se tem dinheiro infinito. E se tem dinheiro infinito, pra que escolher ser eficiente? Basta sair contratando mais gente, infinitamente. Até a bolha estourar. E podem acreditar, ela sempre estoura.
Um projeto costuma ser definido pela trindade escopo, tempo e custo. É impossível ter o maior escopo no menor custo e tempo. Se aumentar o escopo ou o custo aumenta ou o tempo aumenta. Não existe outra forma. Como custo e tempo costumam ser os fatores limitantes o que sempre precisa variar, pra menos, é o escopo. E sempre o escopo é mau definido e os objetivos do projeto que esse escopo quer cumprir são mau entendidos. Só durante o projeto que esse entendimento vai melhorando e isso sempre tem que levar à revisão do projeto.
Quase 10 anos atrás tive um cliente muito burro, o cara era tipo herdeiro. Quem construiu tudo foi a família dele, agora ele achava que só porque fez seu MBA ou sei lá, sabia alguma coisa. Herdeiros acham tudo fácil, lógico, sempre ganhou tudo de mão beijada. É um saco. Na época ele veio com o clássico “Akita, a gente podia encaixar aqui uma funcionalidade de chat, igual o Facebook Messenger, agora que já existe deve ser fácil né? Não dá pra fazer em um mês?” Minha resposta é sempre a mesma “igual? Claro que dá. Se você pagar a mesma coisa que o Facebook pagou, a gente faz”. Sério, lidar com gente que acha que tudo é fácil é foda. Tenho pena de quem trabalhava embaixo dele.
O que um mau gestor sempre vai preferir fazer primeiro, é tentar limitar o problema do tempo fazendo a equipe trabalhar mais horas no dia. E isso é outra burrice sem tamanho. Isso pode funcionar numa emergência de poucos dias. Mas transforme isso numa rotina e automaticamente a qualidade geral de tudo vai cair, e isso se torna uma bola de neve muito rápido, porque as coisas mau feitas dessa semana vão atrapalhar a semana que vem, e agora todo mundo vai ficar correndo atrás do próprio rabo pelo resto do projeto. Como um projeto atrasa 1 ano? Simples, um dia de cada vez.
A trindade de projetos é escopo, custo e tempo, mas existe a quarta variável invisível que todos esquecem. Tente entuchar o máximo de escopo, num tempo pequeno, cortando custos e naturalmente a variável que vai decair drasticamente é a qualidade. Essa é a quarta variável invisível. Falei no episódio anterior que qualidade foi um fator que passou a aparecer entre os anos 80 e 90, mas até hoje muita gente ainda ignora esse fator, porque é mais fácil falar em dólares e horas, mas é difícil de descrever qualidade. Os problemas gerados por um projeto mau feito tendem a ser empurrados pra operação depois.
Comece estabelecendo uma data final. Estabeleça um orçamento. Saiba quais são os objetivos que precisam ser atingidos, em ordem de prioridade, e estabeleça qualidade como fator importante. Daí acomode um escopo que caiba nessas restrições. Normalmente não cabe. E agora vem a inteligência de toda a equipe envolvida em decidir as melhores formas de executar cada tarefa de forma eficiente. Sem fazer horas extras. Garantindo que o que foi feito até agora não seja uma bomba relógio que vai explodir lá na frente. Tudo que é feito às pressas e sem cuidado vai virar um problema muito rápido.
Hoje em dia existe a figura de um PO ou Product Owner. Que é um nome mais bonito pra um gerente de projetos e gerente de operações. Dependendo de pra quem perguntar, vai ter definições diferentes. Mas eu gosto de pensar num PO como sendo um gerente com uma responsabilidade a mais, a de ser responsável pelo ROI do produto, o retorno do investimento. Numa empresa grande, abaixo de um PO vão existir várias equipes, cada uma com projetos próprios, que contribuem pro produto principal. As decisões do PO devem sempre levar em consideração o retorno de investimento de todos. Essa é uma das formas de limitar suas decisões e priorizar seus recursos nos lugares certos. Dê prioridade nos projetos que trazem o maior retorno de investimento. Parece fácil falar, mas muitos se esquecem disso.
Toda empresa e todo projeto tem diversos stakeholders, que são as partes mais interessadas. O financeiro está interessado em manter as contas sob controle, de preferência faturando mais do que gasta. O marketing está interessado em atingir novos clientes, aumentar a fatia de mercado, aumentar as vendas. O marketing só se preocupa com clientes que já existem quando o churn começa a ficar preocupante, ou seja, quando o cliente já existente desiste de você. O suporte ao cliente é o oposto, ele está mais preocupado com o cliente que já existe do que com os que ainda não pagam nada.
Os gerentes de projeto estão no meio desse fogo cruzado. Eles precisam saber colaborar entre si, mas seu foco é no projeto que está executando nesse instante. É nesse fogo cruzado que deveria atuar a camada C, o CEO, CFO, CMO, CTO, etc. A camada C existe pra tomar as decisões que afetam a empresa como um todo. As decisões que um gerente isolado não pode tomar. Facilitar a resolução de conflitos. Por isso eu digo que não existe nada pior que um C-level que não toma decisões e fica empurrando problemas com a barriga, normalmente jogando o osso e deixando os gerentes abaixo brigando entre si pra ver quem ganha ou fala mais alto. É o sintoma de um péssimo C-level e, por consequência, uma péssima empresa.
Da mesma forma, especialmente em empresas grandes, existe uma camada do meio muito gorda, os gerentes midlevel. Eles nem são C-level que podem tomar as decisões mais cruciais e nem estão na linha de frente vendo a guerra de verdade sendo travada nos fronts, onde estão os coordenadores e funcionários em geral. Eles acabam sendo mais burocratas, os famigerados pilotos de Excel e Powerpoint. É um mau necessário em muitas empresas, e eu realmente não consigo ver uma forma de eliminar isso totalmente, só minimizar. Não importa se você chama departamentos de chapters, é tudo a mesma coisa, estrutura hierárquica profunda e pior, estática.
Onde esse problema já existe, que é na maioria das multinacionais e empresas realmente grandes, só vejo isso mudando em épocas de mudança de liderança. Numa mudança de CEO, por exemplo. Onde é forçado a tal "reestruturação" de cima pra baixo. Não é garantia de melhoria, mas pelo menos o caos força mudanças, algumas podendo ser boas. Mas isso é arriscado e custa caro, por isso não se vê todo dia. Em empresas pequenas e médias, o problema é evitar chegar nesse ponto cedo demais.
No começo de uma empresa, ela vai necessariamente ter a cara dos sócios fundadores, que são a primeira geração de C levels dessa empresa. Se os sócios são ruins, a empresa vai ser ruim. As exceções são quando esses sócios tem conexões e investidores que forçam um C level diferente dos fundadores. Mas pensando no caso geral, é por isso que eu sempre digo que um jovem nos seus 20 e poucos anos não deveria pensar em abrir empresa se já não tiver sido muito bem criado e educado com herdeiro de um negócio pré-existente.
Eu disse isso em episódios anteriores, porque muito jovem ingênuo até hoje ainda fala das histórias lendárias dos jovens Bill Gates, Steve Jobs ou Mark Zuckerbergs e a lendária história da startup de garagem, como se todo mundo pudesse fazer a mesma coisa. Existe uma razão de porque se menciona Bill Gates, que abriu a Microsoft no fim dos anos 70. Tem muito pouco exemplo na história. Todos os nomes que eu falei largaram faculdades renomadas. Harvard e Stanford. Experimente entrar nelas. O nome do Bill Gates é William Henry Gates Terceiro. A família já era reconhecida. O famoso contrato da Microsoft com a IBM pra licenciar o MS-DOS só saiu porque o a mãe do Bill Gates era amiga do CEO da IBM daquela época. É assim que se faz. Nem eu, nem você temos como ter contatos assim aos 20 anos.
Quem não é um bom herdeiro vai precisar gastar pelo menos a primeira década de trabalho criando conexões. Conhecendo outras pessoas em começo de carreira que vai confiar em você porque viu em primeira mão que você é competente e entrega o que promete. Daqui alguns anos, ele vai ser dono de empresa, investidor, ou diretor, agora você tem networking de verdade. Isso se constrói e se conquista demonstrando competência de verdade e não se conectando no LinkedIn. Vou repetir: eu não aceito nenhum convite no LinkedIn de quem eu ja não tenha conhecido antes na vida real. Quando aceito desconhecido foi acidente. E outras pessoas que aceitam também não dão nenhum peso. Convite de LinkedIn, cartão de visita, e-mail de spam, vai tudo pro lixo. Não perca seu tempo. Quem eu confio tá no speed dial do meu celular, o resto é resto.
Enfim, o ponto que estava falando é que a empresa vai sempre ter a cara dos fundadores. Se os fundadores forem inexperientes e incompetentes, é assim que a empresa vai ser. Daí vai precisar ter sorte pra conseguir contratar alguém bom que aceite trabalhar pra você. É bem loteria. Por isso eu acho que o certo é primeiro você se tornar bom, um profissional nível A, porque só assim, vai conseguir contratar outro profissional nível A. Um profissional nível B só contrata caras nível C. E caras nível C só conseguem contratar caras nível E, e assim por diante. Só A contrata A.
E isso é importante porque quando possível, parte do trabalho de um gestor é contratar pessoas. Só que se ele próprio não for um cara reconhecido como nível A, vai continuamente contratar as pessoas erradas e colocar nos lugares errados. Das duas uma, ou vai contratar cara nível C quando precisava de um A. Ou vai dar tarefas nível C pra um cara nível A. Em ambos os casos vai ser uma equipe ruim.
Muitos gestores em começo de carreira ficam lendo os cases e metodologias aplicadas em grandes empresas como Netflix ou Google e enchem a boca pra falar “vamos fazer do jeito X porque a Netflix faz assim”. Mas reconheça como isso é idiota. Uma grande empresa como Netflix pode pagar profissionais nível A que ganham meio milhão de dólares por ano ou mais. Primeiro se pergunte: você pode pagar isso? O budget dos projetos que eles executam são da ordem de milhões de dólares. Seu projeto tem esse tipo de orçamento? Se não, por que diabos você está se iludindo achando que pode fazer o que eles fazem?
Sinceramente eu não acredito num gestor que não foi ele próprio um profissional igual aos membros de sua equipe. Um time de futebol onde o treinador não foi ele próprio jogador de futebol. Um chef de cozinha que não foi ele próprio descascador de batatas. Um general que não foi ele próprio soldado raso. E um gerente de equipe de desenvolvimento que não foi ele próprio um desenvolvedor de software. Nem todo programador tem capacidade de virar um gestor, mas certamente um gestor não técnico, nunca vai saber o que é ser um programador num seminário de poucas semanas. Nenhum soldado jamais vai respeitar um general que nunca esteve numa batalha de verdade.
Daí caímos no caso onde temos uma equipe que não respeita seu gestor e o gestor que não confia na própria equipe, que eu chutaria que descreve a maioria das equipes por aí. Respeito e confiança é diferente de ser o cara engraçado no happy hour. Foda-se ser engraçado. Bons profissionais tem respeito mútuo entre si, independente do ranking e classificação. Eles nem precisam ser amigos e gostar um do outro. Mas cada um sabe que na hora H pode contar com o outro. Acaba sendo natural. E esse é o terror das equipes de RH e recrutamento porque eles também não tem a mínima idéia de como contratar certo, porque são só burocratas, nunca estiveram na linha de frente.
E como eu sei que eu sou bom, nível A? Tem um checklist? Tem pré-requerimentos? Tem curso ou certificados que preciso ter? Não, não, não e não. Eu gosto de dizer que ser bom é que nem paixão. Como eu sei que estou apaixonado? Bom, quando estiver apaixonado, você vai saber. E todo mundo ao seu redor também vai saber. É a mesma coisa de ser bom. Se você não sabe se é bom, provavelmente não é. Quando for, vai saber, e todo mundo ao seu redor - que não for sua família e amigos - vão saber. E eu faço essa distinção porque quem automaticamente diz pra você que é bom, mesmo não sendo, tem boas intenções, mas está sendo desonesto. Um amigo de verdade diz quando você está errado, caso contrário está sendo um péssimo amigo, porque está roubando sua oportunidade de melhorar às custas dele se sentir bem consigo mesmo.
Quando você for bom, naturalmente, vai conseguir identificar outras pessoas boas. É assim que funciona. Pra ilustrar, eu gosto da série Peaky Blinders. E me identifico com um aspecto que o protagonista Tommy Shelby tende a no mínimo respeitar quem lutou na guerra como ele. Ele tem vários traumas das trincheiras da França na Primeira Grande Guerra Mundial, que foi uma das mais carniceiras de todos os tempos. Quando você encontra outro ex-soldado condecorado que esteve em batalhões que lutaram juntos, você meio que sabe do que ele é feito. Todo filme de guerra tem esse aspecto, e no mundo fora das guerras de verdade, é similar, a gente que tem cicatrizes sabe reconhecer as cicatrizes dos outros. Só que um recém formado ou iniciante não tem cicatrizes ainda. Esse é o ponto.
Mas não é só executar o trabalho? Não é só preencher planilhas e preencher relatórios e meu trabalho como gestor tá acabado? Esse é o pensamento que muito iniciante tem. Das duas uma, você vira o yes man, que vai só executando o que pede. Ou você se torna o maverick, o imprudente que acha que precisa revolucionar as coisas do seu jeito. Mas como eu disse, nenhum dos dois tem cicatrizes ainda pra saber até onde pode ir e nem como ir. E ambos estão fazendo bobagens. O problema é que o termo “gerenciar projetos” é o jeito errado de dizer. O objetivo é entregar projetos mas você sempre gerencia pessoas. Sua taxa de sucesso em projetos é diretamente proporcional ao seu bom relacionamento com suas equipes.
E pessoas não são máquinas. Especialmente em programação. Aliás, eu sempre falo que essa é a diferença entre software e hardware. Quando falei que é importante saber PMI mas não seguir nada deles ao pé da letra é porque muito do que existe documentado sobre gerenciamento de projetos deriva da engenharia de produção, da gestão de fábricas, relíquias da revolução industrial, o legado de modelos como da Ford. Aquele estereótipo de Charles Chaplin onde pessoas são secundárias e a linha de produção é o principal.
Nesse ambiente, tudo é minuciosamente planejado, você faz blueprints, plantas baixas, esquematizações e daí é possível calcular até que com bastante precisão quanto vai custar e quanto tempo vai levar pra construir a fábrica. E a partir daí a produção dos items é bem uniforme, com pouca variabilidade. Muita coisa é automatizada e no mundo ideal, nem é pra ter pessoas envolvidas, só robôs, como numa fábrica de carros mais moderna. A maior parte do conhecimento de administração e gerenciamento deriva desse cenário de produção em massa.
No jeito antiquado de pensar, se em hardware funciona, em software também deveria funcionar. Afinal, o programador é como se fosse o operário da linha de produção. Basta desenhar o projeto da forma mais detalhada possível, fazer a planta baixa, que seria função de um arquiteto, daí é só o programador executar como um operário numa linha de fabricar carros. Outra metáfora que se usa quando povo tenta falar de software como arte é equiparar com uma orquestra de música clássica, onde temos um maestro ou condutor, que é o gerente de projetos, a composição que é o trabalho do equivalente arquiteto, daí cada um na orquestra com seu instrumento só precisa executar sua parte com precisão pra termos uma peça de sucesso.
Só que ambos os pontos de vista estão errados. O trabalho de operário ou do músico da orquestra, o trabalho repetitivo, braçal, já é totalmente automatizado. Quem cumpre esse papel é o compilador ou interpretador. É o compilador que recebe a tal planta baixa e cospe o binário que o computador vai executar, mecanicamente. Agora o que é essa planta baixa? Esse é o código-fonte, o programa propriamente dito. O programador não é o operário. Todo programador é tecnicamente arquiteto. E na realidade não se trata de uma orquestra de música clássica e sim um grupo de jazz, onde intuição, improvisação, trabalho em equipe, fazem toda a diferença.
Eu não sou músico, mas do pouco que entendo, jazz seria o mais próximo de programação. Cada integrante toca improvisando, complementando e competindo com os demais no mesmo grupo, mas trabalhando de forma a criar uma música que faça sentido. Programação é a mesma coisa. Cada programador tem seu estilo, seu ritmo, e apesar de precisarem ter alguma base mínima pra não virar só barulho, a contribuição individual de cada um conta.
Um programador não é um operário. E software é ordens de grandeza mais complicado do que hardware porque hardware obedece as mesmas leis da natureza que são não-ambíguos pra todo mundo. Duas empresas de construção que recebem a mesma planta baixa, no final vão construir basicamente o mesmo prédio. Com quantidades similares de cimento, tijolos e tudo mais. A especificação é precisa o suficiente pra isso. E tem que ser assim porque uma vez construído, não tem como refatorar uma ponte. Não tem como adicionar ou tirar um andar no meio de um prédio.
Software é diferente. Dois programadores que receberem qualquer tipo de especificação de software, vão sair com dois conjuntos de código completamente diferentes. E quanto mais específico você tentar ser, mais próximo do código final você vai chegar, então no final é como se estivesse você mesmo fazendo o código. O código é a especificação. E o erro é justamente esse: achar que é possível especificar um software com precisão antes de comecar a codificar. Isso é impossivel.
Claro, se você está num ramo de atividade onde sempre faz o mesmo software o tempo todo, aí é mais fácil. Por exemplo, uma agenciazinha cujo trabalho é customizar Wordpress pra pequenos clientes. Nesse caso o grosso do software já está pronto, é o Wordpress. Você muda tema, muda logotipo, faz uma ou outra customização. Mas agora sim, você está muito mais próximo de uma linha de montagem de fábrica. Porque o grosso do trabalho não é codificar, é copiar e colar mesmo.
Mesma coisa um ERP como os de uma Totus da vida. O trabalho de programação mesmo é fazer e atualizar esse ERP, adicionar novas funcionalidades. Mas o grosso do trabalho de instalar nos clientes é customização, e não totalmente programação. A maior parte do software é padronizado e já está pronto. Daí o que tem de programação é mais a integração dele com outros sistemas, por exemplo. Daí é um ambiente um pouco mais controlado. Nesse tipo de ambiente que funciona as tais ferramentas low code ou no code, que é pra grudar peças que já existem e foram codificadas por um programador. Daí um operador só precisa customizar a integração desses peças. Mas o grosso do software em si, que é o ERP, já está pronto.
Na prática, em graus diferentes, ninguém mais faz 100% de todo software do zero. O sistema operacional é padronizado. Componentes como bancos de dados são padronizados. Pouco a pouco plataformas como AWS da Amazon ou Azure da Microsoft foram comoditizando diversas coisas que antes fazíamos do zero, até machine learning e inteligência artifical hoje são serviços que a gente só integra. A maioria dos projetos hoje tem uma parte grande que é basicamente só integração. O que muitos programadores fazem o dia inteiro é na realidade o trabalho de um integrador.
E mesmo assim o trabalho ainda não é linear de linha de produção porque temos diversos aspectos que mudam. Requerimentos de performance, requerimentos de escalabilidade, requerimentos de segurança, requerimentos de usabilidade. Nenhum deles permanece estático pra sempre. Mudanças nesses requerimentos às vezes exigem reescrever uma parte do software que não atende mais o que precisa. Às vezes é jogar fora um legado por um produto mais moderno. E é aí que entram as equipes de desenvolvimento pra decidir qual o melhor caminho: um band-aid em cima do que já existe, reescrever um pedaço, integrar com um produto de terceiros, ou uma combinação de tudo isso.
E de novo voltamos à formação da equipe. Uma vez definido a direção e objetivos. Quem decide como as coisas vão ser feitas? Um gerente não técnico tem zero condições de decidir essas coisas. Então, ou ele precisou receber essa ordem de alguém, ou precisou confiar que a equipe sabe quais as melhores decisões técnicas. E agora ele se ferrou, porque se não teve a oportunidade de criar essa equipe, se for o caso que falei antes de um gestor que não conquistou o respeito da equipe, tenha certeza que parte dessas decisões vai ser tomada no automático, e os resultados nunca vão ser os melhores.
Quando um gestor não tem a capacidade de decidir essas coisas, ele precisa de suporte. É onde normalmente deveria entrar o tal do CTO, o Chief Technology Officer. Dependendo do tamanho da empresa ele vai ter pares como um CSO ou Chief Security Officer que se preocupa com coisas como governança. E um bom CTO se for realmente um nível A, deveria já ter uma equipe de líderes técnicos que ele confia, e juntos conseguem prototipar, criar provas de conceito, e decidir a melhor solução técnica e orientar as demais equipes dos caminhos que decidiram tomar.
Agora cabe aos gestores de cada equipe coordenar com suas equipes e ver se é possível executar o que foi demandado. Às vezes a resposta vai ser não, e aqui um bom gestor tem que ser o firewall da equipe. Ele tem que saber decidir quando precisa forçar a solução pra equipe ou quando a equipe sabe que não vai dar certo, e porquê, e rediscutir o problema pra cima. E isso é sempre um problema quando o gestor não confia na própria equipe ou a equipe não respeita o gestor. Alguém sempre vai estar vendido nessa situação, e por isso eu disse que gestão de projetos é na realidade gestão de pessoas.
Por princípio, se não for do tipo kamikaze como eu, a maioria das pessoas detesta conflitos, e vai fazer o possível pra evitar, inclusive prejudicando os projetos, empurrando o problema com a barriga até ser tarde demais. Esse é o pior tipo de gestor, na minha opinião, porque ele vai dar burn out na equipe, executando uma coisa que já se sabia que não ia dar certo, só pra postergar a discussão do problema. O famoso jogar embaixo do tapete e torcer pra ninguém ver. Dentro da equipe, o único que tem obrigação de não fugir de conflitos, é o gestor. A equipe deve ser blindada de conflitos desnecessários, e o gestor é quem tem que aguentar a úlcera e blindar a equipe.
E falando na equipe, agora temos o problema de composição e comunicação. A realidade é que na maior parte do tempo, nenhum trabalho é realmente interessante. Você tem períodos de coisas legais e períodos de coisas chatas. Infelizmente as duas coisas são importantes. Sabendo disso, muito gestor tenta o caminho de tentar ser o motivador, cheerleader ou algo assim. Isso não funciona. Nenhum gestor motiva equipes, no máximo eles evitam desmotivar. Motivação é intrínseco, cada pessoa só consegue motivar a si mesma. Motivação externa é no máximo um rush temporário. Cada pessoa precisa encontrar propósito nela mesma, e isso é um trabalho individual. Psicólogos podem ajudar, mas gestores só precisam ajudar a não atrapalhar.
Se o gestor enxerga as coisas como fábrica, projetos como linha de produção, programadores como operários, a vida vai ser difícil. Porque ele vai sempre passar só o mínimo de informação, normalmente na forma de ordens, vai microgerenciar como se não houvesse amanhã, e raramente vai ter a via inversa que é de conversa e comunicação. Dizer uma informação é diferente de se comunicar. Comunicação é diálogo. Um diálogo não precisa ter uma resolução imediata, mas no mínimo precisa existir duas mãos na conversa. Isso é o mínimo.
Não dá pra aprender relacionamento de pessoas lendo livros, mas não tem nenhum mau em complementar seu conhecimento com alguns bons livros. E eu recomendo dois. O primeiro é o lendário “Psychology of Computer Programming” do grande Gerald Weinberg. E ele tem vários outros livros interessantes como o “Becoming a Technical Leader”. Mas se quiserem só um resuminho, acho que no mínimo todo mundo já deveria ter lido outro livro famoso, o “Peopleware”, do Tom DeMarco. Esse eu acho que tá um pouco defasado. Várias coisas que eram novidade nele, valiam pro começo dos anos 2000 e hoje parte já é meio considerado comum, mas continua sendo válido ler. Eu vou bater no ponto que a parte mais importante de gerir projetos é entender pessoas, então todo gestor deveria fazer um esforço nessa direção, nem que seja ler alguns livros.
O pior caso é quando o gerenciamento passa a ser em sua maior parte orientado a métricas. Métricas são boas e necessárias. Mas nem toda métrica é boa. As piores métricas são as de produtividade. E isso sempre cai no problema das famigeradas estimativas. O primeiro grande erro é quem confunde estimar com prever. Sabem porque existem duas palavras diferentes? Porque elas significam coisas diferentes. Muita gente ainda pede estimativa mas na realidade estão esperando previsão. Por isso sempre dá discussão "ah, mas você disse que 2 semanas estaria pronto".
Estimativa é sempre aquela brincadeira de "você finge que fala a verdade e eu finjo que acredito". Na prática não importa muito com que instrumentos você quer estimar, seja story points, seja horas-homem. O problema é dividir as tarefas ou storys em tamanhos que não sejam muito diferentes. Por exemplo, se o menor tipo de story é de meio dia, o maior não deveria ser mais que uns 2 ou 3 dias. Mais do que isso é um épico e deveria ser dividido mais. Acho importante no mínimo se ter um backlog com stories e um acompanhamento de stories por sprint, tipo um burn out chart. Se não sabe do que estou falando leia os papers originais de Scrum do Schwaber e Sutherland.
Agora, muito mais do que isso eu acho desnecessário. Isso porque essas medidas já são grosseiras, é mais pra ter ordem de grandeza e não exatidão. Sprints também deveriam ser semanais, duas semanas no máximo, mais do que isso e eu posso adivinhar que tem outros problemas graves sendo escondidos. Por exemplo, suas reuniões duram tempo demais e certamente são desnecessárias. Lógico que não dá pra ter um sprint de 1 semana se a segunda feira inteira é gasta só em planejamento e a sexta feira inteira é gasta com review e retrospectiva, e de terça a quinta todo mundo da equipe é toda hora interrompido.
Não adianta querer medir produtividade, no sentido de código entregue por semana. Seu maior problema de produtividade é desperdício de tempo. De novo, um gestor que não tem muita noção do que está fazendo acha que discutir por horas, vai chegar em algum lugar. No máximo é um gestor que sente que está trabalhando muito por gastar muitas horas fazendo reunião. Fazer reunião é o oposto de trabalhar. Tudo que pode ser resolvido por email, deve ser resolvido por email. Você se junta cara a cara quando a discussão claramente não está evoluindo. Aí faz uma reunião pra bater o martelo, e não pra gerar mais discussões.
Isso sem contar métricas aleatórias que obviamente são prejudiciais. Por exemplo, já vi lugares que mediam quantidade de bugs corrigidos. Ou seja, parecia uma coisa boa, quem mais corrigisse bugs, era o melhor. Não precisa ser nenhum gênio pra saber o que isso vai gerar: ninguém vai se preocupar em não gerar bugs. Já que a métrica é corrigir bugs, então o incentivo vai ser em criar mais bugs. Métricas ruins podem afundar sua empresa, porque se você encheu o lugar de pessoas ruins e deu incentivos pra elas serem ruins, é isso que elas vão ser: ruins. Nunca se esqueçam que no geral, as pessoas sempre vão escolher o caminho de menor esforço, é praticamente uma lei econômica isso.
Não tem nada em comunicação que me irrita mais do que quem não sabe o objetivo da comunicação. Ninguém gosta de ouvir sua voz por mais tempo do que o necessário. Ninguem está interessado no seu discurso. A gente só quer saber: qual o objetivo? Qual a direção? Se for um navio é "virar 15 graus a bombordo". Pronto, essa é a informação. Tudo que você falar antes ou falar depois é desnecessário. O bom dia pode vir na mesma mensagem e não antes de um "digitando ..." que fica nos três pontinhos por 5 minutos e me faz ficar esperando que nem um idiota. E você tem que estar disponível pra todo mundo da equipe o tempo todo, porque o papel de um bom gestor é ser um facilitador. Gestor que é difícil de encontrar, não presta. Ah, mas é porque ele tá sempre em reunião. Não tenho dúvidas, e isso é um problema que ele precisa se virar e resolver.
Toda interrupção é desperdício. Toda tarefa de 1 hora que foi interrompida por 5 minutos no meio vira 1h e meia ou mais. Porém, toda informação relevante precisa chegar na hora certa. Nem antecipado que não altera o fluxo de nada, e nem atrasado que agora vai custar o dobro pra agir em cima. Qual é a hora certa? É pra isso que existe um gestor. Interrompa todo mundo o tempo todo e sua produtividade vai pro buraco. Evite interromper quando realmente precisa e vai cometer erros que vai custar mais caro lá na frente. Se fosse fácil decidir isso, não precisaríamos de gestores.
Chats como Slack não foram feitos pra serem usados o tempo todo. Se algo realmente urgente surgiu que não pode esperar, sim, acione o alerta vermelho, interrompa quem precisar pra resolver. Porém, se tudo é alerta vermelho, em breve ninguém mais vai dar atenção. Se a informação não for urgente, anote, comunique quem precisa por email no fim do dia. É o tipo de etiqueta que não deveria precisar ser dito.
Falando nisso, aprenda de uma vez por todas: se tudo é uma prioridade, por definição, nada é prioridade. Eu fiz um video só sobre priorizar. E saber priorizar vale pra todo mundo, todo integrante de qualquer equipe, até chegar no dono da empresa. Não existe querer fazer tudo, porque não temos recursos infinitos. Gerenciar é a eterna tarefa de eleger prioridades e cortar coisas que não são prioridade. E como define prioridades? Essa é a pergunta de um milhão de dólares, se existisse forma fácil eu estaria vendendo. Agora, se você não consegue definir prioridades, certamente não deveria estar liderando. Foi o que eu falei antes: tomar decisões quando elas precisam ser tomadas, e não empurrar problemas com a barriga.
Estimativas e prioridades são coisas que só quem está ativamente participando do projeto deveria se preocupar. Burocratas que aparecem de vez em quando, não tem que dar pitaco em nenhuma das duas. E esse é outro problema frequente, especialmente em empresas grandes demais onde um diretor não tem como fisicamente estar presente em todos os lugares. E aí voltamos ao problema do nível A que contrata outro nível A. Todo mundo precisa poder confiar em outras pessoas. Não cegamente, mas com o mínimo de informações que te dão segurança o suficiente pra poder focar em outros lugares que precisam mais da sua atenção. Não existe metodologia nem fórmula mágica pra isso. Ou você tem pessoas que confia ou não tem, e se não tem, não dá pra substituir por métricas mágicas. Elas só vão te iludir por mais tempo do que deveria.
Eu disse antes que um soldado não confia num general que não foi ele mesmo um soldado antes. No mundo ágil temos a história do porco e da galinha. O gerente que não precisamos ter são os galinhas. Por que galinha bota o ovo e vai embora, mas o porco corta na carne. Quem toma decisões precisa cortar na própria carne e não largar o problema pra equipe e ir embora, e só aparecer quando é pra tomar o crédito. Faça isso muitas vezes, e daqui a pouco vai estar se perguntando porque a produtividade da sua equipe só cai.
Houve uma época que toda decisão era mais baseada em métricas financeiras. É de onde vem a má reputação no meme popular de que empresas são entidades do mau que só pensam em dinheiro. E muitas realmente são assim. Daí teve a época de qualidade total, onde finalmente caiu a ficha que qualidade faz tanta diferença quanto financeiro. Foi a partir do fim dos anos 60 que passamos a diferenciar trabalhadores entre aqueles que executam tarefas rotineiras e padronizadas, como numa fábrica, versus uma categoria que começou a crescer cada vez mais, o que Peter Drucker cunhou como knowledge workers ou trabalhadores do conhecimento, que executam tarefas não-rotineiras, como nós programadores.
Muitos conceitos de gestão ainda vem da época da Revolução Industrial. A idéia de hora-homem por exemplo. Mas esses conceitos não funcionam pro dia a dia moderno porque fábricas deixaram de ser o principal componente das indústrias. Então medir só com base nos números financeiros já não dava mais indicativos da saúde geral da empresa. Foi quando surgiram outras formas de enxergar empresas como o famoso Balanced Scorecard do Kaplan e Norton e suas variações a partir do fim dos anos 80, com métricas financeiras e não-financeiras.
Se você for de admistração certamente já viu Balanced Scorecards, se não for, os detalhes não interessam tanto, mais a noção que hoje as empresas não são todas tão burras de só olhar métricas financeiras como muitos ingenuamente assumem. Elas podem ser incompetentes em alguns aspectos, mas a maioria tem que preocupar com múltiplos aspectos da empresa, hoje em dia incluindo coisas como reputação em redes sociais. Mas tudo bem, eu sei que tem empresas burras porque vira e mexe ouço falar dos idiotas que querem monitorar produtividade mandando o funcionário ligar a câmera e instalando software pra ver se ele tá mesmo digitando ou coisas assim. São empresas assim que mancham nosso mercado e eu espero que eles entrem em falência logo. Ou você confia em quem contrata, ou então não contrata. Se alguém quebra sua confiança nesse nível, você não fica brincando de monitorar, você manda embora. É simples asim.
Pra complementar, o maior problema de uma empresa é quando ela trata todo mundo como criança. Sabe, piscina de bolinha e afins? Quando é uma creche, sim, consigo ver a necessidade de monitoramento ativo. Porque crianças são difíceis de prever, e alguém pode acabar se machucando. Mas uma empresa precisa tratar todo mundo como adulto. Se você tem adultos, não precisa ficar microgerenciando nem monitorando. Por outro lado, se você trata todo mundo como criança, de novo é culpa sua. Empresas não são creches. Não acumule crianças birrentas. Monitorar crianças só funciona quando elas mijam nas próprias calças e brincam de ficar fuçando onde achar faca da cozinha pra se cortar. Num trabalho sério, monitoramento desse tipo não serve pra nada, só pra comprovar que a liderança é completamente incompetente.
Enfim, Peter Drucker, pelo menos na minha época, era o be-a-ba da administração. E naquela época também tivemos trabalhos como de Ikujiro Nonaka e Hirotaka Takeuchi, como eu falei no episódio anterior os japoneses aceleraram seus processos de qualidade e gestão. E Nonaka e Takeuchi escreveram vários artigos, incluindo o famoso The New New Product Development Game, que é de onde surgiu o termo "scrum" que depois o Ken Schwaber usou pra formular a metodologia Scrum e se tornou uma das raízes do movimento Ágil.
Qualquer um que tenha minimamente estudado agilidade já leu esse paper. E eu recomendo que dêem uma boa estudada caso ainda não tenham feito isso. É o resumo do resumo sobre organizações e termos como auto organização. Não é de hoje que se fala em coisas como autonomia. Esse paper é dos anos 80 e até hoje a maioria das empresas ignora o que já sabemos que funciona. Uma boa parte das idéias dessa época fala em elevar os funcionários a pensar em vez de só obedecer e executar. Mas sem entrar em caos. Eu explico isso no meu video sobre Organizações.
Parte disso tem a ver com evoluir as pessoas e passar esse conhecimento pra novos projetos. Por exemplo, um dos erros que até hoje ainda vejo muitas empresas cometendo é quando querem iniciar um novo projeto, mas todo mundo está ocupado já. O que eles fazem? Contratam uma empresa terceirizada pra fazer o novo projeto. Isso é um grande erro.
Às vezes não existe outra forma a não ser aumentar o head count, ou seja, quantidade de pessoas. Um bom gestor sempre deve designar novos projetos pros membros mais seniors das suas equipes e colocar terceiros embaixo deles. Se por acaso for uma especialização que ninguem das suas equipes tem, mesmo assim você coloca seus seniors junto com os terceiros pra eles aprenderem seja lá qual especialização que não tem.
Terceiros devem ser tratados como juniors internos. Ambos os casos embaixo dos seniors internos. Os seniors se tornam seniors quando eles aprendem a mentorar os membros menos experientes. Esse é o ciclo sustentável. Depois que o projeto que eles entregaram passa pra fase de operação, que é realmente ser usado, receber correções, ajustes, manutenção, eles precisam aprender a criar sucessores pras suas posições, pra continuar o trabalho enquanto eles assumem novos projetos.
Autonomia só existe se todos os membros conseguem confiar nos demais membros, não cegamente, mas porque os mais experientes sabem que conseguem mentorar os mais novos, e porque os mais novos sabem que tem quem consultar quando tem dúvidas ou problemas. Uma equipe só de seniors é um desperdício e uma equipe só de juniors é um desastre esperando pra acontecer. Toda equipe deve ter capacidades mistas e serem rotativas. Um junior bem mentorado vai se tornar o novo senior no futuro, que vai passar a mentorar os novos juniors. Os antigos seniors vão continuar em novos projetos, que passa a aceitar novos juniors pra mentorar e assim por diante.
Bons gestores sabem reconhecer os pontos fortes e fracos de cada membro e a ajustar as equipes de acordo com isso. Se em todo jogo você só manda o dream team jogar, quem está de reserva nunca vai ganhar experiência, e quando um dos membros estrela tiver problemas, ninguém vai conseguir jogar no seu lugar, a equipe não sabe como lidar com a mudança. Todo jogo não decisivo precisa misturar reservas. Todo treinador sabe disso. É assim que começam a surgir novas estrelas. Todo gestor precisa saber disso também. Nada que fica estático tempo demais é bom, sempre vai deteriorar. Pequenas mudanças, periódicas, é bom. É a beira do caos que falei no episódio passado.
Confiança não é amizade. Entendam isso de uma vez por todas. Uma coisa é o happy hour. Outra coisa é o trabalho. Quem confunde essas coisas, acha que esconder os erros do amigo é uma coisa boa, porque ele não quer se o cagoeta, o x9. Mas isso prejudica ele, prejudica a equipe e prejudica quem está cometendo os erros. Se você desse o feedback honesto, estaria dando a chance dele corrigir o erro e melhorar. E quando a pessoa se recusa a corrigir o erro, ele é quem está quebrando a confiança com você. Ninguém precisa de pessoas desonestas do lado, especialmente aquele que te chama de amigo só quando interessa. Corte essas pessoas, o quanto antes. Seja realista. Incompetência é algo que podemos tentar consertar. Porém, maucaratismo se corta na raíz. Eu sempre digo que se a mãe dele não conseguiu criar caráter nele em 20 anos, não sou eu que em 2 meses vai conseguir. Corta.
Mas o trabalho é assim mesmo: quando você faz algo certo, não é nada demais, afinal você é pago pra fazer certo. Por outro lado, quando comete erros, eles sempre se sobressaem. É a vida, se fosse fácil, qualquer um fazia e ninguém precisaria de você. Senioridade é aprender a lidar com isso e continuar caminhando em frente. E o papel do gestor não é fazer tudo sozinho, é conseguir construir uma equipe onde todos tem essa mentalidade, e naturalmente os projetos tendem a alcançar sucesso. Não porque todo mundo previu logo no começo tudo que precisava fazer, mas sim porque entendem que erros vão acontecer no caminho e as expectativas vão sendo realinhadas de acordo. Os stakeholders não ficam sabendo de desastres só quando já é tarde demais, esse é o principal. Todo erro identificado o quanto antes, tem chances de ser arrumado.
Gerenciar projetos é gerenciar pessoas. E gerenciar pessoas é gerenciar expectativas. Ninguém precisa de alguém que só faz promessas. Todo mundo precisa de pessoas que assumem seus erros e fazem o possível pra corrigir e, claro, evitar repetir os mesmos erros. É só isso. Promessas e discursos são inúteis e desnecessários. A camada de gestão é responsável pela estratégia, a direção e objetivos. As equipes são responsáveis pela tática, a execução. Todo soldado na frente precisa confiar que o soldado de trás vai cobrir sua retaguarda, e assim todos avançam coordenados em busca do mesmo objetivo, que é ganhar mais uma batalha.
Como falei no começo, esses foram só alguns pontos que eu considero importante lembrar. Mas cada parágrafo que eu falei não é mais que um pequeno resumo de um assunto gigante. O tema completo de gerenciamento engloba décadas de experiência e técnicas que vieram sendo aprimoradas, modificadas, e continuam em evolução. Toda técnica moderna de gerenciamento de software nasceu nos últimos 15 a 20 anos. Muita literatura ainda fala de coisas de 3 ou mais décadas no passado. Algumas coisas continuam valendo, outras não. E a função de todo bom gestor é se manter atualizado, experimentar coisas novas, e não perder o foco sobre sua missão, que é entregar projetos de forma sustentável e ajudar a evoluir suas equipes. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal, e compartilhem o video com seus amigos. A gente se vê, até mais.