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.