o Pior Programador que conheço
ฝัง
- เผยแพร่เมื่อ 30 ก.ย. 2024
- ✅ Torne-se membro para obter aulas técnicas exclusivas comigo:
/ @lucasmontano
💜Comunidade do Discord: / discord
❤️ Ajude o Rio Grande do Sul, informações em lucasmontano.com/
✅ Meu site parece que foi feito por um DEV backend né?! Mas lá tu encontra tudo que precisa saber sobre o que tenho feito e onde estou:
lucasmontano.com/
✅ 𝗢𝗦 𝗠𝗘𝗟𝗛𝗢𝗥𝗘𝗦 𝗩𝗜𝗗𝗘𝗢𝗦 𝗗𝗢 𝗖𝗔𝗡𝗔𝗟
▸ 3,700,000 requests do MrBeast na API do X (eu tentei e não foi barato)
• 3,700,000 requests do ...
▸ Programação realmente é muito difícil?
• Programação realmente ...
▸ DEV Precificando Projeto tipo Netflix (bem simples)
• DEV Precificando Proje...
▸ Gemini Impressiona ao Superar Humanos : Nova IA do Google • Gemini Impressiona ao ...
▸ OpenAI choca o mundo +1 (mas Sora não é sobre gerar videos)
• OpenAI Sora não é apen...
▸ IA que utilizo & a mentira da Gemini (Nova IA do Google)
• IA que utilizo & a men...
Trampei numa empresa que utilizou a contagem de tickets resolvidos como métrica de desempenho. Os DEVs resolviam porcamente os tickets e era comum um problema mal resolvido retornar como um novo ticket. Sem falar que era uma corrida pra pegar os tickets mais fáceis, pois 1 ticket era 1 ponto, independente da dificuldade.
Unindo isso com pressões desnecessárias como "Vamos ter cortes nos menos produtivos!", foi a gota d'água para gerar um ambiente de não colaboração, pois afinal, era cada um por sí, foda-se o produto e foda-se a equipe!
No final, se o gerente não sabe desenvolver ou não desenvolve a muito tempo, ele se torna a pior pessoa para gerenciar uma equipe, pois pior do que quem não sabe e vai atrás de aprender, é alguém que "acha" que sabe como as coisas funcionam.
Acho muito ridículo o nível da cara de pau de querer medir produtividade das pessoas que fazem um produto no qual o que importa é a qualidade. Não se analisa o quão bons profissionais desse tipo são pelo quanto eles estão trabalhando e sim pelo resultado final. Imagina ficar analisando se o pedreiro é bom pela quantidade de tijolos por hora, se o quiropraxista é bom pela quantidade de estalos. É cada baboseira desse povo que não entende de tecnologia e quer gerir algo tech.
Área de TI é assim pela própria romantização dos próprios programadores.
Eu tenho muito resistência em interagir demais com a galera do meio tech. Todo mundo acha que são especiais e que a área tem algum tesouro escondido, sendo que é só um trabalho como qualquer outro, nada diferente.
Esses dias critiquei microgerenciamento em um canal aqui, e os super programadores todos vieram ofender.
Afinal, se tu tirar essas métricas de produtividade, como o rapazinho vai massagear seu ego e se sentir melhor que os outros?
Sim, medir a produtividade do ator porno pela qualidade de bombadas...
@@psyab9375 não considero um trabalho como qualquer outro. Só pra conseguir entender o mínimo ou escrever uma simples linha de código, dependendo do que você quer programar já tem que entender muito de tecnologia, só pra montar um ambiente simples pra rodar uma IDE já tem que ter estudado um tanto. Na nossa área qualquer coisa simples exige não somente muito estudo como muita prática (estou falando de projetos reais para pessoas reais e não de projetos "Pokédex" da vida). Assim como um médico só pra iniciar a consulta mais simples possível já precisa ter estudado igual um condenado por anos, então não tem como comparar esse tipo de profissão com todas as outras, de certa forma são sim especiais.
@@JonatanEdOrtiz Ah, eu considero. Mas pelo visto minha visão é minoritária no meio.
E, como falei, acho que muito dos defeitos da área vem justamente dessa perceção de que estamos fazendo algo ''além do comum''.
E nem é nivelando por baixo, é uma área específica sim, mas no final do dia a gente está atendendo a demanda de alguém, resolvendo um problema de alguém.
Não me acho melhor/mais especial que um advogado, dentista ou arquiteto.
@@psyab9375 ah sim, não me refiro no sentido de ser melhor/mais capacitado/mais inteligente que profissionais de outras áreas, ainda mais dessas que você citou que também são parecidas com a nossa, exigem muito estudo antes de conseguir atingir até algo básico e inicial, o que quero dizer é que existem muitas profissões que você consegue simplesmente começar no dia que quiser e vai aprimorando com o tempo e existem outras que você precisa "apostar" muitos anos de esforço e aprendizado sem saber se vai dar certo e mesmo que você consiga entrar na área não quer dizer que vai conseguir evoluir nela ou ainda mais, se destacar, porque a partir daí não exige somente esforço, mas capacidade intelectual, acho que por isso muita gente da nossa área se acha superior, por ver que é muito difícil e mesmo assim conseguem se destacar, fora isso tem a questão de a nossa acho que é a única área que quase todo dia tem gente atrás de nós oferecendo emprego, enquanto até um médico precisa procurar emprego ativamente. Nossa área tem muitas particularidades, por isso muitos se acham especiais. Não acho que seja especial nesse sentido, mas sim diferenciada.
Desde quando você me conhece? 🤨
Não. Esse programador sou eu
Ele não me conhece.... Kkkk....
Eu jurava que tinha vazado eu kkkkk
Trabalho numa consultoria que resolveu medir nossa performance pela adoção de IA. 😅. Pergunto pra ia até como faz pão pra garantir meu PLR
O problema do hiper foco é que a gente perde o horário de todo o resto, eu esqueço de comer, atraso o banho em várias horas, pulo o dia de treino porque está tarde demais e a academia já vai estar cheia, enfim... Quanto mais features/resoluções de bug interessantes menos qualidade de vida eu tenho kkk Aí preciso me forçar a sair da frente do Pc e fazer outras coisas, mas o código ainda fica rodando na mente kkk
As vezes tenho medo da nossa profissão e como ela faz nos sentirmos. Me identifico com suas palavras e de Lucas.
@@henriquesenadev2194 tbm tenho medo, já flertei com o Burnout inúmeras vezes.
Acontece exatamente o mesmo comigo 😅
Você literalmente me descreveu.
A academia ajuda muito nisso, tenta focar pelo menos nela. Eu consegui gerenciar minha mente com a disciplina e o cuidado com a saúde.. e isso veio depois que firmei compromisso com a academia.
fic, o Tim tava macetando 3 empregos na gringa e depois indicou o amigo que escreveu a materia.
Duas coisas mudaram minha carreira:
1. Dormir bem;
2. Foco.
Eu era desfocado... Queria fazer trocentas coisas ao mesmo tempo.
E tudo mudou quando resolvi matar os problemas por partes e de maneira altamente focado.
*Não é você que tem hiperfoco... Foi a área que te fez ser assim.*
Não tem jeito: desmontamos bombas. Cortar o fio certo com pressão do tempo.
Duas coisas mudaram minha carreira:
900mg de Lítio todo dia
@@MatheusGambati E a segunda qual foi?
@@ncn32 200g de cocaina por dia
tudo isso pro Tim rodar no próximo layoff da empresa por conta das métricas individuais.
Todo mundo sabe no time quem são os devs bons e quem são os ruins, se o líder é técnico e bom ele também vai ter essa leitura facilmente sem precisar de qualquer métrica
true
mas o VP indiano só sabe olhar um dashboard de merd4 no salesforce
Eu quando começo a programar começo a pensar no problema da informação durante o colapso da função de onda em um sistema quantico e depois me lembro que preciso terminar esse crud…
"Ponto não é prazo"
Maior clickbait da história.
pra VOCÊ mensurar a SUA produtividade beleza, mas como seu GESTOR mensura a sua produtividade em números? Não do time, mas de um individuo específico, fiquei com essa duvida, vejo que isso é de grande dificuldade para a maioria das empresas que eu trabalhei. Tem times que entregam, mas tem pessoas nesse time que estão lá apenas morcegando e pegando a onda junto com o time. Como um gestor identifica esses malandrinhos?
como medir produtividade numa area criativa e não uma industria amigo, pelo que o programador criar o problema e o gerente não saber nada de programação
Na empresa que trabalho, a galera sempre insiste em pontuar as tasks no Jira. Nunca entendi isso, esses pontos de complexidade nem fazem sentido.
Vou pontuar uma task baseada no que? Na dificuldade dela? Beleza, como vou medir a dificuldade da task?
Por tempo? Como vou saber quanto tempo vou levar para finalizar a task? Não tenho bola de cristal.
Esses pontos de complexidade nada mais são do que bullshit, um grande perda de tempo ou uma ilusão para o time pensar que está medindo o trabalho que está sendo entregue.
Não entendo porque não deixam toda essa besteira de lado e só passam a fazer as atividades normalmente.
Falando sério, o PO ou PM passa as atividades para o time e os profissionais falam o que dá pra entregar nessa sprint ou não, não precisa ficar nessa besteira de pontuar as task. É algo totalmente sem sentido que não muda nada na Review.
Enquanto os times perdem tempo pontuando, deveriam já iniciar as atividades.
Existem métodos "objetivos" pra fazer essas medições de complexidade, como pontos de função. Agora se são precisos e justos é outra história... Pessoalmente tenho um ranço enorme de empresa que usa isso
Por isso que Scrum Master sempre vai ser um atraso pra qualquer empresa. Todo Scrum Master vai querer medir usando gráfico de burn down e essas métricas inúteis porque eles precisam justificar a presença deles ali (que todos sabemos serem irrelevantes pro andamento do projeto).
Eu ja tive boas e ruins experiencias com pontuações, mas sim se o PM ou o q vale não deixa os criterios claros de pontuação, realmente vai ser inutil. No projeto q eu achei bom, o momento de pontuação servia tbm para discutir um pouco sobre o projeto e a ferramenta(que era nova) q estavamos utilizando.E acho q se não tivesse essas conversas ia ser pior. Vale tbm deixar claro que sou cientista de dados e não dev, talvez com storys mt claras no que é para fazer não precise msm, msm achando q se bem feito pode ajudar novatos a entneder melhor os problemas gerais.
@@shimadabr pois é mano, penso se é uma medição totalmente abstrata baseada na visão individual de cada um, acho muito sem sentido.
@@antoniomarinho3228 então mano, minha critica não é em relação as reuniões de planning para explicar as atividades ou as histórias de usuário, mas sim as pontuações das atividades, sempre achei isso uma grande perda de tempo. Histórias de usuário e reuniões são é sempre serão importantes.
de fato essa é a parte mais engraçada do ágil, a maioria dos POs/PMs que estão usando agile e fibonacci ressaltam várias vezes que pontuação não é prazo, mas se você demora mais de um dia pra resolver uma tarefa de um ponto eles querem te matar hahahahahah
qual o nome do programa q tu usa pra desenhar as parada na tela?
Excalidraw
O grande problema do Agile é que virou moda, e os gurus de internet começam a vender cursos de 40h que te transformam em um "especialista". A profissão de agile coach, ou scrum master virou moda e pagando salários relativamente bons para pessoas mal capacitadas e empresas adotando ao agile por modismo resultam em uma metodologia mal aplicada. Quantas vezes vi empresas usarem modelo "spotfy" ou o famoso "cascágil" (agil somente até vir uma ordem de cima que chega em forma de cascata e atropelando todos os processos). Isso fez com que a metodologia que tem como objetivo aumentar a produtividade acabar sendo apenas um playground de ritos e cerimônias que perderam o propósito.
Qual e o site que ele usa pra esses desenhos ? Essas explicações ficam tão boa
Acredito que seja o excalidraw
O Agile está tendo que lidar com as decisões que ele influenciou. E agora?
Então me diga aí @LucasMontano:
Tenho uma empresa e quero abrir um setor de desenvolvimento, demanda de cliente ou qq coisa que haja a necessidade.
não sou de programação, não entendo nada de programação, não sei como funciona, não sei nem quando um ; tem que ser Colocado no fim da linha ou não. como faço para avaliar se tenho devs produtivos ou só estou desperdiçando? como faço pra ter indicadores que me sirvam (alguém que não é programador e não sabe o que é uma PR) pra saber se tem um dev mais carregado ou se tem algum de preguiça enquanto o coleguinha leva sozinho. Que sistema uso? como faço pra avaliar?
Se for fazer algo estruturado contrata um gerente de TI, ou um tech lead.
Se for fazer algo mais precário, saiba que implementar medição desempenho de DEVs vai atrasar o desempenho dos DEVs. Dá um problema pra cada um e manda eles se virarem que é melhor, se alguém travar em um problema vc passa o problema dele pra outro dev e passa uma nova tarefa pro dev travado, assim vc vai vendo quem resolve os problemas e quem não resolve.
Cara eu sinto muito isso, quando uma tarefa se torna mais complicada do que eu previ eu tendo a ficar loucamente focado nisso! Do contrario me sinto um merda
Lucas na tirinha ele disse que iria "escrever uma minivan pra ele" ou seja ele iria gerar bugs o suficiente pra comprar uma minivan
hora de all mosar
Eu acho que os gestores deveriam reciclar o próprio conhecimento da area deles e achar meios mais efetivos de avaliar equipes de software. Não dá pra tratar equipe de engenharia de software igual um grupo de trabalhadores de linha de montagem, porque pra mim é isso que parece. Esse modelo é atrasado e não se aplica pro software. Acredito que a qualidade do software é entregar o que o cliente pediu, o que tá no requisito e se o cliente está satisfeito com o produto que ele tem... E principalmente ter um bom suporte, caso ocorra alguns bugs pontuais.
Eu tbm sou assim de "entrar no flow" pra medir a produtividade. É bem como se tu entrasse numa salinha e só existisse vc e a task, e parece q tu sabe exatamente como cada byte ta sendo usado kkkk
Mas tem dia, semana, q não da pra entrar no flow e tem q entregar mesmo assim. Sao as entregas q mais fico inseguro mas costuma dar bom mesmo assim
Seguramente se fizerem como o Lucas Montano, vocês estão ferrados.
O Boss tá com bolso cheio e nem o conhece.
Você deve faturar até uns 15k a cada 30 dias. Mas, seu Boss uns 2 milhões...
E aí, vale a pena se desgastar com hiper foco por 15k?
Seja esperto, enriqueça...
Lucas você pode colocar o link para os artigos na descrição do vídeo quando faz esse estilo de react?
Na minha humilde opinião o método de medir se o dev tá produtivo ou não é literalmente a produtividade.
Ver o que o cara entrega ou não. Na pratica. Não olhando números somente, mas olhando as soluções ou correções ou no que ele participa na equipe enquanto a produtor de soluções.
Não é algo simples de se medir em números.
É algo que um lider, uma gestão que estão na equipe, que fazem parte do time, precisam estar lá vendo acontecer para poder falar sobre isso.
Um obs aqui...
O pior dev que eu conheci era um cara que era de infra e foi posto para codar.
Ele recebeu uma promoção no trabalho.
O cara era mal educado. Chato, vivia achando jeitos e motivos para discutir.
Nunca estava disponível para resolver problemas. E nem para falar sobre eles.
As soluções que ele entregava, no inicio por estar iniciando na area , eram mais simples.
E depois foram ficando mais complexas, como esperado.
Mas todas, sempre , vinham com algum defeito.
Defeito esse que ele brigava muito para corrigir ou empurrava para outros fazer por ele.
Mas se ele era assim, qual motivo de ele receber promoção?
Ele era "amiguinho" de uma panelinha que tinha no setor.
A gestão do setor, e também da firma, gostavam muito dele enquanto pessoa, porque com eles, ele era muito divertido e brincalhão.
Churrascos, almoços, passeios aos finais de semana, tale coisa.
Por essas coisas eu ODEIO o famoso QI.
Porque até hoje com 18 anos de TI eu nunca vi alguém que entrou de QI em algum lugar prestar para alguma coisa além de gerar problemas.
cara, talvez medir por um número não funcione em alguns casos, mas se funcionar em 90% dos casos e não em 10%, pra empresa pode ser vantajoso (o time geralmente tem acompanhamento de um coordenador, não vai conseguir fatiar uma task simples em outras 10 só pra bater meta, os gestores não vão deixar, pode acontecer mas vai ser a minoria das vezes), pensa por exemplo em uma IA olhando seu currículo, muitas vezes ela pode descartar currículos bons e cometer erros, mas não significa que considerando toda amostragem ela não foi produtiva, ela olhou 1000 currículos bons e te deu 800, errou 20%, em vez de uma pessoa que olha 10 e te traz os 10 certos, acertou 100% mas pra uma grande corporação isso não escala.
tem muito desenvolvedor ruim sim (inclusive tem muito mais ruim do que bom), principalmente em consultorias e com essa história ai de o cara aprender em 6 meses ignorando tudo quanto é fundamento, acho que um número pode não ser absoluto mas ele pode ser um alerta para você ir lá e conferir, fazer uma avaliação mais profunda, acompanhar, etc...
Entenda, a vida é muito complexa, geralmente extremos sempre estão errados, "Nunca faça isso", "Sempre faça aquilo", geralmente esses 2 estão errados, e o correto é algo mais próximo ao meio termo, monitorar números sim, usando o que eles tem de bom, mas também usar outras abordagens, como acompanhamento, feedback de outras pessoas do time, etc...
Na minha carreira já vi diversos caras que eram ruins mesmo, e se sustentaram ali por 2 ou 3 anos atrapalhando a performance do time por falta de acompanhamento individual, as vezes deixa de pagar um salário melhor pro cara que tá carregando o time ali pra manter um desses.
Falta de acompanhamento é ruim pro cara que é bom também, ele fica dependendo exclusivamente do chefe dele ver ele, se seu chefe não tiver a capacidade de te enxergar se tá lascado, vai ficar 4 anos no mesmo cargo, se tem algo mais concreto para acompanhar pode ajudar na visibilidade, e isso não depender somente da "percepção"/"feeling" de alguém...
Já vi cara que codava como júnior ser promovido a especialista, no lugar de outro que era um monstro do código (e também de resolver problemas no geral), só por "parecer" bom, falar "bem", ter mais tempo de "experiência", medir por um número nesse caso seria muito mais justo, pois no fim a decisão pareceu aleatória embasada em achismo, um era superior em todos os números entregava 20 task complexa por mês, o outro não mostrava nada, só tentava se aparecer pra diretoria nos momentos oportunos, tanto que depois ele acabou sendo demitido justamente porque não tinha conhecimento necessário para o cargo que foi colocado, só "parecia ter"
Sobre medir pessoas, especialmente com métricas de vaidade: PESSIMO
Cara, sempre quando falam de Agil, me dá uma dor. Como dev, saber da historia do manifesto e os por ques, é interessante!
Fica a sugestão ai! pq tem muito conceito errado ai sobre o Agil.
O que aconteceu com o agile: DESVIRTUADO!
Explico. O manifesto partiu de desenvolvedores, com ideias para resolver problemas vivenciados por eles no modelo anterior. E o manifesto começou a ser seguido por outros devs. Entretanto, aos poucos foi sendo desvirtuado, à medida que outros processos foram sendo trazidos por não devs. Estes, interessados em GERENCIAR melhor os times e ter visões de PROGRESSO. Não que sejam ferramentas ruins, mas que não só não encaixaram bem, como foram sendo cada vez mais usadas com foco no lugar errado: tentar tirar uma visão de prazo e produtividade, meio que à todo custo. E mais uma vez, o objetivo de quem paga os salários, é compreensível. Mas, as ferramentas usadas, não são exatamente as melhores e isto só está ficando cada vez mais CLARO.
Enfim, estamos aprendendo com o que deu errado. E logo surgem coisas melhores, que vão resolver alguns problemas e trazer outros. Vida que segue.
Produtividade é quantidade de funcionalidades entrega sem retorno de bugs. Não adianta fazer 10 funcionalidades sendo que 8 retornam para correção. É mais fácil entregar 6 funcionalidades bem entregues
Falácia detectada. A premisa de un proceso adaptativo é falha somente fora do sprint. Enquanto estivermos dentro de um sprint é preciso seguir o objetivo do sprint ou cancelar-lo. Falha poderia ser construir (queimar story points) algo errado e planificar o próximo sprint diferente com base a feedback e review con cliente ou baixa adoção. Ou seja se o team é improdutivo ou não entrega agile tem pouco a aportar. O propio SAFe visita teorias do management tradicional para corrigir baixa performance.
Uma coisa que funciona comigo, e me ajuda muito. Primeiro organizar todas as tasks mentalmente, segundo, pego post it's e coloco em cada post it o que está na mente, terceiro priorizo esses post-it dependendo do contexto, velocidade e preguiça das tarefas. Por fim quando estiver organizado só olho um post-it por vez, e não me preocupo mais pq foi pensado antes na organização. E vou tirando os post-its a medida que for fazendo. A cabeça funciona, vejo isso.
Eu faço isso só que no Trello
Trabalho com recrutamento e seleção e concordo com todas suas dicas! Currículo inglês no Brasil não é bom, pois muitas vezes quem tria seu currículo não sabe o idioma, ou então usamos palavras chaves que não irão te encontrar dessa forma. Por ler mais de 100 cv em um dia, realmente passamos os olhos rapidamente, é inportante contar sua experiência de uma forma rápida e que chame a atenção. E aqueles tracinhos para dizer nível de idioma também odeio kkkk Enfim, cada dica sua foi essencial! Vim parar aqui por estar em transição de carreira, mas não pude deixar de dar minha visão profissional rs
Dev criando 10 KPIS medindo a produtividade da empresa inteira : OK
Vamos medir a produtividade do dev: aaaah não mas não dá pra medir produtividade do dev BLA BLA BLA
Sei la, eu utilizei muito a review de PR para ver se o dev estava melhorando ou nao. Tu via o primeiro PR do camarada, era aquela aberraçao. Depois de algum tempo, os proximos PRs começaram a ficar melhores, codigo com mais qualidade, testes, seguindo os standards do projeto. Acho que é a melhor forma de avaliar se o cara ta melhorando ou nao. E o gerente confiava em mim pra dizer se as pessoas estavam fazendo o que devia fazer ou se estavam ramelando.
Tambem ja tive o camarada que começou falando que era o saci de patinete e no final das contas era o curupira com os pés virados pra frente, nao fazia nada, nao entregava nada, passava as atividades dele pra outra pessoa resolver. No final das contas, o cara tinha parentesco com algum diretor da empresa, ninguem sabia disso, mas ficamos sabendo quando o time pediu a demissao do cara. Ai ele ficou la, dava uma pbi pra ele ficar o mes todo e nao resolver, jogando pra proxima Sprint.
Respondendo a pergunta final do vídeo: Agile virou microgerenciamento de estimativas que viraram prazos para desenvolvedores. Não faz sentido, né?
Agile deveria ir até a parte de dividir as grandes tarefas em tarefas menores e ponto final.
3:47 Caraca! O Lucas Montano do Canal do Lucas Montano me definiu. Vou até mostrar esse vídeo pra minha esposa kkkkkkkk
A melhor métrica é a da beleza.
Quanto mais desgranhento, mais produtivo.
Uma coisa que eu fico me perguntando é: "Por que ter tanta engenharia pra resolver uma task?" Nao poderiamos só ter uma lista com feito ou nao feito e pronto ? Pra mim isso é mais atraso do que solução.
Gosto de fazer previsão de que vou fazer e um mini relatório diário . Para minha pessoa foi o melhor jeito de ter o controle de produtividade, uso isso tanto na carreira quanto no meu robby de desenhar.
03:35 a sensação desagrável de começar uma tarefa e não terminar se chama Zeigarnik effect th-cam.com/video/LnJaqT5hAik/w-d-xo.html&pp=ygUQWmVpZ2FybmlrIGVmZmVjdA%3D%3D
1 commit por linha
1 pull request por bug corrigido
Logo melhor DEV
Esse gráfico me assombra
Esse gerador de bornout é a qual eu me encontro em 2 dos 3 times em qual atuo, ta me dando calafrios isso KKKKKKKKKKK
Caralho, esse lance de objetivo e OKR é como funciona onde trabalho
consultancy é uma merda, seja dev, suporte ou sei lá o que mais... é burnout na certa
cara gosto muito de vc, mas pq vc fica fazendo video reagindo a post irrelevantes de gente emocionada ? dando palco pra esse lixo eletronico de linkedin
Não existe nenhum trabalho parecido com a dinâmica de desenvolver, se levar pra engenheiro pior ainda. É um trabalho extremamente dinâmico e os resultados dependem também da área de produtos/negócio. Você pode no máximo levantar métricas para entender se os times melhoraram ou não e a longo prazo. Ainda assim corre o risco de errar justamente pela dinâmica que é o trabalho, é tipo prever o valor da ação de um papel na bolsa.
😅😮😅😅😮😅 😊
Já vi esse gráfico estranho em outros locais como por exemplo na barra de progresso de uma atualização, carregamento de leitura de um grande arquivo, tempo de previsão de um backup e entre outros, geralmente esta associado a previsibilidade temporal de um arquivo vs de múltiplos arquivos. Mas como na natureza se algo é observado em uma situação pode ser observado em outras com um certo grau de similaridade.
aqui vai um conselho também que é totalmente pessoal: cuidado com a régua que se cria para medir produtividade.
muitas vezes criamos réguas que não atingimos no final do dia e isso acaba com nossa mente.
acabei demorando pra entender que eu fazia isso e eu acabava me martirizando demais no fim do dia, e isso é resultado desse pensamento. dessa régua que muitas vezes era impossível de atingir.
impossível porque cada dia é um dia. cada dia você ta com um humor diferente, vão ter dias que você vai tar produtivo, outros menos. entender que você é totalmente plausível de oscilações, é respeitar a si mesmo e muitas vezes não cair num burnout.
Eu prefiro ter um foco em algo menor/mais plausível e produzir acima, deixando aquela ''gordurinha'', do que me frustrar tentando algo mais difícil que no final do dia eu mal tive progresso.
E se é algo mais difícil, eu preparo minha mente e aceito que vai ser difícil e tá tudo bem.
@@psyab9375 mesma coisa aqui. Com esse pensamento, melhorei demais os meus dias.
Alguém sabe o nome da ferramenta que ele usa pra ir desenhando? Gostei bastante.
Iiiii rapaz, acabei de almoçar 😢
ESPOOOOCOOOOOOOO !!!!!!!!!!!!!!!!!!!!!!!! ESPOCO TUDO MANO
algem sabe o programa que o lucas usa para fazer os desenhos na hora da explicação?
essa lista de subtarefas eu to tentando quebrar no jira a US em subtasks descritas mesmo antesde começar a codar
Quando eu digo que programador é pedreiro digital, o pessoal me critica
Eu que não sou besta crio uma task pra mim mesmo quando fico horas em pair programming
Estão querendo atribuir na minha empresa o método de chamados para medir a produtividade.
Guia para gestão de escopo/prazo no Scrum:
1 - Ponham essa frase na sua cabeça e na do seu SM/GP pangaré: "O prazo dessa userstory é duas semanas". Repita como um papagaio: "- E dessa aqui? - Duas semanas.", "- E dessa aqui? - Duas semanas.", "- E dessa aqui? - Duas semanas.", "- E dessa aqui? - Duas semanas."
2 - Se a atividade parece que vai durar mais de duas semanas, divida em pedaços que façam sentido durar duas semanas. (Use o bom senso)
3 - Se todas as tuas atividades da sprint te derem a impressão que "não dá pra fazer tudo isso em duas semanas", entregue algumas para outra pessoa ou para outra sprint. (Use o bom senso)
4 - Use o bom senso. (Use o bom senso)
5 - Repita. (O bom senso é opcional)
Que papo gerente de consultoria...
Esse lance de ficar irritado por ser interrompido acontece muito comigo.
Se der TD errado no dia, o Montano pode dizer: na minha cabeça funciona.
1 - burnout (burndown) é o famoso quanto pipi cabe no seu popo ainda.
KKKKKKK todo mundo quer ser um floquinho de neve especial
Que software é esse que o Lucas usou para rabiscar e fazer exemplos?
O que aconteceu com agile? Homeoffice nao combina com reuniao o tempo todo kkk
Ufa, achei que tava falando de mim,
não foi desta vez
O problema nao e ser ruim. O problema e ser o pior de todos. KKKKK
Lucas, pelo amor de Deus, para de falar commit dessa forma :D
a cada video que passa o Lucas fica mais laranja ou eu tô ficando louco?
Amigo, que app é esse que vc usou para desenhar?
Eu, Eu, Eu, Eu, Eu, Eu, Eu, Eu, Eu....
E esse olhos vermelhos? Ainda na Holanda?
Obrigado pelo conteúdo.
Ameeeiiiiiii não tem nada mais verídico
Qual é essa ferramenta de quadro negro que ele usa?
Já vi a porr4 desse gráfico demais
Solução. Scaled cabeça do Lucas.
Muitos falam de produtividade olhando para a eficiência, mas nunca vi associar à eficácia. Alguém aqui tem métricas de eficácia? O PO/PM sabe priorizar? Sabe qual ponteiro na empresa será mexido? Mede a eficácia e deixa claro para empresa? Conhece o impacto da não entrega? E o time to market? São perguntas que não vejo ninguém fazer, mas buscam resultados em commits...Muitos falam de produtividade olhando para a eficiência, mas nunca vi associar à eficácia. Alguém aqui tem métricas de eficácia? O PO/PM sabe priorizar? Sabe qual ponteiro na empresa será mexido? Mede a eficácia e deixa claro para empresa? Conhece o impacto da não entrega? E o time to market? São perguntas que não vejo ninguém fazer, mas buscam resultados em commits...
Salve Lucas! Qual a sua cadeira, meu mano?
Eu tenho hiper-foco ao ponto de, ao término do flow, eu ter que ir ao banheiro quase que ajoelhado, por causa da bexiga cheia, com vontade de fazer xixi. Se minha mente está bloqueada, eu coloco Iron Maiden e AC/DC no último volume no meu SubWoofer enquanto pego novamente a tarefa ... são gatilhos que funcionam pra mim!
Não me mato por nada.
Tarefa é uma por vez com foco em resolver e pronto. EU FECHO TODOS OS OUTROS PROBLEMAS.
Focar em uma coisa só te deixa menos ansioso e sobrecarregado, fora que a liberação de dopamina e satisfação de resolver aquele pequeno problema te dá impulso para resolver o próximo e assim vai.
Toda vez que eu tentei abraçar o mundo, terminei com burnout (inclusive tendo que ficar internado no hospital).
Metricas de pontos deveriam ser utilizada somente para auxiliar no planejamento de uma.sprint. Eu utilizo de forma pessoal e consigo ter uma boa noção de quantos Story Points eu entrego por semana e tenho uma boa noção de quantas tarefas posso alocar.
Agora, medida de produtividade é outra coisa e depende de fatores subjetivos. Acho que a pior coisa é quando comparam story points entre DEVs. "Fulano entregou 10 story points a mais que vc" é uma frase inútil.
Me identifiquei e sou de infra
Legal demais essa análise. Eu trabalhei em empresa que vincula objetivos das sprints a OKRs. O grande problema é a distância entre os OKRs (nível estratégico) ao objetivo da sprint. A relação é tão distante que o time dev não se importa. Simplesmente não se vê inserido no contexto.
Não pode ser gerenciar o que não se mede…
Cara isso que você falou no minuto 4:00 , acontecia muito comigo, eu sempre ficava dessa maneira e fazia exatamente a mesma coisa, saia de frente da tela do notebook, ia tomar um suco ou café, abraçar minha esposa ou tentar puxar um assunto aleatorio, pois eu sempre ficava muito extressado quando não conseguia resolver algum problema que eu via que era simples ou era nescessario finalizar até o fim do dia.
no minuto 8:00 , trabalhei no banco do brasil por mais de 2 anos e lá usavamos esses pontos e a equipe que eu estava sempre batiamos os pontos que a scrum colocava para a equipe, sempre tinhamos algo pra mostrar pro PO
Burn - nout - down da Sprint.
Basicamente o Exposed de quem está assumindo mais complexidade do que outros.
Quem nunca sofreu com isso, não sabe o que é pegar um ticket de 8 mal esclarecido ou um ticket de 13 que deveria ter sido quebrado/dividido em pequenas/médias partes...
Eu só sigo o canal dele por causa do cabelo dele :D
Você me conhece e eu não sabia😂
Lei de Goodhart: "Quando uma medida torna-se uma meta, deixa de ser uma boa medida."
Isso acontece porque, ao transformar uma métrica em objetivo, as pessoas passam a agir de forma a otimizar essa métrica específica, frequentemente através de distorções e manipulações, em vez de se concentrar no real propósito ou no resultado desejado. Existem diversos exemplos em inúmeras áreas, e além dos mencionados no vídeo, um exemplo clássico é usar o número de homicídios de uma região como meta de redução de violência, o que costuma causar a própria polícia movendo corpos de região para não afetar os números da própria região, ou seja, os homicídios não diminuem de maneira prática mas os números são distorcidos por serem considerados como meta, em vez de serem aplicadas políticas eficientes e relevantes para lidar com violência.
O que ele usa pra fazer esses desenhos?
vídeo fresquinho
No SAFe é assim, inclusive é possível vc definir o OKR de forma bidirecional. Negócio define objetivos e épicos virados para um caso de negócio sólido, o time dev e demais recursos do programa elaboram a estratégia de entrega e definem com o negócio os critérios de DoD e DoR. A entrega bem sucedida em ambas as frentes representa o sucesso e o throughput fica menos bagunçado do que tentar medir tempo/entrega só com esses pontos dos infernos.
Convivo com bournout diariamente bhaa ta loko...sou pesquisador e fico escrevendo quase 19 horas sem parar, mas não consigo pegar esse hiperfoco lucas, parabéns para ti..
Eu trabalhei com um aspira que veio da policia, e após alguns poucos meses com outro programador sênior, o qual ele fez amizade, o aspira já achava que sabia tudo, criticava meu serviço, lembrando que o sênior era php, e eu trabalhava com javascript e seus frameWorks e supersets agregados, o cara falava mal pra caramba das técnologias que eu usava, olha que eu já com 9 anos de experiência, o cara era super ruim de serviço mas achava que não, até que uma vez, o gerente de projeto passou uma simples tela pra ele fazer, e consumir uma rota da Api, ele ficou uma semana quase e não conseguiu, foi então que o gerente pediu pra mim fazer, e naquela mesma manhã eu fiz a tela, e entreguei os cards daquela tarefa, e mesmo após isso, não sei que diabo de cegueira, o comportamento dele de orgulho foi só piorando.
Ja trabalhei muito tempo com mensuração de performance de times de desenvolvimento, o que mais faz sentido hoje em dia é a abordagem de dora metrics, recomendo a leitura sobre. Nessa empresa que trabalhei, quando eu entrei eles mensuravam linhas de codigo... no final terminamos com dora metrics, foi super produtivo.
ta me explanando ai bro
Um grande engano é achar que o valor dos pontos de uma tarefa diminui só pq alguem da equipe ja fez/aprendeu a fazer. A nivel de métrica vai fazer sua equipe a entregar menos pontos cada vez mais. Metrica realmente é muito chato. Penso que o ideal seria medir o valor entregue a organização,o quanto aquela equipe colaborou para fazer a empresa perder menos dinheiro ou aumentar o faturamento. 😊
Qual esse app que ele desenha?