DEV Community: Inside SumUp Brazil

GANHANDO OLHOS DE ÁGUIA

Inside SumUp Brazil — Mon, 03 Jan 2022 14:36:34 +0000

Ampliemos nossa visão, como águias, para conseguirmos enxergar as barreiras e as oportunidades que nos conduzirão ao sucesso.

A nossa trajetória profissional, passa por diversas fases, a mais comum é quando iniciamos nossas carreiras através do ingresso no mercado de trabalho. Mas também há momentos que "viramos a mesa" e definimos um novo rumo para nossas vidas, quando surgem novas oportunidades de desenvolvimento clamando por novas competências, novas habilidades. Nesses momentos, várias preocupações surgem em nossa mente. Onde e como adquirir esses novos conhecimentos? O que devemos fazer para que o nosso desempenho continue no mesmo nível de excelência, seja no cargo atual ou em uma nova posição?

Pensarmos em nosso desenvolvimento, imaginando "qual será o nosso lugar" em um futuro é algo muito importante. Com essa projeção estamos fazendo o exercício sobre o que estamos pensando para nossas carreiras.

Jamais chegaremos a outra margem do rio sem os equipamentos necessários para nos levarem até lá

Ter objetivos de carreira é ótimo para nos impulsionar para novos estágios de nossas vidas. Mas não podemos nos esquecer que estes novos desafios exigem esforço e dedicação e precisamos tomar cuidado pois "jamais chegaremos a outra margem do rio" sem os equipamentos necessários para nos levar até lá. Isso significa que precisamos nos desenvolver nesta trajetória.

Quebrarmos grandes metas em pequenas vitórias.

Atingir grandes objetivos é algo muito desafiador e dificilmente acontece de uma vez. É preciso planejar, planejar e planejar… Aprendi muito nesta minha jornada pela busca de me tornar um líder, que são inúmeras as competências a serem desenvolvidas e a melhor forma é de "quebrarmos grandes metas em pequenas vitórias" para que elas nos motivem sempre. Assim chegaremos lá. Importante lembrar que traçar um plano para atingir a nossa meta é tão importante quanto a meta em si. Cada aprendizado, cada vivência contribui para nos tornarmos o profissional que queremos ser.

Onde estou e onde quero estar lá na frente.

A escolha de ser um líder, para mim, não aconteceu de forma natural. Não acredito que nascemos com nosso futuro traçado, definido. Esta reflexão sobre o futuro, se inicia com o desenvolvimento do nosso autoconhecimento, nossas potencialidades e onde queremos chegar. Observar atentamente por alguns anos me ajudou. Apesar de parecer óbvia essa decisão, não é tão simples assim.

Como me vejo no papel de liderança?

Eu fiz algumas perguntas do tipo: Eu me vejo no papel do meu líder? Parece ser algo que gostaria de fazer? No começo da carreira a resposta era: "Não tenho a menor ideia". Depois de algum tempo passou para: "ahh acho que sim, talvez" …. "até que virou hummm… é isso"!

Esteja perto das pessoas que admira, observe como elas agem, tomam decisões, se relacionam, se comunicam. O que elas fazem de especial que as tornam pessoas bem-sucedidas. Tem uma frase de Isaac Newton, que eu gosto muito que diz:

Se eu vi mais longe, foi por estar de pé sobre ombros de gigantes.

Materiais sobre liderança podem ajudar, mas nada como desenvolver o aprendizado no dia a dia do trabalho, ou seja, procure escolher lugares que nos proporcionem trabalhar com pessoas boas. Você admira seu Líder? Seus colegas? E as pessoas de outras equipes? Então se pergunte, o que posso aprender com eles?

E a cultura da empresa? Faz sentido em relação aos seus valores pessoais? Onde preciso me adequar, flexibilizar para aprender mais sobre ela.

Conhecimentos e tecnologias também se obsoletam e precisam mudar.

No Início eu precisava de conhecimentos mínimos para atuar na área, hoje com as novas exigências preciso ficar muito atento com o aprendizado. Pois conhecimentos e tecnologias também se obsoletam e precisam mudar. Um grande aprendizado, ao longo de minha carreira, está relacionado às mudanças de emprego.

Além das novas tecnologias, novas culturas o que me chamou mais a atenção foram os relacionamentos com as pessoas que trabalhei, que representaram muito mais do que os ganhos financeiros. Um bom ambiente de trabalho representa muito e se você tem isso como eu tenho significa um bom trabalho da liderança.

Converse com elas, faça perguntas, se aconselhem…

Com certeza as pessoas em posição de liderança não nasceram sabendo tudo o que sabem. Entender estes processos de desenvolvimento é fundamental para nós. E como saber disso? É simples, converse com elas, faça perguntas, se aconselhem…

"Quais insights ou dicas nos ajudaram a conseguir os nossos propósitos"?

A ideia aqui não é copiar o jeito das pessoas, mas entender o que as levaram a fazer o que precisava ser feito. Quanto mais conversas mais interessante fica. Cada uma vai nos abrir um leque de possibilidades para formar o futuro profissional que desejamos. Essas conversas serão importantes se tiverem elementos não só de sucesso, mas também de experiencias não tão bem sucedidas, pois aprendemos muito com as situações de dificuldades também. Quais insights ou dicas conseguiremos a partir de uma boa conversa com elas e que muito nos ajudarão a conseguir os nossos propósitos?

As experiências das pessoas são ferramentas incríveis para o nosso desenvolvimento. Nos dias de hoje é super simples o cultivo dos nossos alimentos porque em algum momento há 10 mil anos atrás o ser humano teve que aprender como fazer isso. A experiência é que nos impulsionou como sociedade até aqui.

Olhar mais profundamente para um cargo futuro me ofereceu várias ideias de como melhorar.

Algo que comecei a fazer depois de um certo tempo foi analisar todas as atribuições e valores dos meus líderes ou pessoas que admiro (algumas organizações têm essas competências bem definidas) e dentro de uma escala de 1 a 5 me avaliei em cada comportamento espelhado. Como você pode imaginar, na maior parte da minha análise me posicionei no nível 1 ou seja, uma forma muito clara de identificar as áreas e níveis de competência que eu precisaria buscar. É claro que eu também fiz isso também em relação ao meu cargo atual, mas "olhar mais profundamente para um cargo futuro me ofereceu várias ideias de como melhorar "e ainda crescer mais rapidamente para chegar aos meus objetivos.

Ao atingir o topo de uma montanha, é possível observar a existência de outra ainda mais alta

Esperava algum final feliz? Essa jornada só está no início. Eu apenas aprendi algumas dicas de como chegar lá. O caminho é longo. Podemos até usar uma metáfora que diz que "Ao atingir o topo de uma montanha, é possível observar a existência de outra ainda mais alta". É um processo contínuo, quanto mais experientes…maiores serão os desafios.

Você pode ter chegado até aqui e estar se perguntando…. Mas o que isso tem a ver com o título desse artigo? o que isso tem a ver com olhos de águia? Pegando os exemplos dos animais que têm a melhor visão na natureza entendemos duas coisas importantes.

A primeira é que os seres humanos não têm uma visão muito boa :) e que não existe o conceito de melhor visão. A melhor visão depende do objetivo. Para se movimentar a noite, a visão noturna é muito melhor do que visão a longo alcance.

Para a águia capturar o seu alimento, a visão de longo alcance é super importante. Quanto maior a altitude melhor ela consegue ter uma visão panorâmica de como achar a presa.

Toda a minha jornada profissional me mostrou que não basta termos uma boa visão no nosso cargo atual. Claro que isso é de suma importância para nos tornarmos um bom profissional, mas talvez não seja suficiente para nos levar ao local onde realmente desejamos estar. Para tanto é vital que ampliemos nossa visão, como águias, para conseguirmos enxergar as barreiras e as oportunidades que nos conduzirão ao sucesso.

Pensem nisso…

Quer uma nova oportunidade de carreira com desafios globais? Confira nossas vagas em Engenharia e Produto e conheça mais sobre a SumUp.

Elixir and NIF: A Case Study

Inside SumUp Brazil — Wed, 15 Dec 2021 20:38:05 +0000

Hello, devs! I'm Rodrigo Caldeira, Software Engineer at SumUp in São Paulo and I'll be sharing some thoughts about Elixir and NIF with a real story. This is my first contribution here, so I welcome any feedback.!

A little bit of context

I've been working at SumUp since Jan 2020 and after some reshuffles, I'm now in the Business Bank unit working directly with PIX features.
long with others events and meetings, there are two main events that the EP&D (Engineering, Product and Design) departments attend:

Lunch and Learn: In some places this is known as brown bag, the goal here is to have the opportunity to share knowledge during lunch time every Friday –anyone in EP&D can present about any related subject.
HackDay: Every two weeksan entire Friday is reserved to work with any non-SumUp related project. We can do work onliterally anything on this day.

With that said, this post details a bit more about my experience with theseevents.

During one HackDay, I was studying a way to do Slack integrations (without success =( ), when suddenly a QA Engineer called me.

QA Engineer: Hi, Caldeira! How are you? Could you help me with my HackDay project, please? I was trying to do something here, but now I'm stuck =/
Me: Sure! How can I help you? (at this point I had already given up on my project)
QA Engineer: Awesome! So, I'm trying to use a software to automate some tests here, but this software doesn't have an Elixir plugin (we use Elixir here in the Bank). Looking in the docs I found out that it is possible to create a plugin with their C library. Do you know how to do that?
Me: Whoa! That's a tough one! I never did that, but I know that's possible with NIF. Let's create a simple project to study a little bit, and then we come back with that library. What do you think?
QA Engineer: Great! Let's do it!

Spoiler: We didn't came back with that library.

So, that's the whole scenario here. The QA Engineer and I started a study case about Elixir and NIF on HackDay. The outcome of that HackDay was a Lunch and Learn that I presented two weeks after, and that's what I'm sharing with you right now.

The case

Elixir systems run over the Erlang BEAM virtual machine, and NIFs (Native Implemented Functions) are the way to extend Erlang software through loading and executing native pieces of software. Here, those software can be written in any language that compiles to native components, like Rust or C, and in this example I'll create and use a library in C and use it in a simple Elixir module.

So, let's start with our native library. It's a simple calculator that exposes four functions that receives two integer parameters and returns one integer:

For non-ortuguese speakers, my guess is that the functions' names should be straightforward, but here is the translation:

somar -> sum
subtrair -> subtract
multiplicar -> multiply
dividir -> divide

Great! Now that we have our library defined, let's compile it:

$ gcc -o lib_calc.so -c lib_calc.c

No errors, no warnings. Click noice!

BTW, I'm using Ubuntu on WSL2 for our example, but you should not face any problems with other distros.

Now it's time to test our library. To do that, I'll create another C program that will receive three parameters:

An integer number
The operator
An integer number

And compiling it:
$ gcc -o calc calc.c lib_calc.so

Once again, no errors.
Now, let's run our calculator:

$ ./calc 1 + 1 1 + 1 = 2

Awesome! It works!

Now, notice that in our calculator program I didn't do any kind of checking about the parameters sent to it. So, if we run it with an unexpected input, this is the result:

$ ./calc 1 [1] 388 segmentation fault ./calc 1

That's OK for us, for we are not interested in the C calculator.
So, with all that ready, how can we use our library inside an Elixir program?

The solution

To achieve that, we need to write another C program that will represent our NIF to Erlang and expose our calculator library to our Elixir module.

Holy moly! That's a lot of code for a simple library! Let's dig in.
The first line:

#include <erl_nif.h>

is the baseline of our NIF. It is the header of all basic NIF libraries with the functions and macros needed to create the NIF. It is located in the erlang-dev package.

After that, we have four more functions, each one representing the functions in our C library from a vertical point of view, so I will focus on only one of them, as the rest is basically the same.

static ERL_NIF_TERM somar_nif(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[]) { int a, b, result; enif_get_int(env, argv[0], &a); enif_get_int(env, argv[1], &b); result = somar(a, b); return enif_make_int(env, result); }

These lines declare a new static function called somar_nif that returns an ERL_NIF_TERM (a type that represent any Erlang term), and expects three arguments:

ErlNifEnv* env is a pointer that represents an environment that can host Erlang terms. Let's consider it as the environment that is running our NIF.
int argc contains the number of arguments that was passed to the function.
const ERL_NIF_TERM argv[] are the arguments passed to the function.

This resembles a lot like a regular main function in any C program.

int main(int argc, char ** argv)

When you have to read argv to get the values passed to your function, based on the number or arguments contained in argc.
And that's exactly what is happening inside the function:

// Our C variables int a, b, result; // Reads the first value and stores it in a enif_get_int(env, argv[0], &a); // Reads the second value and stores it in b enif_get_int(env, argv[1], &b); // Our lib_calc function been called! result = somar(a, b); // Transforms the result into an ERL_NIF_TERM and returns it return enif_make_int(env, result);

Here the argc is being totally ignored, as we already know that exactly 2 values are being passed as arguments.

After defining all our NIF functions, we have to inform the Erlang NIF API how to call them.

static ErlNifFunc nif_funcs[] = { {"somar", 2, somar_nif}, {"subtrair", 2, subtrair_nif}, {"multiplicar", 2, multiplicar_nif}, {"dividir", 2, dividir_nif}, }; ERL_NIF_INIT(Elixir.Calc, nif_funcs, NULL, NULL, NULL, NULL)

The static ErlNifFunc nif_funcs[] is an array of ErlNifFunc struct. This struct is defined as having the following variables:

name: The NIF function's name, that will be exposed in our NIF
arity: The NIF function's arity
function: The pointer to the function that will be called when the Erlang/Elixir module calls the NIF

There is a fourth variable in ErlNifFunc struct that is the flags, but for our example it can be omitted.

The last piece of code in our NIF is the ERL_NIF_INIT macro call, passing the module name, the functions that will be exposed in our NIF and points to functions dedicated to treat load, reload, upgrade and unload events (ignored here in our example).

Notice that the module name is Elixir.Calc, and not just Calc. That's necessary because our goal is to use this NIF in an Elixir module, and all Elixir modules from the Erlang perspective start with Elixir.

Phew! A lot of work here! Let's compile it and see what happens.

$ gcc -shared -o lib_calc_nif.so -fPIC lib_calc_nif.c lib_calc.so

Great! Again, no errors or warnings.

Notice the -fPIC flag passed to gcc. This is to inform gcc to create a Position Independent Code, which will generate an assembly code with relative address references.

And now, the moment of the truth! Let's create an Elixir module!

This, dear devs, is our Elixir module that will call our NIF! Taking a look you will notice this:

@on_load :load_nifs def load_nifs do :erlang.load_nif('./lib_calc_nif', 0) end

This defines a callback that will be executed when the module is loaded (@on_load :load_nifs), and the callback will load our NIF (:erlang.load_nif('./lib_calc_nif', 0)). Let's see it in action!

$ iex Erlang/OTP 22 [erts-10.6.4] [source] [64-bit] [smp:12:12] [ds:12:12:10] [async-threads:1] Interactive Elixir (1.12.0) - press Ctrl+C to exit (type h() ENTER for help) iex(1)> c("Calc.ex") [Calc] iex(2)> Calc.somar(1, 2) 3 iex(3)>

Hooray! It works!

Now, notice all the other functions defined in our module. They're just fallback functions, just in case the NIF was not loaded for whatever reason.

That's really great! But…

Not so fast! There are a lot of things to be considered here before we move on with our excitement.

First, remember how the arguments are declared in our C library?

int somar(int a, int b);

This function expects integer values. This behavior was passed all along with our journey here.

In fact, our NIF tries to convert the first argument to an integer.

enif_get_int(env, argv[0], &a);

What happens if we try to pass a value from another type?
Like a string, for example:

iex(3)> Calc.somar("test", 1) 32753

What?
Let's try with a float:

iex(7)> Calc.somar(1.0,1) 32753 iex(8)> Calc.somar(1,1.0) 1251267553 iex(9)>

oO???
What is happening here?!

Worse than that, if we keep calling the function with exactly the same value:

iex(8)> Calc.somar(1,1.0) 1251267553 iex(9)> Calc.somar(1,1.0) 1251267553 iex(10)> Calc.somar(1,1.0) 1251531297 iex(11)> Calc.somar(1,1.0) 1251531297 iex(12)> Calc.somar(1,1.0) 1251288249 iex(13)>

The return value changes!

This is because we didn't check inside our NIF to see whether the conversion was successfully done or not. So basically here we are getting junk values from the conversion.

Just trying to convert and sum (subtract, multiply or divide) and ignore the variable itself. So this can do no harm to our module. But remember, we are dealing with C here. Not Elixir, not Erlang. C. Pointers, memory… Can you imagine the scenario?

Besides that, what if we try to divide by zero?
iex(13)> Calc.dividir(1,0) [1] 501 floating point exception iex

The BEAM crashed! That's a huge problem with using NIFs: if the NIF crashes during the execution, the entire BEAM crashes.

So this is a feature that must be used very, very, very carefully.

Final considerations

I really love to study these kinds of topics. Understanding how things work under the hood is a powerful method to discover new possibilities and explore and extend my knowledge about a subject.

I don't intend to put any of these things in production, unless it's totally necessary:

If there is no time to develop an entire feature that is already implemented in a native library.
If there is a bug in Erlang modules that prevents you to deploy your feature.
If that native lib is so exclusive, so unique, and solves a huge problem, and there is no alternative to it.

I think you get the point here.

The source code of this project can be found at https://github.com/rodrigocaldeira/nif_cgo and there is a bonus there!
Thank you so much for following along!

Ready for a new career opportunity? Explore our open roles and learn more about our culture at SumUp: https://go.sumup.com.br/eb-dev-to-vagas

Por: Rodrigo Caldeira

O Poder do Módulo Task do Elixir - O Início

Inside SumUp Brazil — Tue, 30 Nov 2021 13:25:32 +0000

Caso prefira em inglês você pode encontrar aqui.

Recentemente eu estava estudando mais profundamente como o módulo Task funciona e para consolidar meus estudos decidi escrever esse post.

Antes de começar, vamos ver a documentação do módulo task. O melhor lugar para fazer isso é a documentação oficial do elixir. Aqui nós temos:

Conveniences for spawning and awaiting tasks.

Tasks are processes meant to execute one particular action throughout their lifetime, often with little or no communication with other processes. The most common use case for tasks is to convert sequential code into concurrent code by computing a value asynchronously

Ótima definição mas me mostre o código!!!!

Iniciando uma operação async

Nós temos duas maneiras básicas para executar uma operação async usando Task. É possível usar Task.start e Task.async. Vamos ver como isso funciona na prática.

Task.start
Task.start(fn -> IO.inspect("Hello") end)
{:ok, #PID<0.114.0>}

Task.async

Task.async(fn -> IO.inspect("Hello") end)
%Task{
owner: #PID<0.110.0>,
pid: #PID<0.118.0>,
ref: #Reference<0.626386777.2138832899.106529>
}

É possível ver que Task.start retorna uma tupla com :ok e PID, enquanto Task.async retorna uma struct Task. Ambas funções funcionam da mesma forma.

Geralmente precisamos esperar o resultado de algumas funções async para assim, poder executar a próxima ação. Vamos lá!

Esperando resultados

O exemplo anterior foi meio básico, vamos primeiro adicionar alguma um delay na execução para torna-lo mais complexo.

Task.async(fn ->
:timer.sleep(5000)
IO.inspect("Hello")
:ok
end)

Como vimos o resultado será uma %Task{}. Para esperar a response temos duas opções Task.await e Task.yield. Vamos ver as diferenças:

Task.await

O tempo de timeout padrão é 5 segundos;
Dado um timeout, ele lança uma exceção;
Após o tempo limite ser atingido, a task é interrompida;
Você pode definir um tempo limite personalizado ou usar o atom:infinity.

Task.await(task)
Task.await(task, :infinity)

Exemplo de timeout

task = Task.async(fn -> IO.inspect("Hello") ; :timer.sleep(10000); :ok end)

Task.await(task)
"Hello"
** (exit) exited in: Task.await(%Task{owner: #PID<0.110.0>, pid: #PID<0.124.0>, ref: #Reference<0.3761442499.262406148.76432>}, 5000)
** (EXIT) time out
(elixir 1.11.3) lib/task.ex:643: Task.await/2

Como podemos ver, um tempo limite é um pouco explosivo ao usar Task.await. Uma maneira de lidar melhor com isso é são Supervised Tasks.

Task.yield

O tempo de timeout padrão é 5 segundos;
Dado um timeout, ele retorna nil;
Usar o atom :infinity não é permitido como em Task.await;
Depois de um timeout atingido, mantém a task em execução;
É possível terminar uma task em execução usando Task.shutdown (task, shutdown \ 5000).

task = Task.async(fn -> IO.inspect("Hello") ; :timer.sleep(10000); :ok end)
Task.yield(task)
nil
# Let's check again
Task.yield(task)
{:ok, :ok}

Dado um resultado :timeout, a resposta será nil. Depois disso, podemos executar Task.yield novamente. Para evitar task de longa execução sem nenhum resultado, você pode usar Task.shutdown (task, shutdown \ 5000).

Um exemplo mais completo

Temos uma lista de itens e é necessário executar algum processamento em todos itens da lista.

items = ["alpha", "beta", "gama"]

Enum.map(items, fn item ->
  Task.async(fn ->
    :timer.sleep(4000)
    IO.inspect("Hello #{item}")
    :ok
  end)
end)
|> Enum.map(&Task.await/1)
|> function_to_handle_results()

Com essa abordagem, ainda temos a exceção quando acontece o timeout. No entanto, é possível lidar com isso de uma maneira melhor com Supervised Tasks, mas esse assunto será abordado na próxima publicação.

Conteúdo adicional

Originalmente publicado em https://dev.to on May 14, 2021.

Quer uma nova oportunidade de carreira com desafios globais? Confira nossas vagas em Engenharia e Produto e conheça mais sobre a SumUp.

Por: Felipe Araujo, Software Engineer

Manual de Liderança Técnica Ágil Parte 2/2: Práticas Efetivas de Comunicação para Guiar, Inspirar e Influenciar

Inside SumUp Brazil — Tue, 23 Nov 2021 15:27:49 +0000

Introdução
Em mais de uma situação, a pessoa que se tornou formalmente a líder técnica do time não é a que tinha mais tempo de casa ou a mais experiente tecnicamente: era a que mais sabia se comunicar com pessoas do time e fora dele. Mas esse é um tema bastante abrangente. Por isso, nesta segunda parte deste manual, vamos listar algumas práticas mais concretas que devem ser levadas em consideração. Mas todas são baseadas muito mais nas suas habilidades pessoais do que técnicas.

1. Fale no Idioma do Negócio

Uma das principais expectativas de qualquer liderança técnica ou pessoa com mais experiência é que elas consigam explicar qualquer coisa, por mais baixo nível que seja, de forma idiomática. É preciso utilizar termos que todos consigam entender, principalmente as pessoas menos técnicas e mais voltadas para a área de negócio.

Isso se torna ainda mais importante quando você precisa argumentar ou convencer pessoas que não são da área de desenvolvimento a aplicar alguma boa prática de código ou arquitetura que, quando explicadas de forma superficial, parecem não agregar tanto valor ao seu produto quanto uma nova funcionalidade agregaria.

Um bom e comum exemplo é quando queremos quebrar um monolito numa arquitetura de microsserviços. Se você precisa apresentar este grande e trabalhoso processo para um grupo, ou convencê-los de que isso precisa ser feito, não seja tão literal. Quanto mais poder de decisão uma pessoa tem, menos ela vai entender profundamente o que significam esses termos. E será ainda mais difícil fazer elas compreenderem ou serem convencidas, principalmente quando acompanhados de argumentos rasos como dizer que isso deve ser feito simplesmente porque todos estão fazendo, por ser uma boa prática ou porque foi publicado em algum artigo.

É preciso falar o idioma profissional deles que, com certeza, não envolvem as palavras monolito, arquitetura ou microsserviços. Por exemplo: "Hoje, todo nosso sistema está concentrado em um único lugar, isso dificulta a criação e o experimento de novas ideias, além de demorar bem mais que nossos competidores para entregar novas funcionalidades (traga dados contextuais e experiências suas aqui). Para resolver isso, existe uma boa prática chamada arquitetura de microsserviços, onde de forma gradual e estruturada, conseguimos dividir este grande sistema em sistemas menores. Assim temos mais liberdade e podemos escolher tecnologias mais apropriadas para uma dada necessidade de negócio. Além disso, ter sistemas desacoplados e bem definidos também ajuda na performance e diminui o custo de manutenção do nosso produto pois podemos prover mais recursos físicos somente para um serviço, e não para toda a aplicação que é o que temos que fazer hoje".

Sempre tente trazer termos mais próximos de um idioma comum ou explicar sucintamente (cuidado com a prolixidade) algo técnico que tenha surgido no seu discurso. Foque no que realmente importa: o valor que aquela alteração vai agregar ao negócio do seu produto. Inclusive, para qualquer decisão técnica que for tomada, questione sempre sua prioridade e se ela realmente agregará, mesmo que indiretamente, melhorias para seus clientes. É muito comum cair na armadilha de tomar uma decisão por puro preciosismo profissional ou pela imensa vontade de usar uma tecnologia mais moderna, por isso, tenha bastante cuidado.

2. Dê Feedbacks Positivos e Construtivos de Forma Estruturada

Não existe agilidade sem feedback. E isso não serve só para os feedbacks das pessoas que utilizam seu produto. Serve também para nós, pessoas do time e da organização, que queremos evoluir pessoalmente e profissionalmente. Quando melhoramos nossas habilidades, sejam elas comportamentais ou técnicas, o time trabalha com menos atrito, de forma mais fluida e ainda constrói um software melhor pois ele nada mais é do que um reflexo de seus responsáveis. Se nós melhorarmos, ele também vai melhorar.

Infelizmente, nem toda organização fomenta uma cultura de feedback e essa responsabilidade acaba sendo atribuída para um gestor. Na minha opinião, essa abordagem acaba sendo cômoda, mas impede uma evolução orgânica e inclusiva da própria organização. Além disso, é uma ferramenta muito poderosa para a vida pessoal de cada um pois fortalece, através de uma comunicação não violenta e genuína, nossos relacionamentos.

Outro ponto é que, geralmente, gestores não são técnicos ou estão há muito tempo afastados dos ofícios de desenvolvimento. Além disso, um gestor não está no dia a dia das pessoas técnicas do time: não fazem revisões de código, não pareiam, não estão presentes quando decisões técnicas são tomadas, etc. São só através dessas práticas que é possível entender o momento técnico de cada um e, assim, direcionar determinada pessoa para um caminho técnico que você julga importante dada sua experiência na área.

A forma de dar e receber feedbacks que mais funcionaram em todos os projetos que participei foram cara a cara, nas reuniões chamadas de 1:1. Elas aconteciam com determinada frequência dependendo do contexto (a cada uma ou duas semanas). Mas, para que isso seja possível, é necessário saber aplicar o ferramental de feedback. Caso contrário, podem ser gerados atritos entre as pessoas do time que vão resultar no oposto do nosso objetivo. Um bom livro sobre este tema é o "Comunicação Não-Violenta", de Marshall Bertram Rosenberg. Se precisar de algo mais rápido, existe este artigo que ensina o básico que deve ser seguido para realizar esses tipos de conversas.

Lembre-se que receber feedbacks também requer conhecimento. Por isso, certifique-se de que esse estudo esteja disseminado no seu time de alguma forma: dê uma apresentação com o que você aprendeu, assegure-se de que todas as pessoas leram sobre feedback ou pergunte se já adquiriram esse conhecimento em algum lugar.

Dito tudo isso, agora é a sua vez de atuar. Com sua experiência na área de desenvolvimento, comece a observar códigos e argumentos técnicos com a vontade genuína de não só destacar pontos positivos, mas também pontos de melhoria baseados em seus conhecimentos teóricos. Tome nota de todos eles, priorize os mais críticos caso tenha encontrado muitos e os organize de forma que se torne fácil entender o conhecimento que falta por trás dos pontos que você encontrou. Exemplo: Se, constantemente, uma pessoa desenvolvedora tem o costume de criar variáveis com nomes "a", "b" e "c", talvez seria uma boa ela entender mais sobre código limpo e suas vantagens.

E para fechar esta prática com chave de ouro, não esqueça de acompanhar a evolução das pessoas que receberam seu feedback e não hesite em trazer isso para elas, até mesmo de maneira informal. Por outro lado, lembre-se que feedbacks são presentes e que as pessoas podem fazer o que bem entenderem com eles: muitas vezes, por uma questão de contexto ou de prioridade, os pontos de melhoria que você trouxe podem ter sido deixados para um outro momento. E está tudo bem!

3. Compartilhe Conhecimento através de Mentorias ou Apresentações

Conhecimento bom é conhecimento compartilhado, principalmente nos times de desenvolvimento ágil. Deixar que se formem "silos" de determinados assuntos dentro do time é extremamente prejudicial: E se aquela pessoa faltar ou tirar férias? E se ela sair da empresa? E se isso tudo acontecer em meio a um bug crítico relacionado àquele assunto?

Mas além de evitar esses problemas, conhecimento compartilhado também gera aprendizado para todas as pessoas e ajuda a alcançar um dos principais objetivos de uma liderança: o alinhamento técnico para que o time tenha mais autonomia para não só proporcionar segurança para a tomada de decisão, mas também essa decisão ser baseada em padrões de código e arquitetura definidos pelo time.

Existem muitas formas de se compartilhar conhecimento. Escolha ou adapte uma delas de acordo com seu perfil e o contexto do seu time naquele momento. Se você se considera uma pessoa mais extrovertida e comunicativa, ou quer melhorar sua habilidade de falar em público, prepare apresentações mesmo pequenas e sem layout profissional. Nelas, fale sobre conhecimentos que você já estudou ou até mesmo alguma prática ou padrão que utilizou para resolver alguma tarefa do backlog. Outra ideia que já funcionou bem em uma equipe que fiz parte foi organizar coding dojos para refatorar trechos do código ou aprender alguma nova linguagem. Nesse tópico, você pode usar sua criatividade, o que importa é o conhecimento chegar da melhor forma para a maior parte de pessoas do seu time.

Em casos de pessoas que preferem não falar em público, existem práticas extremamente eficientes como a mentoria e o pareamento. A primeira trata-se de, através de reuniões frequentes, ensinar de forma teórica e prática um determinado tema para uma pessoa que busca aquele conhecimento. A segunda, o pareamento, é uma prática famosa no desenvolvimento ágil que, além de melhorar a qualidade da sua aplicação, permite que duas pessoas tenham mais domínio sobre o código e sobre o conhecimento de negócio relacionado à tarefa que está sendo feita.

A ideia neste tópico não é centralizar e se sobrecarregar com essa responsabilidade. Tome a iniciativa e, liderando pelo exemplo, certifique-se de que compartilhar conhecimento tornou-se algo cultural e orgânico no seu time. Encoraje, usando até mesmo feedbacks, todas as pessoas da equipe a realizarem estas práticas. Perceba quem na sua equipe tem bastante conhecimento em algum assunto, seja ele geral ou relacionado ao código ou produto, e incentive essa pessoa a compartilhar esses conhecimentos de alguma forma. Pelas minhas experiências, um time que compartilha conhecimento de forma natural tende a resolver problemas mais assertivamente e desenvolver tarefas com mais velocidade porque mais pessoas vão ter a capacidade de navegar sobre diversos contextos de negócio da aplicação.

4. Gerencie seu Tempo e Delegue Responsabilidades

Um dia eu ouvi uma frase que fez muito sentido: a função da liderança técnica é fazer com que o time não precise de uma liderança técnica. E, para isso, é necessário que você tenha uma boa gestão de tempo e saiba delegar as atribuições que lhe foram dadas para as pessoas à medida que elas evoluem tecnicamente.

Quando você é uma liderança técnica, mesmo sem esse rótulo formal, todas as pessoas de toda a organização buscam a você para resolver problemas ou discutir assuntos de maior calibre. E é natural, principalmente para quem está começando, a aceitar todos esses convites e se perder em um mar de reuniões.

Para resolver este problema e tornar a vida mais fácil, é necessário saber quando dizer não. Pergunte sobre o teor daquela reunião, avalie o contexto atual do seu time e o quanto ele precisa de você naquele momento, priorize esse encontro entre seus afazeres naquele dia. Feito essa análise, existem três opções: delegar aquela reunião para alguém do seu time que tenha contexto sobre aquele assunto, adiar esse encontro para um outro dia ou simplesmente aceitá-lo.

Para delegar uma atribuição é essencial que se pratique os tópicos anteriores: feedback e conhecimento compartilhado. Só assim você vai conhecer as forças e fraquezas das outras pessoas e ter segurança para convidá-los a resolver novos problemas. Isso também contribui muito para a evolução profissional daquela pessoa, tanto dentro quanto fora da organização, além de liberar mais espaço na sua agenda para você fazer tarefas mais prioritárias e urgentes (ou quem sabe codar?).

5. Resolução de Conflitos e Facilitação

Por mais alinhado tecnicamente que seja um time, sempre existirão divergências na hora de tomar decisões de forma colaborativa. A saída fácil e cômoda para esse problema é centralizar esse tipo de decisão nas pessoas mais experientes do time mas, por diversas razões, esse é um caminho a ser escolhido somente em cenários extremos.

Dois fatores são essenciais para nossa motivação profissional: sentir-nos co-autores do que estamos fazendo e quando alcançamos um propósito maior do que simplesmente desenvolver tarefas totalmente pré-definidas por alguém. E esses dois fatores são alcançados quando tomamos decisões de forma colaborativa, sejam elas técnicas, de negócio, ou relacionadas aos processos do time.

É claro que, dependendo da demanda do seu projeto, isso significaria encher o seu time de reuniões. Se for esse o caso, priorize as de maior impacto e aquelas onde o time tem mais contexto para argumentar e agregar à decisão final. Veja quais dessas reuniões de tomada de decisão podem ser opcionais ou, para alguns casos, chame somente as pessoas que tem conhecimento sobre o assunto relacionado à decisão.

Com o time reunido, seja a pessoa facilitadora daquela reunião. Introduza o assunto com a ajuda de desenhos e diagramas, lembrando sempre de mostrar o valor de negócio envolvido, e certifique-se que todos entenderam. Se já tiver pensado em caminhos a seguir, fica a seu critério apresentá-los ou não, pois se assim o fizer pode enviesar a decisão das pessoas do time e acabar perdendo ideias que poderiam ser mais interessantes que as suas.

Deixe a discussão rolar e vá anotando de uma forma que todos consigam ver os possíveis que estão aparecendo. Tome nota de seus pontos positivos, negativos e tente medir suas complexidades. Interfira na discussão sempre que necessário, como nos casos de alguém começar uma conversa baseada em uma premissa falsa ou perceber que se está perdendo muito tempo em um certo ponto que não está convergindo para lugar nenhum. Embora o ideal seja o consenso, tem horas que ele pode demorar muito e é preciso seguir em frente. Nesses casos, que devem ser exceções, pode-se abrir uma votação desde que o time entenda que a decisão tomada será de todo mundo, independente do seu voto. Seja sempre fiel ao tempo estipulado para aquela discussão.

Caso seu time esteja com bastante dificuldade em chegar a consensos, faça uma análise mais profunda de outros aspectos pois é um forte indicativo de um alinhamento técnico fraco. Será que precisamos compartilhar mais o que estamos fazendo no dia a dia? Será que precisamos parear mais? Será que existe algum conceito ou prática de mercado que nosso time precisa se aprofundar?

E é papel da pessoa facilitadora ajudar o time a chegar a um consenso. Quando existe um conflito, tente analisar as reais motivações por trás das opiniões contrárias. Faça perguntas para as pessoas envolvidas até chegar no real objetivo ou motivação de aquela pessoa preferir fazer daquele jeito. Essa tática é quase infalível para escolher um dos caminhos ou até mesmo construir um novo que contemple ambos. Além disso, muitas das vezes, percebe-se que as pessoas estão falando a mesma coisa mas de formas diferentes, o que causaria uma discussão longa e desnecessária que foi evitada pela sua habilidade de facilitação e resolução de conflitos.

Ao chegar perto do final, separe um tempo para sumarizar as decisões que foram tomadas e ter certeza que todo o time está alinhado. Também é aconselhável documentar essas decisões e a motivação delas (lembra do ADR?)

Encerramento

Não existe nada escrito em pedra ou balas de prata para problemas complexos. Não chegue amanhã no seu trabalho e simplesmente tente transportar tudo que foi exposto aqui achando que em pouco tempo será reconhecido como uma liderança técnica. A chave para esse processo está em entender a motivação e a essência por trás de cada um destes tópicos e, como toda boa pessoa agilista, adaptá-los para o contexto da sua organização, produto e equipe. Às vezes algumas práticas já estão sendo feitas de forma satisfatória ou sequer fazem sentido para seu contexto. Lembre-se que o objetivo nunca deve ser fazer as coisas para se tornar liderança e sim agregar valor de negócio ao seu produto, de forma direta ou indireta. Tudo que acontecer depois disso é consequência.

A verdadeira lição desse artigo não são os tópicos em si mas sim mostrar que uma das formas de evoluir tecnicamente é pensar fora da caixa e atuar em frentes que vão além das tarefas do seu backlog. Existe um universo de práticas possíveis que podem ser idealizadas e aplicadas quando você une sua criatividade e sua experiência. Não tenha medo de errar. Assim como no desenvolvimento ágil é comum testarmos hipóteses e falharmos o quanto antes, o mesmo serve experimentar ideias dentro do seu próprio time e de seus processos.

Espero ter contribuído de alguma forma para o seu momento de carreira ao compartilhar essas experiências e, por fim, te encorajo a compartilhar comentários, feedbacks, sugestões e experiências sobre os diversos temas que discutimos. Obrigado e até a próxima!

Confira a parte 1 do artigo aqui.

Quer uma nova oportunidade de carreira com desafios globais? Confira nossas vagas em Engenharia e Produto e conheça mais sobre a SumUp.

Por: Luiz Dias, Backend Software Engineer

O desafio dos e-mails não lidos: como criamos uma solução para melhorar a comunicação com consultores

Inside SumUp Brazil — Wed, 17 Nov 2021 12:37:19 +0000

Você tem muitos e-mails não lidos na sua caixa de entrada? E quanto às mensagens SMS, você abre aquelas que recebe? Melhor nem mencionar os grupos de WhatsApp cheios de "bom dia" então!

Vamos ser sinceros, sem medo de julgamento... Diariamente cada um de nós recebe tanta comunicação que fica difícil acompanhar tudo. Em meio às promoções de eletrodomésticos, lembretes para eventos online e boletos a serem pagos, alguma coisa sempre acaba se perdendo por ali. Acontece, não é mesmo?

E foi diante desse "caos da comunicação" que, aqui na SumUp, nos vimos com um desafio bastante complexo de resolver: como fazer os consultores de vendas lerem as nossas comunicações e ficarem a par das novas regras, campanhas e novidades?

Unimos esforços dos times de Comunicação em Vendas e Engenharia & Produto para criar do zero uma solução interna, customizada para atender às necessidades do programa e 100% dedicada a esse público.

O programa de consultores da SumUp

Embora hoje a SumUp seja uma empresa que oferece diversos produtos financeiros, entre eles a conta digital, o cartão de crédito e o link de pagamentos, no passado nosso único produto era a maquininha de cartão sem aluguel.

Além de vender maquininhas por meio do seu site oficial, já havia também uma iniciativa de "referrals" — no qual os atuais clientes da SumUp podem recomendar o produto para amigos e receber um bônus por cada indicação convertida em compra.

Ainda assim, havia uma grande oportunidade para crescer a força de vendas de forma presencial por meio de representantes de vendas espalhados por todo o país. Foi assim que o programa de consultores da SumUp teve início em 2017.

Quase quatro anos depois, nosso programa hoje conta com mais de 16 mil consultores atuando na maior parte dos estados brasileiros, sendo responsável por trazer quase um terço dos novos clientes da SumUp. Conforme o programa ia crescendo e se consolidando ao longo dos anos, percebemos a importância de construir e oferecer uma plataforma online que concentrasse todos os relatórios e ferramentas úteis para o dia a dia desse consultor ou consultora.

O Portal dos Consultores é oficialmente lançado

Com o objetivo de centralizar dados sobre as vendas mensais dos consultores em tempo real, além de oferecer uma lojinha interna para que todos pudessem repor seu estoque de maquininhas, o Portal dos Consultores foi ao ar no final de 2018.

Ele começou como uma aplicação dedicada somente aos representantes de venda do Brasil, mas hoje já pode ser utilizado também por parceiros localizados em países como França, Alemanha, Itália e Reino Unido.

De lá para cá, diversas outras ferramentas, relatórios e recursos foram adicionados ao Portal — desde o fluxo de signup (criação de conta) para novos consultores, relatórios de gerenciamento de estoque e de clientes, e até mesmo uma central de notificações.

E é sobre essa ferramenta de comunicação que eu quero abordar e compartilhar nossos esforços e aprendizados! Da ideação e design de interface ao desenvolvimento do código no front-end no back-end, cada decisão de produto foi pensada em conjunto por profissionais de comunicação, produto e engenharia de software para chegarmos à solução ideal para os nossos consultores.

Essa é a carinha do Portal dos Consultores hoje, depois de diversas atualizações e melhorias

Uma Central de Notificações para o Portal

Em meados de abril do ano passado, o squad de Partners Engagement — do qual faço parte e é responsável por criar estratégias e ferramentas para ajudar os consultores a aumentarem sua produtividade em termos de vendas — e o time de Comunicação deram início a uma força-tarefa para, juntos, atingirem um objetivo em comum: entender quais as dores dos consultores em termos de comunicação e desenvolver uma solução capaz de resolver esse problema.

Nosso primeiro passo diante do desafio foi, de fato, mapear quais dores e incômodos seriam esses. Optamos por rodar uma sessão inspirada no design sprint, uma metodologia voltada à prototipagem de produtos e soluções. Em geral, a prática sugere que sejam percorridas as cinco etapas de (1) entendimento/definição, (2) divergência, (3) decisão, (4) prototipagem e (5) validação de uma solução.

Nosso time, no entanto, permitiu-se uma "licença poética". Inicialmente, iríamos focar a task force nas três primeiras etapas dela, sem necessariamente já rascunhar protótipos ou soluções.

O objetivo era, portanto, definir muito bem o nosso problema. Isso porque, a depender do desfecho da nossa conversa, poderíamos então pesquisar ferramentas já existentes no mercado e adicioná-las à lista de alternativas para atacar o desafio de comunicação com consultores, quem sabe até mesmo integrando uma delas ao Portal dos Consultores.

Definindo o problema a ser resolvido

Uma vez que estávamos todos trabalhando remotamente na época, decidimos usar como ferramenta o Miro — um whiteboard online (literalmente, uma grande tela em branco, como uma lousa) onde times podem colaborar na construção de diagramas e até mesmo realizar brainstormings de ideias com post-its coloridos. Foi nesse segundo ponto em que focamos, aliás.

Em conjunto, levantamos uma série de dificuldades vividas pelo time de Comunicação ao tentar transmitir mensagens aos consultores de vendas. Vale lembrar que, até o lançamento da nossa Central de Notificações, ferramentas mais comuns já vinham sendo utilizadas para fornecer conteúdo a esse público: e-mails, newsletters, grupos de WhatsApp, mensagens de SMS, etc.

Basicamente, as comunicações se encontravam "esparramadas" em diversos canais diferentes e era complicado trackear quem visualizou ou não cada uma delas. Isso sem contar a dificuldade que o consultor tinha de recuperar um comunicado mais antigo — o e-mail se perdia, o SMS era apagado, o histórico do WhatsApp era muito extenso e complexo de se acessar.

De forma bastante resumida, listamos as seguintes dores:

Como centralizar os muitos tipos de comunicação num único lugar?
Como medir a efetividade da comunicação?
Como armazenar o histórico de comunicações enviadas?
Como compartilhar e reunir materiais de trade marketing?
Como segmentar/personalizar os comunicados para cada consultor conforme seu nível no programa?
Como automatizar nossos envios e ter uma régua de comunicação?
Como engajar o consultor a querer vender mais e subir de nível para receber um bônus maior?

Uma vez que o nosso design sprint tinha como objetivo convergir em um problema com escopo um pouco mais específico e fechado, filtramos entre as dores os seguintes focos: centralizar comunicações, mensurar acessos e armazenar histórico. O que já é bastante coisa para se resolver a partir de um único MVP — do inglês, um produto viável mínimo, ou seja, uma versão inicial, mas que já entrega valor ao usuário.

A solução que implementamos no Portal

Quando tivemos de decidir que tipo de solução poderia ser implementada, começamos a pensar se valeria a pena ter uma ferramenta desenvolvida de ponta a ponta pelo nosso squad de Partners Engagement (do front-end ao back-end), se poderíamos encontrar uma solução pronta (dentro ou fora da SumUp) a ser integrada ao Portal dos Consultores, ou mesmo se queríamos contratar um serviço externo, já existente e consolidado no mercado.

Depois de analisar diversos prós e contras, nosso time optou por criar do zero uma Central de Notificações dentro do Portal, desde o design até o código front-end e back-end que seriam voltados para a solução.

Não optamos por utilizar uma ferramenta externa e pronta porque, uma vez que esse era um MVP ainda a ser testado com os consultores, poderíamos nos comprometer com a contratação de uma empresa terceirizada e investir dinheiro em uma ideia que não traria retorno. Este seria um risco que optamos por não correr naquela época, pois seria melhor ter certeza da adesão dos usuários e da eficácia da plataforma em termos de resolver o nosso problema. Além disso, significaria mais uma ferramenta que o consultor precisaria acessar em adição às demais — e-mail, SMS, WhatsApp e o próprio Portal dos Consultores.

Também descartamos a ideia de integrar o Portal a outra solução como, por exemplo, o Salesforce (sistema de gestão de relacionamento com o cliente) ou Contentful (sistema de gestão de conteúdo). Embora ambas já sejam utilizadas em outras situações pela SumUp, a integração com o portal levaria mais tempo do que o desejado por nós.

Então, quando chegou a hora de colocar a mão na massa para criar nossa própria Central de Notificações, o que usamos?

No back-end, utilizamos a linguagem Go para criar um microsserviço voltado à Central. Foram desenvolvidos quatro endpoints, dedicados às seguintes requisições:

[GET] Devolver a lista completa de mensagens disponíveis ao consultor;
[GET] Devolver uma mensagem específica para leitura — o que ajudaria em performance, já que cada comunicado é um grande arquivo HTML/CSS e seria pesado já trazer todos eles de uma única vez no carregamento inicial da página;
[PUT] Atualizar o status de uma mensagem específica para is_read: true no banco de dados quando ela é clicada na listagem;
[POST] Permitir o upload de novos arquivos HTML/CSS diretamente no banco de dados, assim o time de Comunicação passaria a ter autonomia para subir novas mensagens sempre que quisesse.

No front-end, o Portal já vinha sendo desenvolvido em JavaScript/TypeScript e React, além de utilizar GraphQL e Apollo Client para conectar interface e APIs. Vale destacar algumas especificidades da Central durante o seu desenvolvimento:

O conteúdo das mensagens mostradas na tela chegam sempre em formato HTML com base em um template de e-mail marketing já utilizado/reaproveitado pelo time de Comunicação — se fazendo necessário importar todo o estilo CSS padrão para garantirmos que nada quebrasse visualmente;
Queríamos uma notificação vermelhinha que sempre aparecesse ao lado do item de menu "Notificações" quando uma mensagem nova chegasse até que ela fosse lida. Antes de finalmente decidir estilizar, colorindo-a de vermelho, arredondando com border-radius: 50% e definindo sua localização na tela com position: absolute, quase cogitamos usar um emoji de cereja! (🍒);
Quando implementamos a diferenciação de estilos para mensagens lidas e não lidas, o estilo só mudava após um refresh na página — o que seria péssimo, pois queríamos a mudança acontecendo no exato milissegundo do clique. Descobrimos que, se o endpoint do [PUT] devolvesse na sua resposta também o id da mensagem, o Apollo Client atualizaria os dados em cache e o React se encarregaria de resolver o restante 🙏 (no caso, passando tudo para um tom mais acinzentado).

Vale mencionar que a Central de Notificações foi lançada em duas grandes ondas, como todo bom MVP que vai sendo iterado com o objetivo de permitir entregas de valor mais rápidas e melhorias constantes.

A primeira entrega liberada para os consultores ainda não contava com a possibilidade de chamar o endpoint de [PUT] para diferenciar visualmente mensagens lidas de não lidas, nem enviava eventos de cliques ao Google Analytics. Ela estava focada na visualização da lista de mensagens, na possibilidade de clicar em cada uma para ler o conteúdo HTML completo e na "cerejinha" visível no menu do Portal chamando a atenção do usuário sempre que houvesse uma ou mais mensagens não lidas.

Por fim, o endpoint de [POST] também foi liberado — porém disponível somente ao nosso time interno, por meio de uma VPN — para que a adição de novos conteúdos fosse algo simples, rápido e sem qualquer burocracia ou dependência.

Já na segunda entrega, conseguimos implementar estilos diferentes para que ficasse mais fácil de o usuário perceber o que já havia sido lido ou não. Também passamos a trackear acessos à página da Central e também os cliques por mensagem, comparando o desempenho da nova ferramenta em relação a outras anteriormente usadas pelo time de Comunicação.

Esboço da Central de Notificações adicionada ao Portal dos Consultores

Após um mês no ar, as mensagens publicadas já atingiam uma taxa de abertura de 51% para novos consultores — o maior open rate que uma ferramenta dedicada ao público já chegou aqui na SumUp, uma vez que o recorde era de cerca de 32% antes da Central de Notificações.

Além disso, no acumulado de junho de 2020 a setembro deste ano, os eventos de clique do Google Analytics relacionados à Central de Notificações figuram entre os 10 mais frequentes de todo o Portal. Também, convenhamos, ninguém resiste a uma "cerejinha" vermelha chamando a atenção no menu!

Por: Ceci Sousa

Quer uma nova oportunidade de carreira com desafios globais? Confira nossas vagas em Engenharia e Produto e conheça mais sobre a SumUp: https://go.sumup.com.br/eb-dev-to-vagas

Manual de Liderança Técnica Ágil Parte 1/2: Práticas Essenciais ao Criar e Evoluir um Produto com Qualidade

Inside SumUp Brazil — Tue, 26 Oct 2021 19:47:43 +0000

As expectativas sobre lideranças técnicas, ou qualquer pessoa que ocupe um cargo técnico mais alto, tendem a ser bastante implícitas e variadas de acordo com o contexto do time ou da organização. Mesmo as formalizando em documentos ou conversas, sempre vão haver necessidades essenciais a qualquer produto que não necessariamente serão ditas de forma explícita. E nestes dois artigos tento trazer algumas dessas práticas que são quase sempre esperadas, mas nem sempre ditas.

A liderança técnica deve ser uma consequência e não um objetivo, e é ideal que surja de forma natural. Considerar e adaptar as práticas listadas neste artigo nada mais é que uma forma proativa de amadurecer profissionalmente. O que acontecer depois disso é, como mencionado, consequência.

Outro ponto importante é que você não precisa ser a pessoa responsável por tudo isso. Mas precisa sim, como alguém que almeja amadurecimento técnico, priorizar e aplicar essas práticas tendo em vista sempre o momento e a natureza do seu negócio. Não tente trazer todas de uma vez e, depois de iniciadas, não esqueça de garantir que estão sendo revisadas constantemente (não necessariamente por você).

Antes de começar…

Primeiro de tudo, assegure-se de que você já está fazendo o esperado pela sua equipe e líderes diretos. Você está demorando muito para entregar tarefas consideradas medianas pela sua equipe? Está tendo, com certa frequência, dificuldade para realizá-las mesmo em linguagens e tecnologias a qual considera que tem conhecimento?

Se a resposta for sim, não tente adquirir novas responsabilidades. Use esse catálogo para cobrar atitudes das suas lideranças ou das pessoas mais experientes do seu time e, por enquanto, busque proativamente formas de ganhar conhecimento e segurança: pratique pareamento com pessoas da equipe, peça feedbacks técnicos sobre seu código, procure um mentor para te ajudar com as tecnologias envolvidas, etc. É necessário que tanto você quanto às pessoas ao seu redor tenham muita segurança na sua entrega do dia-a-dia antes de arranjar novas atribuições. E se conscientizar disso já é uma grande vitória.

Caso contrário, se você acha que já existe uma confiança na qualidade e velocidade da sua entrega, ainda não siga em frente: certifique-se desse fato. Busque feedbacks técnicos de forma proativa. Além de demonstrar maturidade profissional, você também garante que é uma pessoa pronta para ser responsável por atividades mais desafiadoras.

Agora, é hora de listar algumas atribuições, que nem sempre são explícitas ou formais, esperadas de lideranças técnicas ou pessoas que almejam mais maturidade na área de desenvolvimento. São práticas essenciais que, por quase todas as equipes que participei, tornaram o desenvolvimento do software mais sustentável e fluido, com bem menos atritos, imprevistos e falhas.

1. Priorize e Acompanhe os Requisitos Transversais (ou Não-Funcionais) do seu Produto

Requisitos transversais são aqueles fatores que vão além de tarefas ou histórias de usuário, mas são igualmente importantes para o funcionamento da sua aplicação: performance (tempo de resposta), disponibilidade, acessibilidade, escalabilidade, efetividade, etc. Uma longa lista deles pode ser encontrada nesse link.

Estes requisitos são considerados imprescindíveis, mas se costuma olhar para eles somente em momentos extremos quando já é tarde demais. Exemplo: um longo tempo de resposta, multas governamentais por não respeitar leis de acessibilidade, erros inesperados da aplicação quando sujeita a uma maior quantidade de requisições, etc.

A ideia aqui é priorizar cerca de três destes requisitos dentre os existentes e coletar métricas relevantes relacionadas a eles. Esta é uma quantidade razoável, mas pode variar segundo o momento e a cultura da sua equipe. E sim, todos eles são importantíssimos, mas uns merecem mais atenção que outros dada a natureza do seu negócio. Deixe isso claro para todas as pessoas: despriorizar segurança não quer dizer que não vamos considerá-la em nossas tarefas, mas, dependendo do produto, ter 100% de disponibilidade é mais crítico para o negócio do que criar testes de intrusão (pen tests) ou rodar dinâmicas de modelagem de ameaça (threat modeling) toda semana. Depois de priorizados, mantenha viva no time a cultura de preocupar-se com eles a cada passo dado: adicione novos passos em sua pipeline de entrega contínua, adicione outros tipos de testes automatizados, adicione critérios de aceite às suas tarefas de negócio e até mesmo crie alertas em seu sistema de monitoramento baseados nas métricas coletadas daqueles requisitos.

Precipitar esses problemas e evitar que eles aconteçam vai não só gerar aprendizados para toda a equipe, mas também o avanço de algumas casas na sua trajetória como pessoa desenvolvedora.

Por último, é necessário garantir que estes requisitos estejam sempre sob controle e, para isso, vamos coletar e acompanhar métricas relacionadas. No entanto, pela abrangência e importância dessa prática, é ideal que ela tenha um tópico exclusivo e aprofundado…

2. Colete e Acompanhe as Principais Métricas da sua Aplicação

Todo time ágil deve saber ou ter fácil acesso a certas métricas técnicas de seu produto. Elas podem variar dependendo da sua natureza, mas existem algumas consideradas básicas que precisam de monitoramento contínuo e em tempo real: qual o tempo médio de resposta da sua aplicação e de seus casos de uso? Qual a porcentagem de falhas inesperadas que chegam até o usuário final? Qual a quantidade de requisições ou utilizações do seu sistema e suas funcionalidades?

Uma lista mais completa dessas métricas pode ser encontrada neste link. Mas não se prenda a elas. Algumas que gosto de acompanhar e não estão nessa lista são as coberturas de testes unitários e de testes de mutação: juntas, ambas dão maior garantia de que seu software está sendo construído de forma sustentável e expansível.

Com isso em mente, junte seu time ou faça você mesmo uma priorização do que precisa ser medido dado o contexto da sua aplicação. Analise se possui as ferramentas necessárias para essas medições e, caso negativo, converse com o time para priorizar atividades que tornem essas medições viáveis como, por exemplo, adicionar mais logs no seu código.

Feito isso, crie painéis organizados com elas (geralmente com alguma ferramenta de monitoramento como o Splunk ou Datadog) e, se possível, deixe-os em um lugar visível para todo o time. Dessa forma, qualquer alteração suspeita no valor dessas métricas será mais perceptível e terá sua causa encontrada e corrigida mais rapidamente.

Por último, crie alertas na mesma ferramenta de monitoramento baseado nelas. Não é garantido que vai ter sempre alguém olhando para esses painéis e atento às variações de valores, então os alertas são importantíssimos para garantir ainda mais uma resposta mais rápida a falhas.

Não se esqueça que esses painéis e alertas agora fazem parte do seu produto. E, como uma espécie de documentação, devem ser constantemente atualizados à medida que o time faz novas entregas. Uma boa ideia é considerar essas métricas e alertas durante a criação das histórias de usuário e adicionar, como critério de aceite, a criação de novos ou atualização dos existentes.

3. Mantenha sua Documentação, seus Diagramas de Arquitetura e Desenhos de Casos de Uso Organizados e Atualizados

É de senso comum que todo software precisa de uma documentação clara e sempre atualizada. Mas, quando estamos começando na nossa carreira de desenvolvimento ou trabalhando sob pressão de entregas e prazos, é comum entrarmos num ciclo vicioso de entregar tarefas preocupando-se apenas com seu funcionamento e deixando de lado outras partes tão importantes quanto a própria entrega. Em muitos times que participei, uma dessas partes esquecidas eram as documentações.

Ter suas documentações sempre atualizadas é essencial não só para as pessoas que utilizam seus serviços, mas também para o seu próprio time e organização. É com elas que conseguimos manter uma cadência na velocidade de entrega pois, quando bem construídas e organizadas, temos fácil acesso a diversas informações que servem de base para nossas próximas funcionalidades e para novas pessoas integrantes da equipe. Por isso, quando falo de documentação, não estou falando somente daquele catálogo de endpoints dos seus serviços, mas também dos READMEs dos seus projetos e os diagramas de arquitetura e de casos de uso (ou de fluxo) da sua aplicação.

Não estou querendo dizer que é papel das lideranças técnicas manter esses artefatos atualizados. Sua responsabilidade (como deveria ser a de qualquer outra pessoa do time) é garantir que isso está acontecendo de forma natural e que todo o time entende a importância dessa prática. Caso isso não esteja acontecendo, sugira novos processos ou cerimônias para sua equipe até que, organicamente, todos considerem atualizar as documentações como parte das tarefas de desenvolvimento. Algumas ideias: pontuar nas histórias de usuário qual artefato deve ser criado ou atualizado, criar cerimônias com certa frequência para o time revisar junto as documentações, dar feedbacks para as pessoas que não o fizerem junto com suas tarefas, etc.

E não se esqueça que parte fundamental dessas documentações são os diagramas de arquitetura do seu sistema e dos casos de uso (ou de fluxo) das suas funcionalidades. Elas devem ser capazes de responder a perguntas como: Com quais outros sistemas o meu produto se comunica? Quem são as pessoas, equipe ou empresa responsável por esses sistemas? Qual é a tecnologia desses sistemas? Por quais sistemas uma requisição passa para fazer uma dada operação? E quais informações são trafegadas entre eles?

Ter a resposta para essas perguntas em boas documentações torna-se cada vez mais essencial a medida que seu produto evolui e poupa bastante tempo em diversas situações. Uma sugestão para desenhar seus diagramas de arquitetura é utilizar o modelo C4 com as ferramentas Draw.io ou Miro. Também existe uma prática bastante reconhecida no mercado chamada ADR (Architecture Decision Record): ela serve para documentar as decisões arquiteturais do seu time e responder, sem depender da nossa falha memória, dúvidas do porquê determinada implementação foi feita daquela forma (quem nunca passou por isso?).

Caso sua equipe seja responsável por "APIs" ou qualquer serviço de backend, existem uma série de ferramentas que não só criam e atualizam uma documentação de endpoints de forma automatizada, mas também a torna usável para que pessoas consumidoras possam fazer testes e requisições. Uma dessas ferramentas é o famoso Swagger. Ele é capaz de gerar uma documentação bastante intuitiva e possui plugins, para quase todas as linguagens de mercado, para gerar a documentação dos seus endpoints através do próprio código, sendo possível versioná-la e publicá-la para toda a organização a cada entrega feita pelo time.

Para diagramas de casos de uso, eu gosto muito do PlantUML, um plugin para desenhar diagramas UML utilizando uma linguagem própria de fácil entendimento. Dessa forma, é possível versionar estes diagramas ou até mesmo colocá-los juntos no mesmo repositório da sua aplicação (mais aconselhado).

4. Lide com Dívidas Técnicas (ou Débitos Técnicos)

Dívidas técnicas são consequências de escolher um caminho mais fácil e rápido para alcançar um objetivo, mesmo sabendo que existe um outro melhor e mais aderente aos bons padrões de código e arquitetura. É uma escolha consciente que pode ser feita por falta de tempo, conhecimento ou ferramentas naquele contexto. E não tem nada de errado com isso! O erro está em você não ter uma estrutura na sua metodologia para documentá-lo e nem um processo para priorizar essas dívidas e garantir que, um dia, ela será paga.

Quando se trabalha em times onde sequer existe o conceito de dívida técnica, as consequências são trágicas (por experiência própria): em uma questão de meses, toda a performance do sistema foi comprometida, além do aumento da taxa de falhas e demora crescente para o time entregar novas funcionalidades pela complexidade do código. Não digo que essas dívidas foram as únicas culpadas, mas certamente contribuíram de forma majoritária para chegar nesse caótico cenário. Tudo era deixado pra depois: a refatoração de classes e métodos enormes, a criação testes automatizados básicos, a melhoria no design de alguns componentes do projeto, etc.

Existem algumas formas de lidar com dívidas técnicas que funcionaram comigo quando percebi que esse cenário poderia voltar a acontecer. Uma delas foi primeiramente marcar um encontro com toda a equipe para alinharmos o conceito de dívida técnica. No mesmo encontro, por não termos muitas dívidas mapeadas, fizemos um brainstorm dos débitos técnicos que havíamos acumulado em alguns meses de projeto. Validamos cada um deles e, depois de ter certeza que eram realmente dívidas e que todos entenderam seu contexto, priorizamos cada uma delas em uma matriz de dor (baixa, média e alta) e esforço (alto, médio e baixo). Em nosso backlog, criamos esses débitos dando prioridade aos de esforço mais baixo e dor mais alta e combinamos com as pessoas responsáveis que, a cada iteração, iríamos pagar pelo menos duas dívidas técnicas por ordem de prioridade.

No final da dinâmica, também combinamos um processo para mapear essas dívidas no nosso backlog: sempre que uma pessoa desenvolvedora gerar um débito técnico, ela mesmo o criava e o priorizava dentre os existentes. Além disso, mensalmente, todo o time se reunia para todos terem conhecimento das novas dívidas geradas naquele período e, se necessário, repriorizá-las.

Por último, mas longe de ser o menos importante: assegure-se que todo seu time entende a importância deste tema e, com isso, mantenha viva a cultura de mapear e pagar dívidas técnicas. Adapte o exemplo dado ou crie novas abordagens que você acha que vão funcionar para o contexto e cultura da sua organização e do seu time e que, mesmo em tempos difíceis e de prazos apertados, elas não cairão no esquecimento.

5. Codar

Isso mesmo, codar, nem que algumas horinhas na semana! É muito comum as lideranças técnicas não terem tempo para programar. Porém, desenvolver tarefas é a melhor forma de ficar mais próximo da realidade das pessoas lideradas e conseguir tomar ações mais precisas. Ações essas que não estarão em artigos ou livros pois são extremamente relacionadas com o contexto que seu time está passando naquele momento.

Então, se você é uma liderança técnica ou uma pessoa desenvolvedora e está sem tempo para programar, reveja suas atuais responsabilidades e atividades. Pense no que pode ser delegado ou adiado e assim o faça.

Quando for programar, se possível, tente parear com pessoas do seu time para conhecê-las ainda mais e conseguir até mesmo dar feedbacks mais assertivos. Parear também, como já mencionado, é uma ótima oportunidade para compartilhar conhecimentos adquiridos com o seu provável muito tempo de projeto.

Ainda não acabou…

No segundo e próximo artigo, vamos falar sobre tópicos menos técnicos e mais relacionados à comunicação dentro e fora do seu time. Como qualquer liderança, a forma de se comunicar cativa, influencia e evolui as pessoas ao seu redor e vou listar alguns tópicos a serem considerados para quem quer alcançar esse tipo de papel em uma organização.

Fica de olho que dia 15/11 temos a parte 2!

Quer uma nova oportunidade de carreira com desafios globais? Confira nossas vagas em Engenharia e Produto e conheça mais sobre a SumUp.

Transações com Ecto

Inside SumUp Brazil — Mon, 18 Oct 2021 20:48:50 +0000

Transações em bancos de dados são um tema recorrente no dia a dia de pessoas desenvolvedoras de software. Em bancos de dados SQL, muitas vezes enfrentamos situações onde alterações em múltiplas tabelas são necessárias para completar uma transação de negócio. Para garantirmos a integridade da operação, transações são necessárias de forma que, em caso de alguma das operações falhar, independente de em qual momento a falha ocorrer, todas as anteriores sejam revertidas e as pendentes não sejam executadas.

Imaginando agora um exemplo em uma arquitetura de microsserviços que trocam mensagens através de um broker (como o Apache Kafka, ou RabbitMQ), tanto a persistência de uma operação no banco de dados local de cada serviço, quanto o envio de uma mensagem relacionada para um broker precisam ter as mesmas garantias em casos de falha. Alguns patterns para lidar com esse problema já são bem conhecidos e utilizados em casos mais complexos, como Two-phase commit, Sagas e Transactional Outbox.

Para casos mais simples, porém, uma forma de lidar com ele é incluir como parte do código que vai executar em um contexto de transação, a publicação dos eventos para seus destinos. Nos casos de uma aplicação escrita em Elixir, com um banco de dados SQL, temos algumas alternativas de escrever essa transação. Vamos ver duas delas.

Utilizando transações com Ecto
Utilizando uma simples transação do Ecto, basta invocarmos a função Ecto.Repo.transaction/2 e, dentro da função que é passada como parâmetro, programarmos as expressões na ordem em que queremos que elas sejam executadas. O trecho de código abaixo exibe um exemplo. Nele estamos realizando uma inserção e em seguida publicando uma mensagem.

def update_and_publish(%Settlement{} = settlement, %{} = updated_params) do
  Repo.transaction(fn ->
    with {:ok, changed_settlement} <-
           Repo.update(Settlement.update_changeset(settlement, updated_params)),
         {:ok, _} <- SettlementPublisher.publish(:settlement_changed, changed_settlement) do
      {:ok, changed_settlement}
    else
      {:error, reason} = err ->
        Repo.rollback(reason)
        err
    end
  end)
end

O problema com esse código é que ele tende a ser verboso e requer explicitamente que façamos tratamento das operações para garantirmos que elas finalizaram com sucesso e decidirmos pelo commit ou rollback da transação.

Introduzindo o Ecto.Multi
O módulo Ecto.Multi permite que se construa operações em cima de um Ecto.Repo utilizando de composição de funções para indicar a sequência em que elas devem ser executadas. A vantagem dessa estratégia é que não há necessidade de se controlar os resultados das operações e o commit ou rollback da transação explicitamente. O Ecto.Multi garante que todas as funções compostas são executadas dentro de um contexto de transação e que o commit dela só aconteça caso todas finalizem com sucesso. Em caso de qualquer uma falhar, o rollback será executado implicitamente.

Além dessa facilidade, o Ecto.Multi também permite dar nomes a cada uma das operações, de modo que as subsequentes recebam uma redução do estado da operação que está sendo composto a cada execução de uma expressão. Isso se mostra muito útil em casos onde, para executar uma expressão, é necessário utilizar dados que foram gerados em instruções anteriores. Desse modo, o código Elixir tende a apresentar um aspecto muito mais declarativo e de composição de funções.

A maioria das operações que geram mudanças no banco de dados presentes no módulo Ecto.Repo, também são encontradas no Ecto.Multi, como por exemplo insert, update e delete.

Além delas, o módulo também fornece a função run que pode ser executada com qualquer operação arbitrária, não necessariamente gerando mudança no database, mas como por exemplo, realizando uma publicação de uma mensagem de evento. Essa função deve retornar ou uma tupla {:ok, value}, ou uma tupla {:error, value}. No primeiro caso, o Multi vai considerar a operação com sucesso e vai continuar com a transação. No segundo, o Multi considera a transação como falha e vai parar a sua continuidade, executando o rollback para as operações que finalizaram com sucesso anteriormente.

Utilizando o Ecto.Multi
É hora de refatorar o exemplo anterior para agora utilizar o Ecto.Multi. No trecho de código abaixo é possível notar um código usando a tão amada composição com o pipe operator que Elixir oferece.

def update_and_publish(%Settlement{} = settlement, %{} = updated_params) do
  transaction =
    Multi.new()
    |> Multi.update(:update, Settlement.update_changeset(settlement, updated_params))
    |> Multi.run(:publish_message, fn _repo, %{update: changed_settlement} ->
      SettlementPublisher.publish(:settlement_changed, changed_settlement)
    end)
    |> Repo.transaction()

  case transaction do
    {:ok, result} -> {:ok, result.update}
    {:error, _, failed_value, _} -> {:error, failed_value}
  end
end

Observe que na chamada para Multi.run, recebemos na função anônima que estamos enviando como argumento um map em que estamos fazendo pattern match na chave update. Esse mapa contém as mudanças que foram executadas anteriormente, nomeadas de acordo com o atom que passamos como argumento para cada chamada de função dentro de um contexto do Multi. Nesse caso, a chave update contém o resultado da função Multi.update, que chamamos anteriormente.

Para formatar um retorno agradável a quem está chamando a nossa função, em caso de sucesso, procuramos o resultado da chamada de update, conforme nomeamos na composição do Multi. Em caso de falha, o Multi nos retorna uma tupla de 4 valores, contendo o atom :error, o nome da operação que falhou, o valor retornado e as mudanças que haviam terminado com sucesso, mas que sofreram o rollback junto com a transação. No nosso caso, estamos apenas interessados no valor de falha, que pode ou ser relacionado ao update no database, ou à publicação da mensagem.

Conclusões
A lib Ecto se destaca em meio à outras que também lidam com acesso e manipulação de dados através de código. A simplicidade e a elegância que oferece à pessoa desenvolvedora é fora de série. Como vimos nesse artigo, não é diferente com transações, principalmente quando trabalhamos com o Ecto.Multi, que oferece uma forma idiomática e simplificada de lidar com elas.

É importante perceber que com essa estratégia de encapsular na transação tanto a alteração no banco de dados e a publicação da mensagem, apenas garantimos que será tudo ou nada em nosso database local. No caso da publicação da mensagem, ela pode completar com sucesso, mas no momento de fazer o commit da transação, termos uma falha no database.

Quando esse tipo de problema ocorre, se for executada uma retentativa nessa função e desta vez a transação completar com sucesso, teremos a mesma mensagem sendo publicada duas vezes. Por isso, é muito importante considerar em uma arquitetura de microsserviços que as operações sejam idempotentes, ou seja, que se ocorrerem repetidamente, não afetarão o resultado esperado.

Também é importante perceber que estamos fazendo uma transação composta de funções simples e que devem durar poucos milisegundos. Em casos onde há expectativa de operações mais onerosas em termos de tempo de execução, não é recomendável manter uma transação do banco de dados aberta, pois há riscos envolvidos, como timeouts. Nesses casos, o pattern de Transactional Outbox citado anteriormente seria mais adequado.

Por: Daniel Pilon, Engineering Manager

Quer uma nova oportunidade de carreira com desafios globais? Confira nossas vagas em Engenharia e Produto e conheça mais sobre a SumUp: https://go.sumup.com.br/eb-dev-to-vagas

Product design — Estrutura na SumUp

Inside SumUp Brazil — Wed, 13 Oct 2021 21:56:15 +0000

Irei compartilhar neste artigo um pouco da minha experiência nesse um ano de SumUp, principalmente sobre o time de design, desenvolvimento de carreira, cultura, estrutura e rituais atuando como Product Design em uma squad global na SumUp.

Ser Product Designer
Vamos ao início… atuando dentro de uma squad sendo Product Designer você é a responsável, end-to-end daquele produto, seja ele nacional ou global. Além disso, existem inúmeras cross iniciativas às quais você pode fazer parte ou até mesmo liderar. Mas a tua responsabilidade principal está sob aquele produto da tua squad.

Dentro da squad temos total autonomia para trabalharmos com o mínimo de dependências dos demais. Sempre há algo em comum para trabalharmos, pois temos em vista o objetivo comum, que é desenvolver produtos e serviços que auxiliem o pequeno empreendedor e gerar valor para o negócio. A cultura da SumUp defende muito a questão da autonomia (e não é só na teoria, isso é vivido na prática).

Como é a estruturação do time de Product Designers?
Temos o nosso chapter de Product Designer e uma VP Global de Design. Mas, mais precisamente sobre Product Designers, cada tribo tem um designer manager, o qual tem sua equipe composta por pessoas de todos os níveis, incluindo lead e principal.

Além de Products Designers na tribo, temos outros designers que atuam em disciplinas cross company, como Design Ops, Researchers e Design System, mas que nos apoiam para executarmos as nossas demandas ou facilitam processos em comum. (ex, recrutamento e operações de design).

Representatividade e diversidade no chapter
Como mencionei acima, temos uma VP de designer, e é possível ver lideranças femininas em outras posições e times além de design. O mesmo vale para outros grupos geralmente não representados. Atualmente, o time de tecnologia da SumUp possui 32% mulheres, é algo que vem sendo trabalhado para melhor, pois vai além da questão de representatividade.

Desenvolvimento e plano de carreira
Na SumUp existe uma iniciativa que se chama Seeds & Steps que compartilha um pouco da visão do que é esperado de cada pessoa que ocupa uma posição, e da visibilidade do que é esperado nos próximos passos da carreira. Um plano é traçado junto ao manager para construir um plano de ação para cada objetivo.

Além do suporte do manager, podemos contar também com um suporte financeiro de R$10.000,00 anual, e individual, para fazermos cursos, participar de eventos, comprar livros e etc.

Um dos highlights que eu tenho da minha experiência aqui, foi ter tido uma conversa desde a primeira semana com meu manager para entender sobre o meu momento de carreira, o que eu almejava para os próximos passos, e também, dando visibilidade ao Seeds & Steps. Foi neste momento que eu entendi que teria alguém além de mim me auxiliando no meu desenvolvimento profissional, e que o objetivo do meu manager era olhar para a minha carreira e me ajudar a atingir os meus objetivos. Estava de olho também em como eu poderia desempenhar o meu melhor papel para também atingir os objetivos da empresa. O sucesso do designer manager, é o seu sucesso.

Como nos mantemos atualizados em um time de 70+ Product Designers?
Além dos famosos grupos de slack, temos alguns rituais para fomentar a troca entre os designers e também compartilhar o que estamos fazendo. Aqui são alguns dos rituais que nós temos:

Tribe design sync
Quem participa? Apenas os designers da sua tribo.
Como é? Comentamos sobre as iniciativas que estamos atuando, com o principal objetivo dar visibilidade aos demais.

Co-design section
Quem participa? Apenas os designers da sua tribo.
Como é? Apresentamos os projetos, desde aqueles que estão na fase inicial, até mesmo aqueles que estão já em fase de desenvolvimento ou interação para coletar feedback do time. Este formato é bem conhecido como ‘’Design Critic Section’’ no mercado.

Quarterly PD Deep dive
Quem participa? Os designers de todas as tribos participam.
Como é? No formato de apresentação (small talks), de projetos, iniciativas, ou pontos importantes da prática de Design, Research e Produto. No final temos um momento de interação e Q&A.

Coffee design match
Quem participa? Qualquer designer da companhia que tenha se inscrito no canal previamente..
Como é? Conversas informais para conhecer designers que atuam em outras tribos ou times que seria pouco provável a interação devido escopo e tribo distinto. Este também acaba sendo um momento que você conhece mais a pessoa, além do profissional. A conversa no geral fica bem aquém dos participantes.

Hackday
Quem participa? Qualquer pessoa de Engenharia e Produto.
Como é? A cada 15 dias a SumUp disponibiliza uma sexta-feira para você se dedicar a alguma iniciativa desassociada/fora do escopo do seu time. Este tipo de iniciativa fomenta a troca com profissionais de outros times, além de claro, promover uma visão holística da empresa e de iniciativas que podem estar acontecendo além do teu squad e tribo.

Nós também temos rituais globais da empresa como All hands, Town Hall, Lunch & Learning, entre outros, que também proporcionam momentos para compartilhamos conteúdos de design, produto e dores e oportunidades relacionadas às pessoas usuárias.

Além de que no dia a dia não somos limitados apenas aos rituais para interagir e colaborar com outros designers, sempre surgem conversas individuais ou iniciativas em comum além dessas que eu mencionei acima.

E claro, se os rituais mencionados acima não forem o suficiente para atender a necessidade de comunicação e visibilidade, ou se acreditamos que algo poderia ser feito diferente, há abertura para sugerirmos e colaborarmos, afinal, melhorar a experiência nunca é demais.

Mas toda estrutura segue essa organização? É sempre assim?
Não. Esses rituais que estou compartilhando são do meu ponto de vista como uma integrante da tribo de aquisição. No geral, esses rituais são flexíveis de acordo com as necessidade de cada tribo, vamos sempre analisando se faz sentido manter, cancelar, ajustar, alterar ou complementar.

Compartilho aqui um pouco da estrutura, cultura e desafios da SumUp. Espero que essa visão possa ter despertado o interesse em saber mais sobre a nossa empresa e os nossos desafios, e quem sabe, também de fazer parte. ;)

E aí, curtiu entender como funciona o nosso time? Aproveite para conferir nossas vagas abertas e venha ser um SumUpper como eu!

Por: Carol Pestitschek, Product Design Specialist

Para quem não está familiarizado com os títulos de tribo, chapter e squad, recomendo ler este material do Spotify que conta um pouco sobre esse tipo de estruturação: https://blog.crisp.se/2012/11/14/henrikkniberg/scaling-agile-at-spotify

Quer uma nova oportunidade de carreira com desafios globais? Confira nossas vagas em Engenharia e Produto e conheça mais sobre a SumUp: https://go.sumup.com.br/eb-dev-to-vagas

5 dicas de como aprender a automatizar testes!

Inside SumUp Brazil — Thu, 30 Sep 2021 18:31:22 +0000

Muitas pessoas AINDA acreditam que automatizar testes é mágica!

Mas NÃO é!

Assim como qualquer atividade/tarefa, a prática leva a perfeição. Muitas pessoas que conheço me perguntam como eu comecei, já que também fui uma testadora manual, e quando digo que foi uma série de práticas que me fizeram ter o conhecimento que tenho, e que ainda quero ter… (diga-se de passagem, porque eu ainda estudo) algumas pessoas pensam que é simplesmente porque tive a oportunidade de exercitar automação no trabalho, mas acredite: isso é apenas 1 dos motivos que me ajudaram.

Dica 1: busque um curso
É bem clichê, eu sei, mas busque primeiro um curso, dentre as várias linguagens de programação que você tenha certeza que vai poder aprender com maior facilidade, separe um tempo pra codar junto com o instrutor e repetir os seus passos.

Dica 2: migas(os) que automatizam
Assim como eu, você deve conhecer mais de uma pessoa que automatiza, pois bem, cola nela! Se você puder casar o curso que vai fazer com a linguagem que seus amigos próximos já automatizam, ótimo! Faça a eles perguntas mais assertivas, como: “Fulano, como eu sei qual elemento usar ao inspecionar uma tela?”. Entenda que a pergunta muda e fica mais assertiva, desse jeito o seu amigo consegue te ajudar bem melhor.

Dica 3: vá em meetups
Siiiiim!! Claro que essa dica não ia faltar! Gente, vocês não tem ideia de como os meetups fizeram e ainda fazem diferença na minha vida, além de conhecer novas pessoas e empresas legais, fazer networking e ainda descolar aquela entrevista que tanto se quer, tem a troca de conhecimento. E o legal é que você nem precisa perguntar mais de uma vez pro seu amigo que já te explicou alguma coisa, você pode perguntar pra outra pessoa que vai te explicar de forma diferente e te ajudar a ter mais entendimento do assunto.

Dica 4: faça entrevistas e testes
Mesmo que você não queira sair do seu emprego, é legal saber como está se saindo e quem vai te dar esse feedback são os recrutadores. Eles que irão te ajudar sobre o seu teste e o que você poderia ter feito pra torná-lo melhor, como: incluir melhores práticas no código, porque fazer algo de modo diferente e qual o ganho fazendo as alterações propostas.

Dica 5: leia livros
Ler livros pode consolidar o conhecimento que você tem sobre determinado assunto, mesmo que não entenda o que está lendo, seguindo as dicas acima e ler livros, é mais uma maneira de aumentar o seu conhecimento por meio do pensamento de outras pessoas. Se possível, é bacana comprar um e-book, como o Kindle por exemplo, que pagando R$19,90 por mês você consegue ler vários livros técnicos que, nem se quer foram publicados em papel, e ainda, ajuda o autor.

Dica bônus:
“Mas Nath, como você conseguiu incluir a automação no seu dia-a-dia do trabalho?”

Por mais que o seu trabalho esteja puxado, entenda que o seu chefe quer a versão entregue, independente se levar 3 dias pra fazer todos os testes regressivos manualmente para aprovar a versão. O que você tem que fazer é advertí-lo de que quanto menos tempo tiver pra se aperfeiçoar e automatizar, mais tempo vai demorar pra entregar algo que poderia ser testado rapidamente. Você pode, por exemplo, dividir o seu tempo, deixando uma ou duas horas pra estudar e fazer automação. Faça isso e mostre pro seu chefe, se ele não gostar… TROQUE DE EMPRESA! Eles definitivamente não merecem o potencial que vai alcançar com os seus estudos. Entenda que existem empresas se estapeando pra ter um QA que saiba automatizar, e esse QA pode ser você!

Por: Nathalia Freire, QA Engineer

Quer uma nova oportunidade de carreira com desafios globais? Confira nossas vagas em Engenharia e Produto e conheça mais sobre a SumUp: https://go.sumup.com.br/eb-devto-lp-engenharia

Do marketing ao front-end: como a SumUp me apoiou na carreira de desenvolvedora

Inside SumUp Brazil — Mon, 27 Sep 2021 17:57:42 +0000

Cecília Sousa, Frontend Engineer na SumUp

Era 2 de março de 2020 quando pisei pela primeira vez em uma empresa sob o cargo de Frontend Engineer. ''Elegante'', você talvez esteja dizendo. Mas eu confesso que só conseguia pensar nas borboletas no meu estômago, pois minha formação acadêmica nada tem a ver com engenharia ou TI. Estudei jornalismo e trabalhei por quase dez anos na área de marketing e comunicação. Isso quer dizer que minhas semanas iniciais na SumUp com certeza podem ser definidas como um misto de empolgação e frio na barriga.

Dando alguns passos para trás, a verdade é que aquele não era bem o meu primeiro dia de trabalho na fintech: na época em que decidi “largar tudo” para estudar desenvolvimento front-end, eu já trabalhava lá — mais especificamente, com relações públicas e conteúdo. Eu vinha me interessando pelo setor de tecnologia quando, em 2019, ouvi falar sobre uma ONG chamada Reprograma que faz um trabalho maravilhoso para apoiar mulheres cis e trans em seus primeiros passos na programação. Participei do processo seletivo para uma das turmas daquele ano e, poucas semanas depois, lá estava eu entre as 30 selecionadas (abençoadas!) para o bootcamp gratuito e em período integral. Foi quando deixei o marketing e a SumUp.

Depois de cinco meses de estudo, dezenas de projetos pessoais, centenas de commits e milhares de bugs, lá estava eu formada e ansiosa para finalmente trabalhar como programadora. Mas quem foi que disse que seria fácil encontrar uma empresa interessada em contratar uma desenvolvedora front-end com um total de zero horas de experiência profissional na área?

Coincidência ou não, a SumUp estava justamente interessada em recrutar e contratar mais profissionais em início de carreira para a sua equipe de Engenharia e Produto. Foi assim que eu vim parar aqui, agora pela segunda vez. “E como as coisas estão por aí?”, você deve estar se perguntando…

Na SumUp, não falta espaço para aprender e crescer
Assim que conheci o meu time, logo de cara fui surpreendida com um desafio. O Product Manager do squad tinha separado uma tarefa de front-end especialmente para mim. Ninguém ali no squad duvidou das minhas habilidades, pelo contrário; todo mundo já contava comigo colocando a mão na massa desde o meu primeiro dia.

Para alguém com pouca ou nenhuma experiência, isso pode até assustar um pouco, mas a verdade é que não existe satisfação melhor do que ser bem recebida em uma empresa que te trata como alguém que é plenamente capaz de entregar valor para os usuários assim como qualquer outro profissional com mais tempo de casa ou de carreira.

Obviamente, não me faltou ajuda para colocar essa e outras tarefas no ar: participei de ótimas sessões de pair programming com cada um no time de desenvolvedores. Me explicaram como o projeto funciona, quais os patterns de desenvolvimento e o processo de deploy. Isso sem contar as grandes aulas sobre bibliotecas e frameworks que eu nunca sequer tinha ouvido falar. Eu, que conhecia um pouquinho sobre HTML e JavaScript quando cheguei, me deparei com um mundo de possibilidades (e desafios) quando vi que o nosso projeto usava React, GraphQL, Apollo, Testing Library, Jest, Cypress, Styled Components, Node.js e TypeScript.

Aqui na SumUp, tive a sorte e o privilégio de participar de incontáveis sessões de mentoria técnica e de programação em dupla para ir descobrindo como usar cada tecnologia a meu favor à medida que uma nova tarefa surgia. Com tanta gente disposta a me ajudar, tanto dentro quanto fora do meu squad, em poucos meses me senti confiante para não só entregar o que estava no nosso roadmap de produto, mas também para propor melhorias e novas features.

Não bastasse todo esse cuidado com o meu aprendizado técnico, ainda recebi um acompanhamento de carreira quinzenal para encontrar oportunidades de me desafiar e me destacar, com foco em crescer e dar o próximo passo na minha carreira de Frontend Engineer. Spoiler: deu certo! (Fui promovida alguns meses depois de completar um ano como desenvolvedora na SumUp.)

Na SumUp, diversidade é assunto sério
Você já deve ter ouvido falar que mulheres são minorias na área de tecnologia, mas preciso avisar que os dados oficiais não são bons. De acordo com uma pesquisa da ONU Mulheres publicada há três anos, somente 17% das pessoas programadoras no Brasil eram do sexo feminino em 2018.

Esse provavelmente deve ser o calcanhar de aquiles de toda empresa de tecnologia e, quando decidi mudar de carreira, muita gente me alertou para o problema dizendo que eu deveria me preparar para situações em que não seria ouvida e para me acostumar a trabalhar em equipes majoritariamente formadas por homens.

Por outro lado, não por acaso, a SumUp é conhecida por se preocupar genuinamente com diversidade e inclusão. No escritório do Brasil, segundo uma pesquisa feita em 2020, o time é composto por 60% mulheres e 31% LGBTQIAP+, por exemplo. Embora os números não sejam os mesmos para o time de Engenharia e Produto, eu tenho à minha volta diversas mulheres desenvolvedoras que, além de mandarem muito bem no que fazem, são ouvidas e respeitadas por todo mundo. (Esse é o mínimo, é verdade, mas anda bem difícil de se encontrar esse ambiente saudável por aí, infelizmente…)

Falando por mim, aqui eu nunca senti que minha opinião tinha menos importância por eu ser mulher ou que alguém não estava interessado em ouvir o que eu tinha a dizer. Pelo contrário, me sinto num espaço seguro para falar o que penso e para perguntar o que eu quiser, sem qualquer sentimento de inferioridade.

Na SumUp, front-end conversa com todas as áreas
Um dos grandes receios que eu tinha ao trabalhar com front-end é que eu acabaria somente recebendo “demandas” que já viriam na forma de solução pronta, fechada e inegociável. Eu certamente me sentiria sem liberdade para ser criativa e sem espaço para participar da concepção de um produto.

Eis que, aqui na SumUp, eu tenho o prazer de fazer parte de um squad multidisciplinar, onde os responsáveis por produto e design fazem questão de ouvir o que os desenvolvedores front-end e back-end tem a dizer. Juntos, nós propomos novas ideias e planejamos os próximos releases. Também participamos de entrevistas com os usuários finais para entender o que gostariam de ver no ar e ouvimos os stakeholders internos para criar soluções que facilitem seu dia a dia.

Nunca falta espaço para sair da “zona de conforto”, estar perto das demais áreas e conhecer um pouco mais sobre como o nosso produto funciona, de ponta a ponta.

Quer uma nova oportunidade de carreira com desafios globais? Confira nossas vagas em Engenharia e Produto e conheça mais sobre a SumUp: https://sumup.com.br/carreiras/engenharia?utm_source=dev_to&utm_medium=article

Venha ser uma pessoa Data Engineer na SumUp!

Inside SumUp Brazil — Tue, 06 Jul 2021 14:25:31 +0000

• VAGA DESTAQUE DO DIA •

Estamos buscando uma pessoa Data Engineering Specialist para a tribo de Lending!

O que a gente precisa:

➡️Experiência mínima de 3 anos como Data Engineer;
➡️Experiência com solução de messageria Kafka;
➡️Sólida experiência em conceitos de gestão de dados;
➡️Experiência com sistemas escaléveis;
➡️Fera no inglês;

Já trabalhou ou conhece alguém que traz esse conhecimento? Inscreva-se neste link https://bit.ly/2UanSGZ ou compartilhe essa oportunidade na sua rede.

Venha ser uma pessoa Product Manager na SumUp!

Inside SumUp Brazil — Thu, 01 Jul 2021 17:09:22 +0000

• VAGA DESTAQUE DO DIA •

Estamos buscando Product Managers para as tribos de Acquisition e Consumer Mission! 🕵️‍♀️

O que a gente precisa:

➡️Experiência mínima de 2 anos como Product Manager;
➡️Experiência atuando em times multifuncionais em ambientes ágeis;
➡️Domínio no inglês;

Já trabalhou ou conhece alguém que tem esse conhecimento? Inscreva-se nesse link https://bit.ly/2UgOSEK ou compartilhe essa oportunidade na sua rede.