Arquivo | Governança de TI RSS feed for this section

A TI é o foco? Cuidado ao responder.

2 Set

Não restam dúvidas que a área de tecnologia da informação (TI) é dinâmica e de vanguarda. E por isso, gostaria de compartilhar uma inquietude: se estamos envolvidos em uma área que olha sempre pra frente, que precisa a todo instante de recursos financeiros e ao mesmo tempo não gosta de ser identificada com uma área que consume muito pra pouco, então porque as estruturas de TI são semelhantes (para não dizer idênticas) a de outros setores, como contabilidade, RH, financeiro, etc.?

Antes de olharmos para metodologias e frameworks de governança, como ITIL e CoBiT, é necessário dizer qual será o posicionamento da TI frente às outras unidades de negócio da organização.

Basicamente: ela será descentralizada ou centralizada?

Isto é algo que realmente importa. Definir como a TI está situada dentro da empresa é fundamental. Acredito que muito se gasta com a TI por ela não ter o posicionamento correto. Ou seja, o modelo de outras unidades não serve para a TI!

Geralmente, os profissionais de TI e, especialmente, os Gerentes de Projetos, relacionam-se com pessoas de diversas áreas de conhecimento, principalmente por que precisamos entender o que e como fazem, para então propormos a melhor solução.

Isso traz a nossa área uma característica muito, mas muito especial: ela tem os profissionais que entendem como as unidades de negócio da empresa trabalham e como elas podem se integrar. A TI não é  fim nela mesmo. Engana-se o profissional que acha que isso é diferente.

Como consequência disso…Nós conhecemos os processos, melhor de que qualquer um! Isto é um fato!

Bom, mas o que isso tem haver com que coloco sobre a TI ser o foco?

Dizer que a TI é suporte parece ser simples, não é? E você com certeza já escutou isso em várias palestras, seminários, programas de auditório, entre outros meios…

Então, se somos meio, porque centralizamos a nossa gestão?

Onde quero chegar com essa conversa: os clientes conhecem do seu negócio e nós conhecemos os caminhos para que eles produzam de maneira mais eficaz e eficiente. Sendo assim, porque cada unidade de negócio não ter sua equipe de TI dedicada?!

Evidente que esta teoria não é minha. Muitos autores já propõe um modelo descentralizado de TI. Antes realmente achava essa ideia absurda, mas atualmente vejo que ela pode ser a saída.

Muitos Gerentes de Projetos tem o sonho de trabalhar em uma estrutura totalmente projetizada, acham que este é o caminho do sucesso. Mas sabemos as desvantagens que este tipo de estrutura pode trazer.

Estas mesmas desvantagens, como: perda de conhecimento, alto custo com equipes, dificuldade em se ter padrões e integrar soluções, desmotivação da equipe, etc. também acontecerão se a TI for descentralizada.

No entanto, pense comigo: se focamos nas unidades que tem prioridade de orçamento e projetos, consequentemente, a empresa, no sentido global, alcançará os resultados de maneira mais rápida e com maior qualidade. Com a TI não deve haver intermediários. A TI é meio, certo?! Não se pode ter uma estrutura totalmente funcional para a organização da TI.

Por mais que isso possa parecer subversivo, a ideia tem que ser discutida. Dê para cada unidade de negócio a sua equipe de TI. As reclamações que somos inoperantes vão diminuir sensivelmente. Indo além: os responsáveis pelas áreas que atualmente só demandam, passam a ser responsáveis pelo sucesso ou fracasso da equipe e do projeto. Para mim isso é fundamental!

E nós como ficamos?

Os gerentes de projetos, com o apoio de um PMO, será o elo entre a operação e a gestão de TI.

Por falar em gestão de TI, ela deve estar preocupada com:

  • Metodologias;
  • Padrões e padronização;
  • Integração;
  • Estabelecimento de políticas;
  • Acompanhamento de portfólio;
  • Suporte;
  • Busca por novas tecnologias, pesquisa…; e
  • Desenvolvimento humano.

Indo um pouco além, penso que nem sobre o investimento a Gestão de TI deverá ser responsável. A organização, neste caso, contará com um BELO de um PLANEJAMENTO ESTRATÉGICO que alinhe as unidades e direcione os recursos. Por isso, a organização será responsável pelo investimento e não um ou outro gestor.

Alerto para que isso não deva ser interpretado com um sonho, mas sim com uma premissa! Planejamento é obrigação e não acessório.

Para finalizar, recentemente li um artigo sobre “quais os três cargos de TI que devem sobreviver no futuro” e pensei: a TI descentralizada está cada vez mais próxima, ou melhor, já é uma realidade!

Se você tem uma opinião diferente ou concorda comigo, opine!!!

Abraços e até a próxima!

———————————————————————–

Sobre este assunto visite:

http://www.malima.com.br/article_read.asp?id=634

http://blog.opus-software.com.br/?p=170

http://olhardigital.uol.com.br/negocios/digital_news/noticias/quais_os_3_cargos_de_ti_que_devem_sobreviver_no_futuro

http://www.bain.com/bainweb/PDFs/cms/Public/Voce_tem_organizacao_de_ti_certa_Portuguese.pdf

http://www.tiespecialistas.com.br/2011/01/repensando-ti-na-estrutura-organizacional/

Imagem retirada de:

http://promoview.com.br/artigos-e-cronicas/131368-um-show-no-atendimento-por-paulo-araujo/

Scrum Master vs Gerente de Projetos, PMP: Presente e Passado?

4 Jul

Se você ainda não vivenciou uma situação parecida com que vou descrever, então imagine: de um lado um ScrumMaster certificado (CSM) e do outro um PMP, e algumas pessoas em volta observando a discussão de quem é o melhor perfil para gerenciar projetos!!!

Seria mais uma daquelas discussões intermináveis?!

Pensando nisso, resolvi escrever este post: seria o CSM o presente e o PMP o passado na gerência de projetos?

Lembro que a proposta de ser iterativo e incremental, pregada pelo Scrum, não é nova. Há várias metodologias na Engenharia de Software que pregam a construção baseada em ciclos e releases. Não pretendo com isso minimizar a importância do Scrum, ao contrário. Eu vejo a força desta metodologia na forma de organização do time do projeto e na condução das iterações (sprints) durante o desenvolvimento do projeto, além  da questão da qualidade nos produtos desenvolvidos. Realmente acredito nesta proposta! Mas não é isto que torna o ScrumMaster o grande profissional de gerenciamento de projeto.

De acordo com o Scrum Guide de 2010, a equipe Scrum (Scrum teams) é designada para otimizar a flexibilidade e produtividade do projeto; e para este fim, a equipe é auto-organizada, são cross-functional  (time com diferentes experiências e habilidades voltadas para um objetivo comum) e trabalham por interações.

Faz parte da equipe Scrum: o ScrumMaster; o Proprietário do Produto e a Equipe Scrum.

O ScrumMaster é o responsável por garantir que o processo é compreendido e seguido por TODOS.

Atenção! É também premissa básica, super importante, fundamental etc. etc. etc., que o PMP garanta o processo adotado para o gerenciamento do projeto e que todos os envolvidos tenham ciência deste processo e o execute de maneira coerente, ok?!??!

As figuras do Sponsor (PMBOK) e do Proprietário do Produto (Scrum) dão um encaminhamento distinto para a atuação dos dois perfis, veja:

O Proprietário do Produto é o responsável por maximizar o valor do trabalho que o Time SCRUM realiza.  Já o Sponsor, como apontado no PMBOK, é a pessoa ou grupo que fornece os recursos financeiros, em dinheiro ou em espécie, para o projeto.

Fundamentalmente isso já traz uma consequência para a atuação do ScrumMaster e o Gerente de Projetos que se baseia no PMBOK, concorda?

Observe que o Proprietário do Produto atua em conjunto com a equipe para que o projeto atenda aos requisitos necessários. Já  Sponsor é uma espécie de suporte ao gerente de projeto, para tratar de assuntos relacionados à mudança, além de ser o porta-voz do gerente de projetos para os níveis gerenciais mais altos.  Esta diferença é realmente importante e na prática acaba fazendo toda a diferença.

O ScrumMaster de acordo com o Scrum Guide:

  • Trabalha com os clientes e gestão para identificar e indicar um Proprietário do Produto.
  • Ensina o Proprietário do Produto como fazer o seu trabalho. Espera-se que o Proprietário do Produto saiba como conseguir otimizar valor usando Scrum. Se não, temos o ScrumMaster responsável.
  • Pode ser um membro da equipe, por exemplo, um desenvolvedor que executa tarefas no Sprint (iteração)No entanto, isso muitas vezes leva a conflitos quando o ScrumMaster tem que escolher entre remover impedimentos e realizar tarefas.
  • Nunca deve ser o Proprietário do Produto.

O Gerente de Projetos segundo o Guia PMBOK:

  • Pessoa designada pela organização executora para atingir os objetivos do projeto;
  • Sua autonomia depende do tipo de estrutura organizacional que projeto será desenvolvido;
  • Requer habilidades da área específica e das proficiências ou competências de gerenciamento geral;
  • Ter capacidade de realização;
  • Ter liderança;
  • Capacidade de orientar a equipe do projeto ao mesmo tempo em que atinge os objetivos e equilibra as restrições do mesmo;
  • Dependendo do contexto do projeto, o GP poderá determinar a necessidade de um controle mais eficaz sobre certas entregas;
  • Cabe ao Gerente de Projetos e a sua equipe, determinar o método mais apropriado de execução do projeto.
  • Gerenciar as expectativas das partes interessadas;
  • Desenvolve o plano de gerenciamento de projeto e todos os componentes relacionados;
  • Identifica e monitora os riscos;
  • Fornece relatórios precisos e oportunos das métricas do projeto;
  • É o líder responsável pela comunicação com todas as partes interessadas;

As funções do Proprietário do Produto e do ScrumMaster são bem definidas e claras. Já o PMBOK dá ao gerente de projetos a responsabilidade sobre atividades que poderiam ser compartilhadas com o Sponsor do Projeto.

Resultado disso na prática:

Bom, aí penso que nem todos os projetos cabem, unicamente, em um ou em outro perfil. O contexto mais uma vez vai direcionar qual a melhor forma de orientar e conduzir os trabalhos.  O momento atual do manifesto ágil é muito bom, mas não significa que a filosofia PMI seja ultrapassada, afirmar isso, a meu ver, seria leviano.

Os profissionais PMP passam por um regime mais rigoroso de certificação que os certificados ScrumMaster, isto tem que ser levado em consideração ao avaliarmos os perfis. 

O IT-Management, baseado em uma pesquisa realizada pelo site de empregos de TI, Dice Learning, publicou sobre as certificações percebidas como de grande valor, e a certificação PMP aparece no topo, sendo que a CSM nem na lista aparece. Pense nisso!

O mercado, no entanto, quer alguém que responda com mais agilidade e seja menos burocrático ou estritamente metodológico. Por muitas vezes, já presenciei gestores importantes referindo-se aos PMP’s como “grandes burocratas de alto custo”.  Vejo como demasiadamente dura a afirmação.

Talvez, digam isso por perceberem que os profissionais que conduzem projetos, baseados no manifesto ágil, dão maior foco nos resultados funcionais do projeto. No entanto, vejo que os PMP’s, para projetos de alta criticidade, que requerem maior controle de custos, riscos e recursos, são os mais adequados.

Para que funcione bem, o Scrum requer uma equipe mais experiente, que saiba como se auto-organizar e que tenha em seu “líder” alguém que seja um facilitador para os problemas que surgem no dia-a-dia do projeto e garanta o processo. Por mais belo que isso seja na teoria, nem sempre é fácil de realizar na prática.

Finalizando: nem o PMP é passado e nem o CSM é o presente. Ambos são realidades! Quem é melhor… Aí é uma discussão interminável, do tipo projetista JAVA  vs projetista C#…

Abraços e até a próxima!

PMO. O QUE EU TENHO HAVER COM ISSO?

3 Maio

O escritório de projetos (PMO – Project Management Office) é um tema recorrente em congressos, workshops, fóruns e por aí vai. Confesso que tenho até me afastado das discussões que envolvem este tema.

Explico: primeiro que é uma discussão sem fim sobre os reais benefícios que ele gera; segundo que cada empresa tem sua cultura e realidade e, portanto, não teremos modelos de escritório de projetos que sirvam para todas as organizações; e, por fim, nada é mais chato do que comparar um caso de “sucesso” com outro caso de “sucesso” que ninguém saiba exatamente do que se trata.

Oras, então porque falar sobre PMO neste post? Continue lendo que você vai entender!!

http://www.thepmoblotter.org/

imagem retirada de: http://www.thepmoblotter.org/

O engraçado, apesar de tudo, é que gosto muito do tema, exatamente por ele não ter uma fórmula pronta. Ou seja, é uma ideia em construção!

E o melhor: demoraremos muito tempo em ter um modelo único, pronto e consolidado, isso se conseguirmos ter algum.

O gerente de projetos, com certa experiência, sabe que para o projeto dar certo, ele dependerá muito do seu esforço pessoal e do comprometimento da equipe com o trabalho a ser desenvolvido. E quando o GP descobre isso, o PMO poderá ficar a ver navios. Se o escritório tem o objetivo de consolidar uma metodologia por toda a organização, o gerente de projetos pode ser seu algoz, pois ele irá fazer do jeito que ele acredita ser certo e não que alguém acredita que seja. Pode soar estranho… mas continue lendo.

O PMO quando posicionado em nível elevado na estrutura organizacional da empresa, pode muitas vezes ter uma visão muito macro das dificuldades setoriais em que os gerentes de projeto estão envolvidos. Já os gerentes de projetos, conhecem como poucos a cultura do seu setor/área dentro da organização. E isso torna a informação assimétrica em favor do gerente de projetos, principalmente, quando ele não faz parte do escritório de projetos.

  • Outra coisa que me questiono muito é quando um escritório de projetos é implantado sem o cuidado de se ter desenvolvido um plano estratégico para ele.
  • Qual a visão, missão, objetivos e metas deste escritório?

Todos na organização têm conhecimento sobre a visão e as metas de curto, médio e longo prazo deste escritório?  Lembro que muitas vezes nem mesmo o plano estratégico da empresa é conhecido por todos.

Ainda nesta linha, vejo muitos escritórios com o objeto de sua existência muito grandioso, o que tende a perder o foco no médio prazo. Em organizações que não tem cultura de gerenciamento de projetos é fácil tornar o PMO alvo de criticas por aqueles que o vêem como um ameaçador ou frustrar àqueles que o viam com solução para seus problemas.

E não é muito difícil adivinhar porque isso ocorre: não há entregas de curto prazo que mostrem os benefícios reais de se ter o escritório.

Volto a dizer: começar pequeno e bem planejado é fundamental.

Em 2009/2010 fiz um estudo sobre implantação de PMO’s no serviço público brasileiro e ao final dele constatei algo que meu orientador já me questionava: afinal pra que serve um PMO? Que benefícios ele traz? PRA QUÊ PRECISAMOS DISSO? Confesso que não consegui responder em sua totalidade estes questionamentos, algo que me frustrou.

Pra não dizer que sou pessimista quanto à implantação de um escritório de projetos, vou indicar quatro pontos que penso que não podem faltar quando se pensa em realizar um PMO:

  1. Defina os resultados de curtíssimo prazo (eu disse CURTÍSSIMO PRAZO) e que gere benefícios para toda organização. Dê visibilidade e atenda as expectativas iniciais.
  2. Reúna pessoas que compartilhem das propostas do gerenciamento de projetos. Envolva, principalmente, os gestores que se animam com a ideia!
  3. Desenvolva competências (e isso não pode ser feito depois da implantação). As competências preparam o ambiente para consolidar a infraestrutura do PMO quando ele for implantado. Você já terá pessoas que compartilham suas idéias! Ou seja, você terá seguidores!!!!!
  4. Não subestime o estado atual do processo em que as pessoas trabalham. Muitas vezes o inicio da maturidade do processo pode estar na consolidação dos processos que já são realizados há anos pela empresa.

Por fim, gostaria de dizer que acredito nos escritórios como disseminadores da cultura de gerenciamento de projetos, como estimuladores do processo de aprendizagem e de controle dos registros de lições aprendidas. Claro que vários outros objetivos podem ser contemplados, mas aí, uma nova discussão se inicia…

Abraços!!!

%d bloggers like this: