[Host: Adolfo Neto (UTFPR)]{.mark}

[Co-host: Ingrid Nunes (UFRGS)]{.mark}

Equipe: Danilo Ribeiro (Zup), Leonardo Fernandes (IFAL), Fabio Petrillo (Univ. Quebec), Gustavo Pinto (UFPA)

+———————————————————————–+ | Resumo: | +=======================================================================+ | Conversamos com Awdren Fontão, professor na Universidade Federal de | | Mato Grosso do Sul (UFMS). | | | | Site de Awdren: | | | | - | | [https://awdren.github.io/]{.underline} | | > (lá ele deixa link para todos os seus outros sites relevantes) | | | | Links Citados | | | | - CBSOFT [https://twitter.com/congressocbsoft]{.underline} | | | | - [The Business Value of Developer Relations: How and Why Technical | | > Communities Are Key To Your Success. | | > [https://de | | v.to/kimmaida/the-developer-relations-explainer-431o]{.underline}]{.mark} | | | | Artigos mencionados: | | | | - [Awdren de Lima Fontão, Sergio Cleger-Tamayo, Igor Wiese, Rodrigo | | > Pereira dos Santos, Arilo Claudio Dias-Neto: On value creation | | > in developer relations (DevRel): a practitioners' perspective. | | > ICGSE 2020: 33-42]{.mark} | | | | - [Awdren de Lima Fontão, Pedro Paes, Oswald Mesumbe Ekwoge, | | > Rodrigo Pereira dos Santos, Arilo Claudio Dias-Neto: Evaluating | | > Processes to Certify Mobile Applications During Developer | | > Relations Activities. IEEE Access 8: 137462-137476 | | > (2020)]{.mark} | | | | - [Raphael Oliveira, Camila Ajala, Davi Viana, Bruno B. P. Cafeo, | | > Awdren L. Fontão: Developer Relations (DevRel) Roles: an | | > Exploratory Study on Practitioners' opinions. SBES 2021: | | > 363-367]{.mark} | | | | Nossa equipe é formada por: | | | | - Leonardo Fernandes (IFAL) | | | | - Fabio Petrillo (UQAC) | | | | - Danilo Monteiro (Zup Innovation) | | | | - Adolfo Gustavo Serra Seca Neto (UTFPR) - co-host deste episódio | | | | - Ingrid Nunes (UFRGS) - co-host deste episódio | | | | Nosso site é | | [https://fr | | onteirases.github.io/]{.underline}. | | | | A edição deste episódio foi feita pela Zup Innovation | | [https://www.zup.com.br/]{.underline}. | +———————————————————————–+

Previsão de publicação: 15/04/2022

Streaming [http://www.youtube.com/watch?v=jvekbiPPEDU]{.underline}

Imagens

Ruim (para testes) [https://ibb.co/Xt04Rk8]{.underline}

Boa [https://ibb.co/ZxF7wyh]{.underline} {width=”6.5in” height=”3.7916666666666665in”}

Script do Episódio

Parte 1: Apresentação

[[ADOLFO]]{.mark} Hoje no Fronteiras da Engenharia de Software vamos conversar com Awdren Fontão, professor da UFMS. O tema do episódio de hoje será DevRel. Tudo bem, Awdren? Você pode se apresentar para as pessoas que nos escutam?

Awdren de Lima Fontão, curumim manauara com orgulho, torcedor do Garantido. Fiz a graduação em Ciência da Computação, mestrado e doutorado em Eng. de SW no ICOMP/UFAM. Há dois anos sou docente da Faculdade de Computação da Universidade Federal de Mato Grosso do Sul. Ah! Já gosto de tereré e do pôr do sol da cidade morena (Campo Grande). Apaixonado pelo ecoturismo e tento praticar uma filosofia "work-life balance". Minha dissertação de mestrado foi na área de ecossistemas de software analisando processos de certificação de apps durante treinamentos de desenvolvedores. E minha tese foi na área de Relações com Desenvolvedores - DevRel (do inglês, Developer Relations). Bem, eu trabalhei como DevRel, especificamente, evangelista de desenvolvedores, no INdT, à época Instituto Nokia de Tecnologia, e com a compra das unidades de dispositivos móveis pela Microsoft passei a atuar como DevRel para o Windows Phone. Os problemas identificados me levaram a fazer o mestrado e doutorado.

[CORTE AQUI]{.mark}

Parte 2 - Tema do Episódio

[[INGRID]]{.mark} Awdren, começando do princípio, o que DevRel?

Vamos começar com um cenário para ajudar no entendimento do conceito: imagine que você é uma organização de software com uma plataforma que já está sendo utilizada e tem um potencial enorme de gerar contribuições em torno dela. Essas contribuições ajudariam na expansão da plataforma e geram oportunidades de negócio e valor para os stakeholders e usuários.

Uns exemplos clássicos? A plataforma Android, iOS, Amazon AWS... um outro fora desse cenário de multinacionais: o Camunda, isso mesmo aquela plataforma que tem ferramenta de modelagem de workflows BPMN... Essas organizações sozinhas não conseguem atender a todas as demandas de seus desenvolvedores/usuários. Quanto às pessoas desenvolvedoras: gerar recursos para que possam desenvolver e evoluir suas contribuições. Para usuários “finais”, produtos gerados a partir das contribuições das pessoas desenvolvedoras.

Então, o que acontece: as organizações abrem suas estruturas para comunidades externas, formando comunidades especializadas. Essas comunidades compartilham de um ambiente, a infraestrutura/plataforma de software, colaborando e competindo. Esse cenário na Engenharia de Software já tem sido estudado como Ecossistemas de Software e não vou entrar pesado neste ponto.

Pois bem, mas como elas abrem a estrutura? Por meio de produtos para desenvolvedores: APIs, ferramentas, serviços, SDKs... Guardem aqui porque esse é um ponto importante: possuir um produto para devs!

Então, tudo resolvido? Há produtos e todo mundo vai contribuir, ser produtivo, gerar nicho, sustentar suas comunidades e consequentemente o ecossistema? Não. Não é simples.

As organizações possuem objetivos estratégicos em torno de suas plataformas. As pessoas desenvolvedoras possuem expectativas e uma jornada de experiências (alegrias, frustrações, etc...). Então, um ponto é estabelecer sinergia (equilíbrio entre os objetivos organizacionais e a experiência dos desenvolvedores). E pra isso precisamos de relações, interação, conexão...

Com isso, surge a área organizacional de Developer Relations (DevRel), como uma estratégia de apoiar a capacidade do ecossistema de manter suas comunidades durante o tempo e a sobreviver a mudanças. DevRel consiste em uma área que estabelece relações entre as comunidades de desenvolvedores e a organização em torno dos produtos. Para isso ela envolve um conjunto de instrumentos para criar e nutrir as comunidades em torno de uma plataforma. É responsável pela tarefa crítica de traduzir as interações das comunidades de desenvolvedores em relações confiáveis com a organização.

Vale deixar claro que não se limita a enviar e-mails comerciais para vender um produto. Não que seja ruim, isso faz parte do marketing para devs. Mas DevRel é mais abrangente, envolve sensibilizar, atrair, permitir a entrada, ativar, reter, reconhecer e tornar referência as pessoas da comunidade em torno de um algo que seja tangível para as pessoas desenvolvedoras.

Uma busca, hoje no Linkedin, apresenta mundialmente mais de 2200 vagas em DevRel.

Quais seriam os exemplos de algumas atividades? Os hackathons, os programas de reconhecimento para desenvolvedores (ex: Google Experts, Microsoft MVP, Amazon Heroes...), produção de conteúdo técnico (ex: tutoriais, vídeos, exemplos de código), suporte às pessoas da comunidade, organização de eventos e palestras...

E exemplos de alguns papéis: Profissional de DevRel, Evangelist, Advocate, Engenheiro de produto/Experiência de dev, marketing de dev, escritor técnico...

[[ADOLFO]]{.mark} Por que este termo novo, DevRel, refere-se a apenas relações com os desenvolvedores e não outros papéis, tais como testes, devops, etc.?

Awdren: Excelente pergunta, confesso que é algo que venho refletindo: os outros papeis como pessoas testadoras, designers... que também estão envolvidas em ações (ex: hackathons) e consomem/produzem recursos em tornos das plataformas. No momento, tratamos todas as pessoas dentro da mesma ação em torno do produto que a organização oferece. Algumas organização tratam mais como uma ação de Community. Talvez seria uma evolução no nome para Community Relations? Algo pra refletirmos enquanto área. A verdade é que a área mesmo ainda está se estabelecendo. Mas considerando o cenário das ações existentes, o foco de DevRel é em pessoas desenvolvedoras.

[[INGRID]]{.mark} E falando de forma mais ampla, trabalhar no desenvolvimento de software é um trabalho realizado em equipe como acontece em várias outras profissões. Por que isso aparece somente no contexto de desenvolvimento de software?

Digo que o contexto de desenvolvimento de software em um cenário de ecossistemas, ou seja, várias comunidades de desenvolvedores, em um ambiente compartilhado, gerando e evoluindo contribuições. Mas essas pessoas não têm contrato com a organização. No máximo aceitam um termo para usar alguma ferramenta, submeter uma contribuição (ex: apps, projeto em repositório open source)...

Então, a governança desse ecossistema não tem como ser o tradicional. Volto aqui com a questão da sinergia entre objetivos organizacionais e a experiência dos devs.

Outro ponto é o foco em estabelecer as relações da organização com desenvolvedores para expandir a plataforma de software. Sabemos que desenvolvedores com boas relações com a organização, que são reconhecidos, que têm acesso a um roadmap de recursos técnicos atualizados, por exemplo, divulgam a organização, se engajam, contribuem e trazem outras pessoas... Então, não é somente desenvolver contribuições de software, mas de evoluir a comunidade para, desta forma, evoluir a plataforma. Essa evolução pode iniciar de forma estruturada, totalmente conduzida pelo time de DevRel, e avançar para algo orgânico, onde as comunidades conseguem evoluir sozinhas contribuindo para os objetivos organizacionais. Inclusive a forma orgânica é a desejada, pois reduz custos operacionais.

Corte de [26:48]{.underline} a [34:07]{.underline}

Inclui as três linhas vermelhas abaixo.

[(CORTE ANTES DESTA PERGUNTA)]{.mark}

[[ADOLFO]]{.mark} O que uma empresa percebe como benefício ao designar pessoas para o papel de DevRel? Isso é algo que inclusive você investigou em um dos seus artigos sobre o assunto.

[(CORTE ANTES DESTA PERGUNTA)]{.mark}

[PERGUNTA REFEITA 2 VEZES]{.mark}

Vou trazer primeiro a definição de Amit e Zott (2001) sobre valor em negócios. O valor direciona a diferenciação do produto e é resultado de transações geradas nas interações humanas.

O framework se organiza em torno de quatro fontes de criação de valor: (1) Eficiência; (2) Retenção; (3) Inovação; (4) Complementaridade. Cada fonte é composta por itens que permitem a sua operacionalização. O produto tratado aqui se refere às contribuições de desenvolvedores e profissionais de DevRel, que envolvem recursos técnicos, como por exemplo, código fonte, eventos para desenvolvedores, soluções técnicas, envolvimento em portais de perguntas e respostas. Já as transações se referem a trocas entre a organização e a comunidade de desenvolvedores.

Eficiência: sugere que a eficiência das transações aumenta quando o custo por transações dentro do ecossistema diminui.

· Para eficiência vou destacar o item Faixa de Seleção: valor é percebido como os recursos desejados por desenvolvedores que podem gerar transações monetárias para o uso de produtos. Então, outro ponto é o conjunto de produtos que são destaque dentro do ecossistema que ajuda a promover a qualidade da plataforma tanto para desenvolvedores quanto para usuários. Para que os recursos desejados sejam oferecidos e produtos sejam promovidos, um aspecto que ajuda e é valoroso do ponto de vista dos participantes é a capacitação técnica dos desenvolvedores. A capacitação técnica pode ser promovida por meio de treinamentos planejados e executados pelos profissionais de DevRel.

Retenção: os desenvolvedores são motivados a participar de transações continuamente e estão dispostos a continuar seu relacionamento com a organização. Uma situação de retenção pode resultar no aumento da vontade dos desenvolvedores consumirem mais produtos do ecossistema.

· Para retenção no estudo vou destacar o item de valor “Ponto de Contato”: o valor pode ser o bom relacionamento entre os profissionais de DevRel e o desenvolvedor. Isto facilita o entendimento das expectativas do desenvolvedor. A ação do profissional de DevRel deve aproximar mais o desenvolvedor do produto como forma de obter feedback. O feedback também leva a compreensão da probabilidade de recomendação para outro desenvolvedor. O ponto de contato ainda permite manter o desenvolvedor mais próximo da organização e produzindo o que ela, realmente, precisa.

Complementaridade: envolve os cenários de agrupamento de vários produtos como forma de gerar mais valor do que oferecer o mesmo conjunto de produtos separadamente, ou seja, valor agregado.

· Para esse item de valor podemos falar sobre Produtos e Serviços: o investimento financeiro dos desenvolvedores nos recursos oferecidos pelos profissionais de DevRel e pelos produtos/serviços da organização. As informações precisas sobre o roadmap da organização para que os desenvolvedores possam adequar suas necessidades.

Inovação: refere-se à exploração com sucesso de novos produtos e serviços, bem como a introdução de novos métodos de condução e organização do negócio.

· Para inovação posso destacar o seguinte item de valor: Reestruturação de Processos e Transações, ou seja, o valor de DevRel como uma área essencial na estrutura organizacional, que ajuda a organização a se concentrar em custos e também na maturidade da organização. A área de DevRel impacta diretamente a experiência do desenvolvedor (as expectativas e percepções geradas a partir do uso de produtos do ecossistema), gera receita por meio do uso de serviços e ajuda no reconhecimento da marca, por isso, deve ser inserida estrategicamente como parte dos negócios da organização.

[[INGRID]]{.mark} E como esse papel de DevRel se diferencia para desenvolvedores que atuam em diferentes nichos, como front end (web e mobile applications), back end (e as diferentes plataformas e linguagens associadas)?

Ingrid, as estratégias em torno para atração, ativação, retenção e reconhecimento em torno do produto podem variar. Pois a experiência em torno de cada produto é diferente.

Por exemplo? Identificação dos perfis, de ambientes em que as comunidades estão mais presentes: No ambiente proprietário (portais de desenvolvedores, fóruns...), portais de perguntas e respostas (SO), canais de comunicação (gitter, slack), repositórios (Gitlab, github..). As comunidades possuem formas próprias de interação e isso precisa ser analisado e levado em consideração para definir estratégias de DevRel.

Então, resumindo as características do produto influenciam muito que estratégia deverá ser adotada.

[[ADOLFO]]{.mark} Falando de projetos de software de código aberto e código fechado. Existe diferença em como o DevRel atua? Ou não faz sentido o papel do DevRel fora do contexto de empresas?

[CORTE AQUI]{.mark}

Corte de 46:55 a 49:52

*** DIFERENÇA CÓDIGO ABERTO E CÓDIGO FECHADO ***

Um primeiro cenário é a empresa ter uma estratégia de ecossistema híbrido: uma plataforma proprietária, mas que tem pontos de abertura à comunidade (usando estratégias open-source). Por exemplo, Microsoft, Amazon fazem isso.

Um outro é o ecossistema open-source: as contribuições estão abertas ao resto dos atores ou ao público. Os valores se referem a compensações não monetárias (p.ex.: conhecimento e experiência ou precisa de satisfação). A Fundação Eclipse, o Gnome, a Fundação Apache e os ecossistemas do governo público são exemplos.

E, por fim, um ecossistema proprietário, em que a plataforma tem pontos de acesso específico para organizações parceiras a partir de contratos mais rigorosos. Normalmente protegido por processos de gerenciamento de propriedade intelectual e o valor refere-se à compensação monetária.

Em todos esses cenários pode haver o trabalho de DevRel.

No open-source: ajudar os desenvolvedores a coordenar a tecnologia e resolver problemas na comunidade (melhor e mais rápido).

No híbrido: contexto “ganhaganha”, equilíbrio entre a necessidade de autonomia e a integridade da plataforma dos desenvolvedores.

No proprietário: estabelecimento de mecanismos para monitorar os fatores que afetam a adoção da plataforma e o ambiente econômico do desenvolvedor, e para controlar os desenvolvedores por meios tecnológicos e não-tecnológicos.

*** FAZ SENTIDO DEVREL FORA DE EMPRESAS ***

Eu ajustaria para: não faz sentido DevRel sem produto para devs e o objetivo de estabelecer relações confiáveis entre sua organização e as comunidades. Se você tem um produto, uma plataforma que favoreça a interação entre os devs e sua organização, você pode ter área de DevRel sim.

[[INGRID]]{.mark} Você tem um estudo que investiga o papel de DevRel considerando diversas fontes de informação. Você pode dar um panorama das conclusões desse estudo?

Boa! No início da entrevista acabei falando, brevemente, sobre alguns papeis dentro da área de DevRel. Bem, na minha tese, apesar de descrever DevRel, fiquei com uma inquietação de realizar um trabalho futuro que ajudasse a compreender melhor os papeis dentro da área. E desta forma fundamentar o caminho para estruturar times de DevRel. A inquietação não era só minha, mas da comunidade científica e da indústria.

Considerando as discussões sobre os papéis de DevRel, Mary Thengvall (diretora de DevRel na Camunda) em diz: “Há uma variedade de papéis de DevRel, mas nenhum deles faz um trabalho particularmente bom em descrever exatamente o que o papel envolve”. E Kim Maida, um das autoras dos artigos identificados no estudo, argumenta: "Defensor do desenvolvedor (Developer Advocate) e Evangelista do desenvolvedor são frequentemente usados de forma intercambiável na indústria. Termos de prática, advocacia e evangelismo não são idênticos (...)". Ao analisar a comunidade científica, embora sejam poucos os estudos sobre DevRel, nenhum estudo investigou os papéis do DevRel na literatura existente sobre equipes de Engenharia de Software, comunidades de código aberto e ecossistemas de software.

Então, executamos um estudo como parte do TCC do Raphael Oliveira (aluno da FACOM/UFMS), que inclusive foi publicado no SBES 2021, para investigar os papeis DevRel, descrevendo as definições e habilidades identificadas para cada papel. Este estudo foi conduzido com base no método Grey Literature Review (GLR) usando como fontes Medium e Dev Community. Fizemos uma validação dos perfis no Linkedin das pessoas autoras dos artigos para garantir que eram profissionais de DevRel.

Alcançamos 132 artigos de 116 profissionais. E dentro desses artigos buscamos informações sobre os papeis. Ao aplicar o método de síntese temática, nós discutimos nove papeis de DevRel:

1. Profissional de DevRel;

2. Evangelista de Desenvolvedores (Evangelist);

3. Defensor de Desenvolvedores (Advocate);

4. Organizador de Comunidades:

5. Gerente de DevRel

6. Engenheiro de Programas de Desenvolvedores

7. Engenheiro de Experiência e de produto

8. Marketing de Desenvolvedores

9. Escritor(a) Técnico(a)

Explico brevemente os 3 mais frequentes:

1. Profissional de DevRel: é utilizado como uma função mais genérica. Provavelmente, quando não se tem objetivos específicos definidos, um cenário de iniciar a área de DevRel na organização, por exemplo;

2. Evangelista de Desenvolvedores (Evangelist): "a favor" da organização. Assume mais a venda dos produtos e objetivos da organização, atingindo os desenvolvedores do ecossistema em largura;

3. Defensor de Desenvolvedores (Advocate): O defensor parece ser "a favor" dos desenvolvedores; ele/ela tenta maximizar o serviço ao desenvolvedor. Pode parecer que o defensor não "prioriza" os objetivos da organização, mas ele o faz a partir de uma relação mais próxima com a pessoa desenvolvedora.

Implicações do estudo:

Para a pesquisa: A pesquisa DevRel existente em ES até menciona alguns papeis como parte de um ecossistema ou influenciadores da comunidade e modelos de DevRel. No entanto, é necessário pesquisar para entender se os papéis que identificamos são impactados pela cultura ou estratégia organizacional, por exemplo. Existe uma função mais importante para conscientizar ou engajar as comunidades, entre outros objetivos? Outro ponto é como as equipes DevRel são formadas dependendo do tamanho da organização e quais objetivos organizacionais estão dentro do ecossistema (o que inclui comunidades de desenvolvedores).

Para a indústria: O catálogo por nós identificado pode servir de base para definir as funções e atividades dos profissionais. As informações por nós identificadas ajudam a responder interna (na organização) e externamente (para todas as comunidades envolvidas no ecossistema) uma pergunta frequente: "O que um profissional DevRel faz?" Os profissionais podem usar os papeis para compor equipes DevRel com foco em atrair, envolver e reconhecer comunidades no ecossistema. Com uma estrutura de equipe DevRel e objetivos organizacionais, os profissionais poderão até mesmo analisar os pontos fracos e fortes de sua área de DevRel.

Para a educação: Há um interesse crescente por profissionais DevRel, uma simples busca no LinkedIn por DevRel retorna mais de 2000 oportunidades de emprego distribuídas ao redor do mundo. Além disso, atualmente os cursos de graduação e demais modalidades de ensino não contemplam conteúdos que subsidiem a formação de competências (principalmente, soft skills) para esses profissionais. Outro ponto é permitir a discussão sobre a importância do profissional DevRel e como as disciplinas existentes contribuem para suas atividades. Inicialmente, a análise de currículos de referência pode ser realizada para propor conteúdos, atividades e cenários que podem ser aplicados em disciplinas para ajudar a contribuir com a formação DevRel.

E o ponto que considero mais importante: a importância de trabalharmos as soft skills!

Corte de [1:04:32]{.underline} a [1:05:28]{.underline} (depois das duas perguntas de 1:03:19 a 1:04:32)

Corte de [1:08:06]{.underline} a [1:08:35]{.underline}

Referente às linhas vermelhas abaixo.

[(CORTE AQUI_]{.mark}

[(CORTE AQUI NO MEIO DA RESPOSTA]{.mark}

Parte 3: Outras perguntas

[[ADOLFO]]{.mark} No Brasil, existem grandes universidades situadas em cidades maiores e que historicamente atraem mais recursos, facilitando o seu desenvolvimento. Você é professor da Universidade Federal do Mato Grosso do Sul. Você observa que há desafios em atuar como professor fora dos tradicionais centros de pesquisa?

Sim, Adolfo! Eu vim do ICOMP/UFAM onde eu vivia uma realidade de incentivos das empresas. Quando decidi vir pra FACOM/UFMS foi justamente pelo desafio, acredito que o Centro-Oeste tem um potencial enorme. O primeiro desafio pra mim e que compartilho com alguns colegas é estabelecer a identidade da nossa região, identificar nossas potencialidades e fraquezas para criar um plano estratégico para a área de Engenharia de Software. Inclusive já demos passos para esse plano. Outro é contribuir para fomentar um ecossistema entre empresas/instituições de ensino locais e organismos externos à nossa região (outros estados e países) que gere valor para a região e todos envolvidos. Um próximo é valorizar os talentos locais e aqueles que acreditam na FACOM/UFMS para sua educação, temos um grupo de discentes de alto nível e que pode ser conectado a oportunidades no Brasil e fora. Se eu acho isso ruim? Não. O desafio me move e queremos, aqui incluo meus colegas da FACOM/UFMS e da área de ES, deixar nossa marca para a história dessa região. Acredito que pelo nosso corpo docente de ES ter sido formado nos centros tradicionais irá contribuir muito para a região.

[[INGRID]]{.mark} O Congresso Brasileiro de Software, do qual o Simpósio Brasileiro de Engenharia de Software faz parte, será organizado na sua cidade por você e outros organizadores em 2023. O que motivou vocês a fazer essa candidatura?

Olha, Ingrid, em primeira mão! :) Aqui começo falando do time, pois irei me posicionar em nome deles: Bruno Cafeo, Debora Paiva, Hudson Borges, Maria Istela e Patricia Matsubara. Todos nós temos uma ligação muito forte de formação propiciada pelo CBSoft, apresentação de artigos, participação em worshops na época de mestrado/doutorado, comitês de programa e o concurso de dissertações e teses, colaborações estabelecidas… Então, já era momento de agradecermos respeitosamente, de alguma forma, a comunidade de ES.

Então, aceitamos o desafio de organizar o CBSoft 2023 em Campo Grande (MS), especificamente na Faculdade de Computação (UFMS), expandindo a experiência de vocês para outras cidades do nosso Estado, mundialmente conhecido pelo Ecoturismo: as cidades de Bonito e Bodoquena, por exemplo.

Somos um grupo diverso nas gerações e com muita vontade de marcar a FACOM/UFMS no mapa brasileiro da comunidade de Engenharia de Software. E temos um plano estratégico para a área de Engenharia de Software, organizar um congresso como o CBSoft é uma das nossas metas dentro dos nossos pilares estratégicos. Quando discutimos, não houve aversão a vontade de realizar e proporcionar uma excelente experiência à comunidade de ES. Dando um breve spoiler: nossa proposta girará em torno de um CBSoft com a mensagem da sustentabilidade que é muito importante devido ao ecoturismo da região. Assim como, uma forte conexão com o ecossistema das indústrias de software.

Esperamos vocês no Mato Grosso DO SUL!! :)

Parte 4: Próxima Fronteira da ES [3 min, estimativa]

[[ADOLFO]]{.mark} Para você, qual é a próxima fronteira da engenharia de software? (pode ser algo que você acha que vai acontecer ou que você gostaria que acontecesse em nossa área)

Fundamentar e estruturar a área de DevRel, pois é evidente a demanda global da indústria. Educação para formar profissionais de DevRel, abordagens para avaliar a maturidade de processos de DevRel existentes, mecanismos de monitoramento de ações de DevRel. Avaliação do impacto da cultura local e global em estratégias de DevRel.

Parte 5: Encerramento

[Adolfo agradece e passa para o(a) entrevistado(a).]{.mark}

[Ingrid fecha o episódio.]{.mark}

Texto para divulgação

Conversamos com Awdren Fontão, pesquisador na Universidade Federal de Mato Grosso do Sul.

Sites de Awdren

Links Citados