LuizTools

Autenticação JSON Web Token (JWT) em Node.js – Parte 2

Atualizado em 10/02/2020 para facilitar o entendimento.

JSON Web Token, o famoso JWT, é de longe a forma mais comum de segurança utilizada em web APIs RESTful depois do uso de SSL/TLS. Quando temos variados clientes consumindo nossas APIs, saber quem está autenticado ou não, ou ainda, que tem autorização ou não para fazer as chamadas, é importantíssimo.

Na primeira parte deste tutorial eu ensinei como implantar um mecanismo de JWT em uma API Node.js, adicionando esta importante camada de segurança. Dentre as dúvidas mais comuns acerca desta técnica está a segurança do token, afinal ele é o ponto mais exposto na técnica e sequestro de tokens é a forma mais comum de tentar burlar este mecanismo.

Claro que usando SSL (sugiro Lets Encrypt que é gratuito) esse risco de captura diminui consideravelmente uma vez que a conexão está criptografada e encorajo fortemente você a não aceitar requisições usando HTTP. No entanto, sabemos que para tudo existem brechas a serem exploradas principalmente por parte de pessoas maliciosas dentro da sua própria empresa muitas vezes…

O risco do JWT

Mas o token não é criptografado? Eu olhei ele e vi um monte de letras e números aleatórios…

Não, o token apenas é codificado em base64, uma representação textual de um conjunto de bytes, se você jogá-lo em qualquer decodificador online, verá as três partes que o compõem sendo que a única ilegível é a terceira onde temos a assinatura digital do servidor, atestando que aquele token foi gerado corretamente pelo seu servidor, o que impede que tokens fake se passem por tokens reais.

No entanto, para essa assinatura é necessário um segredo/secret. Esse segredo é usado tanto para assinar quanto para verificar a assinatura (e autenticidade) de um token. Se você tem apenas uma webapi que usa o JWT, isso é bem tranquilo. Agora, se você possui diferentes microservices e todos eles precisam de autenticação/autorização via JWT, então você tem um problema pois:

ou você faz com que o cliente se autentique em cada um dos microservices que vai usar;
ou você compartilha o secret entre todos eles.;

Uma solução possível para este problema é usar um API Gateway na frente de todos microserviços. Daí todos eles confiariam no gateway, sem ficar pedindo ou verificando tokens. Mas geralmente bons APIs gateways custam caro, embora dê pra fazer um mais caseiro.

Antes de eu entrar em uma possível solução barata para mitigar esse risco, vale lembrar que é importante você ter uma maneira fácil e rápida de invalidar tokens em caso de fraude de chamadas, para que a área de segurança possa agir rapidamente nestas situações. Falarei mais sobre isso no futuro.

Mas voltando ao assunto central: como podemos adicionar mais segurança em nosso JWT?

Entendendo o JWT

Para entendermos realmente o JWT na prática, primeiro compartilho abaixo uma pequena API que implementa este mecanismo, para que você possa acompanhar meu raciocínio sem precisar refazer todo tutorial anterior.

//index.js
var http = require('http'); 
const express = require('express') 
const app = express() 
var cookieParser = require('cookie-parser'); 
const bodyParser = require('body-parser');
var jwt = require('jsonwebtoken');
const secret = "meu-segredo";//esse segredo do JWT seria uma config

app.use(bodyParser.urlencoded({ extended: true })); 
app.use(bodyParser.json());
app.use(cookieParser()); 

//rota protegida
app.get('/clientes', verifyJWT, (req, res, next) => { 
    console.log("Retornou todos clientes!");
    res.status(200).json([{id:1,nome:'luiz'}]);
}) 

//rota de login
app.post('/login', (req, res, next) => { 
    if(req.body.user === 'luiz' && req.body.pwd === '123'){ 
        //auth ok 
        const id = 1; //esse id viria do banco de dados 
        var token = jwt.sign({ id }, secret, { 
            expiresIn: 300 // 5min 
        }); 
        
        console.log("Fez login e gerou token!");
        return res.status(200).send({ auth: true, token: token }); 
    }
    
    return res.status(401).send('Login inválido!'); 
})    

//rota de logout
app.post('/logout', function(req, res) { 
    console.log("Fez logout e cancelou o token!");
    res.status(200).send({ auth: false, token: null }); 
});

//função que verifica se o JWT é ok
function verifyJWT(req, res, next){ 
    var token = req.headers['x-access-token']; 
    if (!token) 
        return res.status(401).send({ auth: false, message: 'Token não informado.' }); 
    
    jwt.verify(token, secret, function(err, decoded) { 
        if (err) 
            return res.status(500).send({ auth: false, message: 'Token inválido.' }); 
        
        req.userId = decoded.id; 
        console.log("User Id: " + decoded.id)
        next(); 
    }); 
}    

var server = http.createServer(app); 
server.listen(3000);
console.log("Servidor escutando na porta 3000...")

//index.js

var http = require('http');

const express = require('express')

const app = express()

var cookieParser = require('cookie-parser');

const bodyParser = require('body-parser');

var jwt = require('jsonwebtoken');

const secret = "meu-segredo";//esse segredo do JWT seria uma config

app.use(bodyParser.urlencoded({ extended: true }));

app.use(bodyParser.json());

app.use(cookieParser());

//rota protegida

app.get('/clientes', verifyJWT, (req, res, next) => {

console.log("Retornou todos clientes!");

res.status(200).json([{id:1,nome:'luiz'}]);

})

//rota de login

app.post('/login', (req, res, next) => {

if(req.body.user === 'luiz' && req.body.pwd === '123'){

//auth ok

const id = 1; //esse id viria do banco de dados

var token = jwt.sign({ id }, secret, {

expiresIn: 300 // 5min

});

console.log("Fez login e gerou token!");

return res.status(200).send({ auth: true, token: token });

}

return res.status(401).send('Login inválido!');

})

//rota de logout

app.post('/logout', function(req, res) {

console.log("Fez logout e cancelou o token!");

res.status(200).send({ auth: false, token: null });

});

//função que verifica se o JWT é ok

function verifyJWT(req, res, next){

var token = req.headers['x-access-token'];

if (!token)

return res.status(401).send({ auth: false, message: 'Token não informado.' });

jwt.verify(token, secret, function(err, decoded) {

if (err)

return res.status(500).send({ auth: false, message: 'Token inválido.' });

req.userId = decoded.id;

console.log("User Id: " + decoded.id)

next();

});

}

var server = http.createServer(app);

server.listen(3000);

console.log("Servidor escutando na porta 3000...")

Para fazer funcionar este código, você terá de instalar os seguintes pacotes com o comando abaixo:

npm i express cookie-parser body-parser jsonwebtoken

1	npm i express cookie-parser body-parser jsonwebtoken

Se você rodar este projeto simples ele deve funcionar como esperado: a rota clientes só pode ser acessada com um JWT válido. Para obter um, POST na rota de login com usuário e senha corretos no corpo.

Se pegarmos o token abaixo…

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MSwiaWF0IjoxNTczODU0NDYwLCJleHAiOjE1NzM4NTQ3NjB9.k3SI3YTtHXb9vuaa6cjpcn-ojiNruoLjJpprwxZf3HU

1	eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MSwiaWF0IjoxNTczODU0NDYwLCJleHAiOjE1NzM4NTQ3NjB9.k3SI3YTtHXb9vuaa6cjpcn-ojiNruoLjJpprwxZf3HU

E jogarmos em um decodificador de base64 online teremos…

{"alg":"HS256","typ":"JWT"}
{"id":1,"iat":1573854460,"exp":1573854760}
t݄vrz#ɦŗ

{"alg":"HS256","typ":"JWT"}

{"id":1,"iat":1573854460,"exp":1573854760}

t݄vrz#ɦŗ

A primeira parte é o header, a segunda é o payload e a terceira é a assinatura do servidor (um hash criado usando o header + payload + secret configurado no servidor). A assinatura é que realmente garante que este token não é forjado, mas para que ela possa ser verificada, a API deve conhecer o mesmo secret usado na assinatura. E isso é um problema de segurança, afinal, se você tem uma senha que muita gente conhece, ela não é uma senha segura…

Mas como podemos garantir que este token possa ser usado em diferentes microservices sem compartilhar o secret com todos eles?

Assinatura assimétrica do JWT

Como estou falando de um token que navega entre diferentes microservices por meio inseguro (internet) o ideal é uma criptografia assimétrica, onde o emissor/servidor irá gerar o token assinado com a chave privada (de posse somente dele) e os consumidores/clientes podem verificá-lo usando a chave pública (de posse de todos microservices).

Assim, todos microservices confiam na emissão de tokens a partir um servidor central, enquanto podem validar sua assinatura para garantir que não foi forjado, sem saber o secret original.

Primeiro, vamos criar um par de chaves (uma pública e outra privada) usando o algoritmo RSA, um dos mais famosos e seguros do mundo de tipo assimétrico. O jeito mais fácil de gerar um par para fins de estudo é usando um gerador online, como esse aqui. O Format Scheme é PKCS #1 e o tamanho da chave varia de 256 bits a 2048 e embora chaves maiores sejam mais seguras (cada vez que você dobra o tamanho multiplica por 6x a dificuldade de quebra da chave) atente ao fato de que seu JWT deverá ser decifrado pelo servidor a cada requisição e que chaves maiores são mais demoradas para decifrar, mesmo com a chave certa.

Como é apenas para estudo, fiz com o menor tamanho comercialmente aceito (1024, enquanto que 2048 é o mais recomendado até 2030) e minha chave pública ficou assim (salve em um arquivo public.key):

-----BEGIN RSA PUBLIC KEY-----

MIGJAoGBAPDA6tLiWR4mS/qj2jFygGFc1t2TYcbmbxU8JQkX4Ytz2TMKQBXd+pLK

mNOzbsDrGE41gi5MET7qaSViADGyWGVn/Rc6FKPRnvMPbmySbqlmBaKR0iD/GYwL

61b3pW9f90PhC08uozJ2qcoypdnwKrb+j20FavgNz3mBGlZTF4+TAgMBAAE=

-----END RSA PUBLIC KEY-----

Enquanto que minha privada ficou assim (salve em um arquivo private.key):

-----BEGIN RSA PRIVATE KEY-----

MIICXAIBAAKBgQDwwOrS4lkeJkv6o9oxcoBhXNbdk2HG5m8VPCUJF+GLc9kzCkAV

3fqSypjTs27A6xhONYIuTBE+6mklYgAxslhlZ/0XOhSj0Z7zD25skm6pZgWikdIg

/xmMC+tW96VvX/dD4QtPLqMydqnKMqXZ8Cq2/o9tBWr4Dc95gRpWUxePkwIDAQAB

AoGBAM5fcGuJH39asLKPFhBg6G+NV5nkJmKLURlQzyZ2VB5oFf1Mgha8i3idNlfy

bbPtUo5oC8mH5xiZc7xZv3TaPi41McRpLfUOgbH2ngZpYwIUg6i6lqBC4Um7th2H

UOkgOr5yeD2dxE2UYLkvNHVSkOR5DsIoMregtaQ/1btbpk2BAkEA/j+Yh4+hQeao

6ymYzuPN4AoVmBbriilBjdxCChVEbiEJ0udE5oWRDxIRzo3nqUBKABELh+cnPDdM

rER656QhYQJBAPJphXbzE82CNKZS957clYySuefl+fatSGtESsaCFbRBP4JI+CB2

KnAfM0FxtOiWBG5Cwud/Dx1hNslAcEeZMXMCQA+aa4v2PplCxJ8aAGzCAkJ7m/On

hHEIMyO3nr3rrDVuBaJR2yKik9Ju83TPtKXociIq6aA/iWLiqevwj/JjWkECQEFn

Ov025DbkVHQzml+gQDEnPUVWBTUK16kpSct5OYXivNHYAiov9488u8WCej7uis98

770pyNgybGesHR8UNAUCQBj4PAEpDWlGe0CXLncAaDE84r6tZKnguFaDc7h8T7Fg

ZbL2d55m06jwEPDlz4hcXGuroBDipTC4kuIgShWcPMA=

-----END RSA PRIVATE KEY-----

Agora, em nossa API, vamos mudar levemente o nosso código que gera os tokens para que os mesmos sejam assinados de maneira assimétrica.

//rota de login
app.post('/login', (req, res, next) => { 
    if(req.body.user === 'luiz' && req.body.pwd === '123'){ 
        //auth ok 
        const id = 1; //esse id viria do banco de dados 
        var privateKey  = fs.readFileSync('./private.key', 'utf8');
        var token = jwt.sign({ id }, privateKey, { 
            expiresIn: 300, // 5min 
            algorithm:  "RS256" //SHA-256 hash signature
        }); 
        
        console.log("Fez login e gerou token!");
        return res.status(200).send({ auth: true, token: token }); 
    }
    
    return res.status(401).send('Login inválido!'); 
})

//rota de login

app.post('/login', (req, res, next) => {

if(req.body.user === 'luiz' && req.body.pwd === '123'){

//auth ok

const id = 1; //esse id viria do banco de dados

var privateKey = fs.readFileSync('./private.key', 'utf8');

var token = jwt.sign({ id }, privateKey, {

expiresIn: 300, // 5min

algorithm: "RS256" //SHA-256 hash signature

});

console.log("Fez login e gerou token!");

return res.status(200).send({ auth: true, token: token });

}

return res.status(401).send('Login inválido!');

})

As alterações estão apenas a partir da linha que declaro a privateKey, que substitui o nosso secret padrão que estávamos usando. A leitura do arquivo da chave é feita usando módulo fs (adicione um require no topo do arquivo) e nas opções de assinatura (terceiro argumento da função) dizemos o algoritmo de hashing que o RSA vai usar no seu algoritmo interno (RS256 no meu caso represa SHA-256).

Atenção: caso o seu arquivo de chave secreta tenha senha (como são geralmente os .PEM gerados pelo OpenSSL, que é a ferramenta que recomendo que você use) você deve passar um objeto {key, passphrase} no segundo argumento do sign ao invés de apenas a privatekey.

Agora, ao se autenticar, o servidor lhe retornará um token com assinatura criptografada de forma assimétrica, o que permite que vários serviços possam verificar sua assinatura usando a chave pública, ao invés da chave privada, usada para assinar o token da primeira vez, o equivalente ao secret original.

{
    "auth": true,
    "token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MSwiaWF0IjoxNTczOTA0NTc2LCJleHAiOjE1NzM5MDQ4NzZ9.jNevuavLpAuNeVhbZKAfV_ls8S1FIyCYAEI3T_fXvT7_-GGhxxUp_XpUlkvvTOS4v3mfJI20pYToCpsQAIVgG9d9Nj_u50MkwNjfO6EEDpBRT7ZwphPDpotTl_spXBasRT2gR-7vKTe6_o_jb0NQ13lkR74kTs7ZjCqM7qJUDfE"
}

{

"auth": true,

"token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6MSwiaWF0IjoxNTczOTA0NTc2LCJleHAiOjE1NzM5MDQ4NzZ9.jNevuavLpAuNeVhbZKAfV_ls8S1FIyCYAEI3T_fXvT7_-GGhxxUp_XpUlkvvTOS4v3mfJI20pYToCpsQAIVgG9d9Nj_u50MkwNjfO6EEDpBRT7ZwphPDpotTl_spXBasRT2gR-7vKTe6_o_jb0NQ13lkR74kTs7ZjCqM7qJUDfE"

}

Atenção: se você tiver o erro “digest too big for RSA key” quer dizer que sua chave é pequena demais para o texto a ser cifrado. Neste caso, use chaves maiores (eu não tive problema a partir de 1024-bit).

Verificando o JWT

Agora é hora de ajustar o código que verifica a assinatura do JWT. Enquanto que para criarmos a assinatura usamos a private key, para verificar a mesma usamos a public key.

//função que verifica se o JWT é ok
function verifyJWT(req, res, next){ 
    var token = req.headers['x-access-token']; 
    if (!token) 
        return res.status(401).send({ auth: false, message: 'Token não informado.' }); 
    
    var publicKey  = fs.readFileSync('./public.key', 'utf8');
    jwt.verify(token, publicKey, {algorithm: ["RS256"]}, function(err, decoded) { 
        if (err) 
            return res.status(500).send({ auth: false, message: 'Token inválido.' }); 
        
        req.userId = decoded.id; 
        console.log("User Id: " + decoded.id)
        next(); 
    }); 
}

//função que verifica se o JWT é ok

function verifyJWT(req, res, next){

var token = req.headers['x-access-token'];

if (!token)

return res.status(401).send({ auth: false, message: 'Token não informado.' });

var publicKey = fs.readFileSync('./public.key', 'utf8');

jwt.verify(token, publicKey, {algorithm: ["RS256"]}, function(err, decoded) {

if (err)

return res.status(500).send({ auth: false, message: 'Token inválido.' });

req.userId = decoded.id;

console.log("User Id: " + decoded.id)

next();

});

}

Note que a alteração foi bem sutil mesmo: carregamos a public key a partir do respectivo arquivo, passamos ela pra função verify, bem como um objeto informando o algoritmo de hashing que usamos junto do RSA (RS256 refere-se a SHA-256). Sim, é um array de algoritmos e passei apenas um.

Agora, se você obter um token pela rota de login e usá-lo para acessar a rota de clientes, verá que está funcionando como deveria e que no uso comum de apenas um cliente e servidor, não mudou em nada. Mas se tiver que confiar neste token em diferentes microservices, todos eles podem verificar a assinatura usando a chave pública.

Note que esta abordagem consome mais recursos computacionais que os tokens comuns. Esteja preparado para um aumento custo de hardware e/ou do tempo entre cada requisição que necessita deste token.

Espero que tenha gostado do artigo!

Curtiu o post? Então clica no banner abaixo e dá uma conferida no meu curso sobre programação web com Node.js!

Transformação Digital nas empresas

Se você está trabalhando com TI ou ao menos atuando no mundo corporativo assim como eu, certamente você já deve ter ouvido falar em Transformação Digital. Toda semana os principais sites de negócios comentam que a empresa X está fazendo sua transformação digital com a consultoria Y. Ou que a empresa W avança em sua transformação digital através da estratégia de implantar os processos ABC e a solução XPTO.

Mas será que é isso que significa fazer uma transformação digital? Implantar um ERP de mercado? Mudar para processos mais ágeis? Contratar uma consultoria boutique?

Afinal o que é uma transformação digital? O que é uma empresa digital?

Pensando em auxiliar quem está tentando descobrir as respostas para estas perguntas, no artigo de hoje trago algumas definições, estudos de mercado e experiências próprias, com o mínimo de achismo possível e o máximo de fatos e conceitos consolidados. Eu não inventei estas teorias e vários trechos eu li em outros lugares, sendo que informarei os links originais ou citarei o autor sempre que possível.

O que é Transformação Digital?

Esse é um termo que está cada vez mais famoso no Brasil, certo?

Mesmo por aqui, Transformações Digitais estão eclodindo em todas grandes empresas que não querem ficar de fora da profusão de matérias sobre o tema e da atenção dos investidores. No entanto, ser digital está longe de apenas informatizar processos manuais e trocar tecnologias, exige um redesenho da organização e uma evolução de sua cultura, dois elementos muito mais delicados.

A questão é que transformações de negócios, de qualquer tipo, são extremamente custosas e arriscadas. Para um negócio se tornar digital, não basta adicionar uma camada de tecnologia ou executar o desenvolvimento de software, você tem de inserir a mesma nas entranhas das camadas já existentes. Não é algo que você resolve investido no departamento de TI da empresa, mas distribuindo a TI por toda a empresa. Ou então o contrário, distribuindo business por toda TI. Não importa.

Não ajudei muito até aqui, certo? Calma, vai melhorar.

Muitas corporações estão se deparando com a necessidade de uma transformação digital, mesmo sem saber direito o que é uma.

De acordo com uma pesquisa de 2017 da CEB chamada “The New IT Operating Model for Digital”, dois-terços dos líderes de negócios acreditam que suas empresas vão perder competitividade se eles não se tornarem significativamente mais digitais. Eles entendem que a sobrevivência de suas empresas depende da sua habilidade de se adaptar a esse novo modelo da economia digital.

Mas o que é ser digital?

A versão online do dicionário Merriam-Webster oferece várias definições para o vocábulo “digital” e duas delas tem a ver com as transformações que estão acontecendo: “dados na forma de dígitos binários” e “interação tátil com os dedos”.

Tecnicamente, quando falamos de transformação digital expandimos esses dois conceitos básicos para mais quatro (segundo Phillipe Assouline, da InfoQ):

Experiência do Cliente (CX)
Cybersegurança
Automação
Mídias Sociais

Sendo assim, uma empresa digital é, por essas verticais, aquela que:

possui sistemas digitais;
sistemas estes de interação fácil e intuitiva (pra não ficarmos preso ao tátil);
cujos clientes (internos e externos) possuem uma boa experiência;
se preocupa com segurança cibernética;
possui processos automatizados;
entende e se comunica com seus clientes através de plataformas sociais;

Uma empresa que deseja se tornar digital deve considerar esses seis verticais de prioridades na hora de compor a sua “estratégia digital”. Estratégia essa que pode ser mais ou menos agressiva, mais ou menos intensa, mais inclinada para um vertical e menos para outro, mas sem negligenciar qualquer um deles.

Estratégia de Transformação Digital

No seu famoso Digital Transformation Guide, Assouline menciona que toda empresa passando por uma transformação digital está em um de três estágios: Going, Becoming ou Being Digital e que a jornada de transformação é justamente ir do primeiro estágio ao terceiro.

O autor entende que absolutamente TODAS empresas estão aptas a saírem da inércia e chegarem aos estágios um e dois, sendo que o dois é a famosa Transformação Digital que tanto se fala, onde sistemas, processos, comunicação, experiência do cliente e segurança são aperfeiçoados.

E aí que mora uma falha comum na definição da estratégia digital, ou melhor, na falta de UMA!

Ao invés de planejar como sairemos da inércia para um plano de transformação digital (estágio um, Going Digital) é comum vermos executivos mudando sistemas e implantando novos processos por toda empresa, sem entender o que se está buscando com cada mudança e como elas se conversam entre si, causando um caos completo e banalizando o termo “digital” como algo hipster que está na moda mas que não traz valor algum, coisa de empresa que gasta dinheiro para parecer cool.

O autor afirma que uma empresa digital está mais relacionada à conectividade da empresa com o mercado e a sua capacidade de entregar valor de maneira rápida e barata na ponta do que a adoção de novas tecnologias por si só.

Entender o nível desejado de união entre negócios + tecnologia que se quer alcançar é a chave para planejar, mapear e comunicar a intenção da organização com a transformação digital que se deseja iniciar. Para isso, Assouline, que é Head de Data Science e Market Insights em uma grande consultoria, criou um modelo de planejamento, representado na imagem abaixo, que ele chama de DTF: Digital Transformation Framework.

Por este framework, temos que a base de toda transformação digital deva ser a segurança cibernética (de comunicação e relação automática com os seres humanos), sustentando três pilares.

O primeiro pilar, Tema Digital, é fortemente baseado na definição do que é ser digital que comentei lá em cima, desdobrados em seis temas que fazem sentido para uma empresa fictícia. Enquanto que User Experience, Automation e Social Media são transcrições literais dos verticais abordados anteriormente (além da própria fundação de cybersecurity), Cryptography, Cloud Computing e IoT são demandas específicas da transformação digital de exemplo.

O autor não menciona isso explicitamente, mas menciona de leve que qualquer um dos temas devem ser substituídos pela sua estratégia de transformação, usando os verticais originais como base e as tendências atuais de mercado. Também é interessante notar que uma transformação pode ser faseada, e diferentes temas ou os mesmos temas com intensidades diferentes podem ser abordados em cada fase, como na metodologia Toyota Kata.

Só para citar como exemplo, no Agibank, onde trabalhei de 2017 a 2019 como Agile Coach, os temas da transformação digital eram 4: Infraestrutura Híbrida, Cybersegurança, Business Agility e Arquitetura Corporativa. Obviamente eu trabalhava focado no tema #3 e apenas apoiava o #2 e #4.

O segundo pilar, Orientação ao Cliente, te ajuda a definir se a estratégia é focada no cliente externo ou interno. Este framework assume que a estratégia digital pode ser composta por várias sub-estratégias, ou seja, podemos ter alguns temas que serão dedicados ao cliente externo em uma estratégia e outros temas ao cliente interno, por exemplo.

O terceiro pilar, Nível de Competência, cruza com os Temas Digitais, onde define-se qual o nível de competência a empresa irá buscar em cada um dos temas definidos para sua transformação digital, considerando três possíveis níveis: Competitivo, Indústria e Mínimo.

o nível Competitivo demonstra que a empresa deseja ser referência no tema específico e para isso investirá tempo e dinheiro acima da média do mercado; será um diferencial competitivo;
o nível Indústria demonstra que a empresa deseja atender aos padrões de mercado, às expectativas comuns para este tema em sua área de atuação; deseja se equiparar aos seus competidores;
por fim, o nível Mínimo demonstra que a empresa deseja apenas alcançar o mínimo de competência, entendendo que estará abaixo de seus concorrentes neste tema, mas que não o deixará desassistido;

Seguindo esta explicação do framework e continuando com o exemplo de transformação anterior, podemos plotar o segundo resultado usando o DTF, como uma proposta de transformação digital (totalmente hipotética, baseado nas necessidades e situação de um cliente fictício).

Neste exemplo do DTF preenchido temos uma estratégia composta por duas sub-estratégias, conforme explicação a seguir.

A estratégia 1 (verde claro) é de investir pesado em automação de processos para clientes externos (finais), tornando-se extremamente competitivo neste campo, acima de seus competidores, enquanto que a UX destes mesmos clientes externos deva atender às exigências do seu mercado, equiparando com seus concorrentes.

Já a estratégia 2 (amarelo) é de atender às exigências médias de mídias sociais para sua área de atuação com os clientes externos (talvez esta empresa não se comunicava com os clientes por redes sociais) e oferecer o mínimo de infraestrutura em nuvem para os clientes internos (talvez alguns ambientes para os time de tecnologia).

Essas duas estratégias não abrem mão de segurança digital, não sendo uma opção investir ou não nesse tema.

No próximo artigo, vou explorar como desdobrar esta estratégia em ação na sua empresa, ainda usando o framework DTF de Phillipe Assoulini.

Quer um material de referência para Transformações Ágeis em empresas? Conheça meu livro sobre o assunto clicando no banner abaixo.

Lean Inception: concepção de produtos enxutos

Atualizado em 26/01/2020!

A Lean Inception é uma técnica de concepção de produtos enxutos criada por Paulo Caroli, consultor da ThoughtWorks. É um método bem popular entre os agilistas brasileiros e é fortemente documentada no livro Lean Inception, do mesmo autor.

Caroli conta em suas palestras e livros que até então as inceptions (reuniões para concepção de um novo produto) duravam mais de um mês na TW e como Caroli atuava como consultor, não raro ele tinha de passar várias semanas por mês fora de casa, fazendo inceptions em clientes. No entanto, quando seu filho nasceu, ele decidiu que não mais ficaria tanto tempo longe da sua família e construiu uma técnica que, em apenas uma semana, é possível definir tudo que é necessário para se conseguir de fato tangibilizar um produto para que tenhamos insumos suficientes para o time de desenvolver começar a trabalhar.

Lean Inception, Sprint 0, Pré-Jogo…

A Lean Inception ocorre logo no início do projeto, no período que antecede a primeira sprint do time de desenvolvimento, período popularmente chamado de Sprint 0 ou Pré-Jogo. Embora o Scrum não aceite a existência de uma Sprint 0, é comum que isto aconteça de fato logo no início de grandes projetos onde a incerteza é tão grande que não vale a pena iniciar o desenvolvimento às cegas.

A ideia central da Lean Inception é fornecer momentos únicos de interação entre os membros do time e os stakeholders para definição dos conceitos elementares do produto, suas funcionalidades, jornadas do usuário, escopo das entregas, roadmap, etc. Tudo em uma semana muito intensa onde a cada dia novas atividades são realizadas e documentadas.

A ideia deste artigo é dar uma resumida no processo completo, cabendo aos interessados em aplicar esta dinâmica na prática buscar os livros do Caroli ou os treinamentos dele e dos treinadores certificados, como a Mayra Souza. O resumo do treinamento que fiz com esta última pode ser visualizado no vídeo abaixo.

Dia 0: Antes de Começar

O trabalho da Lean Inception começa antes do primeiro dia de dinâmicas. Você terá de montar um grupo heterogêneo de profissionais que possam colaborar com a definição do MVP do produto (objetivo final da inception) ou que estejam diretamente interessadas na construção do mesmo (usuários-chave ou stakeholders, por exemplo). Converse individualmente com cada uma destas pessoas e faça o convite pessoalmente, explicando a importância do comparecimento em todos os dias, como que funciona o processo, etc.

Monte uma lista de emails contendo o contato de todos os membros do grupo e dias antes da inception já comece a lembrá-los de que ela vai começar em breve. Certifique-se que seu grupo tenha até 30 pessoas e que tenha facilitadores suficientes para dar conta desta galera toda, em média 1 facilitador para cada 10 pessoas. Os facilitadores não executam as atividades, apenas conduzem, sem influenciar. Também garanta que todos os perfis abaixo estejam presentes neste grupo:

Product Owner do produto;
Scrum Master do time (geralmente um dos facilitadores);
profissionais técnicos do time (programador, analista, etc);
profissionais criativos de UX, UI, marketing, etc;
profissionais das áreas de negócio da empresa;
profissionais das áreas de atendimento da empresa;
usuários-chave do sistema;

Dia 1: Segunda-feira

Como a inception dura a semana inteira, o ideal é que ela comece em uma segunda-feira, para que não aconteça quebra de raciocínio. Mande um email reforçando o início da inception para todos os convidados e tenha um ambiente minimamente dedicado para que a dinâmica aconteça todos os dias no mesmo local e com os mesmos materiais, para que nada se perca entre cada um dos dias.

No primeiro dia as regras da inception são explicadas e em alto nível o que é a ideia do produto (geralmente o Product Owner dará este briefing). Geralmente pede-se que todos os membros do grupo se apresentem, expressem suas expectativas e faz-se uma dinâmica de energização para quebrar o gelo e animar o pessoal. Paulo Pontual, Zip-Zap-Zum, entre outras são sugeridas.

São formados grupos de trabalho, geralmente de 2 a 5 e na parte da manhã a primeira atividade é escrever a Visão do Produto. Cada time escreve a sua visão usando o template abaixo:

Para [cliente final],

cujo [problema que precisa ser resolvido],

o [nome do produto]

é um [categoria do produto]

que [benefícios-chave, razões para comprá-lo].

Diferente do [alternativa de mercado],

nosso produto [diferença-chave].

Depois, cada grupo apresenta a sua versão da visão do produto e ao término das apresentações, consolida-se em apenas uma só, gerando debates para que esta consolidação gere o melhor resultado. Documente a Visão do Produto com fotografias, isso será útil mais tarde, e preferencialmente transcreva-a para um cartaz que deverá estar fixo na sala da dinâmica a semana inteira.

Na parte da tarde (que tal uma energização após o almoço?) faz-se a dinâmica de definição do produto, também chamada de É-Não É, Faz Não-Faz. Aqui a ideia é que cada grupo trabalhe em um cartaz dividido em 4 quadrantes: É, Não É, Faz, Não Faz.

Em cada quadrante os membros do grupo discutem o que o produto é, o que ele não é, o que ele vai fazer e o que ele não vai fazer. Depois que cada grupo cria as suas definições individualmente, novamente cada grupo apresenta e o resultado final é consolidado em apenas uma versão após várias rodadas de discussão envolvendo cada quadrante.

As evidências destas duas dinâmicas são enviadas a todo o grupo no final do dia, bem como quaisquer outras fotos tiradas e uma descrição rápida de como o dia passou. Caso não seja possível deixar os cartazes consolidados nas paredes da sala, o facilitador deve guardar os mesmos para que seja possível manter o histórico da dinâmica completa.

Dia 2: Terça-feira

Começa-se o segundo dia reforçando o compromissos com todos via email, antes mesmo da dinâmica começar. Quando a dinâmica começa de fato, após a energização/quebra-gelo (sim, sempre faz-se uma no início do dia) inicia-se uma recapitulação do dia anterior, mostrando o produto final das dinâmicas de Visão do Produto e da É-Não é-Faz-Não Faz, para que todos estejam na mesma página novamente.

Uma vez que temos em alto nível os conceitos mais fundamentais do produto, é hora de falarmos de quem vai usá-lo/comprá-lo: as personas. As personas são arquétipos de usuários-chave típicos do produto. Cada produto possui no mínimo uma persona, enquanto que alguns podem possuir várias.

Cada grupo de trabalho pega uma persona para trabalhar, preenchendo um cartaz com os quatro quadrantes sobre a persona que escolheram:

nome e retrato: qual o nome ou apelido deste usuário-chave do produto? como ele se parece, se veste, etc?
perfil: idade, nacionalidade, etnia, renda, formação, profissão, etc
comportamentos: hobbies, crenças limitantes, crenças fortalecedoras, etc
necessidades: o que ele está buscando? Quais as suas dificuldades? As suas “coceiras”? As suas aspirações?

Uma vez que um produto pode ter várias personas, pode ser que cada grupo fique com uma diferente, não havendo necessidade de consolidação. Caso alguma persona se repita, deve-se consolidar os resultados obtidos para a mesma persona. De qualquer forma, cada grupo apresenta aos demais os resultados obtidos.

No mesmo dia, na parte da tarde, é hora de fazer a Descoberta das Features. Uma feature ou funcionalidade é a descrição de uma interação do usuário com o produto ou alguma ação que o sistema é capaz de realizar. As descrições das features devem ser simples e sem entrar em detalhes técnicos.

Para fazer esta descoberta de features existem diversas dinâmicas possíveis, desde simples brainstormings até entrevistas com usuários-chave. A técnica sugerida pela Lean Inception é fazer uma matriz onde cada coluna é algo que o sistema faz (lembra do Faz-Não Faz?) e cada linha é uma persona. O cruzamento das personas com o que o produto faz deve induzir às features necessárias.

Note que esta matriz é para ajudar o raciocínio para a descoberta de features, não para limitar a criatividade das pessoas nem para obrigar a fazer todas as combinações de coisas que o produto faz com as personas existentes. No entanto, é sempre interessante descartar features neste momento que de fato não auxiliem na resolução de nenhuma necessidade das personas, direta ou indiretamente.

Ao final do dia, tiram-se fotos dos cartazes das personas e do resultado da descoberta de features. É interessante também adicionar uma numeração nas features para facilitar a organização posterior. Envia-se um email a todos envolvidos com as evidências da dinâmica.

Este artigo ia ficar muito grande, resolvi quebrar em duas partes, sendo que a segunda parte está neste link. Para se aprofundar no assunto, leia o livro do Caroli, abaixo. Para mais conteúdo sobre Métodos Ágeis de desenvolvimento de software, recomendo o meu livro Scrum e Métodos Ágeis: Um Guia Prático e o meu curso sobre o mesmo assunto.