Newton Wagner » projetos

TEDx Asa Sul – Evento e Talks

Newton Wagner — Fri, 11 Nov 2011 11:27:47 +0000

Aconteceu, no dia 10/11/2011, o primeiro TED da Capital Federal, com o nome de TEDx Asa Sul. Ficaria melhor TEDx Brasília, mas tudo bem.

Assim que fiquei sabendo do evento via Twitter corri pra fazer a inscrição, o que deve ter ocorrido com muita gente que gosta do modelo e assiste os vídeos dos TEDs pelo mundo no YouTube. A primeira surpresa foi descobrir que os participantes seriam selecionados com base em um questionário.

Depois de confirmada a Inscrição, a expectativa para o dia do evento.

As conversas rápidas realmente dão um dinamismo muito grande, e não cansam a platéia (pelo que parece, não dá pra dizer o mesmo para os palestrantes, rs). As boas apresentações passam num piscar de olhos, e até aquelas menos empolgantes, não demoram pra acabar. Vou comentar aqui as que achei mais interessantes:

Gestão de Pessoas

Primeira a subir ao palco, Janete Ribeiro dos Laboratórios Sabin, falou sobre Gestão de Pessoas, e o impacto no trabalho. Ela comentou sobre os impactos na empresa após a mudança do foco da Gestão de Processos para a Gestão de Pessoas. Números impressionantes como pouco mais de 300% na lucratividade nos últimos 5 anos, e apenas 3 processos judiciais trabalhistas nos últimos 10 anos (que ela fez questão de ressaltar que a empresa foi absolvida em todas elas).

Ela contou como a empresa faz essa gestão, através de envolvimento social e benefícios diversos. Outra grande revelação foi: "A empresa nem sempre precisa fornecer o benefício, mas facilitar para que ele chegue até os funcionários", citando o caso em que o Sabin contactou uma fabricante de Máquinas de Lavar pra facilitar a compra por seus funcionários.

Pessoas > Processos. Qualquer semelhança com o Manifesto Ágil, não é mera coincidência.

Tecnologia

Elcio Queiroz subiu ao palco pra falar sobre Tecnologia. E conseguiu transmitir de uma forma menos comercial que a da Itautec, como a IBM trabalha para o desenvolvimento de Cidades Inteligentes. Falou de programas como o de previsão de chuvas no Rio de Janeiro para evitar que catástrofes naturais peguem as pessoas de surpresa, como aconteceu recentemente naquele estado; e do monitoramento e acompanhamento das ocorrências nas cidades, com o exemplo do Centro de Operações do Rio de Janeiro, que, segundo ele, reduziu o tempo de atendimento de chamados de 45 para 3 minutos; dentre outras coisas.

Palestra inspiradora, que demonstra que empresas gigantes, como a IBM, podem contribuir de maneira muito positiva para o mundo. O número impressionante ficou por conta da alimentação, onde 40% da produção é desperdiçada antes mesmo de chegar aos consumidores.

Educação

Desde os meus tempos de escola, questionei alguns professores sobre o nosso modelo de ensino. Quando José Leão subiu ao palco pra falar de Educação e das Salas Interativas do Colégio Marista de Brasília, talvez poucas pessoas soubessem tudo que estaria por vir.

Pra começar, ele falou que Médicos e até Cozinheiros do passado que fossem ressuscitados hoje, não conseguiriam praticar suas profissões em um ambiente de trabalho moderno. Mas um professor do passado, colocado em uma sala de aula de hoje, não teria qualquer dificuldade.

Segundo ele, "as escolas estão viradas de costas para o Futuro". O modelo de ensino onde professores "narram-cobram", e os alunos "copiam-memorizam", já está ultrapassado (e eu concordo que a muito tempo), e precisa ser modificado. Pra mudar isso, ele propôs esta Sala de Aula Interativa, onde os alunos são desafiados e orientados. O primeiro resultado visível, foi o aumento do interesse nas aulas, onde os alunos, após o término da atividade, permaneceram em aula, sem qualquer supervisão ou ordem, trabalhando as atividades passadas por aproximadamente 1 hora.

E a escola do seu filho? Ainda é a Tia Mariazinha fazendo ele decorar a tabuada ou a tabela periódica dos elementos?

Startup DOJO

Após o retorno do Coffe Break, Fabrizio Buzeto subiu ao palco como "Speaker X" pra falar sobre o Startup DOJO. Ele apresentou alguns conceitos em torno do Lean Startup e sobre empreendedorismo em geral, e falou sobre a reunião de empreendedores digitais de Brasília que já tem 7 ideias em andamento.

Empreendedorismo

Marcelo Pimenta falou sobre perseverança e desistência nas nossas decisões durante a vida.

A frase que marcou a sua apresentação foi que a nossa limitação está apenas dentro do nosso cérebro. Mostrou experiências feitas pelo mundo em relação ao aprendizado, citando casos em que um computador foi deixado em uma região pobre na Índia sem qualquer material para estudo, e as pessoas aprenderam naturalmente a usá-lo, e outro no interior da Itália onde foi deixado um material a respeito da AIDS em Inglês, e ao retornarem meses depois, as pessoas mesmo sem o conhecimento da língua, teriam captado grande parte da informação.

Conclusão

Estão de parabéns os organizadores e palestrantes do Evento, que encararam um desafio de fazer um evento com a "marca" TEDx. A infra-estrutura do Colégio Marista conseguiu atender bem ao público presente e o Coffe Break foi de primeira linha.

Os temas abordados foram muito bons e com certeza muitas idéias que merecem, foram espalhadas para o público que ocupou todo auditório.

Como são raros estes eventos em Brasília, ficamos sempre torcendo para que não seja o primeiro... e único.

3 razões pra organizar projetos usando um Quadro (kanban)

Newton Wagner — Tue, 11 Oct 2011 20:28:54 +0000

Lembro quando popularizaram as metodologias ágeis para o desenvolvimento do software, quem olhava de fora tinha a impressão que pra fazer projetos ágeis, eram necessários milhares de Post-Its e muitas paredes ou janelas livres pra organizar os projetos (muita gente divulgava o ágil com uma foto de Post-Its na parede).

os agilistas trataram de afastar esse estereótipo pois, de fato, não são as ferramentas utilizadas que fazem um projeto ágil ou não, mas sim a forma de fazer (Execução), de acordo com o Manifesto Ágil.

Mas quais são os Benefícios de ter, como ferramenta, alguns penduricalhos de papel organizados em uma parede, quadro ou janela?

1. Visibilidade

Eu já falei aqui por que eu prefiro minhas atividades no caderno, pois ele estará sempre ao alcance da mão e dos olhos, pra me lembrar de todas as pendências que tenho pra resolver.

Com o controle das atividades expostos a todos, é como se tivéssemos um grande e coletivo caderno aberto. Todos os envolvidos podem ter uma visão de como as coisas estão, quais são os gargalos do processo, que precisam de atenção para melhorar a qualidade do desenvolvimento.

2. Facilidade de uso

Os cartões podem ser bem simples, de forma que novos integrantes na equipe, gestores ou clientes consigam visualizar e entender sem a necessidade de treinamento, "manual" ou softwares de gerenciamento de projeto.

O próprio quadro, quando bem utilizado e formatado, fornece uma representação gráfica do estado em que está o projeto. Simples assim.

3. Auto-organização e Colaboração

Consequência da visibilidade, a auto-organização deve acabar surgindo naturalmente. Se você tiver problemas do tipo: Gente sobrecarregada Vs. Gente desalocada, e o seu quadro permitir visualizar graficamente a alocação, a própria equipe vai ver essas diferenças e isso pode ajudar a criar uma cultura de colaboração.

Em equipes mais maduras, alguém desalocado pode se oferecer para ajudar alguém atarefado, e vice-versa. Em equipes menos maduras ou problemáticas, essa "exposição" pode facilitar o trabalho do líder em apontar os problemas e buscar soluções em conjunto com o time.

Você lembra de mais alguma vantagem? Compartilhe nos comentários.

Colaboração entre Cliente e TI ajuda no Desenvolvimento de Software

Newton Wagner — Mon, 03 Oct 2011 12:07:31 +0000

Houve o tempo em que os desenvolvedores de Software recebiam suas demandas diretamente dos clientes/usuários, e compilavam as regras do negócio para dentro de suas aplicações, sem documentação ou muita possibilidade de transferência de conhecimento.

Anos mais tarde, a falta de documentação destes softwares tornaram as empresas dependentes de seus desenvolvedores, que, caso saíssem, deixariam provavelmente um estado de caos. Assim nasceram as metodologias de software com bases na Engenharia, onde documentações, processos e muito planejamento tomou conta da "indústria", e passamos à denominação de "Fábrica de Software", em uma clara alusão ao processo produtivo de uma indústria comum (linhas de produção de software, no caso).

Isso resolveu alguns problemas, mas trouxe muitos outros, dentre eles: o fato do desenvolvimento ser uma atividade intelectual, e não pode ser medida dentro de um conceito de "Fábrica", de montagem de um veículo, por exemplo; O excesso de planejamento e burocracia, tornou o processo de desenvolvimento muito mais lento, e com o aumento da competitividade o tempo passou a ser fator crítico de sucesso para os projetos, inclusive de Software.

Foi aí que um grupo de grandes profissionais do desenvolvimento de software, como Martin Fowler (pra citar só o mais conhecido), elaborou um Manifesto para o desenvolvimento ágil de Software, em busca do equilíbrio entre estes dois mundos vividos anteriormente.

O que é bastante curioso, a primeira vista, é que o manifesto não trata apenas do desenvolvimento de software da área de TI pra dentro, mas sim de uma mudança cultural que deve atingir todos os envolvidos nestes projetos, valorizando:

Indivíduos e interação entre eles mais que processos e ferramentas;
Colaboração com o cliente mais que negociação de contratos;

Interação entre indivíduos, significa a proximidade (encontros "cara-a-cara" sempre que possíveis), disponibilidade e clareza nas informações. No desenvolvimento do Software, a área Cliente sabe quais são as suas dificuldades e necessidades, e a área de TI sabe como melhor consolidar estas necessidades e transformá-las em Software. A efetiva comunicação entre as duas áreas aumentará a qualidade do produto final.

A colaboração com o cliente é a transparência e confiança na comunicação entre ele e a área de TI, em uma via de duas mãos, comunicando sempre o progresso, informando aquilo que ainda não está claro, trocando experiências e trilhando sempre o caminho da qualidade.

Do manifesto, surgiram também alguns princípios, que também indicam como o comportamento colaborativo favorece o bom trabalho dos projetos:

Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diáriamente, durante todo o curso do projeto.
Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara.
Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.

Com tudo isso, podemos concluir que de fato um Time de Desenvolvimento de Software, não é composto somente por Gerentes de Projetos, Analistas de Sistemas e Desenvolvedores. É feito também pelos Clientes, Patrocinadores e Usuários. Cada um contribuindo com as informações que possuem para o objetivo final e bem comum: Software de qualidade e Ambiente sustentável.

PS.: Não deixe de ver o Manifesto completo, e todos os 12 princípios do software ágil.

Certificação Agile PMI e os PMPs de TI

Newton Wagner — Fri, 25 Feb 2011 17:30:50 +0000

O PMI anunciou em fevereiro/2011 sua certificação PMI Agile Certification, após um longo "namoro" que incluiu a criação de um grupo de estudo e declarações de pessoas influentes do PMI sobre Agile e Scrum.

O Instituto é reconhecido, principalmente, pela manutenção da Base de Conhecimento em Gerenciamento de Projetos (Guia PMBOK(r)), uma compilação das melhores práticas de mercado, que podem ser utilizadas em projetos desde a Construção Civil até o Desenvolvimento de Software.

Se a Base de Conhecimento é formada a partir das melhores práticas vivenciadas pelos membros do PMI no dia-a-dia de projetos, e os métodos Ágeis estão fazendo parte deste dia-a-dia e contribuindo positivamente para o sucesso dos projetos, nada mais óbvio que eles passam a fazer parte destas melhores práticas.

Das duas certificações existentes hoje, oferecidas pela Scrum Alliance e pela Scrum.org, a primeira é conseguida através da participação de um curso presencial, e a segunda é através da realização de um exame online. Ambos os casos certificam papéis específicos dentro do Scrum: Scrum Master, Product Owner, Scrum Developer e etc. Aparentemente, a certificação do PMI será sobre a filosofia ágil e como colocá-la em prática na visão de projetos.

Alias, um dos possíveis problemas que podem surgir, é justamente que o PMI irá definir "melhores práticas" do ponto de vista de um Gerente de Projetos, o que, para muitos "agilistas", por si só já é um problema, pois acredita-se que um time não precisa de gerentes de projeto, e que a equipe deve praticar o auto-gerenciamento.

Mesmo assim, consigo ver com bons olhos o fato do PMI ter lançado essa certificação. A área de TI precisa mudar para conseguir acompanhar as necessidades dos mercados, e os métodos Ágeis têm se mostrado bastante poderosos para trilhar este caminho. Ter o apoio de um instituto que é reconhecido por muitos profissionais, inclusive que ocupam cargos importantes nas empresas, pode fazer com que a filosofia Ágil ganhe muitos adeptos importantes para facilitar este processo de mudança cultural.

Temos de torcer (e auxiliar na evangelização) para que a certificação realmente promova esta mudança cultural, e não se torne apenas mais uma certificação obrigatória nos currículos para ocupar cargos de chefia nas instituições.

Metodologia Tradicional ou Scrum: Foco na Qualidade

Newton Wagner — Tue, 23 Nov 2010 11:30:13 +0000

Muitas empresas e profissionais defendem e comprovam sucesso através da utilização das metodologias hoje ditas "tradicionais", enquanto que, nos últimos anos, vemos uma forte expansão do interesse e uso das metodologias ditas "ágeis", igualmente defendidas através de casos de sucesso. O que nos faz pensar: Afinal, o que fez esses casos darem certo?

Nos últimos meses estive envolvido em um trabalho de atualização e implantação de uma metodologia de desenvolvimento de software no departamento de informática de um órgão público. A metodologia utilizada, apesar de ter suas origens no RUP, conta com influências da cultura ágil, contemplando um número reduzido de artefatos de projeto.

Por se tratar de uma instituição pública, onde naturalmente é mais difícil de se implantar uma nova cultura, e contar com um grande número de equipes e profissionais envolvidos, temos hoje diferentes níveis de maturidade e de aplicação da metodologia internamente. Há casos em que os processos são seguidos rigorosamente, porém os projetos não obtém sucesso, há casos de "caos" finalizados com sucesso e vice-versa.

O problema é que independente da metodologia, é preciso trabalhar a mentalidade dos profissionais, implantar uma cultura de qualidade, para que, independente de seguir a linha de processos tradicional ou ágil, as pessoas estejam focadas no seu trabalho, afetando diretamente a qualidade dos produtos e satisfação dos clientes.

Metodologias X, Y ou Z poderão ser implantadas de acordo com a realidade de cada caso. Implantar SCRUM sem uma participação ativa do cliente como Product Owner possívelmente levará o projeto ao fracasso. Implantar uma metodologia baseada em casos de uso com Analistas de Requisitos que não se façam entender pelo cliente e/ou pela área técnica, possívelmente levará o projeto ao fracasso.

Não se deixe enganar pela venda de Metodologias de Desenvolvimento: não existe Qualidade sem as pessoas. Antes de implantar uma metodologia, trabalhe com todos os envolvidos esta questão. Afinal, este será um fator de sucesso muito mais importante do que a metodologia implantada.

Utilizando Linha de base (Baseline) no MS Project

Newton Wagner — Thu, 29 Apr 2010 13:59:20 +0000

Um grande recurso do MS Project para o acompanhamento do andamento do projeto é a utilização das Linhas de Base (ou Baselines no termo em inglês), que permite comparar o que foi previsto no projeto com o que está sendo realizado.

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).

Certificação CAPM vale a pena?

Newton Wagner — Wed, 06 May 2009 15:54:42 +0000

Em meu caminho para direcionar minha carreira para a área de Gestão de Projetos, por ter pouca experiência atuando na área, resolvi procurar por alguma certificação para servir de guia (ou meta) nesse caminho, e me deparei com as certificações oficiais do PMI: CAPM e PMP.

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).

Briefing, Proposta e Contrato

Newton Wagner — Thu, 23 Nov 2006 11:45:03 +0000

Quando fiz meu primeiro site para um cliente, em 1999, briefing era eu sentado na sala do cliente ouvindo ele dizer que queria uma página com algumas informações a respeito da organização. Proposta era eu, na mesma reunião do "briefing" dizer quanto cobraria e quando entregava a página. Contrato, bem... a não ser que você considere um aperto de mão um contrato, não existia mesmo. .

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?

Por que é tão dificil encontrar bons programadores?

Newton Wagner — Thu, 23 Nov 2006 10:34:09 +0000

[atualização]Incrível, mas o artigo foi removido da base do Web Insider. Não sei se foi a administração do site ou o próprio autor, mas acho que não poderia ter sido feito nada pior.[/atualização]

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.

E por falar em projeto

Newton Wagner — Thu, 05 Oct 2006 17:53:02 +0000

Aproveitando que toquei no assunto Projeto aqui, vi no WebInsider uma ótima matéria sobre projetos em crise. Uma abordagem prática para projetos em crise, escrito por Marcelo Okano, nos mostra a dura realidade dos desafios encontrados na gerência de projetos, e que são muito mais frequentes do que a gente imagina. .

Vale a pena a leitura.

Newton Wagner » projetos

TEDx Asa Sul – Evento e Talks

Gestão de Pessoas

Publicidade

Tecnologia

Educação

Startup DOJO

Empreendedorismo

Conclusão

Artigos Relacionados:

3 razões pra organizar projetos usando um Quadro (kanban)

1. Visibilidade

2. Facilidade de uso

3. Auto-organização e Colaboração

Artigos Relacionados:

Colaboração entre Cliente e TI ajuda no Desenvolvimento de Software

Artigos Relacionados:

Certificação Agile PMI e os PMPs de TI

Artigos Relacionados:

Metodologia Tradicional ou Scrum: Foco na Qualidade

Artigos Relacionados:

Utilizando Linha de base (Baseline) no MS Project

Linha de Andamento

Artigos Relacionados:

Certificação CAPM vale a pena?

Artigos Relacionados:

Briefing, Proposta e Contrato

Artigos Relacionados:

Por que é tão dificil encontrar bons programadores?

Artigos Relacionados:

E por falar em projeto

Artigos Relacionados: