estagio supervisionado iii -...
TRANSCRIPT
Universidade Federal do ABC
Bacharelado em Ciencia da Computacao
ESTAGIO SUPERVISIONADO III
Rodrigo Martins de Oliveira
Orientador: Prof. Dr. Jesus Pascual Mena-Chalco
Santo Andre – SP
2019
Rodrigo Martins de Oliveira
ENGENHEIRO DE SOFTWARE EM QUINTO ANDAR SERVICOS IMOBILIARIOS LTDA
Relatorio de estagio apresentado a banca do
Bacharelado em Ciencia da Computacao da
Universidade Federal do ABC como requisito
parcial para a obtencao do tıtulo de Bacharel em
Ciencia da Computacao.
Orientador: Prof. Dr. Jesus Pascual Mena-Chalco
Santo Andre – SP
2019
Dedicatoria
Dedico este trabalho a todos os amigos e familiares que alegraram minha vida e sempre me deram
a forca de vontade e animacao para aproveitar ao maximo tudo aquilo em que pus meu tempo e
esforco.
1
Agradecimentos
Agradeco, em primeiro lugar, ao professor Jesus, nao apenas por ter me acompanhado durante
toda a trajetoria academica, me ensinando e orientando nos ambitos academico e profissional,
mas tambem por ter me escutado e discutido comigo tantas ideias e assuntos interessantes; meu
gosto pelos assuntos academicos e cientıficos foram imensamente fomentados por este excelente
profissional e singular pessoa.
A todos do QuintoAndar, deixo imenso agradecimento, nao apenas pela oportunidade, mas por
todo o crescimento pessoal e profissional propiciado, pela confianca depositada e pela liberdade
e autonomia concedidos. O espaco construıdo por todos da empresa foi unico e foi terreno fertil
para o amadurecimento e florescimento de um profissional avido por conhecimento, energico no
que faz, crıtico ao que lhe e apresentado, feliz e realizado.
Em especial, agradeco, de todo meu coracao, a minha mae, meu pai e minha irma, por absolutamente
tudo.
2
Se acreditar em mim mesmo significa ser um tolo,
entao serei um tolo minha vida inteira.
“O trabalho duro e inutil para aqueles que
nao acreditam em si mesmos.”
— Mighty Guy, Naruto Shippuuden
3
Resumo
Relatorio de estagio curricular a cerca das atividades desempenhadas pelo autor, enquanto
Engenheiro de Software na empresa QuintoAndar Servicos Imobiliarios LTDA durante Outubro de
2017, Julho de 2018 e Novembro de 2018. Tais atividades foram exercidas durante o Bacharelado
em Ciencia da Computacao na Universidade Federal do ABC. O relatorio traz o desenvolvimento
e aprendizagem de novos conhecimentos, bem como os detalhes profissionais proporcionados.
Palavras-Chave: QuintoAndar, Agil, Desenvolvimento, Prototipagem, Software, Startup, Imovel.
4
Abstract
This report has as main objective to describe professional tasks performed by the author as
Software Engineer at QuintoAndar by October 2017, July 2018 and November 2018. The tasks
were performed while the author was enrolled in the Bachelor’s Degree in Computer Science
program at Federal University of ABC. The report addresses the development and learning of
new concepts as well as professional details provided.
Palavras-Chave: QuintoAndar, Agile, Development, Prototyping, Software, Startup, Real Estate.
5
Contents
1 Introducao 10
1.1 Empresa concedente: Quinto Andar Servicos Imobiliarios LTDA . . . . . . . . . . . 10
1.2 Sobre a empresa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.2.1 Organizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3 Engenharia de Software no QuintoAndar . . . . . . . . . . . . . . . . . . . . . . . . 11
1.3.1 Gestao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.2 Guildas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.3 Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2 Atividades planejadas 13
2.1 Objetivos a serem alcancados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Fluxo de trabalho 14
3.1 Adhoc Sherlock: Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1.1 Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.2 Squad Health Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1.3 Sprint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2 Supply e Supply CRM: Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2.1 Replenishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.2 Retro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Contribuicao e colaboracao de codigo . . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Atividades desenvolvidas 19
4.1 Estagio Supervisionado I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1.1 Desenvolvimento de um sistema de envio de comunicacoes e notificacoes
automatizadas atraves de API disponibilizada pela WhatsApp Inc . . . . . . 19
4.1.2 Refatoracao do sistema de cancelamento de visita . . . . . . . . . . . . . . . 20
4.1.3 Exibicao de propostas ativas para um imovel . . . . . . . . . . . . . . . . . . 21
4.1.4 Microsservico de alerta e recomendacao de novos imoveis para usuarios . . . 21
4.2 Estagio Supervisionado II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.1 Reformular os motivos de descarte de lead . . . . . . . . . . . . . . . . . . . 22
4.2.2 Implementar mudancas nos sistemas internos da empresa para coletar informacoes
de motivo para o abandono de cadastro de imovel ou adiamento da sessao de
fotos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Estagio Supevisionadado III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.1 Integrar a ferramenta interna de CRM com uma plataforma de Autodialer . . 24
5 Disciplinas 24
6 Cronograma de tarefas realizadas 25
6.1 Estagio Supervisionado I . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.1 Outubro de 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6
6.2 Estagio Supervisionado II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2.1 Julho de 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3 Estagio Supervisionado III . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.3.1 Novembro de 2018 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7 Consideracoes finais 30
7.1 Contribuicoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2 Dificuldades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
7
Glossario
Apache Kafka E uma plataforma de processamento de correntes de mensagens, ou message streams,
que apresenta garantia de entrega e foca em escalabilidade horizontal. Citado na pagina 19
Autodialer Tambem conhecido como “discador automatico”, e um sistema, dentro do contexto
de telefonia, que realiza automaticamente as tarefas de discagem de telefones, manutencao
de filas de discagem e atribuicao de ligacoes conectadas a atendentes disponıveis. Citado na
pagina 14
Backlog E o termo, dentro do Scrum, que designa o que ainda esta para ser feito por um squad e
e divido em tarefas, que podem estar organizadas dentro de epicos. Citado na pagina 15
CRM E um termo, do ingles Customer relationship management, que se refere a praticas, estrategias
e tecnologias que companhias usam para gerir e analisar interacoes com clientes e dados atras
do ciclo de vida do cliente com o objetivo de melhorar os relacionamentos entre cliente e
servico, ajudar na retencao do cliente e promover o crescimento do negocio. Citado na pagina
11
Deploy E um termo, dentro do contexto de tecnologia da informacao, que define a operacao de
tornar disponıvel e acessıvel um servico para o usuario final atraves da aplicacao de uma nova
versao de software a um sistema de hardware (usualmente um ou mais servidores). Citado na
pagina 11
NPS E um termo, do ingles Net Promoter Score, que se refere a uma metodologia, criada por Fred
Heichheld [7], para medir o grau de satisfacao e a lealdade de clientes de uma empresa. Citado
na pagina 11
Onboarding E o processo, para o contexto comercial, de insercao, ambientacao e explicacao de um
novo contexto ou produto para uma ou um grupo de pessoas. Citado na pagina 11
Product Assistant Manager E um papel atribuıdo a pessoa que junto ao Product Manager ira
acompanhar um squad para manter o alinhamento entre engenharia e produto intra e inter
equipes. Citado na pagina 12
Product Manager E um papel atribuıdo a pessoa que define e discute os produtos oferecidos por
uma empresa ou organizacao. Citado na pagina 12
Product Owner E um papel definido no Scrum para a pessoa que representa o negocio ou a
comunidade de clientes dentro de um squad e e responsavel por definir e priorizar junto ao
squad as features que serao implementadas. Citado na pagina 12
Project Lead E o lıder de projeto de um squad, sendo responsavel por nortear decisoes tecnicas ao
nıvel de implementacao de um projeto e servir como referencia tecnica no squad. Citado na
pagina 12
8
Scrum Master E um papel definido dentro do Scrum para a pessoa que sera a facilitadora de
processos e tomada de decisoes dentro de um squad 12
Squad E, para a metodologia Scrum, uma unidade independente mınima de operacao dentro de uma
empresa. Usualmente representa um time ou subtime, possuindo algum grau de hierarquia entre
seus membros. Citado na pagina 12
Tech Lead E o lıder tecnico de um squad, isto e, sustenta a figura de lideranca de engenharia de
software dentro da equipe, cuidando para que a parte tecnica que envolve decisoes tomadas pelo
time seja pesada e pensada e tambem cuida do desenvolvimento de carreira dos engenheiros
de software e analistas de qualidade do squad. Citado na pagina 12
Wrapper E um codigo ou aplicacao, dentro do contexto de software, que enclausura ou encapsula
outro codigo, software ou API. Citado na pagina 20
9
1 Introducao
1.1 Empresa concedente: Quinto Andar Servicos Imobiliarios LTDA
Endereco: Avenida Paulista 2537, 5o Andar - Bela Vista.
CEP: 01311-300
Cidade: Sao Paulo
Estado: SP
CNPJ: 16.788.643/0001-81
Representado por: Andre Gustavo Gontijo Penha e Gabriel Braga Vieira
Supervisor: Guilherme Rodrigues Salerno
Horario de Trabalho: Flexıvel
Carga horaria semanal: 48 horas.
1.2 Sobre a empresa
O estagio foi realizado no QuintoAndar, startup de tecnologia que proporciona uma experiencia
de aluguel rapida e descomplicada desde a procura pelo imovel ate o fechamento do contrato. Atraves
do uso intensivo de tecnologia e design o QuintoAndar esta redesenhando todo o processo de aluguel,
de ponta a ponta, mudando completamente a experiencia do cliente.
Durante o perıodo de Outubro de 2017 o QuintoAndar operou nas cidades de Sao Paulo,
Campinas, Guarulhos, Santo Andre, Sao Caetano e Sao Bernando. Ate Novembro de 2018 sua
operacao se expandiu para outras metropoles como Rio de Janeiro, Brasılia, Goiania e Porto Alegre.
Alguns dos diferenciais da empresa sao: a marcacao de visitas e totalmente online e automatizada;
a negociacao e feita diretamente com o proprietario atraves da plataforma online; o inquilino nao
precisa de fiador ou cheque-calcao, pois o QuintoAndar realiza a analise de credito do inquilino e
banca o seguro fianca; o pagamento ao proprietario e garantido mesmo em caso de inadimplencia
do inquilino e ainda o imovel conta com uma cobertura contra danos de ate 50 mil reais; toda
a documentacao, inclusive assinaturas, e feita online, sem necessidade de ir presencialmente a um
cartorio; a media de tempo de aluguel de um imovel, desde a publicacao ate o contrato assinado, e
de 7 dias.
Em termos de produto para os usuarios finais, o QuintoAndar mantem uma plataforma de anuncio
de imoveis para proprietarios, uma plataforma de busca de imoveis e agendamento de visitas online
para potenciais inquilinos, uma plataforma de negociacao para potenciais inquilinos e proprietarios,
uma plataforma para gestao de aluguel tanto para proprietarios que alugaram um imovel quanto
para inquilinos, um servico de alocacao de visitas para corretores, um servico de alocacao de sessoes
de fotos para fotografos e um programa de recompensas por indicacao de imoveis. Ainda, como
Figure 1: Logotipo da empresa QuintoAndar.
10
produtos para uso interno, sao desenvolvidos e mantidos um sistema de CRM proprio e um sistema
de gerenciamento de pagamentos de alugueis.
1.2.1 Organizacao
A organizacao interna do QuintoAndar esta em constante mudanca, times de operacoes e de
produto sao constantemente reorganizados para buscar os melhores resultados. O trabalho descrito
neste relatorio foi integralmente realizado dentro da area de produto e engenharia. Durante o
perıodo de realizacao das atividades descritas neste relatorio esta area se dividiu em times verticais
responsaveis por segmentos do funil que abrangem desde a captacao de usuarios e imoveis ate o
fechamento do contrato e administracao dos alugueis, times horizontais responsaveis pelas de frentes
data & business intelligence e infraestrutura de sistemas e times adhoc, alocados para atacarem
problemas especıficos.
O time de Marketing & Data e um time horizontal que atua tanto promocao da marca QuintoAndar
e atracao de novos usuarios em geral, sejam potenciais inquilinos, proprietarios ou afiliados, quanto no
desenvolvimento de modelos de aprendizado de maquina para prover novas metricas, dados, insights
e features para outros times da empresa.
Ja o time de Infra e o time horizontal que cuida da manutencao dos sistemas da empresa, Deploy
automaticos, alertas de problemas e monitoramento.
Responsavel pela captacao de novos imoveis esta o time de Supply, que foca na vertical de
conversao de imoveis, cuidando do Onboarding dos proprietarios, do processo de publicacao dos
imoveis, da gestao de fotografos e do programa de afiliados que oferece recompensas para usuarios
que indicam novos imoveis.
A vertical de captacao e conversao de novos inquilinos esta sob responsabilidade do time de
Booking, que foca no inquilino ate o momento em que ele agenda uma visita ate a conversao de
visitas realizadas em contratos assinados.
O time de Rental Management cuida da vertical de administracao do aluguel, tanto da parte do
inquilino quanto do proprietario, desde o momento da vistoria e entrega de chaves para o inquilino
ate o momento de saıda do inquilino e entrega do apartamento ao proprietario.
Payments e o time que cuida do pagamento de alugueis e de comissoes de corretores, fotografos
e afiliados.
Atualmente tres times adhoc estao alocados: atacando problemas e desafios da plataforma de
negociacao de aluguel esta o time adhoc Wolves; para melhorar e desenvolver a ferramenta interna
de CRM foi alocado o time adhoc CRM & Help; e, por fim, o time adhoc Sherlock ataca o desafio
de melhorar o NPS da empresa.
1.3 Engenharia de Software no QuintoAndar
Os produtos e toda a operacao do QuintoAndar dependem fortemente de solucoes de software e
o time de engenharia e que desenvolve e mantem todas as ferramentas que permitem o QuintoAndar
operar da forma como opera. E tarefa dos engenheiros de software discutir e desenvolver novas
funcionalidades e dar manutencao nos sistemas da empresa para permitir o crescimento da empresa
de maneira sustentavel, tomando vantagem da tecnologia para manter o negocio escalavel.
11
1.3.1 Gestao
Todos os times do QuintoAndar sao livres para escolherem suas metodologias de trabalho e
discutirem o que melhor funciona para cada um. Atualmente, todos os times adotam metodologias
de desenvolvimento agil.
Em sua maioria, os times utilizam variacoes da metodologia Scrum em conjunto com a Kanban,
ou tambem Scrumban.
Cada Squad possui, alem de alguns engenheiros de software, um Tech Lead e um Project Lead,
que dividem as responsabilidades de Scrum Master e um Product Manager e um Product Assistant
Manager, que dividem as responsabilidades de um Product Owner.
1.3.2 Guildas
Alem dos times regulares, existe uma guilda de frontend e uma de code health scalability, que
sao abertas para qualquer engenheiro de software da empresa participar. O objetivo das guildas
e trabalhar o alinhamento entre times de questoes de engenharia de software, como stacks de
tecnologia, convencoes de codigo e testes, APIs, organizacao de projetos. Tambem existe um grande
empenho de ambas as guildas em promover o compartilhamento e reaproveitamento de codigo entre
diferentes projetos; o que inclui incentivos a modularizacao de sistemas e publicacao de codigos open
source.
1.3.3 Sistemas
Os sistemas do QuintoAndar sao pensados para serem escalaveis a medio prazo, em geral e
desejavel que o sistema seja escalavel ao longo prazo, porem, como a exploracao de novos caminhos e
a mudanca de objetivos sao relativamente constantes dentro da empresa, geralmente nao e vantajoso
dispender o esforco para desenvolver sistemas escalaveis a longo prazo, sendo que a maioria sera
reestruturada, abandonada ou repensada no medio prazo.
O primeiro sistema da empresa e o maior hoje e chamado de Main, um monolito escrito em
Java responsavel pelas logicas de negocio da empresa e operacionalizacao do processo de visitas e
negociacao, no entanto, com o tempo este monolito comecou a abracar responsabilidades para alem
do seu escopo original. Utilizar um sistema monolito foi particularmente vantajoso para a empresa
em seus primeiros anos, devido a facilidade de contruir novas funcionalidades dentro de um sistema
pronto e com um time pequeno. Hoje a Main e dividida em cinco modulos principais: business,
planner, view, daemons e mobile-api. A business e responsavel por todas as logicas de negocio. O
planner e responsavel pela atribuicao de visitas para corretores de maneira a otimizar o numero de
agentes de visita disponıveis para atender. A view e responsavel pela apresentacao do sistema aos
usuarios. O daemons controla jobs que sao executados periodicamente. A mobile-api serve uma
interface para outras aplicacoes integrarem com a Main.
A Main utiliza componentes do framework Spring e o framework Hibernate para integrar com
um banco de dados MySQL. O desenvolvimento na Main e orientado a objetos e a maioria de sua
base de codigos segue boas praticas de programacao populares na literatura, exceto pela cobertura
de testes. Hoje apenas 5% da base de codigo deste projeto e coberto por testes de unidade e existem
poucos testes de integracao.
12
Apesar da maioria dos codigos seguirem boas praticas de programacao, ainda existe neste projeto
secoes de codigo nao cuidadosamente pensadas e que acabam por prejudicar a manutenibilidade do
projeto e impoe desafios a uma boa integracao com novos codigos escritos.
Hoje a Main conta com mais de 500 mil linhas de codigo e comeca a apresentar problemas de
escalabilidade e manutenibilidade custosos de resolver. Com a maturacao da empresa, os sistemas
sao hoje exigidos maior confiabilidade e, aos poucos, responsabilidades estao sendo extraıdas da Main
para novos microsservicos.
Atualmente a interface web fornecida pela Main (modulo view) apenas e utilizada no uso interno
de administradores do sistema. Projetos diferentes cuidam de integrar com a mobile-api, planner e
business para apresentar o frontend para seus usuarios:
• O projeto CRM fornece a interface para a equipe de operacoes;
• Os projetos PWA Tenants e iOS Tenants apresentam as interfaces (Web, Android e iOS) para
potenciais inquilinos;
• Os projetos PWA Owners e iOS Owners apresentam as interfaces para o proprietario anunciando
um imovel;
• O projeto Godfather apresenta as interfaces de negociacao de aluguel para proprietario e
inquilino que sao embutidas nas outras interfaces;
• O projeto Mission Control apresenta as interfaces de gestao e administracao do aluguel, tanto
para inquilinos quanto para proprietarios que tambem e embutida nas outras interfaces;
• O projeto App Visitas apresenta a interface para corretores ajustarem suas agendas e receberem
visitas, bem como acompanhar o status de clientes atendidos;
• O projeto App Afiliados apresenta a interface do programa Indica Aı para afiliados indicares
imoveis, acompanharem a validacao de seus leads e gerir suas recompensas.
• O projeto App Vistoria apresenta a interface para vistoriadores serem alocados a sessoes de
vistoria e submeterem os resultados das vistorias;
• O projeto Peterparker fornece a interface para fotografos se cadastrarem e receberem e gerenciar
sessoes de fotos; e
• O projeto Darkrum apresenta a interface para fotografos fazerem o upload de fotos, fotos 360
e vıdeos para imoveis.
Alem dos projetos de frontend existem mais de 20 microsservicos operando o backend do
QuintoAndar e alguns projetos existem como repositorios de codigo compartilhado, servindo para
serem importados por outros projetos.
2 Atividades planejadas
• Estagio Supervisionado I - Outubro, 2017:
13
– Desenvolvimento de um sistema de envio de comunicacoes e notificacoes automatizadas
atraves de API disponibilizada pela WhatsApp Inc ;
– Refatoracao do sistema de cancelamento de visitas para melhor estruturar os motivos de
cancelamento e permitir o consumo desta informacao pelos sistemas de comunicacoes
automaticas;
– Implementacao da feature de exibicao de propostas ativas para um imovel nas informacoes
de listing para o usuario, bem como a probabilidade de aluguel do imovel;
– Planejamento, arquiteturacao e implementacao um microsservico de alerta e recomendacao
de novos imoveis para usuarios.
• Estagio Supervisionado II - Julho, 2018:
– Reformulacao dos motivos de descarte de lead ;
– Implementacao de mudancas nos sistemas internos da empresa para coletar informacoes
de motivo para o abandono de cadastro de imovel ou adiamento da sessao de fotos.
• Estagio Supervisionado III - Novembro, 2018:
– Integracao da ferramenta de CRM com uma plataforma de Autodialer.
2.1 Objetivos a serem alcancados
Durante o perıodo de trabalho, o colaborador devera desenvolver suas atividades com o proposito
de obter pratica em conhecimentos associados a engenharia de software. Espera-se que sejam
explorados os conceitos de organizacao e trabalho em equipe que tangem metodologias de desenvolvimento
agil e tambem conceitos de organizacao e boas praticas de codigo, como a decisao do emprego
de padroes de codigo bem estabelecidos na literatura quando cabıvel em vista dos princıpios de
manutenibilidade e legibilidade do codigo produzido. Ainda, e esperado o colaborador enxergar,
utilizar e denotar conhecimentos, obtidos em disciplinas realizadas durante o curso de graduacao,
uteis ao trabalho desenvolvido.
3 Fluxo de trabalho
Cada time na empresa possui particularidades em seu fluxo de trabalho. Nesta secao sao descritos
os fluxos de trabalho das equipes as quais o colaborador integrou durante os perıodos descritos neste
relatorio, o time adhoc Sherlock durante Outubro de 2017, o time Supply durante Julho de 2018 e
o time Supply CRM durante Novembro de 2018; todavia sao observados fluxos similares em todas
as outras equipes da area de produto e engenharia.
3.1 Adhoc Sherlock: Scrum
O time adhoc Sherlock utilizou, durante Outubro de 2017, uma variacao propria do Scrum [9],
criada com base no que os membros do time julgaram alinhar e funcionar melhor com seus objetivos.
A plataforma Jira foi empregada para organizar os ciclos de Sprint. As tarefas eram definidas no
inıcio de cada Sprint em uma reuniao de Planning, onde o time revisava as tarefas planejadas a fim
14
de entender se o planejamento foi adequado para o que foi proposto e discutia, definia e pontuava
as tarefas da proxima Sprint. A cada dois ciclos de Sprint era realizada uma sessao de Squad Health
Check, uma metodologia de analise de pontos considerados importantes pelo time para a felicidade
do mesmo.
3.1.1 Planning
Cada Sprint do time durava duas semanas e, alem dos desenvolvedores, participavam igualmente
do processo os designers. Todas as partes da reuniao eram lideradas ou pelo Product Manager ou
pelo Tech Lead, no entanto a dinamica da reuniao nao se traduzia em um modelo de expositor e
ouvintes, mas sim em modelo de discussao aberta, em que uma pessoa trazia o assunto e discutia
ele e escutava a opiniao de todos os outros.
O Product Manager expunha para o time os objetivos a medio prazo, os pontos que seriam
desenvolvidos para alcancar esses objetivos e o que o time ja havia feito em relacao a isso e como
estava sendo o impacto do time nestes pontos.
Apos, o Tech Lead trazia cada ponto exposto pelo Product Manager para uma discussao que
visava determinar quais seriam as tarefas que deveriam ser realizadas para alcancar aquele ponto.
Uma vez definidas as tarefas, cada uma era pontuada por todos do time utilizando a metodologia
de Planning Poker : A tarefa era descrita pelo Tech Lead ou por quem definiu a tarefa para o time e
entao cada pessoa escolhia uma pontuacao de complexidade para a tarefa (a metodologia de Planning
Poker sugere que a pontuacao seja discretizada em numeros da sequencia de Fibonacci) sem expor
isso as outras pessoas para evitar influencias no voto de cada pessoa, depois todos exibiam suas
pontuacoes e por fim o time discutia um conscenso e esclarecia duvidas e desentendimentos sobre a
tarefa [5].
No fim da reuniao o time priorizava as tarefas e definia, com base no rendimento de Sprints
passadas, quais tarefas entravam para a proxima Sprint e quais ficavam de fora, no Backlog do time.
3.1.2 Squad Health Check
A cada dois ciclos de Sprint era realizada uma sessao de Squad Health Check logo antes da
Planning. Esta era uma metodologia que buscava observar a evolucao de pontos considerados
importantes para a felicidade do time ao longo do tempo a fim de incentivar tomada de acoes
quando algum ponto nao estava funcionando para o time.
A metodologia, criada pelo Spotify em 2014 [2], propunha que os pontos que seriam observados
fossem definidos pelo proprio time e que nao excedessem 10 questoes. No time adhoc Sherlock foram
acompanhadas 8 questoes:
• Delivering Value: “O time acredita no valor de suas entregas, pode se orgulhar delas e os
stakeholders estao contentes com elas?”;
• Easy to release: “Fazer o release do software e simples, seguro, sem stress e bastante automatizado?”;
• Fun: “O time ama fazer seu trabalho e se diverte trabalhando?”;
• Health of Codebase: “O time se orgulha da qualidade do seu codigo? Ele e simples, direto,
inteligıvel, manutenıvel, eficiente e testado?”;
15
• Learning : “O time aprende coisas interessantes com frequencia?”;
• Mission: “O time sabe porque existe, conhece e entende seus objetivos e acredita e gosta
deles?”;
• Pawns or Players: “O time se sente em controle dos caminhos que toma? A decisao de fazer
algo e quando fazer e do time?”;
• Speed : “O time se sente rapido e eficiente?”;
3.1.3 Sprint
As tarefas definidas na Planning eram adicionadas ao backlog da plataforma JIRA e, entao,
cada membro do time era livre para atribuir quaisquer tarefas que quiser para si. No entanto, um
desenvolvedor apenas atribuıa uma tarefa para si no momento em que iria realmente fazer a tarefa
e nao previamente ao seu inıcio. Era convencao que um desenvolvedor deveria realizar apenas uma
tarefa por vez normalmente, a menos que uma tarefa entrasse em um estado blocked, i.e., dependia
de algum outro fator externo naquele momento e nao poderia continuar a ser desenvolvida por
hora. A medida que as tarefas eram realizadas, elas passavam para a fase de review por pares e o
desenvolvedor comecava outra tarefa.
Caso o desenvolvedor sentisse dificuldades com sua tarefa era comum ele recorrer ao Tech Lead
ou a qualquer outra pessoa que julgasse relevante em busca de auxılio. Apenas em casos extremos
o desenvolvedor abdicava da tarefa com a qual tinha dificuldade.
Todos os dias o time fazia um ritual de daily : uma reuniao rapida em que cada um descrevia
o que fez desde a ultima daily, o que estava fazendo e o que pretendia fazer caso cabıvel. Este
ritual era importante para o alinhamento, nao so do Tech Lead com os desenvolvedores, mas entre
os proprios desenvolvedores, pois muitas vezes o trabalho de alguns afetava, tanto no sentido de
colaboracao quanto no de conflito, o de outros [8].
3.2 Supply e Supply CRM: Kanban
Os times de Supply e Supply CRM utilizaram, durante Junho e Novembro de 2018 respectivamente,
uma metodologia de Kanban [3] simplificada e customizada. Assim como as demais equipes do
QuintoAndar, a plataforma Jira foi utilizada para fazer o controle de tarefas. As tarefas eram
definidas em uma reuniao de Replenishment, onde o time definia quais seriam as proximas entregas
e como as quebrariam em tarefas pequenas. A cada duas semanas era realizada uma reuniao de
Retro, onde o time se auto avaliava nas ultimas duas semanas em termos de praticas que buscavam
continuar, parar ou comecar. A cada mes era realizada tambem uma reuniao de Squad Health Check.
Dentro da metodologia de Kanban empregada as tarefas comecavam em um estado ToDo para
passarem por Work In Progress, Review, Testing, Acceptance, Ready To Deploy e Done. Cada uma
destas etapas possuia um numero maximo de tarefas que poderiam estar naquele estado, para forcar
o fluxo constante de tarefas ao longo das etapas e evitar que desenvolvedores atuassem em multiplas
tarefas ao mesmo tempo ao inves de focar em uma por vez. A etapa de ToDo possuıa tambem um
numero mınimo de tarefas que deveriam estar disponıveis, quando o numero de tarefas em ToDo
atingisse esse mınimo era realizado o Replenishment.
16
3.2.1 Replenishment
A reuniao de “reabastecimento” era realizada para definir novas tarefas para o time abordar. O
Product Manager expunha para o time as entregas nas quais o time focaria e o porque delas.
O Tech Lead entao trazia cada uma das entregas definidas e propunha uma divisao de tarefas,
discutindo com o time a melhor forma de atacar as entregas e como dividir as tarefas.
Ao fim as novas tarefas eram colocadas em ToDo.
3.2.2 Retro
O ritual de retrospectiva objetivava avaliar qualitativamente as entregas e comportamento do
time.
De inıcio eram revisadas as tarefas entregues nas ultimas duas semanas, onde o time tinha a
oportunidade de comentar sobre dificuldades que encontraram nas tarefas, de falar sobre pontos
positivos que surgiram e tambem de discutir as entregas de uma forma geral. Apos, cada membro
da equipe pensava em pontos que deviam ser de atencao do time para parar de fazer, comecar a
fazer ou continuar fazendo. Depois que todos anotavam seus pontos, o time discutia o que cada
um anotou. Juntamente eram revisados os pontos levantados na ultima Retro para que se pudesse
discutir se o time estava evoluindo em relacao ao pontos observados no passado.
3.3 Contribuicao e colaboracao de codigo
O QuintoAndar utiliza Git [10] como ferramenta para contribuicao e colaboracao de codigo.
Alem dos benefıcios de versionamento, as ferramentas oferecidas pelo Git e pela plataforma GitHub
sao muito uteis e praticas para manter um ambiente organizado e seguro de desenvolvimento sem
subtrair em praticidade e rapidez.
No QuintoAndar a maioria dos projetos tem seus mecanismos automaticos de deploy integrados
a branch master do projeto, ou seja, a branch master usualmente e o codigo que esta em producao.
Codigos que sao aprovados na fase de review sao colocados em uma branch chamada staging. Esta
branch faz deploy para um ambiente production-like: todos os codigos em staging ja foram revisados
e os bancos de dados sao copias anonimizadas dos bancos reais de producao. Neste ambiente os
Q&As realizam testes de comportamento manuais e verificam se a feature ou correcao que o codigo
introduz apresenta o comportamento esperado. Ambientes de teste, apelidados de forno, tambem
tem deploy automatico associado a uma branch chamada forno ou develop normalmente.
Por conta da importancia da branch master, ela e protegida contra commits diretos e a utilizacao
de comandos que nao preservam historico (e.g., git push force). Toda contribuicao ao projeto
deve ser feita a partir de uma branch separada da master e um Pull Request deve ser aberto no
GitHub para que outros desenvolvedores revisem o codigo. E convencao que para contribuicoes
regulares a aprovacao do Pull Request seja feita por, pelo menos, dois desenvolvedores. Todos os
desenvolvedores, independente de times, revisam Pull Requests; a comunicacao da abertura do Pull
Request e feita atraves da ferramenta Slack.
Alguns projetos do QuintoAndar usam uma simplificacao da metodologia Gitflow [1], em que a
branch master e “protegida” por uma branch develop, que recebe as contribuicoes normais e apos um
17
conjunto de contribuicoes, geralmente que somam a uma feature completa, e feito um Pull Request
de release da branch develop para a master.
Cada desenvolvedor deve manter uma branch para cada tarefa, para nao interferir com o desenvolvimento
de outros desenvolvedores e facilitar o processo de revisao. Quando ha features maiores e multiplos
times que interagem com um projeto, geralmente o time abre uma branch relativa a feature e entao
os Pull Requests sao realizados para essa branch separada para depois que a feature estiver pronta
para ser lancada ela ir para a master ou develop.
18
4 Atividades desenvolvidas
4.1 Estagio Supervisionado I
4.1.1 Desenvolvimento de um sistema de envio de comunicacoes e notificacoes automatizadas
atraves de API disponibilizada pela WhatsApp Inc
O QuintoAndar foi convidado a utilizar uma API, entao beta, da Whatsapp Inc para o envio
automatizado de mensagens transacionais no aplicativo de mensagens instantaneas Whatsapp. Esta
e uma oportunidade de interesse, pois diversos processos da empresa necessitam alcancar o cliente
com rapidez e a plataforma de mensagens Whatsapp tem grande alcance sobre a base de usuarios.
Nesta atividade, alem do time adhoc Sherlock, estava envolvido o time de infraestrutura. Este
foi responsavel pela criacao de um microsservico, chamado de Markito, para interagir com a API
do Whatsapp que “escuta” um topico de mensagens no Kafka para envia-las a API do Whatsapp e
tambem retorna callbacks recebidos a outro topico dedicado do Apache Kafka. Ja o time Sherlock
foi responsavel pela implementacao dos triggers e logicas de negocio das comunicacoes que seriam
enviadas como mensagens instantaneas; estas tarefas compreendiam o sistema Main e o microsservico
Jaiminho.
Foi criado o microsservico Markito, em Python, que basicamente mantem um worker que processa
mensagens de um topico no Kafka do QuintoAndar, envia as mensagens a API Restful do Whatsapp,
contendo algumas regras basicas de re-tentativas e, conforme o resultado retornado pela API, escreve
em outro topico do Kafka uma mensagem informando o sucesso ou falha do envio.
A Whatsapp API tambem fornece uma configuracao de endpoint para o qual serao feitas
requisicoes POST com informacoes de callback das mensagens, como quando uma mensagem foi
recebida e quando ela foi lida. O Markito possui um servidor WEB que recebe tais requisicoes e
produz uma mensagem de callback para um topico no Kafka caso seja de interesse do microsservico
que enviou alguma mensagem tomar acoes baseado callbacks da mensagem.
As logicas de negocio atreladas ao fluxo de uma visita no QuintoAndar, desde a marcacao, ate a
realizacao, estao todas contidas na Main, mais especificamente no modulo business.
O framework Hibernate, utilizado na Main, prove um mecanismo de Entity Listeners que sao
executados a cada mudanca em uma entidade. Todas as comunicacoes existentes em relacao a uma
visita sao iniciadas a partir de um evento processado por um Entity Listener.
O Listener de visita foi implementado de tal forma que o proprio metodo que recebe o evento
implementava todas as regras de negocio que definiam se o evento produziria algum tipo de comunicacao
e, em caso afirmativo, tambem definia qual seria o meio de comunicacao utilizado e preparava os
dados necessario para o envio da mensagem.
Neste modelo, um unico objeto unia a decisao de negocio em respeito a quando enviar ou nao
alguma comunicacao, qual meio de comunicacao utilizar e como preparar os dados necessarios ao
envio da mensagem. Visando adequar esta parte do sistema aos princıpios SOLID [4] foi feita uma
refatoracao deste codigo a fim de separar as responsabilidades multiplas do Entity Listener.
No novo modelo, o Entity Listener apenas classifica o tipo do evento recebido entre: (i) criacao
de nova entidade de visita; (ii) alteracao de uma entidade de visita que nao cancela a visita; e (iii)
alteracao de uma entidade de visita que cancela a visita. Uma vez classificado o evento, o seu
processamento e delegado a objetos que implementam uma interface EventHandler que define um
19
metodo que retorna um enumeravel identificando o tipo do evento que aquele objeto processa.
Cada EventHandler atua como intermediador, delegando o processamento do evento a outros
handlers especializados, como handlers que publicam mensagens no Kafka e handlers que enviam
comunicacoes. No caso, todos os handlers de comunicacao implementam uma interface comum e
cada um e responsavel por um meio de comunicacao. Para a comunicacao dos eventos de visita
foram criados handlers de Email, SMS, Push Notification e Whatsapp.
Cada handler toma a decisao de enviar ou nao comunicacoes dado um evento e, em caso positivo,
utiliza um construtor que transforma a entidade que sofreu o evento em um objeto adequado a
serializacao para envio da mensagem. O objeto construıdo e, entao, enviado a um dispatcher que se
conecta com o Kafka para enviar a mensagem.
Apos a refatoracao foi adicionada um handler WhatsappCommunicationHandler e um construtor
para compor um Value Object a partir de uma entidade de visita com as informacoes necessarias ao
envio das mensagens Whatsapp sendo implementadas.
4.1.2 Refatoracao do sistema de cancelamento de visita
O cancelamento de uma visita era realizado atraves de um metodo presente no servico de visita,
um Java Bean que concentra todas as manipulacoes sobre uma entidade de visita. Este metodo
recebia diversos parametros, muitos opcionais, e era encapsulado por alguns outros metodos que
faziam a sobrecarga do metodo original.
Diversos pontos do sistema Main utilizavam os metodos de cancelamento de visita, porem uma
informacao faltante em tais metodos era a identificacao da origem do cancelamento e, tambem,
o motivo do cancelamento era um campo texto aberto. Portanto, logicas de negocio reativas ao
cancelamento de uma visita nao tinham a informacao da origem daquele evento e nao podiam tratar
o motivo de uma forma eficiente, pois algumas partes do sistema preenchiam automaticamente o
motivo, mas em outras partes o motivo era preenchido com textos provindos de campos abertos
expostos aos usuarios.
Visando implementar regras de negocio para serem aplicadas a um evento de cancelamento de
visita que levam em conta a origem e o motivo do cancelamento um refatoracao de todo o sistema
de cancelamento de visita devia ser realizada.
Os metodos de cancelamento deveriam ser alterados para receber um enumeravel identificando
a plataforma de origem da acao e um enumeravel representando o motivo do cancelamento.
Exaustivamente todos os pontos do sistema que realizavam o cancelamento de visita foram
alterados para informar sua origem e motivo do cancelamento, isto incluiu a alteracao do contrato
de algumas das APIs internas do QuintoAndar e o versionamento de outras, bem como a alteracao
dos sistemas que interagiam com tais APIs para: (i) informar a origem do evento; e (ii) informar o
motivo do cancelamento, sendo necessarias novas interfaces de usuarios para apresentar as opcoes
de motivacao da acao.
Os metodos de cancelamento, entao, receberam dois novos parametros e isto adicionou mais
entropia aos argumentos dos metodos. Para amenizar o problema e tornar o codigo mais legıvel
e manutenıvel foi criado um Wrapper dos parametros de cancelamento, implementando o Builder
Pattern, para expor os argumentos obrigatorios e opcionais de forma clara. Entao os metodos
que faziam sobrecarga apenas para passarem alguns parametros opcionais adiante como nulos foram
20
apagados e o metodo original de cancelamento passou a receber apenas um wrapper como argumento.
4.1.3 Exibicao de propostas ativas para um imovel
Foi desenhada uma funcionalidade para expor o numero de propostas ativas em um imovel para
os usuarios que estao procurando imoveis para visitar. A intencao da funcionalidade e nao frustrar
os usuarios que marcam visitas em imoveis que ja tem propostas ativas e podem ser alugados por
outra pessoas em poucos dias.
Posteriormente ao desenho da feature, ela foi alterada para exibir a probabilidade do imovel ser
alugado nos proximos 5 dias ao inves do numero de propostas ativas.
O calculo da probabilidade do imovel ser alugado em algum intervalo de tempo futuro foi
implementado atraves de algoritmos de aprendizado de maquina pelo time de Data Science e exposto
como uma informacao consumıvel atraves de uma API que recebe uma requisicao POST informando
todas as propostas ativas do imovel e o estado de cada uma.
O time Sherlock implementou o frontend da feature e uma regua de comunicacao por Whatsapp
para informar usuarios que tem visita marcada em um imovel que atingiu uma probabilidade de ser
alugado maior do que 70% que sua visita pode ser cancelada automaticamente nos dias subsequentes
caso o imovel de fato seja alugado e tambem para permitir o usuario cancelar por si mesmo a visita
visando economizar tempo case ele acredite que desperdicara seu tempo, pois provavelmente o imovel
sera alugado por outra pessoa.
A tarefa desenvolvida pelo aluno competia implementar uma rotina a ser executada diariamente
para verificar imoveis que atingiram a probabilidade de aluguel nos proximos 5 dias igual ou maior a
70% e enviar mensagens automaticas por Whatsapp para informar os usuarios com visita marcada
para estes imoveis.
Para tal foi feito um job no daemons que busca junto a API criado pelo time de Data Science
a probabilidade de aluguel de cada imovel ativo na base de dados do QuintoAndar e dispara uma
mensagem no Kafka para o Jaiminho enviar a mensagem Whatsapp caso a probabilidade mınima
para envio da mensagem tenha sido atingida.
4.1.4 Microsservico de alerta e recomendacao de novos imoveis para usuarios
O aluguel de imoveis atrativos (imoveis que sao bem localizados, bem conservados, oferecem boas
amenidades, boas instalacoes e tem um valor de aluguel atrativo, isto e, dentro ou abaixo da media
da regiao) e realizado muito rapido devido ao numero de interessados que atrai e as caracteristicas de
agilidade que a plataforma do QuintoAndar prove, portanto a probabilidade de um usuario encontrar
este tipo de imovel e baixa e usuarios mais engajados que estao ha tempo procurando um imovel
do tipo sao obrigados a refazerem suas buscas diariamente para encontra-los, o que gera perda do
tempo do cliente e desincentivo para ele continuar a utilizar a plataforma.
Para amenizar tal situacao foi pensada uma feature para a criacao de alertas automatizados para
usuarios que buscam novos imoveis dentro de caracterısticas de sua preferencia. A ideia e permitir a
criacao de um filtro pelo usuario que lhe envie um email sempre que um novo imovel que se encaixe
dentro do filtro for cadastrado no QuintoAndar. Com esse servico e esperado um engajamento maior
dos usuarios, pois mesmo que nao tenham tempo ou motivacao para pesquisar ativamente imoveis
21
na plataforma, o alerta automatico ira informa-los quando um imovel que ele potencialmente goste
estiver disponıvel.
A feature esta sendo implementada em um novo microsservico, chamado Cidade Alerta, que
deve gerenciar alertas automatizados e, no futuro, pode tambem implementar rotinas que apliquem
algoritmos de reconhecimento de padroes e aprendizado de maquina para recomendar imoveis do
QuintoAndar baseado nos perfis de busca de cada usuario.
O microsservico foi desenvolvido pensando em implementa-lo em dois meses e que seu foco inicial
seria apenas o gerenciamento de alertas automatizados, sem implementar, num primeiro momento,
em interfaces de usuario para gerenciamento dos alertas e em features de recomendacao de imoveis
baseadas em algoritmos de reconhecimento de padrao ou aprendizado de maquina.
A stack de tecnologias foi escolhida para atender aos requisitos de tempo e funcionalidades
esperadas ao mesmo tempo que nao destoe das tecnologias ja utilizadas pela empresa. O microsservico
foi escrito utilizando a linguagem Python 3.6 e utilizando Flask como framework web e a biblioteca
APScheduler para o gerenciamento de rotinas periodicas. A base de dados escolhida foi a Mongo
DB, uma database NoSQL. A decisao de utilizar uma base de dados nao relacional foi tomada
devido a natureza dos dados armazenados nao requerer relacionamentos mais complexos do que o
aninhamento de documentos e a ideia primaria de armazenar alertas criados com a mesma estrutura
JSON com que forem criados a partir da API, dispensando tratamentos e manipulacao de campos e
esquemas de dados por parte da aplicacao antes de persistir tais informacoes.
Durante dois meses foi implementado o microsservico pelo time Sherlock, seguindo o padrao
MVC [6] e princıpios de programacao orientada a objetos.
4.2 Estagio Supervisionado II
4.2.1 Reformular os motivos de descarte de lead
Um lead para o QuintoAndar e uma representacao de um imovel potencial para publicacao. Estes
sao adquiridos por diversos meios:
• Organico: um proprietario acessou sozinho o site ou aplicativo do QuintoAndar, preencheu,
pelo menos, a informacao de telefone ou email e nao prosseguiu para cadastrar sozinho um
imovel;
• Marketing: um proprietario foi impactado por alguma campanha de marketing do QuintoAndar
e deixou informacoes para contado atraves desta campanha;
• Crawler : sistemas de vasculhamento de imoveis cadastrados em sites de anuncio de aluguel
identificaram um imovel que nao tem cadastro no QuintoAndar; e
• Indicacao: um usuario indicou o contado de um proprietario para o QuintoAndar.
Todos os leads sao processados por algoritmos de descarte que vao filtrar casos duplicados,
imoveis ja cadastrados, imoveis fora da area de atuacao, entre outros casos. Apos um lead ser
processado ele e enviado ao sistema de CRM para que uma captadora entre em contato com o
proprietario afim de converter esse lead, isto e, cadastrar um novo imovel no QuintoAndar com
22
base nas informacoes do lead. Neste processo leads sao descartados pelas captadoras por diversos
motivos.
Todo descarte de lead exige a escolha de um motivo para o descarte. Apesar de os motivos
existentes ja contemplarem todos os casos, deseja-se uma maior especificacao destes, para aumentar
a granularidade e poder atuar na recuperacao de leads perdidos.
A implementacao desta mudanca foi realizada de forma retro-compatıvel, isto e, os motivos
antigos de descarte continuam existindo para fins de consulta e analise, mas todo novo descarte
pode apenas utilizar um dos novos motivos definidos.
A introducao dos novos motivos e deprecacao dos antigos demandou alteracoes nos frontends
tanto no CRM, quanto no aplicativo IndicaAı para a exibicao do motivo de descarte de uma indicacao
de usuario; alteracoes nos algoritmos de descarte; e alteracoes nos fluxos de comunicacao automaticos
que eram disparados por motivos especıficos de descarte.
Como a mudanca envolvia grandes partes do sistema, ela foi introduzida com um feature
toggle, isto e, um mecanismo de ativacao do novo codigo por uma variavel de ambiente facilmente
configuravel. Os novos motivos de descarte foram extensamente testados em um ambiente de staging
e validados pela equipe de produto antes de serem ativados em producao.
4.2.2 Implementar mudancas nos sistemas internos da empresa para coletar informacoes
de motivo para o abandono de cadastro de imovel ou adiamento da sessao de fotos
Visando permitir acoes futuras para recuperacao de cadastros abandonados ou delongados e
tambem para entender os motivos que causam o abandono de um cadastro ou delonga, foi proposto
coletar motivos pelos quais uma sessao de fotos do imovel e cancelada ou postergada de agendamento.
A etapa de sessao de fotos e a ultima antes da publicacao do imovel. Para agendar uma sessao
uma captadora e sempre acionada atraves do CRM, mas o proprietario pode tambem realizar o
agendamento sozinho pelo site ou aplicativo. Quando uma sessao de fotos e cancelada ou nao e
concluıda com sucesso por quaisquer motivos uma captadora tambem e acionada no CRM para
entender o que aconteceu e marcar uma nova sessao.
Nos momentos de contato da captadora com o proprietario, seja para agendar uma nova sessao,
cancelar ou entender o que houve de errado com uma sessao cancelada ou mal sucedida, por vezes ha
a exclusao do imovel devido ao abandono do proprietario no cadastro. Coletar o motivo de abandono
ou motivo pelo qual o proprietario deseja postergar a sessao de foto e uma funcionalidade que deve
ser implementada.
Para acompanhar o status de um imovel durante o seu cadastro, foi criada uma entidade
HouseRegistrationStatus que relaciona o estado de cadastro atual do imovel, o motivo, se cabıvel,
pelo qual o imovel se encontra naquele estado e a entidade de sessao de fotos associada ao imovel.
Foram adicionados parametros a todos os pontos do sistema onde ocorrem alteracoes no status do
imovel durante seu cadastro para coletar os motivos de tal alteracao e, juntamente, foram alterados
todos os frontends internos, Admin e CRM, para requererem a especificacao de um motivo de
cancelamento ou reagendamento de sessao de fotos, bem como a especificacao de um motivo de
exclusao de um imovel que ainda esta na etapa de cadastro.
23
4.3 Estagio Supevisionadado III
4.3.1 Integrar a ferramenta interna de CRM com uma plataforma de Autodialer
O QuintoAndar expande rapidamente suas areas de atuacao e tambem cresce, a taxas aceleradas,
a densidade de imoveis cadastrados em todas as regioes. Os fluxos de cadastro de imovel self-service
sao incentivados e aprimorados constantemente em prol da escalabilidade e independencia do cliente.
Todavia muitos usuarios abandonam o cadastro do imovel ou sequer iniciam algum fluxo de cadastro,
consequentemente uma parcela significativa de novos imoveis ainda e captada atraves de equipes de
Inside Sales, que tratam leads (i.e., contatos que representam potenciais imoveis) atraves de contato
telefonico, realizando o cadastro assistido.
A fim de apoiar a escalabilidade dos times de operacao frente ao crescimento de leads sem a
necessidade de dimensionamento proporcional, em numero de pessoas, foi pensado integrar o CRM
a um sistema de discagem automatica para eliminar tempos improdutivos de discagem, de espera na
linha telefonica e de casos de ligacoes caindo em caixa-postal dos analistas de Inside Sales.
Foi discutido com o time como fazer a integracao e foi decidido que seria implementado um
microsservico para integrar diretamente com a API da plataforma de Autodialer e entao seria
implementada a integracao entre o servico de CRM e o microsservico. Esta abordagem foi favorecida,
pois isola ao maximo os sistemas internos de um sistema externo, que e a plataforma de Autodialer.
A isolacao de um sistema externo evita que logicas de negocio sejam construıdas baseadas em
comportamentos que estao fora do domınio do QuintoAndar e tambem facilita a futura implementacao
de fallbacks e ate mesmo a mudanca de uma solucao externa para outra.
O microsservico, denominado Autodialer API, foi implementado utilizando Java 8 juntamente
com o framework Spring 5. A escolha das tecnologias foi baseada na analise do custo para a
implementacao das funcionalidades necessarias ao servico com a tecnologia e no domınio dos engenheiros
de software da empresa sobre tais tecnologias. O QuintoAndar tem a maior parcela de seus engenheiros
experientes com aplicacoes Java utilizando o framework Spring. Por fim, o banco de dados empregado
foi o MongoDB, pois e o banco de dados nao-relacional que o time do QuintoAndar tem maior
experiencia. Um banco de dados nao relacional foi necessario devido a incerteza sobre o schema dos
dados que seriam armazenados e, principalmente, a compatibilidade com os dados JSON produzidos
pelo CRM e a busca por evitar a replicacao do conhecimento sobre a estrutura de dados do CRM
pelo Autodialer API. Sem a necessidade de relacionamentos entre as entidades, a escolha foi por um
banco de dados nao-relacional.
O Autodialer API foi implementado com sucesso dentro de dois meses e entao empregado por
uma das equipes de Inside Sales para testar o novo fluxo e validar hipoteses.
5 Disciplinas
A formacao academica, como um todo, contribuiu para a formacao profissional do aluno. No
entanto, para a realizacao do estagio algumas disciplinas cursadas se destacaram em suas contribuicoes
para o desempenho das tarefas descritas neste relatorio, ao longo desta secao estas sao apontadas.
Para o exercıcio de visualizacao de logicas e fluxos complexos e arquitetura de boas solucoes,
as disciplinas de Processamento da Informacao, Algoritmos e Estrutura de Dados I e Algoritmos e
Estrutura de Dados II foram grandes contribuintes. A capacidade de enxergar multiplas solucoes para
24
problemas, mesmo que complexos, se demonstrou essencial para que as tarefas fossem executadas
pelo aluno com maior autonomia. Tambem contribuindo neste ponto, mas de uma perspectiva
diferente, a disciplina de Analise de Algoritmos promoveu a visao crıtica quanto a eficiencia de uma
solucao, visao esta necessaria para a implementacao de codigos que fossem eficientes e escalaveis.
A disciplina Programacao Orientada a Objetos explorou conceitos de boas praticas de programacao
dentro do paradigma de orientacao a objetos. Tais conceitos foram de extrema importancia para
a realizacao satisfatoria das atividades do estagio. Enquanto que as boas praticas de codigo em si
possam ser assimiladas rapidamente na ausencia desta disciplina, nela foi estudado profundamente
os conceitos do paradigma de orientacao a objetos, o que permitiu uma real compreensao do racional
pelo qual determinados padroes de codigo sao considerados boas praticas de codigo, quais benefıcios
eles trazem e tambem porque certas praticas sao consideradas ruins dentro deste paradigma. O
conhecimento obtido atraves do estudo realizado dentro desta disciplina refletiu no desenvolvimento
da capacidade de analisar estrategias de implementacao nao obvias e conforma-las com os princıpios
de programacao orientada a objetos.
Ja a disciplina Paradigmas de Programacao explorou conceitos do paradigma funcional, contribuindo
para o seu entendimento e assimilacao de boas praticas dentro deste racional de forma analoga a
contribuicao da disciplina Programacao Orientada a Objetos, mas para o paradigma funcional.
Os conceitos de maquinas de estado abordados na disciplina Linguagens Formais e Automata
foram particularmente uteis para visualizar contextos em que codigos que se beneficiariam de uma
implementacao de uma maquina de estados para controlar fluxos.
Diversas praticas utilizadas no QuintoAndar para a organizacao dos times, tarefas e desenvolvedores
foram abordadas na disciplina de Engenharia de Software. Apesar da disciplina nao se aprofundar
tanto em cada uma das metodologias que podem ser empregadas no contexto de desenvolvimento de
software, os conceitos chaves abordados foram uteis para o entendimento das metodologias praticadas
dentro da empresa e do porque elas foram escolhidas.
A disciplina Banco de Dados foi crucial para permitir o aluno incrementar os modelos de dados no
banco dehttps://www.overleaf.com/project/5c1533a0d4db5771fe2a4f9d dados principal da empresa
e tambem arquitetar os modelos de dados dentro dos microsservicos Cidade Alerta e Autodialer API e
decidir qual tecnologia de banco de dados utilizar para tal. Tambem, houve diversas outras situacoes
onde migracoes no banco de dados foram necessarias e os conhecimentos adquiridos ao longo da
disciplinas foram empregados para a execucao de tais tarefas.
6 Cronograma de tarefas realizadas
Nesta secao estao listadas todas as tarefas realizadas durante cada um dos meses de trabalho.
Cada tarefa foi definida em conjunto com o time e nao necessariamente reflete integralmente o
trabalho executado. E importante destacar que, cada uma das atividades listadas foram executadas
integralmente pelo aluno durante o perıodo de estagio e que a participacao nessas atividades demonstra
a execucao das atividades descritas na secao 4.
25
6.1 Estagio Supervisionado I
6.1.1 Outubro de 2017
• Criar o backend para o envio de emails no Cidade Alerta;
• Criar trigger para o job de busca de imoveis do Cidade Alerta;
• Salvar o set global de imoveis que um usuario ja recebeu por emails do Cidade Alerta;
• Salvar o set de imoveis ja enviados por email para cada alerta no Cidade Alerta;
• Salvar o set global de imoveis ja retornados pelo CloudSearch para um alerta cadastrado no
Cidade Alerta;
• Consertar bug: o schema dos criterios de busca do CloudSearch nao estao conforme o Cidade
Alerta espera;
• Consertar bug: Planner nao esta sempre enviando o numero maximo de visitantes por horario
de visita;
• Consertar bug: Search nao esta utilizando a informacao do numero maximo de visitantes por
horario que e enviada pelo Planner;
• Consertar bug: App de Android de inquilinos nao esta utilizando a informacao do numero
maximo de visitantes por horario que e enviada pelo Planner;
• Consertar bug: App de iOS de inquilinos nao esta utilizando a informacao do numero maximo
de visitantes por horario que e enviada pelo Planner;
• Consertar bug: Backend do Cidade Alerta nao esta mapeando o campo id para house id nos
resultados do CloudSearch antes de salva-los;
• Criar um worker no Cidade Alerta para consultar o CloudSearch periodicamente conforme
alertas cadastrados;
• Enviar dados do nıvel de zoom e centro do mapa para o email de confirmacao de alerta
cadastrado no Cidade Alerta;
• Consertar bug: Backend do Cidade Alerta nao esta respondendo requests com um corpo JSON;
• Criar o backend de composicao de emails no Cidade Alerta;
• Criar validacao do email do usuario no momento de cadastro de um alerta no Cidade Alerta;
• Instrumentar tracking no Amplitude para cada link de imovel enviado por email no Cidade
Alerta;
• Consertar bug: Proprietario esta recebendo email de cancelamento quando um visitante cancela
uma visita mesmo havendo outros visitantes para o mesmo horario;
• Criar variaveis de ambiente para configuracao de email no Cidade Alerta;
26
• Aletrar o schema do endpoint de alertas no Cidade Alerta para aceitar e validar o campo width
do mapa;
• Incluir mınimo de cobertura por testes no Cidade Alerta e integrar a execucao de testes no
passo de pre-commit para promover Test Driven Development;
• Atualizar o payload dos emails do Cidade Alerta para refletir mudancas no layout;
• Integrar logs do Cidade Alerta com o Sentry;
• Criar integracao com o New-Relic para monitorar ambiente de producao;
• Consertar bug: Emails de alertas automatizados estao com informacoes incompletas do imovel;
• Atualizar email do servico de alertas automatizados para nao exibir mais ”perto do Metro”
como um destaque do imovel;
• Consertar bug: Queries no CloudSearch contem clausulas AND vazias;
• Consertar bug: Emails e imoveis enviados pelo servico de alertas automatizados nao estao
sendo registrados no banco de dados;
• Criar coluna na tabela Usuario para fazer o opt-out de comunicacoes via whatsapp;
• Alterar a pagina de edicao do usuario para incluir um checkbox com opt-out de comunicacoes
via whatsapp;
• Criar uma configuracao no YAML da Main para ligar e desligar as comunicacoes via whatsapp
(toggle-feature);
• Refatorar o codigo de envio de push-notification para os casos de cancelamento de visitas;
• Refatorar o job de cancelamento de visitas para usar os parametros reason e reasonCategory
em casos de suspensao e despublicacao;
• Refatorar envio de notificacoes para o Jaiminho;
• Atualizar o backend de cancelamento de visita para enviar a data da visita sem formatacao;
• Consertar bug: URLs de reagendamento de visita e de imoveis similates estao apontando para
a Main e nao para o Search;
• Alterar o Backend For Frontend (BFF) do aplicativo de proprietarios para utilizar o enumeravel
de motivos de despublicacao na versao 3 do aplicativo;
• Refatorar os motivos de suspensao de imoveis;
• Alterar o endpoint do modelo Closing-Predictor no Skynet para usar cache;
• Alterar o endpoint do modelo Closing-Predictor no Skynet para um path configuravel quanto
aos dias a se considerar;
27
• Remover versionamento do path do endpoint do modelo Closing-Predictor no Skynet para usar
versionamento no header;
• Integrar o webserver do Skynet com o New Relic;
• Retirar razao de despublicacao ou suspensao do imovel quando ele e republicado ou reativado;
• Restringir cancelamentos de visitas do imovel para apenas visitas do futuro;
• Nao cancelar vistorias de imoveis suspensos;
• Atualizar metodo de cancelamento de visitas para nao quebrar quando nao houver motivo de
despublicacao ou suspensao.
6.2 Estagio Supervisionado II
6.2.1 Julho de 2018
• Ajustar regras de negocio no app Indica Aı para refletir novos motivos de descarte de lead;
• Alterar o Admin da Main para exigir a especificacao do motivo de cancelamento de uma sessao
de fotos;
• Alterar o Admin da Main para exigir a especificacao do motivo de exclusao de um imovel;
• Alterar o CRM para exigir a especificacao do motivo de reagendamento de uma sessao de fotos;
• Alterar o CRM para designar leads para times de acordo com a fonte de origem do lead;
• Alterar o CRM para repriorizar as tarefas adiadas para aparecerem no fim da lista quando
voltam a serem exibidas;
• Criar um motivo de cancelamento de sessao de fotos para refletir a intencao de reagendar
imediatamente;
• Incluir o id da sessao de fotos na entidade HouseRegistrationStatus na Main;
• Consertar bug: Existem multiplas entidades HouseRegistrationStatus para um mesmo imovel,
o relacionamento entre as duas entidades deveria garantir unicidade;
• Incluir novos motivos de descarte de lead;
• Atualizar a versao da biblioteca Flyway na Main;
• Consertar bug: Motivo de descarte de lead ”Imovel ja publicado no QuintoAndar” esta faltando.
6.3 Estagio Supervisionado III
6.3.1 Novembro de 2018
• Pesquisar servicos de Autodialer e levantar pontos positivos e negativos de cada um;
• Criar estrutura do projeto Autodialer Api em Java utilizando Spring Boot e Mongo DB;
28
• Criar modelos de dados e servicos para carregar e salvar os modelos de dados no banco NoSQL;
• Integar o Autodialer Api com a Api de publicacao de leads do servico de Autodialer;
• Preparar o Autodialer Api para lidar com casos de telefone nao-existente;
• Criar logica no Autodialer Api para refletir o adiamento de uma tarefa para o servico de
Autodialer;
• Criar logica no Autodialer Api para manter registro do numero de tentativas de ligacao para
um lead;
• Enviar um batch tarefas do CRM para o Autodialer Api para testes iniciais;
• Consertar bug: Tarefas de agendamento de sessao de fotos nao estao sendo enviadas ao ou
consumidas pelo Autodialer Api;
• Consertar bug: Existem tarefas de agendamento de sessao de fotos o CRM que nao contem o
numero de telefone do proprietario;
• Investigar se o Autodialer Api esta falhando em enviar algumas tarefas de agendamento de
sessao de fotos para o servico de Autodialer;
• Criar logica no Autodialer Api para enviar telefones secundario e comercial do proprietario
quando disponıveis;
• Consertar bug: tarefas adiadas estao sendo consideradas tarefas novas pelo Autodialer Api
quando voltam a serem exibidas;
• Consertar bug: script de envio de batch de tarefas do CRM para o Autodialer Api nao envia
tarefas adiadas;
• Alterar o Autodialer Api para deixar de contar o numero total de tentativas de ligacao para
um lead e comecar a contar o numero de tentativas sem sucesso consecutivas;
• Habilitar integracao automatica de tarefas do tipo ”Lead com baixa prioridade” entre CRM e
Autodialer Api para testar fluxo completo.
29
7 Consideracoes finais
Esta secao tem como objetivo mostrar as contribuicoes do estagio para a empresa, para o
estagiario e as maiores dificuldades encontradas durante o perıodo retratado.
7.1 Contribuicoes
As atividades realizadas durante o perıodo de trabalho permitiram o amadurecimento profissional
do aluno, desenvolvendo praticas de trabalho em equipe e resolucao de problemas relacionados a
ciencia da computacao no contexto de um negocio. A experiencia pratica adquirida foi relevante,
tambem, para o desempenho de disciplinas na universidade, pois tornou mais facil correlacionar a
teoria exposta em disciplinas com sua aplicacao e aproveitamento em situacoes praticas.
Destaca-se como contribuicao para a formacao do aluno enquanto bacharel em ciencia da
computacao o aprendizado relacionado a aplicacao de boas praticas de codigo e o exercıcio de
conceitos de engenharia de software como manutenibilidade e planejamento. Enquanto que tais
conceitos sao ministrados na grade curricular obrigatoria do Bacharelado em Ciencia da Computacao,
a profundidade com que sao abordados estes conceitos e pouca e apenas com a utilizacao destes em
pratica foi percebida pelo aluno a assimilacao destes conceitos e o desenvolvimento da capacidade
de aplica-los em contextos praticos.
O aluno observa, tambem, a contribuicao do curso interdisciplinar para sua formacao profissional.
Ampliando sua visao crıtica para outras areas do conhecimento alem do nicho especıfico no qual se
especializa e facilitando a colaboracao com profissionais de diferentes areas, permitindo-lhe integrar
habilidades e conhecimentos de profissionais distintos para resolver problemas de forma conjunta e
eficiente.
7.2 Dificuldades
Conciliar o tempo necessario ao estudo das disciplinas com o tempo necessario ao trabalho e
concorrente estudo de conceitos especıficos para o desempenho das tarefas demandadas do aluno se
apresentou como a maior dificuldade para o aluno neste perıodo. Foi observada uma performance
significativamente menor em termos de conceitos obtidos em disciplinas apos o inıcio da atuacao
profissional do aluno quando comparada com todo o desempenho academico observado anterior a
este perıodo.
References
[1] Vincent Driessen. A successful git branching model. http://nvie.com/posts/
a-successful-git-branching-model/, note = Acessado em 02/12/2017, 2010.
[2] Henrik Kniberg. Squad health check model – visualizing what to improve. https://labs.
spotify.com/2014/09/16/squad-health-check-model, 2014. Acessado em 20/11/2017.
[3] Henrik Kniberg and Mattias Skarin. Kanban and Scrum-making the most of both. Lulu. com,
2010.
30
[4] Robert C Martin. Principles of ood. lınea]. Available: http://butunclebob. com/ArticleS.
UncleBob. PrinciplesOfOod.[Ultimo acceso: 29 Agosto 2016], 1995.
[5] Kjetil Moløkken-Østvold, Nils Christian Haugen, and Hans Christian Benestad. Using planning
poker for combining expert estimates in software projects. Journal of Systems and Software, 81
(12):2106–2117, 2008.
[6] Design Patterns and C Pattern. Model-view-controller. Microsoft Patterns & Practices,
http://msdn. microsoft. com/practices/type/Patterns/Enterprise/DesMVC, 2003.
[7] Frederick F Reichheld. The one number you need to grow. Harvard business review, 81(12):
46–55, 2003.
[8] Linda Rising and Norman S Janoff. The scrum software development process for small teams.
IEEE software, 17(4):26–32, 2000.
[9] Ken Schwaber and Mike Beedle. Agile software development with Scrum, volume 1. Prentice
Hall Upper Saddle River, 2002.
[10] Linus Torvalds and Junio Hamano. Git: Fast version control system. URL http://git-scm. com,
2010.
31
Universidade Federal do ABC
Bacharelado em Ciencia da Computacao
ESTAGIO SUPERVISIONADO III
Guilherme Rodrigues Salerno
Engineering Manager
Jesus Pascual Mena-Chalco
Professor Doutor Orientador
Rodrigo Martins de Oliveira
Aluno
Santo Andre – SP
26 de Marco de 2019