-
Tão importante quanto escrever
linhas e mais linhas de código
-
é você também fazer
a gestão do seu projeto,
-
e, ao término, você criar o seu produto
e entregá-lo documentado para o seu cliente.
-
Se você está pensando que hoje
você vai escutar mais um podcast
-
falando sobre linguagem de programação,
-
que seja do front-end
ou back-end, não, não é isso.
-
Nós vamos falar sobre a gestão,
-
que é a parte tão importante
na entrega de um software.
-
Eu sou o Rafael Ronqui, e estou
aqui com dois convidados.
-
Vou apresentar para vocês o Alexandre.
-
Olá, Alexandre, tudo bem? Como você está?
-
Tudo bom, Rafael?
-
Obrigado pelo convite.
-
Eu trabalho hoje como responsável
de operações Brasil da Softtek.
-
É um prazer estar aqui com você.
-
Show!
-
E aí, Eduardo, tudo bem? Como você está?
-
Se você puder apresentar para quem
está nos escutando, por favor.
-
Claro.
-
Primeiramente,
obrigado pelo convite, Rafael.
-
Bom, meu nome é Eduardo Floriano,
eu trabalho há dez anos na Softex,
-
sou responsável por algumas
verticais de negócio, pelo delivery,
-
então eu tenho que gerenciar
alguns projetos aí,
-
ou melhor, algumas centenas de projetos.
-
Então o desafio é bastante interessante.
-
Legal.
-
Então eu acho que a conversa
vai ser boa,
-
principalmente porque vocês têm
a vivência na prática, no dia a dia, né?
-
Falar aqui que nem é só
a visão, mas sim a vivência.
-
Para quem está nos escutando,
-
é legal setar o que é a gestão
de projetos, uma definição.
-
Lógico, né, vamos seguir
o PMI/PMBOK, início, meio e fim, né?
-
Fiquem à vontade,
Alê ou Edu, para definir.
-
Na visão de vocês, o que é
a gestão de projetos
-
dentro de desenvolvimento de um software?
-
Eu acredito que, antes de falarmos
da gestão de um projeto,
-
temos que olhar
para um cenário de governança...
-
Porque depende do tipo de projeto,
depende do tipo de necessidade,
-
e também depende do tipo de apoio
que você vai dar para a organização.
-
Você precisa estabelecer uma governança
-
sobre todo esse arcabouço
de projetos que temos hoje
-
implementando na prática.
-
Quando falamos de um projeto,
o projeto é uma atividade bem clara,
-
onde você tem um início,
um meio bem-definido, e o fim.
-
Então isso caracteriza o projeto.
-
O projeto é composto de uma fase inicial,
-
onde é necessário planejamento,
-
porque em cima do planejamento
você vai determinar esses recursos,
-
e esses recursos têm que estar ligados
à sua estratégia de governança
-
dentro da implementação
de qualquer tipo de projeto.
-
Terminou essa parte do planejamento,
definiu bem essas atividades,
-
tem que colocar os recursos, que é
a parte mais importante de um projeto.
-
Às vezes brincamos que temos
a metodologia, temos o processo,
-
mas apesar de dizerem
que 70% de um projeto
-
são a metodologia e os processos,
-
o mais importante é você ter
o colaborador daquele projeto
-
endereçando a execução
na prática do dia a dia.
-
Então, para mim, são esses
os elementos importantes
-
quando falamos de um projeto.
-
E aí você vai ter projetos
de diferentes dimensões,
-
diferentes tamanhos,
e diferentes propósitos.
-
Melhorias evolutivas, projetos do zero,
-
onde você vai fazer
um desenvolvimento completo,
-
uma implementação de um RP,
que é a característica de um projeto.
-
É diferente de um projeto
de desenvolvimento de software.
-
Você tem projetos ligados à parte
de manter a empresa funcionando.
-
Então você tem o dia a dia
da empresa que está funcionando.
-
Muita gente fala
de ambidestria da empresa.
-
Você tem um lado que precisa
desenvolver a empresa
-
e tem um outro lado
que precisa manter a empresa.
-
Então, como que você lida com isso.
-
Por isso eu falo que a governança
é um ponto importante
-
dentro das diversas estratégias que temos
-
para implementação
de um projeto na prática.
-
É legal ouvir isso aí de você, Alê,
principalmente porque essa brincadeira...
-
Eu sabia que você ia falar que esse
projeto não é só o início, meio e fim, né,
-
mas tem todo um contexto por trás.
-
Por exemplo, se uma empresa
quer implementar algo
-
sem fazer a gestão
de projetos, faz sentido,
-
até porque tem uma governança sobre isso.
-
Exatamente.
-
E aí você trouxe uma sopinha a mais,
porque às vezes você pega um aluno nosso,
-
que começou agora a desenvolver, e ele pensa:
"Só vou desenvolver um e-commerce".
-
E não é só isso.
-
Às vezes vai ter um RP
que você quer implementar
-
numa empresa de grande porte.
-
Exatamente.
-
Você trouxe toda essa sopa.
-
Edu, nós já estudamos
junto aí, nós brincamos que,
-
quem sobe muito a régua
complica para o próximo, né?
-
Não que você não consiga
sair bem dessa, né?
-
E aí? O que você tem para complementar?
-
O que é a gestão de projetos aí?
-
Bom, Rafa, ainda bem
que nós estudamos juntos.
-
Você me conhece um pouquinho aí.
-
E sorte a minha que ele deixou
pouca coisa para eu falar, né?
-
Ainda bem que eu trabalho com ele,
e é meu amigo também, né?
-
Então já nos conhecemos
há um bocado de anos.
-
Faz mais de 15 anos
que nós trabalhamos juntos...
-
Dez anos trabalhando juntos.
-
Então foi treinada essa conversa aí?
-
Não, não foi treinada.
-
Ele complicou. Ele sempre dificulta
um pouquinho a minha vida.
-
Só para saber como você se sai.
-
Pois é. Mas vamos lá!
-
Eu vou tentar simplificar um pouco mais
a abordagem que o Alexandre colocou,
-
que foi bem completa.
-
Mas eu colocaria o seguinte:
quem quer gerenciar projetos
-
tem que ter em mente que é
gerenciar crises e mitigar riscos,
-
ou seja, não vai ter projeto que você não vai
encontrar problemas para serem resolvidos.
-
Tem riscos então?
-
Quase nada.
-
- Quase nada?
- Quase nada.
-
- Só para saber.
- Quase nada.
-
Você acha que vai acontecer?
-
Monitora porque pode acontecer.
-
Então eu acho que o principal
ponto da gestão de projetos
-
é o monitoramento dos riscos,
a mitigação dos riscos,
-
e a habilidade de gerenciar problemas,
-
porque problemas vão acontecer.
-
Então, esses são os principais requisitos
que eu entendo no gerenciamento de projetos,
-
seja ele ágil, seja ele
uma metodologia tradicional,
-
que é cascata, "whatever".
-
Então, já que você falou isso,
de puxar outro tema,
-
nós tentamos definir
o que é gestão de projetos,
-
sem falar a tal gestão do PMI,
do PMBOK, ou ágil.
-
Será que conseguimos trazer essa
sopinha para a mesa da conversa,
-
essa quantidade de coisas?
-
Antes até de falarmos de metodologia,
-
entrar na abordagem métodos, né,
-
eu acho que temos uma pessoa
importante nesse cenário,
-
que é o gerente de projeto.
-
Em alguns contextos,
o gerente de programa.
-
O que é um programa?
-
Um programa é uma coleção de projetos
-
que serão executados em paralelo,
sendo administrados,
-
e que tem uma integração dentro
de um contexto maior dentro da organização.
-
Essa é uma figura extremamente
importante, o gerente,
-
Por quê?
-
Por mais que coloquemos metodologias,
métodos, processos,
-
um fator importante é o fator
humano dentro de um projeto.
-
E a gestão, aquele gerente que tem
-
a melhor habilidade na execução,
-
que consegue entregar um projeto...
-
Com qualidade, no prazo,
-
esse gerente geralmente tem uma habilidade
fantástica em gestão de pessoas,
-
que é um dos elementos importantes
quando falamos de projeto.
-
Porque no projeto, nós vamos ter lá
o escopo, vamos ter o método,
-
vamos ter os recursos físicos
e os colaboradores,
-
que são aqueles que executam o projeto,
-
e vai ter aquela pessoa que vai fazer
a orquestração de tudo isso,
-
que é o gerente de projeto.
-
Então, a habilidade do gerente de projeto,
para mim, 70% da habilidade do gerente,
-
está ligado ao relacionamento.
-
Como ele trata os colaboradores,
como ele agrupa e gerencia aquele time,
-
como ele traz o time, engaja aquele grupo,
-
para entregar bem aquele projeto.
-
E aí podemos falar que,
dentro de um cenário,
-
existem metodologias melhores
para determinado tipo de problema.
-
Existe o ágil, que vai atender bem
um determinado tipo de problema,
-
existem métodos em cascata, ou métodos
orientados à implementação de RP,
-
que geralmente estão
atrelados aos fabricantes.
-
São processos que o próprio
fabricante coloca
-
para você poder desenvolver, poder seguir,
-
poder trazer dentro de uma implementação.
-
Porque não é só
no desenvolvimento de software
-
que vamos ter uma gestão de projeto.
-
A gestão de projeto pode ter
em diversos ramos de atividade.
-
Até numa construção, que se pegarmos
a engenharia de software,
-
que ela é nova dentro desse
cenário de desenvolvimento,
-
a própria construção já
faz gestão de projetos,
-
faz a gestão da obra há muito tempo, aplica
métodos e também faz gestão de pessoas.
-
Enfim, gestão completa de um projeto.
-
E a área de tecnologia se apropriou
muito desses tipos de abordagem
-
de outras áreas em diversos...
-
Se falarmos em diversos
ramos da tecnologia,
-
nos apropriamos de alguma
área do conhecimento
-
e implementamos dentro do nosso processo.
-
E a gestão de projetos é isso,
desenvolvemos melhor
-
para dentro das nossas
atividades de engenharia de software.
-
Mas não é só um tipo de problema
que temos que resolver
-
quando falamos de gestão de projeto.
-
Vai depender da necessidade.
-
E aí você vai ter a metodologia que melhor
se adaptar a essa necessidade.
-
E, Rafa, até para complementar
o que o Alexandre colocou,
-
eu acho que vale a pena
colocarmos o viés do colaborador,
-
que é o participante do projeto.
-
Tem o gestor, mas também tem o executor,
vamos dizer assim, do projeto.
-
E tem os executores
que querem se tornar líderes,
-
querem se tornar gerentes dentro
das organizações, gerentes de projeto.
-
O que eu acho que é
superrelevante colocar,
-
e que corrobora
com o que o Alexandre colocou,
-
é primeiramente a questão da comunicação,
a questão de como lidar com pessoas.
-
Tanto a parte gerencial
quanto a parte dos colaboradores, dos...
-
Não vamos falar colaboradores.
-
Dos executores, propriamente dito,
dos desenvolvedores,
-
eles têm que ter hoje uma capacidade
de comunicação muito alta,
-
muito bacana, entre todos os membros
do time, inclusive com o gestor dele.
-
Então, se estamos falando de ágil,
estamos falando com o Scrum Master.
-
se estamos falando
de um projeto mais formal,
-
estamos falando de um gerente
de projeto, propriamente dito.
-
Então eu acho assim:
-
aqueles que buscam a liderança,
-
seja ele como gestor,
seja ele como Scrum Master,
-
tem que ter essa capacidade
de comunicação.
-
Eu digo que gerenciar é 90% comunicar
-
e 10% você trabalhar com cronogramas,
-
trabalhar com Kanban,
trabalhar com processos.
-
O principal é comunicação.
-
Além disso, ter atitude.
-
Para um projeto ser bem-sucedido,
se as pessoas que estão nesse projeto
-
tiverem atitude positiva,
atitude de realizar,
-
a grande probabilidade de sucesso
é enorme nos projetos.
-
Legal ouvir isso, Edu e Alê,
-
porque eu fiz um MBA em 2011,
"Gestão de projetos nas práticas do PMI",
-
e o meu TCC foi focado
na gestão da comunicação.
-
Que foi o que você falou, é
a habilidade de lidar com as situações.
-
Eu acho que foi o Ale que falou.
-
Nós já sabemos quais são os recursos,
qual o escopo, qual o custo previsto.
-
Antes de começar, você já tem
todo esse levantamento.
-
O projeto vai começar, quem vai fazer essa
maestria de tudo andar bem sincronizado?
-
É uma pessoa com habilidade de se comunicar,
de entender, de mapear o risco.
-
E é uma coisa que não
vem pronta, né, Ale? Né, Edu?
-
- Não vem pronta.
- Não.
-
Que legal o que vocês falaram, porque
quando nós trazemos para o aluno,
-
eles acham que, na primeira aula,
já vamos explicar o que é PI
-
e também o que é ágil
e Scrum, por exemplo.
-
Nós falamos: "Não, calma!
-
Vamos falar primeiro
que o projeto tem início, meio e fim.
-
Foi o que você falou.
-
Mas antes, vamos falar
de algumas habilidades
-
que você vai ter que ter
para participar do projeto.
-
E aí o aluno às vezes até fala para nós:
"Professor, você está muito acadêmico.
-
Solta o mundo
da vivência do profissional".
-
É por isso até que convidamos vocês.
-
E foi até provocativo.
-
Foi legal você quebrar.
-
Vamos falar do PMI, ou seja,
em cascata, e vamos falar do ágil.
-
O Ale falou: "Não, antes,
vamos falar dessa habilidade,
-
das coisas que acontecem
antes do projeto".
-
E vocês tocaram no tema de percentual dentro
do desenvolvimento de um projeto de software.
-
E os alunos às vezes acham que, 90% do tempo
alocado em um projeto, é código, por exemplo.
-
Vocês já quebraram
com alguns percentuais aí.
-
Importante assim, né...
-
Código dentro de um projeto é 30%...
-
Quando você coloca dentro uma métrica.
-
Porque se você não definiu bem seu escopo,
-
se você não realizou uma entrevista,
um levantamento, um mapeamento,
-
independentemente da prática
ou o método que você utilize,
-
ágil ou processos unificados, que seriam
mais voltados para a parte de cascata.
-
Então você tem a fase de análise...
-
Quando você faz a análise,
você tem que ir lá no seu usuário
-
entender o problema dele,
discutir com ele,
-
especificar o problema.
-
Depois que você especificou o problema,
pensar como vai resolver o problema.
-
E aí, antes de ir para o código, você ainda
vai ter que chamar um cara de arquitetura
-
e falar: "Cara, tem esse problema aqui.
-
Como vamos criar uma arquitetura
que suporte solucionar esse problema?".
-
Para depois você falar:
"Olha, pensei em tudo,
-
no escopo, na especificação,
na arquitetura.
-
Criamos uma arquitetura
para a organização
-
que pode ser implementada
de forma coerente".
-
E aí você vai falar: "Puxa,
agora vamos trabalhar o código".
-
Trabalhou código, aí você entra numa outra
parte, que é a parte da qualidade do código.
-
Eu tenho que testar, eu tenho que verificar,
-
tenho que fazer uma validação,
-
e depois ainda tem que ter um aceite
desse usuário para colocar em produção.
-
Então, um projeto não é código.
-
O código é uma parte dentro do projeto.
-
E se não você não pensar
as outras partes desse projeto
-
de forma coerente, a hora
que você implementar o código,
-
você pode desenvolver
algo que, lá na frente,
-
você vai ter problema de performance,
você vai ter problema de integração,
-
você vai ter problema
de lentidão da organização
-
porque não vai conseguir
utilizar a ferramenta.
-
Você pode ter problema de usabilidade
porque você não pensou
-
como o usuário vai utilizar
aquela ferramenta.
-
Então existem vários elementos importantes
-
antes de chegar no código.
-
Não é de agora que analisamos dessa forma.
-
Nós brincamos que hoje,
com a transformação digital,
-
todo mundo quer inovar,
-
sair desenvolvendo soluções
dentro das organizações.
-
Isso não é evento novo.
-
Na década de 1990,
-
existia um conceito chamado "reengenharia".
-
Todo mundo queria
redesenhar seus processos
-
e aplicar tecnologia
para resolver problema.
-
Na década de 1990.
-
Será que só mudou nome, ou gourmetizou?
-
O que você acha?
-
Nós temos alguns outros elementos
que a transformação digital traz
-
dentro desse cenário da reengenharia,
que, naquele tempo,
-
não tínhamos nem tantas ferramentas,
nem tantos métodos,
-
e ainda nem tínhamos descoberto
essa integração tecnologia/negócio.
-
Ainda estávamos
engatinhando naquele tempo.
-
Então foi o tempo em que se começou
a criar, desenvolver.
-
Foi quando veio a internet, e aí o boom
do crescimento tecnológico nas organizações...
-
Fora implementar a tecnologia, né?
-
Exatamente.
-
Só que hoje não é só código
que você tem que pensar,
-
porque você pode estar desenvolvendo
várias coisas dentro da empresa
-
e estar criando novamente
um problema que no passado criaram.
-
Durante a reengenharia,
existiam várias áreas
-
que começaram a querer desenvolver
-
as suas próprias ferramentas
internas nas áreas,
-
e onde contratavam um profissional de TI.
-
Eu posso falar que eu trabalhei
numa situação dessa,
-
onde eu trabalhava na área, não na TI,
-
para desenvolver diretamente
para aquela área
-
onde perdeu-se o controle da tecnologia
-
que estava dentro organização.
-
E quando veio o advento do ano 2000
-
e com a chegada dos RPs,
foi o gancho que teve.
-
Para quê?
-
Para que as empresas pudessem
se reestruturar, se reagrupar,
-
reagrupar e centralizar
novamente a tecnologia,
-
e pensar na arquitetura da empresa.
-
E se você pensar
que arquitetura corporativa
-
também começou na década de 90 para cá,
-
arquitetura corporativa tem
o primeiro grande artigo do Zackman,
-
que foi o cara que escreveu
a arquitetura corporativa,
-
pensando o quê? "Cara,
vamos estruturar a organização
-
e vamos criar uma arquitetura
que integre tanto a TI como o negócio,
-
para que você possa aí começar a olhar
-
e sair desenvolvendo
dentro da organização.
-
E o RP ajudou muito
nisso, porque o RP,
-
por ser um software que já tinha a sua
própria integração, tinha seus elementos,
-
já tinha todas as boas
práticas implementadas,
-
ajudou porque você já tem
a arquitetura pronta ali.
-
É legal você falar da RP, Ale,
-
até para quem está nos ouvindo aqui,
-
RP é um sistema que você
pode comprar, por exemplo,
-
empresas como a Tottus, como o SAP,
e você compra por módulos.
-
Se você quer a área de RH,
a área de logística,
-
você vai lá e compra, instala tudo
de uma vez, o que não é adequado,
-
ou instala por módulos.
-
Eu vivi uma vez uma mudança de cálculo
de frete numa multinacional,
-
que lá era o SAP.
-
Abriu-se um projeto para isso.
-
Fizemos um levantamento de escopo,
mapeamento, muitas horas alocado,
-
muitas pessoas para isso, e, no fim,
o desenvolvimento feito dentro desse SAP
-
foi de horas, tipo 10%.
-
Vamos supor que foram
500 horas de projeto.
-
Se foram 40 ou 50 horas
desenvolvendo, foi muito.
-
Mas qual foi a parte boa?
-
Se foi bem levantado, bem documentado...
-
Nem estamos falando de tipo de gestão.
-
Entrou em ambiente
de regression, pré-prod...
-
Aí subiu.
-
E olha que legal o que você falou.
-
E deu certo.
-
Mas aí você vai me falar:
"Qual que foi feito?".
-
Nós não fizemos nesse que talvez
fosse um pouquinho mais rápido, né,
-
que daqui a pouco tentaremos definir.
-
E aí, Edu, você acha que dá para falarmos
um pouquinho dessa definição?
-
Dá sim.
-
O Ale colocou um tema...
-
- Está apimentando, hein?
- Está apimentando.
-
Eu acho que até extrapolou
a gestão de projeto.
-
Ele colocou um tema estratégico, né,
-
falando de arquitetura corporativa...
-
- Que as coisas têm que andar juntas, né?
- Juntas, né, TI e negócio.
-
Já colocou um plus dentro da conversa.
-
Dificultou mais, né,
mas eu acho que agrega mais
-
para todos nós aqui.
-
E aproveitando, Edu e Ale, vocês
ajudam quem está nos escutando
-
a saber que, o que o Rafa
e os outros professores trazem,
-
não é coisa acadêmica.
-
Obrigado!
-
Isso não foi treinado.
-
Você foi e contou a verdade aí.
-
Não, não, é isso mesmo.
-
Não teve script prévio.
-
Não teve script prévio, não
teve treinamento nenhum, tá?
-
- Saiu na raça aqui.
- Fluido.
-
- Fluido.
- Que bom.
-
Se não for, eu faço
disclaimer aqui, tá bom?
-
Não, não, não. Está fluido.
-
- Pode ficar à vontade aí.
- Vamos lá.
-
Eu acho que é importante...
-
Como o Ale, comentou,
como você comentou,
-
o código é uma parte
importante e significativa.
-
Mas antes de falar disso,
-
é também tranquilizar o pessoal
que está nos escutando.
-
Não fiquem preocupados ou com medo de entrar
na área de gestão de projeto, em projetos,
-
mas em qualquer outra profissão, qualquer
outra atuação da sua atividade profissional,
-
vão existir desafios.
-
Eu vou falar para vocês que, projetos,
para quem gosta de desafios,
-
é um excelente ambiente para se trabalhar.
-
Em projetos, vão existir diversos
tipos de desafios a serem superados.
-
E eu gostaria de colocar, Rafa,
o seguinte ponto:
-
estamos falando muito
de metodologia, de processo,
-
da questão estratégica dentro da
organização, de mitigação de riscos.
-
Eu falei um pouquinho lá atrás
de gestão de problemas.
-
Mas imagine assim: nós ainda
não falamos do nosso...
-
Nós falamos que tem escopo, prazo, custo.
-
Mas imaginem vocês dentro...
-
Parece simples o projeto, né?
-
Mas imaginem vocês
que o executivo separe um valor,
-
um montante de dinheiro,
o budget, de 100 mil reais...
-
Eu vou colocar um valor hipotético aqui.
-
Supondo que é alto, né?
-
É, supondo que é algo, tá,
-
mas às vezes são projetos de milhões.
-
Em SAP, nós falamos em milhões.
-
Mas vamos colocar
um número aí de 100 mil reais.
-
E que, durante o projeto,
você identifique situações
-
em que você não vai conseguir
atender àquele escopo,
-
e por não conseguir atender àquele escopo,
-
ao invés de custar 100 mil reais o seu projeto,
-
que você já informou à sua presidência,
-
você vai ter que informar
que ele vai custar 200 mil reais.
-
Olhe a complexidade de informações
-
que o gerente do time que está
sendo gerenciado deverá ter
-
para convencer o seu
presidente, o CEO, que seja,
-
desse pequeno dobro de valor.
-
Então, são situações complexas como essa
-
a serem administradas dentro do projeto.
-
E aí existem aqueles velhos costumes.
-
Vamos identificar quem são os culpados, né?
-
E, na verdade, não funciona assim, gente.
-
Quando um projeto falha,
-
existem percentuais
de falhas em diversos locais.
-
Não é só um local que falha.
-
São diversas falhas que aconteceram,
e aconteceu uma falha grande.
-
Então tem que se trabalhar a causa raiz,
identificar essas causas,
-
os efeitos que elas geraram,
consequentemente os impactos,
-
trabalhar planos de ações,
e contra-argumentar com o presidente
-
e pedir mais dinheiro, o que não é fácil,
-
não é fácil.
-
É uma situação bem complexa,
e acontece no dia a dia.
-
A responsabilidade que tem um gerente
nesse sentido é bastante alta, Rafa.
-
Eu gostaria de colocar esse ponto
porque eu acho que vale.
-
Eu achei legal porque está vinculando
a parte de levantamento de escopo, né?
-
Se você está fazendo a gestão,
fez a previsão de 100 mil,
-
mas você faz ali um levantamento
-
que o budget não reflete
devido ao que você levantou...
-
"Temos esse budget, mas
baseado em todas as entrevistas,
-
o que nós conversamos e levantamos
em x dias na empresa, não vai atender.
-
Não é que não queremos
fazer o gourmet para vocês.
-
É que não vamos entregar
conforme a necessidade".
-
Aí eles tentam muitas vezes
diminuir o escopo.
-
Aí às vezes você pode falar
que é melhor nem fazer, né?
-
Às vezes é melhor nem fazer.
-
Mas se tiver bons argumentos,
-
que seria essa documentação,
essa conversa, tudo que você levantou...
-
Não foi você que levantou,
não foi você que criou.
-
Foi a equipe da empresa que passou
toda essa parte de escopo, né?
-
E aí vai muito na linha
do que o Ale comentou,
-
da parte estratégica também, financeira.
-
Um projeto tem que trazer
algum resultado para a empresa.
-
Normalmente é alguma
otimização processual,
-
alguma otimização da produção,
venda, aumento de venda,
-
ou seja, que traga algum benefício tangível,
normalmente financeiro, para a organização.
-
Se você conseguir provar que,
de 100 mil para o projeto
-
passou para 200 mil,
mas vai ter tais ganhos,
-
é uma maneira de você contra-argumentar.
-
O famoso ROI.
-
É isso aí.
-
Vocês devem defender direto projetos,
principalmente na parte de consultoria, né?
-
Essas conversas devem
ser bem agradáveis, né?
-
Para nós, a defesa do projeto
está mais ligada na abordagem
-
e na estratégia de entrega,
de como vai ser desenvolvido.
-
Esse convencimento
de que o projeto vai dar retorno,
-
ou o projeto vai ter
um benefício para a empresa,
-
geralmente parte da própria empresa,
parte das pessoas que estão ali
-
integradas no dia a dia do negócio,
-
e que, dentro de uma solução,
ou dentro de uma estratégia,
-
ou dentro de uma análise
de problema que eles identifiquem,
-
eles vão trazer uma solução
que vai envolver tecnologia,
-
e, dentro disso, eles vão aí abrir
para nós, como consultoria,
-
oportunidade de participar
de um processo de venda da solução.
-
Muitas vezes nós ajudamos, né, Ale?
-
E muitas vezes nós os ajudamos
a construir a defesa.
-
Geralmente quem defende mesmo
é a própria organização,
-
os próprios gestores da organização,
que, dentro dessa estratégia,
-
vão levar para o board ou para um comitê
-
para apresentar quais seriam os projetos
-
e quais benefícios eles
trariam para a empresa.
-
Mas geralmente são vocês, de consultorias,
-
que os alimentam com essas
informações para eles levarem...
-
- Para o board da empresa, né?
- Às vezes alimentamos...
-
Participamos de um projeto de...
-
- Levantamento.
- Um projeto mais de consultoria.
-
Não seria nem um projeto
de desenvolvimento nem de análise,
-
é um projeto mais consultivo,
-
e aí nós os ajudamos
a desenhar a solução, a ideia,
-
e como resolver o problema.
-
Mas quem vai defender isso de fato
-
vai ser a própria empresa,
-
os próprios gestores perante a empresa.
-
É legal o outro tema
que você trouxe aí, Ale.
-
Acabamos, falando de ROI, mas nem sempre
um projeto de desenvolvimento de um sistema,
-
seja de implementação de um SAP,
-
é só voltado para a parte
do retorno financeiro.
-
Às vezes você está fazendo uma implementação
para mitigar risco fiscal,
-
ou a operação parar,
que indiretamente, ali por trás,
-
corre a parte financeira, né?
-
E aí, ter essa visão de processo,
-
e até mesmo essa parte fiscal,
ainda mais brasileira, é bem difícil, né?
-
E é importante também
olharmos que às vezes um projeto
-
pode ser uma evolução tecnológica.
-
Muitas empresas demoram
para investir em tecnologia.
-
E um dos problemas
que as empresas têm hoje
-
é a obsolescência tecnológica,
tanto de hardware como de software...
-
Porque é um ativo que,
muitas vezes, já está...
-
Não tem uma reposição
dentro da organização.
-
Na parte sistêmica e de software,
-
não tem uma evolução
daquela ferramenta,
-
a evolução da própria ferramenta
para uma nova tecnologia.
-
E aquela empresa acaba ficando
com um parque tecnológico obsoleto.
-
Muitas empresas hoje que querem ir
para um processo de transformação digital
-
encontram dificuldade
porque a sua arquitetura
-
ainda é uma arquitetura monolítica.
-
Então ele precisa se atualizar
em muitas coisas ainda
-
para poder começar
a trazer novos elementos
-
de inovação, de transformação,
para dentro do negócio.
-
Então, esse é um ponto importante que tem
que ser pensado dentro das organizações.
-
É legal você falar, porque às vezes ele
quer implementar uma tecnologia.
-
Mas para implementar aquela
nova tecnologia com aquele projeto,
-
ele tem que tomar outras ações antes...
-
- Para mudar sua organização.
- Ele tem que redesenvolver o seu sistema...
-
Para que esse sistema possa
integrar com a nova tecnologia,
-
ou criar uma situação ali de convivência,
-
onde você convive com a sua situação atual
-
e o que você está trazendo para o futuro.
-
Só que sempre tem uma perda né,
-
porque tem a própria
obsolescência da tecnologia
-
e você acaba perdendo algumas
vantagens, dependendo da tecnologia.
-
Então, é isso que também é
importante olharmos nesse cenário
-
quando vamos falar
de criar novos projetos,
-
fazer inovação,
desenvolver novas soluções.
-
E até pegando isso, quando
falamos no mundo corporativo, pessoal,
-
não é o país das maravilhas, tá?
-
As pessoas que estão iniciando
agora, vocês que estão iniciando agora,
-
muitos na área, vão encontrar...
-
"Pô, vou lá, chegar e desenvolver?".
-
Não.
-
Você vai desenvolver, você
vai chegar a desenvolver,
-
você vai entender o projeto,
-
mas você vai ter que seguir
algumas regras e padrões,
-
inclusive de conformidade.
-
Os requisitos legais, né?
-
Hoje nós temos o LGPD,
-
que são as políticas de Cyber Security...
-
Implantar diretamente no código, né?
-
Pois é. Você tem as questões
que você vai ter que seguir.
-
Não é sentar-se lá simplesmente
e desenvolver e está pronto.
-
Não. Você vai ter uma documentação,
-
você vai ter que seguir essa documentação,
-
alguém vai validar, vai
fazer um peer review...
-
"Pô, o que você está fazendo
está certo mesmo?".
-
Ou ter ferramentas para validar
se aquilo que você está desenvolvendo
-
está em conformidade
para garantir acessos indevidos,
-
para não ter violação de dados.
-
Então, assim...
-
Não existe país das maravilhas.
-
Tem que colocar
a realidade aqui, certo, Rafa?
-
Tem que colocar... Pode colocar, né?
-
Pode. Você até trouxe um ponto,
-
porque às vezes o nosso aluno,
quando corrigimos uma atividade...
-
"Pô, Rafa, você me tirou 10% da nota porque
eu não segui a boa prática no código...",
-
ou não fez a identação do código,
ou não comentou código.
-
Estava escrito no exercício que,
se você entregar funcionando,
-
mas não seguir a boa prática,
perde tais pontos.
-
Aí ele pergunta por quê.
-
Porque dentro de uma governança,
dentro de uma gestão de um projeto,
-
dentro uma empresa, você tem que segui-la
porque você não está trabalhando sozinho.
-
Mesmo que estivesse trabalhado
sozinho, você deixa esse código
-
e alguém provavelmente
vai fazer reengenharia depois,
-
ou vai ter que analisar
para criar um novo sistema.
-
E o exemplo clássico, né?
-
Porque, por exemplo,
falamos de programação, né?
-
Eu já fiz várias entrevistas na época,
-
quando eu ainda cuidava dessa
frente de desenvolvimento.
-
Eu perguntava: cara,
o que acontece se você fizer
-
um "select*" dentro da base?
-
Será que trava essa pergunta?
-
Você vai fazer?
-
Não, não faz não, espera aí!
-
Aí o cara olhava e falava:
"Mas que pergunta é essa?"
-
Você sabe o impacto que você
tem em colocar um select*?
-
Sem o wherezinho para travar, né?
-
Pois é.
-
Porque se você colocar isso no seu código,
-
você vai ter o impacto lá na frente.
-
No quê? Em performance,
-
dependendo do tipo de dado
que você está acessando,
-
do tipo de tabela que você está acessando.
-
Então não é uma boa prática você
utilizar isso dentro do seu código.
-
E geralmente as empresas
têm os seus manuais
-
de boas práticas de programação,
regras de programação.
-
Então são perguntas
que eu fazia na entrevista
-
para já mapear o quanto de habilidade
aquele desenvolvedor tinha
-
para desenvolver
determinado tipo de código,
-
ou para onde eu iria direcioná-lo
para o desenvolvimento.
-
Você falou de um ponto que eu vivi.
-
Eu trabalhei numa multinacional
e comecei como desenvolvedor,
-
e aí eu estava atendendo a área de vendas,
-
a área de vendas de uma multinacional
com uma base muito alta,
-
e aí veio escalado da alta gerência
-
um e-mail falando
por que temos que formar,
-
qual é o range de clientes
que queremos enxergar.
-
Eu quero clicar e baixar
toda a base de clientes.
-
Por sorte, eu, como desenvolvedor júnior,
-
tive a maturidade de perguntar
ao meu coordenador técnico:
-
olha, veio escalado da alta
gerência de vendas.
-
Ele não tem culpa.
-
Mas eu entendo que, se eu
atender e tirar o "where" daqui...
-
Foi o que você falou,
tira ali rapidinho, sobe em teste,
-
aí não vai dar impacto
para subir para a produção.
-
Só que, se eu subir isso daqui, o outro
usa o relatório, se o sistema não cair.
-
Até explicar para essa pessoa,
esse executivo da área de vendas,
-
que, se eu fizesse isso, ia atrapalhar
a performance, ia dar stress.
-
Foram falar com ele, e ele falou:
"Então comprem um servidor novo".
-
Nem se você comprasse ia resolver,
ainda mais há um tempo.
-
Bem interessante essa fala.
-
Mas, por alguns segundos,
eu, como um júnior,
-
eu vou ser bem transparente,
pensei em fazer.
-
Na hora que veio escalado,
quase levando uma bronca,
-
eu, como desenvolvedor, falei:
espera aí, isso não faz sentido!
-
Sorte que eu consultei.
-
E isso conta como maturidade, né, Rafa?
-
Existem passos, né?
-
Você pode ter uma excelente lógica
de programação, que é fantástico, né?
-
- "Select*" lá, deixa rolar...
- Vai embora, vai embora!
-
Vai travar tudo ali.
-
Mas você mede a senioridade
inclusive sobre isso.
-
Mas que impactos
que eu posso ter fazendo isso?
-
Então são etapas que você
acaba adquirindo
-
não somente com o aprendizado
da linguagem de desenvolvimento,
-
mas com a experiência, a vivência
que você tem dentro dos projetos.
-
"Pô, eu fiz isso aqui, eu vi isso aqui...
-
Isso aqui pode impactar.
-
Pô, se eu fizer isso aqui,
eu não sei o que pode acontecer,
-
mas deixe-me fazer uma POC aqui
para ver se pode gerar impacto".
-
Mas eu vou te falar, Edu, que,
na pressão, a hora que vi o e-mail...
-
- A vontade era fazer.
- Tem a pressão, né?
-
Eu juro para vocês.
-
Até hoje eu lembro.
-
Serviu de experiência, crescimento mesmo.
-
Eu falei: espera aí, eu o atendo, mas
o meu coordenador técnico aqui...
-
Vai dar ruim.
-
Aí eu falei: Sérgio, só uma pergunta:
-
se ele quer fazer, eu faço,
mas vai parar tudo.
-
"Ainda bem que você não fez, meu amigo.
-
Me dá esse problema que eu
vou falar com essa pessoa."
-
Não foi fácil.
-
Ele teve que lidar
com uma situação de conflito.
-
Mas esse é o tipo de desafio
que um gerente tem.
-
Determinar, identificar quem
são esses colaboradores
-
que vão trabalhar com ele,
-
qual o nível de senioridade,
-
que tipo de desenvolvimento é melhor
para cada um poder desenvolver.
-
Hoje nós falamos que tem
o front-end e o back-end.
-
Isso já é um tipo de segregação
de função para o desenvolvedor.
-
Tem profissionais que vão conseguir
fazer melhor o front-end,
-
tem profissionais que vão
fazer melhor o back-end,
-
tem profissionais que conseguem
fazer as duas pontes.
-
Mas, no passado...
-
Hoje, por exemplo, você tem ferramentas
que te ajudam a fazer auditoria no código,
-
fazer uma inspeção de código.
-
No passado, ainda não tinha.
-
E aí?
-
- Os legados estão aí, né?
- Aí é onde...
-
Entravam as metodologias,
-
e que em algumas dessas metodologias
tinha uma etapa importante,
-
que era fazer um peer review no código,
-
E aí, com a evolução da metodologia,
com a evolução das ferramentas,
-
com a evolução das tecnologias,
isso facilitou muito a vida.
-
Prega o desenvolvimento em pares, né?
-
Não seria um peer review,
mas é basicamente isso...
-
- Desenvolvimento em pares.
- E tem gente que não quer...
-
Trabalhar nessa porque fala
que é muito estressante.
-
Por que estressante?
-
Para mim, é até uma segurança.
-
Toda vez antes de eu mandar esse código
para a QA, Quality Assurance , por exemplo,
-
passa pelo meu parceiro
de revisão, que é o Edu,
-
para mim, é uma segurança.
-
Se eu sei desenvolver, não é um problema.
-
Com certeza!
-
E eu vou dizer uma coisa para você.
-
Hoje, a questão de código está tão....
-
A questão de tecnologia está tão crítica
-
que, para mim, nós deveríamos
ter responsabilidade civil
-
sobre os códigos que desenvolvemos.
-
Penal e civil, né?
-
Ai ele já pegou...Tá vendo?
-
Por quê?
-
Porque hoje você desenvolve
software para avião, para carro.
-
Você desenvolve software para...
-
Né?
-
Só que você não tem...
-
- Responsabilidade sobre aquilo lá.
- Responsabilidade...
-
Sobre aquilo que você desenvolveu.
-
É diferente de você...
-
Do médico.
-
O médico não tem...
-
- Ele vai pedir dez consultas, dez exames...
- O CRM dele?
-
Ele assina por aquilo ali.
-
Se o seu paciente tiver algum problema,
ele é responsável sobre aquilo.
-
Para você fazer uma construção, não
tem um engenheiro que assina embaixo,
-
e vai o CREA dele naquele documento?
-
Então eu acho que falta
na área de tecnologia
-
algo nesse sentido também,
-
para que as pessoas criem mais consciência
quando desenvolverem um software
-
ou quando criarem um código,
desenvolverem um código,
-
para algum programa, algum sistema.
-
Você não está falando
em burocratizar, né, Ale?
-
- Não, não é burocratizar.
- Não é isso?
-
É trazer a responsabilidade
-
para não ter esse tipo de coisa
que você acabou de dar o exemplo.
-
"Ah, não, eu não quero trabalhar
-
porque vão fazer uma verificação
sobre o meu trabalho."
-
Não, não estou fazendo
uma verificação sobre o seu trabalho.
-
Eu estou fazendo um peer review para garantir
que você não vai ter um problema
-
na hora que você implementar esse sistema.
-
Porque às vezes você não viu
o que fizeram. Não é por mal.
-
O seu amigo vai dar um toque para você
de como melhorar a performance.
-
Porque você tem código hoje,
programas e softwares,
-
desenvolvidos em várias situações.
-
Numa hidrelétrica, você tem software,
-
você tem software no avião,
você tem software no automóvel...
-
- Na área da saúde, na área de ensino.
- Você tem software na área da saúde.
-
Hoje tem software em tudo quanto é área...
-
Do conhecimento.
-
Então, assim, você também
deveria ter responsabilidade
-
sobre aquele código que você escreve.
-
É legal quando criamos um podcast
-
em que vocês conseguem trazer esse
contexto para quem está nos escutando.
-
Porque se você achava que você ia ter
uma resposta do que é um projeto,
-
de qual o melhor, a gestão de projeto ágil
ou em cascata, ou PMI, ou PMBOK que seja,
-
em nenhum momento você iria dar
uma pausa e fazer uma anotação breve.
-
Se é uma aula, às vezes
o professor faz uma definição...
-
"Anota aí que vai cair na prova, tá?".
-
A ideia aqui era para trazer na mesa mais
coisas aí, como o Ale e o Edu trouxeram.
-
E não é para te deixar confuso.
-
Na verdade, é para você entender que,
quando você faz uma gestão de projeto,
-
não é só olhar o seu documento,
pedir para alguém codar
-
80% do tempo do projeto, e está entregue.
-
Se for ágil, melhor ainda
porque vai fazer a qualidade.
-
Nem sempre isso é uma verdade.
-
Se for PMA... "Ah, é um escopo conhecido".
-
Depende, você negociou com o seu cliente?
-
Então esse era o tópico da nossa conversa.
-
E aí eu trago para uma última, Ale e Edu.
-
Fiquem à vontade para quem
quiser ser o primeiro.
-
Para fecharmos, o que você deixa de dica
para quem está nos escutando?
-
Às vezes os alunos que estão nos escutando,
alunos nossos da graduação,
-
já têm experiência, mas começam
principalmente na área de desenvolvimento.
-
Eu comecei, e acredito
que vocês também, né?
-
E aí? Larga a área de desenvolvimento
porque é só 30%?
-
O que vocês deixam de dica
para quem está nos escutando?
-
Uma frase de fechamento
de cada um, por favor, um contexto.
-
Uma dica para quem é desenvolvedor
-
ou que está na carreira
de engenharia de software,
-
tanto em teste,
desenvolvimento, análise, é:
-
migrar para um cargo de gestão,
-
é o que nós colocamos aqui,
você vai lidar com pessoas,
-
pessoas do projeto,
pessoas da sua empresa,
-
usuários, e o cliente,
os gestores do cliente.
-
A pessoa tem que avaliar
o quanto ele está se desenvolvendo
-
em relação ao relacionamento
com as pessoas, porque isso é fundamental.
-
É mais até que metodologia, é mais
até que saber codificar ou não.
-
Então ele tem que definir bem para onde
ele quer direcionar a carreira dele.
-
E hoje nós sabemos que não é preciso
-
tomar uma decisão de ir
para uma carreira de gestor.
-
Tem pessoas que continuam
na trilha técnica
-
e se transformam em especialistas,
-
se transformam em técnicos,
-
em líderes técnicos dentro das equipes,
-
se transformam em excelentes arquitetos,
-
e não necessariamente precisam
estar num cargo de gerente de projetos
-
ou num cargo de Scrum Master, enfim.
-
Por quê? Porque grande parte desse trabalho
é a habilidade de trabalhar a equipe,
-
a colaboração do time,
para que se consiga,
-
naquele produto que você se pensou,
-
chegar ao final com ele concluído,
-
que entre em produção
e o cliente fique satisfeito,
-
ou a empresa fique satisfeita,
com aquilo que foi feito.
-
Então, esse é o ponto importante
que tem que ser avaliado.
-
Não pensar só em código ali?
-
Não pensar só em código.
-
Se ele tem a pretensão
de ser um gerente,
-
de ir para uma carreira de gestor,
-
virar um diretor, crescer
para um lado mais executivo,
-
ele vai ter que analisar e ver
qual é o gap que ele tem
-
em relação à parte humana.
-
A soft skill ali, né?
-
Exatamente.
-
Eu queria falar isso, Rafa,
eu estava guardando aqui.
-
Mas pode terminar, Ale.
-
Ele subiu a régua ali de novo!
-
- É, então, ele sobe a régua.
- "Ah, eu soltei a palavrinha do soft skill..."
-
Deixa a dica aí então, Edu.
-
Deixa a dica para o pessoal.
-
O que eu ia falar é o seguinte: eu acho
que muitos dos alunos, alguns, pelo menos,
-
já tenham escutado, né,
que, muitas vezes,
-
as pessoas são contratadas
pelos hard skills.
-
O que são os hard skills?
-
São os conhecimentos técnicos.
-
Então, quando você fala
em engenharia de software,
-
você está ganhando conhecimento
técnico, que são hard skills,
-
porém, elas são demitidas pelo soft skill.
-
O que são os soft skills?
-
É a capacidade de comunicação,
é a capacidade de colaboração,
-
de como trabalhar em equipe.
-
Então, a dica que eu
dou é: hard skill...
-
Você vai ser contratado pelo hard skill,
por isso que temos que estudar.
-
Nós aqui, nós três aqui, estudamos muito.
-
Fazendo Doutorado agora, né, Rafa?
-
O Ale fazendo Doutorado,
e eu parei no Mestrado.
-
Agora, quem sabe, eu vou no Doutorado.
-
Vamos ver.
-
Eu acho que vou.
-
Mas é superimportante
trabalhar essa frente de soft skill,
-
independentemente da carreira,
-
se é carreira técnica
ou se é carreira gerencial.
-
E para quem quer ser líder,
-
uma dica que eu digo é: liderança
não é dada, se é conquistada.
-
Não é necessário você ter
um cargo de gestor
-
para você se tornar um líder
dentro da sua equipe.
-
A própria equipe consegue
reconhecer o líder
-
quando ele existe dentro
desse grupo de pessoas.
-
Então, gente, não precisa esperar
virar gerente para se tornar líder.
-
Normalmente é o contrário.
-
Você vai se tornar um líder para depois
você se tornar um gerente,
-
ou um executivo, ou um cargo de gestor.
-
Então vai pra cima sem medo de ser feliz.
-
Ousadia com responsabilidade...
-
E bora agilidade, né?
-
Show!
-
Eu gostaria de agradecer
a sua presença, Ale,
-
a liberdade que você teve de trazer
os temas, de uma maneira até polêmica.
-
Edu também.
-
Essa liberdade com certeza
soma para os nossos alunos.
-
Sempre falamos: "Vá além
dos nossos materiais
-
que deixamos disponíveis,
onde o professor ensina.
-
Escutem também os profissionais
de mercado que nós trazemos
-
para vocês verem que,
o que cobramos às vezes,
-
não é porque somos chatos
na hora de uma correção,
-
e sim porque queremos que você entenda
que nem sempre o mercado trabalha
-
como está a cartilha
do ágil, por exemplo, tá?".
-
É isso aí!
-
Edu, eu também gostaria
de agradecer a sua presença,
-
e, da mesma forma, a liberdade
que você teve para trazer os temas,
-
e até mesmo somar para os nossos alunos.
-
Obrigado!
-
E você, aluno, deu para entender que,
para você fazer uma gestão de projetos,
-
não basta apenas
você saber fazer a gestão,
-
mas também tudo que tem envolvido.
-
Eu vou ficando por aqui,
e até uma próxima.