Forward Deployed Engineer: da descoberta à entrega de valor

O papel do FDE e a tese do curso - Apresentação

Apresentando o curso

Olá! Eu sou Rodrigo Santos. Sejam bem-vindas e bem-vindos ao curso de Forward Deployed Engineer (Profissional Implantado no Cliente) da Descoberta à Entrega de Valor. Por questões de acessibilidade, eu vou me autodescrever.

Audiodescrição: Eu sou um homem de pele parda, tenho barba, cabelo curto, uso óculos e estou de camiseta preta.

O que veremos neste curso?

Antecipando os temas das aulas

Na Aula 1, vamos explorar o papel do FDI: o que faz, como atua e quais são suas responsabilidades principais.

Na Aula 2, apresentamos a primeira etapa do trabalho do FDI, a fase de Discovery (Descoberta): como nos comunicamos com as partes interessadas (stakeholders), como coletamos as demandas e desenhamos uma solução. Também esclarecemos as diferenças entre o FDI e outros papéis, deixando essas distinções explícitas.

Na Aula 3, consolidamos tudo o que encontramos com as partes interessadas (stakeholders) e elaboramos um primeiro desenho, um esboço inicial do que será a solução.

Na Aula 4, vamos desenvolver a POC (Proof of Concept, Prova de Conceito) e realizar o chamado teste caro. Esse é um teste que consome tempo e pode ter sucesso ou falhar. Caso falhe, discutiremos caminhos para prosseguir.

Na Aula 5, entenderemos como realizar a entrega para as partes interessadas (stakeholders) e como fazemos o handoff (transição) de tudo o que desenvolvemos para as equipes internas colocarem em produção e seguirem com a evolução do produto.

Organizando o curso

Como este curso está organizado?

Na Aula 1, apresentamos o papel do FDI e a tese do curso, que traz um checklist (lista de verificação) de quatro perguntas para que o FDI avalie se o problema em que está inserido requer a atuação do FDI, uma solução nova ou não.

Na Aula 2, mostramos como realizar um discovery (descoberta) completo, distinto daquele feito por PMs (gerentes de produto) e POs (proprietários de produto), indo da hipótese a quatro respostas. Quais quatro respostas? Veremos na Aula 2, mas, em essência, são respostas que nos dão o direcionamento para formular a solução.

A Aula 3 é dedicada à formulação. Com os resultados do discovery (descoberta), formulamos a solução e realizamos um teste de baixo custo. Teste de baixo custo é aquele que, antes de colocarmos a mão na massa, verifica o que precisamos confirmar para saber se a solução é viável.

Na Aula 4, desenvolvemos a POC (prova de conceito), apresentamos a POC já desenvolvida e compartilhamos os resultados do nosso teste CAR e dos testes A/B, analisando se foram satisfatórios e se foi necessário alterar algo no meio do caminho.

Na Aula 5, tratamos da entrega do protótipo para o time de TI da Águas do Vale, nosso cliente com o qual trabalharemos no case (estudo de caso) deste curso, e de como realizar a entrega para as pessoas stakeholders (partes interessadas), evidenciando o retorno de investimento e como o produto será utilizado no dia a dia.

Conte comigo. Vejo você na sequência.

O papel do FDE e a tese do curso - O que é um FDE?

Definindo o fdi e responsabilidades

Olá! Nesta aula, vamos explicar o que é um FDI.

O papel do FDI é atuar como profissional de engenharia dentro do cliente, com profundo conhecimento do negócio e da tecnologia. Como veremos ao longo do curso, o FDI navega pela área de negócio, compreende os problemas, desenha e desenvolve uma solução de tecnologia para o negócio.

Isso significa que o FDI precisa absorver e desempenhar papéis de diversas pessoas dentro de uma organização. Precisa ser uma pessoa consultora, ou seja, alguém que entende do negócio, mapeia processos, compreende KPIs de negócio e conversa com stakeholders de forma orientada ao negócio, não apenas à tecnologia. Também precisa desenvolver soluções tecnológicas a partir de especificações, trabalhar com dados, realizar análises de dados, desenvolver modelos de machine learning (aprendizado de máquina) e modelos estatísticos, além de conectar todas essas pontas — do negócio ao desenvolvimento e à ciência de dados — para construir uma solução, um produto de tecnologia que resolva o problema do negócio. É necessário medir a solução, verificar se deu certo, entender o que deu errado com os stakeholders, corrigir e fazer com que funcione. Esse é o FDI.

Recapitulando e deixando mais explícito o que cada um desses papéis entrega:

• Pessoa consultora: diagnóstico e recomendação; entendimento do negócio.
• Pessoa desenvolvedora: desenvolvimento de código a partir de uma especificação.
• Pessoa cientista de dados/analista de dados: construção de modelos, análises e entendimento de métricas de resultado.
• Pessoa gestora do produto/solução: gerenciamento do trabalho, manutenção do alinhamento entre todas as pessoas envolvidas, principalmente as de negócio, garantindo que a solução seja utilizada.

Tudo isso compõe o papel do FDI. Em síntese, o FDI desenvolve um software conectado ao negócio. É uma pessoa com dois trabalhos: está no mundo da tecnologia — junto com quem entende código, sistemas, fontes de dados e ERPs complexos, sabendo identificar quando existe um problema tecnológico — e também se comunica com o mundo do negócio. Essa é a grande vantagem do FDI.

Documentando e reutilizando módulos

O FDI tem um ciclo de trabalho que garante alguns pontos importantes. Isso garante que módulos, peças, entendimentos de negócio e componentes tecnológicos possam ser reaproveitados em outros casos. Quando o cliente apresenta um problema, o FDI conta com uma biblioteca de soluções e uma biblioteca de conhecimento de negócio das quais pode se valer. Pode acessar essa caixa de ferramentas, selecionar uma peça e começar a montar; se não existir a peça necessária, desenvolve essa peça.

É essencial que o FDI documente tudo e crie o que nós chamamos de aceleradores ou módulos, para que essas peças e engrenagens se conectem e formem um produto. Quando entra um cliente novo, é possível reaproveitar peças já utilizadas em outro cliente e acelerar o desenvolvimento. Esse é um ponto muito importante do FDI. A ideia de concentrar esse processo em uma pessoa é acelerar o desenvolvimento e manter todo o conhecimento em um único local, na pessoa do FDI.

Um ponto importante: tudo o que é feito para um cliente — para a dor, para o problema de um cliente — pode ser utilizado para outro problema do mesmo cliente, pode ser reaproveitado no mesmo cliente, pode ser reaproveitado em outro cliente e pode ser reaproveitado para outra solução tecnológica.

Como discutimos na linguagem de desenvolvimento, conseguimos criar módulos de soluções, e o FDI precisa se valer disso para manter uma caixa de ferramentas com várias opções.

Avaliando a necessidade de um fdi

Agora, vamos tratar de quando um problema exige a presença de um FDI. Todo bom FDI consegue identificar quando não é necessário. Isso não significa que não conseguiria resolver a situação, mas, muitas vezes, a solução já existe no mercado e pode ser encontrada de maneira mais rápida e gerar mais valor para o negócio; além disso, pode ser mais barata, entre outras vantagens. Portanto, o FDI precisa saber avaliar essas possibilidades.

Mas você pode estar se perguntando: quando é necessário um FDI? Nós usamos um framework (estrutura) de quatro filtros:

1. Solução pronta no mercado
   Se já encontramos a solução pronta no mercado, não precisamos desenvolvê-la novamente.

2. Problemas de informação entre sistemas
   Quando há informações desencontradas entre sistemas, precisamos criar vínculos entre essas informações. Aqui é necessária a presença de uma pessoa que consiga conectar essas pontas. Se os dados não são estruturados, eles devem ser; se existem diversas informações conflitantes entre bancos de dados, é aqui que soluções tecnológicas brilham. É também aqui que um FDI consegue entrar e apoiar a solução.

3. Regra de negócio específica
   Quando existe uma regra de negócio específica, há indício de necessidade de solução tecnológica. Quando não há uma regra específica, isso indica que não precisamos de uma solução tecnológica; precisamos melhorar processos dentro da empresa e, muitas vezes, capacitar melhor as pessoas que operam o negócio, não necessariamente construir tecnologia.

4. Medição de geração de valor
   Precisamos medir quando a solução está, de fato, gerando valor para o negócio. Se a solução não está gerando valor, precisamos saber o porquê e identificar as causas. Um FDI precisa ser capaz de definir métricas e fazer o acompanhamento do uso com as pessoas usuárias e com os stakeholders (partes interessadas), para verificar se a solução está trazendo valor.

São esses quatro filtros que utilizamos para decidir se um FDI é necessário ou não.

Aplicando os filtros na prática

Alguns exemplos:

• Exemplo 1: um caso de um chatbot (assistente virtual de conversação) para responder perguntas frequentes em um site (página na web). Existem soluções de mercado prontas que fazem isso. Um FDI consegue desenvolver essa solução? Sim, consegue. Mas precisamos alocar um FDI para desenvolvê-la? Não. Podemos alocar esse FDI para resolver outro problema que ainda não possua solução pronta de mercado.

• Exemplo 2: o caso em que vamos trabalhar neste curso, o Águas do Vale. É uma empresa de saneamento. É uma empresa que entrega água para as pessoas via encanamento. Vamos ver que a solução que vamos desenvolver para essa empresa não pode ser comprada pronta no mercado: é um problema muito específico da área de negócio. Os dados do cliente estão desorganizados e precisam ser corrigidos. Existem diversas fontes de dados que não se conectam. A regra de negócio é específica, bem entendida e está claramente definida. Existe um trecho do processo em que vamos atuar, e isso está muito bem delimitado. Além disso, alguém precisa acompanhar até a métrica mudar; ou seja, conseguimos medir se essa solução está trazendo retorno para o negócio ou não. É aqui que o trabalho de um FDI brilha. Passou nos quatro filtros? Podemos tentar desenvolver essa solução, alocando um FDI no problema.

Recapitulando os quatro filtros

Recapitulando, este é o checklist (lista de verificação) dos quatro filtros. Como já mencionamos anteriormente, no nosso caso Águas do Vale, ele passa no checklist (lista de verificação) dos quatro filtros.

Nos vemos no próximo vídeo. [♪]

O papel do FDE e a tese do curso - Pedido vago, problema construível

Enquadrando pedidos de negócio e diagnosticando necessidades

Agora vamos falar sobre como esses problemas normalmente chegam da área de negócios.

Os pedidos costumam chegar de forma um pouco vaga, mas, na realidade, são problemas concretos. O que acontece é que as pessoas das áreas de negócios às vezes não conseguem nos relatar exatamente qual é a questão. Vamos nos colocar no lugar de uma pessoa profissional de saúde: raramente alguém chega dizendo “tenho a doença X, A, B, C”; em geral, a pessoa diz: “Estou com uma dor em tal lugar.” Aqui é a mesma lógica.

É papel do FDI investigar, como se fôssemos realizar exames, para entender de fato qual é o problema e, então, montar e desenhar uma solução.

No nosso estudo de caso, na empresa Águas do Vale, a pessoa diretora da área pode simplesmente dizer: “Queremos reduzir perdas.” Parece vago e inócuo, mas essa é a dor percebida: há a sensação de que existe muita perda na distribuição de água, o que gera diversos prejuízos.

Portanto, é papel do FDI transformar esse problema vago em um problema concreto que possa ser resolvido com tecnologia, realizando “exames”, como mencionamos ao fazer a analogia com uma pessoa profissional de saúde.

Mapeando decisões, restrições, dados e sistemas

Para isso, precisamos entender alguns pontos. Em especial, precisamos compreender qual decisão de negócio é tomada, porque essa decisão provavelmente será alterada pelo nosso sistema, ou nosso sistema ajudará as pessoas de negócios a tomarem essa decisão de maneira mais rápida e mais assertiva.

Precisamos entender as restrições de negócio; não necessariamente conseguimos fazer tudo dentro do negócio. Existem restrições que podem ser orçamentárias ou de acesso. Quando nosso sistema enviar pessoas para algum lugar, precisamos conseguir medir; ou seja, precisamos de um sinal. Precisamos saber se a nossa solução, isto é, o nosso sistema, de fato vai melhorar o negócio ou não, e precisamos entregar essa resposta. Além disso, se melhorar, precisamos saber explicar o porquê; se não melhorar, também precisamos saber explicar o porquê. Tudo isso está no sinal.

Precisamos também entender onde estão os dados, onde as informações estão. Se não conseguirmos entender onde as informações estão, já teremos um problema. Então o FDI precisa saber navegar com as pessoas que tomam conta dos sistemas, normalmente a TI dessas empresas, e conseguir entender e conectar as informações, determinar os processos e quais informações esses processos utilizam. Esse é um diferencial do FDI.

Você pode estar pensando: esse é o trabalho de uma pessoa PM? Com algumas ressalvas, uma pessoa PM consegue levantar requisitos de negócio e traduzi-los para a equipe técnica, mas fazer levantamento de dados, entender os ERPs e entender os sistemas é atribuição de uma equipe de tecnologia. No nosso caso, o FDI deve ser a pessoa que consegue navegar por todos esses mundos.

Encerrando a aula e antecipando próximos tópicos

Por esta aula, é isso. Agora, vamos falar um pouco sobre o que veremos nas próximas aulas.

• Como vamos conversar com a área de negócio: precisamos chegar com uma hipótese — isso nós vamos ver na próxima aula.
• Na próxima aula, também vamos entender como conseguimos tirar resposta para as 4 perguntas que acabamos de ver.
• Na Aula 3, vamos entender o que é um teste barato. Antes de montar nossa solução, conseguimos entender o que pode dar errado. Já o teste caro, após nossa solução estar rodando, permite entender se o resultado satisfaz; se não satisfaz, por quê. É isso que nós vamos ver nas próximas aulas.

Sobre o curso Forward Deployed Engineer: da descoberta à entrega de valor

O curso Forward Deployed Engineer: da descoberta à entrega de valor possui 150 minutos de vídeos, em um total de 36 atividades. Gostou? Conheça nossos outros cursos de Arquitetura de Software em Back-end, ou leia nossos artigos de Back-end.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• O papel do FDE e a tese do curso
• Discovery, da hipótese às quatro respostas
• Formulação e o teste barato
• Construindo a PoC e o teste caro
• Entrega e handoff para o time de tecnologia