Pesquisar neste blog

31 de mar. de 2012

Activiti 5,9 introduz Compensação BPMN e Transações

Por:   Daniel Meyer 



In activiti 5.9 we introduce experimental support for transactions and compensation. Both are interesting features, mainly if you are working in the domain of application integration and B2B processes.

Compensation

Compensation is a means for “undoing” the effects of an action. For example, say you charge the amount of 500€ to a credit card. If you later detect that this was an error, you may want to undo this. One way of doing that is crediting the same account 500€.
Now wait, isn’t that what transactions are for? Can I not just rollback the transaction in which I charged the 500€ and I am done?  – Well yes, but there are two problems:
  • The service you are using might not support transactions.
  • You might notice that it was wrong to charge the 500€ too late, at a time where the transaction is already committed.
In both cases we cannot simply “go back in time” and do as if nothing happened. On the contrary, we need to make something else happen, in order to compensate the effects of an action we erroneously committed.
(As we know from real life experience, this is not always that simple and therefore, in general, compensation is not always a strict “undo” action. Consider the case where you send a letter to a customer and then later notice that you need to compensate the sending of the letter. At that point, the customer might have already read the letter. You cannot simply “undo” that fact. What you might do in that situation is send a second letter, asking the customer to forget about the first one.)

Compensation in BPMN 2.0

In BPMN, the concept of compensation is introduced, using compensation events and compensation handlers. For example, the following excerpt of a process shows how we can declare that the “book hotel” activity can be compensated using the “cancel hotel reservation” activity. If a task has multiple instance characteristics (like the “book hotel” task in this example), the compensation handler is invoked for each instance that completed successfully.
The intermediate throwing compensation event allows us to trigger the compensation of the scope it is hosted in or of a specific activity from that scope:
When compensating a subprocess, the execution used for executing the compensation handlers has access to the local process variables of the subprocess in the state they were in when the subprocess completed execution. To achieve this, a snapshot of the process variables associated with the scope execution (execution created for executing the subprocess) is taken. Form this, a couple of implications follow:
  • The compensation handler does not have access to variables added to concurrent executions created inside the subprocess scope.
  • Process variables associated with executions higher up in the hierarchy, (for instance process variables associated with the process instance execution are not contained in the snapshot: the compensation handler has access to these process variables in the state they are in when compensation is thrown.
  • A variable snapshot is only taken for subprocesses, not for other activities.

Compensation in activiti 5.9

Activiti supports compensation boundary events and intermediate throwing compensation events.
The following limitations apply:
  • waitForCompletion="false" is currently unsupported. When compensation is triggered using the intermediate throwing compensation event, the event is only left, after compensation completed successfully.
  • Compensation itself is currently performed by concurrent executions. The concurrent executions are started in reverse order in which the compensated activities completed. Future versions of activity might include an option to perform compensation sequentially.
  • Compensation is not propagated to sub process instances spawned by call activities.
The concept of compensation is also used in transaction subprocesses.

Transaction subprocesses in BPMN 2.0

A transaction subprocess can be used to group multiple activities to a logical unit of work with a consistent outcome. Since BPMN transactions are long running transactions, they make use of compensation for ensuring consistency in case a transaction fails.
A transaction can have three different outcomes:
  • A transaction is successful, if it is neither cancelled nor terminated by a hazard. If a transaction subprocess is successful, it is left using it’s outgoing sequenceflow(s). A successful transaction might be compensated if a compensation event is thrown later in the process.
    Note: just as “ordinary” subprocesses, a transaction may be compensated after successful completion using an intermediary throwing compensation event.
  • A transaction is cancelled, if an execution reaches the cancel end event. In that case, all executions are terminated and removed. A single remaining execution is then set to the cancel boundary event, which triggers compensation. After compensation is completed, the transaction subprocess is left using the outgoing sequence flow(s) of the cancel boundary event.
  • A transaction is ended by a hazard, if an error event is thrown, that is not caught within the scope of the transaction subprocess. (This also applies if the error is caught on the boundary of the transaction subprocess.) In this case, compensation is not performed.
The following diagram illustrates the three different outcomes of a transaction:
Relation to ACID transactions: it is important not to confuse the bpmn transaction subprocess with technical (ACID) transactions. The bpmn transaction subprocess is not a way to scope technical transactions.  A bpmn transaction is different from a technical transaction in the following ways:
  • While an ACID transaction is typically short lived, a bpmn transaction may take hours, days or even months to complete. (Consider the case where one of the activities grouped by a transaction is a usertask, typically people have longer response times than applications. Or, in another situation, a bpmn transaction might wait for some business event to occur, like the fact that a particular order has been fulfilled.) Such operations usually take considerably longer to complete than updating a record in a database, or storing a message using a transactional queue.
  • Because it is impossible to scope a technical transaction to the duration of a business activity, a bpmn transaction typically spans multiple ACID transactions.
  • Since a bpmn transaction spans multiple ACID transactions, we loose ACID properties. For example, consider the example given above. Let’s assume the “book hotel” and the “charge credit card” operations are performed in separate ACID transactions. Let’s also assume that the “book hotel” activity is successful. Now we have an intermediary inconsistent state, because we have performed an hotel booking but have not yet charged the credit card. Now, in an ACID transaction, we would also perform different operations sequentially and thus also have an intermediary inconsistent state. What is different here, is that the inconsistent state is visible outside of the scope of the transaction. For example, if the reservations are made using an external booking service, other parties using the same booking service might already see that the hotel is booked. This means, that when implementing business transactions, we completely loose the isolation property (Granted: we usually also relax isolation when working with ACID transactions to allow for higher levels of concurrency, but there we have fine grained control and intermediary inconsistencies are only present for very short periods of times).
  • A bpmn business transaction can also not be rolled back in the traditional sense. Since it spans multiple ACID transactions, some of these ACID transactions might already be committed at the time the bpmn transaction is cancelled. At this point, they cannot be rolled back anymore.
Since bpmn transactions are long-running by nature, the lack of isolation and a rollback mechanism need to be dealt with differently. In practice, there is usually no better solution than to deal with these problems in a domain specific way:
  • The rollback is performed using compensation. If a cancel event is thrown in the scope of a transaction, the effects of all activities that executed successfully and have a compensation handler are compensated.
  • The lack of isolation is also often dealt with using domain specific solutions. For instance, in the example above, an hotel room might appear to be booked to a second customer, before we have actually made sure that the first customer can pay for it. Since this might be undesirable from a business perspective, a booking service might choose to allow for a certain amount of overbooking.
  • In addition, since the transaction can be aborted in case of a hazard, the booking service has to deal with the situation where a hotel room is booked but payment is never attempted (since the transaction was aborted). In that case the booking service might choose a strategy where a hotel room is reserved for a maximum period of time and if payment is not received until then, the booking is cancelled.
To sum it up: while ACID transactions offer a generic solution to such problems (rollback, isolation levels and heuristic outcomes), we need to find domain specific solutions to these problems when implementing business transactions.

Transaction Subprocesses in Activiti 5.9

The BPMN specification requires that the process engine reacts to events issued by the underlying transaction protocol and for instance that a transaction is cancelled, if a cancel event occurs in the underlying protocol. As an embeddable engine, activiti does currently not support this.
A bpmn transaction guarantees consistency in the sense that either all activities compete successfully, or if some activity cannot be performed, the effects of all other successful activities are compensated. So either way we end up in a consistent state. However, it is important to recognize that in activiti, the consistency model for bpmn transactions is superposed on top of the consistency model for process execution. Activiti executes processes in a transactional way. Concurrency is addressed using optimistic locking. In activiti, bpmn error, cancel and compensation events are built on top of the same acid transactions and optimistic locking. For example, a cancel end event can only trigger compensation if it is actually reached. It is not reached if some undeclared exception is thrown by a service task before. Or, the effects of a compensation handler can not be committed if some other participant in the underlying ACID transaction sets the transaction to the state rollback-only. Or, when two concurrent executions reach a cancel end event, compensation might be triggered twice and fail with an optimistic locking exception. All of this is to say that when implementing bpmn transactions in activiti, the same set of rules apply as when implementing “ordinary” processes and subprocesses. So to effectively guarantee consistency, it is important to implement processes in a way that does take the optimistic, transactional execution model into consideration.
The following is a larger example of a transction subprocess which can be executed by activiti:

30 de mar. de 2012

Modelagem Ágil: aperfeiçoando a comunicação e a compreensão

Por: INFOQ
Em: http://processosprojetosageis.blogspot.com/2012/02/modelagem-agil-aperfeicoando.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+GestoDeProcessosEProjetosgeis+%28Gest%C3%A3o+de+processos+e+projetos+%C3%A1geis%29

Estatísticas alarmantes mostram que os projetos de TI chegam a custar 400% mais que o previsto, realizando apenas 25% dos benefícios prometidos. Embora pesquisas do Standish Group mostrem alguma melhora neste quadro, estamos ainda muito longe do sucesso em projetos de TI.
Podemos classificar o fracasso dos projetos em duas categorias:

Técnico:

A solução não atende aos requisitos do projeto (escalabilidade, performance, confiabilidade, custo etc.);
Devido aos desafios técnicos, prazos são ultrapassados, até que os patrocinadores perdem a confiança e encerram o projeto.

Funcional:

A equipe não compreende os requisitos fornecidos;
Os requisitos fornecidos não são os requisitos corretos.


Parte dos problemas se deve a um pensamento simplista de causa e efeito entre os domínios do problema e da solução. Acredita-se que, compreendido o problema, basta encontrar uma solução.








A Modelagem Ágil é coerente com o Manifesto Ágil e seus princípios. Portanto, é uma prática que pode fazer parte do seu repertório de ferramentas ágeis.









Entretanto, os atuais projetos de TI são maiores em escopo, custo e prazo, além de serem mais complexos, envolvendo muitos sistemas e departamentos de uma ou mais empresas. A compreensão do problema e da solução caminham juntos, ou seja , à medida que são propostas soluções, compreende-se melhor o problema.




Esse processo iterativo de análise nos domínios do problema e da solução é ainda mais complexo do que a visão simplificada anterior, por envolver divers a s partes interessadas com pontos de vista e capacidades de compreensão diferentes.






A figura acima resume as causas de fracasso do ponto de vista funcional mencionadas no início. E o fracasso funcional é uma das grandes causas dos fracassos técnicos. Portanto, as seguintes dimensões são cruciais para o sucesso nos projetos:


Compreensão
Compreendemos o domínio do problema?
Compreendemos o domínio da solução?
Compreendemos a transição entre esses dois domínios?
Comunicação
As partes interessadas são capazes de comunicar os requisitos para aqueles que irão desenvolver a solução?
Os membros da equipe que desenvolverá a solução são capazes de comunicar os detalhes da solução entre eles?
A equipe de desenvolvimento é capaz de comunicar os desafios e alternativas para as partes interessadas? 


Os ideais básicos do Agile (manifesto , princípios e bom senso) surgiram da necessidade de reforçar as dimensões de compreensão e comunicação.










A figura anterior ilustra o Manifesto Ágil, em que (nunca é demais lembrar):


Indivíduos e interações são mais importantes que processos e ferramentas; 
Responder a mudanças é mais importante que documentação; 
Colaboração com o cliente é mais importante que negociação de contratos; 
Software funcionando é mais importante que seguir um plano.


Embora a modelagem seja uma técnica importante em desenvolvimento de softwarem inclusive em metodologias ágeis, frequentemente é subestimada ou mal entendida. Na luta contra o desenvolvimento centrado em processos burocráticos e contra o desenvolvimento baseado em ferramentas, a modelagem acabou sendo atacada também. Precisamos corrigir essa má impressão.


Um bom começo é definição de modelagem, basicamente, a modelagem é a simplificação da realidade. Não significa utilizar determinada notação, ferramenta ou processo, permite compreender e focar nos aspectos importantes, sem detalhes desnecessários.


Considerando essa definição, podemos avançar e descrever a ideia de modelagem ágil. Isto posto, adotamos uma abordagem ágil usando modelos que nos auxiliam a compreender e comunicar.


Aspectos relevantes de Modelagem Ágil:

O processo de modelagem e os modelos suportam comunicação e compreensão;
A Modelagem Ágil busca criar modelos simples usando ferramentas simples (adote a simplicidade);
O foco é entregar software, não modelos. Modelos devem ser usados quando e onde adicionam valor. Se eles não agregam valor nem nos auxiliam no sentido de entregar software funcionando, então não devem ser utilizados;

Modelos devem ser mantidos pelo tempo necessário. Se um modelo serviu ao seu propósito e deixa de ser necessário, jogue fora. Isso permite manter a agilidade sem burocracia. Por outro lado, se seu modelo pode ainda ser útil, guarde ou recicle.

A Modelagem Ágil utiliza múltiplos modelos para diferentes perspectivas, níveis de abstração e públicos. Cada modelo é criado a partir de um objetivo e para satisfazer determinado público.

A Modelagem Ágil combina modelos formais e informais conforme a situação, público-alvo e objetivos. Por exemplo, um modelo poderia ser composto de formas simples desenhadas a lápis ajudando o essencial de um sistema, ou utilizando diagramas detalhados de classes do UML.


Conclusões

Para valorizar pessoas e suas interações é preciso fortalecer a comunicação. Em vez de investir em novas ferramentas ou adotar processos prescritos, sugerimos uma abordagem diferente, a Modelagem ágil. A utilização de métodos de modelagem facilita a compreensão do problema e da solução, além de melhorar a comunicação entre os stakeholders e resposta a mudanças.

29 de mar. de 2012

A importância do Business Case para projetos

Por: Anderson Gonzaga de Souza
Em: http://www.tiespecialistas.com.br/2012/02/a-importancia-do-business-case-para-projetos/


A dinâmica na econômia global, custos crescentes e a competitividade, fazem com que as empresas assumam riscos cada vez maiores para atingir os seus objetivos comerciais. A visão conservadora do gerenciamento de projetos, onde objeto de desejo era atingir as metas de prazos, custos e tempo, estão cada vez mais se tornando insuficientes para os negócios. Mesmo cumprindo os objetivos da triple constraints, os benefícios esperados com o projeto não são entregues. A pressão por resultados tem feito com que cada vez mais, as empresas organizem o seu portifólio de projetos orientados a “valor”. Permitindo responder aos investidores não somente questões relacionadas a custo e prazo, mas também aos benefícios gerados pelo projeto.

Quando existe a necessidade de investir recursos em um projeto, a organização precisa materializar esse desejo (Equilíbrar Benefícios, custos e riscos) em um “Business Case”. Esse documento de projeto, tem papel fundamental para organização. Pois através dele, será possível avaliar os benefícios, permitindo a organização priorizar os projetos.

O Business Case precisa suportar o projeto durante todo o seu ciclo de vida. Possibilitando em diferentes momentos avaliar sobre continuidade ou não do projeto. O Business case precisa apoiar a organização, validando se os objetivos e valor propostos pelo projeto continuam sendo válidos.

Apesar de reconhecer a importância do Business case para o negócio, muitas empresas não o fazem. Mas quais seriam os motivos? Me arrisco a sugerir alguns:
  • Não sei por onde começar;
  • Não precisamos planejar, pois sabemos o que fazer;
  • Não vou formalizar em um documento e assumir compromissos pois me traz desconforto.
O Business Case tem como objetivo responder alguns questionamentos, antes e durante o ciclo de vida do projeto, tais como:
  • Vale a pena iniciar esse projeto?
  • Por que estamos fazendo esse projeto?
  • Vale a pena continuarmos com o projeto?
  • Quais os benefícios?
  • Quais os efeitos colaterais com esse projeto?
A justificativa de negócio é a razão de ser do projeto, sendo assim, nenhum projeto pode iniciar sem uma. Se a justificativa de negócio for válida no início do projeto, mas deixar de ser durante a execução, o projeto deve ser interrompido ou modificado.

Avaliar somente os benefícios do projeto é um dos grandes equívocos que as empresas cometem durante o desenvolvimento de projetos. Deve-se avaliar os ganhos e perdas com o projeto.

Sua empresa vai investir R$ 200.000 em uma solução de CRM e que espera ter um retorno sobre seu investimento em 20 meses devido à redução de duas pessoas no departamento administrativo da empresa. Menos trabalho administrativo será necessário, pois os clientes podem agora encomendar e ver todas as informações on-line pela internet, ao invés de fazer contato telefônico.

No entanto, 2 meses depois do projeto iniciado, você encontra o seguinte situação: Três de seus maiores clientes não desejam utilizar a nova solução WEB em seu departamento de compras, pois o acesso a internet é restrito. Assim você terá que manter pelo menos 1 pessoa no administrativo. Portanto, o retorno do seu investimento vai mudar e vai demorar 30 meses ao invés de 20 meses, para recuperar o investimento no projeto. O Business Case deve ser atualizado com esta informação.


O manual PRINCE2 diz que: “ A justificativa de negócio é documentada em um Business case que descreve as razões do projeto com base em estimativa de custo, riscos e benefícios esperados.”

Com o Business case a alta administração pode avaliar de forma segura, quais os projetos possuem maior contribuição para os objetivos estratégicos da organização. Permitindo a organização avaliar em quais projetos investir.

O produto do projeto (Saída) e as mudanças obtidas com esses produtos ( Resultados) precisam estar relacionadas aos ganhos (Benefícios) esperados.

Quando a empresa decide implantar um sistema de gestão empresarial, ela deve especificar junto aos principais usuários do projeto, os benefícios esperados com o produto do projeto.

O executivo, por sua vez, é responsável por assegurar que os benefícios específicados, tenham boa relação custo/benefício, que estejam alinhados com os objetivos da organização e que possam ser realizáveis.
Exemplo:
Saídas: Implantar sistema de gestão.
Resultados: Eliminar redundâncias, reduzir processos manuais e integrar departamentos da empresa.
Benefícios : Redução dos custos em 15%, melhorar o tempo de resposta dos departamentos da empresa em 30 % e aumentar as vendas em 10%.


Portanto, a relação entre saídas, resultados e benefícios deve acompanhar o projeto: antes, durante e depois do projeto ser finalizado. A proposta do manual PRINCE2 é que esses vínculos estejam claramente visíveis, pois geralmente os projetos se concentram na produção do produto do projeto e os benefícios e resultados esperados, se perdem do propósito original do projeto.


Gostou? Você encontrará maiores informações sobre esse assunto no manual Managing Successful Projects with PRINCE2® 2009 Edition (Brazilian Portuguese Translation), 2011.

Também recomendo o livro do colega Robériton Luís Oliveira Ribeiro “GERENCIANDO PROJETOS COM PRINCE2″ da editora Brasport.
Referências:
OGC, Office Goverment Commerce; Managing Succesful Projects with PRINCE2™. Edição 2005, Publicado por TSO (The Stationery Office).
OGC, Office Goverment Commerce; Tailoring PRINCE2™. Edição 2004, Publicado por TSO (The Stationery Office).
PRINCE2™; Site : www.prince2.org.uk
PMI (Project Management Institute); PMBOK – Project Management Bod of Knowlodge, 4rd editon.

28 de mar. de 2012

Análise do processo de gestão de contratos em fábrica de software

Por: Renato Rosalino
Em: http://www.tiespecialistas.com.br/2012/02/analise-do-processo-de-gestao-de-contratos-em-fabrica-de-software/

1.   Introdução
O processo de gestão de projetos/sustentação em um modelo de fábrica de software é muito mais complexo do que se imagina. É necessário conhecer bem o cliente, seus negócios e seus sistemas. É necessário conhecer as tecnologias e os processos nos quais o contexto está inserido. Saber lidar com pessoas, prazos e escopo é fundamental para o sucesso do contrato.

O processo de fábrica de software/sustentação baseia-se em serviços. O cliente contrata serviço e não mais pessoas para fazerem os serviços. Estes serviços tem de ser orçados, aprovados e executados. Aí há um processo de gestão que não havia em contratos de mão-de-obra, onde os serviços chegavam por email, tapinha nas costas, telefonema, conversas informais e formais.

Os novos contratos do governo federal para a modalidade de serviços de fábrica de software/sustentação, baseia-se não mais na contratação de homem/hora e sim de pontos de função (utilizando-se da técnica de Análise de Pontos de Função e suas variantes). A partir do número descoberto pela aplicação da métrica (analogamente falando compara-se com metro quadrado) e, de acordo com o estabelecido por cada contratante, são encontrados o esforço, custo e prazo para cada serviço demandado.
2.   Estabelecer a confiança do cliente
Em um contrato de fábrica de software/sustentação o primeiro passo é conquistar a confiança do cliente. Esta conquista vem do trabalho e do empenho em conhecer bem suas demandas, tecnologias e processos. Entregar um bom serviço dentro do prazo e da qualidade desejados.

Precisamos então tomar conhecimento do que será repassado para a CONTRATADA e o que é o cliente que fará, ou seja, estabelecer claramente papéis e responsabilidades. É importante conhecer também os processos para a execução do serviço e todas as demais informações relativas aos sistemas que serão desenvolvidos e/ou mantidos.

Precisamos entender quais são as demandas do cliente. Esse conhecimento irá auxiliar a empresa a definir a carga de trabalho e serve como orientação para controle do uso dos recursos da mesma de acordo com cada cliente.

Todo contrato é regido por normas e regras que devem ser seguidas na sua plenitude. Não existe contrato perfeito e por isso é que existe um dispositivo chamado Aditivo Contratual. Este dispositivo permite à Contratante fazer adequações para melhorar a execução do contrato.

Quanto melhor a empresa estiver conhecendo a aplicabilidade do contrato, melhor será para a sua gestão e negociação de fatores de risco com o cliente.
3.   Estabelecer a confiança dos funcionários
Paralelo ao primeiro passo, outro fator de grande importância para o sucesso da gestão de um contrato de Fábrica de Software/Sustentação é a confiança dos funcionários, tanto com o contrato quanto com seus líderes, pares e clientes.

É preciso entender o perfil de cada um, procurando identificar seus pontos fortes e fracos, tanto na esfera profissional quanto na pessoal. Uma pessoa trabalha mais satisfeita e produtiva quando seus aspectos de vida estão ajustados (Trabalho, Família, Relacionamentos, etc). É preciso aos poucos aproveitar o melhor que cada um tem e pode dar de si ao trabalho que será executado. Desta forma haverá uma sincronia e cumplicidade com o serviço, uma vez que, rotina de fábrica não há exclusividade a um único projeto e cliente.

É preciso identificar qual a capacidade de produção das pessoas, seus conhecimentos e habilidades. Esse conhecimento oferece à fábrica, informações a cerca da capacidade de trabalho de seus colaboradores, de acordo com o perfil funcional, o que serve como orientação para definir os perfis necessários para o atendimento de seus projetos.

De igual forma é preciso ter em mãos a produtividade da fábrica que está sendo gerenciada. A produtividade de uma fábrica de software deve ser calculada não apenas pelo número de horas gastas nos projetos mas também por uma métrica que permita conhecer o tamanho do software que será desenvolvido/mantido. Para isso utiliza-se mais comumente a técnica de APF (Análise por Ponto de Função), que baseia-se no cálculo das informações (requisitos) considerando o peso de cada especificação. Tendo o conhecimento a cerca da sua produtividade em termos de pontos por função, é possível planejar seus projetos/manutenções com maior assertividade e segurança.
4.   Criar mecanismos de gestão (ferramentas, planilhas, etc)
a) Gestão de Ordens de Serviço (ferramenta automatizada)
Toda gestão necessita de informações com velocidade e precisão e para isso, faz-se necessário o uso de uma ferramenta automatizada. Esta ferramenta deve possibilitar:

  • O registro das Ordens de Serviço com todas as informações importantes e relevantes para o entendimento da demanda e seus prazos;
  • O recebimento das Ordens de Serviço e retorno ao demandante da solução ao pedido, estabelecendo prazos e custos baseado em acordos previamente estabelecidos em contrato;
  • A validação do orçamento (esforço, custo e prazo) informado pela Contratada ao demandante;
  • O acompanhamento da execução do serviço
  • A gestão da fila de espera para cada uma das Ordens de Serviço
  • O registro de todas as ocorrências de idas e vindas de cada Ordem de Serviço, registrando também pagamentos e faturas;
b) Gestão do Contrato
A Gestão do Contrato é tão importante quanto a gestão das Ordens de Serviço. Esta gestão possibilita ao corpo estratégico da empresa tomar decisões com base em informações concretas. Permite ao gestor do contrato e líderes técnicos, administrarem melhor o contrato e tomar ações/atitudes focadas na melhoria da execução do contrato e por consequência, na das Ordens de Serviço.

Existem algumas formas de coletar e tratar os dados oriundos das Ordens de Serviço e de acordos/tratados feitos para a execução do contrato. Planilhas Eletrônicas, ferramentas automatizadas de gestão, ferramentas de BI, etc. Seja qual for a ferramenta ou somatório de mais de uma delas, é necessário coletar dados que possibilitem:
  • O registro das Ordens de Serviço com todas as informações importantes e relevantes para o entendimento da demanda e seus prazos;
c) Gestão de Receitas x Despesas

Ficar atento à geração de receita versus o controle das despesas é fundamental para a saúde do contrato. Receita vem de serviços demandados, executados e homologados pelo cliente. Despesa vem do custo com pessoal e administrativo.


O controle das despesas pode vir do controle dos custos administrativos visto que, reduzir custos com pessoal significa contratar recursos mais baratos ou até mesmo reduzí-los.
Já a gestão da receita é bem mais intensa, pois é refletida diretamente pela quantidade de serviço que é demandado, executado e validado mensalmente. Portanto, a atenção neste quesito deve focar em:
  • Buscar demandas com o cliente pois, apesar de os contratos em geral não se obrigarem a contratar a quantidade de serviços estimados, cabe ao gestor do contrato estar em plena sintonia com seus liderados e cliente para que a demanda de serviços seja constante e frequente.
  • Gerir a fábrica de tal forma que permita aos técnicos serem produtivos
  • Dar atenção aos serviços demandados x executados visto que, muitas vezes há possibilidade de garimpar novos serviços dentro das demandas que já estão sendo executadas. Isto significa uma atenção maior do corpo técnico, tanto no que está executando/implementado quanto nas possibilidades de novas implementações que podem ser demandadas dentro da esfera do sistema que está sendo mantido.
  • Cobrar do cliente a homologação dos serviços executados e entregues pois, na grande maioria dos contratos, estão estabelecidos Acordos de Níveis de Serviço somente para a Contratada e quase nunca para a Contratante. Com isso, o cumprimento de prazos vale somente para a Contratada e faz-se necessário que o gestor do contrato e líderes de fábrica estejam em constante sintonia com o cliente, cobrando-o as homologações
5. Conclusões
Diante do exposto já deu pra perceber que fazer a gestão de um contrato de fábrica de software não é nada simples. Além da mudança de cultura para o cliente e os colaboradores, agrega-se a isto o fato de receber por serviço e não mais por disponibilidade.

Muita atenção às regras do contrato antes de encarar a licitação. Solicite vistas a todos os anexos mencionados no contrato. Leia-os com atenção. Faça incansáveis simulações em cima das estimativas de serviços a serem contratados. Leia atentamente as regras do contrato. Atenção mais que especial aos Indicadores de Níveis de Serviço pois geram multas e penalidades. Use a seu favor lições aprendidas com outros contratos. Faça do seu cliente o seu aliado e não somente o demandante de serviços e gerador de suas receitas.

Negocie formas aceitáveis de se executar determinadas regras do contrato, quando estas não estiverem claras e permitirem flexibilidade de entendimento. Documente tudo, guarde e-mails, documentos, planilhas. Gerencie as ordens de serviço em ferramenta automatizada, tenha um ótimo Analista de Métricas com muita vivência e experiência de mercado, de preferência que este já tenha sido analista/desenvolvedor de sistemas.

Acima de tudo seja honesto com seu cliente e com sua equipe. Jogue limpo. Lembre-se que a mentira precisa ser combinada com muita gente e a verdade não. Faça sua escolha e bom contrato!

27 de mar. de 2012

A difícil arte de priorizar projetos de TI

Por: BETH STACKPOLE
Em: http://computerworld.uol.com.br/gestao/2012/02/24/a-dificil-arte-de-priorizar-projetos-de-ti/


Como gestor de tecnologia de ponta na Aspen Skiing Compan durante os últimos 16 anos, Paul Major aperfeiçoou a arte de manter várias bolas no ar.
Responsável por todas as iniciativas de TI que suportam quatro estâncias das montanhas do Colorado e amplo portfólio de hotéis, lojas de varejo e locação, o gerente aprendeu a ajudar sua equipe, de 20 funcionários de campo; Ele sabe priorizar as solicitações para manter o 3,4 mil funcionários da empresa felizes do ponto de vista técnico.
 Ultimamente, porém, o malabarismo ficou muito mais intenso, diz o executivo.
As tecnologias móveis e sociais, grupo comandado por Major,  têm bombardeado o gestor constantemente com pedidos de novos projetos. Um executivo lê sobre um app móvel legal em uma revista de bordo, ou durante uma conversa informal sobre tecnologia que a caixa de e-mail de Major lotar.
"Temos hoje uma enorme quantidade de demanda de TI para novas tecnologias que não seguem a trajetória normal de TI", diz Major. "Você não pode simplesmente ter mil pedidos aleatórios chegando, para tecnologias muito novas e não testadas. É preciso uma voz de sanidade sobre o que estas tecnologias vão fazer e qual é a estratégia de longo prazo."
Major é contra o que muitos departamentos de TI estão enfrentando. A alta na demanda nas organizações para as tecnologias móveis, sociais e de análise adiciona trabalho extra ao da TI tradicional. "O yin-yang do clima econômico não ajuda - os orçamentos de tecnologia são pequenos e as empresas parecem pouco propensas a aumentar a equipe . Além disso, trabalhadores qualificados nas novas tecnologias são escassos", afirma.
No auge da hegemonia de TI, gestores como Major teriam mais tempo para manter as prioridades sob controle. Os gerentes das áreas de negócios socilitariam o uso de novas tecnologias e, em seguida, entrariam na fila para conseguir o que eles precisavam da TI. Hoje, os usuários finais podem aproveitar o poder da nuvem para seguirem em frente se perceberem algum atraso da área de TI.
"Os modelos formais e mecanismos de priorização não funcionam mais", diz David Cearley, vice-presidente do instituto de pesquisas Gartner. "A priorização não pode ser feita de forma isolada do negócio. Precisa acontecer em estreita parceria com a empresa."
Nesse cenário, a TI está sentindo a pressão para ser mais ágil em seus métodos de entrega, mais flexível na priorização de projetos, e mais experiente na avaliação de retorno sobre o investimento (do inglês ROI) - tudo para que possa trabalhar com, e não contra, as necessidades de negócio.
Prós e contras para os negócios
consumo de TI, em particular, está impulsionando mudanças radicais não só no que a TI precisa priorizar, mas também na forma como ela interage com outras unidades de negócios para entregar esses projetos.
Não só é preciso descobrir como administrar, adquirir, apoiar e criar aplicativos móveis, como também repensar toda a experiência de computação do usuário final em torno dos dispositivos móveis, de acordo com Cearley.
Como os recursos não são infinitos, diz ele, a gestão de TI precisa reformular o seu papel para tornar-se mais que um corretor de serviços de TI, trabalhando em conjunto com o negócio para compreender as principais prioridades e funcionar como um facilitador, não como um gargalo para a implementação da nova tecnologia.
Por exemplo, em vez de derrubar um pedido de uma aplicação móvel por questões de segurança, a responsabilidade da área de TI é a de ajudar a empresa a entender os riscos fundamentais e destacar as tecnologias disponíveis para mitigar riscos.
"Ser pró-ativo significa ajudar a empresa a entender como as novas tecnologias como o celular podem impactar o negócio", explica ele. "A governança não pode ser o mecanismo de dizer não. Governança deve ser o mecanismo para ajudar a direcionar e apoiar os requisitos do negócio."
É uma directiva na Aspen Skiing que Major está levando a sério. Com uma avalanche de dispositivos pessoais aparecendo no trabalho e a demanda quase universal entre os empregados por aplicações móveis que possam suportar serviços ao cliente como a emissão de bilhetes e o aluguel de esqui, Major decidiu montar um comitê executivo para introduzir novas tecnologias e apresentar exemplos de estudo de caso, encorajando feedback e colaboração para começar a fazer a criatividade fluir.
Balanço da carteira de projetos
Além de envolver negócios diretamente no processo de priorização, Major está começando uma nova estratégia para frear o que ele diz ser um número insustentável de projetos no pipeline de TI.
Ele trabalha com um grupo estratégico de seis representantes divididos igualmente entre TI e finanças. A equipe realiza entrevistas com altos funcionários de toda a empresa para identificar os projetos solicitados ao seu departamento que fujam às atribuições tradicionais da área - nada tão complexo como um novo sistema de Business Intelligence (BI) ou tão simples como a compra de um novo mouse.
Os projetos são classificados para encontrar oportunidades de reuso e de acordos de licenciamento otimizados. "A ideia é ver a um nível elevado o que estamos fazendo, descobrir onde queremos estar em 18 meses, e depois classificar projetos por horas de trabalho, custos, riscos e prioridades", diz Major. "Se pudermos extrair da lista cinco ou dez projetos bem fundamentados, podemos apresentá-los à liderança executiva e obter financiamento que garanta a execução de cada um deles."
Aplicativos de uma nova maneira
Na Catalina Marketing, os novos aplicativos móveis e os projetos de BI são tão centrais para a empresa que todos estão ansiosos para trabalhar em sintonia com a TI para fazer lobby junto à alta administração para apoiar o desenvolvimento.
"Como resultado, a Catalina tem 250 pessoas no departamento de TI que receberam um cheque em branco para trazer os recursos necessários para começarem a fazer o trabalho que precisa ser feito", explica Eric Williams, ex-CIO da empresa, que presta serviços de marketing para clientes nas indústrias de varejo e da área de saúde.
"As equipes de vendas nas diferentes unidades de negócios deixam claro para o CEO onde precisamos estar", diz Williams, que se aposentou em dezembro passado.
O alto nível de envolvimento das partes interessadas também levou TI a repensar seu processo de desenvolvimento, passando a adotar uma abordagem mais ad hoc quando as equipes de TI passam a integrar o pessoal de marketing ou das áreas de negócios para o desenvolvimento mais rápido de um aplicativo móvel  - às vezes em questão de dias em vez de semanas ou mesmo meses.
"É uma integração muito mais coesa do desenvolvimento do produto que eu já vi no passado", diz Williams.
A Northern Kentucky University também ajustou seu processo de priorização para um sistema mais aberto, em que as solicitações são feitas a partir de comitês consultivos formados por professores, alunos e funcionários, de acordo com Timothy Ferguson, reitor adjunto de Tecnologia da Informação e CIO da universidade.
Quando chega a hora de realmente desenvolver novos projetos de mobilidade ou de mídia social, o executivo tem acesso um recurso exclusivo: os alunos da universidade do programa de tecnologia da informação que foram criados sobre essas novas plataformas. "Eles cresceram com essa tecnologia, estão conectados", explica Ferguson.
Atualmente, Ferguson conta com cinco ou seis estudantes desenvolvedores que trabalham 25 horas por semana em novos projetos. Até agora, tem sido uma situação ganha-ganha: os alunos estão ensinando aos seus colegas de TI muito sobre tecnologias emergentes. Já os funcionários tradicionais estão ajudando os alunos a compreenderem o que é preciso para escrever aplicativos back-end, bem como questões importantes em aplicativos empresariais, como a autenticação e a segurança.
Sem metodologias formais para a priorização e governança pró-ativa, os departamentos de TI correm o risco de serem marginalizados. É um grande risco que nenhum CIO está disposto a assumir.