☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta gestao. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta gestao. Mostrar todas as mensagens

sábado, 8 de fevereiro de 2025

O Salaryman que Virou Shitennō — Quando Uchimura Saiu do Escritório, Entrou no Exército do Rei Demônio e Descobriu que o Verdadeiro Boss Final Era a Gestão de Pessoas

 

Bellacosa Mainframe apresenta Sararīman ga Isekai ni Ittara Shitennō ni Natta Hanashi

☕ Um Café no Bellacosa Mainframe

O Salaryman que Virou Shitennō — Quando Uchimura Saiu do Escritório, Entrou no Exército do Rei Demônio e Descobriu que o Verdadeiro Boss Final Era a Gestão de Pessoas

Ou: por que um homem sem espada sagrada, sem status LV 9999 e sem harém de princesas resolveu problemas de guerra usando negociação, logística, respeito pelo time e uma espécie de RACF emocional

Sararīman ga Isekai ni Ittara Shitennō ni Natta Hanashi
(サラリーマンが異世界に行ったら四天王になった話)

Título ocidental: Headhunted to Another World: From Salaryman to Big Four!
Tradução livre: Quando um assalariado foi para outro mundo e se tornou um dos Quatro Generais.

ItemInformação
Obra originalManga
Autor da históriaBenigashira
Arte do mangaMuramitsu
PublicaçãoComic Gardo / Overlap, desde 27 de dezembro de 2019
Direção do animeMichio Fukuda
EstúdiosGEEKTOYS e CompTown
Estreia6 de janeiro de 2025
Encerramento24 de março de 2025
Episódios12
GênerosIsekai, fantasia, comédia, aventura, ambiente corporativo, romance leve
Classificação de conteúdoViolência fantasiosa moderada, tensão política, escravidão como tema narrativo; perfil aproximado de 12+/13+, conforme a plataforma e o país
SituaçãoAnime concluído em uma temporada; manga continua em publicação

A adaptação teve 12 episódios e foi produzida pela GEEKTOYS com a CompTown. O site oficial também lista o manga em pelo menos 10 volumes; a editora anunciou que a série superou 600 mil cópias em circulação, contando físico e digital. Site oficial do anime e Overlap — volume 11


Sinopse: o onboarding mais perigoso do universo

Dennosuke Uchimura é um salaryman japonês que foi retirado da rota de ascensão e enviado para trabalhar numa fábrica no exterior. Não é um jovem prodígio, nem um guerreiro reencarnado, nem alguém que descobriu uma skill chamada INFINITE CREATION.

Ele é só um profissional que conheceu chefes ruins, metas absurdas, trabalho invisível e aquela sensação clássica de que competência nem sempre vira reconhecimento.

Então o Rei Demônio aparece com uma proposta: ser recrutado como o quarto membro de sua cúpula militar.

Não é uma convocação do tipo “salve a humanidade”. É um headhunting. Há entrevista, salário simbólico, cargo executivo, resistência da equipe antiga e uma lista de entregas capaz de dar ABEND em qualquer gestor: crise de abastecimento, disputa entre povos, negociação internacional, monstros descontentes, comerciantes predatórios e guerras que ninguém consegue resolver apenas com força bruta.

Uchimura aceita porque, pela primeira vez, alguém olha para sua experiência e diz: “eu sei o que você sabe fazer; venha trabalhar comigo”.

Para um salaryman, isso é mais poderoso que magia de fogo.


A história: do “entrevistado” ao administrador do Reino Demoníaco

A temporada começa como uma sátira de recrutamento. O Rei Demônio não quer Uchimura porque ele é valente: quer porque observou sua capacidade de trabalhar sob pressão, negociar em ambiente hostil e sobreviver a uma operação estrangeira.

A primeira aventura é quase uma prova técnica. Os outros generais não entendem por que um humano, sem força física e sem magia, merece aquela cadeira. Uchimura precisa provar que não foi contratado por amizade de LinkedIn do Rei Demônio.


Daí a série abre seu verdadeiro motor: cada arco parece uma demanda de negócio disfarçada de fantasia.

  • Uma comunidade tem produção, mas não tem canal de venda.

  • Um grupo tem força militar, mas sua cultura interna bloqueia reformas.

  • Um reino vizinho tem recursos, mas não confiança.

  • Um mercador manipula escassez e usa informação assimétrica como arma.

  • Uma cidade é governada por quem trata pessoas como custo descartável.

Em qualquer isekai convencional, o protagonista derrubaria a porta, derrotaria o vilão e receberia aplausos. Uchimura primeiro pergunta:

Quem produz? Quem perde? Onde está o gargalo? Quem tem medo de mudar? E quem está lucrando com o problema?

É o sujeito que chega ao incidente e, antes de executar CANCEL, abre o log, verifica o job anterior, confere a dependência e pergunta por que aquele processo existia.


Os personagens: a empresa onde o organograma tem chifres

Dennosuke Uchimura

Uchimura é o protagonista adulto que falta em muitos isekais. Sua habilidade não é uma magia escondida: é experiência acumulada, escuta, capacidade de formular acordos e, sobretudo, coragem de assumir responsabilidade.

Mas há um detalhe humano: ele carrega trauma de uma vida corporativa que o ensinou a duvidar da própria competência. Quando o Rei Demônio lhe oferece reconhecimento, Uchimura não vira imediatamente um comandante confiante. Ele estranha. Ele suspeita. Ele teme falhar de novo.

O anime entende uma coisa que muito material de autoajuda ignora: promoção não cura automaticamente a ferida causada por anos de desprezo.

O Rei Demônio

Dublado por Akio Ōtsuka, o Rei Demônio é talvez o maior golpe de humor e de crítica da obra. Ele é o “vilão” com postura de líder ideal: identifica talento, distribui responsabilidades, conhece as limitações dos subordinados e cria ambiente para que eles cresçam.

O Rei Demônio é menos Sauron e mais o gerente que você gostaria de ter encontrado antes de decidir trabalhar remoto e evitar reuniões.

O próprio material oficial descreve-o como o chefe ideal de Uchimura. Ficha oficial dos personagens

Ulmandra

Ulmandra é uma dos Quatro Generais e a maior força de combate do exército. Ela resolve problemas com o método mais antigo do mundo: socar primeiro e atualizar o documento depois.

Só que o anime não a reduz a “garota forte que se apaixona pelo protagonista”. Ela é leal, é respeitada pela tropa e representa a competência operacional. Uchimura pensa, Ulmandra executa, e a dupla funciona porque cada um reconhece a especialidade do outro.

Ela é o colega de produção que não escreve o PowerPoint mais bonito, mas mantém o ambiente de pé quando todos os dashboards estão verdes e o cliente está ligando.

Sylphid e Genome

Sylphid é a especialista técnica da cúpula: domina a tecnologia mágica, protege sua identidade e funciona como aquela pessoa que conhece o sistema legado inteiro, mas só aparece quando a situação já virou RC=16.

Genome comanda tropas de demi-humanos, é disciplinada e vive em atrito com Ulmandra. A rivalidade entre elas ajuda a mostrar que organização não é uma família de propaganda: equipes podem ser competentes, leais e ainda assim divergir de método, origem e prioridades.

Orle, Neia e os personagens dos arcos

Orle, filha do líder ogro, introduz o tema da modernização de uma sociedade sem apagar sua cultura. Neia leva a narrativa a encarar escravidão, exploração e abuso de poder. Já comerciantes como Butagarian e autoridades locais corruptas fazem o papel de antagonistas que não têm aura demoníaca: têm monopólio, influência e a certeza de que ninguém vai auditar o processo.

Eis uma verdade bellacosiana: o dragão pode destruir uma vila, mas quem controla estoque, taxa e informação consegue destruir dez sem usar uma unha.

O que este isekai tem de diferente?

Ele troca a fantasia do poder individual pela fantasia, bem mais rara, de ser tratado com dignidade no trabalho.

Uchimura não recebe uma espada que corta montanhas. Ele recebe confiança. E, ainda mais importante, aprende a devolver essa confiança ao time.

O anime também evita uma armadilha comum: não diz que toda habilidade corporativa é boa. Seu herói traz marcas de uma empresa tóxica; ele precisa desaprender a lógica de que sofrimento é prova de valor. A experiência dele serve quando vira empatia, planejamento e diplomacia — não quando vira exploração com estética de produtividade.

A diferença pode ser resumida assim:

Isekai de poder clássicoSalaryman Shitennō
“Sou especial porque fui escolhido”“Tenho algo útil porque vivi, errei e aprendi”
Vitória pela habilidade máximaVitória por diagnóstico, acordo e execução
Rei Demônio como inimigo finalRei Demônio como líder que reconhece pessoas
Aventura centrada no heróiProblemas resolvidos com comunidade e equipe
Status, nível e magiaConfiança, logística, política e gestão

Aventuras e as mensagens ocultas

1. A entrevista no outro mundo

O primeiro teste não é de combate: é de legitimidade. Uchimura enfrenta preconceito de cargo. Foi contratado “por cima”, logo precisa provar que não é indicação indevida.

A mensagem é ótima: quando alguém entra em uma equipe numa posição elevada, competência não basta. É preciso conquistar confiança sem humilhar quem já estava ali.

2. O problema da produção e do mercado

A obra mostra comunidades capazes de produzir, mas incapazes de transformar esforço em prosperidade porque faltam canal, informação, transporte ou acordo justo.

A mensagem não é “comércio resolve tudo”. É que trabalho sem acesso, sem organização e sem poder de negociação tende a enriquecer o intermediário mais forte.

3. Povos monstruosos, culturas diferentes

Uchimura não chega mandando ogros ou demi-humanos abandonarem quem são. Ele tenta entender quais valores são importantes para eles e só então desenha uma solução.

Aqui há uma pequena aula de mudança organizacional: transformação imposta de cima costuma virar resistência; transformação que respeita o grupo pode virar adesão.

4. Conflitos internacionais

A série trabalha diplomacia como algo mais difícil que vencer batalha. Acordo não é fazer todos saírem felizes; é fazer todos saírem com algo suficiente para não voltar à guerra amanhã.

Para quem conhece mainframe, é a diferença entre “o job terminou com RC=0” e “a cadeia inteira fechou, os arquivos estão consistentes e ninguém terá de reprocessar tudo na segunda-feira”.

5. O trauma do protagonista

O último movimento da temporada volta à questão essencial: Uchimura pode assumir uma responsabilidade maior sem repetir a vida que o destruiu?

A pergunta escondida não é “ele será rei?”. É “uma pessoa treinada por um ambiente ruim consegue voltar a desejar crescer sem achar que será punida por isso?”

Essa é a parte mais adulta da obra.

Temas centrais

  • Reconhecimento profissional sem bajulação.

  • Liderança que conhece talentos e limites.

  • Trabalho como ferramenta de comunidade, não só de status.

  • Diplomacia acima da força bruta.

  • Transformação cultural sem colonialismo disfarçado.

  • Trauma corporativo, síndrome do impostor e reconstrução de autoestima.

  • Relações entre chefe, equipe e responsabilidade.

O anime é leve, mas não é vazio. Ele brinca com o desejo muito japonês — e muito universal — de que alguém finalmente diga: “você trabalha bem; eu vejo isso”.

Qualidade, classificação e para quem funciona

Minha classificação Bellacosa seria 7,5/10.

Não é uma obra revolucionária em animação, nem entrega batalhas no nível de Mushoku Tensei, Frieren ou Re:Zero. A produção é funcional, por vezes econômica, e alguns conflitos têm resolução mais rápida do que mereciam.

Mas é um anime honesto, simpático e bem posicionado dentro do próprio escopo. Ele não promete épico de mil anos e depois entrega reunião de condomínio. Ele promete uma fantasia corporativa e cumpre: um protagonista experiente, um chefe bom, uma equipe estranha e problemas que não se resolvem gritando “mais poder”.

É recomendado para quem gosta de:

  • isekai com protagonista adulto e competente;

  • fantasia com economia, comércio e diplomacia;

  • romance leve, sem transformar tudo em harém;

  • humor de escritório;

  • histórias em que conversar é uma habilidade real;

  • obras como The Genius Prince’s Guide, Maoyuu ou episódios mais econômicos de Spice and Wolf.

Talvez frustre quem procura ação contínua, vilões puramente malignos ou o protagonista dominando o mundo por cheat skill.

Censura: houve corte ou polêmica?

Não há registro público relevante de censura específica do anime, de retirada de episódios ou de uma edição conhecida por cortes entre a transmissão japonesa e o lançamento internacional.

A série traz violência de fantasia, ameaças, guerra e um arco que envolve escravidão, mas não constrói seu apelo em gore, erotização extrema ou choque visual. O tratamento é relativamente contido para o padrão de fantasia noturna japonesa.

Portanto, o ponto correto não é “foi censurado”; é: a obra já nasceu mais moderada em tom e imagem. Caso uma plataforma aplique classificação indicativa diferente no Brasil, ela pode variar por política local — isso não significa que exista uma versão mutilada da série.

Manga, novel e games

Aqui existe um pequeno bug de catálogo que vale corrigir.

A obra não nasceu como light novel. Ela começou como trabalho de manga/web manga de Benigashira e ganhou a versão serializada ilustrada por Muramitsu no Comic Gardo, da Overlap. O autor, inclusive, declarou trabalhar como salaryman enquanto escrevia a história — o que ajuda a explicar por que as dores corporativas parecem observadas, não copiadas de uma lista de clichês. Equipe e comentários oficiais

Até setembro de 2026:

  • Manga: em publicação; pelo menos 12 volumes japoneses anunciados/publicados pela Overlap.

  • Light novel: não há linha principal de light novels conhecida da obra.

  • Anime: uma temporada de 12 episódios.

  • Game próprio: não há anúncio confiável de jogo dedicado, mobile game ou visual novel da franquia.

  • Áudio promocional: a produção teve o programa web Izakaya Radio, com os dubladores de Uchimura e Ulmandra, reforçando o humor de “bar depois do expediente”. Página oficial do programa

Impacto cultural: modesto em escala, certeiro no alvo

Não foi um fenômeno global que parou a internet, nem virou uma nova indústria de bonecos. Seu impacto é menor, porém específico: deu forma de fantasia a uma frustração muito reconhecível por adultos trabalhadores.

No Japão, o salaryman é um arquétipo cultural fortíssimo. O personagem não está só cansado; ele representa o trabalhador preso entre lealdade, hierarquia, medo de falhar e a sensação de que sua competência pode passar a vida inteira sem ser vista.

O Rei Demônio ser o chefe mais saudável da história é, ao mesmo tempo, piada e crítica social.

Em outras palavras: o anime pergunta por que tantos trabalhadores prefeririam receber uma proposta de emprego de um soberano demoníaco a continuar onde estão.

E, francamente, há muita gente que já teve uma segunda-feira suficiente para entender a resposta.

Veredito final

Sararīman ga Isekai ni Ittara Shitennō ni Natta Hanashi não é o isekai que vai derrubar o castelo com animação de cinema. É o isekai que chega com uma prancheta, conversa com o ogro, identifica o gargalo, desmonta a chantagem do fornecedor, organiza a operação e depois toma uma cerveja imaginária para processar o trauma.

Uchimura não é um herói porque pode matar um dragão. Ele é herói porque olha para uma crise e consegue enxergar pessoas, interesses, medos e saídas.

No Bellacosa Mainframe, ele seria o sujeito convocado para um incidente crítico às 2h da manhã sem conhecer o sistema — e que, em vez de fingir que sabe, reúne quem conhece, escuta o operador, protege o júnior, negocia a janela, recupera o serviço e deixa documentação para a próxima madrugada.

Isso, meus caros, é uma habilidade lendária.



quarta-feira, 15 de junho de 2022

Phileas Fogg Entra no CPD — A Volta ao Mundo em 80 Sprints e o Dia em que Descobriu que Scrum e Waterfall Podiam Viajar no Mesmo Trem

 

Bellacosa Mainframe apresenta o scrum e o waterfall

☕ Um Café no Bellacosa Mainframe

Phileas Fogg Entra no CPD — A Volta ao Mundo em 80 Sprints e o Dia em que Descobriu que Scrum e Waterfall Podiam Viajar no Mesmo Trem

Ou: como Waterfall, Scrum, modelos híbridos, Stage Gates, DevOps, automação, governança, feedback, riscos e um pouco de COBOL podem atravessar o mesmo projeto — e por que Passepartout descobriu que o maior atraso nunca estava no trem, mas no handoff esperando aprovação



Prólogo — Uma aposta no Reform Club e um projeto com data de produção

Londres, 1872.

Phileas Fogg entra no Reform Club, consulta o relógio e afirma com a serenidade de quem nunca recebeu um S0C7 às 16h58 de sexta-feira:

— É perfeitamente possível dar a volta ao mundo em oitenta dias.

Se Júlio Verne tivesse trabalhado algumas décadas em Tecnologia da Informação, provavelmente alguém responderia:

— Depende. O Architecture Board já aprovou?

Passepartout consultaria o Jira.

— Monsieur Fogg, a Índia está BLOCKED. O túnel ferroviário não ficou pronto.

Fogg não se abalaria:

— Então mudaremos o plano.

— Mas isso não estava no escopo!

— Passepartout, nosso objetivo é chegar a Londres. Não cumprir o PowerPoint.

E talvez tenhamos acabado de explicar boa parte da diferença entre seguir um plano e administrar um projeto.

Nossa viagem de hoje começa com uma pergunta aparentemente simples:

Scrum e Waterfall podem trabalhar juntos?

Podem.

Aliás, em grandes organizações, frequentemente já trabalham.

A questão mais interessante é outra:

Eles trabalham juntos porque alguém projetou conscientemente essa combinação ou porque cada departamento resolveu trabalhar de um jeito diferente?

Essa diferença separa um modelo híbrido intencional de um Frankenstein metodológico capaz de possuir todos os documentos do Waterfall, todas as reuniões do Scrum e nenhuma das vantagens dos dois.

Pegue seu café.

O trem parte exatamente às 20h45.

Fogg não tolera atrasos.



1. Primeira parada: afinal, o que é Waterfall?

Antes de transformar Waterfall no vilão da história, precisamos entendê-lo.

O modelo tradicional imagina o projeto aproximadamente assim:

REQUISITOS
    ↓
ANÁLISE
    ↓
DESIGN
    ↓
DESENVOLVIMENTO
    ↓
TESTES
    ↓
IMPLANTAÇÃO
    ↓
MANUTENÇÃO

Existe uma forte preocupação em compreender e planejar o trabalho antecipadamente.

Para nosso iniciante COBOL, imagine que o banco peça:

Criar um sistema de cálculo de juros para determinado produto financeiro.

Num processo bastante tradicional, poderíamos primeiro documentar as regras, depois projetar arquivos e tabelas, escrever programas COBOL, testar, homologar e finalmente implantar.

Waterfall possui vantagens quando o problema é relativamente conhecido e quando alterações tardias custam caro.

E isso não acontece apenas em software.

Imagine Phileas Fogg chegando ao porto e dizendo:

— Vamos alterar o casco do navio durante a travessia.

O capitão provavelmente sugeriria que ele bebesse menos conhaque no Reform Club.

Algumas decisões precisam realmente acontecer antecipadamente.

Infraestrutura física, hardware, contratos, regulamentações, certificações e determinadas arquiteturas possuem essa característica.

Portanto:

Waterfall ≠ burrice
Waterfall ≠ tecnologia antiga
Waterfall ≠ automaticamente ruim

Ele é simplesmente uma maneira de administrar trabalho que favorece planejamento, sequência e previsibilidade.

O problema surge quando fingimos conhecer antecipadamente aquilo que ainda não conhecemos.



2. Passepartout conhece Scrum

Durante a viagem, Fogg possui um plano.

Mas o mundo não leu o plano.

Trem atrasou?

Adapte.

Navio não está disponível?

Procure outro.

A ferrovia não foi concluída?

Encontre outra solução.

O objetivo permanece.

A execução muda.

Existe aí uma analogia maravilhosa com Agile.

Scrum trabalha em ciclos curtos:

PRODUCT BACKLOG
      ↓
SPRINT PLANNING
      ↓
SPRINT
      ↓
INCREMENTO
      ↓
SPRINT REVIEW
      ↓
FEEDBACK
      ↓
RETROSPECTIVE
      ↓
PRÓXIMO SPRINT

A ideia não é simplesmente:

“Vamos programar mais rápido.”

Esse é um erro comum.

A grande vantagem é:

vamos diminuir o tempo entre fazer alguma coisa e descobrir se aquilo fazia sentido.

Isso é completamente diferente.


3. O usuário frequentemente não sabe exatamente o que quer

Esse é um segredo que todo programador descobre cedo ou tarde.

O usuário pede:

— Quero uma consulta de clientes.

Você cria:

       ACCEPT WS-COD-CLIENTE.

       EXEC SQL
          SELECT NOME
            INTO :WS-NOME
            FROM CLIENTE
           WHERE COD_CLIENTE = :WS-COD-CLIENTE
       END-EXEC.

Você demonstra.

Ele responde:

— Excelente! Mas precisamos pesquisar pelo CPF também.

Você implementa.

Nova demonstração.

— Ah... seria maravilhoso mostrar os contratos.

Depois aparece Jurídico:

— Esse campo não pode ser exibido.

Depois Segurança:

— Precisamos mascarar aquele dado.

Depois Produção:

— Essa consulta está fazendo table scan.

😂

O requisito não necessariamente estava “errado”.

O conhecimento sobre o problema evoluiu.

Scrum tenta transformar descoberta em parte natural do desenvolvimento.


4. Fogg descobre o Hybrid

Agora imagine algo interessante.

Phileas Fogg possui uma restrição absolutamente rígida:

80 DIAS

Mas sua execução precisa ser extremamente adaptável.

É quase nossa metáfora perfeita.

No projeto corporativo podemos ter:

DATA REGULATÓRIA
ORÇAMENTO
CONTRATO
ARQUITETURA CORPORATIVA
POLÍTICAS DE SEGURANÇA
AUDITORIA
JANELA DE PRODUÇÃO

Esses elementos podem exigir planejamento.

Enquanto desenvolvimento possui:

BACKLOG
SPRINTS
PROTÓTIPOS
FEEDBACK
PRIORIZAÇÃO
EXPERIMENTAÇÃO

Nasce o modelo híbrido:

              PROJETO
                 │
       ┌─────────┴─────────┐
       │                   │
   WATERFALL             SCRUM
       │                   │
   estrutura             adaptação
   orçamento             backlog
   milestones            sprint
   contratos             review
   gates                 feedback
       │                   │
       └────── HYBRID ─────┘

Não estamos necessariamente escolhendo um vencedor.

Estamos perguntando:

Qual problema cada abordagem precisa resolver?


5. Water-Scrum-Fall — Londres, Índia e Londres novamente

Uma combinação bastante conhecida pode ser representada assim:

WATERFALL
    ↓
Planejamento
Budget
Arquitetura
Contratos
    ↓
┌─────────────────┐
│      SCRUM      │
│ Sprint 1        │
│ Sprint 2        │
│ Sprint 3        │
│ Sprint 4        │
└─────────────────┘
    ↓
WATERFALL
    ↓
Homologação
Change
Aprovações
Deployment

Ou seja:

Water → Scrum → Fall.

O projeto começa bastante estruturado, desenvolve iterativamente e termina novamente em processos controlados.

Quem trabalha em grandes empresas provavelmente já encontrou algo semelhante mesmo sem usar esse nome.

O time passa semanas falando:

Sprint! Backlog! Story! Velocity!

Até chegar o momento da implantação.

Surge então um personagem misterioso usando sobretudo e carregando uma prancheta:

— Número da Change?

Silêncio.

— Aprovação de Segurança?

Silêncio.

— Plano de rollback?

Mais silêncio.

O Agile acabou de encontrar o fiscal Fix.


6. Easter egg mainframe nº 1 — produção possui RACF

Nosso programador COBOL iniciante precisa aprender cedo:

Agilidade não significa fazer qualquer coisa em produção.

Você pode desenvolver iterativamente.

Pode automatizar testes.

Pode entregar várias vezes por dia em determinados ambientes.

Mas sistemas críticos possuem controles por uma razão.

No z/OS, podemos encontrar mecanismos envolvendo segurança, auditoria, separação de funções e processos de mudança.

Portanto a questão madura não é:

“Como remover todos os controles?”

É:

“Como manter os controles necessários eliminando o desperdício desnecessário?”

Essa distinção é enorme.


7. Scrum dentro de Waterfall

Outra parada da nossa viagem.

Imagine um grande programa de modernização:

MODERNIZAÇÃO DO SISTEMA
│
├── Arquitetura ........ tradicional
├── Infraestrutura ..... tradicional
├── Compliance ......... gates
│
├── COBOL Team ......... Scrum
├── API Team ........... Scrum
├── Front-end Team ..... Scrum
│
└── Produção ........... processo controlado

Não existe lei universal dizendo que todos precisam trabalhar exatamente da mesma maneira.

Um departamento responsável por adquirir hardware pode ter horizontes e dependências completamente diferentes do time construindo uma interface.

O erro é exigir uniformidade metodológica simplesmente porque ela fica bonita na apresentação executiva.


8. Stage Gates — os postos de fronteira da viagem

Phileas Fogg atravessa fronteiras.

Nos projetos corporativos também existem fronteiras.

Chamamos algumas delas de gates.

Por exemplo:

GATE 0
Business Case
    ↓
GATE 1
Architecture Approval
    ↓
SPRINTS
    ↓
GATE 2
Security Review
    ↓
SPRINTS
    ↓
GATE 3
UAT
    ↓
GATE 4
Production

O gate pergunta:

“Estamos autorizados a continuar?”

Scrum pergunta:

“Qual é a coisa mais importante que devemos construir agora?”

São perguntas diferentes.

E justamente por isso podem coexistir.


9. Times paralelos — cada um usando um transporte

Na viagem de Fogg não existe um único meio de transporte.

Há trem, navio e outras soluções muito mais... criativas.

Num grande projeto acontece algo semelhante:

COBOL/CICS TEAM
      ↓
    Scrum

API TEAM
      ↓
    Scrum

INFRASTRUCTURE
      ↓
 planejamento

SECURITY
      ↓
 gates

FORNECEDOR
      ↓
 milestones

OPERATIONS
      ↓
 processos operacionais

Isso parece ótimo até descobrirmos um problema.

Dependências.

O time COBOL termina sua funcionalidade.

Mas precisa de infraestrutura.

Infraestrutura aguarda Network.

Network aguarda Security.

Security aguarda documentação.

Documentação aguarda Architecture.

E Architecture está esperando uma reunião na próxima terça-feira.

Resultado:

STATUS: BLOCKED

O código demorou dois dias.

A entrega levou três semanas.


10. Easter egg nº 2 — JES2 já conhecia filas

Quem trabalha com mainframe olha para isso e pensa:

— Já vi esse filme.

JOB
 ↓
QUEUE
 ↓
EXECUTION
 ↓
OUTPUT

Filas importam.

E projetos também possuem filas invisíveis.

Existe o tempo de trabalho e existe o tempo de espera.

Imagine:

Análise ................ 4 horas
Espera aprovação ....... 4 dias
Desenvolvimento ........ 2 dias
Espera ambiente ........ 6 dias
Teste .................. 1 dia
Espera Change .......... 5 dias

Se você otimizar o desenvolvimento em 30%, talvez quase nada aconteça no lead time total.

A grande descoberta é:

muitos projetos não são lentos porque programadores programam lentamente; são lentos porque trabalho pronto passa tempo demais esperando.


11. Predictability — cuidado com o mapa

Fogg possui horários de trens e navios.

Mas horário não é realidade.

O mesmo vale para nosso glorioso Gantt Chart.

Uma organização pode mostrar:

Projeto: 24 meses
Milestones: 137
Tasks: 4.281

Isso parece extremamente preciso.

Não significa necessariamente que seja previsível.

Existe uma diferença fundamental:

PRECISÃO ≠ EXATIDÃO

Dizer:

“Terminaremos em 17 de março às 14h35.”

é muito preciso.

Pode continuar completamente errado.

Uma abordagem mais madura reconhece horizontes diferentes de certeza:

12 meses → direção estratégica
 6 meses → grandes entregas
 3 meses → planejamento mais concreto
 1 mês   → maior detalhamento
 2 semanas → execução detalhada

Quanto mais distante o futuro, maior a incerteza.

O mapa deve admitir isso.


12. Flexibilidade — trocar o trem sem trocar o destino

Aqui está uma bela lição de A Volta ao Mundo em 80 Dias.

O objetivo não é usar determinado trem.

O objetivo é completar a viagem.

Da mesma maneira, o objetivo do projeto não deveria ser:

“executar perfeitamente o plano elaborado nove meses atrás.”

Deveria ser:

produzir o resultado necessário dentro das restrições relevantes.

Se aprendemos alguma coisa nova, o backlog pode mudar.

DESCOBERTA
    ↓
BACKLOG
    ↓
PRIORIZAÇÃO
    ↓
SPRINT
    ↓
REVIEW

Isso é adaptação controlada.

Não caos.


13. Risk Management — envie Passepartout primeiro

Existe uma ideia particularmente poderosa em desenvolvimento iterativo:

testar cedo as hipóteses perigosas.

Imagine uma modernização:

COBOL
  ↓
CICS
  ↓
z/OS Connect
  ↓
REST
  ↓
Cloud

No PowerPoint tudo funciona.

É impressionante como arquiteturas funcionam maravilhosamente dentro do PowerPoint.

Então construímos.

Aparecem:

LATÊNCIA
TIMEOUT
CERTIFICADOS
AUTENTICAÇÃO
FIREWALL
VOLUME
SERIALIZAÇÃO
RATE LIMIT
PERFORMANCE

Em vez de descobrir tudo isso no final, construa cedo uma pequena fatia vertical:

Programa COBOL
      ↓
CICS
      ↓
API
      ↓
Consumidor

Talvez processe somente uma operação.

Mas terá respondido perguntas arquiteturais valiosas.

Um pequeno experimento pode eliminar um grande risco.


14. Stakeholders — não desapareça por 18 meses

Uma das caricaturas mais perigosas do desenvolvimento tradicional é:

Usuário
  ↓
Requisitos
  ↓
18 meses de silêncio
  ↓
Sistema
  ↓
Usuário:
"Mas eu não pedi isso!"

Scrum reduz essa distância:

SPRINT
 ↓
DEMO
 ↓
FEEDBACK
 ↓
AJUSTE
 ↓
SPRINT

O verdadeiro benefício não é fazer mais reuniões.

É reduzir o tempo entre erro e descoberta do erro.

Quanto antes descobrimos uma premissa incorreta, menor tende a ser a quantidade de software construída sobre ela.


15. Culture Clash — Fogg encontra duas tribos

Aqui mora um dos maiores perigos do Hybrid.

A cultura Waterfall tende a perguntar:

Estamos seguindo o plano?

A cultura Agile tende a perguntar:

Ainda estamos construindo a coisa certa?

As duas perguntas são importantes.

Mas imagine uma empresa anunciando:

AGORA SOMOS AGILE!

Ela instala Jira.

Cria Scrum Masters.

Faz Daily.

Usa Story Points.

Mas mantém:

Escopo fixo
Prazo fixo
Budget fixo
Arquitetura fixa
Prioridades fixas
Aprovações centralizadas

Parabéns.

Você pode ter inventado:

Waterfall usando camiseta de Scrum.


16. O pior híbrido possível

Existe uma maneira especialmente cruel de implementar Hybrid:

pegar todos os controles do Waterfall e adicionar todas as cerimônias do Scrum.

Agora o desenvolvedor precisa:

  • atualizar o Gantt;

  • atualizar Jira;

  • participar da Daily;

  • preencher status semanal;

  • participar da Planning;

  • preencher documentação;

  • fazer Review;

  • atualizar planilha do PMO;

  • fazer Retrospective;

  • preparar slides executivos.

Em algum momento ele pergunta:

— Quando programamos?

Esse é o chamado imposto metodológico.

Todo processo possui custo.

A pergunta é se esse custo produz valor.


17. Handoffs — o verdadeiro Inspetor Fix

Em Júlio Verne, o Inspetor Fix persegue Fogg pelo mundo.

No projeto corporativo, nosso Fix pode ser o handoff.

BUSINESS
   ↓
ANALYSIS
   ↓
ARCHITECTURE
   ↓
DEVELOPMENT
   ↓
TEST
   ↓
SECURITY
   ↓
OPERATIONS

Cada seta pode representar:

fila
espera
reunião
ticket
aprovação
retrabalho

Portanto, quando alguém disser:

“Precisamos aumentar a produtividade dos desenvolvedores.”

pergunte primeiro:

“Quanto tempo o trabalho passa parado entre departamentos?”

Essa pergunta pode ser muito mais valiosa.


18. Defina contratos entre equipes

Uma excelente prática para modelos híbridos é transformar dependências vagas em interfaces claras.

Não escreva apenas:

Team A → Team B

Defina:

O QUE será entregue?
QUEM entrega?
QUEM recebe?
QUANDO?
EM QUAL FORMATO?
QUAL O CRITÉRIO DE ACEITE?
QUAL O SLA?
QUAIS AS DEPENDÊNCIAS?

É quase uma API organizacional.

Se APIs precisam de contratos, equipes também se beneficiam deles.


19. DevOps embarca no navio

Aqui nossa história ganha outro personagem.

Porque discutir somente Scrum versus Waterfall é insuficiente.

Scrum ajuda muito no ciclo de desenvolvimento e aprendizado.

DevOps olha para outro problema:

CODE
 ↓
BUILD
 ↓
TEST
 ↓
PACKAGE
 ↓
DEPLOY
 ↓
OPERATE
 ↓
OBSERVE

O objetivo é melhorar o fluxo entre desenvolvimento e operação.

Num ambiente moderno, inclusive mainframe, podemos automatizar boa parte disso.

Developer
   ↓
Git
   ↓
Build
   ↓
Unit Test
   ↓
Static Analysis
   ↓
Security Checks
   ↓
Package
   ↓
Deploy
   ↓
Integration Test
   ↓
Evidence

E chegamos a uma conclusão extremamente importante:

controle e velocidade não são necessariamente inimigos.


20. Compliance como código

Imagine que auditoria exija evidências de testes.

Modelo manual:

executa teste
 ↓
captura evidência
 ↓
preenche documento
 ↓
envia e-mail
 ↓
alguém arquiva

Agora imagine pipeline produzindo automaticamente:

BUILD ID
COMMIT
TEST RESULT
TIMESTAMP
APPROVAL
ARTIFACT VERSION
DEPLOYMENT RESULT

A automação pode aumentar simultaneamente:

velocidade + rastreabilidade + repetibilidade + controle.

Isso é extremamente importante em ambientes regulados.

O objetivo não precisa ser remover o gate.

Pode ser automatizar tudo aquilo que existe antes do gate.


21. Hybrid intencional versus Hybrid acidental

Essa distinção merece ficar pendurada na parede do CPD.

Hybrid intencional

A organização conclui:

Budget precisa de planejamento.
Compliance precisa de gates.
Desenvolvimento precisa de iteração.
Produção precisa de controle.
Feedback precisa ser rápido.

Então desenha conscientemente o sistema.

Excelente.

Hybrid acidental

A empresa cresceu durante décadas:

PMO ............. Waterfall
Development ..... Scrum
Operations ...... ITIL
Security ........ Gates
Finance ......... orçamento anual
Vendor .......... milestones

Ninguém projetou o fluxo completo.

Cada pedaço funciona isoladamente.

O conjunto parece a bagagem de Passepartout depois de atravessar três continentes.

Isso também é Hybrid.

Só que por acidente.


22. Easter egg nº 3 — o PERFORM RESPONSABILIDADE

Outro problema aparece quando misturamos estruturas.

Agora temos:

Project Manager
Product Owner
Scrum Master
Delivery Manager
Program Manager
Architect
Tech Lead
Business Analyst

Pergunta simples:

— Quem decide?

Silêncio.

Podemos representar em COBOL:

       PERFORM RESPONSABILIDADE
          THRU ALGUEM-DEVE-SABER.

😂

Definir papéis é absolutamente essencial.

Quem prioriza?

Quem controla orçamento?

Quem aceita?

Quem aprova arquitetura?

Quem responde pelo prazo?

Quem remove impedimentos?

Se duas pessoas acham que possuem a mesma autoridade, teremos conflito.

Se nenhuma acha que possui, teremos paralisia.


23. O segredo que nenhum framework gosta de admitir

Agora chegamos à grande pergunta que iniciou nossa conversa:

E se a “melhor metodologia” estiver escondendo o maior defeito do projeto?

Projeto atrasou.

— Vamos adotar Scrum!

Continua atrasado.

— Precisamos de mais governança!

Continua.

— Vamos fazer Hybrid!

Continua.

Talvez o problema seja:

arquitetura ruim
dívida técnica
ambientes instáveis
dependências excessivas
fornecedor atrasado
decisões lentas
requisitos contraditórios
testes manuais
falta de pessoas
governança inútil
liderança indecisa

Nenhum framework transforma magicamente problemas estruturais em produtividade.

Você pode reorganizar as cadeiras do navio.

O motor continuará quebrado.


24. Exemplo completo — a volta ao mundo de um programa COBOL

Vamos acompanhar uma funcionalidade.

O banco precisa disponibilizar uma operação COBOL/CICS através de API.

Etapa 1 — objetivo macro

Definimos:

prazo
budget
segurança
arquitetura
compliance

Aqui planejamento tradicional pode fazer sentido.

Etapa 2 — arquitetura

Consumer
   ↓
REST API
   ↓
z/OS Connect
   ↓
CICS
   ↓
COBOL
   ↓
Db2

Etapa 3 — backlog

Transformamos a implementação em itens menores.

Story 1 — consultar cliente
Story 2 — autenticação
Story 3 — consultar contratos
Story 4 — tratamento de erros
Story 5 — observabilidade

Etapa 4 — Sprints

Implementamos e demonstramos progressivamente.

Etapa 5 — integração contínua

Cada alteração dispara processos automatizados.

Etapa 6 — gates

Segurança e compliance verificam requisitos necessários.

Etapa 7 — homologação

Usuários validam comportamento.

Etapa 8 — implantação

Change aprovada, artefato identificado, rollback preparado.

Etapa 9 — observabilidade

Depois de produção medimos:

latência
throughput
erros
CPU
consumo
timeouts
disponibilidade

Perceba:

não precisamos escolher entre controle e aprendizado.

Precisamos projetar ambos.


25. A matriz de Fogg para escolher uma abordagem

Antes de perguntar “Scrum ou Waterfall?”, faça cinco perguntas.

1. O que sabemos?

Quanto maior a certeza, mais planejamento detalhado pode fazer sentido.

2. O que ainda precisamos descobrir?

Quanto maior a incerteza, mais úteis são experimentação e ciclos curtos.

3. Quais decisões são caras de reverter?

Construir infraestrutura é diferente de alterar a cor de um botão.

4. Quais decisões são facilmente reversíveis?

Decisões reversíveis não precisam necessariamente de seis comitês.

5. Onde o trabalho espera?

Essa talvez seja a pergunta mais negligenciada.

Desenhe:

IDEIA
 ↓
ANÁLISE
 ↓
DESENVOLVIMENTO
 ↓
TESTE
 ↓
SEGURANÇA
 ↓
PRODUÇÃO

Depois coloque o tempo em cada etapa.

Talvez você descubra:

TRABALHO REAL = 8 dias
ESPERA        = 42 dias

Nesse caso, reduzir uma Sprint de duas semanas para uma semana talvez não resolva absolutamente nada.


26. Curiosidade — o mapa não é o território

Phileas Fogg podia consultar horários, mapas e rotas.

Mas continuava sujeito ao mundo real.

Gerenciamento de projetos sofre da mesma ilusão.

Temos:

Gantt
Roadmap
Backlog
Dashboard
Burndown
Velocity
Risk Matrix

São representações.

Não são o projeto.

Um dashboard verde não significa necessariamente que tudo está bem.

Story Points não significam valor.

Número de tarefas concluídas não significa resultado.

Percentual de conclusão pode ser particularmente enganoso.

Você pode estar 90% concluído durante seis meses.

Quem já viu projeto corporativo sabe exatamente do que estou falando.


27. A verdadeira definição de Hybrid

Depois de atravessarmos continentes metodológicos, podemos melhorar bastante aquela definição inicial.

Hybrid não deveria significar:

“Misture Scrum e Waterfall.”

Uma definição mais madura seria:

Use previsibilidade onde existe conhecimento suficiente para planejar e adaptação onde ainda existe incerteza a ser descoberta.

Essa frase muda tudo.

Porque desloca a discussão de:

QUAL FRAMEWORK?

para:

QUAL PROBLEMA?

E essa é uma evolução enorme.


28. A metodologia não deve virar religião

Talvez essa seja uma das maiores lições para quem está começando.

Não seja torcedor de metodologia.

Não existe:

SCRUM F.C.
       VS
WATERFALL UNITED

😂

Métodos são ferramentas.

COBOL também é ferramenta.

Db2 é ferramenta.

CICS é ferramenta.

Jira é ferramenta.

CI/CD é ferramenta.

A pergunta profissional é:

Que problema estou tentando resolver e por que esta ferramenta é adequada?

Quando a organização começa a defender o processo mesmo quando o processo prejudica o resultado, alguma coisa saiu dos trilhos.

Literalmente, no caso de Fogg.


29. A regra Bellacosa da Volta ao Mundo

Se nosso jovem programador COBOL lembrar apenas de uma coisa deste café, guarde isto:

WATERFALL
Planeje aquilo que você conhece.

SCRUM
Aprenda rapidamente sobre aquilo
que ainda não conhece.

HYBRID
Não trate todos os tipos de
incerteza da mesma maneira.

DEVOPS
Reduza a distância entre código
e produção.

AUTOMAÇÃO
Faça a máquina executar aquilo
que não precisa de criatividade humana.

GOVERNANÇA
Controle aquilo cujo erro realmente
possui consequências.

Esse conjunto é muito mais útil do que perguntar qual metodologia ganhou a guerra.


Epílogo — Fogg retorna ao Reform Club

Oitenta dias depois, as portas do Reform Club se abrem.

Phileas Fogg entra.

Passepartout vem atrás carregando um notebook corporativo, três dashboards, vinte Changes, quarenta e sete histórias concluídas e uma retrospectiva que ninguém teve tempo de fazer.

O presidente do clube pergunta:

— Monsieur Fogg, afinal, qual metodologia permitiu completar a viagem?

Fogg olha para o relógio.

Depois responde:

— Nenhuma.

Silêncio.

— Eu tinha um objetivo, restrições, riscos, recursos e informações incompletas. Planejei aquilo que podia prever e adaptei aquilo que não podia.

Passepartout abre o notebook:

PROJECT STATUS: COMPLETED

O Inspetor Fix aparece correndo.

— Espere! Falta minha aprovação!

Passepartout fecha a tampa.

— Está em produção, monsieur.

😂

E talvez Júlio Verne tenha escrito, sem saber, uma excelente metáfora para gerenciamento moderno de projetos.

Fogg tinha um prazo praticamente Waterfall:

oitenta dias.

Mas sua execução era profundamente adaptativa.

Quando uma rota falhava, ele não convocava uma reunião para explicar por que o plano original continuava correto.

Ele procurava outra rota.

Esse é justamente o ponto que tantas organizações esquecem.

Planejamento não existe para obrigar a realidade a obedecer ao plano. Planejamento existe para ajudar pessoas a navegar pela realidade.

Scrum não deve ser desculpa para ausência de planejamento.

Waterfall não deve ser desculpa para ignorar feedback.

Hybrid não deve ser desculpa para acumular burocracias.

DevOps não significa ausência de governança.

Automação não significa ausência de responsabilidade.

E Agile definitivamente não significa colocar Post-its numa parede e esperar que o projeto magicamente fique rápido.

No final, talvez o melhor modelo seja aquele que quase desaparece.

O desenvolvedor sabe o que precisa fazer.

O Product Owner consegue priorizar.

A arquitetura fornece limites compreensíveis.

Os testes encontram problemas cedo.

Security participa antes do último minuto.

Compliance recebe evidências confiáveis.

O pipeline elimina trabalho manual.

Produção recebe mudanças rastreáveis.

E o usuário vê valor continuamente.

Quando isso acontece, ninguém precisa passar metade do dia discutindo se aquilo é Scrum, Waterfall, Water-Scrum-Fall, Stage-Gate Agile ou Hybrid.

O trem simplesmente anda.

E para nós, habitantes do Bellacosa Mainframe, sobra a última lição.

No z/OS aprendemos há décadas que controle, filas, prioridades, segurança, automação e execução precisam coexistir. Um JOB não recebe acesso irrestrito ao sistema apenas porque precisa terminar rápido. Também não deveria ficar eternamente parado porque alguém decidiu que todo controle precisa ser manual.

Projetos modernos estão redescobrindo exatamente esse equilíbrio.

Talvez a volta ao mundo do desenvolvimento de software tenha levado décadas apenas para chegarmos novamente a uma velha conclusão do CPD:

velocidade sem controle produz acidentes; controle sem fluxo produz filas; e metodologia sem propósito produz reuniões.

Phileas Fogg consulta novamente o relógio.

Passepartout pergunta:

— Para onde vamos agora, monsieur?

Fogg observa um programador COBOL abrindo o Jira.

— Para produção.

— Scrum ou Waterfall?

Fogg pega o café.

— Primeiro descubra onde está o gargalo.

Fim do JOB.

IEF142I FOGG80D STEP01 - STEP WAS EXECUTED
IEF285I JOURNEY COMPLETED
IEF375I JOB/F0GG80D/ START
IEF376I JOB/F0GG80D/ STOP

RETURN CODE = 0000

E o café, ao contrário do projeto, ainda estava dentro do prazo.

Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...