🎯 MASTER GUIDE PARA ENTREVISTA - PARTE 5

FERRAMENTAS DE QUALIDADE APLICADAS AO

DESENVOLVIMENTO DE SOFTWARE

📌 SEU DIFERENCIAL ÚNICO

A Narrativa Poderosa
"Minha formação em engenharia me deu algo que a maioria dos desenvolvedores não tem: domínio profundo
de ferramentas de análise e qualidade. Enquanto outros aprendem a debugar por tentativa e erro, eu aplico
Ishikawa para encontrar causa raiz. Enquanto outros estimam por feeling, eu uso 5W2H para planejar. Isso me
torna um profissional mais analítico e metódico."

Como Posicionar
"Não são apenas ferramentas da engenharia - são metodologias universais de resolução de problemas.
Google usa 5 Whys, Amazon usa 6-pager (similar ao A3), Toyota criou o Lean que inspirou o Agile. Eu trago
essas ferramentas já internalizadas."

1️⃣ 5W2H APLICADO AO DESENVOLVIMENTO

PERGUNTA: "Como você usa 5W2H em TI?"
Resposta Completa com Exemplos Práticos

"5W2H é meu framework mental para qualquer projeto ou problema:

PLANEJAMENTO DE FEATURE/USER STORY:

1 ## Feature: Sistema de Autenticação Two-Factor

2
3 ### WHAT (O que?)
4 - Implementar autenticação de dois fatores (2FA)
5 - Suportar TOTP (Time-based One-Time Password)
6 - Integrar com apps como Google Authenticator
7 - Backup codes para recuperação
8
9 ### WHY (Por que?)
10 - Aumento de 300% em tentativas de invasão último trimestre
11 - Compliance com LGPD/SOC2 requer MFA
12 - Concorrentes já oferecem, estamos perdendo clientes enterprise
13 - ROI: Reduz 99.9% dos ataques de credential stuffing
14
15 ### WHO (Quem?)
16 - **Responsável técnico:** Dev Senior (João)
17 - **Stakeholder:** Security Officer
18 - **Usuários afetados:** 100% da base (opt-in inicial)
 19 - **Time envolvido:** 2 devs, 1 QA, 1 DevOps
20
21 ### WHERE (Onde?)
22 - **Código:** Microserviço de autenticação
23 - **Banco:** Tabela user_2fa_settings
24 - **Interface:** Tela de configurações do usuário
25 - **Infra:** Redis para cache de tokens temporários
26
27 ### WHEN (Quando?)
28 - **Início:** Sprint 15 (01/02)
29 - **MVP:** Sprint 16 (15/02) - funcionando para admins
30 - **Beta:** Sprint 17 (01/03) - 10% dos usuários
31 - **GA:** Sprint 18 (15/03) - todos os usuários
32 - **Deadline crítica:** 31/03 - auditoria SOC2
33
34 ### HOW (Como?)
35 1. **Sprint 15:** Research e spike técnico
36 - Avaliar libs (speakeasy, otpauth)
37 - POC com Google Authenticator
38 - Definir fluxo de UX
39
40 2. **Sprint 16:** Implementação core
41 - API endpoints
42 - Geração QR Code
43 - Validação TOTP
44 - Testes unitários
45
46 3. **Sprint 17:** Refinamentos
47 - Backup codes
48 - UI/UX polido
49 - Recovery flow
50 - Testes E2E
51
52 4. **Sprint 18:** Rollout
53 - Feature flag progressivo
54 - Monitoramento
55 - Documentação
56
57 ### HOW MUCH (Quanto?)
58 - **Esforço:** 120 story points (~3 sprints)
59 - **Custo desenvolvimento:** 240h × R$150 = R$36.000
60 - **Custo infra adicional:** R$500/mês (Redis dedicado)
61 - **ROI esperado:**
62 - Evita 1 breach = economia de R$500k+
63 - Habilita contratos enterprise = R$50k/mês adicional
64 - Payback: < 1 mês

DEBUGGING COM 5W2H:

1 ## Bug: API retornando 504 timeout aleatoriamente

2
3 ### WHAT
4 - Timeout 504 Gateway Timeout
 5 - Afeta endpoint GET /api/reports/monthly
6 - Intermitente (30% das requisições)
7 - Começou após deploy da versão 2.3.0
8
9 ### WHY (5 Whys aplicado)
10 1. Por que timeout? → Query demorando >30s
11 2. Por que query lenta? → Fazendo full table scan
12 3. Por que full scan? → Índice não sendo usado
13 4. Por que índice ignorado? → Tipo de dado diferente após migration
14 5. Por que tipo mudou? → Migration com cast implícito
15
16 ### WHO
17 - **Reportou:** Cliente Enterprise (ACME Corp)
18 - **Afetados:** 50 clientes que usam relatórios
19 - **Responsável fix:** Eu + DBA
20 - **Code review missed:** Senior dev estava férias
21
22 ### WHERE
23 - **Ambiente:** Produção AWS us-east-1
24 - **Serviço:** report-service (Node.js)
25 - **Database:** PostgreSQL RDS
26 - **Query específica:** LineItem JOIN com Orders
27 - **Arquivo:** src/services/ReportService.js:147
28
29 ### WHEN
30 - **Primeiro ocorrência:** 15/01 14:30
31 - **Padrão:** Picos às 9h e 14h (maior uso)
32 - **Frequência:** 30% das requests
33 - **Urgência:** P1 - Cliente bloqueado
34
35 ### HOW (Solução)
36 1. **Imediato:** Aumentar timeout para 60s (paliativo)
37 2. **Curto prazo:** Adicionar índice correto
38 3. **Médio prazo:** Implementar cache Redis
39 4. **Longo prazo:** Redesign com materialized view
40
41 ### HOW MUCH
42 - **Impacto:** R$10k/dia em produtividade perdida
43 - **Custo fix:** 8h desenvolvimento + 2h deploy
44 - **Prevenção futura:** CI/CD com performance tests

TEMPLATE QUE CRIEI PARA O TIME:

1 # 5w2h_template.py
2 class TaskPlanner:
3 def __init__(self):
4 self.questions = {
5 'what': 'Qual é a tarefa/problema específico?',
6 'why': 'Por que isso é importante/urgente?',
7 'who': 'Quem são os responsáveis e afetados?',
8 'where': 'Onde será implementado/onde ocorre?',
9 'when': 'Qual o timeline e milestones?',
10 'how': 'Como será executado passo a passo?',
 11 'how_much': 'Qual o custo em tempo/recursos/dinheiro?'
12 }
13
14 def generate_template(self, task_type='feature'):
15 templates = {
16 'feature': self._feature_template(),
17 'bug': self._bug_template(),
18 'refactor': self._refactor_template()
19 }
20 return templates.get(task_type)
21
22 def validate_completeness(self, responses):
23 missing = [q for q in self.questions if not responses.get(q)]
24 return len(missing) == 0, missing

BENEFÍCIOS QUE OBSERVEI:

Clareza: Todos entendem escopo

Prevenção: Identifica riscos cedo

Alinhamento: Evita surpresas

Documentação: Histórico de decisões

Estimativa: Mais precisa com todos os detalhes"

2️⃣ DIAGRAMA DE ISHIKAWA (FISHBONE) PARA ROOT CAUSE

ANALYSIS
PERGUNTA: "Como você aplica Ishikawa em debugging?"
Resposta com Casos Reais

"Ishikawa é perfeito para bugs complexos onde a causa não é óbvia:

CASO REAL: Memory Leak em Aplicação Node.js

1 ## Problema: Aplicação consumindo 4GB RAM após 24h

2
3 ENVIRONMENT CODE
4 / \
5 Configs errados Memory não liberado
6 Node version antiga Closures mantendo refs
7 Heap size default Event listeners não removidos
8 \ /
9 \ /
10 \ /
11 INFRASTRUCTURE \ / METHODS
12 \ \ / /
13 RAM insuficiente \ MEMORY LEAK / Não usar WeakMap
14 No monitoring \_______________ / No profiling regular
15 No auto-restart \ / Deploy sem stress test
16 \/
 17 /\
18 DEPENDENCIES / \ DATA
19 \ / \ /
20 Lib com leak conhecido / \ Large datasets in memory
21 Version não atualizada / \ Cache sem TTL
22 Módulo nativo C++ / \ Logs acumulando

CÓDIGO DE ANÁLISE SISTEMÁTICA:

1 // ishikawa_debugger.js
2 class IshikawaDebugger {
3 constructor() {
4 this.categories = {
5 'ENVIRONMENT': [],
6 'CODE': [],
7 'METHODS': [],
8 'DATA': [],
9 'DEPENDENCIES': [],
10 'INFRASTRUCTURE': []
11 };
12 }
13
14 analyzeMemoryLeak() {
15 // ENVIRONMENT checks
16 this.checkNodeVersion();
17 this.checkHeapSize();
18 this.checkEnvVariables();
19
20 // CODE analysis
21 this.findEventListeners();
22 this.findClosures();
23 this.findGlobalVariables();
24
25 // METHODS review
26 this.checkDeploymentProcess();
27 this.checkTestingCoverage();
28 this.checkMonitoring();
29
30 // DATA patterns
31 this.analyzeCacheUsage();
32 this.checkDataStructures();
33 this.reviewLogRotation();
34
35 // DEPENDENCIES audit
36 this.auditPackages();
37 this.checkForKnownLeaks();
38 this.reviewNativeModules();
39
40 // INFRASTRUCTURE
41 this.checkResourceLimits();
42 this.reviewAutoScaling();
43 this.analyzeMetrics();
44 }
 45
46 checkEventListeners() {
47 // Encontrar event listeners não removidos
48 const listeners = process.listeners();
49 const suspicious = [];
50
51 for (const event in listeners) {
52 if (listeners[event].length > 10) {
53 suspicious.push({
54 event,
55 count: listeners[event].length,
56 issue: 'Possible listener leak'
57 });
58 }
59 }
60
61 this.categories.CODE.push(...suspicious);
62 }
63
64 generateReport() {
65 const criticalIssues = [];
66
67 for (const [category, issues] of Object.entries(this.categories)) {
68 if (issues.length > 0) {
69 criticalIssues.push({
70 category,
71 issues,
72 priority: this.calculatePriority(issues)
73 });
74 }
75 }
76
77 return {
78 diagram: this.renderDiagram(),
79 issues: criticalIssues.sort((a, b) => b.priority - a.priority),
80 recommendations: this.generateRecommendations(criticalIssues)
81 };
82 }
83 }
84
85 // Uso prático
86 const debugger = new IshikawaDebugger();
87 debugger.analyzeMemoryLeak();
88 const report = debugger.generateReport();
89 console.log(report);

OUTRO EXEMPLO: Performance Degradation

1 ## Problema: API 10x mais lenta após refactor

2
3 PEOPLE PROCESS
4 / \
5 Junior fez refactor No code review
 6 Férias do senior No performance test
7 Pressão de prazo Deploy direto pra prod
8 \ /
9 \ /
10 \ /
11 TECHNOLOGY \ SLOW API / METHODS
12 \ \ / /
13 ORM N+1 query \ / No monitoring
14 No query cache \_______________/ No load testing
15 Missing index Algorithm O(n²)
16
17 MATERIALS MEASUREMENTS
18 | |
19 Dataset cresceu 100x No benchmarks
20 Imagens não otimizadas No APM tools
21 JSON responses huge No SLA defined

PROCESSO ESTRUTURADO QUE USO:

1. Definir problema claramente

Métrica específica (response time > 1s)

Quando começou

Impacto mensurável

2. Brainstorm por categoria (6Ms)

Man: Pessoas envolvidas

Method: Processos usados

Machine: Tecnologia/Infra

Material: Dados/Inputs

Measurement: Métricas/Monitoring

Milieu: Ambiente/Context

3. Investigar cada ramo

1 // Exemplo: Investigar ramo "Database"

2 async function investigateDatabase() {
3 const checks = {
4 slowQueries: await checkSlowQueryLog(),
5 missingIndexes: await analyzeMissingIndexes(),
6 locks: await checkDeadlocks(),
7 connections: await checkConnectionPool(),
8 statistics: await checkTableStatistics()
9 };
10
11 return checks.filter(check => check.severity === 'HIGH');
12 }

4. Priorizar por impacto

Pareto: 80% dos problemas vêm de 20% das causas

 Quick wins primeiro

Root cause vs symptoms

5. Documentar aprendizados

1 ## Post-Mortem: Memory Leak Incident

2
3 ### Root Causes (Ishikawa Analysis)
4 - **Primary:** EventEmitter listeners não removidos (CODE)
5 - **Secondary:** Node.js heap default muito baixo (ENVIRONMENT)
6 - **Contributing:** Falta de monitoring de memória (METHODS)
7
8 ### Actions Taken
9 - [ ] Implementar removeListeners em todos destroys
10 - [ ] Aumentar heap para 2GB
11 - [ ] Adicionar alertas de memória > 70%
12
13 ### Prevention
14 - [ ] Lint rule para event listeners
15 - [ ] Memory leak test no CI/CD
16 - [ ] Training sobre gerenciamento de memória

VANTAGEM DO ISHIKAWA: 'Força pensar sistematicamente, não só no código. Muitos bugs são causados por
fatores externos - ambiente, dados, processo. Ishikawa garante que não perdemos nada.'"

3️⃣ FMEA (FAILURE MODE AND EFFECTS ANALYSIS) PARA

PREVENÇÃO
PERGUNTA: "Como você usa FMEA em desenvolvimento?"
Resposta com Framework Prático

"FMEA me ajuda a prever e prevenir falhas antes de acontecerem:

TEMPLATE FMEA PARA SOFTWARE:

 1 ## FMEA - Sistema de Pagamento
2
3 | Component | Failure Mode | Effect | Severity | Cause | Occurrence | Detection | RPN |
Action |
4 |-----------|-------------|--------|----------|-------|------------|-----------|-----|-
-------|
5 | Payment Gateway | Timeout na API | Pagamento falha | 9 | Alta latência | 5 |
Monitoring | 270 | Circuit breaker |
6 | Database | Deadlock | Transação travada | 8 | Concurrent updates | 3 | Logs | 72 |
Ordenar locks |
7 | Credit Card | Token expirado | Cobrança falha | 10 | TTL muito curto | 2 | Error
handling | 60 | Refresh automático |
8 | Webhook | Não recebe callback | Status desatualizado | 6 | Network issue | 4 | Retry
queue | 96 | Exponential backoff |
9 | Cache | Dados stale | Info incorreta | 7 | TTL muito longo | 3 | Validation | 63 |
Smart invalidation |
10
11 RPN = Severity × Occurrence × Detection

IMPLEMENTAÇÃO EM CÓDIGO:

1 # fmea_analyzer.py
2 class FMEAAnalyzer:
3 def __init__(self):
4 self.severity_scale = {
5 'CATASTROPHIC': 10, # Data loss, security breach
6 'CRITICAL': 9, # Service down
7 'MAJOR': 7, # Feature broken
8 'MODERATE': 5, # Degraded performance
9 'MINOR': 3, # UI glitch
10 'NEGLIGIBLE': 1 # Cosmetic
11 }
12
13 self.occurrence_scale = {
14 'VERY_HIGH': 10, # >50% chance
15 'HIGH': 7, # 20-50%
16 'MODERATE': 5, # 5-20%
17 'LOW': 3, # 1-5%
18 'VERY_LOW': 1 # <1%
19 }
20
21 self.detection_scale = {
22 'IMPOSSIBLE': 10, # No detection
23 'VERY_HARD': 8, # Manual only
24 'HARD': 6, # Complex monitoring
25 'MODERATE': 4, # Standard monitoring
26 'EASY': 2, # Automated alerts
27 'TRIVIAL': 1 # Self-evident
28 }
29
30 def analyze_component(self, component):
31 failures = []
 32
33 # Analyze different failure modes
34 for failure_mode in self.identify_failure_modes(component):
35 severity = self.assess_severity(failure_mode)
36 occurrence = self.assess_occurrence(failure_mode)
37 detection = self.assess_detection(failure_mode)
38
39 rpn = severity * occurrence * detection
40
41 failures.append({
42 'mode': failure_mode,
43 'severity': severity,
44 'occurrence': occurrence,
45 'detection': detection,
46 'rpn': rpn,
47 'mitigation': self.suggest_mitigation(failure_mode, rpn)
48 })
49
50 return sorted(failures, key=lambda x: x['rpn'], reverse=True)
51
52 def suggest_mitigation(self, failure_mode, rpn):
53 if rpn > 200:
54 return 'IMMEDIATE ACTION REQUIRED'
55 elif rpn > 100:
56 return 'HIGH PRIORITY - Sprint planning'
57 elif rpn > 50:
58 return 'MEDIUM PRIORITY - Backlog'
59 else:
60 return 'LOW PRIORITY - Monitor'

FMEA PARA ARQUITETURA:

1 // architectural_fmea.js
2 const architectureFMEA = {
3 'Microservices': {
4 failures: [
5 {
6 mode: 'Service Discovery Failure',
7 effect: 'Services cannot communicate',
8 severity: 9,
9 causes: ['Consul down', 'Network partition'],
10 occurrence: 3,
11 currentDetection: 'Health checks',
12 detection: 4,
13 rpn: 108,
14 mitigations: [
15 'Multiple Consul instances',
16 'Client-side caching',
17 'Fallback to static config',
18 'Circuit breakers'
19 ]
20 },
21 {
22 mode: 'Cascade Failure',
23 effect: 'All services down',
24 severity: 10,
25 causes: ['No circuit breakers', 'Tight coupling'],
26 occurrence: 2,
27 currentDetection: 'APM tools',
28 detection: 5,
29 rpn: 100,
30 mitigations: [
31 'Implement circuit breakers',
32 'Bulkheads pattern',
33 'Rate limiting',
34 'Graceful degradation'
35 ]
36 }
37 ]
38 },
39
40 'Database': {
41 failures: [
42 {
43 mode: 'Connection Pool Exhaustion',
44 effect: 'No new connections possible',
45 severity: 8,
46 causes: ['Leaking connections', 'Spike in traffic'],
47 occurrence: 4,
48 currentDetection: 'Connection metrics',
49 detection: 3,
50 rpn: 96,
51 mitigations: [
52 'Connection timeout',
53 'Pool monitoring',
54 'Auto-scaling',
55 'Query optimization'
56 ]
57 }
58 ]
59 }
60 };
61
62 // Generate action plan based on RPN
63 function generateActionPlan(fmeaData) {
64 const actions = [];
65
66 for (const [component, data] of Object.entries(fmeaData)) {
67 for (const failure of data.failures) {
68 if (failure.rpn > 100) {
69 actions.push({
70 priority: 'HIGH',
71 component,
72 failure: failure.mode,
73 rpn: failure.rpn,
74 mitigations: failure.mitigations,
 75 owner: assignOwner(component),
76 deadline: calculateDeadline(failure.rpn)
77 });
78 }
79 }
80 }
81
82 return actions.sort((a, b) => b.rpn - a.rpn);
83 }

CASO PRÁTICO: Deploy de Nova Feature

1 ## FMEA - Feature: Integração com Provider de Pagamento

2
3 ### Análise de Riscos Pré-Deploy
4
5 | Failure Mode | S | O | D | RPN | Mitigation Strategy |
6 |-------------|---|---|---|-----|---------------------|
7 | API Key exposta | 10 | 2 | 8 | 160 | Vault, rotation, scanning |
8 | Rate limit exceeded | 6 | 5 | 2 | 60 | Caching, queue, backoff |
9 | Dados de cartão em log | 10 | 1 | 7 | 70 | Log sanitization, audit |
10 | Webhook não autenticado | 9 | 3 | 5 | 135 | HMAC validation |
11 | Double charging | 10 | 1 | 4 | 40 | Idempotency keys |
12 | Currency mismatch | 8 | 2 | 3 | 48 | Validation, tests |
13
14 ### Ações Tomadas (RPN > 100)
15 1. **API Key Security (RPN 160)**
16 - Implementado HashiCorp Vault
17 - Rotation automática 30 dias
18 - Secret scanning no CI/CD
19
20 2. **Webhook Authentication (RPN 135)**
21 - HMAC-SHA256 validation
22 - Timestamp verification
23 - IP whitelist
24
25 ### Resultado
26 - Zero incidentes de segurança em 6 meses
27 - 100% uptime do sistema de pagamento

MEU DIFERENCIAL: 'FMEA não é reativo como debugging - é proativo. Antes de codar, já identifico onde vai
quebrar. Isso economiza retrabalho e previne bugs em produção.'"
4️⃣ ANÁLISE SWOT PARA DECISÕES TÉCNICAS
PERGUNTA: "Como SWOT se aplica em tecnologia?"
Resposta com Exemplos Estratégicos

"Uso SWOT para decisões de arquitetura e tecnologia:

EXEMPLO 1: Escolha de Stack Tecnológica

1 ## SWOT: Migrar de Monolito Ruby para Microserviços Node.js

2
3 ### STRENGTHS (Forças Internas)
4 - Time tem experiência com Node.js
5 - Arquitetura atual bem documentada
6 - Boa cobertura de testes (85%)
7 - CI/CD maduro
8 - Budget aprovado para refactor
9
10 ### WEAKNESSES (Fraquezas Internas)
11 - Sem experiência com Kubernetes
12 - Dívida técnica acumulada
13 - Poucos DevOps no time
14 - Documentação de APIs fraca
15 - Dependência de seniors
16
17 ### OPPORTUNITIES (Oportunidades Externas)
18 - Mercado pedindo mais features
19 - Concorrentes lentos para inovar
20 - Talento Node.js disponível
21 - Ferramentas maduras (K8s, Istio)
22 - Cloud credits da AWS
23
24 ### THREATS (Ameaças Externas)
25 - Competidor lançou microserviços
26 - Complexidade operacional aumenta
27 - Custo cloud pode explodir
28 - Talento DevOps caro/escasso
29 - Riscos de segurança aumentam
30
31 ### Decisão Estratégica
32 ✅ MIGRAÇÃO GRADUAL
33 - Strangler Fig Pattern
34 - Começar com serviços não-críticos
35 - Investir em treinamento K8s
36 - Contratar DevOps senior
37 - POC de 3 meses primeiro

CÓDIGO PARA ANÁLISE SWOT:

1 # swot_analyzer.py
2 class TechSWOTAnalyzer:
3 def __init__(self, technology_choice):
4 self.tech = technology_choice
5 self.swot = {
6 'strengths': [],
7 'weaknesses': [],
8 'opportunities': [],
9 'threats': []
10 }
11 self.weights = {
12 'strengths': 0.25,
13 'weaknesses': 0.25,
14 'opportunities': 0.25,
15 'threats': 0.25
16 }
17
18 def analyze_migration(self, from_stack, to_stack):
19 # Analyze Strengths
20 self.swot['strengths'] = [
21 ('team_knowledge', self.assess_team_knowledge(to_stack)),
22 ('performance_gain', self.calculate_performance_gain()),
23 ('scalability', self.assess_scalability_improvement()),
24 ('cost_reduction', self.estimate_cost_savings())
25 ]
26
27 # Analyze Weaknesses
28 self.swot['weaknesses'] = [
29 ('migration_risk', self.assess_migration_risk()),
30 ('training_needed', self.calculate_training_hours()),
31 ('legacy_dependencies', self.count_dependencies()),
32 ('downtime_risk', self.estimate_downtime())
33 ]
34
35 # Analyze Opportunities
36 self.swot['opportunities'] = [
37 ('market_demand', self.analyze_market_trends()),
38 ('talent_availability', self.check_job_market()),
39 ('ecosystem_maturity', self.assess_tool_ecosystem()),
40 ('competitive_advantage', self.calculate_time_to_market())
41 ]
42
43 # Analyze Threats
44 self.swot['threats'] = [
45 ('competitor_moves', self.analyze_competitors()),
46 ('technology_obsolescence', self.predict_longevity()),
47 ('security_risks', self.assess_security_posture()),
48 ('vendor_lock_in', self.calculate_lock_in_risk())
49 ]
50
51 return self.calculate_decision_score()
52
53 def calculate_decision_score(self):
54 score = 0
55
 56 # Positive factors
57 for strength in self.swot['strengths']:
58 score += strength[1] * self.weights['strengths']
59
60 for opportunity in self.swot['opportunities']:
61 score += opportunity[1] * self.weights['opportunities']
62
63 # Negative factors
64 for weakness in self.swot['weaknesses']:
65 score -= weakness[1] * self.weights['weaknesses']
66
67 for threat in self.swot['threats']:
68 score -= threat[1] * self.weights['threats']
69
70 return {
71 'score': score,
72 'recommendation': self.get_recommendation(score),
73 'action_items': self.generate_action_plan()
74 }
75
76 def get_recommendation(self, score):
77 if score > 70:
78 return 'STRONGLY RECOMMEND - Proceed immediately'
79 elif score > 40:
80 return 'RECOMMEND - Proceed with caution'
81 elif score > 10:
82 return 'NEUTRAL - Need more analysis'
83 else:
84 return 'NOT RECOMMEND - Too risky'

EXEMPLO 2: Avaliação de Framework

1 ## SWOT: Adotar React vs Vue.js vs Angular

2
3 ### React
4 **S:** Huge ecosystem, Meta backing, job market
5 **W:** Learning curve, too many choices
6 **O:** React Native for mobile, Server Components
7 **T:** License changes history, framework fatigue
8
9 ### Vue.js
10 **S:** Gentle learning curve, great docs, lightweight
11 **W:** Smaller ecosystem, less enterprise adoption
12 **O:** Growing popularity, Vue 3 composition API
13 **T:** Single person origin, smaller community
14
15 ### Angular
16 **S:** Full framework, TypeScript first, Enterprise ready
17 **W:** Steep learning curve, verbose, heavy
18 **O:** Google backing, consistent updates
19 **T:** Losing market share, complex for simple apps
20
21 ### Decision Matrix
 22 | Criteria | Weight | React | Vue | Angular |
23 |----------|--------|-------|-----|---------|
24 | Learning Curve | 20% | 7 | 9 | 5 |
25 | Ecosystem | 25% | 10 | 7 | 8 |
26 | Performance | 20% | 8 | 9 | 7 |
27 | Team Experience | 20% | 6 | 8 | 4 |
28 | Future Proof | 15% | 9 | 7 | 7 |
29 | **Total** | 100% | **8.15** | **7.95** | **6.35** |
30
31 Decisão: React (mas Vue.js muito próximo)

SWOT PARA DECISÕES DO DIA A DIA:

1 // Exemplo: Escolher biblioteca de testing

2 const testingLibrariesSWOT = {
3 'Jest': {
4 strengths: ['Facebook', 'Zero config', 'Snapshot testing'],
5 weaknesses: ['Large size', 'Sometimes slow'],
6 opportunities: ['Industry standard', 'Great mocking'],
7 threats: ['Vitest growing fast']
8 },
9
10 'Vitest': {
11 strengths: ['Fast', 'Vite compatible', 'Jest compatible'],
12 weaknesses: ['New', 'Smaller community'],
13 opportunities: ['Growing rapidly', 'Modern'],
14 threats: ['May not mature']
15 },
16
17 'Mocha': {
18 strengths: ['Flexible', 'Mature', 'Lightweight'],
19 weaknesses: ['Needs configuration', 'No built-in assertions'],
20 opportunities: ['Stable', 'Well documented'],
21 threats: ['Losing market share']
22 }
23 };
24
25 function quickSWOTDecision(options) {
26 // Quick scoring based on our priorities
27 const priorities = {
28 'speed': 0.3,
29 'community': 0.3,
30 'features': 0.2,
31 'stability': 0.2
32 };
33
34 // Calculate scores...
35 return bestOption;
36 }

MINHA APLICAÇÃO PRÁTICA: 'Antes de propor qualquer mudança tecnológica, faço SWOT. Evita decisões
emocionais e mostra que penso estrategicamente, não só tecnicamente.'"
5️⃣ DMAIC PARA MELHORIA CONTÍNUA
PERGUNTA: "Como você aplica DMAIC em desenvolvimento?"
Resposta com Case Completo

"DMAIC é perfeito para otimização sistemática:

CASE: Melhorar Performance do Build (CI/CD)

1 ## DMAIC: Reduzir Tempo de Build de 45min para <15min

2
3 ### 1. DEFINE (Definir o Problema)
4 - **Problema:** Build demoram 45 minutos em média
5 - **Impacto:** 10 devs × 3 builds/dia × 45min = 22.5h/dia perdidas
6 - **Meta:** Reduzir para menos de 15 minutos
7 - **Prazo:** 2 sprints (4 semanas)
8 - **ROI Esperado:** 15h/dia recuperadas = R$2.250/dia
9 // metrics_baseline.js
10 const buildMetrics = {
11 current: {
12 average: 45, // minutes
13 p50: 42,
14 p95: 58,
15 p99: 65,
16 stages: {
17 checkout: 2,
18 dependencies: 8,
19 compile: 12,
20 tests: 18,
21 build: 3,
22 deploy: 2
23 }
24 },
25 target: {
26 average: 15,
27 reduction: 66.7 // percentage
28 }
29 };

2. MEASURE (Medir)

1 # measure_build_performance.py
2 import time
3 import json
4 from datetime import datetime
5
6 class BuildPerformanceAnalyzer:
7 def __init__(self):
8 self.measurements = []
9
10 def measure_stage(self, stage_name):
11 def decorator(func):
12 def wrapper(*args, **kwargs):
13 start = time.time()
14 result = func(*args, **kwargs)
15 duration = time.time() - start
16
17 self.measurements.append({
18 'stage': stage_name,
19 'duration': duration,
20 'timestamp': datetime.now().isoformat(),
21 'success': result.get('success', True)
22 })
23
24 return result
25 return wrapper
26 return decorator
27
28 @measure_stage('dependencies')
29 def install_dependencies(self):
30 # npm ci ou yarn install
31 pass
32
33 @measure_stage('tests')
34 def run_tests(self):
35 # jest ou mocha
36 pass
37
38 def generate_report(self):
39 total = sum(m['duration'] for m in self.measurements)
40
41 report = {
42 'total_duration': total,
43 'stages': {},
44 'bottlenecks': []
45 }
46
47 for measurement in self.measurements:
48 stage = measurement['stage']
49 if stage not in report['stages']:
50 report['stages'][stage] = []
51 report['stages'][stage].append(measurement['duration'])
52
53 # Identify bottlenecks (Pareto - 80/20)
54 sorted_stages = sorted(
55 report['stages'].items(),
56 key=lambda x: sum(x[1]),
57 reverse=True
58 )
59
60 cumulative = 0
61 for stage, durations in sorted_stages:
62 stage_total = sum(durations)
 63 cumulative += stage_total
64
65 if cumulative <= total * 0.8: # 80% do tempo
66 report['bottlenecks'].append({
67 'stage': stage,
68 'impact': f'{(stage_total/total)*100:.1f}%',
69 'average': sum(durations)/len(durations)
70 })
71
72 return report

3. ANALYZE (Analisar)

1 ## Análise de Root Causes

2
3 ### Descobertas
4 1. **Tests (40% do tempo):**
5 - Testes de integração redundantes
6 - Sem paralelização
7 - Fixtures pesadas
8
9 2. **Dependencies (18% do tempo):**
10 - Sem cache
11 - Download toda vez
12 - Pacotes não usados
13
14 3. **Compile (27% do tempo):**
15 - Webpack não otimizado
16 - Source maps em produção
17 - Sem cache de transpilação
18
19 ### Análise de Pareto
20 // pareto_analysis.js
21 const paretoData = [
22 { stage: 'tests', time: 18, cumulative: 40 },
23 { stage: 'compile', time: 12, cumulative: 67 },
24 { stage: 'dependencies', time: 8, cumulative: 85 },
25 { stage: 'outros', time: 7, cumulative: 100 }
26 ];
27
28 // Focar nos top 3 = 85% do problema

4. IMPROVE (Melhorar)

1 # .github/workflows/optimized-ci.yml
2 name: Optimized CI Pipeline
3
4 on: [push, pull_request]
5
6 jobs:
7 build:
8 runs-on: ubuntu-latest
9
10 steps:
11 # MELHORIA 1: Cache de dependências
12 - uses: actions/cache@v3
13 with:
14 path: |
15 ~/.npm
16 node_modules
17 key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
18
19 # MELHORIA 2: Paralelização de testes
20 - name: Run Tests in Parallel
21 run: |
22 npm run test:unit &
23 npm run test:integration &
24 wait
25
26 # MELHORIA 3: Build incremental
27 - name: Incremental Build
28 run: |
29 npm run build:incremental
30 env:
31 WEBPACK_CACHE: true
32
33 # MELHORIA 4: Deploy condicional
34 - name: Deploy if needed
35 if: github.ref == 'refs/heads/main'
36 run: npm run deploy
37 // webpack.optimized.config.js
38 module.exports = {
39 cache: {
40 type: 'filesystem',
41 buildDependencies: {
42 config: [__filename]
43 }
44 },
45
46 optimization: {
47 splitChunks: {
48 chunks: 'all',
49 cacheGroups: {
50 vendor: {
51 test: /[\\/]node_modules[\\/]/,
52 priority: 10
53 }
54 }
55 }
56 },
57
58 // Apenas em dev
59 devtool: process.env.NODE_ENV === 'production'
60 ? false
 61 : 'eval-source-map'
62 };

5. CONTROL (Controlar)

1 # control_metrics.py
2 class BuildMonitor:
3 def __init__(self, threshold=15):
4 self.threshold = threshold
5 self.alerts = []
6
7 def check_build_time(self, duration):
8 if duration > self.threshold:
9 self.alert(f'Build exceeded threshold: {duration}min')
10 self.trigger_investigation(duration)
11
12 def alert(self, message):
13 # Send to Slack/Email
14 self.alerts.append({
15 'message': message,
16 'timestamp': datetime.now(),
17 'severity': self.calculate_severity(duration)
18 })
19
20 def weekly_report(self):
21 return {
22 'average': self.calculate_average(),
23 'trend': self.calculate_trend(),
24 'violations': len(self.alerts),
25 'improvements': self.suggest_improvements()
26 }
27 // Dashboard de monitoramento
28 const buildDashboard = {
29 metrics: {
30 before: {
31 average: 45,
32 p95: 58
33 },
34 after: {
35 average: 12, // 73% reduction!
36 p95: 16
37 }
38 },
39
40 savings: {
41 timePerDay: '18 hours',
42 costPerMonth: 'R$ 45,000',
43 deploymentFrequency: '3x increase'
44 },
45
46 nextSteps: [
47 'Implement distributed caching',
 48 'Move to build artifacts',
49 'Parallelize across machines'
50 ]
51 };

RESULTADO DO DMAIC:

Build time: 45min → 12min (73% redução)

Deploys/dia: 3 → 10

Developer happiness: 📈

ROI: 2 semanas payback"

6️⃣ PDCA (PLAN-DO-CHECK-ACT) PARA ITERAÇÕES

PERGUNTA: "Como PDCA se relaciona com Agile?"
Resposta Conectando Conceitos

"PDCA é a base filosófica do Agile - cada sprint é um ciclo PDCA:

1 ## PDCA vs SCRUM
2
3 | PDCA | Scrum Equivalent | Duração |
4 |------|-----------------|---------|
5 | PLAN | Sprint Planning | 4 horas |
6 | DO | Sprint Development | 2 semanas |
7 | CHECK | Sprint Review | 2 horas |
8 | ACT | Sprint Retrospective | 1.5 horas |

APLICAÇÃO PRÁTICA:

1 // pdca_sprint_manager.js
2 class SprintPDCA {
3 constructor(sprintNumber) {
4 this.sprint = sprintNumber;
5 this.cycle = {
6 plan: {},
7 do: {},
8 check: {},
9 act: {}
10 };
11 }
12
13 // PLAN - Sprint Planning
14 plan() {
15 this.cycle.plan = {
16 goal: 'Implement user authentication',
17 stories: [
18 { id: 'US-101', points: 5, description: 'Login form' },
19 { id: 'US-102', points: 8, description: 'JWT implementation' },
20 { id: 'US-103', points: 3, description: 'Password reset' }
21 ],
22 capacity: 16,
23 risks: ['OAuth provider availability', 'Security review'],
24 success_criteria: 'Users can login securely'
25 };
26 }
27
28 // DO - Execute Sprint
29 do() {
30 this.cycle.do = {
31 daily_progress: [],
32 impediments: [],
33 burndown: [],
34
35 recordDaily(day, completed, remaining) {
36 this.daily_progress.push({
37 day,
38 completed,
39 remaining,
40 velocity: completed / day
41 });
42 }
43 };
44 }
45
46 // CHECK - Sprint Review
47 check() {
48 this.cycle.check = {
49 completed: ['US-101', 'US-103'],
50 incomplete: ['US-102'],
51 demo_feedback: 'Password reset flow confusing',
52 metrics: {
53 velocity: 8,
54 quality: '2 bugs found',
55 coverage: '87%'
56 }
57 };
58 }
59
60 // ACT - Sprint Retrospective
61 act() {
62 this.cycle.act = {
63 what_went_well: [
64 'Pair programming helped',
65 'Daily standups were quick'
66 ],
67 what_went_wrong: [
68 'Underestimated OAuth complexity',
69 'Security review came late'
70 ],
71 action_items: [
72 'Schedule security review in planning',
 73 'Create OAuth spike for research',
74 'Document authentication flow'
75 ]
76 };
77
78 // Apply improvements to next cycle
79 this.applyImprovements();
80 }
81 }

MICRO-PDCA (Daily):

1 # daily_pdca.py
2 class DailyPDCA:
3 """Every day is a mini PDCA cycle"""
4
5 def plan_morning(self):
6 return {
7 'tasks': self.get_tasks_from_board(),
8 'priority': self.sort_by_priority(),
9 'estimate': self.estimate_completion(),
10 'blockers': self.identify_blockers()
11 }
12
13 def do_work(self):
14 for task in self.tasks:
15 self.start_timer(task)
16 self.execute(task)
17 self.stop_timer(task)
18 self.commit_code(task)
19
20 def check_evening(self):
21 return {
22 'completed': self.get_completed_tasks(),
23 'incomplete': self.get_incomplete_tasks(),
24 'actual_vs_estimate': self.compare_estimates(),
25 'quality': self.run_tests()
26 }
27
28 def act_improve(self):
29 if self.actual_time > self.estimated_time * 1.5:
30 self.log_lesson('Underestimated complexity')
31 self.adjust_future_estimates(1.3)
32
33 if self.test_failures > 0:
34 self.add_to_tomorrow('Write tests first')

VANTAGEM DO PDCA: 'É um framework mental universal. Uso para tudo - aprender nova tecnologia, resolver
bugs, melhorar processos. É o método científico aplicado ao desenvolvimento.'"
7️⃣ COMBINANDO FERRAMENTAS
PERGUNTA: "Como você integra todas essas ferramentas?"
Resposta Mostrando Sinergia

"Cada ferramenta tem seu momento e elas se complementam:

1 ## Framework Integrado de Qualidade

2
3 ### 1. PLANEJAMENTO (Início do Projeto)
4 - **5W2H:** Definir escopo completo
5 - **SWOT:** Avaliar viabilidade
6 - **FMEA:** Identificar riscos
7
8 ### 2. EXECUÇÃO (Durante Desenvolvimento)
9 - **PDCA:** Cada sprint/iteração
10 - **Ishikawa:** Quando bugs aparecem
11 - **5W2H:** Para cada user story
12
13 ### 3. PROBLEMAS (Troubleshooting)
14 - **Ishikawa:** Root cause analysis
15 - **5 Whys:** Drill down rápido
16 - **FMEA:** Prevenir recorrência
17
18 ### 4. OTIMIZAÇÃO (Melhoria Contínua)
19 - **DMAIC:** Projetos de melhoria
20 - **PDCA:** Iterações pequenas
21 - **SWOT:** Reavaliações periódicas

EXEMPLO INTEGRADO: Bug Crítico em Produção

1 # integrated_problem_solving.py
2 class IntegratedProblemSolver:
3 def __init__(self, incident):
4 self.incident = incident
5 self.tools_used = []
6
7 def solve(self):
8 # 1. 5W2H - Entender o problema
9 context = self.apply_5w2h()
10
11 # 2. Ishikawa - Encontrar causas
12 root_causes = self.apply_ishikawa()
13
14 # 3. FMEA - Prevenir futuras ocorrências
15 prevention = self.apply_fmea()
16
17 # 4. PDCA - Implementar fix
18 fix = self.apply_pdca()
19
20 # 5. DMAIC - Se problema recorrente
 21 if self.is_recurring():
22 optimization = self.apply_dmaic()
23
24 return self.generate_report()
25
26 def apply_5w2h(self):
27 return {
28 'what': self.incident.description,
29 'when': self.incident.timestamp,
30 'where': self.incident.service,
31 'who': self.incident.affected_users,
32 'why': 'TBD - needs Ishikawa',
33 'how': self.incident.error_trace,
34 'how_much': self.calculate_impact()
35 }
36
37 def apply_ishikawa(self):
38 categories = {
39 'code': self.analyze_code(),
40 'infrastructure': self.analyze_infra(),
41 'data': self.analyze_data(),
42 'process': self.analyze_process(),
43 'external': self.analyze_external()
44 }
45
46 return self.identify_root_cause(categories)
47
48 def apply_fmea(self):
49 failure_modes = []
50
51 for cause in self.root_causes:
52 failure_modes.append({
53 'mode': cause,
54 'severity': self.assess_severity(cause),
55 'occurrence': self.assess_occurrence(cause),
56 'detection': self.assess_detection(cause),
57 'rpn': self.calculate_rpn(cause),
58 'mitigation': self.design_mitigation(cause)
59 })
60
61 return sorted(failure_modes, key=lambda x: x['rpn'], reverse=True)
62
63 def apply_pdca(self):
64 return {
65 'plan': self.create_fix_plan(),
66 'do': self.implement_fix(),
67 'check': self.verify_fix(),
68 'act': self.deploy_and_document()
69 }

DASHBOARD DE QUALIDADE:

1 // quality_dashboard.js
 2 const QualityMetrics = {
3 tools_usage: {
4 '5W2H': { frequency: 'Daily', impact: 'High' },
5 'Ishikawa': { frequency: 'Weekly', impact: 'High' },
6 'FMEA': { frequency: 'Sprint', impact: 'Very High' },
7 'SWOT': { frequency: 'Quarterly', impact: 'Strategic' },
8 'DMAIC': { frequency: 'Project', impact: 'Transformational' },
9 'PDCA': { frequency: 'Continuous', impact: 'Incremental' }
10 },
11
12 results: {
13 bugs_prevented: '67% reduction',
14 mttr: '4h → 45min',
15 deployment_failures: '12% → 2%',
16 technical_debt: '30% reduced',
17 team_productivity: '25% increase'
18 },
19
20 roi: {
21 time_saved: '20h/week',
22 cost_avoided: 'R$50k/month',
23 quality_improvement: '89% → 97%'
24 }
25 };

MEU DIFERENCIAL ÚNICO: 'Enquanto outros devs correm para codar, eu paro 10 minutos para aplicar a
ferramenta certa. Resultado: menos retrabalho, código mais robusto, soluções mais elegantes. É investir 10
minutos para economizar 10 horas.'"

8️⃣ CASOS DE SUCESSO

"Dê um exemplo onde essas ferramentas fizeram diferença"

1 ## Case: Redução de 90% em Bugs de Produção

2
3 ### Contexto
4 - Projeto: Sistema de e-commerce (trabalho da faculdade)
5 - Problema: 20+ bugs por semana após deploy
6 - Impacto: 30% do tempo em firefighting
7
8 ### Abordagem com Ferramentas
9
10 #### 1. ISHIKAWA - Identificar Causas (Week 1)
11 PEOPLE PROCESS
12 / \
13 Júnior sozinho No code review
14 Sem pair programming No tests required
15 Pressão de prazo Deploy direto
16 \ /
17 \ /
18 \ BUGS /
19 \________________/
20 / \
21 / \
22 ENVIRONMENT TECHNOLOGY
23 | |
24 Dados de dev ≠ prod No type checking
25 Sem staging env Console.logs em prod
26 Configs hardcoded No error handling
27 #### 2. FMEA - Priorizar Riscos (Week 2)
28 | Risk | S | O | D | RPN | Action |
29 |------|---|---|---|-----|--------|
30 | No tests | 9 | 8 | 2 | 144 | Mandatory 80% coverage |
31 | No review | 8 | 7 | 3 | 168 | PR required |
32 | Bad data | 10 | 4 | 5 | 200 | Data validation |
33
34 #### 3. 5W2H - Plano de Ação (Week 3)
35 - **What:** Implementar quality gates
36 - **Why:** Reduzir bugs 80%
37 - **Who:** Todo time (pair programming)
38 - **Where:** CI/CD pipeline
39 - **When:** 2 sprints
40 - **How:** TDD + Code Review + Staging
41 - **How Much:** 40h investimento
42
43 #### 4. DMAIC - Execução (Weeks 4-8)
44 - **Define:** Bugs < 2/week
45 - **Measure:** Current 20/week
46 - **Analyze:** 80% são type errors
47 - **Improve:** TypeScript + Tests
48 - **Control:** Quality dashboard
49
50 ### Resultados
51 - Bugs: 20/week → 2/week (90% reduction)
52 - Deploy confidence: 30% → 95%
53 - Dev velocity: +40% (menos debugging)
54 - Team morale: 📈
55
56 ### Código Implementado
57 ```javascript
58 // quality_gates.js
59 const qualityGates = {
60 preCommit: [
61 'eslint',
62 'prettier',
63 'type-check'
64 ],
65 prePush: [
66 'unit-tests',
67 'coverage > 80%'
68 ],
69 preMerge: [
70 'integration-tests',
71 'code-review',
 72 'security-scan'
73 ],
74 preDeploy: [
75 'e2e-tests',
76 'performance-test',
77 'rollback-plan'
78 ]
79 };

Lições Aprendidas
1. Ferramentas de qualidade = menos retrabalho

2. Prevenção > Correção

3. Métricas guiam melhorias

4. Processo > Heroísmo individual

1 ---
2
3 ## **🎯 RESPOSTAS RÁPIDAS**
4
5 **"Por que ferramentas de engenharia são relevantes em TI?"**
6 "Software É engenharia. Google, Amazon, Netflix - todos usam essas ferramentas. Só têm
nomes diferentes: Post-mortem é Ishikawa, Blameless RCA é 5 Whys, Design Doc é 5W2H."
7
8 **"Isso não é overengineering?"**
9 "Pelo contrário. 10 minutos de análise economizam 10 horas de debugging. É como
escrever testes - investimento inicial que paga dividendos."
10
11 **"Como você convence o time a usar?"**
12 "Começo usando sozinho e mostro resultados. Quando reduzo bugs em 50%, todos querem
saber como. Lead by example."
13
14 **"Qual ferramenta é mais útil em TI?"**
15 "Ishikawa para debugging e FMEA para arquitetura. Mas 5W2H uso diariamente - é simples
e poderosa."
16
17 **"Isso não deixa desenvolvimento lento?"**
18 "Inicialmente sim, depois acelera muito. É como TDD - parece lento mas reduz
retrabalho. Measure twice, cut once."
19
20 ---
21
22 ## **✅ CHECKLIST DE FERRAMENTAS**
23
24 ### **Domínio Atual**
25 - ✅ 5W2H - Uso diário para planejamento
26 - ✅ Ishikawa - Root cause analysis
27 - ✅ FMEA - Análise de riscos
28 - ✅ SWOT - Decisões estratégicas
29 - ✅ DMAIC - Projetos de melhoria
30 - ✅ PDCA - Ciclos de iteração
31
32 ### **Como Demonstrar**
33 - ✅ Ter templates prontos
34 - ✅ Cases de sucesso documentados
35 - ✅ Métricas de impacto
36 - ✅ Código que implementa conceitos
37 - ✅ Whiteboard para desenhar diagramas
38
39 ---
40
41 ## **🚀 SUA MENSAGEM FINAL**
42
43 "Minha formação em engenharia não é bagagem - é superpoder. Enquanto outros developers
aprendem a debugar por tentativa e erro, eu aplico metodologias provadas há décadas.
Isso me torna mais eficiente, metódico e confiável. Não é sobre usar ferramentas por
usar - é sobre ter um arsenal mental para atacar problemas de forma estruturada. Cada
bug é uma oportunidade de aplicar Ishikawa. Cada projeto novo é um 5W2H. Cada decisão
técnica é um SWOT. Isso é o que me diferencia: trago rigor de engenharia para o mundo
ágil do software."
44
45 ---
46
47 **FIM DA PARTE 5**
48
49 *Próxima Parte: DevOps, CI/CD, Docker, Kubernetes e Cloud Basics*