Governança de TI

As organizações investem grandes quantias em dinheiro na TI. Eles contam com a TI para dar suporte às operações de negócios, melhorar o resultado e atingir os objetivos estratégicos. Contudo, geralmente o desempenho de TI está aquém do esperado. A Governança de TI ajuda na tomada de decisão; no alinhamento de metas de negócio com as metas de TI.

 O que é Governança de TI

Governança é responsabilidade da alta administração (incluindo diretores e excecutivos), ela faz parte da Governança Coorporativa e consiste em liderança (incluindo diretores e executivos), ela faz parte da Governança  Corporativa e consiste em liderança, estruturas organizacionais e processos que garantem que a TI da empresa sustente e estenda as estratégias e objetivos da organização.

Uma governança de TI eficaz deve tratar três questões:

1. Quais decisões devem ser tomadas para garantir a gestão e uso eficaz da TI ?
2. Quem deve tomar as decisões ?
3. Como estas decisões serão tomadas?

Para responder as estas questões é apresentada uma matriz de Arranjos de Governança (Matriz de Responsabilidade de Decisões), levando as seguintes informações em consideração:

• Princípios de TI: Esclarecimento do papel de negócios da TI
• Arquitetura de TI: Definindo os requisitos de integração e padronização
• Necessidades de Aplicações de negócio: Especificando a necessidade de aplicações de TI adquiridas ou desenvolvidas internamente
• Investimento e priorização de TI: Escolhendo quais iniciativas financiar e quanto gastar.

Estas cinco decisões-chave estão inter-relacionadas e requerem vinculação para que haja uma governança eficaz

Arquétipos de governança

• Monarquia de Negócios: altos gerentes;
• Monarquia de TI: Os especialistas em TI;
• Feudalismos: Cada unidade de negócio toma decisões independentes;
• Federalismo: Combinação entre centro corporativo e as unidades de negócios, com ou sem envolvimento pessoal  de TI;
• Duopólio de TI: O pessoal de TI e outras pessoas, como alto gerentes, lideres das unidade de negócios);
• Anarquia: Tomada de decisões individual ou por pequenos grupos de pessoas de modo isolado;

Matriz de Arranjos de Governança (Matriz de Responsabilidade de Decisões)

Leitura do quadro acima

• Quem decide sobre os princípios de TI é o CEO. Exemplo; Definir a missão da TI;
• Quem decide sobre a Arquitetura de TI e infra-estrutura é o CIO
• Quem decide sobre necessidade de aplicações de negócios são os Gestores das Unidades de Negócio e a TI (CIO);
• Quem decide sobre os investimentos em TI é o CFO.

O preço do Débito Técnico “Gambiarras” em Desenvolvimento de Sistemas

Um problema recorrente e crescente associado ao desenvolvimento de sistemas, são as chamadas “Gambiarras” .

Muitas vezes, para manter o custo do projeto  dentro dos valores orçados e/ou pressão para garantir os prazos de entrega, atividades importantes do processo de desenvolvimento de software são “encurtadas” e/ou descartadas.

Muitas vezes, este procedimento não é percebido, até que o produto entre efetivamente em produção.

Contudo, em produção, os problemas de segurança, confiabilidade nos resultados em transações que foram construídas utilizando esta abordagem aparecem.

E muitas vezes, para a efetiva solução do problema, a única solução é reconstruir a transação do zero.

Seque link que aborda com propriedade o assunto.

http://www.blogcmmi.com.br/engenharia/o-preco-das-gambiarras

 

 

 

 

 

Gerência de Manufatura

Premiar funcionários por metas relacionados com cronograma ou mesmo pela quantidade de código escrito. Funcionários que produzem mais tem melhores salários, mesmo se o código apresentasse muitos defeitos e precisasse ser constantemente consertado.

As consequências dessa organização, como custo de re-trabalho, em geral passam despercebidas: ao final do prazo de implementação de um projeto repleto de erros, os culpados apontados são, em geral, os desenvolvedores. Assim como os programadores  tendem a ignorar os próprios erros, gerentes terminam por fazer o mesmo.

Outro critério enganoso é aplicar mais recurso para resolver problemas de prazo. se duas máquinas transportam o dobro de peso, então dois programadores deveriam escrever o dobro de linhas! Esse assunto é explorado em Brooks em seu famoso livro, The mythical Man-Month. O raciocínio errôneo que leva ao problema pode ser ilustrado assim: “Um pedreiro constrói um muro em 4 dias, dois o farão em 2 dias; então cem pedreiros o construirão em 10 minutos”.

Um gerente que siga essa ideia está cometendo o erro de aplicar um modelo linear ao um problema que não o é. O volume de trabalho produzido não cresce na mesma proporção do número de pessoas e a diferença é ainda mais sensível em programação.

Ao incluir mais pessoas em um projeto, o volume de comunicação eleva-se: cada desenvolvedor precisa compartilhar com o restante da equipe de trabalho. A complexidade dessa interação cresce exponencialmente, e sem essa comunicação o trabalho não funciona. Além disso, os novos funcionários acarretam um custo adicional que é coloca-los a par do andamento do projeto, dos padrões e ferramentas adotadas..

Mito: Específicar antes reduz o desperdício

A razão para desenvolvermos todos esses códigos excedentes está no jogo que fazemos com os nossos clientes. Estabelecemos as regras:
Você valioso cliente, poderia nos dar, por favor, uma lista de tudo o que quer que o software faça? Escreveremos tudo e pediremos para você assinar o resultado. Depois disto, se você quiser mudanças ou funcionalidades adicionais, terá que passar pelo árduo processo chamado “gestão de mudança” para ter uma alteração aprovada.
Assim, é melhor pensar em tudo o que quer agoram pois temos que saber tudo isso no início para que possamos desenvolver um bom programa.

Não é de admirar que nossos clientes joguem tudo, incluindo a pia da cozinha em sua lista de requisitos? Muitas vezes, o jogo de controle de escopo tem o efeito oposto – ele cria um escopo inchado. Do mesmo modo que Taiichi Ohmo definiu a sobreprodução como o pior desperdício na produção, as funcionalidades não usadas são o pior tipo de desperdício no desenvolvimento de software. Cada pedaço de código que está lá e não necessário cria uma complexidade que contaminará o código base para o resto de sua vida. Código não usado ainda requer testes,, documentação e suporte desnecessários. Isso contribuirá para tornar  código frágil e difícil de entender e de ser mudado à medida que o tempo passa. O custo da complexiade no código domina todos os outros custos, e funcionalidades extras que acabam se tornando desncessárioas representam alguns dos maiores assassinos da produtividade de software.

Precisamos de um processo que nos permita desenvolver 20% do código que entregará 80% do valor, e somente depois continuar a desenvolver as próximas funcionalidades mais importantes. Nunca deveríamos estabelecer o escopo com uma lista de tudo o que o sistema poderá eventualmente precisar, sobretudo se esta lista vier de clientes que não sabem bem o que querem.

Desenvolvimento Lean de software – Princípio 1: Eliminar o desperdício

Taiichi Ohno chamou o Sistema toyota de Produção um sistema de gerenciamento para “a eliminação absoluta deo desperdício”. Quando perguntado como funcionava ele dizia: “Tudo o que estamos fazendo é olhar para a linha de tempo do momento que o cliente nos faz o pedido até o momento que recebemos o dinheiro. E estamos reduzindo a linha de tempo ao removermos os desperdícios de acréscimos sem valor”. Em suma, esta é a essência do que é a produção lean. No desenvolvimento lean de software, o objetivo é eliminar o desperdício é o mesmo,  as o início e o final da linha de tempo podem ser modificados. O relógio é iniciado quando recebe um pedido de resolver uma necessidade do clientes (o que quer que significa na sua organização) e para o relógio quando o software visando aquela necessidade é implantado. O desenvolvimento lean de software tem como foco a redução da linha do tempo ao remover os desperdícios de acréscimos sem valor.

Para eliminar o desperdício, primeiro você precisa reconhecê-lo. Uma vez que o desperdício é tudo o que não agrega valor, o primeiro passo para eliminá-lo é desenvolver um senso aguçado do que o valor realmente é. Não há melhor maneira de desenvolver um profundo conhecimento sobre o que os clientes realmente valorizarão do que quando eles começam a utilizar o software. No nosso ramo o valor tem o hábito de mudar porque, frequentimente, os clientes não sabem realmente o que querem. Além disso, quando eles veem o novo software em ação, sua idéia do que querem invariavelmente muda. Todavia, grandes organizações de desenvolvimento de software desenvolvem um profundo senso de valor do cliente e, continuamente, satisfazem seus clientes. Pense no Google; ele regular e repetidamente encanta clientes ao redor do mundo.

Uma vez que você tenha um bom entendimento do valor, o próximo passo é desenvolver a capacidade de realmente ver desperdício. Desperdício é qualquer coisa que interfere em entregar aos clientes aquilo que eles valorizam no tempo e no lugar em que isso gerará o maior valor. Qualquer coisa que façamos que não adicione valor ao cliente é despedício, e qualquer atraso que impeça o cliente de obter valor quando ele o deseha também é desperdício.

Na produção, o estoque é desperdício. Estoque deve ser manuseado, movido, guardado, monitorado e reabastecido. Isso não só custa tempo e esforço, mas também adiciona complexidade – um multiplicador de grande custo. Estoques se perdem, ficam obsoletos, escondem problemas de qualidade e estagnam dinheiro. Portanto, um dos objetivos da produção é ter o menor estoque possível.

O estoque em desenvolvimento de software equivale aos trabalhos parcialmente acabados. Um software parcialmente acabado tem todos os males de um estoque na produção: se perde, fica obsoleto, esconde problemas de qualidade e estagna dinheiro. Além disso, a maior parte do risco de desenvolvimento de software jaz em trabalhos parcialmente acabados.

Uma grande forma do desperdício no desenvolvimento de software é p churn (volatilidade, inquietação, necessidade de mundaça) sempre esta associado a grandes estoques de trabalho parcialmente acabado. Quando os requisitos são específicados muito antes da codificaçãom certamente eles mudarão. Quando os testes acontecem muito depois da codificação, o churn testar-e-corrigir é inevitável. Infelizmente, esses tipos de churn são apenas precursores de um churn ainda maior de atraso na integração (também conhecido com big-bang).

Entretanto, a maior fonte de desperdício no desenvolvimento de software são de longe as funcionalidades adicionais. Somente certa de 20% das funcionalidades e funções em um programa personalizado típico são usadas regularmente. Algo como dois terços delas raramente usadas. Não estamos falando de segurança necessária ou funcionalidades de segurança. Estamos falando de funcionalidades que realmente não eram necessárias em um primeiro momento. Existe um enorme custo para desenvolver funcionalidades adicionais em um sistema  de software. Eleas acrescem uma complexidade ao código base do programa que eleva seu custo a uma taxa alarmante, tornando seu custo de manutenção cada vez mais caro e reduzindo drasticamente seu tempo de vida útil.

Tudo mais falhou…

Certa vez, um gerente de TI de uma grande corporação da área financeira em uma conferência. Ele era engenheiro eletricista por formação e foi convidado para assumir a TI a fim de “corrigi-la”.

Ele disse: “Isso aconteceu há bem mais de três anos e, você tem que entender, eu fracassei. Tentei aquela coisa do CMM e também aquela outra coisa do PMI e, depois de dois anos, fiquei frustado e voltei ao meu antigo trabalho”.

“Mas depois de outro ano, eles me pediram para tentar novamente, só que desta vez eu fiz as coisas de um modo diferente. Dividi a organização pela metade: operações e desenvolvimento. Depois, dividi o grupo de desenvolvimento em seis equipes de produto. Cada equipe de produto tem que vender seus produtos para as áreas de negócio, sendo avaliados pelo lucro comparado ao custo de produção”.

“Só se passaram seis meses, mas até agora nos tornamos imensamente bem sucedidos. Não sei por que não pensei nisso antes”.

Colaboração entre TI e Negócios

No relatório da McKinsey Quarterly intitulado “When IT´s Customers are External”, Simon MacGibbon e seus coautores sugerem que as áreas que atendem o negócio num departamento de TI devem se comportar como uma empresa de software. Eles lembram que as empresas de software diferen dos departamentos internos de TI sob três aspectos:

1. Empresas de software fazem pesquisa para realmente compreender aquilo que o mercado quer, de tal forma que possam fornecer produtos que irão vender. Se este trabalho for mal feito, essas empresas não irão durar por muito tempo. De fato, empresas de software atualizam continuamente suas pesquisas, procurando sempre por melhores formas de servir o mercado. Uma vez que elas não podem demandar de seus clientes o envolvimento no projeto de sistemas, esses empresas elaboram todos os tipos de painéis consultivos e discussões de grupo para descobrirem em primeira mão o que os clientes relamente necessitam. Muitas vezes, os departamentos de TI pulam esta etapa de marketing supondo que alguém tenha feito a pesquisa de mercado e são surpreendidos quando os seus produtos não satisfazem as necessidades de negócio.
2. As empresas de software vendem para mercados altamente competitivos, motivo pelo qual elas precisam controlar seus custos. Elas projetam produtos que sejam simples o suficiente para serem desenvolvidos e mantidos de forma rentável, enquanto asseguram o conjunto de características que irá fornecer aos seus clientes uma forte razão para comprarem o seu software. Muitas vezes, os departamentos de TI assumem que uma lista de requisitos de negócio representa todas as características essenciais do sistema, mesmo se características muito caras estão envolvidas. Eles têm pouco incentivo para realizar o mesmo comparação de custo/benefício que as empresas de software devem realizar para permanecerem no negócio.
3. As empresas de software percebem que se os clientes não estão satisfeitos com os seus produtos, a empresa não terá um negócio sustentável. Por isso, elas examinam todas as oportunidades a fim de ajudar os clientes a terem sucesso e criar uma ampla base de receitas, enquanto garantem que seus produtos sejam bem-sucedidos nos mercado a longo prazo. Muito frequentemente, os departamentos de TI acreditam que o sucesso dos sistemas que eles entregam é de responsabilidade da unidade de negócios. Embora seja verdade que as unidades de negócio devem ser responsáveis pelo suscesso dos esforços de desenvolvimento de software autorizado pelo seu negócio, também é verdade que o departamento de TI só será bem sucedido se seus produtos contribuírem para o sucesso do negócio.

Muitos departamentos de TI utilizam o modelo de projeto para o desenvolvimento de software, mas o modelo de porjeto vem da indústria contratante, onde a confiança não é parte integrante do contrato. A fim de criar uma colaboração saudável entre TI-Negócios, é interessante que seja adotado o modelo de produto, pois os incentivos incorporados a esse modelo propriciam muito mais a criação de uma relação de colaborativa. Quando a TI está dentro de uma empres, realmente não há razão alguma para se adotar o modelo Nós-Eles de fazer negócios que um projeto se propõe a adotar. Em particular, não é preciso fixar p escopo de início, não é preciso de assinaturas dos clientes, não é preciso monitorar um escopo detalhado por um cronograma e não é preciso fazer tudo o que seus clientes dizem ser importante. Ao invés disso, o que você precisa é trabalhar em colaboração com seus parceiros de negócios, entregando o maior valor de negócio possível, no menor tempo e custo possíveis, ajudando-os a empregar o sistema de forma efetiva e entregando mais e melhores funcionalidades ao longo do tempo.

Responsabilidade

Tradicionalmente os departamentos de TI das grandes empresas demonstram ser organizações separadas daquele negócio que elas suportam. Isso é comum, pois a empresa deseja uma infraestrutura de informação padronizada e é mais fácil desenvolver o conhecimento técnico quando os especialistas estão na mesma organização. No entanto, este fato tem levado à falta de clareza sobre quem é o responsável pelos resultados das atividades de desenvolvimento de software e, muitas vezes, uma falta de clareza sobre a fomra de medir seus resultados.

O problema da responsabilidade não é específico das organizações de TI. ele ocorre toda vez que as pessoas do mesmo time trabalham para diferentes organizações com diferentes formas de medir o desempenho. Por exemplo, uma organização que desenvolva software embarcado pode ser gerenciada separadamente do departamento de hardware. Uma empresa de consultoria que trabalha para um negócio claramente possui uma estrutura de gestão separada de seu cliente.

Particularmente, não é eficaz subdividir o esforço pelas linhas organizacionais e, em seguida, ver uma parte da equipe de desenvolvimento dando “requisitos” para outra parte da equipe. Esta abordagem tem uma tendência a obscurecer o objetivo global do empreendimento conjunto, e possui uma longa história de gerar resultados desfavoráveis. É muito mais eficaz para os membros de uma equipe multifuncional compartilharem a responsabilidade do comprimento dos resultados de negócio que justificam o pagamento do seu trabalho.

Porém no final, deve existir um único ponto de responsabilidade sobre os resultados de negócio para um investimento de TI. A responsabilidade deve recair sobre a área de negócio patrocinadora do projeto. Quando líderes de negócio gerenciam os investimentos de TI com o memo afinco que realizam seus próprios negócios, esses investimentos tenem a produzirem resultados mais significativos para o negócio.

 

 

 

De projetos para produtos

Frequentemente, um software personalizado é desenvolvido como um projeto, contudo o desenvolvimento de “produto” fornece um modelo mais útil. Uma das coisas interessantes sobre projetos é que ele tendem a ser financiados de uma única vez, no início do projeto.

Uma vez alocados os fundos, a questão que naturalmente surje é “O que é que vamos obter com este investimento e quando é que isso vai ficar pronto?”. As respostas a essas perguntas são consideradas como um compromisso – afinal de contas, o dinheiro já esta alocado -; com isso o sucesso do projeto é medido com base em ter seus custos, cronograma, escopo e compromissos cumpridos.

Os produtos, por outro lado, são tipicamente financiados de forma incremental esse financiamento incremental é um sinal claro para todos de que se espera a evolução do escopo à medida que o conhecimento é adquirido. O sucesso do desenvolvimento de um produto geralmente é medido com base na fatia de mercado e lucratividade que o produto acabará atingindo.

Existem outras diferenças entre projetos e produtos, Projetos apresentam um início e (aparentemente) um fim. Produtos, por outro lado, possuem um ínicio e (felizmente) nenhum fim. O software está mais pra um produto do que para um projeto, pois a maioria dos bons produtos vive e muda durante muito tempo. Bem mais de metade de um produto de software como um todo é desenvolvida após a primeira versão para produção.

Desenvolvimento Personalizado

Só porque o software está sendo desenvolvido para um único tipo de aplicãção, isso não exime uma organização da obrigação de criar valor e encantar seus clientes. O objetivo ainda é criar um software que irá proporcionar um excelente valor para a organização que está pagando por ele. De fato, a necessidade de liderança e times completos é talvez mais importante para as ofertas de produtos, pois a ausência de pressão competitiva pode enfraquecer o foco intenso no cliente, que é competência do sucesso das empresas de software.

Teoria das Filas

A teoria das filas é o estudo de linhas ou filas de espera. Nós, certamente, temos filas no desenvolvimento de software – temos listas de requisições de clienres e listas de defeitos que pretendemos corrigir. A teoria das filas tem muito a oferecer para ajudar a gerenciar essas filas.

Lei de Little

A Lei de Little diz que, em um sistema estável, a quantidade média de tempo que algo leva para atravessar um processo é igual ao número de coisas no processo dividido por sua taxa de conclusão média (figura 5.2).

Tempo do ciclo = Coisas no processo / Taxa média de Conclusão

Uma forma de reduzir o tempo de ciclo é fazer as coisas mais depresa – aumentar a taxa de conclusão média. Isso geralmente significa gastar mais dinheiro. Se nao temos dinheiro para gastar, a outra maneira para reduzir o tempo do ciclo é reduzir o número de coisas no processo. Isso exige muito vigor intelectual, mas geralmente não requer muito dinheiro.

Variação e utilização

A Lei de Little se aplica a sistemas estáveis, mas há um punhado de coisas que tornam o sistemas instáveis. Primeiro, há variação – coisas acontecem. A variação é frequentimente tratada pela redução do tamanho de lotes se movendo ao logo do sistema. Por exemplo, muitas lojas têm filas de pagamento para “10 itens ou menos” para reduzir a variação no tempo de saída para aquela fila. Digamos que você tenha um código de integrar em um sistema. Se é trabalho valoroso de seis semanas, pode ter certeza de que haverá um monte de problemas. Porém se é apenas um trabalho de 60 minutos, a quantidade de coisas que podem dar erradas é limitada. Se você tem projetos grandes, a variação do planejamento será enorme. Projetos pequenos apresentarão menos variação de planejamento.

Alta utilização é outra coisa que torna os sistemas instáveis. Isso é óbvio para qualquer um que tenha ficado preso em um engarrafamento. Quando a utilização de uma estrada chega a mais de 80%, a velocidade do tráfego começa a diminuir. Adicione alguns poucos carros e muito em breve você está se arrastando. Quando gerentes de operação veem seus servidores rodando a 80% da capacidade em momento de pico, eles sabem que o tempo de resposta esta começando a sofrer e eles rapidamente arrumam mais servidores.

Como a Google foir organizado por um bando de cientistas estudando mineração de dados, não é surpresa que sua estrutura de servidores reflita um profundo entendimento de teoria de filas. Primeiro de tudo, eles armazenam dados em lotes pequenos. Em vez de grandes servidores com quantidades massivas de dados em cada um, a Google tem milhares e milhares de pequenos servidores baratos espalhados pelo mundo, conectados por meio de uma rede muito sofisticada. Os servidores não esperam ser 100% confiáveis; em vez disso, falhas são esperadas e detectadas imediatamente. Não é um grande problema quando servidores falham, pois os dados foram divididos em pequenos pedaços e armazenados em vários lugares. Assim, quando servidores falham e são automaticamente removidos da rede, os dados foram divididos em pequenos pedaços e armazenados em vários lugares. Assim, quando servidores falham e são automáticamente removidos da rede, os dados que eles mantinham são encontrados em algum outro lugar e replicados novamente em outro servidor. Os usários nunca sabem que algo aconteceu, eles ainda têm respostas quase instantâneas.

Se você já se perguntou po que a Google escolhe dedicar 20% do tempo de seus cientistas e engenheiros para trabalhar em seus próprios projetos, dê uma olhada no gráfico no final do artigo. Essa figura mostra que o tempo de ciclo começa a aumentar apenas acima de 80% de utilização e que esse efeito é amplificado por grandes lotes (alta variação). Imagine um grupo de cientistas que estudaram a teoria das filas a vida toda. Suponha que eles se encontrem dirigindo uma empresa que deve colocar como mais alta prioridade trazer novos produtos para o mercado. Para eles, criar 20% de folga na organização de desenvolvimento “software” seria a decisão mais lógica do mundo. É curioso que os observadores aplaudam a Google por servidores redundantes, mas não entendam o conceito de folga na organização de desenvolvimento.

A maioria dos gerentes de operação seria demitida por tentar obter a utilização máxima de cada servidor, pois é conhecimento comum que a alta utilização retarda servidores até se arrastarem. Por que, então quando gerentes de desenvolvimento veem um relatório dizendo que 90% de suas horas disponíveis foram usadas no último mês, sua reação é, “Veja ! Temos tempo para outro projeto!”? Claramente, esses gerentes não estão aplicando a teoria das filas no iminente engarrafamento em seus departamentos.

Você não pode escapar das leis da matemática, nem mesmo em organização de desenvolvimento. Se você tem como foco aumentar a utilização, as coisas vão ficar mais lentas. Se você acha que grandes lotes de trabalho são o caminho para a alta utilização, vai retardar as coias ainda mais e reduzir a utilização no processo. Se, contudo, você atribuir trabalho em pequenas cargas e se concetrar no fluxo, pode relamente atingir uma utilização muito boa –  mas utilização numa deveria ser seu objetivo primordial.