Read more

Conforme as organizações identificam o valor de soluções baseadas em nuvem e de experiências digitais, elas também passam a dar mais atenção não só para a experiência do consumidor, mas do desenvolvedor. Pensar e planejar como esse profissional vai adotar ou operar tais tecnologias é uma medida estratégica que trará bons frutos à empresa. 

Semelhante à User Experience (UX), a Developer Experience (DX) se concentra na jornada do desenvolvedor. Contar com uma DX de qualidade não é mais opcional, mas um imperativo quando pensamos em competitividade no mercado. Ela representa todas as interações de um desenvolvedor com seu produto, seja ele um código aberto, framework, API, SDK, ferramenta ou serviço.

Durante o processo de elaboração de um novo produto, o olhar das organizações costuma se voltar para a experiência do usuário, no caso, o consumidor. Porém, ao mesmo tempo, é preciso entendimento do que os devs necessitam para executar suas tarefas.

As APIs, por exemplo, assumiram protagonismo no mundo dos negócios, sendo agora consideradas até produtos de muitas organizações. Tratando dessa tecnologia, os desenvolvedores também deveriam ser vistos como uma prioridade, já que são seus principais usuários.

Encarando os desenvolvedores como consumidores de APIs, é possível proporcionar uma boa DX  a partir de:

• APIs úteis;

• APIs estáveis;

• APIs escaláveis;

• APIs bem documentadas.

O fluxo de trabalho deve ser o mais suave possível, ou seja, a documentação não deve somente oferecer informações de como interagir com a API, mas também guias de início rápidos e exemplos de trabalho.

Logo, a cultura DX bem enraizada representa menos frustrações e projetos mais bem sucedidos para o time de desenvolvedores. E como isso pode ser traduzido em valor estratégico para seu negócio?

No caso de desenvolvedores que lidam com APIs, estes são alguns dos benefícios:

1. Melhor acompanhamento dos dados

A partir do acompanhamento de dados, podemos detectar possíveis falhas e irregularidades internas. Com isso, há uma melhor análise das APIs, tendo uma visão mais ampla da sua eficácia, tolerância aos erros e facilidade de uso.

2. Alinhamento dos processos

Compreender melhor o usuário, ou seja, o próprio desenvolvedor, implica em identificar mais rapidamente as áreas que precisam de ajustes e suporte.

3. Manutenção das informações

Seu desenvolvedor deve contar com um guias e manuais, descrevendo as regras de uso das APIs e disponibilizando sua documentação. Tutoriais também podem demonstrar boas práticas e fornecer um ponto de partida para soluções personalizadas. Com isso, é possível melhor compreensão dos fluxos e atualização ágil das informações sempre que necessário.

A escolha de ferramentas e frameworks é capaz de influenciar positivamente na produtividade e na experiência de sua equipe de desenvolvimento. Por exemplo, uma maneira de proporcionar uma ótima DX é optar por ferramentas que diminuam a carga cognitiva.

Ao escolher as ferramentas para seu time de desenvolvedores, procure pensar nas seguintes questões:

• Como será a experiência de onboarding?

• Alguém da equipe já usou a ferramenta antes? Pode dar feedback?

• Há documentações disponíveis sobre a ferramenta?

• Há ferramentas similares para fazer comparativos?

Vale destacar que, além de adotar uma cultura DX, um dos passos fundamentais é medi-la. Você pode fazer isso identificando a frequência de implantação, ou o tempo de produção para um novo serviço.

Para outros critérios mais subjetivos, como a satisfação dos devs no ambiente de desenvolvimento, faça pesquisas e fale com os profissionais. E lembre-se, conforme os produtos e serviços digitais evoluem, a experiência do desenvolvedor permanecerá um elemento relevante para o sucesso das empresas.

Quer conversar sobre DX e APIs? Clique aqui e marque uma reunião

Este artigo foi escrito por Luana Brigo e publicado originalmente em Prensa.li.

Com poucos meses para a Lei Geral de Proteção aos Dados entrar em vigor é natural que surjam dúvidas e questionamentos sobre a eficácia da lei, seus principais desafios e quais as consequências ela trará para diferentes setores, especialmente para empresas ligadas a área de tecnologia.

Uma das melhores formas de traçar um parâmetro é os resultados da implantação da GDPR, afinal de contas a Lei Geral de Proteção de Dados teve como modelo o regulamento da UE.

Para dar a você uma noção dos valores envolvidos, um ano após a GDPR ter entrado em vigor foram aplicados aproximadamente €56 milhões em penalidades e mais de 64 mil notificações de vazamentos, sendo 280 dos casos fora da UE.

Ao mesmo tempo que vemos estes números significativos resultantes de penalidades e vazamentos, temos mais de 375 mil empresas com registro formal de um Data Protection Officer (DPO) e mais 500 mil que planeja contratar um profissional responsável pelos dados.

A questão que fica: como um desenvolvedor por entrar em conformidade com a GDPR?

Algo do qual podemos ter certeza com a implantação da GDPR é o cuidado e atenção necessários na criação de sites e serviços online, é necessário mais transparência com a forma de coletamos e usamos dados armazenados.

Os desenvolvedores possuem um papel importante a desempenhar a partir da vigência da LGPD. Afinal de contas, a prática de proteção de dados envolve tanto o lado do desenvolvimento (elaboração de códigos, dados e segurança) quanto o lado comercial/negócios.

Vou exemplificar alguns pontos relacionados ao trabalho de um desenvolvedor (pós-GDPR) para deixar mais claro como você saiba o que esperar para a agosto de 2020, quando a LGPD entrar em vigor.

1. Padrões de Programação

A importância de um fluxo de trabalho saudável de proteção de dados e a prevenção da perda ou captura de dados desnecessários exige que o desenvolvedor tenha como base um conjunto de bibliotecas de códigos, ferramentas e estruturas. Logo, estar em conformidade com o GDPR significa criar uma lista de padrões e metodologias aprovados para codificação e testes.

A chegada do GDPR não promoveu uma lista de linguagens de programação e ferramentas certas ou erradas, o que realmente importa aqui é se tudo o que você utiliza é claramente definido e seguido para cada situação em que você ou sua empresa utilizam.

Obviamente isso não significa que em nenhum momento do seu trabalho você não poderá alterar as ferramentas ou mesmo as infraestruturas, mas será preciso garantir que estas sejam reconhecidas e documentadas como as estruturas a serem usadas.

Os padrões de codificação também precisam ser preventivos. Dessa forma, você deve desativar módulos não seguros ou desnecessários, especialmente em APIs e bibliotecas de terceiros

2. Consentimento do usuário (back-end e front-end)

Rever a proteção de dados levando em conta as diretrizes do GDPR se relaciona com passar o controle dos dados aos usuários utilizando de mecanismos de consentimento e acesso de sujeito. A partir daí o usuário deve ser informado a respeito do fluxo de seus dados e de seus direitos sobre os mesmos.

No front-end, o desenvolvedor deve fornecer bons mecanismos de consentimento e controle do usuário. As aplicações precisam oferecer o controle ideal sobre as configurações de consentimento através de painéis de controle, painéis do usuário, configurações de conta e centros de privacidade.

Além disso, é importante que seja fornecida uma interface de direitos de acesso de sujeitos individuais, garantindo que estes editem e corrijam informações, baixem e excluam dados.

Já no back-end, o desenvolvedor precisa impor o consentimento e a escolha do usuário. Quando o usuário configura uma conta pela primeira vez ele deve usufruir de configurações ideais de privacidade por padrão.

Outro ponto é que ao longo do desenvolvimento do back-end será essencial que o desenvolvedor garanta uma documentação com data e hora do consentimento do usuário, como ele o deu e se o retirou ou não.

3. Requisitos de Projeto

Quando falamos de um fluxo de desenvolvimento consciente do GDPR, requisitos de projeto também são parte integrante. Nesse caso, a proteção de dados por padrão necessita de um desenvolvimento voltado para a minimização:

• Coleta de uma quantidade mínima dados pessoais, ou seja, somente os realmente necessários, tanto no front-end quanto no back-end.

• Não vinculação dos dados pessoais a outros grupos de dados armazenados em um único local.

• Remoção de dados pessoais e de identificação no caso de agregação de dados

Embora as diretrizes que compõem o GDPR exijam que você defina agendas de retenção e exclusão para todos seus dados pessoais, não há nenhuma obrigatoriedade que você exclua tudo como regra. Você pode muito bem manter registradas informações de compras por 5, 10 anos para fins fiscais. Desde que tudo seja documentado e justificado, manter os dados é aceitável.

Vale ressaltar que a exclusão dos dados, quando estes não forem mais necessários, pode ser feita tanto automaticamente quanto por meio de ações do usuário.

Outro aspecto do design do sistema está ligado a privacidade. Dessa forma, dados pessoais não devem estar à vista de todos, nem no frontend e nem no back-end. Além disso não é recomendado que todos os usuários tenham acesso universal.

Por questões de segurança e privacidade, os dados do usuário precisam estar criptografados, estejam eles em trânsito ou em repouso.

3. Manutenção e testes

Adequar-se ao GDPR significa adicionar privacidade e proteção de dados por padrão em seus processos de teste. Isso deve complementar os procedimentos existentes, como testes de penetração (pentest).

Tais procedimentos de teste de privacidade devem prever como usuários não autorizados obteriam acesso a dados no seu sistema. Para isso você precisa ter os seguintes questionamentos:

• Os dados de usuários são armazenados nos cookies de login?

• Alguém poderia ter acesso aos dados acionando intencionalmente um erro?

• Há alertas externos sobre violações de dados, potenciais ou reais?

• A criptografia utilizada para informações pessoais foi a mais forte?

• Logs das aplicações não estão comprometendo a privacidade do usuário?

Sendo assim, você precisa pensar de forma um tanto maliciosa a respeito de como seus dados podem escapar e onde eles não deveriam estar.

A regra de ouro da LGPD e do GDPR: documente tudo. Se não está registrado então não aconteceu. Os resultados do seus testes e métodos usados para alcançá-los devem ser anotados e acionados como documentos vivos. Você precisará comprovar em situações extremas de vazamento que você utilizou a melhor tecnologia existente no período em que o desenvolvimento ou manutenção aconteceram.

Caso você queira saber um pouco mais sobre como desenvolvedores se adaptaram ao GDPR, leia mais em MasterCard Developers.

O que todo desenvolvedor precisa saber

Um conceito importante ligado ao GDPR é o porquê da coleta de dados, ou seja, quando você fizer a coleta é necessário que ela tenha um objetivo específico e justificável. Isso não significa que você não possa coletar os dados que desejar, mas eles deverão apresentar uma finalidade. Isso sem contar que o usuário precisa ser notificado e concordar com a coleta.

Uma boa dica é adicionar estas justificativas como um DoD (Definition of Done) da estória ou escopo de projeto à ser desenvolvido pelo time técnico.

Logo, como desenvolvedor, seja para entrar em conformidade com o GDPR ou a LGPD, é essencial que você tenha debates com o responsável pelo produto (Product Owner) e com parceiros sobre sua adequação às leis de proteção de dados, assim como conversar com outros desenvolvedores mais familiarizados com os códigos e arquitetura de seus sistemas. Procure compreender como eles processam, armazenam e manipulam os dados.

Ofereça uma API para gerenciar o consentimento do seu usuário e, principalmente, as versões do consentimento, dado que a solução digital é viva e pode, ao longo do tempo, solicitar ou utilizar os dados de maneira distinta da inicialmente proposta.

Lembre-se a privacidade dos dados necessita ser protegida a cada passo do usuário, do login ao logout.

No caso de APIs vale a pena ficar atento ao seu gerenciamento, afinal ele é a base para uma uma arquitetura compatível com a LGPD. O gerenciamento permite que as empresas criem rapidamente regras sobre obtenção de consentimento e assim informem seus usuários acerca de regulamentações ligadas ao acesso e a portabilidade de dados.

A partir da vigência da LGPD, será preciso que as organizações revejam o ciclo de vida de suas APIs e implementem controles mais rigorosos e robustos para a proteção dos dados.

O papel de um DPO (data protection officer)

A nova regulamentação sobre proteção de dados entre em vigor em agosto de 2020, o que significa que para evitar penalidades de até R$ 50 Milhões por infração as organizações brasileiras devem estar alinhadas às normas da LGPD.

Nesse novo cenário surge a figura do Data Protection Officer (DPO) ou segundo tradução literal Oficial de Proteção de Dados. Esse profissional fica a cargo do canal de comunicação entre a empresa, os donos das informações e a Autoridade Nacional de Proteção de Dados (ANPD). Sua figura tem tomado mais espaço desde a GDPR e foi absorvido, com adaptações, pela LGPD. Trata-se de um

nova posição do nível estratégico, posição esta que merece atenção por parte das empresas.

Os desenvolvedores são profissionais que pelos seus conhecimentos técnicos e habilidades devem estar preparados para assumir esse papel de guardiões das de gerenciamento de dados apropriadas. Similar a um diretor de conformidade, o DPO possui noções bem abrangentes dos requisitos de gerenciamento de dados e como implementá-los em cada projeto elaborado.

O ideal é que as organizações já nomeiem profissionais para ocupar esse cargo, antes o início efetivo do vigor da lei, o que ajudaria ainda mais no processo de adaptação à LGDP composto por análises da maturidade da empresa em relação ao tema e desenvolvimento de relatórios de impacto à proteção de dados pessoais contendo as características dos tratamentos de dados, os riscos para os titulares e avaliação sobre os impactos sobre a proteção de dados.

Se você quer saber mais sobre Governança de APIs, se cadastre no API Playbook e tenha acesso à entrevistas, video-aulas e materiais voltados ao ciclo de vida de APIs.

Quer conversar sobre DX e APIs? Clique aqui e marque uma reunião.

Este artigo foi escrito por David Ruiz e publicado originalmente em Prensa.li.

Termos como UX (experiência de usuário) e UI (interface de usuário) não são nenhuma novidade faz um tempo, especialmente se você trabalha ou se interessa por assuntos que envolvam tecnologia. Uma boa experiência de usuário é a chave para a adoção de um produto. Afinal de contas, se ninguém entender como usá-lo, ninguém terá interesse nele.

O mesmo vale quando falamos de APIs (Interface de Programação de Aplicativos). Seus principais usuários são os desenvolvedores. Quando eles gostem de usar uma plataforma e consideram ela eficiente, as chances dessa plataforma ser escolhida aumentam.

A cada dia os Devs se tornam mais ativos e exigentes com suas experiências e qualidade dos produtos que utilizam, principalmente quando falamos de APIs. E a chave para APIs de sucesso está justamente na Developer Experience (DX), a experiência do desenvolvedor

Mas o que é Developer Experience?

A Developer Experience é o equivalente a quando o usuário principal do produto é o desenvolvedor.

Na DX há uma preocupação do desenvolvedor quanto à usabilidade do produto, SDKs, documentações, frameworks, soluções open source e, claro, APIs.

Simplificando, a DX é importante pelos mesmos motivos que uma UX. Ela é o agregado de todas as experiências que um desenvolvedor tem ao interagir com sua plataforma. Além disso, desenvolvedores com uma boa DX utilizam o produto em questão por mais tempo e até o promovem.

Quando falamos em uma boa DX, quero dizer que ela deve atender às necessidades dos seus clientes. Mas antes de tudo, você precisa entender quem é o seu cliente. E o que vemos por aí são empresas de tecnologia que ainda não tem essa compreensão.

Por exemplo, a API como um produto. Ela não deve ser fácil de usar apenas para seu público técnico, embora isso seja extremamente importante. Ela também precisa de uma usabilidade facilitada pensando nos tomadores de decisão. Contudo, estes não têm os mesmos conhecimentos técnicos que um desenvolvedor, e terão que decidir pelo uso ou não da plataforma.

Sua API precisa atrair tanto o público técnico quanto não técnico, e para isso seu processo de adoção de API deve ser o mais direto possível.

Dessa forma, uma API agrega dois públicos diferentes:

1. Negócio: Product Owner, Profissionais de Inovação ou até mesmo o CEO, especialmente no caso de startups e pequenas empresas

2. Técnicos: CTO, CIO, CDO e CSO, arquitetos de integração e desenvolvedores

A jornada da API, da sua descoberta até seu consumo, precisa responder a pelo menos 4 perguntas de seus consumidores:

• Por que devo usá-la?

• Como me registro?

• Por onde começo?

• Como posso testar?

As respostas para cada uma dessas perguntas devem ser claras para seus usuários desde o início. A partir daí é que você poderá identificar seus pontos de valor.

Então minha estratégia de APIs deve considerar a Developer Experience (DX)?

Atualmente, existem milhares de APIs disponíveis, com diversas funcionalidades e propósitos. Por isso, ganhar aquele destaque e sair na frente da concorrência é fundamental quando se trata de dar uma atenção especial aos desenvolvedores e oferecer a eles uma boa experiência no uso das APIs.

De que serve uma ótima API se o desenvolvedor não a utiliza, porque considera sua documentação e onboarding complicados? Ou por que ele não obtém respostas do suporte ou retorno de seus feedbacks? Por isso afirmo que cuidar da sua Developer Experience é vital para ter sucesso nas suas estratégias de APIs.

O mesmo vale para o caso de APIs internas. A má experiência relacionada a APIs internas pode resultar em desperdício de tempo e dinheiro, já que seus desenvolvedores irão refazer seus componentes, ou vão gastar sua energia tentando entender como utilizá-la adequadamente. Isso significa que APIs com excelente DX evitam trabalho desnecessário e tarefas repetitivas. O resultado, na verdade, é uma maior produtividade e aceleração do time-to-market.

Experiência do desenvolvedor em equipes

Para que a construção de uma developer experience funcione dentro dos times de sua empresa, é necessário que toda comunicação, especialmente entre time de negócios e técnico, estejam o mais clara possível.  Uma comunicação eficaz pode agregar um valor incrível ao seu projeto e ajudar a lançar produtos melhores.

A padronização no fluxo de trabalho também é mais do que bem-vinda, sem contar as ferramentas disponíveis. Todos na equipe devem usar as mesmas ferramentas para a mesma tarefa. O mesmo se aplica à configuração.

Uma configuração idêntica inclui majoritariamente ferramentas compartilhadas, como as de CI / CD ou ambientes de teste. Isso não implica que todos devam apresentar exatamente as mesmas configurações / preferências de usuário.

A integração deve ser um ponto de atenção da mesma forma.  Se novos desenvolvedores ingressarem na equipe, suas atividades devem ficar claras. Eles precisam saber quais ferramentas devem instalar, e a quem recorrer para tirar suas dúvidas. E para isso, uma documentação, não apenas de software, mas dos fluxos de trabalho e processos, serve de suporte.

Pilares da Developer Experience

1. Função

Ela é essencial para a DX. Uma devtool (ferramenta de desenvolvedor) é tão boa quanto a funcionalidade que ela oferece. Não adianta tentar encobrir uma funcionalidade pobre com uma estética bonita, desviando assim a atenção do problema. Se a API não operar corretamente, ele não possui serventia para o desenvolvedor e nem colabora para a DX.

2. Estabilidade

Sem uma API estável não há confiança. Um dos elementos mais críticos para uma boa Developer Experience é a garantia das atividades e de um desempenho confiável. A estabilidade também está relacionada à capacidade de corrigir erros. Sem ela, as APIs e suas funcionalidades, mesmo que boas, tornam-se irrelevantes.

3. Facilidade de uso

A facilidade em utilizar uma API não está relacionada apenas a como navegar nas suas ferramentas, mas também a como acessar o que for necessário em todas as etapas da jornada. Tudo de forma eficiente e rápida.

Documentação rica, casos de uso, comunidades, filtros intuitivos, pesquisas realizadas anteriormente e pontos mais profundos como desempenho agregam velocidade ao processo de interação dos desenvolvedores com sua API e aumentam o engajamento.

4. Clareza

Quando falo em clareza, me refiro a uma interface simples e intuitiva, que traga todas as informações necessárias para ajudar o desenvolvedor a realizar suas atividades diárias e atenuar erros de usuários. Logo, clareza é sobre o desenvolvedor ter visibilidade total das possíveis consequências de uma ação.

Invista sem medo em uma DX

Muitas das experiências digitais que impulsionam a economia de hoje têm sua origem no trabalho e desempenho de desenvolvedores. Poucas são as empresas que não se enquadram nessa realidade. Uma verdade: Os desenvolvedores são colaboradores estratégicos tão essenciais quanto qualquer outro ator no pipeline de produtos de uma empresa. Portanto, o envolvimento do desenvolvedor deve ser um item prioritário para qualquer organização.

Isso significa que APIs não deveriam ser tratadas simplesmente como um middleware, mas como produtos para desenvolvedores. Elas exigem, como qualquer outro produto, uma equipe qualificada para gerenciá-las, sem contarmos todo o envolvimento com o cliente, ciclos de feedbacks e as interações ao longo do processo.

Se você pretende criar e lançar uma API de sucesso, precisa começar a investir em uma ótima experiência de desenvolvedor. Tal experiência deve incluir:

• Conteúdo relevante sobre a API para grupos-alvo, e não apenas para desenvolvedores;

• APIs de fácil entendimento;

• Fluxos de integração;

• Glossário para explicar os termos;

• Guia de primeiros passos descrevendo as etapas de integração;

• Exemplos  nas linguagens de programação mais comuns.

• Referência da API com detalhes dos terminais, solicitações e respostas esperadas, além de códigos de erro;

• As notas de versionamento da API;

• Limitações da API, incluindo cotas de solicitação e limitações de frequência.

API em primeiro lugar para um boa DX

Quando falamos de consumidores de APIs, abordamos o tema de desenvolvedores, e como sua experiência com o produto API pode levar ao sucesso ou fracasso de uma API. A estratégia API First ajuda na criação de APIs mais consistentes, melhor projetadas e documentadas, garantindo uma Developer Experience positiva e uma menor curva de aprendizado.

Ao projetar primeiro sua API, você garante uma melhor developer experience, já que tudo o que for feito será construído com base nela. 

Além disso, os times de desenvolvimento conseguem trabalhar em paralelo, uma vez que não seja incomum que processos de desenvolvimento sejam síncronos e não paralelos. 

Por exemplo, os primeiros a atuarem na criação de um novo serviço são os membros do time de pesquisa. Em seguida, a equipe de back-end começa a escrever o protótipo. A participação do front-end e Q&A só ocorrerá após a conclusão do protótipo e o compartilhamento da documentação da API.

O empecilho surge quando há a necessidade de aprimoramento por conta de um bug, fazendo este ciclo recomeçar, tomando um tempo valioso de todos os envolvidos e até atrasando o lançamento do produto ou serviço em questão.

Sendo assim, a estratégia possibilita o trabalho paralelo de equipes. Ela envolve também o estabelecimento de um contrato entre determinados serviços por parte dos times de desenvolvimento.

Tal contrato irá permitir que as equipes trabalhem em mais de uma API ao mesmo tempo. Dessa forma, um desenvolvedor não precisa esperar a atualização seguinte de uma API antes de passar para a próxima. Um contrato possibilita a simulação e testes das dependências de APIs com base na definição de API estabelecida.

Developer Experience Owner (DXO)

Uma adição à equipe de desenvolvimento que pode colaborar para o bom andamento da developer experience é o Developer Experience Owner (DXO). Um membro do time de desenvolvimento designado para cuidar da DX da equipe, selecionando e configurando as ferramentas, definindo fluxos de trabalho, integrando novos membros e sendo uma pessoa de contato central para todas as questões relacionadas à experiência do desenvolvedor.

Outro aspecto do DXO é manter os desenvolvedores “sincronizados”, ou seja, garantir que todos saibam o que está acontecendo, quando e quais atualizações são necessárias. O que inclui a prevenção de uma forma ruim do shadow IT, no qual os desenvolvedores usam ferramentas ou processos sem avisar a ninguém porque temem que isso não seja permitido.

Promova inovação e expanda seus negócios com a API Playbook, consultoria especializada em DX e governança de APIs

Este artigo foi escrito por Luana Brigo e publicado originalmente em Prensa.li.

Atualmente podemos falar de experiências conectadas, temos a possibilidade de controlar objetos domésticos inteligentes por IoT (Internet of Things ou Internet das Coisas) através de um aplicativo móvel ou mesmo solicitar encomendas usando uma assistente de voz.

Isso por que nossa cultura está cada vez mais digitalizada, o que acaba alterando nossos hábitos como um simples ato de compra. E com isso tivemos uma mudança estrutural do varejo com a vinda de novos players e a transformação de modelos de negócios em marketplaces.

Alguns desses modelos de marketplaces criaram processos disruptivos em muitas indústrias. Temos nomes tradicionais como eBay, Amazon, Mercado Livre, B2W (Americanas, Submarino e ShopTime) e Magazine Luiza aqui no Brasil.

A mudança em nossa forma de consumo resultou em uma convergência do offline para o online e com isso a indústria de marketplace percebeu uma valiosa oportunidade, já que o consumidor muitas vezes prefere a praticidade de pesquisar e comprar no digital, ainda que continue retirando o produto na loja mais próxima de sua casa.

O câmbio para o meio digital pode ser comprovado através da 4ª edição da pesquisa PayPal/Ipsos: o perfil do consumidor online. O estudo Paypal/Ipsos indicou uma provável movimentação de R$270 bilhões no comércio eletrônico, crescendo 17% este ano e 18% em 2020.

O estudo também indicou os 4 fatores mais decisivos que farão o consumidor escolher comprar por uma loja virtual:

1. Maior conveniência — 63% (dos 34 mil entrevistados)

2. Mudança no rendimento disponível — 46%

3. Aumento no número de plataformas de comércio online — 32%

4. Mudanças na economia — 25%

Por isso, marketplaces tem investido em tecnologias, como Machine Learning, Inteligência Artificial, Analytics e Big Data. Tudo isso para oferecer maior qualidade no serviço, segurança e uma melhor Customer Experience (CX), ou seja, experiência do consumidor.

Uma Customer Experience é formada por ações voltadas para a melhoria e otimização das interações entre cliente e a marca. Saber trabalhar e investir nesse relacionamento é vital para qualquer empresa. E hoje mais do que nunca, uma boa CX precisa de recursos tecnológicos para ser aprimorada continuamente. O uso de dispositivos, ferramentas e redes sociais, por exemplo, colabora na facilitação da relação cliente-empresa, fazendo-a mais acessível e rápida.

Como as APIs podem revolucionar a sua Customer Experience

Uma das tecnologias aliadas na aprimoração da Customer Experience são as APIs (Interfaces de Programação de Aplicativos). Componentes importantes, as APIs permitem que as empresas capacitem seus desenvolvedores na criação novas experiências conectadas, incluindo compartilhamento seguro de ativos digitais com parceiros/desenvolvedores externos e conectados internamente através de APIs. Logo estas interfaces não são simplesmente conectores, mas um caminho de novas experiências, e a exemplo disso cito facilmente a Customer Experience.

Em outras palavras, uma API é como uma porta para os valiosos ativos digitais de uma empresa. Ela tem sido uma grande catalisadora da inovação e isso impactou na relação empresa-cliente. A partir de suas funcionalidades nos deparamos com o fornecimento de um perfil mais preciso do consumidor e o resultado é uma experiência do cliente com maior qualidade.

Nos últimos anos tivemos um fomento dos canais de comunicação com os clientes, que hoje conseguem interagir com suas marcas por meio de lojas, voz, e-mail, aplicativos móveis, web ou chatbots. Logo o crescimento dos pontos de interação tornou a jornada do cliente mais complexa, levando as empresas a considerar os dados desses canais para garantir uma experiência mais proveitosa possível.

Para fazer isso, as organizações passaram a sincronizar dados entre os canais e fazer referência cruzada dos dados. Isso só é realizado através de APIs, já que estas permitem um processamento de dados mais apurado.

É essencial que as empresas consigam fazer esse acompanhamento do consumidor, que cada vez mais trafega de um dispositivo para outro em suas transações. Por exemplo, um cliente liga para uma loja pedindo informações sobre determinado produto, mas acaba fechando a compra por meio de um computador ou de um aplicativo. São as APIs que permitem a coleta e transferência de dados, ou seja, elas auxiliam na experiência personalizada do cliente.

Mas as facilidades não vão apenas na direção do consumidor, as APIs permitem que sua empresa realize a coleta de grande volume de dados de clientes como suas preferências. A partir de tais informações a empresa consegue criar um perfil mais detalhado do consumidor e assim oferecer ofertas especiais como incentivo a compra.

E não pense que apenas empresas de grande porte podem melhorar suas operações através de APIs. Se você possui uma empresa de pequeno ou médio porte também pode se beneficiar, seja a partir da exposição de seus dados, do uso de APIs para acessar dados de fora da sua empresa ou uso de APIs para otimizar processos internos. Portanto, empresas que tomam a iniciativa de investirem em estratégias de APIs implementadas conseguem:

• Melhorar os processos e fluxos de trabalho

• Apresentar maior transparência e visibilidade

• Minimizar possíveis riscos

• Impulsionar a inovação

Além disso, não podemos nos esquecer da cereja do bolo: o relacionamento com o cliente, até porque toda empresa, independente do segmento ou tamanho, oferece produtos ou serviços a alguém. Por isso, aderir às estratégias de APIs envolve:

1. Dados em tempo real

2. Experiências relevantes

3. Ganho de valor

4. Mashup de experiências

O desafio de uma boa Customer Experience

Com tudo o que foi dito neste artigo, fica claro que as APIs são aliadas valiosas de qualquer organização que saiba como utilizá-las de maneira estratégica, principalmente por que elas permitem que as organizações analisem seus dados de forma mais operacional e real-time.

Ainda sim, há empresas que mantém um relacionamento com seus clientes pouco próximo, tratando-os como se nunca tivessem interagido antes. Como resultado temos aí vários pedidos e buscas de históricos de interações anteriores. Algo que não colabora em nada para o entrosamento entre empresa e consumidor.

O maior desafio para as empresas, que buscam evitar tais situações, é proporcionar aos seus clientes uma experiência contínua, consistente e personalizada através de uma análise em tempo real de seus dados. Ter em mãos informações relevantes dos clientes ao longo dessa interação permite tomadas de decisão mais acertadas, favorecendo a satisfação e expectativas do cliente.

É partindo desse desafio que uma boa estratégia de APIs consegue não só prever o comportamento de compra do cliente, mas também de fazer sugestões mais adequadas aos seus desejos e necessidades através do enriquecimento de informações por terceiros.

De fato, APIs são uma ótima solução para as necessidades do mercado quando falamos de experiência do cliente. O problema, como já mencionei, são as organizações que não valorizam uma implementação de estratégias de APIs, fator vital em tempos de transformação digital. É preciso compreender que as APIs são o elo que faltava entre os dados e experiência do consumidor.

É na junção das informações coletadas, no uso de inteligência artificial e tabulações cruzadas que encontramos um refinamento na construção do perfil do consumidor e este tem, no fim das contas, uma experiência muito mais fluida e relevante com sua empresa.

O sucesso de suas APIs, independente do público principal ser técnico ou de negócio passa por uma documentação bem elaborada, transmitindo seu valor ao negócio de forma clara e sua utilização acessível, ajuda novos usuários a compreender as suas aplicações e reduz o impacto na entrega e, consequentemente, o custo de implementação e suporte.

Quando o assunto é API, sua documentação é um dos elementos principais para que esta tenha sucesso. Trata-se da entrega técnica de todo conteúdo, ou seja, um manual de referência com instruções de como realizar uma integração efetiva da API, além de pormenores a respeito das suas funções, tipos de retorno, argumentos e exemplos de uso.

Logo uma API bem documentada:

• Deixa claro o seu benefício do ponto de vista de negócio;

• Aperfeiçoa a Developer Experience;

• Previne manutenções;

• Torna o usuário consciente do papel da API;

• Favorece e acelera o processo de integração;

• Ajuda no planejamento de orçamento, cronograma e lançamento de novos produtos.

Todo desenvolvedor precisa compreender que suas APIs podem ser utilizadas por terceiros, que apresentam visão de negócios diferentes e conhecimentos técnicos superiores ou inferiores. Dessa forma, a boa documentação de API é o melhor caminho para que qualquer outro desenvolvedor consiga compreendê-la e a utilize corretamente.

Quando explicativa, a documentação permite que desenvolvedores priorizem seu tempo e a força de trabalho durante processo de integração da API. Por outro lado, uma documentação inadequada acarreta em barreiras para a disponibilização e uso da API, uma vez que pode provocar adversidades relacionadas à excedentes orçamentários não previstos e contratempos de suporte. Ademais, quanto maior a clareza e objetividade presente na documentação, melhor e mais longo será o ciclo de vida da API.

A importância de uma boa documentação

O desenvolvimento de uma estratégia de API pública envolve a construção de um ecossistema em torno dela e, consequentemente, passa pela documentação, onde seu principal objetivo é obter a maior quantidade de desenvolvedores conhecendo-as e implementando as com uma boa experiência. Por isso o mais indicado e correto é que não se pule nenhuma etapa na criação da documentação, evitando assim o risco de perder potenciais usuários.

A seguir as 10 dicas fundamentais para uma documentação de sucesso:

1. Elabore uma documentação completa

A documentação acessada pelos desenvolvedores deve apresentar um conteúdo que auxilie durante toda a interação do usuário com a API, por isso é essencial uma atenção especial e detalhada de todos os dados. É importante também destacar as implicações no seu uso e com isso o usuário entenderá mais sobre a estabilidade da API no momento da integração.

2. Apresente a lista de recursos disponíveis

Os métodos e dados disponíveis são itens básicos de toda documentação de APIs. Elaborar essa lista é um dos primeiros passos envolvendo esse documento. Por isso descreva detalhadamente a função de cada método, parâmetros de entrada e saída. Afinal de contas tal lista será uma das principais referências para que desenvolvedores possam traçar um plano de integração da API.

Exemplo: Instagram

3. Disponibilize exemplos

Mostre exemplos de código para que outros desenvolvedores possam fazer a ligação entre conceito que você transmite e a aplicação prática da API.

4. Reforce os dados sobre autenticação

Reforce em todas as páginas da documentação as etapas e informações necessárias para consumi-las. Por mais que pareça repetitivo, reforce sempre que possível, como por exemplo, processo de autenticação, passos obrigatórios, cadastro para geração de chaves de acesso e etc.

5. Fique atento aos Códigos de Erro/HTTP Status

Outro integrante importante da documentação são os códigos de erro ou mensagens de HTTP status da API. Os HTTP Status Codes possuem um padrão, mas o mesmo não ocorre no caso de códigos de erros. Utilize o espaço da documentação para detalhar todas as possibilidades de problemas e erros com os quais o desenvolvedor pode se deparar ao trabalhar com a sua API. Uma escolha interessante é evitar mensagens de erro genéricas e optar por mensagens mais explicativas.

Exemplos: Twitter e AWS

6. Invista em documentação interativa

Permitir que haja interação dos usuários com sua API através da documentação é uma ótima forma de tornar a experiência mais dinâmica e as integrações mais rápidas. Além da documentação estática e descritiva, invista em uma mais dinâmica por meio de serviços como o Swagger, no qual o desenvolvedor consegue autenticar, verificar métodos e fazer chamadas em tempo real, com retornos de saída e códigos de erro.

7. Teste sua documentação

É necessário coerência e dados concretos presentes na documentação de uma API, por esse motivo teste tudo o que foi documentado sobre sua API e de preferência com o auxílio de uma equipe de desenvolvedores que não elaborou a criação dela, assim você terá a sua disposição diferentes olhares daqueles já presentes no projeto.

8. Permita a experimentação anônima da API

Essa é uma maneira de autorizar que outras pessoas tenham a chance de testar sua API de forma rápida e intuitiva, por meio de uma interface web. A vantagem disso é que não há necessidade de instalar nada. Com exploração de API, usuários com menor conhecimento técnico podem brincar com sua API e explorar seus dados.

Outra questão da exploração é dar permissão para clientes em potencial possam experimentá-la sem precisar se cadastrar ou passar por um processo burocrático. O engajamento é consideravelmente maior nessa situação. É possível também oferecer um ambiente de sandbox, já que ele é relativamente simples e pode ajudar os desenvolvedores a conhecer visualmente o valor de sua API.

Exemplo: Catho

9. Limitando a quantidade de requisições

Outro elemento de relevância na documentação é a quantidade de chamadas disponíveis. Esse número pode variar no caso da monetização de APIs, por exemplo você possui uma parceria com uma empresa ou desenvolvedor e nesse caso eles possuem mais chamadas que um usuário comum. De modo geral, tais informações precisam ser claras e de fácil acesso, da mesma forma que a mensagem de erro que aparecerá para o usuário se este ultrapassar o limite permitido

10. Estruturas, métodos de URI

A estrutura e os métodos de cada URI na API devem ser documentados. Isso precisa ser realizado de tal maneira que o usuário tenha acesso a descrições detalhadas de todas as funções disponíveis. Obviamente nem tudo a respeito de um endpoint pode ou deve constar na documentação, isso nos casos em que o usuário não tenha os direitos necessários para usar tais endpoints.

Uma forma de exemplificar isso é através de dois segmentos de APIs: as gratuitas e as disponíveis apenas para usuários business-to-business ou monetizados. No caso da primeira, é possível que algumas funções, por serem restritas, não estejam disponíveis para um usuário comum. Dessa forma, a documentação desse endpoint não deve ser oferecida para alguém sem autorização.

Os benefícios de uma documentação de APIs bem implementada

Dentre todas as fases do ciclo de vida da API, a documentação é uma das mais importantes. Ficar atento a todos os elementos que devem constar no documento é essencial para colher os frutos de uma API bem sucedida.

Saber documentar uma API implica nos seguintes benefícios:

• Adoção de mais APIs

Os padrões de adoção já não são mais os mesmos para os desenvolvedores. A elaboração de uma boa documentação de API está diretamente correlacionada a adoção de APIs. Se você oferecer uma documentação clara e acessível, mais usuários encontrarão valor em seus serviços, levando a um crescimento e adoção de mais APIs

• Maior conscientização

Quando muitas pessoas utilizam um produto ou serviço tornando-o valioso trata-se do efeito de rede. O mesmo vale para os consumidores de sua API. Quanto mais satisfeitos eles estiverem, com mais afinco eles defenderam seus serviços e assim será possível prever um crescimento no evangelismo e na publicidade boca a boca.

• Manutenção e atualizações mais fáceis

Quanto mais detalhada e precisa for a documentação melhor será a manutenção e atualização das APIs. Com isso as equipes internas terão em mãos mais detalhes sobre os recursos, métodos, solicitações e respostas associadas.

Saiba como apresentar as informações

Apesar da significativa importância da documentação de APIs, ela ainda é vista por muitas empresas como um item “opcional” e acaba sendo deixada de lado, especialmente quando o time de desenvolvedores mantém a documentação manualmente a cada lançamento de novas versões.

É preciso levar em conta o que uma boa documentação pode proporcionar como melhora na Developer Experience e aumento nas chances de consumir a API, dado que os usuários encontrarão valor em seus serviços com facilidade.

Confira 3 exemplos de empresas que realizam documentação de suas APIs:

1. Pagar.me

2. ELO

3. Twilio

Vale destacar que muitas das pessoas que trabalham com APIs não possuem necessariamente um conhecimento aprofundado do assunto ou mesmo domine os jargões comuns no setor, portanto, escreva de maneira simples, permitindo a compreensão tanto de desenvolvedores como também de tomadores de decisão, ou seja, os não técnicos.

A produção de vídeos, webinars e tutoriais são muito mais explicativos do que documentações extensas, portanto, por mais que o custo seja mais elevado e dificulte a sua realização constante conforme as APIs são atualizadas, o investimento se paga facilmente dado a simplicidade de consumo por parte do desenvolvedor ou agente de negócio.

Engajar desenvolvedores é fundamental para uma API de sucesso. Boa parte disso se deve a documentação bem elaborada. Se uma API não for documentada adequadamente, muito provavelmente o usuário gastará seu tempo tentando entender o seu funcionamento, o que acaba criando barreiras no uso do serviço.

Um dos focos deste documento são os recursos e endpoints disponibilizados e é preciso lembrar que não basta apresentar algumas páginas HTML sobre variações de retorno, como realizar autenticação e o qual a função de cada recurso. A documentação de APIs vai além destes requisitos básicos, mas precisa oferecer uma experiência mais visual e interativa da API, ou seja, proporcionando um teste em tempo real delas.

No mercado podem ser encontradas diversas ferramentas para auxiliar na elaboração de uma boa documentação interativa para os recursos da sua API.

Atualmente três especificações se destacam entre as demais:

1. Swagger

2. API Blueprint

3. RAML

Cada uma das ferramentas acima apresenta foco em diferentes aspectos como legibilidade, design, curva de aprendizado, integração com outros serviços. A seguir vamos entender suas particularidades:

Tornando sua documentação mais intuitiva com Swagger

Entre os diversos formatos de descrição de APIs que geram a documentação dinamicamente, o mais conhecido é o Swagger. Ele é de código aberto e permite que desenvolvedores e equipes projetem, construam, documentem e consumam APIs em RESTful. Atualmente se encontra em sua versão 2.0.

Trata-se de uma ferramenta padrão de mercado, cujo objetivo é possibilitar que a documentação evolua juntamente com a implementação da API, uma vez que a documentação pode ser gerada automaticamente. Grandes empresas de tecnologia como Amazon, Netflix, Apigee, Getty Images, Microsoft e Paypal já adotam Swagger em seus produtos e projetos, principalmente em função da facilidade de integração com o código fonte.

Na hora de descrever a API é preciso que os arquivos sejam criados no formato JSON. Se por um lado isso facilita o trabalho de programadores, por outro pode ser algo complexo demais para alguém que não esteja tão envolvido com o código.

O Swagger é capaz de ajudar desenvolvedores de APIs REST a:

• Modelar APIs;

• Gerar documentação automatizada da API;

• Gerar códigos do cliente e do servidor, suportando diversas linguagens de programação;

• Testar funcionalidades da API.

Para realizar tais tarefas o Swagger precisa especificar a OpenAPI, uma linguagem para descrever contratos de APIs REST. Ela delimita um formato JSON com campos padronizados para que o usuário consiga descrever recursos, modelo de dados, URIs, Content-Types e métodos HTTP aceitos .

Além da OpenAPI, o Swagger dispõe um conjunto de ferramentas e as principais são:

• Swagger Editor

• Swagger UI

• Swagger Codegen

O módulo de UI permite que desenvolvedores interajam intuitivamente com as APIs em sandbox. Já o Editor é uma ferramenta online que possibilita documentar de forma mais interativa usando YAML. Um dos benefícios do Editor é seu portfólio contendo templates de documentos que servem de base para quem não deseja iniciar do “zero” a documentação.

Além disso, uma de suas principais funções do Editor é de que ao iniciar um novo projeto o usuário pode definir a toda a estrutura de sua API e assim gerar o código em uma linguagem de sua preferência

Quanto ao Swagger Codegen, a partir da descrição em YAML cria automaticamente o “esqueleto” da API com documentação em diferentes linguagens de programação.

A documentação para APIs pode ser feita de três formas:

1. Manualmente: o desenvolvedor escreve livremente as especificações da API e as publica posteriormente em seu próprio servidor.

2. Automaticamente: simultaneamente ao desenvolvimento da API é gerada a documentação.

3. Codegen: converte todas as anotações contidas no código fonte das APIs REST em documentação

A documentação interativa da API por meio do Swagger ainda inclui endpoints da API REST que detalham payloads, cabeçalhos, parâmetros, métodos HTTP necessários para solicitações e informações de código de erro.

Vale lembrar que investir em uma documentação mais interativa com o Swagger traz vantagens para o desenvolvedor que deseje futuramente consumir sua API, pois ele torna a integração desta mais rápida e de maior qualidade.

A facilidade de leitura do API Blueprint

Trata-se de uma linguagem de descrição e especificação de APIs baseada em Markdown, o que facilita a edição dos materiais por usuários que não estão familiarizados com códigos. A maior parte de suas ferramentas são open source, já que seu intuito é garantir que o desenvolvedor consiga projetar e criar protótipos de APIs em menos tempo, além de documentar e testar as APIs de missão crítica já implantadas.

Sua sintaxe é simples e concisa, mas ainda sim expressiva, permitindo que ela seja acessível a todos os envolvidos no ciclo de vida de uma API.

Há outros padrões muito conhecidos no mercado como o Swagger, mencionado acima, porém a curva de aprendizagem da API Blueprint é mais rápida. Quanto a leitura ela é fácil, pois as seções são bem definidas e agrupadas por rota, sendo que cada rota pode apresentar vários métodos HTTP diferentes com nomes associados a cada método

A documentação nesse caso mostra:

• Atributos listados com suas descrições

• Exemplos de solicitações

• Respostas desses exemplos

No caso do Blueprint, duas são as ferramentas integradas a ele que se destacam:

1. Dredd

Permite que o serviço de back-end seja testado com base na documentação da API. Dessa forma os problemas de atualização da documentação em questão podem ser resolvidos. A ferramenta é capaz de suportar linguagens como PHP, Python, Ruby, Perl, Node.js ou Go

1. Drakov

Permite que serviços simulados sejam iniciados e testados com solicitações/respostas adaptadas à documentação da API, o que pode ser visto como uma banco de ensaio.

RAML: de desenvolvedores para desenvolvedores

Trata-se de um acrônimo para RESTful API Modeling Language, logo RAML é uma linguagem para descrever explicitamente API RESTful. Além de tornar mais fácil o gerenciamento do ciclo de vida da API, o RAML é conciso e faz a legibilidade da API mais amigável ao ser humano.

Para documentar sua API com RAML, você pode optar por ferramentas open source como o Console da API ou o HTML RAML 2. A documentação pode ser gerada rapidamente, sendo que os analisadores disponíveis em vários idiomas permitem que a criação de documentos personalizados e scripts interativos, como Spotify.

O RAML tem como formato base o YAML, mas também é amplamente desenvolvido com base em outros padrões como JSON e é neutro com ferramentas de linguagem como Java, Javascript, .Net, PHP, Python, Ruby.

No caso do YAML, não se trata de uma linguagem de marcação, mas de uma para realizar a descrição de dados de maneira legível para desenvolvedores. Tal descrição, por ser muito utilizada por desenvolvedores facilita a compreensão do RAML, que suporta muitas práticas de reutilização e ajuda na criação de sua documentação a partir de pequenos blocos de construção.

Apesar disso, optar pelo RAML possui algumas desvantagens como ser destinado a APIs RESTful, dessa forma se sua Web API não seguir os mesmos princípios é possível que você não consiga usar o RAML adequadamente. Tal qual o API Blueprint, ele não se ajusta bem no caso de APIs não HTTP.

Outro ponto que se deve ter atenção é quanto a linguagem. O YAML é direcionado para desenvolvedores, ou seja, se este não utilizar uma ferramenta de design para criar a API ou a documentação, a equipe sem conhecimentos técnicos poderá ter dificuldades.

Documentação constantemente atualizadas

Como você pode ver as três ferramentas que citei acima são bons exemplos para manter sua API com um bom nível de documentação. Uma dica valiosa é se preocupar com este aspecto — a documentação — logo na concepção da API, assim o desenvolvimento e documentação podem caminhar juntos.

Em qualquer cenário, a ausência de material pode representar um afastamento de usuários em potencial. O lado bom é que hoje podemos contar com frameworks de documentação de APIs automatizados. As ferramentas mencionadas — Swagger, API Blueprint e RAML — apresentam recursos para criar automaticamente a documentação para todo o ciclo de vida de sua API.

Entretanto documentar por si só através dessas ferramentas não é o suficiente. É necessário que você como desenvolvedor mantenha seu trabalho atualizado, evitando documentações pobres ou obsoletas. Isso por que as APIs são modificadas a cada bug resolvido e nova funcionalidade são adicionada, ou seja, documentar sua API com as ferramentas corretas e regularmente atualizar o documento garante uma melhor comunicação para todos os envolvidos no produto.

Neste artigo compartilho com vocês algumas dicas importantes de como a sua empresa pode se conectar e fortalecer corretamente ecossistemas existentes.

Diferente de quando comecei a trabalhar como voluntário há onze anos, hoje muito se fala sobre ecossistema como um todo, não só sobre desenvolvimento, mas também de empreendedorismo e de inovação. Empresas, em especial as de grande porte, patrocinam não só grandes eventos, mas também promovem encontros, hackathons e desafios. Até aqui tudo bem, o problema está em como estas empresas estão conduzindo estas iniciativas, onde acabam confundindo voluntariado com exploração. Alimentação barata com prototipação gratuita.

Fortaleça iniciativas existentes

A melhor forma de iniciar o relacionamento de uma empresa com os ecossistemas existentes é através do patrocínio e incentivo. Isto porque a grande maioria dos ecossistemas são formados por grupos e comunidades de pessoas que atuam de forma voluntária. Voluntários ativos no mercado de trabalho que dedicam parte do seu tempo livre para compartilhar conhecimento através de artigos e postagens em grupos de discussão online, ou através de pequenos eventos (conhecidos como meetups) ou até mesmo em eventos de médio e grande porte.

Diferente do que possa parecer, o investimento é muito pequeno comparado com o impacto positivo gerado. Para a empresa que patrocina, o principal retorno é o relacionamento com os líderes destes grupos e comunidades, que serão bem úteis para conectar seu negócio com a audiência, em especial validando seu produto/serviço, ou até mesmo para a contratação de novos colaboradores.

Recomendo três tipos de ações:

1. Eventos menores, meetups e workshops: Muitas vezes os grupos/comunidades nem precisam de dinheiro diretamente, mas apenas de apoio ao oferecer um local para realizar o encontro, com infraestrutura e alimentação adequados. Dependendo do meetup, o dinheiro é necessário para uma produção mais profissional e também para o deslocamento de alguns membros e palestrantes.

2. Grandes eventos (Ex: Endeavor, CASE, Campus Party, iMasters e The Developers Conference): Grandes eventos oferecem uma estrutura bem organizada para os patrocinadores, desde pacotes de mídia como também todo o suporte para realizar ações antes e durante o evento. O investimento é maior comparado a minha primeira sugestão, porém, só o retorno de mídia tende a pagar o investimento realizado.

3. Espaços físicos (Ex; ONOVOLAB, Developer Hub — iMasters e WeWork): O investimento em espaços físicos tende a ser maior que as duas sugestões anteriores, porém, a presença da marca será fixa e ocorrerá ao longo do ano, bem como a oportunidade de engajamento com o público. Vale ressaltar que este apoio permite com que outras atividades (eventos/meetups/hackathons) aconteçam no espaço e, em muitas vezes de participação gratuita.

Crie conexões e promova a organização

Ao firmar um patrocínio dentre as sugestões anteriores, a empresa normalmente terá a oportunidade de se apresentar para a audiência. Muito cuidado aqui para não “fazer jabá”. Diferente de audiências tradicionais, aqui ela tende a ir embora ou simplesmente ignorar o que está sendo dito se o discurso for muito “genérico” ou “vendedor”. Aproveite esta oportunidade para ser transparente e sincero. Deixe claro os interesses da empresa e convide para que a audiência conecte-se com os colaboradores presentes. Crie um canal de comunicação direto. Isso será fundamental ao longo do relacionamento.

Outra oportunidade é aplicar a cultura do compartilhamento do conhecimento e de organização “orgânica” para dentro da empresa. Convide outros colaboradores que não fazem parte do projeto para participarem. Aproveite uma reunião geral ou encontro que a empresa realiza e convide quem participou para compartilhar sua experiência. Incentive para que isto aconteça com maior frequência, independente de ser um evento patrocinado pela empresa.

Valide seu produto/serviço e crie oportunidades de negócios

Ao patrocinar grandes eventos ou espaços físicos, a empresa poderá promover desafios que poderão ser apenas para receber ideias/sugestões ou até mesmo criar soluções em cima de um produto/serviço (ideal para hackathons). Esta é uma excelente oportunidade para receber feedback rápido e sem filtro do produto/serviço em questão.

Se o objetivo da empresa é apenas fomentar o uso, recomendo adotar um regulamento claro onde a propriedade intelectual do que está sendo feito é do autor.

Caso a empresa tenha interesse em utilizar o que está sendo criado, recomendo formatar um regulamento que também mantenha a propriedade intelectual, porém que permita o uso do que foi feito pela empresa.

Desafios e hackathons que transferem ou cedem a propriedade intelectual normalmente são criticados pelos grupos/comunidades quando a premiação não é proporcional com o valor que a solução pode ter para a organização.

É muito importante criar e validar o regulamento com empresas que possuem experiência na realização de desafios deste tipo. Convide um líder de comunidade para auxiliá-lo e até validar o regulamento, desta forma você terá uma opinião sem correr o risco dela estar “contaminada”. Mas lembre-se: essa relação ainda não é comercial, portanto, não extrapole. Aproveite os primeiros contatos para sentir se existe “fit” com a cultura da empresa. Existindo sinergia, contrate-o para uma consultoria pontual.

Outro ponto importante é deixar claro para os participantes qual é a expectativa da empresa ao realizar o desafio, se existirá uma continuidade de relacionamento ou não. Muitos participantes ficam frustrados pois criam uma expectativa de negócio ou de contratação que não acontecem.

Leve em consideração a opinião da comunidade/grupo na evolução de seu produto/serviço. Incentive a co-criação. Convide-os a participar de sessões de validação/entrevistas (presenciais ou remotas) para auxiliar no desenvolvimento e priorização do seu backlog. Você será muito mais assertivo e de quebra poderá mostrar o envolvimento da comunidade/grupo na sua priorização, mostrando que eles influenciam a tomada de decisão.

Coloque as dicas em prática

Estas foram algumas dicas que entendo que serão importantes para que a sua empresa tenha êxito no relacionamento com ecossistemas existentes, em especial com comunidades/grupos. Eu já tive a oportunidade de estar nos dois lados da mesa (como patrocinador e patrocinado). Caso você tenha dúvidas ou precise de alguma orientação, entre em contato comigo que eu terei o maior prazer em ajudá-lo.

Texto criado por David Ruiz e revisado por Kell Bonassoli

Quer ficar por dentro de novos artigos produzidos por mim ou pela Prensa? Cadastre-se aqui.