Post interessante no blog Software Development Today, onde é discutida a viabilidade do uso das ferramentas em projetos que não sejam especificamente de desenvolvimento de software.

O post pode ser lido pelo link: Can Scrum and Kanban be used for non-software development work?

Fonte: JustKanban pelo Twitter

Por André Dourado

Não sou um especialista nem em Redmine, nem em Rails, portanto essa pode não ser a melhor solução no tocante às ferramentas, mas acabou sendo uma forma simples de implementar gráficos de controle de nosso backlog no Redmine.

Descrição da Solução

Precisávamos de uma tabela para armazenar uma fotografia do backlog de nosso setor de desenvolvimento. Nessa tabela inserimos, através de uma tarefa agendada, diariamente às 2 da manhã: quantos tickets entraram e saíram no dia anterior e o total de tickets no backlog.

A partir dessa tabela geramos dois gráficos: um gráfico de linhas, com a quantidade diária de tickets abertos, outro de barras verticais, com a quantidade de tickets que entram e que saem.

Google Charts API

Google Charts API é uma ferramenta muito útil e interessante para quem desenvolve aplicações web e quer gerar gráficos de uma forma dinâmica. Esta API caracteriza-se pela facilidade de utilização e implementação, não sendo necessária a instalação de qualquer software ou frameworks. Para a sua utilização, basta a URL da API no qual serão referenciados os dados e características necessários para gerar o gráfico pretendido.

Os parâmetros são separados por “&”. Podem ser especificados quantos parâmetros se desejarem e pretenderem. Não pretendo aqui tentar esgotar as diversas opções de gráficos possíveis. A documentação completa da API pode ser encontrada em: http://code.google.com/intl/pt-BR/apis/chart/

Detalharei aqui apenas os que utilizamos em nossos gráficos, de forma que tenham um ponto de partida para que possam adaptá-los a suas necessidades.

Construção do Gráfico
“chs” Tamanho do gráfico gerado. Use chs=largura,altura. Ex: chs=430×225&

“cht” Especifica o tipo do gráfico. Linhas do tipo lc, onde são desenhadas diversas linhas para diversos conjuntos de dados, ou do tipo lxy, onde um par de conjuntos de dados é necessário para cada linha. Ex: cht=lc&

“chxt” Especifica os diversos eixos que serão usados no gráfico. O índice do primeiro eixo é 0, o índice do segundo eixo é 1 e assim por diante. Você pode especificar diversos eixos incluindo x, t, y ou r diversas vezes. Ex: chxt=x,y& onde x corresponde ao eixo 0 e y ao eixo 1.

“chxr” Define a escala de um eixo. O primeiro parâmetro é o número do eixo relacionado ao especificado em “chxt”. Os seguintes definem o início e o fim da faixa do eixo. Ex: chxr=1,0,150&

“chd=t” Codificação dos dados em forma de texto com dimensionamento de dados. Usa uma string de qualquer número positivo ou negativo em conjunto com um parâmetro de dimensionamento (chds). Ex: chd=t:108,111,111,111,120&

“chds” Maneira alternativa de definir a linha zero, combinado à codificação de texto. Um conjunto de dados que varia de -60 a 120, pode definir uma escala de -80 a 140 para deixar algum espaço acima e abaixo das barras. Ex: chds=0,150&

“chxl” Todos os rótulos de eixo são separados por uma barra vertical “|”.Os rótulos de eixo devem ser especificados em seqüência (0, seguido de 1, seguido de 2 e assim por diante). Ex: chxl=0:|25|26|27|28|29&

Formatação do Gráfico
“chls” Especifica os estilos de linha. Espessura da linha, comprimento da linha contínua, comprimento do segmento em branco. Ex: chls=2,1,0& linha de espessura média (2), linha não tracejada (1,0).

“chco” Especifica as cores das linhas, barras etc. Todos os valores de cores são números hexadecimais no formato RRGGBB. Ex: chco=DE091A,EBB671& mostra dois conjuntos de linhas/barras.

“chf” Especifica o preenchimento sólido com “bg ou c ou a,s,cor|”, onde “bg” para preenchimento de plano de fundo, “c” para preenchimento da área do gráfico ou “a” para aplicar transparência ao gráfico inteiro. é um número hexadecimal em formato RRGGBB. Ex: chf=c,lg,45,ffffff,0,b1cbfa,0.75|bg,s,fcfcfc&

“chm” Para colocar valores e marcadores sobre os pontos dos gráficos. São muitos os detalhes relativos a esse parâmetro. Sugiro consultar diretamente a documentação na Google: http://code.google.com/intl/pt-BR/apis/chart/#shape_markers2

“chma” Define as margens do gráfico. Use chma=esquerda,direita,topo,baixo. Ex: chma=30,20,20,30&

Por exemplo o gráfico de linha que utilizaremos no tutorial, seria gerado a partir da seguinte url:

http://chart.apis.google.com/chart?
chd=t:108,111,111,111,120&
chxl=0:|25|26|27|28|29&
chm=o,FF0000,0,0,6,0|o,FF0000,0,1,6,0|o,FF0000,0,2,6,0|o,FF0000,0,3,6,0|o,FF0000,0,4,6,0|
t108,FF0000,0,0,10,0|t111,FF0000,0,1,10,0|t111,FF0000,0,2,10,0|t111,FF0000,0,3,10,0|t120,FF0000,0,4,10,0&
cht=lc&
chxt=x,y&
chs=430x225&
chds=0,150&
chxr=1,0,150&
chco=FF0000&
chls=2,1,0&
chf=c,lg,45,ffffff,0,b1cbfa,0.75|bg,s,fcfcfc&
chma=30,20,20,30&
chdl=Tickets+Abertos&
chdlp=b

Criação do Modelo

1.Execute o comando de criação do modelo “backlogs”:

ruby script/generate model backlogs project_id:integer
back_date:date back_abertas:integer back_fechadas:integer back_total:integer

2.Execute a migração:

rake db:migrate

Instalação do Google Charts API

1.Instale a gem do Google Charts API. Mude para o diretório raiz do redmine e digite o seguinte comando:

gem install googlecharts

2.Adicione a nova gem no ambiente de sua aplicação. Edite o arquivo redmine/config/environment.rb e acrescente a linha: config.gem “googlecharts”, :lib => “gchart”

Rails::Initializer.run do |config|
  config.gem "googlecharts", :lib => "gchart"
end

3.Edite o arquivo redmine/app/controllers/application.rb e acrescente a linha: require “gchart”

require "gchart"
class ApplicationController < ActionController::Base
...

Implementação dos gráficos no Redmine

1.Edite o arquivo “redmine/app/controllers/projects_controller.rb” e insira as seguintes linhas:

  def graficos_backlog
    dados = ""
    legenda = ""
    pontos = ""
    pontos_barras = ""
    dados_abertas = ""
    dados_fechadas = ""
    max_total = 0
    max_abertas = 0
    max_fechadas = 0

    nponto = 8

    Backlogs.find(:all, :conditions => {:project_id, @project.id},  rder => "id desc", :limit => 9).each do |s|
      dados = "," + s.back_total.to_s() + dados
      dados_abertas = "," + s.back_abertas.to_s() + dados_abertas
      dados_fechadas = "," + s.back_fechadas.to_s() + dados_fechadas
      legenda = "|" + s.back_date.strftime("%d/%m") + legenda
      pontos = "|o,FF0000,0," + nponto.to_s() + ",6,0|t" + s.back_total.to_s() + ",FF0000,0," + nponto.to_s() + ",10,0" + pontos
      pontos_barras = "|t" + s.back_abertas.to_s() + ",FF0000,0," + nponto.to_s() + ",10,0|t" + s.back_fechadas.to_s() + ",FF0000,1," + nponto.to_s() + ",10,0" + pontos_barras

      nponto = nponto - 1

      if max_total < s.back_total
         max_total = s.back_total
      end

      if max_abertas < s.back_abertas
         max_abertas = s.back_abertas
      end

      if max_fechadas < s.back_fechadas
         max_fechadas = s.back_fechadas
      end
    end

    if dados.length > 0
      dados = "chd=t:" + dados[1, dados.length] + "&"
      dados_abertas = "chd=t:" + dados_abertas[1, dados_abertas.length] + "|" + dados_fechadas[1, dados_fechadas.length] + "&"
      legenda = "chxl=0:|" + legenda[1, legenda.length] + "&"
      pontos = "chm=" + pontos[1, pontos.length ] + "&"
      pontos_barras = "chm=" + pontos_barras[1, pontos_barras.length] + "&"

      # define pontos maximos dos graficos
      if max_total > 10
         multi = 1.1
      else
         multi = 2
      end

      max_graf_linha = "chds=0," + (max_total * multi).to_i().to_s() + "&chxr=1,0," + (max_total *multi).to_i().to_s() + "&"

      if max_abertas > max_fechadas
         max_barra = max_abertas
      else
         max_barra = max_fechadas
      end

      if max_barra >= 10
         multi = 1.1
      else
         multi = 2
      end

      max_graf_barra = "chxr=1,0," + (max_barra * multi).to_i().to_s() + "&chds=0," + (max_barra * multi).to_i().to_s() + "&"

      # define parametros de saida
      custom_linha = dados + legenda + pontos + max_graf_linha + "cht=lc&chxt=x,y&chs=430x225&chco=FF0000&chls=2,1,0&chf=c,lg,45,ffffff,0,b1cbfa,0.75|bg,s,fcfcfc&chma=30,20,20,30&chdl=Tickets+Abertos&chdlp=b"
      custom_barra = dados_abertas + pontos_barras + legenda + max_graf_barra + "cht=bvg&chs=430x225&chco=DE091A,EBB671&chbh=15,0,12&chxt=x,y&chs=430x225&chdlp=b&chdl=Abertos|Fechados&chf=c,lg,45,ffffff,0,b1cbfa,0.75|bg,s,fcfcfc&chma=30,20,20,30"
    else
      custom_linha = ""
      custom_barra = ""
    end

    {:custom_linha => custom_linha, :custom_barra => custom_barra}
  end

2.Ainda no arquivo “redmine/app/controllers/projects_controller.rb”, na definição da ação “Show” insira a seguinte linha:

    @graficos_backlog = graficos_backlog

3.No arquivo “redmine/app/views/projects/show.rhtml”, insira as seguintes linhas:

    <%= Gchart.line :size => '430x225',
                    :custom => @graficos_backlog[:custom_linha],
                    :format => 'image_tag' %>

3.Ainda no arquivo “redmine/app/views/projects/show.rhtml”, insira as seguintes linhas:

    <%= Gchart.bar :size => '430x225',
                   :custom => @graficos_backlog[:custom_barra],
                   :stacked => false,
                   :bar_width_and_spacing => '15,0,5',
                   :format => 'image_tag' %>

4.Inclua no arquivo “redmine/config/routes.rb” a linha:

map.resources :graficos_backlog

5.Reinicie o serviço do redmine para que as alterações tenham efeito.

O resultado final deve ser semelhante a tela abaixo:

Postado por Juan Bernabó para o Blog teamware blog
em Maio 27, 2009

Depois de ouvir o podcast de Ricardo Vargas, Chairman do PMI, sobre Agile Project Management ficou claro que será necessario um trabalho grande para continuar desmistificando Scrum e Agile, agora não porque não exista interesse ou demanda para adoção, o que acontecia há muitos anos quando tivemos a coragem de começar fazer os primeiros treinamentos de scrum no país, justamente pelo contrário.

Como o interesse esta crescendo, um dos aspectos que podem ser banalizados mais rapidamente, é de que para poder usufruir dos benefícios de Scrum e Agile, é necessário uma mudança de paradigma, e é esse nosso principal desafio.

Eu vejo com muito bons olhos que aqueles que de alguma forma tem pautado suas carreiras a gestão de projetos (os gestores de projetos) e são associados do PMI, e tem um objetivo de avançar a ciência da gestão de projetos, possam começar a ser expostos a métodos inovadores de gestão como Scrum, que tenho certeza vai aumentar muito o valor da sua caixa de ferramentas, porem minha experiencia me diz que temos que tomar cuidado com um aspecto fundamental.

Alguns desafios pela frente

Gestores de projetos sobre tudo que passam numa certificação onde existem perguntas extremamentes claras sobre qual deveria ser a forma de pensar correta sobre um assunto, vão provavelmente manifestar uma elevada taxa de concordância sobre algumas premissas fundamentais, certamente entre elas existirá diferente capacidade ou habilidade porem algumas crenças, verdades e premissas fundamentais serão similares.

Muitos dos gestores que tenho feito coaching, e tinham recebido treinamento formal em gestão tradicional de projetos, apresentavam mais o menos a mesma forma de pensar sobre ser possível ou não detalhar todas as atividades de um plano de projeto para desenvolvimento de software.

O que tenho visto, é que existe um gap entre o discurso e a prática, ou seja as teorias esboçadas e as teorias em uso tem divergencias muito grandes e isso pode ser a causa de muitos problemas, como a falta de reflexão sobre alguma premissa fundamental, e assim a falta de aprendizado.

Peter Senge, autor do livro A Quinta Disciplina, fala que o problema das organizações não é que não conseguem resolver os seus problemas, o problema é não conseguir “enxergar” seus problemas, o seu paradigma os cega.

Como as teorias aprendidas acabam sendo reforçadas, já que são as respostas certas para exames de certificação, elas passam a ser tratadas como “verdades” e como Scrum e Agile partem de premissas em alguns casos opostas da gestão tradicional, é necessário quebrar a ilusão que foi criada, para permitir o aprendizado de uma ferramenta que tem como premissa outras “verdades” que conflitam com aquelas adquiridas anteriormente.

O nosso trabalho tem sido basicamente nos últimos anos, criar duvida suficiente das “verdades” aprendidas, porém que estão criando problemas não deixando as pessoas conseguirem olhar para a realidade e refletir sobre os problemas que estão tendo realmente.

Conceitos para complementar o podcast do Ricardo

Aqui vão alguns comentários sobre o podcast que creio que podem ajudar a entender melhor e complementar o que Ricardo disse.

Ser ágil não se trata de velocidade, se trata sobre ser enxuto. Ou seja, imaginem algo que tem muita massa, pode ganhar extrema velocidade e ser muito rápido, porem terá muita inercia e terá dificuldade de mudar de direção rapidamente sem muito esforço.

Então a rapidez na verdade não é o objetivo de Scrum e sim reduzir a massa.

Para poder ser ágil e flexível será necessário reduzir a massa, ficar mais enxuto, e isto a gente faz em Scrum usando o conceito de One Piece Flow (criar um fluxo de produção de uma única peça) por exemplo se faz fluir um único requisito funcional desde o detalhamento até o teste funcional no menor tempo possível, fazendo que toda a equipe se concentre na menor quantidade possível para abaixar o estoque de trabalho em progresso (um conceito de Lean – Toyota – Just in Time) para poder responder a mudanças sem stresse.

O desafio para quem passou por treinamento formal em gestão tradicional de projetos será poder re-avaliar as premissas e crenças fundamentais, digo isto depois de ter reciclado centenas de pessoas formalmente treinadas em gestão de projetos tradicionais, não como uma hipótese e sim como um fato, nosso maior desafio é como o que tive com orientação a objetos há uns 22 anos atrás, mudar o meu paradigma (o sistema de verdades, crenças e premissas) que lamentavelmente nós humanos não fomos projetados para mudar muito frequentemente na nossa vida.

Existem milhares de implementações meia boca de Lean, existem milhões de analistas e desenvolvedores OO que programam em linguagens OO porem continuam pensando de forma estruturada, como eu já vi esta historia varias vezes o desafio maior é que não tenhamos milhares de PMPs usando Scrum sem mudar o seu paradigma, sem realmente conseguir retirar todo o valor da ferramenta já que para poder retirar a maior quantidade de valor é necessário pensar diferente.

Uma pergunta para develar uma premissa

No Scrum Gathering apos a palestra do Ricardo Vargas, eu Juan Bernabó, acabei fazendo uma pergunta chave, conhecendo as premissas dos gestores tradicionais eu fiz só uma pergunta para tentar entender melhor se o discurso era um discurso de quem tinha passado por um entendimento profundo, mudança de paradigma, ou simplesmente de quem ainda so conhece os artefatos mais não as premissas fundamentais de Scrum.

A pergunta foi “O PMI parece ser muito centrado no papel do gestor de projetos, certo? Porem o PMI esta preparado para um mundo de equipes auto-geridas?”

O Ricardo contesto de forma totalmente transparente uma “verdade” que ele tem “experimentado” e que se eu não tivesse tido tanta experiencias reais com Scrum também teria, ele disse que a idéia de equipes auto-geridas é romântica, mais nunca viu uma funcionando direito, logico sem Scrum e Ágil eu vi uma porem era uma raridade.

Eu já transicionei mais de 80 equipes auto-geridas, por isso tenho plena convicção, porem sem essa experiencia seria difícil ter tanta certeza, sobre todo quando usamos processos que não estão ajustados para a auto-gestão, e que os ciclos de controle são muito grandes.

Pela primeira vez com Scrum tenho a oportunidade de criar em larga escala equipes auto geridas, que se comportam relativamente dentro de parâmetros, e que tem um resultado muito superior a qualquer outra forma de organização que eu já tinha visto.

Pela resposta do Ricardo deu para entender que ainda não foi exposto e ainda precisara passar por uma mudança de paradigma.

Por exemplo da para entender claramente o que um gestor tradicional acredita sobre times auto gerenciados, como ele nunca viu funcionando de forma eficaz então deve ser porque é necessário um time extremamente maduro.

Porem a auto gestão só é possível não porque as pessoas são muito maduras, mais porque usamos de alguns mecanismos que permitem que um grupo de pessoas normais (na media) tenham comportamentos emergentes (do sistema) inteligentes, isso se chamam gestão empírica com ciclos curtos (2 a 4 semanas), equipe holística sem papeis que permite que os pares possam se auto-regular, e feedback binário e concreto através da demonstração de produto pronto que é facilmente verificável, que passa nos testes de aceitação automatizados por exemplo.

Scrum nada mais é do que o nosso velho amigo o PDCA levado extremamente a serio por exemplo, 1 dia de Sprint “Planning” (Plan), 8 dias de “Sprint” (DO), 4 hrs. de Sprint “Review” (Check), e 2 hrs. de Sprint “Retrospective” (ACT).

O controle na gestão empírica não esta no processo e sim em definir claramente a entrada (item do backlog) e verificar rigorosamente a saída (features prontas testadas), e não mexer no processo durante o momento onde o processo esta executando (Sprint), só ajustar o processo depois de verificar a saída (ou seja no Sprint Retrospective).

A outra diferencia é que o papel das equipes mudou de co-adjudantes para papeis principais, elas planejam taticamente no Sprint Planning, e melhoram seu processo no Sprint Retrospective ao invés de simplesmente executar planos planejados por algum gestor, e ver seus processos melhorados por alguma área ou responsável por processos.

Como vemos Scrum esta sendo bem aceito inclusive na comunidade de gestão de projetos tradicional, logico não sem algumas preocupações, o papel do gestor de projetos como o conhecemos em Scrum muda de forma radical, PM irão precisar adquirir novos skills, novas formas de pensar, é muito mais legal e interessante do que assustador, porem precisa se ter consciência que para termos resultados no mundo ágil uma transição será necessária.

Já hoje e mais no futuro o que ira agregar valor é ser aquele facilitador que saberá criar o ambiente certo e os processos certos para que equipes possam se auto-gerir, um profissional com estas habilidades nunca deixara de ter valor no mercado.

Boa noticia

Donella Meadows fala em seus 12 pontos de alavanca para intervir num sistema
que o paradigma é um dos mais fortes, porem mais forte do que o paradigma é o poder de transcender a paradigmas, como a física clássica não deixou de ser útil nem perdeu validade com o advento da física quântica, a gestão tradicional e muito do seu corpo de conhecimento não perdeu relevância o problema é tentar usar uma única ferramenta (paradigma) para tentar resolver todos os problemas.

Fonte: teamware blog

Publicada a versão 2009 do Gartner Magic Quadrant for IT Project and Portfolio Management.

O Magic Quadrant é a representação gráfica de um mercado durante um período de tempo específico.

Ele descreve a análise da Gartner de como determinados fabricantes são avaliados com base em critérios definidos pela própria empresa para esse mercado. A Gartner não endossa nenhum fornecedor, produto ou serviço descrito no Magic Quadrant nem recomenda que os usuários de tecnologia selecionem apenas os fornecedores dispostos no Quadrante dos “Líderes”.

O Magic Quadrant é meramente uma ferramenta de pesquisa e não tem como objetivo ser um guia específico de decisões estratégicas.

Os fabricantes são classificados em quatro quadrantes como: “Líderes”, “Desafiadores”, “Visionários” ou “Fornecedores de nicho”.

• Líderes. São aquelas empresas que têm uma atuação consistente no mercado, assim como uma visão clara de direcionamento de marketing. Essas empresas devem, ainda, manter um desenvolvimento de competências para sustentar sua posição de liderança no mercado.
• Desafiadores. Os desafiadores executam bem, mas ainda não demonstram uma visão particular neste mercado.
• Visionários. Estes fornecedores já demonstraram inovação neste mercado, mas ainda terão que apresentar o mix da viabilidade global, dimensão funcional, execução de vendas, e acompanhamento dos registos para passarem para o quadrante dos líderes.
• Fornecedores de nicho. Os fornecedores que se encontram neste quadrante tendem a ter pontos fortes em muitos aspectos do mercado, sem disponibilizarem um suporte mais abrangente. Alternativamente, tendem a ter uma experiência mais limitada em termos geográficos, através da falta de enfoque neste mercado, ou porque são novos no mercado.

Veja na integra em: http://mediaproducts.gartner.com/reprints/microsoft/vol6/article11/article11.html

Fonte: Twitter do Ricardo Vargas

Nesse podcast Ricardo apresenta o gerenciamento ágil de projetos e os conceitos de Scrum. Ele teve um contato inicial com Agile e Scrum e tenta nesse podcast falar um pouco sobre como funciona o Agile e Scrum. Importante ressaltar que Ricardo não é um especialista no assunto. O objetivo nesse podcast é apresentar para os não especialistas em Agile e Scrum alguns dos principais conceitos envolvidos na técnica. Ele tb comete um pequeno deslize no podcast onde fala que scrum é do jogo de futebol americano. Na verdade Scrum é a formação do Rugby.

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

25/05/2009 Gerenciamento Ágil de Projetos e Scrum 1 de 2

Nesse podcast, Ricardo mostra suas percepções sobre o uso de gerenciamento ágil e como isso pode ser utilizado em conjunção com o PMBOK Guide e outros padrões e/ou metodologias para uma prática bem sucedida de gerenciamento de projetos. Segundo podcast sobre o tema.

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

01/06/2009 Gerenciamento Ágil de Projetos e Scrum 2 de 2

Ricardo Viana Vargas é especialista em planejamento, gerenciamento e controle de projetos. Atualmente atua como presidente da Macrosolutions, uma empresa de consultoria de gerenciamento de projetos no Brasil com mais de 20 perfis complexos de projetos do Brasil e América Latina, abrangendo um portifólio de investimentos de mais de $5 bilhões. Ricardo Vargas é membro do PMI desde 1997, e atualmente ocupa a posição de diretoria do Board do PMI. Participou da revisão do PMBOK®, Project Management Body of Knowledge (PMBOK® Guide), e foi membro da equipe do projeto de atualização do PMBOK® Guide em 2004. Também foi presidente do Comitê de Verificação de Tradução para língua portuguesa do PMBOK® Guide 2004.

Fonte: Ricardo Vargas – Five Minutes PM Podcast

Matthew Hotle
8 de maio de 2009

Descobertas chave

• Mudar sua estrutura organizacional deveria ser o último recurso.
• Recursos humanos qualificados e determinação são mais importantes do que uma melhor estrutura organizacional.

Recomendações

• Não faça mudanças organizacionais para solucionar problemas nos processos. Foque primeiro o próprio processo.
• Use atribuições rotativas de tarefas e outros incentivos para gerar determinação se a segmentação for sua opção.
• Assegure-se de que os acordos de nível de serviço (SLAs) tenham sido implementados antes de realizar a mudança organizacional.

O QUE VOCÊ PRECISA SABER
Os clientes costumam perguntar se deveriam dividir seu pessoal entre projetos (geralmente associados a desenvolvimento, na verdade se referem a trabalho líquido e novo, e a projetos de aperfeiçoamento) e suporte. As empresas que já se encontram nessa situação perguntam se seria melhor dividir o pessoal ou se deveriam voltar a ser uma empresa de estilo misto. Se isso soar mais como um estilo de tomada de decisões do tipo “será que a grama está mais verde”, então é mesmo. A maioria das empresas que cogita dividir suas estruturas organizacionais seguindo esses preceitos está na verdade tentando solucionar uma de várias questões relativas a seus processos:

• Os projetos estão atrasados (embora sem ultrapassar o orçamento) porque os recursos alocados para eles foram transferidos para a área de suporte.
• As qualificações da área de suporte estão totalmente unificadas, sem nenhum backup ou contingência.
• Os requisitos de recursos para suporte estão fragmentados.
• O pessoal qualificado para a área de suporte ou não está disponível, ou logo não estará mais disponível devido a aposentadorias ou transferências.
• Relacionamentos problemáticos entre os diferentes grupos geram problemas significativos de gestão e estado de espírito.

Mudar simplesmente a estrutura organizacional não irá solucionar nenhum desses problemas. De fato, mudar a empresa irá, todas as outras coisas mantendo-se as mesmas, tornar os problemas ainda piores durante seis a 18 meses, simplesmente porque, além de possuir processos problemáticos, a empresa enfrentará a distração de um novo quadro organizacional. Há bons motivos para mudar um empresa (esta pesquisa não se refere a quando mudar, mas a como mudar), mas fazer isso deve ser algo cuidadosamente avaliado e ponderado com o potencial das mudanças nos processos de solucionarem efetivamente os problemas, e não apenas mudarem o pessoal de lugar.

ANÁLISE
A primeiro regra para mudar um desenho organizacional: Não faça isso!

É claro, isso nem sempre é verdade. Porém, modificar os relacionamentos de reporte e o lugar das pessoal com certa freqüência é um dos principais problemas que as divisões de aplicações enfrentam. É relativamente fácil porque os relacionamentos e a dimensão do controle são algo sobre os quais os gestores têm controle direto, e o mais importante, é fácil ver que uma mudança está sendo feita. Porém, há dois problemas aqui:

• Mudar a estrutura de uma empresa resultará entre 6 a 18 meses de ruptura. Alguns se associam a seus chefes; enquanto outros não se sentem à vontade com eles. Independente disso, quando os relacionamentos de reporte organizacional forem modificados, haverá um período de acomodação entre os novos associados e sua gestão. Haverá também um período de tempo em que as partes da empresa sujeitas às modificações deverão se realinhar para que o trabalho possa fluir novamente pela nova estrutura de gestão.
• Os maus processos continuam sendo maus. Isso é realmente fundamental aqui. Muitas empresas tentam mudar seus quadros organizacionais para solucionar um problema dos processos, mas isso não funciona. Solucione o problema primeiro, e então escolha uma estrutura organizacional que funcione.

Grande parte das atividades nas empresas tem origem em relacionamentos informais e em processos implícitos. Status ou poder já foram atribuídos nas estruturas já existentes. Muitas empresas têm muito pouca consciência desses aspectos, e os danificam ou destroem durante os processos de reorganização. Infelizmente, algumas das estruturas e processos que deveriam ter sido modificados sobrevivem ao processo de reorganização.

Para colocar isso tudo no contexto desta discussão, muitas empresas estão de problemas de RH e de planejamento através da segmentação de suas estruturas organizacionais. Vamos presumir que haja bons motivos para dividir a empresa, incluindo aqueles citados acima. Qual é a mecânica dessa separação?

Aspectos Fundamentais de uma Divisão das Áreas de Projetos/Suporte
Se você estiver prestes a segmentar sua empresa, então o seguinte conjunto de passos será crucial ao fazer isso:

• Defina claramente o que é um projeto e quais atividades serão atribuídas à área de suporte. Isso poderá parecer fácil, mas muitas empresas referem-se a um projeto como alguma espécie de massa amorfa de trabalho, ou como qualquer coisa que precise ser administrada. Para os fins desta discussão, vamos presumir que um projeto é algo que contenha um mínimo de 320 horas. Há algum sentido nisso: usando o mínimo necessário de oito horas para o planejamento de tarefas estabelecido pelo Project Management Institute (PMI), vamos presumir que um projeto possua cinco fases (requisitos, análise/design, código, teste e implementação), e que cada uma dessas fases possua apenas três atividades. Cada atividade possui três tarefas associadas a ela. Temos agora um total de 15 tarefas (cinco fases: três atividades por fase e três tarefas por atividade), o que gera um total de 320 horas. Tudo o mais fica a cargo da área de suporte. Geralmente, há três tipos de atividades de suporte: reparo de defeitos, pequenas mudanças ou aperfeiçoamentos, e outros trabalhos necessários para atender aos SLAs. O trabalho de conformidade ou observância regulatória poderá na verdade entrar em qualquer uma das categorias de projetos ou suporte. Se houver uma necessidade consistente de pessoal para realizar essas mudanças, então essas mudanças poderão ir para a área de manutenção. Se a demanda for esporádica, então será melhor lidar com elas como se fossem projetos, colocando-as no topo da cadeia de prioridades.
• Para cada aplicação ou grupo de aplicações, crie um SLA. Ou seja: Suporte consiste no reparo de defeitos, pequenos aperfeiçoamentos, e outros trabalhos necessários para prover suporte aos SLAs (resposta a questões corporativas, realização de análises conjunturais e assim por diante). Aqueles serviços devem ser claramente definidos e codificados em um SLA que proveja à empresa e à divisão de aplicações um mecanismo para atender aos níveis de serviços desejados pela empresa. Isso proverá também um mecanismo para dimensionar a divisão de suporte.
• Com base nos requisitos dos SLAs e de trabalho, dimensione a estrutura organizacional. Infelizmente, é daqui que parte a maioria das empresas que desejam segmentar seu pessoal. Determinar quantas pessoas devem estar na divisão de suporte é um terreno desconhecido até que você determine: (1) a taxa de contratação segundo a gravidade dos defeitos; (2) quantas pessoas a empresa está disposta a pagar para realizar os pequenos aperfeiçoamentos; e (3) quais outros serviços devem ser realizados, quando e como (veja “Administrando a Inexorável Demanda por Trabalho em Aplicações”).

Até agora, tudo isso é razoavelmente simples. Agora, porém, chegamos ao que é talvez o maior impedimento para a realização de uma segmentação: os próprios associados. O reparo de defeitos requer pessoas que estejam acostumadas e dispostas a trabalhar sob pressão, e que sejam muito bons solucionadores de problemas. Geralmente não há pouca oferta de tais recursos humanos, mas é algo que vale a pena observar porque poderá haver pessoas dispostas a realizar o trabalho de suporte e que não possuam as qualificações básicas. O maior problema, porém, é que muitos profissionais de TI simplesmente não desejam realizar somente o trabalho de suporte. Eles consideram uma tarefa de suporte como uma via sem saída, um predecessor da terceirização ou uma mudança que limitará suas perspectivas. Por outro lado, os que pertencem à comunidade de desenvolvedores poderão vir a ver a si mesmos como superiores aos profissionais da divisão de suporte. Ao realizar o trabalho de segmentação, as empresas precisam pensar em como poderão fazer com que seu pessoal se sinta confortável realizando uma tarefa de suporte e disposto a aceitá-la. Há um alguns mecanismos chave para fazer isso:

• Pague um bônus ao pessoal de suporte. Muitas empresas recusam-se a fazer isso, pois consideram que o trabalho de suporte não possui valor agregado.

Fonte: Info Corporate

Publicado por marco em 06 Mai 2009

Duas notícias recentes levantam críticas sobre o uso dos tradicionais e estabelecidos modelos de gerência de projetos, programas e portfólios do renomado instituto PMI.

1. O Gartner Group fez críticas duras à falta de aplicabilidade destes corpos de conhecimento para TI devido especialmente à sua superficilialidade em diversos pontos (sic). A notícia completa e uma análise desta polêmica esta aqui no portal da SearchCIO. Compilo aqui uma frase do diretor de pesquisa do Gartner Group, Michael Hanford – “Their portfolio management standard shows a solid understanding of a complex discipline, but I’d say it disappoints with an uneven level of explanations“.

2. O SCRUM tem sido adotado mundialmente em cada vez mais empresas no Brasil e no exterior. Uma interessante reportagem do uso do SCRUM em empresas fora do âmbito de TI está disponível aqui. Aparentemente, o SCRUM se adapta melhor a empresas com realidades dinâmicas e ágeis e segue a escola de gerenciamento ágil que também tem sido fomentada pela IBM em sua melhor prática denominada Two Level Planning.

Pensamento do dia: “It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change.”, Charles Darwin

Fonte: Blog do Marco Mendes

Clique aqui: href=”http://guiadopublicitario.blogspot.com/2009/03/262-links-que-voce-pode-precisar-um-dia.html

Fonte: Guia do Publicitário

Na sua empresa quando se fala em gerenciamento de projetos todos pensam em PMBok. Você acha que Scrum pode ajudar seus projetos mas não consegue enxergar como fazer isso em um ambiente completamente tradicional de projetos. O que fazer? Onde foi parar o Gerente de Projetos? E o PMO, como fica? Tenho práticas ágeis que se equivalam às áreas de conhecimento do PMBok? Nesta palestra a filosofia ágil é apresentada de forma a fazer entender como Scrum pode ser aplicado nestes ambientes, e qual o caminho a ser seguido pelos Gerentes de Projeto acostumados com práticas PMI para conseguir serem bem sucedidos em projetos Scrum.

Palestra do Alexandre Magno para o Falando em Agile 2008.

Assista a palestra aqui.

Fonte: Falando em Agile 2008

Ontem foi o primeiro dia da primeira edição de 2009 do Scrum Gathering. Organizado pela Scrum Alliance, este é o maior e principal evento de Scrum do mundo.

Durante o almoço aconteceu um pequeno pronunciamento de Gregory Balestrero, Presidente e CEO do PMI – Project Management Institute.

Gregory mostrou bastante bom senso ao falar do que a comunidade Scrum tem feito:

“Vocês tem mostrado ao mundo como obter bons resultados em projetos. Encorajo PMPs a buscarem conhecimento e certificações na área de Scrum, pois realmente acreditamos nisso.”

Fonte: aXMagno