Introdução às Tarefas

Olá! Se você chegou aqui nessa página é porque provavelmente é seu primeiro projeto com a Alpina como desenvolvedor. (Se não for também, fique à vontade para rever toda a lista de processos, revisar é sempre bom).

Como é o processo?

O processo começa no setor de Novos Negócios, quando eles fecham a venda do projeto. É gerado então um escopo de tudo que o projeto irá conter, e o projeto passa para as mãos de uma pessoa que ficará responsável por criar o conteúdo do site.

Na Criação de Conteúdo serão estabelecido os esqueletos. São definidas quantas e quais páginas farão parte do projeto, assim como todo o conteúdo interno destas páginas: Quantas e quais seções, os textos, onde terão botões, formulários, sugestões de imagens, entre outros itens.

Logo após, o projeto adentra de fato dentro do time de Projetos, nas mãos do designer, que é quem irá fazer toda a composição visual do projeto, dar um corpo e um rosto àquilo que até então era somente um esqueleto.

Quando o designer aprovar todo o layout com o cliente, o projeto então estará apto a ganhar um desenvolvedor.

Depois de tudo desenvolvido, o projeto segue o baile para a Equipe de Suporte, que será sua morada final dentro da Alpina.

Nesta documentação iremos falar de todos os processos que um projeto passa enquanto está na mão de um desenvolvedor.

A pasta do Cliente

Como falamos na seção anterior, o projeto passou por vários setores antes de chegar na mão do desenvolvedor. E não tenha dúvidas que cada pessoa que trabalhou no projeto deixou a sua marca.

A primeira dessas marcas é a pasta do cliente. Esta pasta conterá todas as informações que você precisa (e até mesmo não precisa) saber sobre o projeto que você executará.

O alaska-PROJETOS

Se você faz parte do time de Projetos da Alpina, o caminho para encontrar todas as pastas dos clientes é entrando no seu drive da Alpina, e indo para a aba de Compartilhados comigo.

Um dos itens que deve aparecer é a pasta chamada alaska-PROJETOS. Dentro dessa página teremos logo no topo uma pasta para os clientes antigos, onde estarão aqueles com projetos já finalizados e entregues à equipe do Suporte.

E então teremos em seguida todas as pastas do cliente em ordem alfabética, como podemos ver nesse exemplo a seguir:

nota

Se você está trabalhando como freelancer, esse provavelmente não é um acesso que terá. Em vez disso, você terá um link direto para a pasta do cliente específico.

O cliente em si

Ao entrar na pasta de um cliente específico, é assim uma aparência aproximada que ela terá:

Vemos ali uma pasta chamada de 01. Início e outra página chamada 02. Conteúdos. Nesta, temos até ali embaixo mais alguns arquivos, que já não serão de nossa alçada, apenas as duas pastas serão de nosso interesse.

info

Enquanto o projeto roda na mão do desenvolvedor, poderá ser necessário criar uma pasta chamada 03. Dev para armazenar seus arquivos importantes. Por exemplo alguma chave de API criada.

A declaração de escopo

A pasta 01. Início terá, como o nome diz, as tratativas iniciais do projeto. Nessa pasta, nosso grande interesse será o famoso Escopo do Projeto. Haverá um arquivo com os dizeres BASE - Declaração de Escopo, e a responsabilidade do desenvolvedor é zelar por ele.

Tudo que for feito durante o projeto deve ser analisado se está dentro do escopo, para que tudo esteja cumprido corretamente como foi contratado, e não seja feito nem menos nem mais do que o que está ali.

Leve sempre o escopo debaixo do braço.

info

Pode ser que haja mais de um arquivo de escopo nesta pasta, seja porque o escopo foi atualizado em versões mais novas ou até porque haja mais de um projeto em paralelo do mesmo cliente. Certifique-se de estar com o escopo correto.

Os conteúdos

Dentro da pasta 02. Conteúdos teremos dois caminhos, um levando para os arquivos enviados pelo cliente e outro para os organizados pela Alpina.

Na pasta 01. Enviados pelo Cliente teremos realmente tudo que o cliente tiver enviado dele que quiser utilizar no projeto como marcas, fotos, textos.

Geralmente o foco aqui para o desenvolvedor será a pasta 02. Organizados pela Alpina, que contém os arquivos de conteúdos do site organizados por uma pessoa especializada.

info

Alguns projetos, geralmente mais básicos, não passam pela etapa de Organização de Conteúdo, então essa organização é feita pelo próprio designer no que ele envia pelo Figma.

Os famosos conteúdos organizados

Nessa pasta teremos toda a estrutura de páginas do site, tal qual é passado para o designer quando ele fará seus desenhos. Grande parte desse conteúdo já estarão representados nas telas quando o designer entra o projeto no Figma para você.

Mas tem informações que não podem ser simplesmente representadas pelo formato visual, como por exemplo o SEO, então tudo que você precisará saber de adicional sobre a páginas do site estarão aqui.

Aqui neste exemplo você pode ver como Fulaninha da Alpina organizou o conteúdo do site do cliente Lojas Fulana de Tal:

Temos ali 01. Home que é o arquivo que contém toda a estrutura da página inicial do site.

Já a página 02. Nossa Empresa é uma página que mostra um conteúdo institucional da empresa.

No item 03. Marcas Distribuídas vemos que existe um subitem 03.1. Esse vai ser o caso de muitos projetos, pois páginas podem ter subpáginas dependendo do tamanho do escopo.

Sobre os conteúdos organizados é basicamente isso. De resto é acessar esses arquivos e entender o que tem dentro.

O Figma

Todos os projetos são desenhados usando o software Figma. Então o designer ou o gestor irá sempre passar um link do Figma do projeto atual.

O projeto no Figma é somente leitura, então você não poderá fazer nenhuma edição. Sabemos que às vezes é preciso ter algum poder de editor para agilizar alguns processos de exportação, então você poderá criar uma cópia de rascunho do projeto para você, sendo esta totalmente editável.

Mas não recomendamos que se apegue a esta sua cópia, pois o projeto pode ter várias edições enquanto você desenvolve, e você estará simplesmente sentando sobre uma cópia obsoleta. Se possível, apague após utilizar tudo e crie outra quando precisar de novo.

Como novas abas e telas podem ser criadas no Figma enquanto você desenvolve, sempre se certifique de estar olhando a última versão do projeto. O designer ou gestor avisará a você quando tiver alguma mudança no projeto. Além de que você mesmo poderá solicitar essas mudanças.

O RunRun.it

O RunRun.it é a plataforma online que usamos para registrar as horas em cada tarefas. Basicamente tudo que é feito nas suas horas de trabalho no dia deve estar registrado lá.

atenção

Não estamos mais atualmente usando o RunRun.it. Mas para efeitos de aprendizados, e enquanto não utilizamos o novo sistema, manteremos essas seções abaixo.

Visão geral das tarefas

A interface do RunRun.it é muito simples e direta, você vai logar em sua conta e vai ter as tarefas que foram atribuídas a você. Essas são as atividades que estão em aberto para o desenvolvedor Zezinho Silva, por exemplo:

As tarefas todas terão um número diferente e estarão atribuidas a um cliente. Algumas serão de Alpina - Cliente Interno, como é o caso da tarefa ali de Realizar reunião - Daily, pois são tarefas executadas internamente para a própria Alpina. Clicando em cima do nome da tarefa, você poderá saber mais detalhes sobre ela.

Continuando na análise da imagem, vemos que existe um botão de PLAY. É ali que clicamos para dizer que estamos iniciando uma tarefa. Depois ele se transformará num botão de pause, que apertamos para dizer que iremos parar de trabalhar naquela tarefa. Ao lado do play vemos ali um CHECK, é ali que apertamos para dizer que estamos entregando a tarefa. Tudo bem intutivo.

Aí seguimos com o contador de horas trabalhadas ao lado, depois uma bandeira e um calendário. Essa bandeira nunca é utilizada em nossos processos. Já o calendário é onde o gestor irá colocar o prazo da tarefa, portanto não cabe ao desenvolvedor mexer nesse item.

Do lado tem 6 ícones cinzas que são representações de ícones que a tarefa pode ter. Um dos ícones que poderá estar ativo nas tarefas é o de checklist, que irá indicar que aquela tarefa tem uma série de passos que devem ser executados e marcados antes da entrega da tarefa, como é o caso da segunda tarefa.

Adiante tem a expectativa de duração da tarefa. Como cada projeto é um, nem sempre essa expectativa pode estar de acordo com o que você irá executar, podendo estar muito abaixo ou muito acima. Então se prepare para ver muitos valores irreais.

Por fim, há um seletor de etapa. Esse daí, como em outros casos acima, também estará só de enfeite.

Prazos e entregas de tarefas

Ao entrar em um projeto, você receberá todas as tarefas relacionadas ao projeto. Podem ser todas as tarefas, do início ao fim de enquanto projeto estiver em suas mãos, ou podem ser tarefas apenas da etapa do projeto em que você está. Mas o fato é que um dia todas estarão com você.

Logo que você iniciar, possivelmente nenhuma tarefa terá prazo, pois você ainda não definiu nada com o gestor. Mas logo esse dia irá chegar.

A dica antes de dar um prazo é sempre analisar bem o projeto. Abra o Figma, veja quantas páginas serão feitas, e qual o tamanho de cada uma delas. Entenda qual é a complexidade do projeto, o quanto ele vai demandar de você.

Faça algumas dessas perguntas em sua mente:

• Existe algum componente visual muito complexo para se montar?
• Precisaremos de animações muito rebuscadas de CSS?
• Criaremos muito comportamentos JavaScript ou de AJAX novos ou avançados?
• Desenvolveremos um backend muito rebuscado e/ou muito específico, focado para esse cliente?
• Teremos que implementar alguma funcionalidade nova que não existe em outros projetos?
• Usaremos algum plugin de WordPress inédito?
• No geral aproveitaremos pouca coisa de projeto anteriores?

Tendo a resposta para a maioria das perguntas, você deve partir para a mesa de negociações com o gestor e fechar um prazo com ele, dizendo quantos dias úteis você acredita ser necessários para a execução do desenvolvimento do projeto.

Quando uma tarefa tem uma data de entrega, ela irá aparecer de onde tem o ícone da bandeira, como é o caso de algumas das tarefas aqui que foram entregues pelo desenvolvedor Zezinho Silva, onde apenas uma delas foi entregue sem ter sido definida uma data limite:

Reabrindo tarefas

Reabrir alguma tarefa não é um procedimento padrão, quando uma tarefa é entregue, ela está completa.

O próprio RunRun.it trata a pessoa como um criminoso, e remove pontos no ranking de um usuário que reabre tarefas. Então mesmo que ali exista um botão para reabrir uma tarefa, não busque apertar esse botão por sua conta.

Mas claro, no dia-a-dia de uma empresa, várias demandas são reabertas. Quando é esse o caso, você deve pedir ao gestor que reabra para você alguma tarefa para que você possa executar alguma demanda que não estava prevista no momento daquela entrega.

Já se for por algum acidente ou imprudência... Bom, avise do mesmo jeito.

Estou sem tarefas

Você está trabalhando no projeto do XYZ Advogado, e chega o gestor e pede para que dê uma olhada para ajustes alguns itens no projeto do Siclano Moda. Mas aí você não tem nenhuma tarefa desse segundo projeto. Ou porque já entregou tudo ou porque nunca nem trabalhou no projeto do Siclano.

O procedimento é que você peça alguma tarefa ao seu gestor para poder atuar nessa demanda. Ou que ele indique em qual tarefa você irá registrar essas horas.

Não saia cumprindo demandas sem saber para que local devem ir essas horas.

Esqueci de dar o play

O clássico dos clássicos é esquecer de dar o play em alguma tarefa. Bom, todos somos humanos.

A recomendação principal é que você tenha um alarme para as 9:00 que te lembre de ligar o RunRun.it todos os dias.

Quando você precisar trocar de uma tarefa pra outra, fica mais complicado. Terá que realmente estabelecer uma rotina de não iniciar uma tarefa sem antes visitar o RunRun.it.

Se realmente foi esquecido, você irá ter que realizar o processo manualmente de alocar horas na tarefa. Até porque o RunRun.it irá te encher o saco de que você não registrou horas suficientes naquele dia e não deixará fazer nada até corrigir.

Mas o registro manual não é o apropriado. Sempre o registro deve ser feito apertando o play.

Desligue o play!

Ao terminar o expediente todos os dias, o mesmo play que está ligado na tarefa deve ser desligado, sinalizando que você parou de trabalhar.

Embora o play não conte horas quando você não está em horário de trabalho, e fique com um ícone mostrando um pause forçado, internamente ele conta essas horas como adicionais.

Então imagine que enquanto você dorme ou passa o final de semana viajando, o cronometro está lá rodando a torto e direito.

Se um projeto que foi feito em 15 dias úteis estiver com o play ligado para sempre ele estaria contando todo o trabalho como 21 dias.

O mesmo alarme que você coloca no início do dia, coloque aqui também.

Interferências no projeto

É comum que durante a atuação no projeto surjam outras demandas em diferentes projetos, ou agendas de reunião para discutir assuntos diversos.

Se situações como essas forem muito constantes ou tomarem muito de seu tempo, que deveria estar dedicado a esse projeto, você deve procurar o gestor para discutir um acréscimo de tempo no prazo de entrega.

Não demore, procure logo que você souber que precisará de um prazo.

Conclusão

Dito tudo isto, nas próximas páginas desse tutorial focaremos em tarefas individuais que fazem parte do dia-a-dia do desenvolvidor na Alpina.

Destrincharemos em miúdos quais tarefas você precisará executar e entregar em cada etapa do processo de desenvolvimento. Até lá!