Para utilização da Linha de Base, primeiro é preciso entender que ela é uma Foto do seu planejamento, ou seja, como você planejou a execução do seu projeto. Você pode salvar baselines tanto para atividades específicas, como para todo o projeto, mas iremos trabalhar apenas o segundo cenário aqui.

O primeiro passo é criarmos um cronograma do nosso projeto, como neste exemplo:

Uma vez fechado o planejamento, podemos salvar a linha de base do nosso projeto acessando o menu “Ferramentas > Controle > Definir Linha de Base“, que irá nos levar até a tela abaixo.

Agora que já salvamos nossa linha de base, podemos visualizar em nosso cronograma no Project a linha de base ao lado do meu cronograma de andamento, através do menu “Exibir > Gantt de Controle”, passando a ter a seguinte visualização do gráfico:

Agora que temos a linha de base salva, vamos supor um andamento do nosso projeto, considerando a data atual como 28/04/2010 (linha pontilhada no Gantt). Vamos considerar que a Atividade A foi iniciada e concluída dentro do prazo, a atividade B não foi iniciada no dia, e terá o atraso de 1 dia em seu início, e a atividade C foi iniciada e está com andamento dentro do que foi planejado.

Já vemos agora no Gantt de Controle, uma distorção entre Planejado (barras pretas no Gantt) e o Realizado (barras azuis e vermelhas no Gantt), indicando claramente o atraso nas Atividades B e D:

Linha de Andamento

Outra forma de fazer o acompanhamento com a linha de Base além do Gantt de Controle, é utilizando a Linha de Andamento, acessada através do menu “Ferramentas > Controle > Linhas de Andamento”. Iremos configurar uma linha de base simples, em relação ao nosso Planejamento (“Plano da linha de base”), conforme tela abaixo:

Depois de configurada a linha de andamento, podemos ver no Gantt uma linha vermelha, cortando nosso cronograma na data atual e com marcadores do andamento para cada atividade:

• Atividade A: Concluída, sem marcador;
• Atividade B: Marcador recuado em relação à linha de andamento e à atividade, indicando atraso em relação ao planejado (Linha de Base);
• Atividade C: Marcador sobre a linha de andamento, indicando que a atividade está sendo executada dentro do previsto;
• Atividade D: Atividade futura, sem marcador.

Com a linha de andamento, conseguimos ter uma visualização rápida de como está o andamento das atividades em relação ao que foi planejado até a data atual, mas não conseguimos visualizar o impacto nas atividades futuras do projeto (neste caso, Atividade D).

A primeira certificação, é a de PMP, Project Manager Professional, dispensa comentários, pois é extremamente difundida no mercado de trabalho. Já a CAPM, Certified Associate in Project Management, foi criada pelo PMI em 2003 para profissionais envolvidos em projetos e jovens gerentes de projetos que ainda não atingiram os pré-requisitos para a PMP, exigindo apenas 1 ano de experiência de participação em projetos, contra o mínimo 3 anos de atuação como gerente de projetos da certificação PMP.

Nesse momento, como me encaixaria no grupo dos que ainda não possui os pré-requisitos para a certificação PMP, me perguntei se valeria a pena investir na CAPM. Pra responder a essa pergunta, resolvi dar uma olhada no mercado de trabalho.

Realizando uma pesquisa no portal de empregos Catho Online, sem qualquer outro filtro além da palavra chave “PMP” , obtive 107 ofertas como resultado. Ao realizar pesquisa semelhante com a palavra chave “CAPM”, nenhum resultado foi encontrado. O mesmo cenário se repetiu em outros dois portais de empregos, CEVIU e EmpregosTI.

Um pouco surpreso com o resultado da pesquisa, aproveitei o contato com uma figura conhecida no mundo de Gerenciamento de Projetos, e fiz para ele a mesma pergunta que havia feito pra mim mesmo: CAPM vale a pena?

A resposta foi positiva, mas com algumas ressalvas.

A ressalva é que o mercado brasileiro ainda não absorveu a certificação CAPM e, por isso, não encontramos vagas específicas para esse tipo de certificado. Então, mesmo com essa certificação você não garante uma vaga para atuação como Gerente de Projetos, tanto quanto um certificado PMP, no mercado de trabalho.

O argumento positivo é, de certa forma, o genérico para certificações: indicativo de interesse pelo assunto; comprometimento e capacidade de aprendizado para aprovação na prova. Isso significa que, se você está atuando como líder técnico, por exemplo, e quer partir para a área de Gestão de Projetos, então uma boa forma de demonstrar isso para seus líderes ou futuro empregador, é tirar uma certificação (CAPM) que demonstra o seu interesse e comprometimento com um modelo reconhecido pelo mercado (no caso o Guia PMBOK).

Perceba que a idéia, e o destaque, são os mesmos da UML, ou seja, foco no usuário do sistema, visão do usuário do sistema, para que ele possa entender o que está sendo feito e interagir.

Assim como aconteceu com BPMN, estou só estudando, mas acho que dessa vez, em breve, vou praticar um pouco mais a aplicação da APF, e aí vejo a possibilidade de passar algumas informações mais relevantes sobre o assunto. Por enquanto, seguem alguns links para estudos:

• IFPUG – International Function Points User Group;
• BFPUG – Brazilian Function Points User Group;
• Fatto Consultoria e Sistemas: Este site contém um FAQ e outras informações sobre APF;
• Compare Preços do Livro: Análise de Pontos de Função: Medição, Estimativas e Gerenciamento de Projetos de Software, ISBN 8571948992;

Porém, a motivação de escrever este post não veio do evento em si, mas sim de algumas das impressões sobre o evento do Daniel Costa.

A primeira é o fato da apresentação da codificação em ASP.NET 2.0 no Visual Studio. Concordo com o Daniel quando ele diz que este tipo de programa não garante qualidade de código. Porém, o mercado hoje está em busca de produtividade, afinal de contas, o usuário não se importa se você fez uma série de IFs aninhados, ou se separou a lógica do programa em métodos e etc. E aí o Visual Studio aparece como uma poderosa ferramenta de apoio ao desenvolvimento, assim como o Delphi para PHP, anunciado pela Borland, pode se tornar uma.

A segunda foi a leve crítica feita ao PHP-DF, que segundo ele está demorando pra sair. Não, não vou defender o grupo nem a posição do Daniel, mas é interessante notar que esse tipo de coisa a Microsoft e a Sun sempre saem na frente, até mesmo na produção de ferramentas de qualidade, que é o investimento. Os próprios integrantes do BrasilDotNet revelaram ter algum, pequeno, apoio da Microsoft, enquanto isso dezenas de empresas são parceiras da Sun pra divulgar o Java, mas a Zend não oferece nenhum tipo de incentivo pra eventos relacionados ao PHP.

Pra terminar, achei interessante as palestras, apesar de terem sido muito corridas. Os próximos eventos que pretendo ir é o 1º PHPDF Pocket e o CodeGear Delphi Tour 2007, onde será apresentado o Delphi for PHP dia 27.

A diferença entre as duas é que a primeira foi feita exclusivamente para relatar os Processos de Negócio, deixando de lado alguns (poucos) tecnicismos que encontramos na segunda, como os Includes e Extends, que podem dificultar o entendimento do fluxo de um processo.

Pelo que li até agora, não existem segredos na notação, mas não sei dizer o quão difundida ela esta no mercado. Essa semana vou receber um treinamento sobre isso, e se pintar alguma coisa realmente interessante eu conto por aqui.

Começando com uma introdução à orientação a objetos e passando pela descrição notação da UML, o autor então dá uma visão de cada fase do projeto e explica, através de exemplos, como escrever casos de uso e diversos diagramas UML utilizados durante o processo. Além disso, no decorrer do livro, são passados alguns exercícios, pra você praticar.

Fica a recomendação de uma ótima referência para quem está começando no assunto. O livro está disponível no Submarino.

Com a idéia de voltar a trabalhar como “freelancer meio-expediente” rondando minha cabeça, me peguei lembrando da evolução, não só técnica, mas também dos procedimentos de trabalho ao longo destes 7 anos. Muito deste aprendizado foi através dos meus próprios erros, outros foi observando a experiência alheia e, como não poderia deixar de ser, aprendi muita coisa também com os livros.

E você? Como vai indo?

Em artigo publicado no Web Insider, Marcelo Okano (já citado aqui anteriormente) nos dá a visão das agências na contratação de programadores, fazendo a pergunta: Por que é tão difícil encontrar bons programadores?

O artigo começa muito bem, falando sobre as complexas questões do mercado de trabalho na área de desenvolvimento, porém, depois o autor inicia uma série de generalizações, indicando uma marginalização dos profissionais da área.

Não vou me aprofundar nos trechos que dizem coisas como: passou pela cabeça do programador limpar as bases de dados e apagar os arquivos. Se passou pela cabeça do programador, poderia ter passado na cabeça do médico, do eletricista, do mecânico e de qualquer profissional picareta que existe por aí. É preciso lembrar que esse tipo de atitude não está relacionada à área profissional, e sim à pessoa.

Eu credito essa “dificuldade” de se encontrar bons programadores, ao próprio mercado, que atravessa uma fase de carência por profissionais, gerando uma enorme quantidade de oportunidades. Quem oferece as melhores condições de trabalho, fica com os melhores profissionais, e é aí que as agências podem estar encontrando tal dificuldade. Olhando de fora (nunca trabalhei em agência), eu acredito que o profissional disputado entre as agências sejam os publicitários.

Sendo assim, as agências, ao invés de contratar estagiários ou programadores inexperientes acreditando que eles conseguirão gerenciar um projeto de desenvolvimento do dia pra noite sem cometer erros, deveriam buscar outros caminhos, como terceirização ou até mesmo investir na área, montando uma pequena fábrica de desenvolvimento própria. Depende do custo/benefício de cada solução.

Vale a pena a leitura.

É comum, principalmente na área de TI, colocarmos a culpa sempre nos clientes (ou usuários), mas, na verdade, existem técnicas mais ou menos adequadas para ultrapassar esta barreira e captar estas informações, mesmo em clientes mais “problemáticos”, ou em casos que muitas pessoas sejam influenciadoras ou influenciadas pelo projeto. Conheça um pouco sobre estas técnicas:

Entrevista

A entrevista deve ser feita, preferencialmente, com usuários mais comunicativos e com bom conhecimento do processo. Evite entrevistas com longas horas de duração, o entrevistado pode se desmotivar, causando queda de produtivadade do levantamento de requisito. Sempre planeje sua entrevista e anote tudo.

Brainstorming

Muito útil quando existem diversos interessados no projeto. É dividido em duas etapas. Na primeira, anota-se todas as idéias que surgirem, sem que sejam questionadas. Neste momento o que importa mais é a quantidade, não deixe de anotar nada. Na segunda etapa, debate-se com o grupo para ir refinando as idéias apresentadas anteriormente. Deixe as regras bem claras, e defina uma pessoa (facilitador) para “comandar” a reunião, para garantir que as regras sejam respeitadas.
No Brainstorming, você não precisa de usuários comunicativos, utilizando anotações anônimas para a divulgação das idéias, você atrai até os mais tímidos para a participação da tarefa. Aqui você pode, também, identificar as pessoas mais participativas e agendar entrevistas.

Role playing

Esta técnica consiste em observar o usuario executando determinada tarefa, no dia-a-dia do seu trabalho, ou, até mesmo, você fazendo o trabalho deste usuário, para identificar suas dificuldades e necessitades, sentindo na pele como é realizar a tarefa. Muito útil quando o usuário não consegue identificar ou transmitir as informações necessárias para a identificação dos requisitos.