Em parceria com a Sucesu-SP e a Athem, entre 07 e 11 de novembro realizamos o 1º treinamento: Fundamentos para gestão ágil no gerenciamento de projetos com SCRUM.

Foi simplismente um sucesso.

Agradeço a todos os participantes e organizadores.

Usabilidade no desenvolvimento de software

Usabilidade: é um termo usado para definir a facilidade que os indivíduos podem empregar uma ferramenta ou objeto a fim de realizar uma tarefa específica importante.

A usabilidade é uma metodologia científica, aplicada na criação e remodelação de interfaces de aplicações (sites, intranets, aplicativos, jogos e produtos no mundo Web), com a finalidade de torná-los fáceis de aprender e usar.

Um software cujo manuseio seja fácil e rapidamente aprendido, dificilmente será esquecido, que não provoque erros operacionais, ofereça um alto grau de satisfação para seus usuários e, resolva eficientemente as tarefas para as quais foi projetado, pode ser considerado um sistema com grande potencial de usabilidade. Ou seja, considerar o design de um produto não apenas pela sua engenharia óptica, mais primordialmente pela sua usabilidade e a viabilização da ‘Cultura de Uso’.

Dessa forma, percebe-se a importância do desenvolvimento de software baseado em práticas de usabilidade, visando assim uma melhor aceitabilidade destes sistemas por parte dos seus futuros usuários.

A usabilidade é entendida como uma categoria relacionada à qualidade do produto de
software e, é afetada por aspectos de outras categorias como funcionalidade, confiabilidade e eficiência.

Antigamente, a experiência do usuário (UX, de user experience), não tinha uma prioridade alta na maioria dos projetos de desenvolvimento, mas isso mudou. Hoje em dia, os usuários têm muita experiência com a Web e com software. Eles desejam um design que seja fácil de aprender e de usar e que se ajuste ao seu fluxo de trabalho.

O termo "experiência do usuário" descreve a experiência subjetiva de uma pessoa quando ela está interagindo com um produto. Diariamente discute-se a usabilidade informalmente quando relatamos uma ótima experiência em um restaurante ou uma péssima no cinema. Mas quando projetamos ou avaliamos a experiência do usuário de um produto interativo, precisamos de uma maneira mais estruturada de ver o produto e analisá-lo.

Para os designers de UX, o sucesso significa criar produtos que sejam úteis, utilizáveis e desejáveis. Para ser útil, o produto deve fornecer valor ao usuário, em termos de desenvolvimento, isso significa que o produto deve implementar a funcionalidade certa. E os produtos desejáveis são aqueles com que os usuários sonham. Quanto mais desejável for um produto, mais tempo e energia o usuário dedicará a ele.

Em geral as pessoas confundem UX com design visual, equiparando-a com cores, fontes e estética. Naturalmente, o design gráfico é um dos componentes da experiência do usuário, mas o processo de design de UX é muito mais profundo. Essencialmente, a UX consiste em como a funcionalidade é implementada em termos de interação usuário-sistema.

Enquanto o analista de negócios tende a se preocupar com o que o produto deve fazer, o designer de UX se concentra em como a função deve ser apresentada por meio da UI (user inteface). Como os usuários têm habilidades e necessidades diferentes, o designer de UX determina quais segmentos de usuários precisam ser atendidos. O designer vai reunir dados sobre os segmentos de usuários e pode criar “personas” (biografias fictícias de usuários com base em dados reais), que ajudam a concentrar as discussões durante o processo de design.

Usando entrevistas e observação, o designer de UX vai identificar as tarefas que são executadas pelos usuários, como eles abordam essas tarefas e as palavras que são usadas para descrevê-las. Esses dados podem ser resumidos como cenários, histórias dos usuários ou storyboards.
Design da interação: Define como o usuário interage com o produto. Determina o comportamento do produto em resposta às ações tomadas pelo usuário e enfoca a navegação do produto, bem como os controles específicos que são usados.

Arquitetura de informações: Define como as informações são organizadas e apresentadas.
Pesquisa de usuários: O processo de estudar os usuários a fim de desenvolver um design que atenda às suas necessidades, capacidades e preferências. Os métodos são variados e normalmente empregam algumas técnicas de entrevista junto com a observação. Também são usados registros de usuários e fontes secundárias. Pesquisas e grupos de foco também podem ser usados, embora muitos designers de UX os evitem.
Design visual: Os designers visuais podem ser artistas gráficos em vez de designers de UX. Embora o impacto visual seja importante, também é essencial que o design visual não prejudique a legibilidade ou a usabilidade.
Teste de usabilidade: O processo de observar os usuários executando determinadas tarefas em um protótipo ou uma imitação da UI. Tradicionalmente, o teste de usabilidade era realizado em um laboratório com os observadores atrás de um espelho. Contudo, cada vez mais, os testes de usabilidade estão usando tecnologia de webcast.

Sinergia com a metodologia ágil

Sob o ponto de vista conceitual, os motivos para a criação de uma boa UX são aumentar a eficácia e a eficiência, reduzir a sobrecarga e a reformulação do desenvolvimento e agregar o maior valor possível, seja para operações internas ou para clientes externos.

Não é eficaz pedir que os usuários determinem o que o sistema deveria fazer e de que modo. Essa abordagem coloca nos usuários a carga de traduzir suas próprias necessidades para o que eles acham que o software deveria fazer, restringindo a descoberta de alternativas melhores, que um designer ou um desenvolvedor seriam capazes de sugerir.

O design centrado no usuário (UCD, user-centered design) agrega valor ao enfocar o entendimento das pessoas — seus objetivos, suas tarefas e suas atividades — e usando esse valor como a base para a criação.

Sob o ponto de vista prático, existe muita sinergia com a metodologia ágil. Ambas são essencialmente iterativas. Ambas exigem a colaboração constante das pessoas.
Mas lembrem-se: quem desenvolve não está apto a testar a usabilidade da aplicação desenvolvida.

Em breve mais sobre usabilidade.

Aquele abraço.

Fonte:http://msdn.microsoft.com/
http://www.scriptfacil.com.br/
http://www.ufpa.br

Fixe o prazo e o orçamento, flexibilize o escopo

Olá amigos, estou lendo um livro chamado "Getting Real" (Caindo na Real), o livro aborda o desenvolvimento ágil de software. Vou compartilhar com vocês um trecho bem interessante.


Fixe o prazo e o orçamento, flexibilize o escopo


Lance dentro do prazo e do orçamento

Aqui vai uma maneira fácil de lançar dentro do prazo e do orçamento: mantenha-os fixos. Nunca jogue mais tempo ou dinheiro em um problema, apenas diminue o escopo.

Existe um mito que diz o seguinte: podemos lançar no prazo, no orçamento e no escopo. Isso quase nunca acontece e quando acontece a qualidade normalmente sofre.

Se não puder encaixar tudo dentro do prazo e orçamento planejados então não aumente o tempo e o custo. Em vez disso, puxe o escopo para trás. Sempre existe tempo para adicionar coisas mais tarde – o mais tarde é eterno, o agora está voando.

Lançar alguma coisa grande que está um pouco menor em escopo do que o planejado é melhor do que lançar alguma coisa medíocre e cheio de buracos porque precisou atingir uma janela mágica de prazo, orçamento e escopo. Deixe a mágica para Houdini. Você tem um negócio de verdade para administrar e um produto real para entregar.

Aqui vão os benefícios de fixar o prazo e orçamento e manter o escopo flexível:

Priorização
Precisaremos descobrir o que é realmente importante. O que vai chegar ao lançamento inicial? Isso força uma restrição que o pressionará a tomar decisões difíceis em vez de ficar hesitando.

Realidade
Configurar expectativas é a chave. Se tentar fixar o prazo, orçamento e escopo, não será capaz de entregar com um alto grau de qualidade. Claro, provavelmente poderá entregar alguma coisa, mas “alguma coisa” é o que realmente quer entregar?

Flexibilidade
A habilidade de mudar é a chave. Ter tudo fixado torna as mudanças difíceis. Injetar flexibilidade de escopo apresentará opções baseadas em sua experiência real de construir o produto. Flexibilidade é seu amigo.

Nossa recomendação: abaixo o Escopo. É melhor fazer meio-produto do que um produto meia-boca (mais sobre isso depois).

Um, dois, três...

"Como um projeto chega estar um ano atrasado? Um dia de cada vez." - Fred Brooks

Trecho do livro: Getting Real - 37signals

Versão completa em português.

Kanban no desenvolvimento ágil de software by Dilbert.

Fonte: Universitários de POA

WORKSHOP - SCRUM

Olá, gostaria de convidá-lo a participar de um evento que vamos ministrar referente a SCRUM.

O treinamento tem como principal propósito, introduzir os profissionais ao mundo dos métodos ágeis e prepará-los para a curva de aprendizado que envolve esse meio. Entender porque os métodos ágeis têm recebido tanto destaque nos últimos anos, e como aplicar de forma prática a teoria em ação.

Durante o curso, os participantes irão entender de forma simples e direta como uma framework pode transformar os resultados de uma empresa, além de aprender como aplicar SCRUM em diversos tipos de projetos independente da segmentação e área de negócio.

Por fim, com este treinamento o aluno terá uma clara percepção da essência dos métodos ágeis: seus valores e princípios.

Inscreva-se: Clique aqui

Papéis no SCRUM.

No Scrum existem 3 papéis principais:

Product Owner

Comumente o cliente ou o gerente de um projeto maior. As suas principais responsabilidades são definir as funcionalidades, os prazos, estabelecer as prioridades de entrega, ajustar prioridades e funcionalidades e, por fim, aceitar o produto entregue.

Scrum Master

Responsável pela aplicação do Scrum na equipe. Remove obstáculos à conclusão dos trabalhos, controla o bom andamento das atividades e acompanha a aplicação das funcionalidades e a qualidade do que está sendo produzido. Atua como ponto de contato entre a equipe, os clientes e a gerência do projeto.

Equipe

Geralmente entre 5 a 10 membros. Inclui perfis multidisciplinares e auto-gerenciáveis (desenvolvedores, designers, testadores, analistas, arquitetos), que atuam em tempo integral no sprint.

O pontapé inicial para a definição de um sprint é o seu planejamento. Itens como capacidade de equipe, o backlog, tecnologia atual e funcionalidades são levadas em consideração por toda a equipe.

Nesse processo, é gerada a priorização do backlog e o plano, as diretrizes de como a equipe irá chegar ao seu objetivo final. O principal artefato gerado por essa etapa é o sprint backlog. Já formatado e com as devidas priorizações, responsáveis, tempos e datas de entrega.

Com o sprint backlog gerado, a equipe já pode começar a trabalhar nos produtos. Diariamente e feita uma reunião informal (preferencialmente com todos de pé) de cerca de 15 a 20 minutos, onde a equipe pode colocar ao Scrum Master os obstáculos que encontraram para a conclusão de suas atividades do dia anterior.

É importante salientar que essa reunião não deve servir para discussão de funcionalidades ou problemas alheios às atividades do dia anterior em si, para não perder sua essência e foco.

O gerenciamento de cada sprint é feito pelos próprios membros da equipe. Qualquer membro dela pode modificar, incluir ou eliminar tarefas e cada um fica responsável por escolher quais tarefas irá executar e atualizar diariamente as horas gastas e a estimativa de horas restantes para conclusão das atividades.

Ao final do sprint é celebrada uma reunião de revisão, onde a equipe apresenta os resulatados obtidos durante o sprint. Nessa reunião, que é informal e sem grandes apresentações, todo o time participa e discute os progressos e os problemas encontrados, onde pode-se planejar de forma mais efetiva para atingir os resultados do próximo sprint.

Fonte: http://webinsider.uol.com.br

Quer aprender mais sobre o tema? Clique aqui

Como lidar com a ausência (indisponibilidade) do Product Owner

Uma questão bastante abordada e discutida quando pensamos em projetos que utilizam do SCRUM como ferramenta de processo, é a ausência (indisponibilidade) do Product Owner. Se levarmos em consideração que PO é o "cara" que melhor conhece o produto, que tem clara a prioridade do que deve ser feito, é a pessoa que demanda as necessidades do negócio, considero natural que esta "entidade" não seja tão acessível quanto pregamos no SCRUM.

Como resolver esta questão?

Abaixo uma matéria escrita por Paulo Rebelo  no site  INFOQ explana um pouco mais sobre o assunto.

Como lidar com a ausência de um Product Owner efetivo

O papel do Product Owner tem grande importância no Scrum, mas muitos dos profissionais que assumem esse papel não possuem o tempo necessário para acompanhar a equipe, não tendo disponibilidade sequer para a evolução do produto da forma que merece. Neste artigo, são exploradas alternativas para tornar mais efetivo o papel do Product Owner. 

Papel e responsabilidades

Em Scrum, lembrando, temos três papéis bem claros: ScrumMaster, Product Owner e membro da Equipe (ou do Time). Nosso foco é no Product Owner, que possui basicamente as seguintes responsabilidades:

• Conceber o produto, escrevendo suas histórias e funcionalidades gerais;
• Priorizar as histórias de mais alto valor;
• Estar disponível para a equipe, ajudando-a a entender os requisitos;
• Aprovar as histórias realizadas pela equipe;
• Definir as necessidades dos usuários;
• Garantir o retorno de investimento para cada funcionalidade entregue;
• Possibilitar que seja feito o mais simples possível, mantendo a funcionalidade necessária.

A efetiva contribuiçāo do Product Owner (PO), como se vê, é um fator chave para o sucesso do projeto. Mas será que os POs possuem a dedicação exigida para a entrega de um produto? Da mesma forma que a equipe e o ScrumMaster, o PO também precisa ter o foco necessário, sendo este um valor importante do Scrum.

É importante que o PO participe das reuniões diárias, e sua presença é obrigatória em Reviews e Plannings (lembrando que Review é a reunião de apresentação do que foi realizado pelo time, e Planning é a reunião de planejamento do que será feito em um determinado ciclo de entrega). 

Recomenda-se ainda que o PO esteja disponível para a equipe, para lidar com eventuais dúvidas e sugestões. Além disso, na reunião de Product Grooming, contamos com o PO para trazer as respostas e os direcionamentos necessários.

No entanto, isso frequentemente não é o que acontece na prática, pois muitos dos Product Owners são extremamente ocupados, não possuindo o tempo para dedicação à equipe e principalmente ao produto. Muitos dos eleitos para a função de PO cuidam de outras atividades, outros produtos, até mesmo gerenciam outras equipes, dentre varias responsabilidades adicionais. Esse acúmulo de funções pode ser enormemente prejudicial para todos os envolvidos no projeto. 

Alternativas

Como lidar com essa situação? Em muitos casos, o que se pode fazer é tratar o PO atribulado como um Business Owner, delegando as tarefas do PO de fato, com o foco no desenvolvimento do produto e na equipe. Saber delegar e confiar no profissional para o qual está passando essa responsabilidade traz retorno para o próprio Business Owner. O PO precisa se conscientizar (ou ser conscientizado) de que não é possível "encaixar" mais um papel em seu dia-a-dia. Deve-se ainda reforçar que esta é uma responsabilidade básica para o Scrum.

É neste último ponto que talvez esteja o problema: será que a implantação do Scrum nas empresas fica realmente clara e transparente para todos? Às vezes, "transformamos" o atual Gerente de Projetos em ScrumMaster, treinamos o time de desenvolvimento em técnicas ágeis, mas e o Product Owner? Não bastaria apenas treinar aquele que hoje responde pelo produto, pois é ele mesmo quem deveria exercer essa função?

Querendo ou não, a denominação de PO do Scrum é confundida por muitos, talvez pela tradução literal da palavra ("dono do produto"). Mas, o fato é que a escolha do PO pode ser decisivo para o sucesso de um projeto. Imagine um PO sem capacidade de determinar o retorno de investimento do seu produto; ou que não saiba o que gera mais valor.

Existem implantações de Scrum, nas quais já participei, em que existia um grupo de Product Owners e um Chief Product Owner (recomendo a leitura do artigo de Roman Pichler que trata do papel de Chief Product Owner). O Chief Product Owner é um profissional responsável por treinar, colaborar e conduzir os Product Owners. Na minha experiência, o modelo funcionou bem, pois os CPOs eram focados na função e por existir essa comunidade, compartilhavam muitas experiências. Os Product Owners faziam a interface com a área de negócio e o dono real do produto era considerado o Business Owner (leia mais sobre o conceito de Business Owner no artigo de Dean Leffingwell).

Outra opção para garantir uma boa condução do produto é a alocação de um analista de negócio. Esta pessoa faz o detalhamento dos épicos, temas e histórias; fica ao lado do time e responde às dúvidas de negócio, viabilizando a geração de valor para o produto, entre outras funções. Mas novamente aqui podemos cair em uma armadilha: o analista não é um Product Owner de fato, e muitas vezes requisitaria certo tempo do verdadeiro Product Owner. Isso porque não teria a mesma autonomia para priorizar ou aceitar as histórias, por exemplo.

O Problema da indisponibilidade

A falta de tempo do PO tende a se tornar um círculo vicioso, que na maioria das vezes acaba sobrecarregando o ScrumMaster. Se o PO não cumpre com a sua função como deveria, o ScrumMaster é quem acaba assumindo grande parte da responsabilidade. Não é raro encontrar um ScrumMaster refinando uma história para o time ou até mesmo criando-a. 

Dito isso, algumas questões vêm à tona: será que foram dadas as condições necessárias para o PO realizar efetivamente o seu trabalho; ou seja, não deveria o PO ser um Business Owner, e permanecer em um papel com menos responsabilidades? Para isso acontecer, no entanto, precisaria ele contratar um PO e delegar essa função, ou deixar a resolução do impasse a cargo de quem implantou o Scrum? 

A Implantação do Scrum nas Empresas 

Toda a culpa parece ficar por conta do Scrum, o que não é verdade. Apesar de ser um framework baseado em princípios simples, o Scrum detém complexidade significativa e sua implantação em empresas exige cuidado e atenção a detalhes. Se a implantação não ocorrer de forma bem planejada, novos problemas surgirão e a impressão do Scrum ficará comprometida. 

Os papéis e as responsabilidades de cada um devem ficar muito claros, não pode haver sobreposição de tarefas (por exemplo, um PO deve se dedicar a essa função). Além disso, treinamentos são necessários para todos, inclusive para os profissionais nas demais funções, que, de uma forma ou de outra, serão afetados pela implantação. E, talvez o mais importante, é a transformação cultural da empresa, e o aprendizado e a adaptação dos profissionais que a compõem.

Conclusões

O papel de Product Owner no Scrum é complexo, envolvendo múltiplas tarefas e responsabilidades. É preciso ter foco no produto a ser entregue e tempo de dedicação. Portanto, a escolha do Product Owner é de vital importância para todos os envolvidos. É o Product Owner quem direciona o produto. Mas se não tem o tempo necessário, e não for possível fazer mudanças na empresa para que o tenha, será melhor considerá-lo como Business Owner e contratar um Product Owner que realize essa função.

Fonte: http://www.infoq.com/br/articles/product-owner-efetivo

Métodos ágeis - JIRA como uma ferramenta de gerenciamento de projetos.

Diferente do modelo tradicional para o controle de projetos, a metodologia ágil exige uma evolução tecnológica das aplicações e ferramentas para o gerenciamento de projetos. Um dos melhores exemplos com o qual atuo é o JIRA - Atlassian.

JIRA é altamente customizável, possuindo inúmeros recursos que ajudam em um projeto de gerenciamento de requisitos.

JIRA para Gerentes de Projeto
 Gerencie todos os seus projetos
 Gerencie muitos componentes em um único local
 Controle as atividades de sua equipe
 Monitore progressos em seus projetos
 Acesso on-line seguro

Gerenciar projetos e componentes
 Rastreie todos os seus projetos
 Gerencie sua lista de to-dos
 Número ilimitado de tarefas e sub-tarefas
 Descrições
 Arquivar anexos
 Mecanismo individual de workflow para: departamento, projeto e tipo de tarefa
 Customização de workflows

Controle as atividades de sua equipe
 Relatórios de monitoramento de tempo
 Road maps
 Painéis com atualizações de status
 Exportação de relatório de dados para Microsoft Word e Excel
 Exportação de relatório de dados como XML e RSS

Monitorar o progresso de seus projetos
 Dashboard para atualizações de status rápido
 Gráficos e relatórios sobre o seu dashboard pessoal
 Relatórios enviados automaticamente
 Atualizações por e-mail

Acesso on-line seguro
 Regimes de segurança granular
 Gerenciamento de segurança em nível empresarial

Time Tracking
 Definir uma estimativa para cada tarefa
 Log de tempo gasto em cada tarefa
 Registro de acompanhamento de tempo para cada fase do projeto
 Acompanhar tarefas de risco em um projeto
 Definir feeds RSS em tarefas de risco

Controle de atividades do projeto

Agilizar tarefas de gerenciamento de projeto
 Mostra a estrutura de hierarquia de issues
 Fornece avançados planners para Gerentes de Projetos
 Gerencie issues de risco em um projeto
 Integre JIRA com MS Project

Link hierarquias entre issues

Gerenciamento de risco/Gerenciamento de Projeto Ágil
 Definição de responsável por drag and drop
 Estimativa de Issue
 Planejamento da Iteração
 Gráfico Burndown
 Relatório sobre o estado da iteração

Vale ressaltar que cada gerente de projeto tem seu estilo e meio de gestão... as aplicações, ferramentas e controles são todos direcionados conforme seu maior conforto e meio de condução.

Em parceria com a ECORE, minha intenção desse post não é "vender" a aplicação, e sim disseminar o conhecimento sobre uma solução completa para a gestão de projetos, não nos limitando apenas ao velho e bom MS Project.

Fonte: http://blog.ecore.com.br

Como deve agir um analista de negócios?

Essa é uma questão muito subjetiva, e na maioria dos casos esse profissional é sempre colocado em xeque pela sua conduta, devido a ser uma posição de destaque na organização, a maturidade do indivíduo que exerce a função de analista de negócios deve ser bem dilatada e seu senso crítico altamente treinado para não cair nas valas de uma gestão que em quase sua totalidade possui gestores que ainda não sabe quem realmente são ou o que fazem esses elementos.

Grandes organizações confundem as profissões, em determinados casos nomeiam analistas de sistemas e consultores como analistas de negócios, estratégia essa adotada como manobra comercial, a fim de valorizar o profissional perante o seu cliente e diminuir seu custo referente ao valor da hora/homem na prestação de serviços.

Após vários anos de experiência e com mais de 11.000 horas de trabalho atuando como analista de negócios, entendi como realmente deve se comportar um profissional nessa posição.

Agir com toda a isenção que a função lhe permite, sua posição de destaque faz com que se torne um facilitador e em muitos casos influenciador na tomada de decisões estratégicas. Para tanto, sua linha de conduta e postura devem ser íntegras, seu nível de envolvimento com a área de negócios não pode ultrapassar a fronteira do “desejo e necessidade”, sua missão é exclusivamente alcançar o objetivo definido pela organização.

O ato de executar uma atividade com base no seu julgamento do certo ou errado, desejável ou indesejável... Faz parte do conflito diário que vive esse profissional, em sua essência a excelência é o seu maior princípio, mesmo que fatores externos e alheios a estratégia apareçam. Seu modo de agir e se comportar não podem ser corrompidos pelo “sistema”.

Claro que esse é o mundo ideal e não o que vivemos, e afirmo: estamos muito longe dessa condição. Porém, os analistas de negócios que tem essa maturidade e que mantém-se imunes aos problemas do dia a dia, devem ser prestigiados e respeitados, seus valores representam que seu modo de agir não está só alinhado a estratégia da organização, mas também a sua ética.

Quais são realmente as atribuições de um analista de negócios?

Manuais, livros, instituições e afins com a devida chancela, descrevem, orientam e certificam quais as atribuições de um analista de negócios, porém em muitos casos a prática não permite que os mesmos desempenhem seu papel conforme sua essência e em muitos outros casos nem sequer dispõe das ferramentas necessárias para execução de seus trabalhos.

Especificar, modelar, descrever, prototipar e analisar as demandas são as competências padrões do analista de negócios toda mecânica utilizada nessas ações são sua responsabilidade, ele não deve ser sênior em linguagens de programação, banco de dados e aplicações técnicas, é sim um especialista nato em gerir conflitos (pessoas), conduzir/coordenar projetos, agregar mais valor às entregas, gerar indicadores, e principalmente agir como um facilitador dentro da organização.

Enfim, a grande maioria dos gestores não desenvolve nas organizações o espaço necessário para aplicação das melhores práticas e técnicas da análise de negócio, e por isso sempre afirmo e concluo: “somente unidos seremos capazes de disseminar o conhecimento e criar a cultura do analista de negócios nas empresas”.

Em síntese: O que é gerenciamento de projetos?

O gerenciamento de projetos é a aplicação de conhecimento, habilidades, ferramentas e técnicas às atividades a fim de atender aos seus requisitos. Planejamento, iniciação, execução e monitoramento, são os meios de controle que o gerente de projetos utiliza para garantir o sucesso na entrega das demandas e alcançar os objetivos esperados.

Gerenciar um projeto inclui:

• Identificação das necessidades;
• Estabeler objetivos claros e alcançáveis;
• Balancear as demandas conflitantes de qualidade, escopo, tempo e custo;
• Adaptação das especificações, dos planos, da abordagem às diferentes preocupações e expectativas das diversas partes interessadas.

É importante observar que muitos processos dentro do gerenciamento de projetos, são iterativos devido a existência e necessidade de uma elaboração progressiva durante todo o seu ciclo de vida do projeto. Isto é, conforme uma equipe aprende mais sobre um projeto, maior será seu nível de gerenciamento de detalhes e com isso, alcançar o objetivo se torna uma consequência natural.

Entendimento do ambiente do projeto

Praticamente todos os projetos são planejados e implementados em um contexto social, econômico, internacional, político, físico e ambiental, tendo impactos intencionais e não intencionais positivos e/ou negativos. Sendo assim, os envolvidos devem ter a capacidade de adaptação e versatilidade como premissas básicas nas suas ações.

Ambiente cultural e social: o time precisa entender como o projeto afeta as pessoas e como as pessoas afetam o projeto. Isso exige um entendimento de aspectos econômicos, demográficos, educacionais, éticos, étnicos, religiosos e de outras características das pessoas envolvidas. Cabe ao gestor examinar a cultura organizacional e ter a autoridade para gerenciar o projeto.

Ambiente internacional e político: talvez seja necessário que alguns membros da equipe estejam familiarizados com as leis e costumes internacionais, nacionais, regionais e locais aplicáveis, além do clima político que possa afetar o projeto. Outros fatores internacionais a serem considerados são as diferenças de fuso horário, feriados nacionais e regionais e a logística (viagens, teleconferência, etc.).

Ambiente físico: em caso de impacto no ambiente físico, alguns membros da equipe de projetos precisam conhecer bem a ecologia local e a geografia física, somente com a ciência desses aspectos, os envolvidos tem a dimensão e a realidade das causas e efeitos referente a entrega do projeto.

Por fim, o termo "gerenciamento de projetos" às vezes é usado para descrever uma abordagem organizacional ou gerencial na condução de atividades não somente ligadas a TI e sim a um contexto geral dentro de uma organização, em síntese: "é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo."

Guia do conjunto de conhecimentos em gerenciamento de projetos – (GUIA PMBOK) 3ª Edição

Escritório de gerenciamento de projetos

Da mesma forma que o conceito de projeto, o conceito de Escritório de Gerenciamento de Projetos admite muitas definições, mas sem muita variação conceitual. Pode-se definir o PMO como sendo a entidade organizacional formalmente estabelecida responsável por:

• Definir, uniformizar e defender padrões, processos, métricas e ferramentas;
• Oferecer serviços de gerenciamento, treinamento e documentação;
• Garantir o alinhamento das iniciativas à estratégia organizacional e confeccionar relatórios de progresso e acompanhamento.

Modelos, funções e composição interna:
Os PMO´s podem ser divididos em três tipos principais:

• Nível 1 – Escritório de Controle de Projetos
• Nível 2 – Escritório de Suporte aos Projetos
• Nível 3 – Escritório Estratégico de Projetos

Apesar da divisão de modelos, diferentes tipos de escritórios podem ser utilizados ao mesmo tempo em áreas distintas da organização ou mesmo dentro da mesma área. Esses modelos podem também se misturar, fazendo com que as fronteiras entre eles sejam muito tênues.

Nível 1 – Escritório de Controle de Projetos

Um PMO de nível 1 é responsável pela emissão de relatórios e pelo acompanhamento de indicadores previamente estabelecidos, sem influenciar a forma como os projetos são conduzidos. As funções de um PMO neste nível são:

• Emitir relatórios de progresso, custos, orçamento, performance e riscos.
• Manter uma base de dados de ações históricas.

Em síntese, um escritório desse nível trabalha controlando as atividades do dia-a-dia dos projetos, para ajudar os gestores a assegurar a realização das metas, resultados e orçamento planejados.

Nível 2 – Escritório de Suporte aos Projetos

Um PMO de nível 2 geralmente controla projetos grandes ou um número expressivo de projetos pequenos e médios. É responsável por:

• Todas as funções de um PMO de nível 1;
• Fornecer treinamento em gerenciamento de projetos;
• Estabelecer e verificar o cumprimento de padrões e métricas;
• Possibilitar o alinhamento dos projetos às estratégias organizacionais;
• Controlar e armazenar as lições aprendidas e os relatórios gerados;
• Definir, implementar e controlar mecanismos de controle de mudanças;
• Assumir o papel de mentor para projetos com problemas.

Assim, basicamente, um PMO de nível 2 difere de um de nível 1 principalmente pelo poder de influenciar no andamento dos projetos por meio de definição de metodologias, técnicas, métricas e ferramentas a serem utilizadas.

Nível 3 – Escritório Estratégico de Projetos

Um Escritório Estratégico de Projetos opera no nível corporativo, coordenando e definindo políticas para todos os projetos dentro da organização, gerenciando o portfólio corporativo e prestando auxílio aos escritórios de nível 1 e 2, se existirem. Neste nível, um PMO geralmente é considerado um centro de excelência em gerenciamento de projetos, guiando e ajudando o nível gerencial das organizações e demais membros dos times a alcançarem seus resultados de maneira mais eficiente.

. Neste nível de PMO, as funções principais são:

• Todas as funções do PMO de nível 2;
• Padronização do gerenciamento de projetos;
• Identificação, priorização e seleção de projetos;
• Gerenciamento corporativo de recursos;
• Implantação e manutenção de um sistema de informações;
• Alinhamento dos projetos à estratégia corporativa;
• Desenvolvimento profissional dos integrantes do PMO.

A principal diferença entre os níveis 2 e 3 dos Escritórios de Gerenciamento de Projetos é o caráter corporativo do segundo em relação ao caráter departamental do primeiro. Muitos escritórios são considerados modelos híbridos em relação aos níveis apresentados. O importante dessa divisão é observar que não se deve definir um PMO de nível 3 e ocupá-lo exclusivamente com tarefas operacionais de projetos, ou definir um PMO de nível 1 e ocupá-lo com tarefas estratégicas.

Uma das funções do PMO é ser o guardião da metodologia do gerenciamento de projetos da empresa e o responsável por sua contínua evolução. Para tanto, o escritório faz uso de um modelo de maturidade em gerenciamento de projetos.

Fonte: Promon Business & Technology Review

O Escritório de processos - Parte II

Todas as organizações precisam que seus diversos colaboradores estejam inspirados, informados e apoiados para chegar ao trabalho todos os dias procurando resolver um problema de processo ou percebendo uma oportunidade de melhoria. A Toyota Motor Corporation mostra o que é possível em termos de desenvolvimento de uma cultura de melhoria contínua. Em 2007, foi relatado que aproximadamente 600.000 sugestões de melhorias foram recebidas dos colaboradores anualmente. Especula-se que, dessas sugestões, 99% foram implementadas.

O Escritório de Processos proporciona metodologia, treinamento, relatório, coordenação, expertise, apoio e direcionamento para gerir as ações de BPM. É a chave para a melhoria e gerenciamento baseado em processos bem sucedidos.

O Escritório de Processos não assume o controle das responsabilidades existente dos gerentes de linha. As responsabilidades das unidades de negócio não são alteradas. O Escritório possui um papel de liderança e apoio para verificar se as iniciativas estão sendo concluídas corretamente. Ele proporciona um ponto central em termos de coordenação, comunicação e coaching. Ele encoraja e facilita a utilização das ferramentas e técnicas de gestão por processos da organização.

Um importante aspecto do estabelecimento de um Escritório de Processos será definir um modelo de governança efetivo que determine o relacionamento entre o Escritório e outras entidades (donos de processos, líderes de processos, gestores de negócio etc.). Existe uma diferença essencial entre o papel do Escritório de Processos e o que é frequentemente denominado de “governança de processos”. Não é papel do Escritório ser o dono de todos os processos gerenciados pela organização.

Os serviços oferecidos pelo Escritório para a organização estão categorizados tanto como “Serviços de Melhoria de Processos” ou como “Serviços da Gestão do Dia-a-Dia dos Processos”. Serviços de melhoria de processos são atividades como modelagem, análise e redesenho de processos, que são consumidos pelos projetos. Alguns projetos requisitarão um maior envolvimento do Escritório do que outros (neste caso aquelas atividades serão desenvolvidas pelas próprias unidades de negócio). Serviços de gestão do dia-a-dia incluem atividades como manutenção da arquitetura e repositório de processos, apoio à medição de desempenho e educação nos conceitos de gestão por processos. Eles são serviços geralmente executados periodicamente, ao invés de por projetos.

Fonte: O livro - Estabelecendo um escritório de processos

Escritório de processos.

O escritório na prática
Etapas-chave no desenvolvimento de um escritório de processos efetivo que aumente significativamente a performance de uma organização.

Preparar e planejar
Garantir os recursos do projeto, uma compreensão abrangente por parte dos principais interessados e dos propulsores da mudança.

Concientizar sobre o BPM

Preparar uma base sólida por meio de birefings, debates e apresentações com todas as partes interessadas, entender o histórico de BPM na organização e reforçar o uso de cases de sucesso.

Desenvolver competência interna
Criar competência interna em gestão de processos, documentar a arquitetura de processos da empresa e adaptar as metodologias para definir seu "processo de gestão de processos".

Construir e operar um escritório

Estabelecer um escritório de processos eficaz através de 3 pilares de desenvolvimento:

1 - Modelo de referência em escritório de processos;

2 - Programa de desenvolvimento de competências em BPM;
3 - Implementação em ondas.

Comunicação
Construir e manter o interesse, a urgência e o comprometimento com a gestão por processos a partir de uma visão de futuro clara e reporte periódico do progresso obtido.

Gerenciar as mudanças

Desenvolver agentes de mudança que reforcem a cultura de processos. Executar projetos que implementem mudanças de fato e entregue valor para a organização.

Demonstrar a melhoria de processos

Fazer a transição da sala de aula para o local de trabalho e da teoria a prática, através de projetos piloto e cases.

Melhorar continuamente

Coletar as lições aprendidas e dissemine boas práticas para a melhoria continua da atuação do escritório de processos.

Gestão por processos é mobilizar pessoas para gerar ganhos em uma organização, a partir de melhorias e inovações em seu dia-a-dia. Adotar gestão por processos é criar uma cultura forte que inspire continuamente os colaboradores para criar e perseguir idéias que mudem os processos e maximizem o valor gerado para os clientes.

"É o melhor caminho para que as pessoas transformem a realidade em que vivem, resolvendo seus problemas, alavancando idéias e comprovando os resultados obtidos."

Cada vez mais as organizações que demonstrem lideranças e alto desempenho estão adotando uma abordagem de gestão baseada em processos. O escritório de processos é um importante mecanismo que tem sido amplamente adotado para coordenar as iniciativas de BPM e perpetuar seus benefícios por toda a organização.

Fonte: Estabelecendo o Escritório de Processos
Roger Tregear
Leandro Jesus
André Macieira

Engenharia de software.

Perceber que atividades fazem parte do processo de engenharia de software é o primeiro passo para o concretizar, mas é também importante perceber como essas atividades do processo se relacionam umas com as outras para que se torne visível todo o processo de desenvolvimento do sistema.

O termo "modelo do ciclo de vida" é utilizado para descrever uma template que visa descrever um grupo de atividades e a forma como elas se relacionam. Os modelos mais sofisticados incluem ainda uma descrição de quando e como se deve mover de uma atividade para a próxima e as ações que devem ser produzidas em cada etapa.

A razão pela qual estes modelos são tão conhecidos é o fato de ajudar as equipas de desenvolvimento, e em particular os gestores, a obter uma visão geral do projeto de forma a ser possível segui-lo passo a passo, saber que ações foram especificadas, os recursos alocados e os objetivos propostos.

Estes "modelos de ciclo de vida" ou "modelos de processos" são tipicamente produzidos a partir de uma perspectiva de que poderão existir vários modelos para o mesmo processo, porém deles é capaz de dar uma visão completa de um determinado processo.

Independente da metodologia de desenvolvimento a ser seguida (tradicional ou iterativo e incremental), todos os sistemas bem elaborados passam pelos estágios de: concepção, criação e manutenção. No popular: "o que", "como" e "mudanças no sistema e ambiente".

Modelo tradicional (cascata)

Modelo iterativo e incremental

O processo de desenvolvimento efetivo deve considerar:

Relação entre todas as tarefas;

Ferramentas;
Metodologias utilizadas;
Treinamento;
Motivação dos envolvidos.

Fonte: http://pt.kiokea.net

Analistas de negócio valem ouro.

Apesar do artigo abaixo ser de 2008, acredito que o conteúdo ainda reflete o momento em que vivemos. É polêmico, mas incita a leitura.

"Por duas décadas, o CIO foi visto como o "link" entre as funções de negócio e tecnologia, embora esta talvez seja a percepção exata da sala da diretoria, nos bastidores os analistas de negócio são os encarregados de fazer essa ligação ao elaborar os business cases para desenvolvimento de projetos de TI, suavizando as relações entre concorrentes e impulsionando projetos.

O cargo de analista de negócio varia de acordo com a organização e a linha divisória entre funções puramente de negócio e de TI se desfez. Uma coisa é clara: a maioria dos analistas de negócio bem-sucedidos mescla o temperamento e a habilidade de comunicação de um diplomata com o talento analítico de um oficial do serviço secreto. Hoje, os analistas de negócio, valem ouro.

“Todos concordam com a importância do papel do analista de negócio, porém poucos sabem exatamente o que faz um profissional como esse.”

O analista de negócio do século 21 é um elo, uma ponte, um intermediário que equilibra a freqüente discrepância entre a oferta de recursos de TI e as demandas do negócio.

Alguns cargos de analista de negócio pendem mais para funções como operações, marketing, finanças ou engenharia. Outros analistas parecem se enquadrar melhor em postos mais voltados para TI, como em grupos de aplicativos e arquitetura ou em escritórios de projetos, porém, poucas pessoas são capazes de oferecer uma definição padronizada (com conjuntos típicos de habilidades, métodos de treinamento apropriados e carreira profissional) para o cargo.

"Analista de tecnologia do negócio o melhor amigo do CIO". Assim, surge mais uma questão relacionada a esse tipo de profissional.

Onde se encaixaria um analista de negócio em um organograma — negócio ou TI?

Distinguir entre espécies de analista de negócio faz sentido teoricamente, mas, na prática, as tendências tanto de negócio quanto de TI estão obrigando-os a assumir responsabilidades fora dos silos onde se sentem confortáveis.

A fusão definitiva do analista orientado ao negócio com o analista orientado à TI é o que alguns estudiosos denominam “analista de tecnologia do negócio”. E o indivíduo nesta função pode ser, não apenas um trunfo do CIO e do departamento de TI, mas também um elo corporativo mais bem preparado.

Estes novos analistas de tecnologia do negócio ou simplesmente analistas de negócios, são fundamentais para tornar realidade aplicativos de negócio dinâmicos ao acelerar a velocidade com que eles podem ser alterados e garantir o engajamento do usuário nestas mudanças, é um profissional que possui um mix de know-how de negócio e elevado grau de conhecimento tecnológico."

Agora pergunto: Os analistas de negócio valem ouro ou não?

Fonte: http://cio.uol.com.br

Gerenciar o desempenho da análise de negócios.

As atividades de análise de negócios precisam trazer valor a iniciativa e à organização. O analista de negócios tem a responsabilidade de garantir a melhoria dos processos e do desempenho das tarefas realizadas.

Para assegurar que haja um processo de melhoria contínua, é necessário planejar como mensurar, acompanhar, avaliar e comunicar o trabalho efetuado em relação ao desempenho, à qualidade, ao custo envolvido, ao tempo despedido.

Para permitir que o trabalho de análise de negócios transcorra com sucesso é necessário obter as métricas de desempenho de análise de negócios. Essa informação deverá ser obtida através da observação e acompanhamento das tarefas executadas.

Para entender qual o melhor momento de efetuar o acompanhamento e, também, identificar os desvios será necessário utilizar os padrões de desempenho organizacional, pois contém um planjemanento das tarefas, resultados, datas, etc.; e será necessário avaliar o alinhamento da execução versus o planejado. Além disso, será importante compreender as expectativas de mudança nos requisitos e aderência ao plano de gestão dos requisitos.

É relevante assegurar que, para possibilitar a gerência de expectativas em relação ao trabalho de análise de negócios, é necessário configurar com antecedência as métricas de medição de desempenho.

As ferramentas necessárias para o gerenciamento de desempenho são:

Entrevistas;

Processos de aprendizagem;

Métricas e indicadores-chave de desempenho;

Rastreamento de problema;

Modelagem de processos;

Análise de causa raiz;

Questionário e pesquisa;

Análise e variação.

Fontes: Prof. Ernani Marques - Um curso em um livro e www.administradores.com.br

KANBAN em poucas palavras

Como de costume, publicamos informações sobre metodologias ágeis, o KANBAN se mostra uma ferramenta eficiente, e extremamente ágil, inclusive quando utilizada em conjunto com SCRUM, mas este assunto abordarei num próximo post. Abaixo uma definição simples e em poucas palavras do que é o KANBAN:

• Visualize o Fluxo de trabalho

- Divida o trabalho em partes, escreva cada item em um cartão e coloque na parede.
- Use colunas nomeadas para demonstrar onde cada item está no fluxo de trabalho.

• Limite o trabalho em progresso (WIP - Work in progress) 

Associe Limites explícitos para quantos itens podem estar em progresso em cada estado do fluxo de trabalho.

• Acompanhe o tempo de execução da tarefa

Tempo médio para completar um item, algumas vezes chamado de "tempo de ciclo", otimize o processo para tornar o temppo de execução o menor e mais previsível possível. 

Fontes: http://www.crisp.se/kanban

Livro: Kanban e SCRUM obtendo o melhor de ambos - Henrik Kniberg & Mattias Skarin

Planejar as atividades de análise de negócio.

Planejar as atividades de análise de negócio é uma tarefa essencial para a iniciativa como um todo. Se esta tarefa for bem executada, a análise de negócio contribuirá mais fácilmente para a entrega de resultados com a quantidade almejada pelos interessados.

Um planejamento cuidadoso poderá contribuir para a entrega de um bom conjunto de requisitos que, por sua vez, contribuirá para a entrega de um produto ou serviço que agregará valor ao negócio.

Essa ação é que possibilita identificar as atividades que serão produzidas, estimar o esforço necessário para sua realização e determinar as ferramentas de gestão que serão utilizadas para o gerenciamento e medição das tarefas e das entregas.

Ao planejar as atividades, o (a) analista de negócios tem condições de definir respostas para as seguintes perguntas:

Quais entregas deverão ser produzidas?

Qual o escopo das atividades de análise de negócio?

Quais atividades deverão ser executadas, em que momento e como?

Quais são as melhores estimativas para o trabalho?

Quais técnicas devem ser utilizadas para cada atividade?

Quais ferramentas de gestão deverão ser utilizadas?

Fonte: Prof. Ernani Marques - MBA, PgMP, PMP / CBAP & PREP Um cuso em um livro

Como dividir User Stories

Muitas das novas equipes ágeis têm dificuldades em dividir suas user stories ('histórias de usuários') para obter um tamanho pequeno o suficiente de forma a trabalhar bem com técnicas de Agile. Em vários artigos, membros da comunidade Agile fornecem orientações sobre como dividir histórias de forma eficaz.

Há diretrizes gerais que podemos seguir na tentativa de dividir histórias muito longas em histórias menores? Rachel Davies recomenda quebrar cada história de modo a criar um produto que:

1. Funciona
2. Agrega valor
3. Potencialmente gera feedback dos usuários

Richard Lawrence sugere as seguintes técnicas que considera úteis no processo de divisão de histórias longas:

1. Dividir uma história de acordo com as etapas do fluxo de trabalho envolvido, talvez colocando um caso simples resumindo o fluxo como uma história, e criar histórias independentes para outras etapas do fluxo de trabalho;
2. Dividir uma história de modo que cada variação das regras de negócio seja a sua própria história;
3. Dividir uma história em "implementar o primeiro [X]" e "implementar o resto dos [X]s". Isto pode ser aplicado quando o esforço envolvido na execução do primeiro [X] será muito maior do que o de implementação de qualquer um dos [X]s subsequentes;
4. Quando se deparar com uma história complexa, separar a versão mais simples da história como uma história independente;
5. Dividir uma história baseando-se nos tipos de dados que manipula;
6. Dividir uma história pela diferenciação entre um método simples de entrada de dados e um mais complexo;
7. Mover as considerações sobre desempenho da história atual para uma ou mais novas histórias;
8. Dividir uma história de acordo com criação, leitura, atualização e exclusão (CRUD), uma ou mais para cada uma dessas ações;
9. Em última instância, criar uma história para descobrir como implementar uma funcionalidade do sistema.

Rachel Davies oferece outros detalhes sobre como dividir as histórias com relação aos dados de entrada e saída, indicando que se pode criar histórias para cada tela de entrada de informações, ou para cada elemento habilitado na interfa gráfica do sistema.

Além disso, Bob Hartman oferece as seguintes técnicas para divisão de histórias:

• Em uma história que envolve múltiplas personas, dividi-la por persona;
• Dividir uma história de forma que as partes de alto risco fiquem separadas das partes de baixo risco;
• Dividir histórias de forma a maximizar o número de desenvolvedores que podem trabalhar em cada história;
• Dividir histórias de forma a facilitar os testes;

Quais caminhos para divisão de histórias de usuários você considerou mais úteis?

Fonte: InfoQ

Levantamento de Requisitos e Mapeamento de Processos

O levantamento de requisitos é uma das partes mais importantes do processo que resultará no desenvolvimento de um sistema. Entender aquilo que o cliente deseja ou o que o mesmo acredita que precisa e as regras do negócio ou processos do negócio. Isso é cerne que move essa importante função que faz parte da engenharia de requisitos.

Aliado ao levantamento de requisitos existe o mapeamento dos processos que é de vital importância para a melhoria dos resultados obtidos nesse levantamento. Muitos sistemas são retardados em seu prazo estipulado na fase de definição de escopo do projeto ou até mesmo morre durante seu percurso, pois, a etapa de levantamento de requisitos é negligenciada ou simplesmente feita de forma ineficaz.

Existe também um personagem, que é constantemente deixado em segundo plano, no mapeamento dos processos, o especialista do domínio ou especialista do negócio. É o profissional que possui experiência no ramo ou nicho de mercado do negócio para qual o sistema atenderá em suas funcionalidades. Porém, um fato é que as empresas esbarram em um sério problema, a dificuldade em encontrar esses indivíduos (importante informação essa, concorda?).

Para desenvolver sistemas profissionais e de qualidade, precisamos levantar de forma eficaz e com seriedade os requisitos. Para isso, é necessário ter bons profissionais em diversas áreas do ciclo de desenvolvimento: analista de requisitos, analista de processos, analistas de testes, gerentes de projetos, desenvolvedores, analistas de qualidade, e outros de acordo com a necessidade específica de cada projeto.

Acredito seriamente na importância do levantamento de processos, mapeamento e melhoria dos processos de negócio.

Fonte: www.qualidadebrasil.com.br

BPM E SOA HABILITAM AGILIDADE DE TI E NEGÓCIOS

BPM em SOA permite ao pessoal de TI projetar, construir, registrar e instalar serviços de negócios reutilizáveis, que podem ser descobertos e executados em processos de negócios.

Até que a fase de adaptação seja superada e os clientes entendam a real necessidade de ferramentas de análise, os forncedores estão apresentando novidades em soluções BPM. É possível que em determinadas soluções a organização possa acompanhar a aplicação, execução e desenvolvimento dos fluxos críticos de informação, essas ferramentas estão em constante modernização e podem integrar os processos de forma mais eficaz.

O mercado está observando como as soluções de BPM podem ajudar no dia-a-dia, pois a implementação acaba sendo uma forma de as companhias adquirirem vantagens competitivas, já que a redução dos custos é repassada para os clientes e torna o negócio, qualquer que seja ele, muito mais atraente.

O FUTURO

O mercado de BPM cresce anualmente a uma taxa de 20%. Inicialmente, o primeiro olhar para BPM estava focado principalmente na automatização e na integração, porém a tendência é que ele se desloque principalmente para o cumprimento das normas, para a agilização dos negócios, das aplicações e para a otimização.

Fonte: BPM Executive Report

Governança - estudo técnico.

Para segmentar essa ação, identifique no fluxo sua execução:

Considerada uma atividade prática, o Estudo Técnico tem o conceito de contextualizar a estratégia e ações adotadas pela área de TI sobre as demandas solicitadas, baseado em todos os pilares da análise de negócios, esse documento é formal e detalha ponto a ponto o posicionamento da TI sobre o assunto.

Direcionado pelo objetivo da organização, o cenário atual é traçado e sintetizado na visão de valores e necessidades. Apoiado nos requisitos funcionais e não funcionais, é elaborada a lista GAP´s e as questões técnicas dos projetos. Através das RFP´s os envolvidos são convocados para reunião de negociação/avaliação de investimento, visão de riscos e prévia do cronograma.

Por fim, analisadas as vantagens e desvantagens de cada envolvido, de forma isenta o AN descreve seus comentários e posicionamentos sobre cada participante, e "constrói" sua conclusão.

Vale ressaltar que essa atividade é complexa e considerada de alto risco, pois os desdobramentos impactam diretamente no orçamento da área e da organização, portanto, recomendo: façam planejamento e sempre alinhem-se a estratégia da empresa.

O Cobit sob uma perspectiva de controle a serviços e processos.

Maturidade das ações, qualidade na condução das atividades, normatização e formalização dos procedimentos, são os pilares do sucesso na gestão dos projetos e processos. As melhores práticas e a disseminação de metodologias de trabalho refletem na entrega (conceito de pronto).

O ciclo lógico das fases de controle reflete em levantamentos e identificação de requisitos, aspectos clássicos para a gestão de processos.

A fase de levantamento permite quantificar o desempenho atual dos processos e evidenciar por meio de documentação a maturidade dos processos. Os registros das situações encontradas através de parâmetros qualitativos permitem o apontamento das não-conformidades a serem tratadas durante o monitoramento das ações.

Dentre os aspectos comumente existentes: a ausência de metodologias, gerenciamento de aderência da aplicação, normatização de padrões, falta de indicadores, planos de testes e treinamentos, impactam diretamente na fase de planejamento, que gera como conseqüência um modelo de implantação ineficiente, retrabalho, clientes insatisfeitos, aumento de custo.

Analisar, investigar, mitigar recursos e meios de condução, são os conceitos para aprofundar o entendimento da situação atual. Aproveitar o conhecimento e a expertise dos envolvidos especificamente onde cada um é mais competente e capaz de prover soluções é uma estratégia (e no meu conceito, a melhor estratégia), para o gestor, no entanto é uma ação ousada, pois a conseqüência natural é a gestão compartilhada ou auto-gestão e com isso voltamos ao quesito MATURIDADE.

Para lidar com uma equipe com auto-gestão é preciso que as ferramentas de controle para mensurar o desempenho e o conceito de pronto, contribuam para com a melhoria dos processos do dia a dia, e que não afetem o planejado. Transformar os pontos de controle em atividades operacionais do processo, e o objetivo sempre como a referência a ser alcançada.
O mais alto nível na construção de controles segue um modelo de aplicação direta e completa do CobiT, definir claramente as expectativas do processo, no exemplo abaixo um modelo utilizado por uma das maiores organizações de tecnologia do mundo:

Porém, é preciso definir quais os objetivos desses controles, sua forma de medição:
Metolodogias aplicadas a testes de aceite, homologação e provas de entregas;
Revisão e pós-implementação;
Métodos de medição;
Checklists;

Estratégia do “entregável”:
Foco na estrutura do processo;
Objetivo;
Equiparar experiências e idéias de forma padronizada;
Relacionamento dos produtos recebidos e resultados entregues;
Garantia que todas as atividades estão cobertas;
Fatores críticos do sucesso (FCS);
Indicadores chave do sucesso e Indicador chave do desempenho (KGI e KPI)
Geração de documentação e evidencia à auditorias;
Definir claramente o escopo e expectativas sobre o processo.

Relatório de acompanhamento:
Relatório de entrega ao final de cada fase crítica do processo.

Envolvimento do time:
Treinamento de forma estruturada em todas as fases do projeto de desenvolvimento, manutenção ou implantação de sistemas.

Gestão de melhora contínua:
Análise e aprovação da metodologia proposta pela TI a alta direção;
Período de uso assistido dessa metodologia e divulgação dos indicadores de performance do processo.

Acredito que para utilização do CobiT, o fator principal é conseguir o patrocínio da alta direção, ou seja, o peso decisório gestor no conceito cultural e maduro dos elementos da organização, pois os subsídios gerados durante sua utilização no dia a dia remetem a registros e controles de documentações mais severos e de alto nível.

Para uma gestão de serviços de TI mais profissional, atuar com CobiT garante ao fornecedor de serviços, desenvolver uma atividade com maior qualidade, custo compatível e o alinhamento aos requisitos do negócio.