Como gerir um projeto de desenvolvimento de um site empresarial (com Rich Butkevic, do Project Zendo)

Leia a transcrição:

Estamos a experimentar transcrever os nossos podcasts utilizando um programa de software. Perdoe quaisquer erros tipográficos, pois o sistema automático não está correto a 100%.

Ben Aston

Obrigado por nos ouvir. Eu sou Ben Aston, fundador do The Digital Project Manager. Bem-vindo ao podcast DPM. Quer seja um gestor de projetos experiente, um produtor digital ou algo completamente diferente — talvez tenha acabado, de alguma forma, responsável pela gestão de projetos — saiba que hoje, nos seus auscultadores, se junta a milhares de outras pessoas na mesma situação, a darem o seu melhor para iniciar, planear e entregar projetos melhores.

No thedigitalprojectmanager.com estamos aqui para o ajudar a tornar-se um gestor de projetos mais confiante e competente, e para o ligar a outras pessoas que também gerem e lideram projetos. Se quer realmente evoluir e levar as suas competências de gestão de projetos ao nível seguinte, consulte a nossa DPM School e inscreva-se na nossa subscrição profissional para ter acesso a todos os nossos recursos selecionados.

Por fim, enquanto ouve o programa, subscreva-o e junte-se à nossa lista de correio em thedigitalprojectmanager.com para se manter a par de tudo o que está a acontecer. Se alguma vez desenvolveu um site empresarial, saberá muito bem como é extremamente difícil fazê-lo corretamente. Em parte, isso acontece porque não é algo que se faça com muita frequência, mas há mais fatores envolvidos: objetivos pouco claros, um briefing vago, uma rede complexa de partes interessadas e muita política.

Tudo isso torna extremamente difícil concluir um site empresarial — quanto mais fazê-lo corretamente. Acrescente alguns desafios técnicos e esses projetos de sites novos e apelativos podem transformar-se num desastre completo. Por isso, no podcast de hoje, vamos explicar como desenvolver corretamente sites empresariais. Continue a ouvir para descobrir como pode planear, gerir e controlar os seus próximos projetos de sites empresariais e concluí-los corretamente.

Obrigado por nos ouvir. Eu sou Ben Aston, fundador do The Digital Project Manager, e este é o podcast DPM. Quer seja um gestor de projetos experiente, um produtor digital ou algo completamente diferente — talvez tenha acabado, de alguma forma, responsável pela gestão de projetos — saiba que hoje, nos seus auscultadores, se junta a milhares de outras pessoas na mesma situação, a darem o seu melhor para iniciar, planear e entregar projetos melhores. No thedigitalprojectmanager.com estamos aqui para o ajudar a tornar-se um gestor de projetos mais confiante e competente, e para o ligar a outras pessoas que também gerem e lideram projetos.

Se quer realmente evoluir e levar as suas competências de gestão de projetos ao nível seguinte, consulte a nossa DPM School e inscreva-se na nossa subscrição profissional para ter acesso a todos os nossos recursos selecionados. Por fim, enquanto ouve o programa, subscreva-o e junte-se à nossa lista de correio em thedigitalprojectmanager.com para se manter a par de tudo o que está a acontecer.

Este podcast é-lhe apresentado pela Clarizen, líder em software empresarial de gestão de projetos e portefólios. Visite clarizen.com para saber mais. Hoje, estou acompanhado por Rich Butkevic-

Rich Butkevic

Perfeito.

Ben Aston

Disse bem?

Rich Butkevic

Disse perfeitamente.

Ben Aston

Ora aí está, pratiquei. Rich é consultor de gestão de projetos e autor do blogue projectzendo.com. Passe por lá e consulte-o. Também organiza workshops de gestão de projetos em todo o Texas; visite artofpmo.com se tiver interesse. Falaremos disso dentro de momentos. Rich reúne uma combinação única de cargos de liderança em gestão de projetos e produtos, garantia de qualidade, análise de negócio, marketing e formação. Utiliza Agile e Scrum e tem todas as letras e certificações que poderia desejar: PMP, Certified Scrum Master, IBM Rational Unified Process, além de ser certificado pela Amazon e pela E-Marketer. Tem tudo.

Olá, Rich, e obrigado por te juntares a nós hoje.

Rich Butkevic

Olá, Ben. Obrigado pelo convite. Agradeço.

Ben Aston

Quero começar por explorar todas essas qualificações e letras que tens depois do nome. Algumas pessoas adotam uma postura do género “não me importo realmente com certificações”; tu escolheste claramente o caminho oposto e obtiveste praticamente todas. Isso deve-se a uma paixão específica pela aprendizagem? O que te levou a obter certificações em tantas áreas?

Rich Butkevic

Não sei se foram assim tantas, mas tenho realmente paixão pela aprendizagem. É algo de que gosto muito. Penso que obter uma certificação em gestão de projetos — ou, na verdade, em qualquer área — demonstra a seriedade com que se encara a profissão e a vontade de acompanhar a evolução das coisas. Para além do PMP, adquiri as outras certificações mais ou menos conforme eram necessárias para os projetos.

Por exemplo, no caso da certificação AWS, se estivesse num projeto que utilizasse os Amazon Web Services, gostaria de compreender bem a tecnologia para poder desempenhar melhor o meu papel de gestor de projetos. Ao fazê-lo, descobri que gostava da área e queria aprender mais. E, se já iria aprender mais, era útil ter um objetivo a alcançar. Por isso, estabeleci como objetivo obter uma certificação; foi assim que aconteceu.

Ben Aston

Conta-nos então como entraste na gestão de projetos. És claramente orientado para a área técnica. Não conheço muitos gestores de projetos com uma certificação técnica como a AWS-

Rich Butkevic

Claro.

Ben Aston

Mas como começaste e entraste na gestão de projetos?

Rich Butkevic

Durante a universidade, trabalhei como técnico de suporte e atendia o telefone precisamente quando a banda larga estava a surgir. Tive contacto com a área técnica desde o início, numa época bastante entusiasmante. Quando terminei a universidade, tornei-me analista de negócio numa grande empresa de telecomunicações em Chicago, onde vivia na altura. Depois passei para a garantia de qualidade, comecei a geri-la e, mais tarde, entrei na gestão de projetos nessa empresa. Obtive a minha certificação e as coisas continuaram a evoluir a partir daí.

Ben Aston

E no teu primeiro dia como gestor de projetos aprendeste certamente muitas lições. O que dirias agora ao teu eu mais jovem, sabendo o que sabes hoje?

Rich Butkevic

Penso que o mais importante seria perceber que não se trata da ferramenta. Muitos gestores de projetos concentram-se demasiado em conhecer todos os pormenores e particularidades da ferramenta de gestão de projetos que utilizam. Na minha perspetiva, tudo o que fazemos com uma ferramenta é apenas uma forma de simplificar, automatizar e ajudar a gerir um processo que deveríamos conseguir realizar com um lápis e uma folha de papel.

Se não se sente confortável a gerir um projeto apenas com uma caneta e um caderno, não estou a dizer que seja isso que deve fazer. Mas ser um bom gestor de projetos não significa ser a pessoa que mais sabe sobre o Microsoft Project ou qualquer outra ferramenta ou software de gestão de projetos. É muito mais do que isso: envolve competências interpessoais, competências e uma boa compreensão daquilo que está a tentar alcançar como gestor de projetos, em vez de ser um especialista no software.

Ben Aston

Sem dúvida. Mas, já que falamos de ferramentas — porque eu gosto de ferramentas — o que faz parte do teu conjunto de ferramentas de gestão de projetos, além da caneta e do bloco de notas?

Rich Butkevic

Penso que, para além da ferramenta de gestão de projetos que estamos efetivamente a utilizar, o que fez a maior diferença foi algum tipo de ferramenta de colaboração. Gosto muito do Slack. É simples e fácil de utilizar, e faz uma enorme diferença em comparação com tentar gerir tudo através de uma avalanche de mensagens de correio eletrónico e folhas de cálculo do Excel espalhadas pela empresa em unidades partilhadas que ninguém consegue encontrar.

Gosto do Slack, mas o conceito e a ideia subjacentes à ferramenta de gestão de projetos são mais importantes do que a ferramenta escolhida.

Ben Aston

Utilizas alguma integração com o Slack que consideres particularmente útil para promover a colaboração e tirar mais partido dessas competências interpessoais?

Rich Butkevic

Nada me ocorre além de algumas integrações de acompanhamento que possa utilizar como consultor. As empresas com que trabalho normalmente têm normas às quais temos de obedecer. Por isso, embora o software de gestão do tempo integrado com o Slack possa mudar, ter essa integração de alguma forma é útil. Mas aquilo que considero realmente benéfico no Slack é conhecer os atalhos de teclado; isso fez uma enorme diferença.

Ben Aston

Diz-nos qual é o teu atalho preferido.

Rich Butkevic

Agora estás a pôr-me à prova. Não sei. Parece que os conheço instintivamente, como se os meus dedos soubessem quais são-

Ben Aston

Tenho a certeza de que sabes.

Rich Butkevic

Mas o meu cérebro não.

Ben Aston

Não consegues dizê-los, mas conheces os gestos das mãos.

Rich Butkevic

Sim. É como o meu número de telefone. Às vezes tenho dificuldade em dizê-lo a alguém, mas não tenho dificuldade em marcá-lo, porque preciso de o fazer.

Ben Aston

É engraçado. Mas voltando ao teu ponto: não se trata das ferramentas, embora tenhamos começado a falar de ferramentas. Vamos regressar ao tema. Disseste que uma boa gestão de projetos não depende das ferramentas. Fala-nos mais sobre aquilo que descobriste ser a verdadeira arte da gestão de projetos e sobre como utilizas essas competências interpessoais para entregar projetos melhores.

Rich Butkevic

Quando falo de competências interpessoais, é evidente que a comunicação e outras competências semelhantes são importantes. Mas, para além disso, talvez seja melhor dizer que é necessário compreender, a um nível conceptual, o que um gestor de projetos deve fazer e como um projeto deve funcionar, pelo menos idealmente, para se poder concentrar no que é essencial e não em coisas que são apenas uma perda de tempo.

Ao longo de um projeto, há alguns grandes grupos de atividades nos quais devemos concentrar-nos. Depois existem tarefas que temos de fazer, devemos fazer ou poderíamos fazer dentro desses grupos. Mas é essencial identificar os requisitos, garantir que tanto a empresa como a equipa técnica — se for um projeto de TI ou de um site — têm uma compreensão comum desses requisitos, assegurar que os testes são realizados e que os defeitos são geridos de alguma forma. É preciso compreender as atividades de nível mais elevado, normalmente representadas como tarefas-resumo num plano de projeto, bem como o objetivo global e a razão pela qual essas atividades estão a ser realizadas.

Costumo dizer que, se não consegue escrever uma publicação curta sobre o motivo pelo qual está a preencher um documento ou a fazer determinada coisa, provavelmente deve parar e esclarecer a razão. Muitas vezes, se não sabemos porque fazemos algo, não conseguimos fazê-lo bem — e talvez nem devêssemos fazê-lo.

Ben Aston

Vamos então abordar a gestão de projetos de desenvolvimento de sites empresariais. Publicámos recentemente um artigo sobre como os projetos de sites empresariais correm mal — um guia rápido para gestores de projetos. Consulte-o em thedigitalprojectmanager.com se ainda não o leu. A realidade é que isto é difícil. Os projetos de sites empresariais são realmente complexos. As empresas contratam agências e consultores e precisam de ajuda externa para fazer uma atualização importante, migrar para a nuvem, implementar um novo CMS ou integrar ferramentas de marketing digital. Mas, pela própria natureza destes projetos, normalmente não são realizados com frequência. Muitas vezes só acontecem de três em três ou de cinco em cinco anos, o que significa que as pessoas envolvidas não têm muita experiência e talvez só tenham gerido um projeto deste tipo uma ou duas vezes durante a carreira.

É um desafio e, como referi no início, há muitas partes interessadas, briefings pouco claros, política e desafios técnicos. Se ainda não consultou o artigo do Rich, leia-o. Quero falar sobre este processo, sobre como o podemos simplificar e desenvolver a partir daquilo que o Rich estava a dizer acerca de compreender o que tem de acontecer para que o projeto seja bem-sucedido. Comecemos por explorar por que razão isto é tão difícil. Talvez possas partilhar um exemplo ou uma história de terror sobre algo que tenha corrido mal contigo no passado, e eu farei o mesmo.

Rich Butkevic

Uma das grandes lições que aprendi no início da carreira foi, diria eu, confiar, mas verificar. Muitas vezes, os recursos do projeto diziam que tinham concluído uma tarefa, quando na realidade queriam dizer que planeavam concluí-la ou que ela estava na lista de tarefas. Depois surgiam outras coisas, a tarefa era esquecida ou escondida, e alguns desses problemas só se tornavam evidentes quando se chegava à produção, infelizmente.

Foi provavelmente uma das maiores lições que aprendi no início. Além disso, colaborar bem com equipas grandes, especialmente em projetos de grande dimensão ou com recursos distribuídos geograficamente, tem sido fundamental. Quanto maior é um projeto, menos podemos depender dos esforços heroicos de uma ou duas pessoas para resolver tudo no final.

Num projeto de site empresarial, um consultor como eu pode deslocar-se a empresas diferentes algumas vezes por ano e trabalhar em projetos deste tipo. Já trabalhei em algumas dezenas. Mas um administrador de sistemas ou de redes de uma empresa, que esteja lá há 15 anos, pode ter feito algo semelhante apenas uma vez, talvez duas, durante toda a década ou década e meia em que esteve na organização.

Por isso, embora para algumas pessoas possa parecer algo rotineiro, para muitos recursos empresariais não é nada rotineiro.

Ben Aston

Vou partilhar uma história sobre algo que correu mal. Há alguns anos, trabalhei num projeto de site empresarial e o desafio acabou por se resumir ao alinhamento do briefing. Isto relaciona-se diretamente com a gestão das partes interessadas. A pessoa responsável por gerir internamente o projeto não tinha necessariamente reunido todas as opiniões da equipa.

Tinha escrito um briefing que não fora aprovado ou, se tinha sido aprovado, não fora devidamente revisto. Avançámos, concebemos o site, desenvolvemo-lo e, mesmo antes de o colocar online, descobrimos que havia uma etapa adicional de aprovação na estrutura de governação do projeto que desconhecíamos completamente. Disseram-nos que o fundador e presidente ainda tinha de aprovar o site antes do lançamento. O fundador e presidente era, na realidade, o verdadeiro responsável.

Rich Butkevic

É verdade.

Ben Aston

Tinha ideias muito claras sobre aquilo que queria e não queria, e essas ideias eram fundamentais para todo o projeto.

Rich Butkevic

Claro.

Ben Aston

Tivemos então uma conversa difícil. Tivemos de dizer: “Lamentamos, mas isto não estava no briefing. Aprovou tudo ao longo do projeto e agora o fundador e presidente não está satisfeito, por isso mais ninguém está satisfeito.” Tivemos de emitir um pedido de alteração enorme, o que deixou o cliente descontente por ter de pagar mais, e a relação ficou prejudicada.

Rich Butkevic

Claro.

Ben Aston

Também tivemos alguma responsabilidade, porque não insistimos o suficiente sobre a estrutura de governação no início do projeto. Deveríamos ter avançado mais lentamente e obtido a aprovação ao longo de toda a hierarquia, até ao nível máximo.

Rich Butkevic

Isso pode ser muito difícil, sobretudo numa empresa de maior dimensão, onde se podem identificar cerca de doze partes interessadas no projeto, mas todas têm um chefe, que por sua vez tem outro chefe, e assim sucessivamente. Quando alguém com autoridade suficiente vê uma alteração no site de que não gosta, pode anular decisões anteriores. Isso pode tornar-se complicado.

Ben Aston

Uma das lições que retirei foi explicar as consequências. Atualmente digo: “Vamos mapear as partes interessadas e criar uma matriz RACI para os diferentes marcos do projeto. Mas, para sermos claros, se esta pessoa for responsável por aprovar algo, e mais tarde descobrirmos que ainda temos de voltar atrás para obter outra aprovação, isso terá impacto nos custos e no prazo. Diga-o agora ou teremos consequências mais tarde.”

É importante esclarecer tudo. Muitas vezes a equipa de marketing é responsável pelo projeto, atribui-o a uma pessoa júnior e essa pessoa diz: “Vou envolver o meu chefe.” E nós pensamos: “Provavelmente devemos envolver mais algumas pessoas.”

Rich Butkevic

Certo.

Ben Aston

Explica-nos então o processo de alto nível. Como passamos de um cliente empresarial que diz “Preciso de um novo site empresarial” para “Está concluído”?

Rich Butkevic

Claro.

Ben Aston

Falavas dos grandes grupos de atividades, das tarefas-resumo no plano de projeto. Como é que isso funciona para ti? Sei que és um defensor do Agile e tens a tua certificação em Scrum. Como aplicas essa abordagem num projeto de site empresarial, quando uma abordagem mais faseada talvez faça sentido devido ao estado das aprovações?

Rich Butkevic

A um nível elevado, a primeira coisa que quero garantir é que identificamos os objetivos reais do projeto ou do site. Por vezes existe uma fusão ou aquisição e é necessário integrar dois sites; outras vezes trata-se de um redesign ou reposicionamento da marca; noutras situações implementa-se um novo sistema de gestão de conteúdos. Dependendo dos objetivos, muitas das tarefas seguintes serão diferentes.

Depois de identificados os objetivos, gosto de avançar para as histórias de utilizador. É algo que muitos projetos de design ou de sites não consideram. A maioria das empresas não serve todas as pessoas. Normalmente consegue identificar alguns perfis de clientes diferentes, que designamos por avatares: pessoas que vão comprar, pessoas que procuram informação ou clientes existentes que pretendem repetir uma encomenda, por exemplo.

Cada tipo de utilizador terá objetivos diferentes no site, procurará informações diferentes, terá um nível de conhecimento distinto e seguirá percursos diferentes. O objetivo final do utilizador e da empresa também irá variar consoante o avatar. Identificar esses perfis-

Ben Aston

Está bem.

Rich Butkevic

E escrever o motivo pelo qual visitam o site e aquilo que esperam fazer ajuda a orientar a etapa seguinte: conceber a hierarquia e a estrutura do site. Queremos limitar o número de cliques necessários para chegar a qualquer informação. Não queremos que algo esteja escondido 20 páginas abaixo, porque o utilizador nunca o encontrará ou ficará frustrado. Também não é bom por muitas outras razões, incluindo razões de otimização para motores de pesquisa. Assim, utilizamos as histórias de utilizador para definir a estrutura do site.

Depois de definir a hierarquia, analisamos o conteúdo e a forma como será gerido. Num site pequeno, com menos de 50 páginas, isso é relativamente simples. Mas num redesign ou numa alteração de CMS de um site empresarial de grande dimensão, podem existir milhares de páginas. É necessário saber que conteúdo permanece, qual será atualizado, eliminado ou fundido. Trata-se de um trabalho significativo e é uma das áreas em que as ferramentas podem ajudar muito, pois não queremos ter dois ou três mil documentos Word espalhados numa pasta.

Ben Aston

Sim.

Rich Butkevic

Só depois disso começo realmente a preocupar-me com os aspetos técnicos. Esses aspetos são relativamente estáveis. Existem diferenças entre empresas, dependendo da infraestrutura, do CMS e de outros fatores, mas podemos fazer toda a parte técnica na perfeição; se os outros elementos não tiverem sido pensados, se os objetivos não forem alcançados, se o site não estiver organizado de forma intuitiva e se o conteúdo certo não estiver disponível, a parte técnica não será suficiente.

Ben Aston

Para ti, o mais importante é definir o briefing e os objetivos do site, identificar as personas ou arquétipos, criar a arquitetura do site e a arquitetura da informação para permitir uma utilização eficaz. Depois há uma fase de design, em que criamos wireframes e componentes de design. Costumas fazê-lo como um fluxo de trabalho paralelo? Para quem está a ouvir e pensa que isto vai demorar muito — descoberta, planeamento e design antes do desenvolvimento — que estratégias utilizas para executar tarefas em paralelo e acelerar o processo sem deixar de fazer tudo corretamente?

Rich Butkevic

Procuro não utilizar demasiadas estratégias rápidas, porque o planeamento faz uma enorme diferença na rapidez com que o projeto avança mais tarde. Se não temos tempo para fazer algo bem à primeira, também não teremos tempo para o refazer. Dito isto, é possível executar muitas atividades em paralelo e, em certa medida, é isso que deve acontecer.

Enquanto se definem os objetivos gerais do site numa empresa existente, normalmente já se sabe quem são os clientes e que tipos de pessoas irão visitar o site. É possível começar a criar histórias de utilizador e, ao mesmo tempo, tomar notas sobre a estrutura do site. Num redesign, provavelmente faz sentido utilizar a estrutura existente como ponto de partida e verificar onde pode ser melhorada. Também pode existir uma equipa de conteúdos, com diferentes departamentos da empresa. As vendas terão conteúdos, os recursos humanos terão conteúdos e outros grupos terão os seus próprios conteúdos. Todos podem começar a rever os seus conteúdos e decidir o que querem fundir, eliminar ou atualizar.

Todas essas atividades podem avançar em conjunto. Quase me esquecia da segunda parte da pergunta: como utilizo o Agile, o Scrum ou abordagens iterativas neste contexto? Penso que ajudam sobretudo na gestão das partes interessadas.

É importante chegar rapidamente a algo que as partes interessadas e o decisor possam ver com os próprios olhos. Muitos líderes organizacionais não querem participar no dia a dia do projeto, e isso é provavelmente adequado. Mas quando marcamos uma sessão em que podem ver o progresso e o site num ecrã, costumam participar. É nessa altura que obtemos feedback valioso. Quanto mais cedo o obtivermos, melhor, porque não queremos tomar uma decisão de design que se propague por todo o site e descobrir no fim que não era aquilo que uma pessoa da direção pretendia. Por vezes uma abordagem mais faseada é melhor, mas, na minha experiência, normalmente não é.

Ben Aston

Os testes com utilizadores também podem ajudar muito. No desenvolvimento de um site empresarial, identificamos as personas no início: para quem estamos a construir o site? Muitas vezes, alguém da empresa mistura isto com o desejo de promover o ego de determinada pessoa. Esse pode ser um objetivo implícito do projeto, mas deve ser tornado explícito.

A criação de arquétipos ou personas ajuda-nos a alinhar com o cliente a razão pela qual estamos a realizar o projeto e os seus objetivos. Em muitos projetos de sites empresariais, alguém diz: “Na página inicial, o mais importante é contar a todos o que o nosso CEO fez. Está na empresa há 15 anos e queremos falar disso.” E nós perguntamos: “Porquê? Se são uma empresa de banda larga, que importância tem isso para os utilizadores?”

Rich Butkevic

Claro.

Ben Aston

Para alguém, isso pode ser o mais importante porque, se fizer o CEO parecer bem, talvez consiga uma promoção e um aumento. Existem objetivos explícitos e implícitos. As personas ajudam-nos a orientar as decisões sobre o que colocamos em cada lugar. Depois temos os testes com utilizadores, que ajudam a reduzir o risco de as partes interessadas tomarem decisões inadequadas.

Podemos dizer: “Estas são as nossas personas. Vamos testar com elas aquilo que criámos.” Damos-lhes tarefas específicas, como: “Quer adquirir um novo pacote de banda larga. Como faria isso?” Mostramos o site, a arquitetura da informação e os wireframes e pedimos que encontrem o pacote adequado. Podem responder: “Vejo esta grande informação sobre o CEO e os seus 15 anos na empresa, mas não consigo perceber como configurar o meu pacote de banda larga.” Assim temos dados concretos para levar à equipa empresarial e dizer: “Talvez devêssemos substituir o banner da página inicial por um configurador de banda larga, em vez de destacar o CEO.” É um exemplo exagerado, mas ilustra a ideia.

Rich Butkevic

É um excelente exemplo e esse tipo de situação acontece constantemente. Nos testes com utilizadores, é muito importante garantir que os utilizadores representam realmente os avatares de clientes identificados anteriormente. Se vendemos seguros de habitação, não devemos testar com pessoas que não têm casa ou com adolescentes. Precisamos de amostras representativas das pessoas que utilizarão o site.

Muitas empresas utilizam os próprios colaboradores nos testes, o que normalmente é uma péssima ideia. Quem trabalha na empresa conhece melhor o funcionamento do negócio, os objetivos e o jargão do setor. Não queremos realizar testes, concluir que tudo é fácil de utilizar e depois descobrir, quando o site é lançado, que o público não compreende uma expressão como “banda larga”. As pessoas podem não clicar na ligação de navegação, ficar confusas e visitar um concorrente que utiliza uma expressão como “internet de alta velocidade”.

Ben Aston

Falámos bastante sobre a descoberta, o planeamento e o design. Vamos agora abordar o desenvolvimento. Tens muita experiência nos aspetos técnicos da gestão de sites empresariais. Conceber sites é difícil e fazê-los cumprir os objetivos definidos no início é essencial. Se queremos aumentar as conversões ou atingir os nossos indicadores-chave de desempenho, o design tem de estar correto. Mas existe uma diferença entre o design estar correto e o site funcionar tecnicamente como previsto.

Quais são as tuas principais recomendações para gerir o desenvolvimento de um site empresarial? O que deve considerar um gestor de projetos que esteja a gerir um projeto destes pela primeira vez, especialmente ao gerir uma equipa de programadores?

Rich Butkevic

O mais importante é lembrar que os programadores do projeto normalmente não terão muita experiência nesta área específica, ou pelo menos na migração. Podem ter experiência na gestão de um site depois de este estar em funcionamento, mas não necessariamente nos restantes pormenores técnicos. Há alguns aspetos a que presto especial atenção porque, se algo for esquecido ou feito incorretamente, provavelmente será numa destas áreas.

Uma delas é o redirecionamento HTTPS. Quase todos os sites, especialmente os empresariais, utilizam agora uma ligação segura para encriptar o tráfego. É essencial garantir que, se um cliente escrever HTTP, não escrever HTTPS ou não chegar ao site através de uma ligação, o pedido é encaminhado para a versão segura da página. Já vi isto ser mal configurado muitas vezes e de diversas formas.

Também é necessário garantir que o URL é reescrito corretamente. Caso contrário, os motores de pesquisa podem considerar que existem duas versões do site: a versão HTTP e a versão HTTPS. Isso pode criar problemas de conteúdo duplicado e, nas ferramentas de análise, as duas versões serão frequentemente monitorizadas de forma independente, tornando muito difícil relacionar conversões e outras ações.

Outro aspeto surge quando chega o momento de lançar o site e é necessário atualizar o DNS. O DNS é o sistema que permite traduzir um nome de site, como Google, num endereço IP para que possa ser encontrado na Internet. Pode chegar o momento do lançamento e a pessoa responsável pelas atualizações de DNS não ter acesso ao registador. Essa informação costuma ser muito restrita, e deve sê-lo, porque quem tem acesso ao domínio principal da empresa deve ser responsabilizado.

Ainda assim, é necessário garantir que as pessoas certas têm o acesso de que precisam. A equipa do projeto, sobretudo a liderança, deve compreender o conceito básico de propagação: depois de uma alteração de DNS, é necessário algum tempo para que a alteração seja refletida nos servidores de toda a Internet. O que tento evitar é lançar o site, enviar uma mensagem às partes interessadas a dizer “Concluímos todas as atualizações” e receber de seguida mensagens a dizer “Está avariado, não funciona comigo”. Na realidade, funcionará dentro de 15 minutos; as alterações ainda não se propagaram. Explicar isto reduz muito o pânico desnecessário no dia do lançamento.

Ben Aston

Existem excelentes recomendações para o lançamento que devem ser pensadas com bastante antecedência. Muitas vezes estamos tão envolvidos no processo de desenvolvimento que sabemos que o lançamento será dentro de duas semanas, mas só no dia anterior começamos a pensar se conseguimos redirecionar o DNS ou fazer as atualizações. Então descobrimos que ninguém sabe a palavra-passe e que a pessoa que a conhece está de férias.

Pensar antecipadamente nestes aspetos é um excelente conselho para quem está a preparar o lançamento de um site empresarial. Mas quero voltar ao processo de desenvolvimento. Depois do design, o site tem de ser construído.

Rich Butkevic

Claro.

Ben Aston

Como se gerem programadores quando não somos técnicos? Um gestor de projetos pode ser excelente a gerir o processo de design da experiência do utilizador, mas não se sentir tão confiante a gerir programadores. Se não consegue ver o que estão a fazer e pergunta se uma tarefa está concluída, eles respondem que sim, mas querem dizer que ainda não está completamente concluída, como se gere essa situação?

Rich Butkevic

É uma situação em que uma abordagem iterativa é particularmente útil, porque permite ver algo a funcionar ou a não funcionar numa demonstração, diretamente no ecrã. Essa seria provavelmente a minha primeira recomendação. Ajuda a identificar problemas rapidamente, permite perceber se o trabalho está a avançar como deveria e confirmar se aquilo que nos dizem corresponde à realidade.

Também não posso deixar de salientar a importância de não existirem grandes intervalos entre reuniões e atualizações. Não quero reuniões apenas para dizer que houve uma reunião, mas realizar pelo menos uma reunião diária ou a cada dois dias, mesmo que seja uma reunião de cinco minutos, é muito útil para manter tudo no caminho certo. É algo comum no Scrum, mas não é exclusivo dessa estrutura. Pode ser utilizado independentemente da abordagem de desenvolvimento. Quanto mais os assuntos forem acompanhados e os problemas resolvidos, maior será a probabilidade de o projeto se manter no caminho certo.

Ben Aston

O ímpeto é importante. É necessário manter o trabalho a avançar, fazer demonstrações e construir algo que possamos observar. No final da semana queremos ter uma versão funcional para avaliar. O programador pode dizer: “Só construí a barra de navegação.” E nós respondemos: “Vamos vê-la a funcionar.” Ao testá-la no telemóvel, podemos descobrir que não funciona e corrigir o problema imediatamente.

Identificar estes problemas cedo é essencial. Devemos manter uma cadência regular de demonstrações do sprint ou de apresentações do trabalho em curso, bem como reuniões diárias. Podemos perguntar: “O que fizeste ontem? Qual é o plano para hoje? Há algum bloqueio em que possa ajudar?” Isso reduz a opacidade do desenvolvimento, em que os programadores desaparecem durante seis semanas e depois descobrimos que o resultado não está correto.

Para quem está a ouvir parcialmente no carro e pensa que falámos de descoberta, planeamento, design, desenvolvimento e lançamento, há muito para recordar. Qual é a recomendação mais simples para alguém que está prestes a gerir ou já está a gerir um projeto de site empresarial? Como podemos garantir o sucesso, gerindo e controlando o projeto, o orçamento e o calendário?

Rich Butkevic

É uma combinação de tudo o que discutimos. É essencial colaborar bem e utilizar uma ferramenta que facilite essa colaboração. As reuniões diárias são importantes e ajudam a antecipar muitos problemas. São apenas outra forma de colaboração, e quanto mais curto for o ciclo de feedback, melhor.

A vantagem de uma abordagem Agile é que o ciclo de feedback pode ser dividido em períodos de duas semanas, durante os quais demonstramos algo real. Também podemos dividi-lo em reuniões diárias, nas quais não fazemos demonstrações, mas recebemos atualizações e feedback, tornando o ciclo ainda mais curto. Ao utilizar o Slack ou outra ferramenta de colaboração, podemos resolver os problemas de imediato, sem que alguém tenha de esperar até ao dia seguinte ou até ao sprint seguinte para os comunicar.

Essa seria provavelmente a minha principal recomendação. Há ainda outro aspeto que não abordámos: antes do lançamento, devemos rastrear o site à procura de ligações quebradas. Isto identifica muitos problemas que passam despercebidos. É uma tarefa simples, mas raramente vejo alguém fazê-la. Como gestor de projetos, na semana anterior ao lançamento, costumo rastrear o site para verificar se existem ligações quebradas. Isso pode revelar problemas de codificação, problemas de organização ou problemas técnicos.

Ben Aston

Que ferramentas utilizas para fazer esse rastreamento?

Rich Butkevic

Não tenho uma recomendação específica; funcionam todas de forma semelhante. Procuraria online por uma ferramenta de verificação de ligações.

Ben Aston

Algo desse género.

Rich Butkevic

Depende de se está a construir um site novo ou a fazer um redesign e de precisar de uma ferramenta que funcione dentro ou fora da rede. Existem algumas particularidades, mas são detalhes menores. O importante é garantir que a verificação é feita, porque traz grandes benefícios.

Ben Aston

Obrigado por te juntares a nós, Rich. O aspeto mais valioso da nossa conversa foi a importância de começar bem o projeto: definir corretamente o briefing, os objetivos e as metas, porque tudo o resto parte daí. Também não falámos de um aspeto importante: depois do lançamento, existe normalmente uma fase em que avaliamos o desempenho do site. Se mantivermos os objetivos presentes durante todo o projeto, será muito mais fácil verificar se o site gera resultados, retorno do investimento e valor. Começar corretamente é realmente essencial. Muito obrigado, Rich.

Rich Butkevic

Obrigado, Ben. Foi ótimo estar aqui contigo.

Ben Aston

Foi ótimo ter-te connosco. O que pensa sobre isto? Que estratégias, dicas e truques utiliza no desenvolvimento de sites? O que descobriu que funciona e que não funciona? Se tem histórias de fracassos ou sucessos, conte-nos nos comentários. Se quer aprender mais e avançar no seu trabalho, junte-se à nossa comunidade através da subscrição DPM. Encontrará todo o tipo de bons recursos, incluindo planos de projeto para grandes desenvolvimentos de sites, utilizando diferentes metodologias, sprints ou uma abordagem mais tradicional em cascata. Visite thedigitalprojectmanager.com/membership.

Terá acesso à nossa equipa do Slack, modelos, workshops, horários de atendimento, livros digitais e muito mais. Se gostou do que ouviu hoje, subscreva o podcast. Reserve alguns minutos para nos deixar uma avaliação honesta e obrigado por nos ouvir. Até à próxima, cuide-se.