O tempo dos projetos

O gerenciamento do tempo dos projetos representa uma das áreas de conhecimento do PMBOK® (PMI, 2004) mais citadas nas entrevistas. Conforme já foi adiantado em outras seções, é também o fator que é percebido de maneira mais diferenciada entre os líderes e liderados. Nesta

seção, serão analisadas as características do gerenciamento de prazos e do cronograma dos projetos na agência escolhida para o estudo de caso, com o objetivo de poder tirar conclusões a respeito das necessidades de estruturas de apoio para os desafios detectados.

É possível perceber que todos os entrevistados estão cientes da importância do tempo de um projeto para o seu sucesso: “Com certeza [...] um fator bem crítico. O cumprimento do prazo do projeto é um dos principais pontos para um cliente” (gerente de projetos). Foi possível compreender, por meio da observação participante durante a convivência no setor, que no caso do lançamento de uma loja virtual, não somente a agência contratada para o desenvolvimento da mesma, mas também diversas áreas do lojista estão se preparando para uma data específica e desta forma um atraso teria impactos sistêmicos em campanhas, vendas, operações e muito mais. Devido a este fato, o planejamento realista e acompanhamento assíduo dos prazos dos projetos, por meio das ferramentas utilizadas na gestão, representam um dos maiores pontos de atenção e exigências à estrutura, conforme formulado no Requisito 4A.

Requisito 4A: As ferramentas de gestão utilizadas, e as comunicações internas devem auxiliar a evitar o atraso nas entregas sinalizando os diferentes prazos de maneira clara e em tempo hábil para todos os interessados.

Analisando as durações dos projetos, é possível perceber que as variações do tempo estimado entre os projetos da agência se dão, via de regra, de acordo com a complexidade do escopo acordado e são pequenas (“quanto mais funcionalidades específicas, landing pages, etc, mais demorada pode ficar a etapa de criação de layout e Implementação”, gestor de projetos). Fatores como tipo de contrato, relacionamento com o cliente e fila de projetos, entre outros, podem impactar estas estimativas e resultar em projetos com prazos curtos desde o momento de sua venda: “isso também depende. Às vezes o cliente já vem com um prazo fixo em mente e avaliamos se conseguimos cumprir, e outras vezes estimo de acordo com nossa fila de projetos e o tempo esperado pelo desenvolvimento” (gestor). A metodologia utilizada para a determinação dos prazos dos projetos está baseada na experiência do gestor e define o ritmo de trabalho necessário para a entrega dentro do tempo estipulado: “eu tenho mais ou menos em mente quanto tempo cada time leva e como são etapas, uma seguida da outra, pelo menos na maioria dos casos, é uma soma de estimativas. Depois o time trabalha para cumprir o combinado, temos uma margem ali também” (gestor de projetos). Esta situação é percebida de forma crítica pelos funcionários porque pode

gerar estresse e impactar as entregas; ao ser questionado se existem grandes variações entre os prazos dos projetos, um designer responde: “deveria. Mas acaba que muitas vezes fazemos um projeto grande e complexo em quase tanto tempo quanto um padrão. Isso pode prejudicar a qualidade ou nos estressar bastante. Claro que eu não culpo só a gestão por isso, muitas vezes o próprio cliente tem pressa com a entrega e todo o projeto acaba sendo meio corrido”.

No entanto, na grande maioria dos casos, atrasos nos projetos devido a alguma falha da agência conseguem ser evitados (“graças a deus são raros. Pelo menos os atrasos por nossa culpa”, gerente de projetos). Isto significa que a metodologia de estimativa dos tempos do projeto adotada é eficaz. No entanto, sabendo da importância do cumprimento dos prazos no segmento do comércio eletrônico, não calcular com margens maiores em todos os projetos pode representar um grande risco e prejudicar, a longo prazo, a motivação dos envolvidos.

No momento, com o time de projetos acelerando as entregas quando necessário (“bate porque fazemos bater. Se eu conhecer o tempo disponível desde o início, consigo distribuir minhas atividades de acordo. Não digo que é o caso ideal, mas entrego o layout no tempo previsto”, designer), a principal razão para os atrasos se encontram em um desalinhamento da finalização das responsabilidades do lojista com o prazo estipulado para o lançamento da loja implementada: “o que mais acontece é o lojista ainda não estar pronto do seu lado e isso travar o desenvolvimento de alguma maneira”, “Normalmente é quando um lojista some, tem dificuldades de fechar algum contrato com um serviço de frete, meios de pagamento ou similar, ou ele mesmo desprioriza o projeto por conta de campanhas ou outras razões específicas” (gestor de projetos). Também ocorre, em poucos casos, um ultrapassar do prazo devido à quantidade de ajustes solicitados pelo cliente na fase de homologação, tanto do layout - situação onde ainda é possível recuperar uma certa quantia de dias na implementação - quanto da loja finalizada em termos de implementação de código. Ao entrevistar o gerente de projetos e sua equipe a respeito do impacto, as respostas são: “Nesse caso não temos responsabilidade, mas somos prejudicados igualmente. Um atraso em um projeto bagunça toda a fila de projetos. Não sei quando será retomado esse projeto em questão e pode ser que já tem prazos de outros projetos se aproximando e a equipe precisa passar para essas entregas de outro cliente”, “Aí acumula [os projetos simultâneos acumulam]” (gerente de projetos).

Entende-se, assim, que não somente a projeção dos prazos adequados e o controle interno dos mesmos, mas também a gestão do cumprimento das atividades necessárias do lado do lojista

devem ser considerados no gerenciamento do tempo de um projeto para o mesmo obter sucesso como um todo. Esta exigência foi suficientemente contemplada pelo Requisito 1C (“A estrutura de gestão de projetos precisa prever o apoio consultivo às tarefas do cliente”) anteriormente apresentado e discutido, na Seção 5, de acordo com as contribuições científicas relacionadas.

Desta forma, mais uma vez, fica evidente a importância do alinhamento das expectativas com o cliente para evitar a necessidade de muitos ajustes e consequentes impactos nos prazos e no trabalho intensificado das pessoas alocadas: “internamente atrasamos pouco, só [...] quando surge algo muito complexo ao longo do projeto [...] um comportamento ou funcionalidade incomum. Que é demorada de fazer e não sabíamos antes que teria ou fizemos de uma certa maneira mas o cliente não gostou. Dependendo de quem é o cliente precisamos fazer mesmo assim” (desenvolvedor).

Além disto, para evitar requisitos de entrega e quantidades de ajustes surpreendentes ao longo do projeto, é importante conhecer a quantidade de pessoas e estruturas internas do cliente envolvidas na aprovação do projeto, fator mais bem analisado na seção a respeito dos stakeholders de um projeto.

Uma vez que os prazos forem estabelecidos, é importante acompanhá-los e garantir o alcance dos mesmos. Em um ambiente multiprojetos, como é o caso da agência estudada aqui, diferentes prazos tanto dos projetos como um todo, quanto das diferentes etapas necessitam ser visualizados, avaliados e controlados, assim como suas datas de cumprimento registradas para possibilitar uma supervisão da área como um todo. No presente estudo de caso, o conhecimento das etapas atuais e dos projetos com prazos próximos ou com riscos de atraso está dificultado, conforme já detectado no primeiro bloco das entrevistas. Falta uma estrutura de apoio à gestão dos projetos facilmente atualizável e que disponibilize, de maneira automatizada, informações estratégicas a respeito dos projetos. O conhecimento é baseado principalmente em comunicação verbal e poucas informações são registradas formalmente e correlacionadas para obter informações de apoio à tomada de decisão.

Combinando os resultados da entrevista com uma análise documental das estruturas de controle de prazos existentes, é possível observar que existe um interesse da gestão na estruturação destas informações, mas que a manutenção das planilhas criadas no serviço de armazenamento

online, Google Drive, para atender esta necessidade é muito complexa e exige atualizações muito manuais. O impacto negativo desta situação pode ser observado pelas respostas dos outros entrevistados analisadas nas seções anteriores, principalmente nos tópicos 1) e 2) da seção análise dos resultados da pesquisa, assim como pelo pouco tempo disponível do gerente de projetos no dia a dia. Existe a necessidade de uma estrutura de gestão padronizada, de fácil manutenção e focada no gerenciamento macro do andamento dos projetos, conforme registrado anteriormente no Requisito 2A (“Para a gestão dos projetos são necessários cronogramas de fácil visualização e atualização por todas as partes interessadas. Precisa ser de clara compreensão a etapa atual, seu prazo e as próximas etapas. Adicionalmente, uma visualização de todos os projetos em conjunto facilita a comunicação interna, assim como um desempenho positivo da gestão”).

Esta necessidade se confirma quando analisada a centralização do conhecimento a respeito dos projetos no momento. Quando questionado se as atividades relacionadas ao controle dos prazos do projeto poderiam ser executadas por outra pessoa, o gestor de projetos explica: “No momento, dificilmente. Tem muita informação específica do projeto que eu possuo. Todo o contato com o cliente, o briefing inicial, o contato com o time de saber em qual nível está o andamento de cada layout ou implementação e o que isso significa para os prazos. Só talvez minha assistente que está acompanhando mais de perto”. Esta situação reforça a importância da exigência constatada por meio do Requisito 1F (“Os registros do andamento do projeto precisam estar visíveis aos interessados a qualquer momento, portanto a ferramenta escolhida para o acompanhamento precisa ser acessível a todos sem necessitar de reportes adicionais do lado da gestão de projetos”).

O fato de possuir projetos com ciclos de vida e micro etapas muito similares, facilita a adoção de um cronograma padronizado o qual pode ser reutilizado, necessitando somente de pequenos ajustes de projeto para projeto (conforme Requisito 1D: “Recomenda-se o uso de uma estrutura de gestão padronizada que possa sustentar as atividades gerenciais e que evite a necessidade de reconstrução dos instrumentos de gestão a cada projeto”). Para atender às demandas do gestor de projetos e outros interessados, como a área comercial, é importante que este cronograma possua um campo com o status respectivo de cada etapa. As etapas atuais de cada projeto e seus prazos devem ser facilmente visualizáveis, no melhor caso em conjunto com todos os projetos em andamento - requisito facilitado com a padronização dos cronogramas e respeitando as boas práticas formuladas no Requisito 2A (“Para a gestão dos projetos são necessários

cronogramas de fácil visualização e atualização por todas as partes interessadas. Precisa ser de clara compreensão a etapa atual, seu prazo e as próximas etapas. Adicionalmente, uma visualização de todos os projetos em conjunto facilita a comunicação interna, assim como um desempenho positivo da gestão”).

Como, para a atualização de qualquer ferramenta de controle, o gestor necessita do conhecimento do avanço das etapas, é importante criar em paralelo à estrutura de gestão uma cultura de atualização periódica, tanto pelo gestor, quanto pelo time. Sabe-se, por meio da entrevista e revisão documental, que existe uma separação das tarefas de implementação de uma loja entre os desenvolvedores, e que ambos, desenvolvedores e designers, possuem acesso à plataforma Jobber para registrar as horas trabalhadas em cada projeto: “nós separamos as atividades necessárias para a loja ficar pronta entre a gente. E cada um cuida de sua parte. Se eu sou responsável por algo eu atraso menos, porque serei...bom, responsabilizado por isso. Até tínhamos um documento disso, mas confesso que não é uma prática muito frequente preenchermos. O [nome do gerente de projetos] briga às vezes conosco, mas como não é tanto reforçado no início do projeto, acabamos definindo entre a gente e aí cada um já parte para suas responsabilidades.”, desenvolvedor. Para que o gerente de projetos possa ter conhecimento da distribuição das tarefas de desenvolvimento, assim como do avanço da conclusão das mesmas, é importante que a equipe possua documentos compartilhados, ou utilize o próprio Jobber, para marcar a conclusão das etapas e possivelmente observações a respeito, como, por exemplo, as atividades que não chegou a realizar por falta de tempo. Para isto é necessário que a pauta no Jobber seja criada no momento do preenchimento do cronograma, tarefa a qual não somente garante a disponibilidade dos recursos quando necessário, mas também facilita o planejamento da fila de projetos e disponibiliza a informação sobre projetos futuros à equipe. O espaço de descrição do job, disponibilizado pela ferramenta, pode ser utilizado para registrar as informações a respeito de escopo e briefing. Uma vez que estas atividades de atualização de status de desenvolvimento são somente atividades de apoio à gestão, e não agregam valor direto ao projeto, é importante que sua realização seja rápida e intuitiva.

Como o monitoramento dos prazos de um projeto vai além do simples conhecimento de sua etapa atual (“e para saber se vai atrasar, tem que olhar mais do que isso, tem que olhar quais

tipos de funcionalidades ainda estão para desenvolver. Porque isso pode depender de projeto a projeto. Não quer dizer que, porque estou terminando o carrinho de compras, amanhã pode ir para homologação do cliente. Isso pode ser o caso, mas também pode ser que ainda falte muita outra coisa”, desenvolvedor), é importante também que sejam realizadas trocas de informação diárias entre o gestor e o time liderado, conforme formulado por meio do Requisito 4B.

Requisito 4B: É importante que seja criado uma rotina de atualização das ferramentas de gestão dos prazos e tempos do projeto, como cronogramas e pautas, e que todo o uso seja acompanhado de reuniões frequentes entre o gestor e a equipe.

Para possibilitar o uso das ferramentas de gestão pelo gerente de projetos, é importante não somente que os mesmos sejam de fácil manuseio, mas também que outro desafio seja analisado: a falta de tempo do gestor devido às atividades relacionadas ao atendimento diário dos clientes (tópico 2) do Quadro 5): “Como você vê, a gente já deu muitos passos na organização da área, mas muita coisa fica para trás pela falta de tempo. Quase não há dias em quais fico tranquilo e quando aparece um, algum lojista já me liga” (gerente de projetos).

Na observação foi constatado que a maioria dos contatos ocorrem porque o lojista possui dúvidas técnicas a respeito do uso da plataforma VTEX ou porque deseja consultar o andamento do projeto. Uma vez que o gerente tiver estabelecido o cronograma, o mesmo é compartilhado com o cliente, mas vira rapidamente um documento obsoleto quando não atualizado. As necessidades anteriormente levantadas, de possuir estruturas facilmente atualizáveis, automatizadas e compartilháveis, são novamente confirmadas aqui. O estabelecimento de uma rotina de atualização do cronograma, para que o cliente possa, de forma autónoma, obter as informações a respeito do andamento do projeto, acaba sendo mais eficiente do que a necessidade de contatos pessoais de consultoria do status de um projeto pelas diversas partes interessadas. Esta situação reforça a importância do Requisito 1F, levantado em seções anteriores (“Os registros do andamento do projeto precisam estar visíveis aos interessados a qualquer momento, portanto a ferramenta escolhida para o acompanhamento precisa ser acessível a todos sem necessitar de reportes adicionais do lado da gestão de projetos”).

Assim, as reuniões com o cliente podem ser utilizadas para assuntos mais estratégicos e que agreguem diretamente à conclusão do projeto.

Ao analisar o cronograma, detectou-se que no início do projeto é recomendado ao lojista um vídeo introdutório à plataforma VTEX. Porém, o mesmo possui quatro horas de duração e é de uso dificultado para fins de consulta. Foi observado que a maioria dos lojistas não assistem a este treinamento. Por meio das análises documentais foi possível descobrir que a VTEX dispõe de um grande acervo de manuais a respeito do manuseio da plataforma, disponíveis na página help.vtex.com, e que a própria agência já desenvolveu manuais próprios. Estes documentos, se repassadas ao lojista nos primeiros contatos, ou junto ao treinamento inicial, possibilitam a ele consultar as informações a respeito de suas dúvidas específicas. Em casos extremos, é de se pensar em aumentar a estrutura de recursos humanos ou usar mais recursos compartilhados para atender dúvidas técnicas para que o próprio gerente de projetos seja aliviado e possa se dedicar a tarefas mais estratégicas para os projetos. Na agência analisada no presente estudo já existe um consultor da plataforma, em formato de recurso compartilhado. Caberia, nestas condições, ao gestor filtrar as dúvidas dos contatos com os clientes e direcionar as de cunho técnico para este consultor.

Conforme visto anteriormente, as tarefas atribuídas ao lojista possuem um papel fundamental para o prazo total de um projeto: “até porque não adianta eu alocar o desenvolvimento logo após o layout, mesmo se tivesse disponibilidade na fila. Normalmente o lojista demora um certo tempo para organizar suas partes então chegaríamos a um momento onde não teríamos como finalizar o desenvolvimento porque faltam por exemplo os meios de pagamento ou de envio” (gestor de projetos). Portanto, é importante que a ferramenta de gestão escolhida auxilie no adiantamento de etapas críticas do lado do lojista, para que possa ser estabelecido um contato pró-ativo, possivelmente por meio de um email padrão, tendo em vista a criticidade destas etapas: “às vezes também ele [o gestor de projetos] não sabe quais são as informações que faltam do cliente, isso acontece que precisamos lembrar ele. Quando eu não tenho essas informações não posso terminar certas partes” (desenvolvedor).

O último assunto a ser tratado, referente ao tempo dos projetos, é relacionado ao tópico 4) do Quadro 5: a sensação do time de estresse com os prazos dos projetos. Foram feito as duas perguntas “Como você percebe o tempo para o desenvolvimento dos projetos?” e “Você se sente sobrecarregado ou ocioso em certos períodos?” ao designer e ao desenvolvedor entrevistados. As respostas para a primeira foram: “é curto. Com alguns projetos corremos bastante para a entrega. Mas normalmente é okay. É curto, mas dá certo. Mas tem que dizer que com mais tempo às vezes

conseguiríamos entregar soluções melhores”, desenvolvedor, “eu não posso reservar horas para pesquisa, por exemplo. É importante eu conhecer o mercado de cada cliente, buscar por inspiração, conhecer a marca, como eu disse antes. E não consigo fazer testes quando estou apressado, preciso tomar as decisões muito rápidas, quando o trabalho criativo normalmente é algo que necessita dos testes visuais para validação”. Segundo os entrevistados é possível observar uma relação direta entre o tempo de desenvolvimento e a qualidade dos projetos e, conforme já foi tematizado na seção anterior e em relação ao escopo dos projetos, é possível perceber que o tempo economizado, por exemplo em pesquisas que poderiam ser realizadas para tornar os resultados do layout mais assertivos, muitas vezes é gasto em ajustes depois: “olha, com certeza. Se não na própria implementação, vem no contrato de evolução depois. E como vamos fazer esses testes depois e mostrar que realmente está ineficiente se nós mesmos desenvolvemos, sabe? Muito complicado isso” (designer).

Em relação à segunda pergunta, a respeito de tempos ociosos, as respostas são unânimes: “Isso já é mais raro. Sempre tem um projeto ou algum ajuste ongoing [em andamento]. Até queria estar mais ocioso - não ocioso no sentido da palavra, mas para poder ter um tempo e pesquisar e testar novas tecnologias, repensar um pouco nossas metodologias de trabalho”, “Às vezes sim [me sinto estressado]” (desenvolvedor), “sobras de tempo é mais comum haver nos períodos entre projetos ou entre as suas etapas - quando por exemplo um feedback está demorando para voltar para nós, por questões lá do cliente. Mas nunca ficamos ociosos, sempre tenho bastante coisa para estudar, testar, ajustar etc” (designer).

Resumidamente, não somente o tempo curto para desenvolvimento, mas também o tempo disponível para testes e pesquisas de tecnologias novas são percebidos de maneira crítica pelos colaboradores. Para poder compreender melhor os impactos positivos e negativos do tempo dos projetos, no caso de um projeto com prazo curto e no caso onde existe tempo para realizar as pesquisas e os testes citados, seria importante mensurar tanto o tempo gasto para desenvolvimento, quanto os resultados, considerando também os custos envolvidos, fator considerado para a elaboração do Requisito 5A, apresentado na seção seguinte. Conseguindo estabelecer relações entre estes três, tempo, resultados e custos, será possível obter uma base para conversas e decisões a respeito. Isto reforça a importância do registro das horas gastas nas diferentes etapas de um