RxJs — Uma nova maneira de tratar assincronia

RxJs — Uma nova maneira de tratar assincronia

async é algo que já é parte do cotidiano de um programador JS, como ele é uma linguagem assíncrona muitos já se acostumaram com essa maneira de programar, o nosso querido EcmaScript já oferece alguns recursos para tratar isso como, Promises, Generators e o Async/Await. Porém hoje quero falar de uma nova maneira, o Reactive X, especificamente a implementação para JS.

Primeiro é importante falar sobre a Programação Reativa, que é uma maneira declarativa de tratar Data Streams. Mas o que isso quer dizer ? Vamos abstrair um pouco mais esse conceito, pense em um canal do YouTube, esse canal publica videos e existem inscritos que querem obter esse conteúdo então ao se inscrever em um canal o inscrito irá receber esse conteúdo até que uma das 2 coisas aconteçam, o canal pare de publicar videos ou o inscrito remover essa inscrição. Resumindo o canal do YouTube é um Data Stream nesse exemplo, e a programação reativa basicamente é uma maneira de lidar com todo esse fluxo de inscritos e emissão de conteúdo.

Falando um pouco mais agora sobre como o Reactive X nos auxilia a implementar a programação reativa, ele combina dois patterns que estão no GoF o Iterator e o Observer com alguns conceitos de programação funcional. Ele usa o Observer Pattern para obter dados ou eventos e além disso oferece vários operadores que permitem que você componha os streams de uma maneira declarativa.

Observable é o mais usado dos recursos do RxJs, ele representa uma coleção de dados ou eventos futuros, para tratarmos os dados emitidos por ele temos o Observer, onde definimos o que iremos fazer quando vier o próximo dado, quando der algum erro e quando acabar o stream. Além disso temos a Subscription que representa a execução do Observable e é utilizada para cancelar o mesmo, já que ele é como uma função e só será executado quando tiver um subscribe e não ao definir apenas o código.

O Reactive X oferece mais um recurso que é o Subject, ele é a junção de um Observable com um Observer. Ele emite o mesmo conteúdo para todos os inscritos, com ele você consegue controlar quando emitir o próximo conteúdo e assim que for emitido todos os seus subscribers irão recebe-lo. Possui vários tipos como o ReplaySubjectBehaviorSubject e o AsyncSubject.

You can build your app as one big observable… but please don’t

Essa frase foi dita pelo Ben Lesh, que é o principal mantenedor no RxJs e engenheiro no Google, e basicamente quer dizer que temos que sempre tomar cuidado para não usar esses recursos de uma maneira exagerada, temos que sempre lembrar que outros pessoas irão ler o nosso código, e elas tem que entender ele para poder dar suporte, porque ao trabalhar com eventos pode ficar um pouco confuso principalmente no começo, ler o código e entender como o stream está definido.

Então a minha dica final é comece a usar ele, porque só conseguimos entender realmente esses conceitos usando eles, combinando diferentes eventos, tratando diferentes cenários. É muito legal ver a evolução do seu código com o tempo, conforme você vai aprendendo a utilizar melhor os operadores o seu código vai melhorando, então treine, tente re-fatorar os seus códigos depois de um tempo e tente ensinar para outras pessoas também porque assim você aprende mais ainda!

Basicamente é isso que tenho pra hoje, até a próxima !

Boas práticas para mensagens de erro

Boas práticas para mensagens de erro

Quando o assunto é desenvolvimento de aplicações digitais, muitas vezes pensamos de maneira negativa no tratamento de erros, uma vez que, projetamos nossos sistemas para evitar os erros, certo? Pois bem, pensar em como tratar os erros e exibi-los de maneira amigável para nossos usuários é tão crucial quanto evitá-los. E acredite, por mais clichê que pareça, isso faz toda a diferença.

Para iniciarmos o assunto, proponho trocarmos o termo “mensagem de erro” para “mensagem de exceção”. Quando falamos em mensagens de erro, a aplicação foi projetada para ser usada de uma única maneira e o usuário desvia desse caminho feliz. No entanto, se pensarmos na abordagem do design resiliente, projetamos a aplicação dando a flexibilidade para que o usuário resolva problemas e explore as informações como desejar, e frente a situações inesperadas, orientá-lo para que sozinho resolva os problemas encontrados.

Partindo disso, darei algumas dicas de como pensar na experiência do usuário na hora de tratar os erros, escrevendo boas mensagens de exceção.

Exibição

O primeiro passo é pensar na maneira como exibi-la. A mensagem de exceção deve ser, sobretudo, diferente do conteúdo principal da página. Existem dois tipos principais de mensagens: a de página inteira e a em linha.

A mensagem de exceção em linha permite que o usuário interaja com o conteúdo principal da página e possa corrigir a condição de erro. É recomendável utilizá-la sempre que a exceção possa ser recuperada facilmente pelo usuário, como no caso do login inválido no Mailchimp.

Exemplo de mensagem em linha

Perceba que a mensagem ganha um destaque especial ao mesmo tempo em que os campos do formulário ficam disponíveis na tela, basta o usuário corrigir o username para prosseguir.

A mensagem de exceção de página inteira pode ser utilizada quando a condição de erro não é recuperável ou requer que o usuário execute alguma ação específica. Nesse caso, a mensagem deve ocupar mais ou menos a página inteira e os outros itens da tela devem ser escondidos para induzir o usuário a resolver a situação.

Exemplo de mensagem de tela inteira

No exemplo do Uber, quando o gps está desativado é necessário antes de mais nada, que o usuário o habilite, pois a ação principal da tela, que é pedir o carro, depende diretamente dessa ação.

Evite o uso de popups

Uma boa prática é evitar o uso de popups, pois as chances de o usuário ignorá-las sem ler o conteúdo são grandes. Além de que várias popups pulando a todo momento podem causar frustração.

Outro problema é que popups podem interromper o usuário no meio de uma determinada interação. Um exemplo, é o acesso a permissão da localização em aplicativos. Se ao acessar a tela o usuário não oferecer a permissão de acesso a localização, ao invés de exibir uma popup solicitando o acesso, podemos exibir uma mensagem no canto da tela solicitando a localização.

Popup de permissão de acesso a localização
Mensagem exibida quando a permissão de localização não foi concedida

Dessa maneira, informamos ao usuário de maneira clara que é necessário habilitar a localização e para qual finalidade ela é requerida, sem fazer o uso de popup.

Conteúdo

A comunicação com o usuário deve ser clara e objetiva, por isso, precisamos pensar com carinho no conteúdo que vamos exibir. Uma boa mensagem de exceção deve responder as seguintes perguntas:

O que aconteceu?

O que isso significa?

O que o usuário pode fazer sobre isso?

O que aconteceu?

A primeira pergunta é sem dúvida a mais difícil de ser respondida. Precisamos entender muito bem o que aconteceu e traduzir para a linguagem do usuário. Como explicar para alguém leigo em tecnologia a frase “Erro interno no servidor”? Não devemos utilizar termos técnicos e assumir que o usuário é o culpado pelo erro ocorrido.

Evitar iniciar as mensagens com palavras negativas é uma ótima maneira de ser um pouco menos agressivo e mais gentil com o usuário que está ali frente ao erro. Nesses casos, a dica de ouro é abusar da palavra do momento, a empatia.

O que isso significa?

Além de deixar claro para o usuário o que está acontecendo é importante explicar as consequências do problema. Digamos que a confiança do usuário nesse momento pode estar um pouco abalada, visto que acabou de receber um erro, por isso, é importante ser claro sobre a o que ocorreu. A frase “Podemos ter perdido seus dados devido a instabilidade na internet” é muito mais significativa do que simplesmente “Ocorreu um erro desconhecido”.

O que devo fazer?

Por fim, e não menos importante, é necessário direcionar o usuário sobre o que ele deve fazer frente ao erro, incluindo ações que possa executar para contornar a situação. Vamos evitar que nossos usuários fiquem com a sensação de “E agora, José?”. Ainda no exemplo do Uber, a ação “Ativar serviços de localização” ilustra bem como direcionar o usuário sobre o que fazer.

“Boas mensagens de erro dizem aos usuários o que deu errado — e possivelmente o porquê — fornecem uma ou mais soluções para corrigir o erro e oferecem um conjunto de botões que se relacionam diretamente à próxima ação que um usuário deve tomar.” — Rhonda Bracey

Símbolos e cores

Além das palavras, podemos reforçar as mensagens através de símbolos e cores, associando um estilo visual para cada tipo de mensagem. Vale ressaltar que é importante tomar cuidado com as cores, afinal, podemos ter usuários com deficiência de visão.

Exemplo de símbolos e cores para cada situação

O usuário lerá os símbolos como palavras, por isso, é importante usar símbolos e cores adequados para cada situação. A dica da vez é documentar esses estilos em um guia de estilos para que todos possam compartilhar e manter o padrão e consistência na aplicação.


Conclusão

A melhor mensagem de erro é aquela que não aparece. Mas, isso não elimina o fato de que podemos e devemos pensar no usuário até mesmo quando o assunto é tratamento de erros. Sempre que algo inesperado acontece, os usuários no geral, tendem a ficar inseguros sobre o que fazer e eles precisam de clareza e ajuda na aplicação, por isso precisamos ser legais e gentis com nossas palavras.

Pensar com um pouco mais de empatia, assumir que nosso usuário pode não ter conhecimento técnico e que ele não é responsável pelos erros, são os primeiros passos para tornarmos as mensagens de exceção mais humanas.

Até a próxima 🙂

Ana Gabriel

Ana Gabriel


Product Owner na Tegra
- Soluções Digitais, organizadora do Rails Girls Sorocaba, apaixonada em resolver problemas através da tecnologia, aprender e ensinar.

Quero ser ágil

Quero ser ágil

Como ser ágil quando sua empresa precisa de aprovações de um comitê para realizar um deploy em produção e isso só acontece uma vez por mês?

Antes vamos entender um pouco o que é ser ágil

No modelo de desenvolvimento de software tradicional tínhamos muitos problemas, principalmente no que diz respeito a ecoo do projeto, pois era necessário logo no primeiro momento fechar ˜todo˜ escopo o que implicaria no cliente tomar uma série de decisões como o que ele quer e o que ele não quer antes mesmo de ter tido qualquer experiência com aquilo que ia ser desenvolvido. 

Depois do cliente conseguir idealizar o que ele gostaria e o que ele não gostaria, etapas subsequentes vinham com outros profissionais envolvidos e uma nova etapa só começava quando a anterior terminava e todas essas etapas levavam muito tempo.

E por isso depois de muito tempo desenvolvendo o software quando o cliente recebia, em muitos casos ouvíamos que não era isso que queria ou que ele precisava. E pior ainda acontecia quando o cliente precisava por algum motivo parar o projeto no meio do caminho ele não teria nada pra receber, não teria nenhum valor   “agregado” para o seu negócio mesmo depois de ter desembolsada um valor para investimento.

Para suprir essas deficiências é que o modelo de desenvolvimento ágil foi tomando espaço onde conseguimos desenvolver aplicações que possuem um certo entendimento da necessidade do cliente mas não um entendimento total, a construção é feita em conjunto e em ciclos “pequeno”, onde o cliente a cada ciclo recebe uma funcionalidade do software ou parte dela que possa agregar valor ao seu negócio. Essa execução permite que a equipe de desenvolvimento tenha feedbacks mais rápidos do cliente sobre o que está sendo desenvolvido permitindo que a respostas a mudanças sejam realizadas sem muitos impactos ou até mesmo sem impactos.

Existem vários métodos de desenvolvimento ágil ,um deles é o Scrum. Que é considerado um conjunto de ideias de trabalho onde o conceito de time é muito mais importante que o o indivíduo em si. Os quais  podem tratar e resolver problemas complexos de forma produtiva e entregar produtos com o mais alto valor agregado. Por isso, as características principais do time ágil são: equipe pequena, multidisciplinar e autogerenciáveis. Simples de entender, mas difícil de dominar!

No Scrum, os ciclos pequenos são chamados de sprints. As sprints podem ser de uma semana a até quatro semanas. As atividades que são definidas dentro uma sprint levam em conta quais atividades tem mais importância para ao meu cliente se desenvolvida em determinado momento. Isso gera entregas contínuas e que agregam cada vez mais valor ao cliente.

É muito importante que o time além de fazer, pratique os valores que estão envolvido no desenvolvimento ágil::

  • CORAGEM para fazer as coisas certas e trabalhar em problemas difíceis
  • FOCO para se concentrar no trabalho da sprint e nos objetivos da equipe
  • SE COMPROMETER pessoalmente em alcançar as metas da equipe
  • RESPEITAR os membros da equipe para serem pessoas independentes e capazes
  • O TIME deve concordar em estar com a mente aberta aos desafios com a realização do trabalho a fim dos STAKHOLDERS confiar mais e mais no trabalho dos desenvolvedores

Depois de entender um pouco do Scrum, vamos entender o que é DevOps.

DevOps – junção das palavras “desenvolvimento” de software e “operação” de software. Como entregar um software funcionando que pode ser gerenciado, escalável, mantido e cuidado facilmente. Isso é algo que o mundo da entrega de software precisa desesperadamente.

O ato de executar, manter e operar um software não era algo que fazia parte da realidade de um desenvolvedor e a forma como desenvolvemos e operamos um software hoje mudou drasticamente desde os dias em que o modelo de desenvolvimento ágil foi criado. A entrega contínua necessita de uma implantação automatizada de entregas, principalmente no que diz respeito ao ambiente produção.

Porém em muitos casos os times ágeis voltaram-se para a área que se sentiam mais confortáveis como a criação, desenvolvimento e testes de softwares, deixando de lado a entrega, implantação efetivamente dita. O problema dessa abordagem é que, ao separar o trabalho de construção e de implantação, junto com as atividades de gerenciamento de infraestrutura, estamos basicamente fazendo com que “o problema seja de outra pessoa” no ponto de vista da equipe ágil, e mais uma vez, a “Operabilidade” desaparece.

Podemos atribuir  que uma grande parte da culpa desse descasamento entre as equipes é da própria Empresa, pois de um lado ela cobra quanto a estabilidade e gerenciamento das aplicações, e do outro lado ela cobra mais entregas com valor agregado. No entanto, a empresa não dá o suporte necessário nem para a infra, garantindo os equipamentos e máquinas necessários para a “operabilidade”, nem para o time de desenvolvimento ágil como por exemplo: disponibilizando todos os ambiente necessários  para que o time realize os todos os testes para garantir a qualidade da entrega.

Por isso, podemos entender que o DevOps é a colaboração entre o desenvolvimento e a equipe de operações é olhar a infra-estrutura como parte do desenvolvimento de software. É um movimento cultural e profissional, focado em aumentar a comunicação, a colaboração e a harmonia entre o time de desenvolvimento ágil e os times de operações de TI para fornecer entregas contínuas aos clientes, com menor custo e menor percentual de bugs, derrubando-se assim as barreiras existentes entre os times.

Entendemos então que os valores da cultura DevOps são:

  • ELIMINAR a competição entre equipes de infraestrutura e desenvolvedores
  • MELHORAR o planejamento do ambiente produtivo, resultando em projetos entregues dentro do prazo e sem estourar o orçamento estimado;
  • EFICÁCIA no monitoramento das aplicações desenvolvidas devido a integração e colaboração entre as equipes;
  • Maior ESTABILIDADE e DESEMPENHO das soluções entregues;

COMO INTEGRAR SCRUM e DEVOPS

Já pensou em que acontece com todas as informações utilizadas ao final de cada Sprint?

Sim, todas as informações geradas nos ˜post-its internos, rascunhos e outros canais manuais são descartadas e nem se sequer chegam ao conhecimento da outra equipe de TI, por exemplo a equipe de infra que lidaria com o projeto na fase de implantação.

Com a integração entre a equipe de desenvolvimento e a equipe de operações toda documentação é compartilhada e a rastreabilidade fica acessível a todo o time de TI.

Dessa forma facilitaria até na organização do Product Backlog, tornando-o mais eficiente no processo de hierarquização de ações no projeto.

Os negócios dos nossos clientes mudam o tempo todo e muito rapidamente e a área de TI deve responder a essas mudanças. Para lidar com esse cenário, é preciso muitas vezes que TI mude todo o fluxo operacional, algo que pode ser feito com DevOps e Scrum com excelência!

Com isso, acredito que podemos responder a pergunta feita no início  “Como ser ágil quando sua empresa precisa de aprovações de um comitê para realizar um deploy em produção e isso só acontece uma vez por mês?”

Através do trabalho em conjunto do Scrum e Devops a fim de prover a verdadeira transformação das empresas!

Para refletirmos!

Será que não se faz necessário ter um DevOps no time Scrum já que ele é multidisciplinar? Isso não reduziria ainda mais a distância e quebraria as barreiras das áreas? 

Liderar é influenciar pessoas, não ser chefe

Liderar é influenciar pessoas, não ser chefe

Uma das primeiras coisas que aprendi é que não precisamos de um cargo de liderança para liderar e transformar equipes e ambientes. Quando herdamos lógicas das organizações hierárquicas e aprendemos a nos livrar da culpa de estar liderando algo que ninguém nos deu um título para liderar é uma enorme coisa.

Hoje o que me faz imensamente feliz e agradecida é não trabalhar em uma empresa hierárquica e limitadora de iniciativas, muito pelo contrário, aqui se temos uma ideia, podemos fazer, colocar em prática.

Temos espaço e abertura para movimentos inovadores, existe como se fosse uma crença de que estamos sempre fazendo o nosso melhor, jamais ouvimos por aqui “vocês podem fazer melhor”, estamos sempre fazendo o nosso melhor, agregando sempre novos conhecimentos e crescendo juntos, pois, se algo dá errado aprendemos e evoluímos com os erros, tornando a falha em aprendizado. Sempre as coisas acontecem em conjunto, acredite aqui sempre encontramos aliados.

Quando se trata de fazer as coisas acontecerem eu me vejo como uma pessoa animada, e sempre que identifico algo que possa melhorar, sempre tomo a iniciativa, os erros acontecem, porém, todos trazem aprendizados enormes, e esse aprendizado me ensinou que para ser líder, não precisamos ser chefe de ninguém:

Ser líder, jamais chefe: Quando temos uma visão e levamos essa visão para mais pessoas faremos acontecer, podemos liderar ideias, ter iniciativas e empenhar pessoas para isso acontecerpodemos entender que liderar é fazer com que coisas aconteçam por intermédio de outras pessoas inclusive com outras pessoas. Você sendo uma pessoa que toma decisão e tem responsabilidades você está liderando.

Mandar, não é liderar: Liderar não é controlar, mandar, gerenciar. Todos temos responsabilidades, porém, como líder nosso trabalho é compreender onde cada pessoa encontra-se e como percorrer com ela até onde queremos chegar.

Abraçar todos os problemas, não ajuda a resolvê-los: Dividir com o time problemas sem procurar resolver tudo sozinho auxilia a abrir espaços de lideranças e principalmente o compartilhamento de responsabilidades essencialmente em times auto-gerenciáveis. Se você está o tempo todo ocupado, ou aparenta isso você acaba se distanciando das pessoas, pois, por muitas das vezes elas não querem te atrapalhar e isso acaba atrapalhando a comunicação.

Não confunda pessoas com recursos: Aprendi que ninguém precisa fazer as coisas como eu faria, nem ao menos no tempo que eu faria. Humildade e respeito possibilitam que você se abra para as pessoas e as ideias que elas têm.

Dar sempre o seu melhor: Quando damos o nosso melhor inspiramos e engajamos pessoas.

Pessoas, nada mais que pessoas: Sem elas, nada acontece.

Liderança é uma caminhada e jamais um cargo!

Toda minha caminhada aqui tem sido bastante preciosa, provocadora e prazerosa para mim. Hoje só tenho a agradecer as pessoas que estão comigo nessa jornada, tenho bastante a aprender todos os dias.

Até a próxima.

 

Importância de ouvir o cliente

Importância de ouvir o cliente

João, o construtor

Hoje vivenciei um episódio que ao certo irá me marcar por um bom tempo. Compartilho com você.

Trabalho com desenvolvimento de soluções de software e atendemos a várias empresas de diferentes necessidades. Uma característica é comum a todos: eles buscam solução. Mais do que isto, buscam solução com simplicidade.

O desenvolvimento de software tem em sua origem muitos jargões, siglas, termos, etc. que para quem é “do meio” é sinal de orgulho, inconsciente talvez. Quanto mais letras na sopa de letrinhas do profissional deste setor, a imagem que é vendida é que é de maior capacidade.

O cliente não técnico, mesmo não demonstrando, sente-se intimidado por tantos complicômetros em forma de siglas. Muitas vezes, para não sair por baixo, durante uma conversa sobre projetos, o cliente arrisca alguns termos técnicos, que em geral viram “memes” na rádio peão.

Acontece que se não temos o cuidado de conduzirmos o diálogo para uma zona de entendimento comum entre cliente e time técnico, muitas vezes, criamos um abismo de compreensão que gera fortes quedas ao longo do tempo.

Ou seja, complicamos a compreensão do cliente pelo uso do “tequiniquês” ao invés de inspirar sua confiança usando o “descompliquês”.

Para tornar mais claro

Imagine que você encontrou o sítio dos seus sonhos e o compra. Contrata um engenheiro e conta para ele tudo o que gostaria de contemplar em sua construção: que quer ter espaço grande para pomar, uma varanda ampla e com pé direito alto para convidar amigos para fazer uma comida uma vez por semana. Menciona também que quer manter o pé de abacateiro, centenário, como agradecimento a Natureza por sua beleza e perfeição e não abre mão de ter uma vista da rua que passa a frente da propriedade. Ele projeta.

Com projeto em mãos, você contrata o João que é construtor civil e seu time para materializá-lo. Em conversa com João, ele parece ser uma pessoa honesta e que será capaz de realizar o projeto como o esperado.

Em tempo de negociação, a expectativa é que a entrega ocorra em 5 meses, sendo o pagamento parcelado em 5 parcelas de 20% do valor total cada.

Você explica ao João que você mora longe que poderá visitar a obra somente a cada 30 dias e que qualquer dúvida, para ele entrar em contato. João aceita o combinado.

Passado 30 dias, nenhuma ligação de dúvida do João, ao chegar no local com a expectativa de ver as primeiras paredes já em pé, você encontra o buraco que será o poço artesiano e o espaço para o portão da frente. Surpreso, você realiza o pagamento da parcela 1/5, porém com um ar desconfiado.

60 dias depois, nova visita a obra com expectativa de haver laje e início de telhado, no entanto, o que se vê é a marcação de terreno e fundação. Você questiona se o que foi feito não é muito pouco. João explica em termos técnicos que você não conhece o processo de construção, mas que você pode ficar tranquilo que vai notar diferença na próxima visita. Novo pagamento, parcela 2/5. Sentimento mais profundo de desconfiança.

Nova visita, agora com 90 dias e a expectativa de já haver paredes, janelas, laje, telhado, hidráulica e contra piso, porém desta vez, somente as paredes de pé, mas segundo o João, com a estrutura mais forte que alguém já viu, que aguenta até 10 andares, sendo que você nunca sequer mencionou ter um segundo andar sequer, e nem no projeto consta. Parcela 3/5 paga e sentimento de desconfiança passa a ser de implicância.

Entre os dias 91 e 120, o sonho do projeto passa a tomar ar de preocupação e um “quezinho” de raiva do João, pois toda vez que você o questiona, ele justifica que sua expectativa como cliente é que está muito alta. Sua obra nas mãos do João tem que ter reforço nas “sapatas”, estrutura forte nas “viga” e para ficar bonito, um telhado de pelo menos “8 águas”.

Final do mês 5: a casa mais robusta que você possa imaginar foi entregue, que aguenta 10 andares e que ainda por cima tem poço artesiano (que eu nem tinha pedido).

O que você não contava é que o pé de abacate que você pediu para manter, precisou ser cortado para não afetar a estrutura da casa, segundo o João.

A visão que você que queria ter da rua, ficou tampada pelo portão que mais parede uma entrada de castelo, praticamente uma muralha. “Cortesia” do João para agradar o patraozin.

O espaço que você pediu para a horta foi mantido, mas há mais de 100 metros de distância da casa para não sujar a água do poço artesiano que você não pediu para construir e a varanda de pé direto alto não ficou tão alto quanto você esperava devido ao telhado de “8 águas” que o João fez para você.

Prioridades

João entregou o que foi contratado: um projeto de casa, e entregou mais do que foi contratado: um poço artesiano e uma muralha de portão. Mas era esta a sua prioridade? Com qual sentimento você ficou? Você indicaria o João para outro amigo seu que te pedisse indicação de construtor? Provavelmente não.

Priorizar um projeto, seja de construção civil, de software, mecânico ou de qualquer outra natureza precisa ter como critério o desejo e o sentimento do cliente.

Saber ouvir o cliente, se colocar no lugar dele, considerar o que ele deseja sentir e vivenciar ao receber o projeto que ele está comprando é fator determinante para conduzir um projeto de forma a atender e até mesmo superar as expectativas do cliente.

E esta visão de se colocar no lugar do cliente deve ser comum a todos os envolvidos no time, do gestor ao auxiliar, do analista ao programador, do projetista ao operador de máquina. Se esta visão se perde ao longo do caminho, o resultado será aquém ao desejo do cliente.

Encantamento

Imagine que o João havia entendido o que você realmente queria e ao invés de ter feito um espaço para o pomar há mais de 100 metros de distância da casa, ele tivesse feito o pomar, inclusive com as frutas que você mais gosta e que lembra sua infância já plantadas?

Na varanda com pé direito bem alto, um fogão a lenha e uma churrasqueira rústica com uma bela mesa de alvenaria, que não estava no projeto, mas que conversando com você, seu João percebeu quantas pessoas viriam visitá-lo quando fizesse comida.

Inclusive João surpreendeu e construiu um espaço que após a refeição, todos pudessem descansar ao redor do abacateiro.

Como você se sentiria? Indicaria o João para outro amigo seu?

Conheça-me

É interessante como nós gostamos de falar de nós mesmos. Quando alguém pergunta qual é minha trajetória profissional é muito comum eu começar a falar e não parar mais.

Percebo que este fenômeno não ocorre somente comigo, mas com muitos, senão com a maioria.

Uma pessoa de mais idade quando questionada sobre seus feitos, se tiver o tempo disponível poderá falar por horas a fio. E com muita alegria.

Conhecer o cliente é um ato de escolha. Não se trata de uma técnica, de fingimento, de cumprir tabela, tampouco de um processo.

Trata-se de um desejo genuíno de conhecer o cliente. E para isto o olhar empático é fundamental.

Meu convite: seja você profissional da área que for, tecnologia, construção civil, comércio, metalurgia, etc., queira conhecer seu cliente. Se coloque em seu lugar. Ouça-o com atenção e saberá o que priorizar e como encantá-lo.

Boa empatia a você 😉

Autor: Willian Polis

Autor: Willian Polis


Líder educador na Tegra
- Soluções Digitais, apaixonado por compreender pessoas, gerar soluções através da tecnologia, resolver problemas, aprender coisas novas e dedicar-me totalmente em tudo o que faço. E-mail: polis@tegra.com.br

RanchoDev – De Devs para Devs

RanchoDev – De Devs para Devs

Um dia inteiro de troca de conhecimento, cultura e discussões sobre desenvolvimento.

A Tegra sempre se preocupou em fortalecer a comunidade de Tecnologia, criar mais oportunidades para que as pessoas que vivem em Sorocaba e região pudessem viver a experiência de grandes conferências mas em nossa cidade, com isso tivemos a ideia de organizar o RanchoDev.

O RanchoDev é uma conferência para desenvolvedores de software, esta em sua 3ª edição, já tivemos a oportunidade de trazer diversas palestras e temas diversificados que se relacionam a tecnologia.

Contamos também com apoio e patrocínio de grandes empresas de Sorocaba e região.

O RanchoDev já teve representantes de diversas empresas e comunidades como Henrique Bastos (Fundador do Welcome to the Django), Fabio Akita (Fundador da CodeMiner), Roberto Marin (Gerente de Engenharia no Vivareal), Joaquim Torres (UX na Locaweb), Mauricio Alegretti (Cofundador da Smile, estúdio de games).

Edição 2018

Buscamos através do RanchoDev abordar a maior diversidade de assuntos e os temas que mais atraí a comunidade atualmente.

O evento vai acontecer no dia 29/09 na Faculdade Facens Rod. Senador José Emírio de Moraes,1425 Constantino Matucci, das 8h30 ás 17h30.

PALESTRANTES CONFIRMADOS

Erick Wendel
Node.js, Microservicos e Containerização

Descrição da Palestra: É importante entender como as aplicações funcionam e como a arquitetura está evoluindo. Pensando nisto, abordaremos sobre os benefícios de Docker para criação de microserviços com Node.js.

Mini biografia: Pós graduando em BI with Big Data. Microsoft Most Valuable Professional (MVP). Co-organizador das comunidades NodeBR, Javascript São Paulo, Nerdzão e Nerdgirlz. Consultor Especialista na EW.IT, Microsoft Certified Professional. Possui amplo conhecimento em arquitetura, desenvolvimento e segurança de aplicações. Palestrante nas maiores e mais populares conferências de tecnologia da América latina.

Kete Martins Rufino
Usando GraphQL para reduzir complexidade no front e no back

Descrição da Palestra: Usamos React Native para construir a Nuconta e o GraphQL veio para reduzir a complexidade de manipulação de dados tanto para o front quanto para o backend. A ideia é mostrar quais os prós e contras de usar essa ferramenta num ambiente de micro serviços e mobile hibrido.

Mini biografia: Engenheira de software na Nubank e pouco criativa pra criar bios divertidas.

André Baltieri
Distribuindo Microsserviços de forma inteligente no Microsoft Azure

Descrição da Palestra: Já pensou no trabalho que é distribuir 500, 600 ou até mais de 1000 Microsserviços? E o cache? Banco de Dados? API Gateway? O que é serviço, o que é function? Utilizo Docker? Pois é… Nesta talk vamos falar sobre a distribuição de Microsserviços na nuvem Microsoft de uma forma otimizada!

Mini biografia: Olá eu sou o André Baltieri, desenvolvedor Web desde 2003, já trabalhei aqui no Brasil e nos EUA, em projetos de diversos tamanhos. Faço parte do seleto time de MVPs da Microsoft, desde 2013, um reconhecimento global dado para os maiores influentes em suas tecnologias. Sou palestrante em diversos eventos como ASP.NET Conference, DevXperience, TDC, GDG dentre outros.
Site: andrebaltieri.com

Fernanda Bernardo
Jogos: indo além do simples CSS!

Descrição da Palestra: Há quem pense que o CSS serve somente para aplicar estilos a determinados elementos, e realmente seu principal objetivo é esse! Mas alguém já pensou que seria possível capturar eventos, como um evento de clique por exemplo, e gerar algum tipo de animação com isso? E falar que com isso é possível criar um jogo? Neste talk explicarei como criar um jogo simples, sem uma linha de javascript, usando apenas HTML e CSS. Além de muitas de suas funcionalidades: pseudo-elementos, pseudo-classes, animations, entre outras.

Mini biografia: Desenvolvedora front end, criadora do @help4papers, plataforma para ajudar pessoas a começar a palestrar e a receber feedback de suas palestras, instrutora e mentora, organizadora do TC Talks meetup do @trainingcentr, Microsoft MVP e criadora do @diabetesmaisdoce, aplicativo para facilitar o dia a dia de uma pessoa diabética e blog sobre diabetes.

Filipe Versehgi
Aplicativos nativos com React?

Descrição da Palestra: Um overview sobre o que é o React Native, uma tecnologia que utilizamos na Tegra para criar aplicativos com React. Um código para ambas as plataformas, com ótima performance, fácil manutenção e uma comunidade super ativa.

Mini biografia: Filipe Versehgi é desenvolvedor Frontend na Tegra, onde trabalha no projeto mobile Meu Desconto e Pão de Açúcar Mais. Trabalha com desenvolvimento web há cerca de 6 anos, atuando nas três pontas do desenvolvimento de um projeto: interface, frontend e backend.

Marcelo Rosa
Inteligência Artificial no Mercado Financeiro

Descrição da Palestra: Pioneiras no uso de Analytics, as organizações do setor financeiro, estão explorando os recursos da inteligência artificial para obter insights e criar modelos de negócios melhores e mais lucrativos, além de corresponder às expectativas dos seus clientes, promover transparência, e gerar uma vantagem competitiva sustentável no setor. Acompanhe esta palestra para entender o impacto da inteligência artificial no mercado financeiro.

Mini biografia: Engenheiro de Produção, músico e Consultor de TI na GFT Brasil atuando em tópicos relacionados a Big Data e Advanced Analytics no setor financeiro. Possui experiência com ferramentas de suporte à decisão orientadas a dados como modelos de programação matemática, simulação de sistemas e algoritmos de aprendizado de máquina.

Jose Gustavo Z. Rosa
Ciência dos Dados: Limpar, Organizar, Estudar & Decidir

Descrição da Palestra: A ideia é mostrar de forma simplificada, o workflow de se trabalhar na coleta limpeza e organização dos dados, até o ponto onde análises preliminares são feitas. Também pretendo mostrar código (Python e R) bem como resultados intermediários.

Mini biografia: Gestor de desenvolvimento de software e inovação com pouco mais de 20 anos de experiência em desenvolvimento de software, times ágeis, negócios. Aficcionado pelo processo de “decisão bem informada” fiz especializações e pós graduação em estatística aplicada a ciência dos dados, campo no qual atualmente trabalho estudando a qualidade de combustível no varejo, usando dados coletados em campo.

Carlos Mattos
Desventuras de um Programador no Mundo Corporativo

Descrição da Palestra: Essa palestra é um convite à reflexão sobre a distância entre as expectativas dos jovens iniciando a carreira na área de tecnologia, e as expectativas das empresas de tecnologia. Oportunidades, desafios, comportamento, lições para construir uma carreira de sucesso na área de tecnologia.

Mini biografia: Mattos é pai, professor, escritor e palestrante, apaixonado por tecnologia. Atua na área de desenvolvimento de software para o mercado corporativo desde 1998.
Reconhecido pela Microsoft como MVP por 12 anos consecutivos e como Microsoft Regional Director em 2017 pelas suas contribuições para as comunidades técnicas e acadêmicas.
Mattos é Head of Technology and Innovation na GFT.

Inscreva-se: www.ranchodev.com.br

Edições Anteriores:
folio-02 folio02

folio-05folio05