Reforço de equipe ou terceirização de sistemas legados

Reforço de equipe, projetos terceirizados e contratos em que o fornecedor responde pela entrega podem produzir bom software. Eles fracassam por motivos diferentes porque vendem unidades diferentes de responsabilidade. Um vende pessoas, outro vende um pacote de trabalho descrito e o terceiro vende um resultado funcional, com o fornecedor responsável por colocá-lo em produção.

Os compradores costumam comparar diárias e datas de entrega sem declarar essa diferença. É assim que um contrato que parecia econômico em uma reunião de direção deixa um engenheiro interno decidindo se deve executar novamente um lote que falhou às 02:00. A pergunta útil não é qual modelo comercial parece mais seguro. É quem tem autoridade, informação e obrigação para tomar a próxima decisão irreversível quando o plano deixa de corresponder à realidade.

Já vi os três modelos funcionarem e já vi cada um deles ser usado como disfarce. Mãos adicionais são vendidas como equipe. Um escopo fixo recebe o nome de resultado. Um fornecedor afirma ser responsável pela entrega, mas exige que o cliente aprove toda decisão de arquitetura. Os nomes na proposta não definem o modelo operacional. Direitos de decisão, evidências de aceite e dever de responder a incidentes definem.

Reforço de equipe aluga capacidade, não um resultado

O reforço de equipe funciona quando sua organização já sabe como dirigir o trabalho. Você acrescenta engenheiros a uma equipe existente, enquanto seus líderes mantêm o backlog, a arquitetura, a decisão de liberação e a responsabilidade operacional. O fornecedor deve disponibilizar pessoas capacitadas nos termos combinados. Sua empresa continua devendo a si mesma um resultado.

Isso pode ser exatamente o que você precisa. Uma equipe de produto pode ter uma fronteira de serviço clara e uma fila de seis meses de trabalho bem compreendido. Pode precisar de dois engenheiros de Go experientes enquanto conclui contratações. O trabalho pode ser dividido, revisado e implantado por mecanismos que a equipe já controla. Nesse cenário, o reforço aumenta a capacidade de entrega sem inventar outra camada de gestão.

O modelo quebra quando o comprador na verdade não tem liderança técnica ou conhecimento do sistema. Dez profissionais contratados não conseguem executar uma decisão que ninguém está qualificado para tomar. Eles vão esperar, deduzir ou criar respostas locais. O gerente interno então reclama que falta iniciativa, enquanto os contratados observam corretamente que mudar a propriedade dos dados nunca esteve dentro da autoridade deles.

Fred Brooks formulou a versão desse problema ligada a prazos em The Mythical Man-Month: adicionar pessoas a um projeto de software atrasado pode atrasá-lo ainda mais porque treinamento e comunicação consomem a capacidade que se esperava ganhar. Algumas pessoas repetem a lei de Brooks como se aumentar a equipe nunca ajudasse. Isso é amplo demais. Engenheiros adicionais ajudam quando o trabalho pode ser dividido, as interfaces são estáveis e alguém consegue absorver a revisão. Eles atrapalham quando cada pessoa nova depende de especialistas escassos para explicar um sistema mal mapeado.

A armadilha comercial está em medir presença porque é isso que o contrato entrega com clareza. Planilhas de horas, ocupação e velocidade individual dizem pouco sobre o sistema estar se tornando mais seguro para alterações. Se seus gerentes não conseguem definir trabalho concluído sem citar horas consumidas, você comprou mão de obra e perdeu a discussão sobre valor.

Use reforço de equipe apenas se um responsável interno nomeado puder responder a todas estas perguntas sem ligar para o gerente de conta do fornecedor: qual backlog vence quando as prioridades entram em conflito? Quem pode mudar uma interface? Quem aceita uma versão? Quem fica de plantão? Quem remove o acesso de um contratado? Se as respostas estiverem espalhadas por um comitê, mais pessoas aumentarão a fila diante desse comitê.

A terceirização só funciona com uma fronteira estável

A terceirização tradicional funciona melhor quando o comprador consegue descrever um serviço delimitado e julgá-lo em sua fronteira. Processamento de folha, uma fila de suporte com níveis de serviço definidos ou um componente com protocolo maduro podem se encaixar. O fornecedor decide como alocar a equipe, e o comprador avalia as saídas com base no contrato.

A modernização de software raramente começa com essa clareza. Um conjunto legado esconde comportamentos em agendamentos de tarefas, hábitos dos operadores, restrições de banco de dados, repasses por planilhas e consumidores posteriores que ninguém incluiu nos requisitos. Uma especificação de trabalho pode fixar preço e escopo, mas não faz essas incógnitas desaparecerem. Ela apenas decide quem terá de negociar quando surgirem.

A falha comum começa com um documento grosso de requisitos e uma definição fina de aceite. O fornecedor implementa as telas e interfaces citadas. Depois, o comprador descobre que o fechamento trimestral depende de uma ordem específica de registros e de uma nova tentativa não documentada. O fornecedor chama isso de solicitação de mudança porque o documento não mencionava o caso. O comprador chama de defeito porque a produção se comporta assim há quinze anos. As duas posições são defensáveis, e o sistema continua sem funcionar.

É por isso que a terceirização transfere a execução com mais facilidade do que transfere o risco. Se aceite significa conformidade com o escopo escrito, o comprador é dono de todas as omissões desse escopo. Se aceite significa paridade com o comportamento observado em produção, o fornecedor precisa acessar evidências representativas e ter autoridade para mudar sua abordagem quando essas evidências contradisserem o documento. São contratos muito diferentes.

A terceirização também cria uma divisão arquitetônica na fronteira comercial. O fornecedor otimiza o componente que é pago para entregar. Sua equipe de plataforma otimiza o conjunto. Se ninguém for responsável pela interação, os dois lados podem tomar decisões razoáveis que produzem um todo irracional: repositórios de identidade duplicados, observabilidade incompatível, duas políticas de repetição ou um modelo de dados que expõe premissas internas entre serviços.

Uma fronteira estável vai além de uma especificação de API. Ela inclui propriedade dos dados, semântica de falhas, independência de implantação, encaminhamento do suporte e as mudanças que cada parte pode fazer sem permissão. Se esses fatos estiverem em aberto, você está terceirizando uma negociação. Coloque um preço explícito nesse trabalho de gestão ou escolha um modelo que assuma a descoberta como parte da entrega.

Responsabilidade pela entrega move a fronteira do risco

Um contrato com responsabilidade pela entrega torna o fornecedor responsável por um resultado em produção, não apenas por uma equipe alocada ou uma lista de tarefas. O fornecedor deve controlar as escolhas de implementação necessárias para atingir o resultado e arcar com o custo de corrigir o trabalho que não passar pelo aceite combinado. Sem essas duas propriedades, a responsabilidade pela entrega é apenas um rótulo colado à terceirização.

Esse modelo é útil quando o trabalho tem uma fronteira de negócio clara, mas muita incerteza de implementação. Reescrever uma aplicação legada é um bom exemplo. O comprador pode nomear os fluxos que precisam continuar, os sistemas que devem se conectar e as restrições operacionais que não podem mudar. Talvez não conheça todas as regras enterradas no código nem a melhor arquitetura de destino. O responsável pela entrega é pago para resolver essa incerteza e provar o resultado.

O modelo custa mais do que capacidade bruta porque o fornecedor inclui o risco no preço. Esse valor adicional só faz sentido quando o risco realmente muda de lado. Leia as exclusões. Se o fornecedor pode tratar todo comportamento não documentado, atraso em dependência e diferença de ambiente como mudança cobrável, o comprador ainda é dono das incógnitas. Se o cliente precisa prescrever a arquitetura, aprovar cada escolha técnica e fornecer a equipe de liberação, o fornecedor não pode afirmar honestamente que possui a entrega.

Responsabilidade real exige obrigações simétricas. O fornecedor precisa ter autoridade sobre método, pessoal e projeto dentro das restrições combinadas. O comprador precisa ter autoridade sobre políticas de negócio, acesso à produção, tolerância ao risco e aceite. Um lado pode bloquear o outro, então o contrato deve estabelecer tempos de resposta e caminhos de escalação para dependências do cliente. Responsabilidade pela entrega não permite que o fornecedor contorne a governança. Significa que a governança não pode continuar sendo uma fila do cliente que ninguém mede.

Não confunda garantia com responsabilidade operacional. Um fornecedor pode prometer corrigir defeitos depois do aceite enquanto sua equipe ainda detecta incidentes, limita danos e decide se deve reverter. Esse arranjo pode ser adequado, mas o risco das 02:00 continuou com você. Se você espera que o fornecedor responda, ofereça telemetria, procedimentos, acesso e uma obrigação explícita de plantão. Expectativas sem acesso produzem conferências telefônicas, não recuperação.

A responsabilidade pela entrega é mais forte quando o aceite pode ser executado. Testes, reproduções de tráfego, saídas conciliadas e exercícios de recuperação transformam uma discussão sobre conclusão em evidência. A opinião de um comitê de direção não substitui essa evidência, sobretudo quando as pessoas que aprovaram o escopo estão dormindo durante a primeira falha.

A arquitetura pertence a quem pode rejeitar uma mudança

Responsabilidade pela arquitetura é a autoridade para aceitar ou rejeitar escolhas de projeto com consequências e conviver com seus efeitos operacionais. Não é a pessoa que desenha os diagramas. Um arquiteto-chefe que pode aconselhar, mas não consegue impedir uma divisão de esquema, não é dono dessa decisão. Um fornecedor que precisa pedir permissão para toda escolha relevante também não é dono da arquitetura.

Separe as decisões por domínio em vez de declarar uma responsabilidade conjunta vaga. Normalmente, o cliente deve ser responsável pelas restrições empresariais: identidade, tratamento de dados regulados, zonas de rede, ambientes de execução aprovados, fronteiras dos sistemas de registro e custos operacionais desejados. A equipe de entrega deve ser responsável pelas escolhas de implementação dentro dessas restrições: fronteiras de módulos, sequência de migração, bibliotecas internas, desenho de testes e táticas de refatoração. Decisões que alteram uma interface compartilhada precisam de um árbitro nomeado e um prazo.

A ideia de Architecture Decision Record de Michael Nygard é útil aqui porque registra em um documento curto uma decisão, seu contexto e suas consequências. Martin Fowler ressalta que uma decisão posterior deve substituir um registro antigo em vez de reescrever a história. Isso importa nas relações com fornecedores. Um histórico claro mostra se um resultado ruim veio de uma restrição, de uma escolha de implementação ou de nova evidência, sem transformar o registro em um livro de culpados.

O registro ainda precisa de um responsável pela decisão. Uma pasta cheia de ADRs pode documentar paralisia com o mesmo capricho com que documenta bom julgamento. Coloque quatro campos em cada decisão relevante: proponente, partes consultadas, decisor e gatilho de revisão. O gatilho importa porque uma escolha sensata para dez mil transações por dia pode se tornar errada depois que uma fusão dobrar a carga.

Team Topologies defende equipes alinhadas a um fluxo com responsabilidade de ponta a ponta e usa equipes capacitadoras para desenvolver uma competência que falta durante uma interação limitada. A lição útil para a contratação é que a ajuda deve deixar a equipe responsável mais capaz. Se especialistas externos se tornarem tradutores permanentes entre seu produto e sua própria plataforma, você criou uma dependência, não capacitou uma equipe.

A arquitetura pode continuar interna em qualquer modelo comercial. O que muda é a carga de gestão. Com reforço de equipe, arquitetura interna é o padrão. Com terceirização, você precisa vigiar a divisão. Com responsabilidade pela entrega, você define restrições e deixa o fornecedor projetar dentro delas. É possível misturar esses arranjos decisão por decisão, mas cada exceção acrescenta uma passagem que precisa de um responsável.

A falha do lote às 02:00 lê o contrato em voz alta

Uma falha em produção expõe a distribuição real de responsabilidade mais depressa do que qualquer slide de governança. Imagine um lote migrado de liquidação que lê 1,8 milhão de registros, grava lançamentos contábeis e publica um evento de conclusão. Às 02:07, ele para depois de confirmar o banco de dados, mas antes de publicar o evento. O agendador marca a tarefa como falha.

Um operador enxerga três ações possíveis. Executar o lote de novo e arriscar lançamentos duplicados. Publicar o evento manualmente e arriscar anunciar uma execução incompleta. Restaurar a versão anterior e arriscar aplicar código antigo a um estado parcialmente migrado. Isso não é principalmente um problema de depuração. Alguém precisa conhecer a fronteira de idempotência, ter autoridade para escolher e arcar com a consequência.

Com reforço de equipe, seu comandante de incidente é dono dessa decisão. Os contratados podem diagnosticar e aconselhar, mas seu modelo operacional os dirige. Se o único engenheiro que entende o marcador de confirmação pertence ao fornecedor e não está de plantão, o contrato de pessoal expôs uma concentração de conhecimento que você aceitou.

Na terceirização convencional, a resposta depende do escopo do serviço. Se o fornecedor opera o lote sob um nível de serviço baseado em resultado, seu comandante pode ser responsável pela recuperação. Se apenas construiu e entregou a aplicação, sua equipe cuida do incidente e aciona o processo de defeitos depois. Um telefone de suporte no contrato não decide quem pode alterar dados de produção.

Com responsabilidade pela entrega, o dever deve acompanhar a fase de aceite. Antes do aceite em produção, o fornecedor normalmente responde por diagnóstico e correção, enquanto o cliente controla a autoridade sobre produção. Durante uma virada acompanhada em conjunto, nomeie um comandante de incidente e um aprovador de negócio. Depois do aceite, os deveres podem passar ao cliente ou continuar com o fornecedor, mas a transição deve incluir evidência de recuperação, não apenas um procedimento.

Coloque o acordo operacional em um formato que os engenheiros possam testar. Este exemplo não é um padrão, mas um anexo contratual compacto que evita a ambiguidade mais cara:

incident: settlement-batch-partial-commit
detection_owner: customer-operations
incident_commander: delivery-supplier
data_mutation_approver: customer-finance-platform
diagnosis_sla_minutes: 20
allowed_without_approval:
  - pause-downstream-consumers
  - capture-logs-and-state
forbidden_without_approval:
  - rerun-batch
  - publish-completion-event
  - restore-database
exit_evidence:
  - ledger-count-reconciled
  - duplicate-check-passed
  - downstream-event-confirmed

Exercite o acordo antes da liberação. Injete uma falha entre a confirmação e a publicação em um ambiente semelhante ao de produção, então observe quem consegue ver o alerta, obter evidências e aprovar a próxima ação. Se o exercício travar por acesso ou autoridade, mudar uma frase do contrato depois do lançamento não tornará a recuperação mais rápida.

O conhecimento fica onde as decisões são tomadas

A transferência de conhecimento falha quando é tratada como um item final da entrega. Um repositório de documentos pode guardar fatos, mas os engenheiros aprendem um sistema tomando decisões, vendo falhas e alterando o projeto. Se o fornecedor faz todas as escolhas relevantes enquanto os funcionários internos assistem a demonstrações semanais, o fornecedor vai embora com o raciocínio.

O reforço de equipe pode reter bem o conhecimento porque os engenheiros externos trabalham dentro da equipe, do processo de revisão e das ferramentas do cliente. Também pode fazer o contrário. Se os contratados recebem todo o trabalho pouco atraente no legado enquanto os funcionários constroem a plataforma nova, os contratados se tornam as únicas pessoas que entendem comportamentos dos quais a receita depende. O tipo de contrato não causou essa divisão, a distribuição do trabalho causou.

A terceirização costuma produzir artefatos explícitos porque a fronteira comercial exige isso. A fraqueza é o contexto. Um pacote de transição descreve o que existe no fim, enquanto a equipe do fornecedor lembra por que as alternativas rejeitadas falharam. Exija a participação dos engenheiros internos em revisões de projeto e exercícios de incidente, não apenas a aceitação de documentos. A participação consome capacidade durante a entrega, e esse custo compra independência mais tarde.

O trabalho com responsabilidade pela entrega cria uma tensão mais forte. Você contrata o fornecedor porque ele resolve incertezas rapidamente, então forçar uma aprovação interna para toda decisão destrói o modelo. Ainda assim, a separação completa deixa sua equipe sem capacidade para operar ou ampliar o resultado. A resposta não é responsabilidade compartilhada por toda escolha. Dê aos engenheiros internos responsabilidades específicas: uma interface, um conjunto de testes de paridade, um caminho de implantação ou um exercício operacional. Eles aprendem respondendo por uma parte real.

Meça a transferência pela ação independente. Um engenheiro interno consegue explicar por que uma fronteira está onde está? A equipe consegue diagnosticar uma reprodução que falhou sem perguntar ao fornecedor onde olhar? Consegue fazer uma pequena mudança e provar paridade? Quantidade de documentos e presença em reuniões medem entradas. Uma alteração sem assistência que funciona é evidência.

Observe os incentivos perto do fim. Um fornecedor cobrado por tempo se beneficia quando as perguntas continuam. Um fornecedor de escopo fixo se beneficia quando a transição termina rápido. Um responsável pela entrega pode otimizar o aceite e deixar a operação fraca se o teste de aceite não a incluir. Contratos não tornam fornecedores indignos de confiança. Eles tornam alguns atalhos economicamente atraentes. Seus controles devem atingir esses atalhos.

Controle e responsabilidade precisam andar juntos

A distribuição de risco se torna fictícia quando uma parte carrega a responsabilidade, mas outra controla a decisão que a cria. Um fornecedor não consegue garantir uma data de liberação se o cliente acrescenta requisitos sem mudar o aceite. Um cliente não consegue possuir a disponibilidade se apenas o fornecedor controla implantação e observabilidade. Os contratos frequentemente criam esses desencontros porque cada cláusula é negociada separadamente por pessoas que otimizam preocupações diferentes.

Mapeie controle ao lado da consequência. Se o fornecedor escolhe a sequência de migração, deve corrigir os defeitos dessa sequência por conta própria. Se o cliente exige um banco específico ou bloqueia o acesso às evidências de produção, deve carregar o risco de atraso e compatibilidade criado pela restrição. Se os dois lados aprovam uma interface compartilhada, nomeie quem desempata um impasse. “Acordo mútuo” descreve uma reunião, não um mecanismo de decisão.

Limites de responsabilidade financeira não dizem aos engenheiros o que fazer durante um incidente. Eles resolvem parte da disputa financeira depois que o dano acontece. O risco operacional precisa de mecanismos mais rápidos: acesso, alertas, autoridade decisória, critérios de reversão e um caminho ensaiado até quem pode aceitar o impacto no negócio. Trate indenizações e comando de incidente como camadas separadas. Recursos legais importam, mas não conciliam um livro contábil antes de a empresa abrir.

O controle de mudanças merece a mesma precisão. Existem pelo menos quatro eventos diferentes que as equipes chamam casualmente de mudança:

• O cliente pede um novo comportamento de negócio que o sistema antigo nunca teve.
• A descoberta revela um comportamento existente que o escopo escrito omitiu.
• O fornecedor muda o projeto porque a primeira abordagem não consegue cumprir o aceite.
• Uma dependência externa muda depois que as partes estabeleceram a referência.

Esses eventos não devem receber o mesmo tratamento comercial. Um novo comportamento normalmente altera preço, prazo ou ambos. Um comportamento existente, mas não documentado, pertence a quem aceitou o risco de descoberta. Uma abordagem de implementação que falhou geralmente pertence à parte que controlava o projeto. Uma mudança externa segue as premissas de dependência escritas na referência. Um processo genérico de mudança deixa a força comercial decidir o que a evidência técnica deveria decidir.

A governança deve analisar evidências no ritmo em que o risco aparece. Uma reunião mensal de direção serve para orçamento e decisões executivas, mas é lenta demais para escolhas de interface que bloqueiam o trabalho diário. Crie uma janela curta para exceções arquitetônicas e dependências do cliente. Quando a janela vencer, o contrato deve dizer se o trabalho pausa, se um padrão se aplica ou se a questão escala para um responsável nomeado. O silêncio precisa ter um efeito definido.

As métricas também podem mover o risco na direção errada. Pagar por chamados fechados premia chamados pequenos. Pagar por linhas convertidas premia transliteração e pune exclusão. Pagar somente no aceite final pode incentivar o fornecedor a esconder incertezas até ter um sistema que parece completo. Marcos devem corresponder à redução de risco: comportamento mapeado, interfaces provadas, tráfego reproduzido, implantação recuperável e operação independente. O pagamento pode acompanhar esses resultados sem fingir que todos exigem o mesmo esforço.

O teste prático é a simetria. Para cada obrigação, pergunte se a parte obrigada tem informação e autoridade para cumpri-la. Para cada direito de aprovação, pergunte se o aprovador carrega o atraso que pode causar. Para cada risco transferido, pergunte qual evidência provará que o fornecedor o assumiu. Uma obrigação sem controle vira uma exclusão mais tarde. Controle sem consequência produz governança descuidada imediatamente.

Compras precisa testar o modelo operacional

A área de compras pode distinguir os três modelos pedindo que os fornecedores respondam a situações concretas de falha e decisão. Apresentações genéricas de capacidade premiam equipes comerciais bem treinadas. Um cenário curto força cada fornecedor a revelar o que acredita possuir, o que precisa de você e o que exclui.

Pergunte quem paga quando o comportamento de produção registrado contradiz os requisitos escritos. Pergunte quem escolhe entre preservar o comportamento e melhorar a arquitetura. Pergunte quem acompanha a primeira execução em produção, quem pode aprovar uma reversão e quando o plantão muda de mãos. Em seguida, coloque as respostas no anexo comercial. Se ficarem nas notas da reunião, perderão para o texto de responsabilidade.

A comparação de preços também precisa incluir o trabalho mantido pelo cliente. Uma diária baixa pode exigir gestão de produto, arquitetura, engenharia de qualidade e operações internas em tempo integral. Um preço fixo de terceirização pode gerar um orçamento de mudanças em torno de comportamentos não documentados. Um preço com responsabilidade pela entrega inclui risco, mas ainda pode depender de especialistas do cliente, acesso ao ambiente e aprovações rápidas. Compare o esforço operacional total, não apenas as faturas do fornecedor.

Use etapas de aceite que correspondam ao risco:

1. Defina o comportamento observável e as tolerâncias antes de começar a implementação.
2. Registre as restrições de arquitetura separadamente dos projetos preferidos.
3. Reproduza casos representativos de produção e concilie as saídas.
4. Execute um exercício de recuperação de falha com decisores nomeados.
5. Peça a um engenheiro interno que faça e verifique uma pequena mudança sem intervenção do fornecedor.

Essa é uma cadeia de evidências, não cinco marcos administrativos. Um projeto pode passar pela revisão de código e pelos testes funcionais, mas falhar no exercício de recuperação porque ninguém possui o estado parcial. Pode passar pela paridade e falhar na mudança independente porque todo o conhecimento continua externo. O aceite deve expor essas diferenças antes da fatura final.

Não exija preço, escopo e data fixos para trabalho dominado por comportamento desconhecido e depois finja surpresa quando o fornecedor se proteger com exclusões. Escolha qual variável pode mudar ou pague alguém para assumir o risco da descoberta. Certeza comercial criada ao redefinir toda descoberta como mudança é contabilidade, não certeza de entrega.

O modelo certo acompanha a incerteza

Escolha reforço de equipe quando o trabalho é compreendido, sua equipe possui arquitetura e operações, e o gargalo são pessoas capacitadas. Escolha terceirização quando a fronteira é estável, as saídas são fáceis de inspecionar e você aceita administrar a interface. Escolha responsabilidade pela entrega quando o resultado é claro, a implementação é incerta e um fornecedor pode controlar o suficiente do método para carregar essa incerteza.

Partes diferentes de um programa podem usar modelos diferentes. Você pode reforçar a equipe de plataforma, terceirizar uma fila bem especificada de limpeza de dados e dar a um fornecedor a responsabilidade de entregar uma reescrita de legado. Desenhe as fronteiras em torno de decisões e modos de falha, não de categorias de compra. Uma pessoa precisa ser responsável pela integração entre elas.

Não use responsabilidade pela entrega para evitar um responsável interno. O cliente ainda é dono das políticas de negócio, da aceitação de risco e da longa vida do sistema. Nenhum fornecedor pode decidir qual divergência financeira é tolerável ou qual fluxo de cliente pode mudar. Um bom responsável pela entrega remove a incerteza de implementação. Ele não substitui o julgamento executivo.

Em reescritas de legado, o comportamento geralmente é a fronteira mais difícil de especificar apenas com documentos. A CodeHero lê todo o código, moderniza a arquitetura e verifica o resultado com um ambiente de paridade contra o tráfego de produção registrado, com entrega em menos de 30 dias. Essa só é uma proposta com responsabilidade pela entrega se o cliente também fornece evidências de tráfego, restrições, acesso e decisores necessários para verificar o resultado.

A escolha deve passar por um teste final. Escreva uma falha plausível às 02:00, a pessoa autorizada a agir, as evidências que ela verá e quem paga para corrigir o sistema. Se qualquer resposta for “em conjunto” ou “a combinar”, o contrato ainda não distribuiu o trabalho. Ele adiou a discussão até o sistema cair.