Ricardo Vercesi
Tutor

Comecei como fotógrafo, vindo das artes. Descobri a internet em 1995 e desde então não tenho feito outra coisa. A possibilidade de colocar online uma fotografia minha e tê-la disponível mundialmente no mesmo momento fascinou-me. Daí à posição em que me encontro hoje tem sido um percurso com altos e baixos, como aliás é natural neste meio. Fiz um pouco de tudo nas TI, mas apaixonei-me pela gestão de projetos e pela web logo de início.

Como autodidata procurei sempre aprender com os melhores exemplos e nas melhores empresas. Estudei várias linguagens e tecnologias nas empresas por onde passei. Tive a sorte de aprender com os melhores. E posso dizer com algum orgulho (e talvez pouca modéstia) que tive a oportunidade e honra de trabalhar nas maiores empresas de media de Portugal. Isso deu-me uma perspetiva muito completa dos diversos modelos de gestão praticados – ou não – no panorama nacional. Penso que isso influenciou a minha decisão de me focar mais na gestão de projetos e cada vez menos no desenvolvimento. Se bem que ainda desenvolva com regularidade.

Há uns anos comecei a dar formação na área das tecnologias web e uma nova paixão surgiu. Assim, hoje em dia partilho o meu tempo entre projetos de consultoria e desenvolvimento, como freelancer, dar aulas e estudar.

Os meus dias são normais. Saio de manhã para o escritório e passo lá 8 a 10 horas. Depois de sair, se não tiver aulas, procuro desligar e dedicar-me à família e a outras coisas não relacionadas com trabalho. Mas, como sempre, há dias em que temos que nos sujeitar e trabalho pela noite dentro. A rotina diária consiste em reservar meia-hora no início do dia para responder a emails e analisar o que foi feito no dia anterior, assim como ver a minha lista de tarefas para o próprio dia. No final do dia de trabalho habitualmente reservo 15 minutos para fazer a lista de tarefas para o dia seguinte. Pelo meio tenho sempre a parte comercial de um freelancer, assim como a parte de cobrador. São estas que habitualmente quebram o ritmo, mas acabam por ser necessárias. De resto, eu diria que um típico dia de trabalho quase que cai na banalidade.

A (falta de) definição de escopo, ou de âmbito, na minha opinião é a principal causa de insucesso nos projetos. Quando os stakeholders / clientes não têm ainda uma visão definida do que querem ou quando não conseguem traduzir essa visão em requisitos funcionais, estamos a dar um “tiro no pé” logo de início. Por outro lado, se quem define o âmbito não tiver o mínimo de conhecimento técnico, podemos correr o risco de se estar a planear para um projeto que não é exequível num determinado timeframe ou que caiba num orçamento. Mesmo em fase de pré-venda, quando um account está nos primeiros contactos com o cliente e este lhe explica a sua visão genérica, deveria haver um acompanhamento por alguém com know-how, de modo a que o âmbito do projeto seja definido já tendo em consideração a tecnologia em que vai ser desenvolvido.

Infelizmente vemos com demasiada frequência projetos que são vendidos sem sequer haver feedback da equipa que os vão desenvolver. Isso leva a que se venda tudo e mais alguma coisa que depois se verifica não ser possível concretizar, seja por impedimentos técnicos ou orçamentais.

Adicionalmente, aquela que é talvez a falha maior na definição de âmbito é a tendência de o alterar ao longo de um projeto. O chamado “Scope Creep”. Caso se decida efetuar alterações de âmbito, todos os aspetos irão ser afetados: timing, orçamento, impacto no negócio, risco, etc.. O âmbito de um projeto deve ser congelado no início de um projeto. Para tal, a definição de âmbito deve ser efetuada com o máximo rigor possível.

O único conselho que posso dar é: “Não tenham receio em gastar algum tempo nesta fase. Irão poupar muito mais do que se não o fizerem.”

Nos métodos tradicionais, o projeto é sequencial, seguindo os passos típicos de análise, planeamento, desenvolvimento, testes e entrada em produção. Ora, imaginemos que um projeto estimado em 6 meses. Chegamos ao final do tempo, estamos preparados para colocar em produção o nosso projeto e detetamos um problema com o âmbito do mesmo. Corremos o risco de perder 6 meses de trabalho (e dinheiro).

Os métodos ágeis vieram propor alternativas ao fomentar a entrega contínua e incremental de funcionalidades. Assim, o risco – sempre presente – de alterações de âmbito é bem-vindo porque é mais facilmente enquadrável. E, como se costuma dizer: “O melhor das metodologias ágeis é que conseguimos saber se um projeto está a falhar ao fim de duas semanas.”

Como indiquei anteriormente, a entrega continuada e incremental de funcionalidades. Isto possibilita a que um projeto esteja em evolução constante, que o cliente veja o seu projeto ganhar forma e que as equipas se mantenham motivadas. Para além disso, as equipas ágeis não possuem a figura de um gestor de projetos, caindo a gestão de tarefas nas próprias equipas, responsabilizando-as e levando a que haja um “ownership” comum do código e do projeto. Concluindo, sem estar a enumerar todas as diferenças, o principal nas metodologias ágeis é a tentativa de eliminar entropia e minimizar o impacto da mudança, abraçando-a como parte natural do processo.

Esta tem sido uma daquelas questões que tenho mais dificuldade em responder. Se formos seguir as regras à letra, teríamos que nos limitar a equipas de desenvolvimento até 9 pessoas, com sprints de 2 a 4 semanas, pair programming, etc. A verdade é que os fundamentos das metodologias ágeis nasceram na sua maioria em fábricas de produção em cadeia (Lean, Kanban, por exemplo). Ainda assim, eu diria que os projetos ágeis são mais adequados a projetos com equipas de dimensão relativamente pequena (pessoalmente gosto de equipas até 7 pessoas) e cujo grau de necessidade de mudança e adaptação seja superior.

Primeiro, ter noção que num ambiente ágil, a figura de gestor de projetos como a conhecemos não existe. Depois, do ponto de vista prático, deveria pegar num projeto de baixo risco com uma equipa reduzida e usá-lo com projeto piloto. É fundamental que toda a empresa consiga entender as práticas e fundamentos da metodologia. Caso contrário, nunca irá resultar. Finalmente, estudar a fundo a(s) metodologia(s) que quiser implementar. E depois adaptar isso à realidade da sua empresa e dos projetos.

Sem dúvida. Embora os conceitos já existam há mais de 20 anos, hoje em dia as metodologia ágeis tomaram a dianteira com o crescimento do desenvolvimento de projetos digitais, principalmente com Scrum e XP (Extreme Programming), mas também com Kanban, que muitas das vezes é utilizado sem se saber que se está a usar Kanban. Esperemos que continue o seu crescimento e que em breve seja prática comum em todas as empresas que desenvolvam este tipo de projetos.

Penso que esta pergunta já foi respondida há duas perguntas atrás, mas posso reforçar dizendo que agilizar os projetos não chega. É necessário agilizar as equipas e, acima de tudo, as empresas. Se as administrações e diversas unidades de negócio não aceitarem e entenderem os conceitos ágeis, vai ser muito difícil trabalhar pois acabaremos por estar a remar contra a maré. A agilização de uma empresa e consequentemente dos projetos, mesmo que introduzida ao nível das equipas de desenvolvimento, deve ser adoptada de cima para baixo, de modo a que todos os intervenientes partilhem os mesmos valores.

Há uns anos geri o meu primeiro projeto num modelo remoto. Tive que recrutar parcialmente a equipa de desenvolvimento e gerir o trabalho de todos a partir de casa. Foi um projeto aliciante porque me permitiu pôr em prática muitas das bases do que hoje ensino e forçou-me a procurar informação e aprender as melhores práticas. Em 4 meses conseguimos passar de um conceito, criar uma equipa e desenvolver duas lojas online com produtos diferenciados, recorrendo a profissionais em início de carreira (na altura) e que hoje têm provas dadas no meio. Foi muito bom ter conhecido estes profissionais e gerido o projeto, mesmo com os naturais constrangimentos de só nos vermos pessoalmente uma vez por semana. Mais do que um projeto de desenvolvimento foi um projeto de aprendizagem muito bom.

Para além de ter sido pai, penso que foi ter conseguido provar a mim próprio que conseguia chegar onde queria profissionalmente. Estou talvez a atravessar o melhor período da minha vida profissional, em termos de satisfação pura. Adoro o que faço e mesmo com muitos obstáculos, pessoais e profissionais, consegui alcançar o objetivo de ser reconhecido pelo meu trabalho. E isso, mais do que diplomas ou certificações, é o melhor de tudo.

The Agile Samurai de Jonathan Rasmusson, por ser muito simples e com exemplos práticos.

Learning Agile: Understanding Scrum, XP, Lean, and Kanban, por explicar de forma simples e bem estruturada as diferentes metodologias ágeis.

Atrevo-me a indicar mais um: The Art of Agile Development, talvez o melhor em termos globais nas metodologias ágeis.

No campo dos websites:

https://www.scrum.org/ criado por um dos fundadores do Scrum. Aqui podemos encontrar muita documentação, testes gratuitos e inclusive procurar a certificação.

https://www.coursera.org/ por oferecer formação em diversas matérias, nomeadamente gestão de projetos, com base em aulas vídeo lecionadas por Universidades de renome, com possibilidade de tirarmos certificações completas, sem ter que sair de casa.

Tendo a minha base na fotografia, tento andar sempre com a câmara atrás. Para além disso, sou um leitor e escritor ávido. Adoro andar a pé, principalmente à beira-mar e fins de tarde num qualquer miradouro de Lisboa. Em casa gosto de cozinhar. Consumo filmes, séries e documentários quando já todos dormem e eu ainda tenho a cabeça a mil. Para compensar, sempre que possível medito, nem que seja por 15 minutos.

Estudem. Procurem informação. Hoje em dia tudo está disponível online. Reparem que uma coisa não invalida a outra. Devem sempre procurar formação, porque a troca de ideias e experiências é fundamental, mas complementem sempre com livros, documentos, use cases, etc.. Depois, na prática, a regra número 1 (e 2 e 3), é que não tenham problemas em perguntar. Ninguém espera que cheguem ao mercado de trabalho a saber tudo. E, se o fizerem, irão verificar que há muitos profissionais que gostam de partilhar conhecimento e experiências. Finalmente, lutem pelos vossos objetivos. Mesmo que deem um trambolhão, não desistam. Todos nós já ouvimos negas, fomos deitados abaixo, caímos de cara no chão. O truque é aprender com isso e seguir em frente.