O caso em que menti para o CTO e escapei da crise
(GrumpyOldDev.com)- Um grande projeto para um cliente importante de uma empresa da Fortune 500 começou com dependência de um produto de fornecedor, mas na prática era um software quase semiacabado que exigia customização pesada
- A integração com o fornecedor acabou reunindo ao mesmo tempo as desvantagens de um pacote inflexível e do desenvolvimento sob medida, levando a uma marcha da morte de integração para tentar cumprir o lançamento de outubro após a entrega em agosto
- O design que armazenava todas as transações do cliente em um único documento JSON gigante criou problemas de desempenho, e o limite de 16 MB por documento do MongoDB na época se revelou uma limitação fatal na migração de dados reais
- A empresa escondeu o problema do cliente e do fornecedor, atrasou o lançamento em um mês e, com uma equipe interna de 3 pessoas, fez uma reescrita skunkworks para substituir a integração do fornecedor em cerca de 2 meses
- Quando o CTO ordenou trabalho durante o feriado pouco antes do Natal, o líder da equipe relatou como se tarefas já concluídas ainda estivessem em andamento para deixar os desenvolvedores descansarem, e a equipe conseguiu cumprir os testes de janeiro e o lançamento
Um projeto mal concebido que começou com um produto de fornecedor
- Em uma empresa da Fortune 500, o CTO prometeu entregar um grande projeto para um cliente importante com quem tinha relação pessoal
- A parte central foi terceirizada para uma grande empresa de serviços de tecnologia, e o fornecedor afirmou ter um produto que faria a maior parte do trabalho pesado
- Na prática, o produto só correspondia de forma aproximada aos requisitos, então era necessária uma customização intensa para obter o comportamento desejado
- Como resultado, surgiram ao mesmo tempo as desvantagens do software do fornecedor e do software sob medida
- Virou um pacote inflexível que precisava ser forçado a fazer algo diferente do propósito original do seu design
- Foi derivado do codebase principal do fornecedor, aumentando o custo de manutenção e criando também a possibilidade de ficar sem suporte no futuro
- As pessoas envolvidas no projeto viam que essa abordagem não era boa, mas como a linha de reporte direto ao CTO mudava com frequência, as reuniões de status acabavam no estilo “boa ideia, chefe”
Atrasos no cronograma e uma estrutura de dados fatal
- A equipe interna de desenvolvimento construiu internamente outras partes do projeto, enquanto o fornecedor prometia durante todo o verão que o produto logo estaria pronto para integração
- Quando o produto do fornecedor foi entregue em agosto, começou uma marcha da morte de integração com meta de lançamento em outubro
- Em setembro, surgiram bugs graves o suficiente para impedir o lançamento
- O produto do fornecedor armazenava todas as transações do cliente como registros JSON dentro de um único documento JSON gigantesco
- À medida que os dados de teste aumentavam, o desempenho ficava cada vez mais lento
- Cada nova transação era adicionada lendo o documento JSON inteiro do banco de dados e anexando o novo registro ao final
- O fornecedor disse que isso poderia ser corrigido adicionando índices aos campos das transações, e por um tempo isso pareceu ajudar
O limite de 16 MB do MongoDB e a reescrita escondida
- O problema maior era que o banco de dados escolhido pelo fornecedor era o MongoDB, que na época tinha um limite de 16 MB por documento
- Em outubro, quando a equipe de migração começou a inserir dados reais de clientes, passou a esbarrar nesse limite de 16 MB
- A empresa decidiu iniciar a operação com um mês de atraso sem revelar essa limitação ao cliente
- Ao mesmo tempo, iniciou um projeto skunkworks para substituir a integração do fornecedor
- Nem o próprio fornecedor foi informado disso
- Na prática, a situação crítica foi escondida tanto do cliente quanto do parceiro tecnológico
- Originalmente, cerca de 70 pessoas estavam alocadas pelo lado do fornecedor, mas apenas 3 foram designadas para o trabalho interno de substituição
- 1 para o design do banco de dados
- 1 para construir o backend que interagia com o banco de dados
- 1 para construir a lógica de negócios e os serviços web
A decisão pouco antes da marcha da morte de fim de ano
- Foi informado ao cliente que uma nova versão para testes seria fornecida em janeiro e que corrigiria os defeitos mais críticos aceitos no início da operação
- Mas o cliente não foi informado de que, na prática, todo o sistema central estava sendo reescrito em cerca de 2 meses
- O projeto original levou mais de um ano até o lançamento, mas a reescrita teria de ser feita por 3 pessoas, incluindo o período de feriados
- Em meados de dezembro, os participantes do projeto foram informados não por pedido, mas por ordem, de que haveria trabalho durante o feriado
- A maior parte da equipe já estava em burnout após trabalhar de 60 a 80 horas por semana por 6 meses
- Lançamentos de software trazem uma pressão e uma recompensa parecidas com as de um espetáculo ao vivo
- O resultado de meses ou anos de preparação chega aos usuários reais no dia do lançamento
- O desenvolvedor sente um forte senso de realização no “eu consegui” e na reação dos usuários
- Um lançamento de software pode parecer um show ao vivo para pessoas introvertidas
A semana em que menti para o CTO e deixei a equipe descansar
- Perto do Natal, a equipe de 3 pessoas já tinha praticamente concluído o software de substituição em um mês
- Ainda restavam funcionalidades para finalizar, mas, se a equipe não entrasse em burnout, estava em condições de cumprir o cronograma de testes de janeiro
- Quando o CTO ordenou o cancelamento das folgas de feriado, o líder da equipe respondeu “OK” publicamente
- Na prática, disse aos 3 desenvolvedores: “Tirem uma semana de descanso. Eu resolvo isso.”
- Todas as manhãs, o líder participava da reunião obrigatória de status e reportava ao CTO como se trabalhos concluídos no mês anterior ainda estivessem em andamento
- “A equipe está trabalhando duro. Hoje chegamos ao marco de integração #73”
- “Ontem a equipe avançou bem e concluiu mais um serviço web”
- Uma semana depois, os desenvolvedores voltaram revigorados
- A equipe cumpriu o cronograma de janeiro, fez um bom lançamento e, por um breve momento, se sentiu como uma banda de rock
- Ao relembrar, diz que a sensação foi mais próxima de Herman’s Hermits do que de The Beatles, mas ainda assim foi boa
1 comentários
Opiniões no Hacker News
Se você é alguém que cancela férias e continua trabalhando por ser “orientado a prazos”, falando por experiência própria, eu diria: pare de ser idiota
É especialmente difícil parar quando seu esforço é reconhecido, mas no fim você vai se arrepender de todo esse tempo
Se a empresa tem uma estrutura em que acha natural usar os feriados e férias dos funcionários para vender o produto, isso contribui para criar o mundo problemático em que vivemos hoje
Se muita gente faz isso, mais gente terá de fazer; se ninguém fizer e todos agirem como se esse tipo de exigência fosse absurda, a empresa passará a fazer estimativas realistas, ainda que isso doa no bolso do CEO
Avise sobre seus planos de férias, providencie alguém para cobrir você, coloque no calendário da equipe, faça a transição e simplesmente descanse
Projetos vêm e vão, e cronogramas às vezes escorregam por conta própria
Se você começar a remanejar férias para se adequar ao cronograma de projetos, nunca mais vai tirar férias na vida
A exceção seria em funções em que períodos movimentados são claramente conhecidos, como fim de ano, fechamento de trimestre ou temporada de impostos, e seria inadequado desaparecer nesse período
Meu primo trabalhou quase todos os dias até 1h da manhã, de setembro de 2023 a janeiro de 2024, para concluir um projeto pessimamente gerenciado, e só folgou no Natal — e mesmo assim porque era um feriado religioso e o diretor autorizou por medo de os funcionários processarem
Ele perdeu eventos importantes e emagreceu cerca de 20 libras por causa do estresse
A empresa tinha um prazo apertado para migrar para um novo sistema e, embora soubesse disso havia cinco anos, não começou até o ano anterior
Se não cumprissem o prazo, enfrentariam milhões de dólares em custos fora do contrato; no fim, a equipe cumpriu o prazo, mas a recompensa, algumas semanas depois, foi uma demissão sob a justificativa de que o cargo havia sido eliminado
Agora, com mais de 50 anos, ele está procurando emprego no pior momento possível
Eles ficam viciados em se sentir valiosos e importantes, e não têm muito o que fazer quando saem do trabalho
Em alguns casos, o funcionário premiado também tinha parte da responsabilidade pela bagunça
Só lá pela quarta vez é que os executivos na sala perceberam que a empresa tinha problemas estruturais
Se houver pessoas jovens lendo isto, o fato de histórias assim seguirem esse rumo depende muito da empresa e da sorte
Em uma empresa saudável, é bem provável que a própria abordagem de terceirizar a implementação nem tivesse começado
Isso porque é um padrão de fracasso óbvio demais, cujo resultado alguém experiente conseguiria prever antes mesmo de começar
Mais cedo, as pessoas não teriam mentido ao CTO dizendo que estava indo bem; teriam dito que não estava
Se fosse necessário um caminho mais inteligente ou criativo para salvar o projeto, isso teria sido ajustado junto com o CTO e talvez até com o cliente
Também não teriam pressionado a equipe, já em burnout, a trabalhar longas horas durante feriados
Um gerente ou líder enfrentaria a hierarquia em defesa do sucesso do projeto e da saúde da equipe e, se necessário, argumentaria que a equipe precisava descansar no feriado
Em uma organização “meio saudável”, um gerente pode agir deliberadamente de forma ambígua ou omitir informações, e se isso é bom ou ruim depende da situação
Mas, como nesta história, se um gerente ou líder mentiu de forma explícita e repetida para cima na cadeia de comando, isso normalmente é visto como algo muito ruim, seja a empresa saudável ou não
Claro que é muito mais fácil avaliar esse tipo de situação depois, de braços cruzados
Em posições difíceis ou sob excesso de trabalho, qualquer um pode errar, mas faz sentido observar e aprender com cenários assim para reagir melhor caso você seja jogado de novo em uma situação parecida e complicada
Se você está em uma empresa assim, é melhor começar a procurar outro emprego
Quando a corrupção no topo chega a esse nível, é impossível consertar, e eles também não vão transformar você em CTO
Em 25 anos de trabalho, nunca vi uma
Levou um ano e meio para consertar, e durante esse tempo não dava nem para reverter vendas porque “roupa íntima” havia sido enviada
Na realidade, não vendíamos roupa íntima, apenas serviços de rede, mas só podíamos ajudar o cliente depois que o sistema aguardasse o encerramento do fluxo do pedido
Esse membro do conselho saiu um ano depois e imagino que tenha ficado bastante satisfeito por ter enganado o CEO idiota
No fim, fui demitido de lá e não tenho nenhuma simpatia por aquela empresa atrapalhada
Eram idiotas tentando terceirizar a “solução” e só aumentaram o sofrimento de todo mundo
Há problemas que de fato precisam ser resolvidos, mas metade é lixo feito apenas para dar a sensação de “economizar dinheiro não desenvolvendo internamente”
No fim, você continua pagando custos de contrato para manter um lixo que nem foi você quem criou em primeiro lugar
Quero dizer dizer os fatos como são, sem esconder os problemas, e isso é realmente raro
Basta olhar para os memorandos de segurança da Microsoft
É verdade, até certo ponto, que não há death march em feriado se você trabalha em um banco ou em uma FAANG
Se a empresa tem “cultura de startup”, é melhor esquecer
Na prática, quando seus próprios interesses estão em jogo, a atitude em relação ao trabalho muda bem rápido, mas acho que não há muitas empresas em que você consiga ter e observar esse tipo de oportunidade
Muitas vezes fiz o que precisava ser feito no meio da noite, quebrando regras sem ninguém saber, e muita gente competente também seguiu esse caminho
Já vi isso até em bancos
Desde que você não faça uma aposta financeira maior que o valor da empresa ou da equipe, muita coisa pode passar batida
Ou você entrega e é promovido, ou reduz suas próprias chances de promoção e acaba procurando outro emprego
O trecho dizendo que “o produto do fornecedor armazenava todas as transações de clientes como registros JSON dentro de um enorme documento JSON e, para adicionar uma nova transação, lia o documento JSON inteiro do banco de dados e anexava o novo registro ao final” deve soar insano mesmo
De forma parecida, certa vez ajudei com a due diligence técnica de um possível investimento de um fundo, e a tabela de usuários da startup também continha os dados de tickets/reservas
Como cada ticket era uma coluna, se o usuário mais ativo tivesse 5 tickets em todo o histórico, eram necessárias 5 colunas
Quando analisamos, já havia mais de 500 colunas, e eles estavam buscando investimento para “escalar”
Claro que era um problema solucionável, mas, como era de se esperar, tudo tinha sido projetado de um jeito completamente invertido e distorcido, e esse foi o momento mais óbvio de “que diabos é isso?”
Eles não conseguiram o investimento
O banco de dados inteiro de clientes e produtos ficava armazenado, junto com senhas em texto puro, em um único arquivo
.jspúblico de vários megabytes, e, nas velocidades de internet do começo dos anos 2000, o app precisava carregar tudo antes de fazer qualquer coisaAlém disso, o app era um único arquivo gigantesco, e o diretório estava cheio de nomes como
index.1.js,index.final.js,index.newest.js,index.45.jsEu já tinha experiência suficiente para conhecer boas práticas, então fui até o CEO, fiz com que ele demitisse o CTO e comecei a refazer tudo com
git,mysql, lógica do lado do servidor e uma estrutura de verdadeDepois disso, o servidor Windows em que tudo rodava foi hackeado e virou um servidor de pornografia; eu nunca nem tinha visto aquele servidor e não tinha privilégios de administrador, mas, por algum motivo, a culpa caiu em mim
Os primeiros empregos foram realmente educativos
Um engenheiro sênior que se gabava de ter saído de Stanford projetou o sistema
Eu argumentei longamente, com base em dados reais de produção, que aquilo não escalaria quando fosse lançado, mas ninguém ouviu, e poucas semanas após o lançamento ele desmoronou
Logo mudei de equipe, e o pior é que esse engenheiro sênior acabou sendo promovido, enquanto o sistema foi passado para uma equipe completamente nova para que eles brigassem com ele
O design do sistema inteiro era horrível, e dá para imaginar por quê
Bajularam os executivos com jantares e viagens luxuosos, entregaram um produto desastroso e garantiram que continuariam sendo necessários no futuro
Pela própria história, o CTO não sabia de nada
Do ponto de vista dele, no fim tudo pareceu dar certo
Foi uma vitória para todo mundo, exceto para os desenvolvedores que trabalharam 80 horas por semana
Tudo nessa história está quebrado, inclusive a abordagem do protagonista
Um líder de equipe dar folga às pessoas e esconder isso com mentiras é totalmente inaceitável e entra bem no território em que a empresa poderia demiti-lo
Na prática, parece até caso de demissão por justa causa
Dito isso, a liderança parece tão fora de órbita que talvez deixasse passar e até o elogiasse
Parece uma ação adaptada ao ambiente em que ele estava
Meu conselho a novos líderes de equipe seria: não há nada aqui de que se orgulhar, e a escolha melhor é levantar um grande problema dizendo que as pessoas estão fazendo hora extra, e exigir que o fornecedor seja submetido a critérios normais ou que o escopo do projeto seja reavaliado para caber em uma semana normal de trabalho
Se você faz uma situação dessas “funcionar” de algum jeito, o único resultado pode ser pessoas entrando em burnout ou sendo demitidas, sem benefício algum
A menos que você esteja realmente desesperado para sustentar a família, um líder de equipe tem a responsabilidade de proteger as horas de trabalho razoáveis da equipe contra exigências malucas
Esse é o morro no qual se deve estar disposto a ser demitido, não o morro no qual se deve mentir
Portanto, se isso não afetou os resultados, é perfeitamente aceitável que o líder dê folga às pessoas e até minta sobre isso
Se tivesse sido compartilhado, o que a diretoria teria feito? Teria adiantado ainda mais o projeto
Quem tenta fazer os outros trabalharem ainda mais duro para a própria glória merece levar uma rasteira
Afinal, o dia de quem foi salvo?
O fornecedor ruim que entregou lixo?
O CTO que claramente se cercou de yes-men e não faz ideia do que acontece na empresa?
Os desenvolvedores que trabalharam até moer os ossos e receberam um “tudo bem, eu deixei vocês tirarem uma semana de folga, não deixei?”
O protagonista, que mentiu para todo mundo para cumprir um prazo arbitrário de uma empresa que não se importa com os funcionários?
Essa história me deu arrepios a cada momento
Eu sou do tipo que trabalha duro e, às vezes, faço horas extras para deixar uma entrega a um cliente mais tranquila, mas esta história é pura insanidade
Só aceito dedicar tempo extra de vez em quando porque existe uma relação de confiança com meu chefe, e sei que sempre posso dizer a verdade
Na verdade, esse é o conceito central de uma cultura sem culpabilização, e ela só é possível quando todos dizem a verdade
Mentir feito louco para cumprir o prazo de um CTO burro é literalmente insano
Se você estiver em uma situação assim, saia imediatamente e procure um emprego melhor
“Orgulho e sensação de realização” e burnout?
O “nós” em “também cumprimos o cronograma de janeiro, lançamos com excelência e viramos rockstars por um instante” claramente quer dizer eu
Pode ter sido sorte, mas nunca fui demitido por dizer a verdade, e a verdade era mais fácil de sustentar.
Algo como: “há um bug em uma biblioteca de terceiros no caminho crítico. Dá para tornar o bug mais difícil de acontecer, mas não dá para corrigi-lo antes que o fornecedor corrija”, ou “com o crescimento de usuários, problemas de desempenho apareceram antes do que imaginávamos. Enquanto levamos 2 meses para corrigir, podemos mitigar gastando o triplo em infraestrutura ou perder clientes por causa do desempenho”, ou “nosso maior cliente só descobriu o que queria depois de receber a primeira iteração. É completamente diferente do que achávamos que iríamos construir. Podemos construir isso e gerar receita, ou morrer correndo atrás de um sonho”.
De novo, talvez eu tenha tido sorte, mas a honestidade funcionou bem para mim.
Então, como outros disseram, diga que “vai analisar” e depois empurre aos poucos, ou coloque em tarefas braçais.
A segunda opção é ficar de boca fechada e vê-los passar um bom tempo sofrendo até fracassarem.
Normalmente leva cerca de 1 ano, mas já vi casos que foram encerrados em 2 ou 3 meses e em que a liderança foi, na prática, cortada no trimestre seguinte.
Se alguém pedir sua opinião, você pode explicar suas preocupações diplomaticamente; se não pedirem, também pode ficar quieto.
O ponto central é se você vai apontar ativamente os problemas de um plano de alguém acima de você que está tentando levar o crédito.
No momento em que você fala, eles sentem que o julgamento deles está sendo questionado e encaram como um ataque pessoal.
É extremamente difícil fazer isso sem criar inimigos, e inimigos permanecem por muito tempo; o dano de um único inimigo é difícil de compensar mesmo com vários amigos.
Então é preciso jogar o jogo.
É um detalhe realmente importante o fato de o protagonista estar mentindo sobre algo que já tinha terminado.
Todas as manhãs, ele entrava na reunião obrigatória de status tipo death march com o CTO e dizia “a equipe está trabalhando duro”, “hoje atingimos o ponto de integração do marco nº 73”, “ontem tivemos bom progresso e concluímos mais um web service”, mas, na realidade, eram coisas que já haviam sido concluídas no mês anterior.
Por um ângulo, isso parece prometer pouco e entregar muito.
Se ele tivesse mentido dizendo que algo ainda não concluído estava pronto, eu teria me sentido muito pior.
Sem dúvida seria mais arriscado, e também não seria bom para a equipe, quando voltasse, ouvir “aqui estão os tickets, mas eu já disse ao CTO que estavam prontos, então corram”.
A interação entre desenvolvedores e executivos sofre muito com assimetria de informação e falta de confiança.
Estou trabalhando agora em um projeto para atualizar uma codebase que roda em um compilador muito antigo.
Trabalhamos nisso por 1 ano e grandes partes do sistema já foram concluídas, mas ainda resta uma parte bastante importante.
A direção não entende o processo e também não tem certeza de que o projeto acabará dando certo.
Não os culpo por ficarem ansiosos, porque projetos de software, especialmente trabalhos de conversão, têm um longo histórico de fracassos.
As reuniões de andamento, que eram semanais, agora passaram a acontecer 2 vezes por semana; parece que eles acham que isso vai acelerar as coisas.
Em geral, eles não participam diretamente, e um gerente intermediário atua como mensageiro.
Do ponto de vista dos desenvolvedores, é claro que isso vai dar certo, e pessoalmente nunca duvidei do sucesso.
Só que o sistema é grande e antigo, então o prazo é incerto.
O que resta são meses, não anos, e conheço a regra 80/20, mas já estamos bem avançados dentro desses 20%.
Para a direção, é apenas um estado binário de concluído/não concluído, então é difícil avaliar o progresso, e não há “confiança” no que dizemos.
Eu entendo isso.
Se tivéssemos passado 1 ano sem fazer nada, mas apenas participando de reuniões, eles não saberiam.
Como é um contrato de preço fixo, não temos motivo para enrolar, mas todo o risco está com eles.
Eles já gastaram muito dinheiro e estão ansiosos.
Tomaram boas decisões técnicas com base no conselho de especialistas técnicos externos, mas ainda lhes falta convicção.
No fim das contas, se o projeto fracassar, o impacto recai sobre eles; sobre nós, relativamente menos.
Não há solução fácil.
Não dá para simplesmente dizer que os gestores deveriam ser técnicos, e essa tecnologia nem é o core business deles.
Chamar mais consultores também não vai aquecer o coração de ninguém.
O melhor que podemos fazer é seguir em frente e entregar.
Mesmo que sejam blocos de um mês, tudo bem: basta detalhar e dividir tudo em subtarefas.
Não precisa ser perfeito; não há problema em haver partes grosseiras.
Recomendo dar a cada bloco um nome amigável e divertido.
Por exemplo, nomes de danças clássicas como tango, cha-cha e valsa seriam bons.
Marquem reuniões com os gestores, incluindo executivos seniores, e peçam que os gerentes intermediários participem como observadores das daily standups.
Façam todos ficarem de pé para que a reunião termine rápido, e acompanhem o progresso em relação às tarefas da lista.
Uma tarefa ser acrescentada ou atrasar um pouco não assusta as pessoas, desde que, no todo, vocês estejam chegando perto.
Nós dois sabemos que o deploy real é o grande obstáculo, mas basta não dizer isso a eles até que esteja pronto.
Atrasos deixam a direção ansiosa, e eu entendo isso, mas fazer mais reuniões não acelera nada.
Um PM fazer check-in diário de 30 minutos dizendo que “vai apoiar e fornecer o que for necessário para colocar o projeto de volta nos trilhos” não ajuda.
A única coisa necessária é ter menos reuniões.
O único obstáculo é tempo, e o motivo de o tempo ser um obstáculo é que, para começo de conversa, o alto escalão insistiu em um cronograma irrealista.
No fim, ao demonstrar que não confiam nos desenvolvedores, eles também demonstram que não confiam na própria capacidade gerencial de ter contratado os desenvolvedores certos.
Eles estão fazendo muito mal uma parte central do próprio trabalho.
Um projeto de 1 ano não deveria estar em um estado binário de concluído/não concluído.
É preciso haver indicadores de progresso com os quais se possa trabalhar.
A alta direção não precisa ser técnica, mas em algum ponto da hierarquia deve necessariamente haver alguém capaz de traduzir o progresso para um formato compreensível.
Duas coisas que sei com certeza sobre o fornecedor são difíceis de perdoar
Uma é que ele fez a lógica central depender de fazer registros do Mongo crescerem indefinidamente; a outra é que três pessoas um pouco acima da média, com esforço deliberado, conseguiram substituí-lo em cerca de 3 meses
O fato de esse fornecedor ter chegado ao ponto de negociar com clientes Fortune 500 mostra como organizações parecidas com esse cliente se sentem impotentes diante de trabalhos de software que nem são tão grandes assim
Na prática, o escopo daquele projeto parece algo que alguns daqui conseguiriam fazer até como projeto de hobby
Por isso também dá para entender por que o Retool é popular entre líderes técnicos, mas não necessariamente entre engenheiros
Fico curioso para saber quais outras abordagens de produto poderiam preencher essa mesma lacuna
Graças às planilhas, qualquer pessoa em um cargo baixo conseguia criar, em poucos dias, um protótipo tosco e quase funcional de uma ferramenta sem precisar lidar com mais ninguém na organização
Antes das planilhas, era preciso convencer alguém de cima a fazer o departamento de TI assumir a solicitação, e só esse processo levava no mínimo 3 meses
Depois disso, você ainda teria de esperar mais alguns trimestres para receber uma implementação tosca e quase funcional, escrita em algo como Cobol ou C, que não batia com os requisitos
Alguns desenvolvedores e algumas pessoas de suporte foram se encontrar com os usuários, e os desenvolvedores estavam havia 6 meses criando uma nova ferramenta para resolver um grande problema
Só que aquele dia foi a primeira vez que os usuários finais a viram
Pouco tempo depois, estávamos voltando pela divisa estadual, e os desenvolvedores estavam de rabo entre as pernas
Pelo que sei, ninguém nunca mais tocou no assunto daquele projeto
O esquema é fazer os recém-contratados executarem todo o trabalho e cobrar pela hora de desenvolvedor sênior
Gostaria que as pessoas parassem de usar imagens de capa geradas por IA
Isso quebra a concentração logo de cara
Aquele código está atrás do monitor?
E também há código no encosto da cadeira lá atrás? Ou aquilo em que a pessoa está sentada é um iPad gigante?
Se você vai usar imagens de IA, pelo menos precisa se esforçar para que elas não pareçam completamente estranhas e malucas
Esse tipo de imagem é gerado literalmente em segundos; essa foi a melhor que escolheram?