Um produto por semana

Para atender a demanda de um cliente decidimos aplicar uma técnica de criação rápida de um produto. Ele precisava de uma ferramenta de otimização de feeds e widgets, permitindo encontrar novos parceiros – indo um passo a mais de distância que o Urchin ou Analytics.
Duas semanas depois, o Probe estava no ar atendendo as requisições internas e gerando estatísticas importantes sobre parceiros de qualquer empresa. Mas o que permitiu entregar um produto tão rápido?
Fugindo do brainstorm
A idéia do produto já havia sido discutida internamente na Caelum entre diversas pessoas, o que amadurece a mesma, permitindo cortar idéias não triviais que seriam danosas a uma primeira entrega. Esse período não foi um brainstorm onde determinadas pessoas sentam numa mesa e discutem ao máximo determinado assunto, tentando chegar na visão ótima do que seria seu produto. Pelo contrário, isso não seria nada ágil.

Não existe e consequentemente é impossível alcançar algo perfeito, adaptamos o que temos para chegar o mais próximo do idealizado.

Discutir no dia a dia a idéia com diversas mentes que entendem um pouco ou muito do assunto amadurece aos poucos a visão que temos do produto.
A interface
Por mais que alguns projetos com os quais os usuários interagem possam ser tocados sem wireframe, para evitar dúvidas pontuais de CSS, usabilidade etc, utilizamos um design pronto (simples, intuitivo e direto), economizando tempo de pesquisa e encaixe pois as lógicas já eram criadas no design final.
Fazer o mínimo possível
Com o design em mãos e uma visão razoável do que queremos, escolhemos as funcionalidades mínimas para ter um produto que entregue algo que os produtos similares (Feedburner, Analytics etc) ainda não fazem. Essas funcionalidades, um subconjunto de histórias, foi definido como o objetivo ideal de entrega: o que deixaria o produto um passo a frente dos concorrentes.
Além disso, o PO possuia uma data de entrega, quando o sistema deveria estar no ar, que só ele conhecia. E aí entra a questão: se a data e o escopo estão fixos, perderemos qualidade.
Excluindo funcionalidades
Para fugir da perda de qualidade, o escopo era ideal, mas não fixo. Se fosse possível entregar tudo o que o PO desejava, ótimo, se não, ele deve estar pronto para lidar com o que foi entregue. Durante essa fase, o PO é capaz de rejulgar o escopo.
Após poucos dias, algumas funcionalidades foram cortadas, pois ficou claro que a ferramenta já entregaria valor suficiente com menos do que originalmente pensado para o primeiro release.
Excluindo funcionalidades
Mais alguns dias e novamente outras funcionalidades se apresentaram desnecessárias, junto com a maior importância na data de entrega do que no escopo a ser entregue. Com isso, menos funcionalidades (menos valor) seriam feitas, mas teríamos um produto que retorna valor em breve.
Priorizando o backlog
Priorizar o backlog adequadamente foi outra ação fundamental para entregar o máximo de valor possível no produto desenvolvido.
Excluindo funcionalidades
A equipe não possui um comprometimento com um escopo em uma data específica, portanto é responsabilidade do PO escolher o que é melhor ser entregue nesse período, isto é, priorizar corretamente.
Foram mais de duas vezes durante o período de desenvolvimento que cortamos funcionalidades. Em todas elas ganhamos tempo pois entregaríamos algo usável antes do planejado.
Equipe mínima
Em um início de produto tão rápido, é necessário manter uma equipe pequena pois qualquer burocratização do dia a dia de desenvolvimento levaria tempo demasiado para encaixar-se nas poucas horas. No nosso caso, existiam dois desenvolvedores e sentimos que em um grupo de até três, talvez quatro, seria possível fazer um trabalho similar.
Qualidade
Apesar de usar as práticas mais educadas possíveis, houve uma queda na qualidade, algo que o PO teve que pesar: após as 64 horas de desenvolvimento (2 pessoas, 4 dias úteis), tivemos mais 60 horas para investir somente em testes e refatorações.
A partir daqui, o desenvolvimento deve ser feito seguindo todas as práticas que acreditamos, sem margem para entregas rápidas como essa primeira pois a complexidade desse trabalho aumenta muito.
Pareamento e isolamento
A equipe se manteve razoavelmente distante de outras equipes de desenvolvimento e combinou pareamento com programação não pareada. Houve um equilíbrio de forças, misturando a propriedade coletiva do código com a produtividade que foi necessária. Novamente, após essa primeira entrega, abrir mão do pareamento se torna inviável.
Cliente ao lado
A qualquer instante os desenvolvedores tinham acesso ao PO e o cliente, tomando alguns cuidados. Esse é um ponto a ser defendido a todo custo se a entrega de uma versão inicial seguirá esse padrão. A qualquer instante o cliente poderá remover histórias desnecessárias ou solucionar problemas.
Na continuidade do projeto, isso já se torna diferente, uma vez que não esperamos re-priorizações dentro de sprint ou um cliente 100% liberado para os desenvolvedores.
Outros
Existem daily meetings, feedback rápido etc, como as práticas ágeis defendem.
A entrega
Após ter entrado em produção notamos que o tempo todo de desenvolvimento, o foco estava voltando na entrega de algo utilizável, algo com valor para o cliente, que no dia seguinte já poderia colocar em produção.
Deixamos um front end aberto da aplicação para quem desejar visualizá-lo, apesar do back end envolver funcionalidades ligadas com REST, feeds, widgets etc que não estão visíveis no mesmo.
Resumindo
O primeiro release de um produto pode ser feito com práticas ágeis que fujam um pouco da qualidade máxima que tentamos atingir, viabilizando uma entrega rápida – mas não necessariamente ágil a todo instante – e valiosa.
Mas nada disso serve como desculpa para manter o desenvolvimento do produto dessa maneira posteriormente: a preocupação com a qualidade deve voltar ao máximo e a partir desse instante um método de desenvolvimento mais formal (como Scrum, Lean etc) deve ser seguido.

Gestão Ágil de Portfólio de Projetos: A nova fronteira da produtividade estratégica nas organizações

Nós, agilistas e engenheiros de software, estudamos muito acerca de como organizar e gerenciar um projeto, desenvolver o software, testá-lo, implantá-lo, etc. Focamos bastante em como maximizar o retorno e o valor dos requisitos e fuincionalidades geradas em um projeto de software. Mas será que estamos perguntando se o projeto em si gera valor para a organização? E mais que isso: será que esse projeto em particular gera mais valor que um outro projeto, que pode estar sofrendo problemas por falta de recursos?

A próxima fronteira para aumentarmos a otimização de valor para as organizações é subir um degrau acima: tratar sobre a gestão ágil de portfólio de projetos e sua ligação com a estratégia da empresa.

Alguns números muito interessantes (e impressionantes) ajudam a mostrar a realidade do mercado de TI:

- Gastos de TI podem representar até 70% dos investimentos de capital em algumas companhias fortemente dependentes de TI
- 84% das organizações não montam um business case profundo e realista para seus projetos de TI
- 89% das organizações estão voando às escuras, com poucas ou nenhuma métrica financeira relevante e cruzada com aspectos estratégicos
- 83% das organizacões não conseguem ajustar seus orçamentos com as necessidades de negócio em períodos menores que um ano
- 40% dos projetos de software entregues provaram-se não econômicos e não geraram um retorno positivo sobre o investimento. Resumindo: pagaram mais para desenvolver o software que receberam por ele.
- Em torno de 23% dos projetos de software são cancelados sem entregar valor nenhum.
- Segundo Maizlish e Handler, em média apenas 1 dólar de cada 14 dólares gastos pelo orçamento de TI conseguem ser correlacionados com benefícios claros de negócio.
- De acordo com Tockey, 54% de todos os projetos de software são contraprodutivos do ponto de vista financeiro e econômico. Isso significa que em mais da metade do tempo, organizações que pagaram para desenvolver software estariam melhor financeiramente sem eles! 

Esses números impressionantes mostram que muitas organizações estão sofrendo uma hemorragia geral em seus gastos de TI. Muito disso se deve a:

- Vários projetos "pessoais" - isto é, realizados porque são favoritos pessoais de alguém e não porque foram analisados e aceitos como importantes dentro de um portfólio
- Relutância em matar projetos iniciados, mas percebidos posteriormente como de valor negativo ou baixo para os acionistas
- Muitos projetos ativos e um backlog gigantesco de projetos
- Miopia e foco na tecnologia pela tecnologia dentro dos departamentos de TI
- Critérios inexistentes, inconsistentes e incompletos para avaliar investimentos em TI
- Falha em estimar o Total Cost of Ownership, entre outras variáveis de custos
- Governança inadequada

Outro dado fundamental, analisado e estudado por Preston Smith no capítulo 11 (Preventing Overloads) do livro "Developing Products in half the time": sobrecarregar o portfólio de projetos dilui diretamente o esforço e cria filas, o que aumenta os prazos e os custos dos projetos. Isso significa que a falta de controle do portfólio de projetos é uma das causas-raiz do estouro de custos e prazos em projetos.

Esses dados e números reforçam um aspecto que muitas vezes negligenciamos: a disciplina da gestão de portfólio de projetos (preferencialmente ágil) é tão ou mais essencial para o sucesso dos projetos de uma organização do que apenas o uso de um processo ágil de desenvolvimento de software focado em melhorar a produtividade e qualidade dentro de um projeto.

Devido à relevância e amplitude do assunto project portfolio management tratarei sobre ele em vários outros artigos nesse blog. Aproveito para conceituar já aqui os objetivos da gestão de portfólio de projetos, alguns temas que apóiam essa disciplina e listar alguns livros iniciais para direcionar aqueles que perceberam a necessidade dessa disciplina em suas organizações.

A gestão de portfólio de projetos é um processo dinâmico de decisão em que a lista de projetos ativos e novos é constantemente revisada. Novos projetos são avaliados, selecionados e priorizados a partir de técnicas, métodos e critérios definidos pela organização. Projetos existentes podem ser acelerados, eliminados ou despriorizados. Recursos podem ser alocados e realocados pelos projetos.

Podemos resumir que a falta da gestão de portfólio de projetos em médias e grandes organizações significa que: há muitos projetos na organização, uma falta de foco, nenhum ou poucos critérios de seleção (projetos são selecionados na emoção ou por jogos políticos) e nenhum critério estratégico para a seleção de projetos. Esses pontos resultam em: maiores taxas de falhas em projetos e prazos mais longos de término de projetos, poucos produtos e softwares vencedores do ponto de vista de valor e falta de alinhamento estratégico nos projetos (o que gera efeito metralhadora: atira-se para todos os lados para ver se alguns dos projetos acertam!).

Algumas das ferramentas que serão tratadas nessa série de artigos:
- Ferramentas financeiras para avaliação de projetos de investimento e orçamentação de capital (capital budgeting)
- Pensamento sistêmico (Systems Thinking)
- Pensamento enxuto (Lean Thinlking)
- Ferramentas de pensamento da Teoria das Restrições (Theory of Constraints)
- Teoria das Filas

Relembrando: o gerenciamento pró-ativo do portfólio de projetos de uma organização pode trazer tantos ou até mais benefícios que apenas focar no processo de desenvolvimento e gestão de um único projeto. A gestão ágil de portfólio de projetos, juntamente com a gestão ágil de projetos com práticas técnicas, maximizará ainda mais o valor de cada dólar ou real investido e trará uma maior produtividade nos projetos certos. Isso transformará a TI da organização num centro de lucros e valor e não em um centro de custos e em uma commodity.

Por que Agile e Lean funcionam? Ou como explicar para seus executivos e líderes a hiperprodutividade que esses tais de agilistas conseguem!

Analisando as pesquisas sobre sucesso de projetos encontramos números interessantes. De acordo com o Chaos Report de 2009, em torno de 30% dos projetos de TI são bem sucedidos. Enquanto isso, surveys sobre Agilidade mostram que em torno de 80% dos projetos Ágeis terminam com sucesso. E mais que isso: empresas como a SalesForce.com obtiveram uma melhoria de quase 400% no valor gerado após a adoção da cultura Ágil, em torno de 70% de redução nos defeitos e 50% de redução no time to market para lançamento de novas versões de seus produtos.

Será mágica? Será Bala de prata? Não. Então como explicar os números impressionantes acima?

Vou tratar um pouco dos 'segredos' do Agile / Lean funcionar tão bem quando ocorre uma mudança de paradigma real dentro da organização.

Os dois pilares do Lean (e que podem ser encontrados também embutidos no Manifesto Ágil) são:
- Respeito pelas pessoas
- Melhoria contínua

Podemos resumir esses dois pontos nessa frase: "A raiz do Lean/Agile é ser um eterno insatisfeito com o status quo. Você tem que se perguntar continuamente: 'Por que estamos fazendo isso?' ". Portanto é possível compreender que o princípio de Eliminar desperdícios do Lean está umbilicalmente relacionado com o pilar positivo da melhoria contínua e da eterna insatisfação com a mesmice.

Mas vocês devem estar se perguntando: Como isso explica a hiperprodutividade Agile? Vamos explicar agora, mas lembre-se de não tirar de sua cabeça os pilares: Respeito pelas pessoas e melhoria contínua com eliminação de desperdícios.

Quando ocorre uma mudança de paradigma para o Lean, as pessoas da organização voltarão seus esforços para eliminar tudo aquilo que não agrega valor na cadeia produtiva. O livro dos Poppendieck levanta uma série de elementos para identificar os geradores de desperdícios na área de desenvolvimento de software. Mas eu vou focar nos dois mais importantes e que geram o maior impacto inicial na produtividade da empresa:

- Projetos desnecessários
- Requisitos desnecessários

A adoção estratégica de Lean deve iniciar pelo esforço de Gestão Ágil de Portfólio de Projetos. Pela elaboração de business cases enxutos e continuamente avaliados para cada projeto da empresa. Conforme descrito por Donald Reinertsen em seu livro Desenvolvendo Produtos na Metade do Tempo: eliminar projetos com baixo retorno vai gerar mais velocidade no time to market dos projetos restantes. Apesar de contra-intuitivo, quando você corta projetos você entrega mais projetos num time to market menor! Esse nível mais estratégico do portfólio de projetos é pouco tratado em processos ágeis como Scrum, XP, OpenUP, etc. Porém é fundamental para a busca da hiperprodutividade.

O próximo nível é o de requisitos desnecessários. É aí em que os processos ágeis possuem práticas e mecanismos orientados para que o desperdício de criar requisitos de pouco valor não ocorra. Aí também entra a necessidade de boas pessoas e bom time. Um bom product owner (desgraçado ganancioso, como meu amigo Yoshima gosta de resumir) é fundamental para que o desperdício (quase uma hemorragia, já que segundo o Chaos Report quase metade dos requisitos não agregam valor maior que o custo para produzí-los) estanque.

Além disso, a filosofia e práticas da Agilidade/Lean focam na auto-organização do time, na responsabilidade conjunta pelos objetivos de negócio do projeto e na produtividade com qualidade e com ritmo sustentável. Todas elas são práticas de administração consagradas e evidenciadas por Peter Drucker para liderar trabalhadores do conhecimento. Nas palavras do próprio Peter Drucker: "Knowledge workers must take responsibility for managing themselves".

No tocante à gestão de projetos também temos efeitos benéficos. O PMBOK já fala sobre o clássico ou quadrante mágico de variáveis do projeto. Ele é composto por escopo, custo, prazo e qualidade. Há também uma lei em relação a esse quadrante: das quatro variáveis, você só pode fixar três... uma irá variar.

Num projeto tradicional cascata e com preço fixo (ainda no Brasil esse é o modelo mais usado, portanto o chamo de tradicional por causa disso) é fixado o custo, o prazo e o escopo. Acho que é fácil entender agora porque a maioria dos projetos de TI falha do ponto de vista dos stakeholders: o que varia é a qualidade... e ela varia lá pro fundo do buraco!

Uma empresa Ági/Lean, entendendo que defeitos são o terceiro grande gerador de desperdícios, muda isso. Ela fixa o prazo, o custo e a qualidade(a qualidade é fixada quando usamos as práticas de engenharia Ágil. Sem elas você não será hiperprodutivo) e deixa variar o escopo. Essa mudança fundamental também ajuda a resolver o segundo desperdício: requisitos desnecessários. Quando o prazo e o custo são fixos, o product owner e os stakeholders terão que se esforçar ao máximo para atingir os objetivos de negócio almejados pelo projeto realizando apenas os requisitos importantes e de maior valor agregado, despriorizando ou eliminado requisitos de baixo valor. Veja como é exatamente isso que o cara que paga (sponsor) e outros stakeholders querem: um resultado (produto) de alta qualidade contendo o mínimo necessário de funcionalidades que resolvam seus problemas e necessidades de negócio, e ainda com a facilidade de mudar de idéia no decorrer do projeto.

Algumas pessoas orientadas ainda pelo paradigma preço fixo costumam imediatamente perguntar o seguinte: isso significa que um projeto Ágil entrega menos escopo que um cascata? E respondo: Muito pelo contrário, ele entrega um escopo de maior qualidade e valor agregado para o negócio. E é isso que o faz ser visto como bem sucedido pela organização.

Em resumo: Por que Agile / Lean funciona? Porque o respeito pelas pessoas e a busca da melhoria contínua levam à hiperprodutividade. Mas como essa hiperprodutividade ocorre quando ocorre a mudança de paradigma? Ela ocorre porque eliminam-se desperdícios das mais variadas formas e devido ao foco no resultado com ritmo sustentável. Os principais itens que geram isso no início são:
- Eliminação ou redução de projetos de baixo valor agregado.
- Eliminação ou redução de requisitos de baixo valor agregado.
- Em relação ao quadrante de variáveis do projeto: fixar custo, prazo e qualidade e deixar variar o escopo.

Não é fácil resumir o segredo do sucesso de algo, mas precisamos tentar. Esses segredos é que explicam a executivos e stakeholders porque adotar a filosofia Ágil os levará a outro patamar e também esclarecerá que só o 'processo' Ágil e suas práticas não resolverão o cerne do problema. A organização precisa de um choque cultural para que a hiperprodutividade se torne uma realidade, assim como ocorreu na Salesforce e em outras empresas que precisam do desenvolvimento de software e sistemas para manter seus negócios.


Um breve pensamento para fechar: "O Modelo tradicional cascata é errado e perigoso. Nós temos que superá-lo." - Frederick Brooks, autor do livro 'The Mythical Man-Month', em seu novo livro 'The Design of design'

10 previsões para o mercado de TI em 2010

Entre as previsões para este ano estão:

1. Maior mobilidade na mão de uma onda de produtividade pessoal e profissional.

A consultoria afirma que até o final de 2010 serão vendidos na AL mais de 43 milhões de computadores portáteis. Pela primeira vez na história, os portáteis superarão em venda os desktops.

O mercado dos netbooks seguirá ampliando-se em toda a região. Em alguns mercados, acredita-se que a composição entre a venda de netbooks e notebooks será quase 50% e 50% este ano.

Já os smartphones tendem ao nível recorde de venda, com mais de 11 milhões de unidades.

2. A evolução do vídeo impulsionará a próxima onda de verdadeira oferta de Triplo Play.

Na busca por continuar competitivos, evitar a perda de clientes e aumentar seus rendimentos, prestadores de serviços, telecomunicações e TV paga aumentaram o desenvolvimento de produtos durante 2009. A aposta aqui é no desenvolvimento da IPTV, método de transmissão de sinais televisivos com base no protocolo IP, principalmente no Brasil e no México.

A televisão digital ganhará destaque no ano da copa do mundo de futebol. Assim, também o acesso de banda larga sentirá o impacto de milhões de usuários em linha, estimulando o crescimento de assinaturas de banda larga em até 20%.

3. As aplicações móveis de conteúdo governarão através de 3,5G (HSPA).

Para 2010, espera-se que a demanda continue aumentando, encurtando o caminho para a geração 4G. Por enquanto, o 3.5G domina a penetração no mercado, sendo o padrão em mais de 50 carriers em 20 países.

Os investimentos em infraestrutura wireless representaram 2/3 do total de gasto em equipes de transporte de telecomunicações na América Latina durante 2009, e se espera manter este nível em 2010, chegando a quase $ 4 milhões de dólares.

4. Novos modelos de infraestrutura definirão a monetização dos investimentos dos operadores em redes de nova geração em 2010.

A consultoria espera que 2010 seja o ano em que os provedores e os equipamentos de serviços e de redes da América Latina capitalizem e aumentem os investimentos em redes de nova geração.

Também é possível afirmar que o transporte óptico, roteadores, switches, a infraestrutura de vídeo e o acesso às tecnologias da nova geração gerarão crescente investimento em 2010.

5. "Dynamic IT", a base para “Private Cloud”, o primeiro passo na evolução para novos modelos de infraestrutura.

As restrições orçamentárias durante 2009 foram a força catalisadora de adoção de novas tecnologias (principalmente virtualização), mas também impulsionaram às organizações a procurar modelos alternativos na entrega de infraestrutura.

A nova dinâmica de mercado impulsionará os provedores de sistemas a transformar suas ofertas e prover uma infraestrutura pronta para virtualização que inclua: processamento, armazenamento e conectividade em forma integrada sempre que seja possível. Neste caminho, também veremos a aparição de novos players no mercado como provedores de serviços de telecomunicações, provedores de outsourcing e canais especializados com capacidades de entregar e implementar soluções complexas.

6. A nascente adoção de serviços “Cloud” em aplicações terá tímidos resultados no 2010.

Na atualidade, o fenômeno de Cloud resulta ser um modelo utilizado em sua maioria nos Estados Unidos, tendendo em conta que 65% dos gastos de Cloud no mundo se realizam neste país. A oferta atual de serviços de Cloud na América Latina se concentra praticamente em aplicações. Em 2010 e 2011 estas serão as aplicações para produtividade de negócios. Serão as que mostrarão maiores assinaturas à adoção de serviços deste tipo.

7. Colaboração ‘enriquecida’ se converterá na verdadeira aplicação de comunicações unificadas e no próximo passo da colaboração empresarial.

A noção de colaboração empresarial sofreu uma importante transformação nos últimos anos. O conceito de "Rich Collaboration" pode ampliar-se com o afinco de componentes de colaboração em aplicações tradicionais de empresa.

Enquanto o mercado ainda está tentando elucidar qual é o melhor ponto de partida das comunicações unificadas, o impulso subjacente da transformação da colaboração se converte na aplicação.

8. A renovação de sistemas de faturamento e atendimento a clientes nos setores de Telecomunicações, Finanças e Comércio gerará uma onda de investimentos em aplicações para estas empresas.

As empresas observarão o faturamento e o sistema de clientes que estão integrados com o sistema administrativo central, em lugar de fazê-lo só com seu sistema financeiro. As melhorias no suporte aos clientes e nos sistemas de faturamento terão um forte impacto, indo além dos proporcionados por programas de Business Intelligence (BI) ou CRM, os quais utilizam sistemas legacy.

Melhorias, migrações e a otimização do faturamento, bem como os investimentos em suporte a clientes, atingirão investimentos de até bilhão de dólares em 2010.

9. A busca de equilíbrio entre custo e crescimento estimulará a adoção de ferramentas analíticas e uma nova maneira de utilizar “TI para administrar o negócio”.

A redução dos orçamentos dos clientes em 2009 fez com que os provedores gerassem maior concorrência que nos anos passados. A consultoria acredita que a demanda de projetos relacionados com a otimização de negócios continuará nas empresas da América Latina em 2010.

A IDC prevê que o mercado de software analítico na América Latina crescerá cerca de 12% em 2010.

10. Um 2009 difícil e um crescimento ambicioso conduzirão a consolidação do mercado da América Latina de distribuição de hardware.

O impacto do difícil ano de 2009 se refletirá como consolidações em 2010, onde alguns distribuidores de hardware de segundo nível serão adquiridos por distribuidores regionais e internacionais que se encontram na busca por incrementar suas vendas, fortalecer sua presença na região ou, em alguns casos, estabelecer-se pela primeira vez na América Latina. 

Gestão de projetos cresce e se profissionaliza

por Financial Web

30/05/2008

Principais benefícios são maior comprometimento com resultados e disponibilidade de informação para tomada de decisões

A gestão de projetos já assume um papel estratégico dentro das companhias instaladas no País, de acordo com um estudo realizado pelo Project Management Institute Brasil (PMI), entidade internacional que regulamenta os executivos do setor. O trabalho constatou que o grau de profissionalização nessa área é crescente e que o monitoramento de projetos é cada vez mais valorizado dentro das empresas. O “Estudo de Benchmarking em Gestão de Projetos”, realizado com 184 empresas (entre elas, Petrobrás, Nestlé, Vale, IBM e Lojas Renner), concluiu que 65% dos responsáveis por essa área possuem a certificação PMP (Project Management Professional) conferida pelo PMI. Segundo a entidade, são mais de 4 mil pessoas capacitadas no Brasil, e o número cresce ano a ano. O coordenador geral do trabalho, Américo Pinto, explica que o reconhecimento do profissional é fruto dos resultados trazidos por uma gestão de projetos eficaz. “Enquanto o amador toca as coisas na base da intuição, aumentando os riscos de fracasso, o gestor profissional se vale de metodologias e ferramentas reconhecidas internacionalmente, aumentando as chances de sucesso”, explica. Os benefícios de se investir em estão de projetos são diversos, segundo as empresas consultadas pelo PMI. Mais de 80% delas indica que gestão de projetos contribui para o maior comprometimento com os objetivos e resultados; 76% citam a disponibilidade de informação para tomada de decisão; outras 72%, melhoria de qualidade nos resultados; e 66%, aumento da satisfação do cliente (interno e externo). O estudo destaca também a redução do retrabalho durante os projetos, como um fator que prova o amadurecimento do gerenciamento. Em 2003, esse era um ponto crítico para 72% das empresas consultadas. Na pesquisa com dados de 2007, o percentual caiu para 26%. Oportunidades Segundo o PMI, a valorização do gerenciamento de projetos abre um novo caminho de oportunidades para os executivos brasileiros. A entidade traz, em 2008, novas certificações para o País. A mais recente é a de gerenciamento de programas (PgMP), destinada a gestores que coordenam múltiplos projetos inter-relacionados. Outra oportunidade é o oferecimento de bolsas de estudos para cursos preparatórios da certificação PMP, pelo PMI São Paulo, que tem o maior número de associados entre as filiais da América Latina.

Não cumprimento dos prazos é o principal problema na gestão de projetos

por IT Web

23/09/2009

Pesquisa anual de benchmarking do Project Management Institute aponta comunicação e gerenciamento de conflitos como principais falhas

O não cumprimento dos prazos representa o principal problema dos projetos conduzidos nas empresas brasileiras. A constatação estampa a sexta edição da pesquisa anual de benchmarking de Gerenciamento de Projetos, realizada pelo braço nacional do Project Management Institute (PMI). Dentre os outros fatores que atrapalham o sucesso, a associação lista as constantes mudanças de escopo (58%), problemas de comunicação (58%), escopo não definido adequadamente (52%), riscos não avaliados corretamente (46%), recursos humanos insuficientes (44%), concorrência entre o dia a dia e o projeto na utilização de recursos (43%), não cumprimento do orçamento (41%), mudança de prioridade constante ou falta de prioridade (35%), estimativas incorretas ou sem fundamento (30%) e problemas com fornecedores (29%). Para o estudo com os dados de 2008, a PMI ouviu 373 empresas, de oito indústrias e nove estados brasileiros. Metade das companhias que participam do estudo possui orçamento acima de R$ 1 milhão para projetos. De acordo com a associação, 49% das empresas têm mais de 500 funcionários e 53% verifica faturamento anual superior a R$ 100 milhões. Ainda de acordo com a associação, as principais deficiências encontradas nos profissionais de gestão de projeto atrelam-se à comunicação (47%), gerenciamento de conflitos (41%), conhecimento em gerenciamento de projetos (38%), capacidade de integrar as partes (36%), negociação (29%), política (24%), liderança (23%), atitude (21%), organização (18%), conhecimento técnico (15%), iniciativa (15%) e trabalho em equipe (14%)

62% das empresas brasileiras estouram orçamento de projetos

por IT Web

04/05/2010

Segundo estudo do PMI, 59% das companhias não utilizam soluções específicas para gestão do conhecimento em projetos

Os números são alarmantes: 79% das organizações brasileiras costumam ter problemas no cumprimento dos prazos estabelecidos para os projetos, enquanto 62% afirmam estourar os orçamentos definidos. É o que mostra o estudo de benchmarking em Gerenciamento de Projetos Brasil 2009, realizado pelo PMI (Project Management Institute). O levantamento ouviu 300 companhias que atuam no País. De acordo com a pesquisa, 32% dos projetos estouram em até 10% do valor previsto e 28% afirmaram que o rombo geralmente é maior do que isso. Por outro lado, 59% das empresas brasileiras não costumam ter problemas de qualidade no que é entregue. A satisfação com os resultados também não deixa a desejar. Problemas que ocorrem com mais frequência citados pelos respondentes tocam comunicação (76%), prazos (71%), mudanças de escopo (70%), escopo não definido adequadamente (61%) e concorrência entre o dia a dia e o projeto na utilização de recursos (52%). Iniciativas que as empresas pretendem desenvolver nos próximos 12 meses passam por desenvolvimento e revisão de metodologia de gerenciamento (60%), programas de capacitação em gerenciamento de projetos (57%), implantação de indicadores (50%). Outro dado relevante da edição do estudo mostra que 42% dos projetos estão sempre alinhados às estratégias da organização. Além disso, 62% dos entrevistados afirmam não utilizar balanced scorecard (BSC). Mesmo assim, 83% das empresas utilizam algum software para gerenciamento de projetos. Entre as ferramentas utilizadas estão MS Project (60%), software desenvolvido internamente (26%), MS Project Server (23%) e Oracle Primavera Systemas (8%). Todavia, 59% das companhias não utilizam soluções específicas para gestão do conhecimento em projetos, mas pretende adotá-la no futuro. Além disso, 33% das áreas de TI possuem um PMO (Project Management Office). O departamento também é o que mais utiliza metodologia de Gerenciamento de Projetos (63%). Os aspectos considerados na metodologia estão prazo (97%), escopo (94%), custo (83%), riscos (70%), comunicação (68%), qualidade (64%), recursos humanos (62%), integração (57%) e aquisições (48%).

Two major publications stress the importance of governance - Cobit

1. The Report of the Committee on the Financial Aspects of Corporate
Governance (Cadbury Report, 1992) focused global thinking on the
issue of governance. While the report is aimed at financial reporting and
auditing, it alludes to wider concepts of governance. It recommends
openness, integrity and accountability to improve standards of corporate
behaviour, strengthening controls over enterprises and their public
accountability while retaining the essential spirit of the enterprise. It
identifies various board governance responsibilities, such as setting
strategic aims, providing leadership, supervising management and
reporting to shareholders on their stewardship.
In practice, that stewardship is extending to IT as boards investigate the
depth of their enterprise’s reliance on IT.
2. The Bank for International Settlements (BIS), in Enhancing Corporate
Governance in Banking Organisations (1999), defines governance
arrangements as encompassing the set of relationships between the
entity’s management and its governing body, its owners and its other
stakeholders and providing the structure through which:
• The entity’s overall objectives are set.
• The method of attaining those objectives is outlined.
• The way that performance will be monitored is described.

Framework do Cobit

34 processos do Cobit

Desenvolvimento de um PMO

Em geral há 4 Estágios de Implementação

• Estágio 1 – Criação do Project Office (Foco em Padronização)
• Estágio 2 – Entrada em Operação (Foco em Acompanhamento e Controle de Projetos)
• Estágio 3 – Realimentação (Foco em Melhoria Contínua)
• Estágio 4 – Alinhamento com o Negócio (Foco Corporativo / Estratégico)

Estágio 1 – Criação do PMO

• Foco em padronização:
• Localização
• Infra-estrutura
• Papéis e responsabilidades
• Alocação de recursos
• Escopo do Project Office e sua implementação
• Metodologia
• Procedimentos
• Ferramentas
• Suporte ao Gerente de Projetos (Doutrinar)

Estágio 2 – Entrada em Operação

• Foco em Acompanhamento e Controle de
• Projetos:
• Suporte ao Gerente de Projetos (Operar)
• Criação e Manutenção da base de dados
• Revisão documentação existente
• Correção de desvios
• Atualização de documentação de projeto
• Produção e distribuição de relatórios
• Revisão e suporte a projetos-problema

Estágio 3 – Realimentação

• Foco em Melhoria Contínua:
• Refinamento de processos existentes
• Base de dados com performance em projetos anteriores
• Base de dados sobre recursos humanos e materiais otimizando sua utilização em projetos
• Recomendações de treinamento em função de performance passada e de necessidades futuras
• Base de dados com capital intelectual para reutilização e transferência de conhecimento

Estágio 4 – Alinhamento com o Negócio

• Foco Corporativo / Estratégico:
• Definição de critérios de seleção e priorização de projetos
• Gerenciamento de portfólio de recursos e projetos
• Previsão de demanda de recursos
• Divulgação de práticas de gerência de projetos por toda a empresa

Fonte: www.ricardovargas.com.br

Introdução a ITIL

A ITIL foi desenvolvida inicialmente pela CCTA (Central Computing and Telecommunications Agency) atual OGC (Office of Government Commerce). O OGC é órgão do Governo britânico que tem como objetivo desenvolver metodologias e criar padrões dentro dos departamentos do governo britânico, buscando otimizar e melhorar os processos internos. A biblioteca da ITIL foi desenvolvida pela CCTA, e tinha como objetivo melhorar os processos dos departamentos de TI do governo britânico. Desde o seu surgimento em 1980, as empresas e outras entidades do governo perceberão que as práticas sugeridas poderiam ser aplicadas em seus processos de TI também. Em 1990 a ITIL acabou se tornando um padrão de facto em todo o mundo, e a partir dela houveram várias adaptações de outros fornecedores, com a Microsoft, IBM e HP.
A ITIL atualmente desperta grande interesse no mercado, pois há uma preocupação com o Gerenciamento de Serviços de TI nas empresas. Como falamos anteriormente, a grande dependência da TI para os negócios faz com que os gestores de TI busquem a adoção da melhores práticas com o objetivo de trazer resultados positivos, como redução de custos e agilidade em seus processos.
Mais de 10.000 empresas no mundo todo já adotaram as melhores práticas da ITIL, isto comprova sua maturidade e aceitação pelo mercado. O Brasil e EUA estão na fase inicial de implementação destas práticas, muitas empresas aqui já adotaram e já temos vários cases de sucesso.
A ITIL oferece um framework comum para todas as atividades do departamento de TI, como a parte da provisão dos serviços, baseada infra-estrutura de TI. Estas atividades são divididas em processos, que fornecem um framework eficaz para um futuro

Gerenciamento de Serviços em TI aprimorado. Cada um destes processos cobre uma ou
mais tarefas do departamento de TI, tais como desenvolvimento de serviços, gerenciamento da infra-estrutura, fornecimento de serviços e suporte a serviços. Estes processos propiciam o uso da melhores práticas, fazendo com que o departamento de TI possa adotar independente da estrutura da organização.
As melhores práticas da ITIL têm como objetivos:

• Servir de inspiração para melhorar seus processos de TI;
• Sugerir onde é possível chegar, pois outras empresas já conseguiram resultados
• positivos;
• Sugerir para quê serve os processo e práticas;
• Sugerir por quê adotar os processos e práticas.

Muitas destas melhores práticas são claramente identificáveis e na verdade são utilizadas
na maioria das organizações de TI, talvez muitos dos conceitos que você vai ver aqui
você já utiliza ou conhece.
A ITIL apresenta as melhores práticas de forma coesa. Os livros da ITIL descrevem como
estas podem ser otimizadas, e como a coordenação das atividades pode ser aperfeiçoada. Os livros também explicam como os processos podem formalizados dentro de uma organização. Fornecem uma referência dentro da organização para uma terminologia padronizada, e ajudam a definir os objetivos e determinar o esforço requerido.
A ITIL não pode ser vista como uma metodologia, pois as melhores práticas são flexíveis a ponto de você adaptar aos seus processos, já uma metodologia possui uma implementação mais rígida, com regras bem definidas. “Na ITIL tudo pode, nada deve.”
A vantagem da adoção das melhores práticas está no fato de não ter que “reinventar a roda”, adotar práticas já testadas propicia um ganho de tempo e retorno mais rápido sobre o projeto de implementação de uma Gestão de Serviços.

Gama de software e produtos auxilia o CIO

É inegável que os desafios que o CIO precisa encarar são
grandes e numerosos. Mas também é verdade que há
uma gama de soluções que prometem auxiliar o profissional
nessa árdua tarefa. Umas cumprem o que prometem,
outras nem tanto. Porém, muitas vezes o problema
não está no produto, mas na escolha adequada para a
necessidade específica. Cabe ao profissional de TI a busca
e o conhecimento das opções existentes e a adoção
daquela que se encaixe na solicitação.

Web services, SOA (Service-oriented architecture), ou
ainda, em português, arquitetura orientada a serviços;
virtualização, tecnologia Blade e a adoção do ITIL (Information
Technology Infrastructure Library), que está
na versão 3.0 e já conta com livros em Português, são
algumas atitudes a serem adotadas, além das ferramentas
específicas de gerenciamento, que podem facilitar
o trabalho de manter a infra-estrutura disponível e
operante, inclusive para missões críticas. Para refrescar
a memória, Web service é uma solução utilizada na integração
de sistemas e na comunicação entre aplicações
diferentes. Com esta tecnologia é possível que novas
aplicações possam interagir com aquelas que já existem
e que sistemas desenvolvidos em plataformas diferentes
sejam compatíveis, como define a Wikipédia.
soluções

As tendências tecnológicas e econômicas afetam diretamente
os Data Centers Corporativos na medida em
que caminha para ser mais denso, com inúmeros ambientes
virtuais e de gestão remota flexível. Tecnologias
disponíveis atualmente permitem a drástica redução do
espaço computacional; as elevadas capacidades de processamento
permitem também rentabilizar um servidor
físico para várias aplicações simultaneamente e, dada a
complexidade inerente, o gerenciamento se apresenta
como vital na evolução dos centro de dados.

Mais uma vez, o gerenciamento de TI tem por objetivo
prover serviços de tecnologia com qualidade e alinhados
às necessidades do negócio, buscando sempre a
redução de custos, mesmo que seja a longo prazo. Para
tanto, existem algumas opções, umas mais antigas, mas
ainda em vigor, e outras mais recentes. Entre os exemplos
está o modelo Internet, que adota uma abordagem
gerente/agente. Os agentes mantêm informações sobre
recursos e os gerentes requisitam essas informações aos
agentes. Outro modelo é o OSI, da ISO, que se baseia na
teoria de orientação a objeto. Esse modelo gera agentes
mais complexos de serem desenvolvidos, consumindo
mais recursos dos elementos de rede e liberando o gerente
para tarefas mais inteligentes. Há também sistemas
de gerenciamento baseados em Java, que consistem
em browser gerenciador no NMS (Network Management
System) e uma máquina Java no agente.

Glossário de SCRUM

• Product owner - Responsável por maximizar o valor do produto (comprometido e disponível)
• Team - Multi-funcional (célula)
• Product backlog - Lista priorizada de histórias de usuário
• Sprint - Um ciclo de 2 a 5 semanas que geram componentes funcionais
• Sprint backlog - Lista de tarefas que devem ser executadas para transformar o ‘backlog’ em componentes funcionais durante o ‘sprint’
• Sprint planning and Sprint Review Meeting
• Increment - Um pacote de produto potencialmente entregável construído em cada sprint
• Daily scrum - Reunião diária de acompanhamento “em pé”
• Scrum Master - Facilitador do processo e produtividade