Débito Técnico

Motivado pelo post do Guilherme Chapiewski (cara, como é difícil decorar este sobrenome) decidí escrever sobre mais uma adoção de Agile, especificamente de Scrum.

Imagine uma empresa que desenvolve software. Imagine ela com uma equipe de mais de 200 desenvolvedores. Nessa empresa TODOS os funcionários são CLT, com benefícios e com horário de trabalho das 8:30 às 17:30. Imagine agora que além disso a tecnologia utilizada é de ponta. Não bastando, as equipes têm liberdade, a administração é colaborativa e realmente as pessoas são valorizadas. Os projetos estão sendo guiados pelos valores ágeis, utilizando Scrum e com a participação do cliente. Além disso, o escritório é bonito, confortável, cheio de Kanbans nas paredes e máquinas Italian Coffee sempre a disposição.

Não, eu não estou falando dessa vez de Google, Microsoft, ThoughtWorks e outras. Eu estou falando do Venturus aqui mesmo no Brasil. O Venturus é um Centro de Inovação Tecnológica que desenvolve software para os setores de Telecomunicação fixa e móvel, atendendo principalmente a Sony Ericsson. Nesse mês de maio tive o prazer de treinar 120 pessoas do Venturus com o nosso Workshop Scrum e confesso que foi uma das melhores empresas que ministrei até hoje.

Desenvolver aplicações web e desktop pode ser complicado, porém, desenvolver novas aplicações e protótipos para celulares pode ser mais emocionante ainda. O crescimento forte deste setor está gerando uma grande corrida por mais e mais aplicações que rodam numa infinidade de aparelhos e conversam com um mundo de acessórios variados. Este tipo de ambiente requer uma maior maturidade pois um bug em produção nesse tipo de desenvolvimento é caríssimo.

O Venturus é uma empresa que adotou Agilidade partindo dos clientes e dos próprios colaboradores numa iniciativa conjunta e com grande suporte do corpo executivo. É mais um case de adoção “Enterprise Scrum”. A iniciativa do desenvolvimento infectou até as rotinas administrativas (que também pude auxiliá-los). Atualmente eles estão trabalhando num ciclo de 2 semanas em equipes de tamanho variado. O Scrum está em adoção desde Novembro de 2007. Como ferramenta eles adotaram o ScrumWorks.

A história do Venturus não podia ser diferente do que o Guilherme falou no post dele. Antes da Agilidade o que existia eram Gantt Charts nunca cumpridos, maiores “controles” operacionais e um processo cascata tentando ser previsível. O simples fato de tornar o processo iterativo-incremental já mostrou resultados positivos nos primeiros Sprints. Com as outras práticas do Scrum de inspeção e adaptação boas rotinas de trabalho estão emergindo das equipes e o processo segue em melhoria contínua.

Minha visão sobre um treinamento Scrum…

O treinamento Scrum da Aspercom é um Workshop de 8 horas. Nós montamos um treinamento mais curto, mais prático, mais direcionado e principalmente mais barato exatamente para acontecer o que aconteceu no Venturus. Um treinamento para TODA a equipe. Dificilmente as empresas possuem verba para pagar um treinamento caro para 120 pessoas. Nossa visão sobre um treinamento Scrum eficiente é que toda a equipe deve ser treinada e não somente o ScrumMaster. Quem está querendo adotar o Scrum sabe que cada papel do Scrum tem responsabilidade com relação ao gerenciamento do Projeto. No Scrum, não existe gerente de projeto. ScrumMaster não é Gerente de Projeto.

Um padrão que considero maléfico para a adoção do Scrum é uma empresa pegar seus Gerentes de Projeto tradicionais e treiná-los como ScrumMasters para que a implantação do Scrum ocorra. É difícil um GP tradicional se tornar um ScrumMaster logo de cara. Os valores são completamente diferentes! Tudo isso que falo aqui seria assunto para um outro artigo no blog (PMPs, esperem esse novo artigo antes de atirar as pedras).

De qualquer forma, nós da Aspercom estamos vendo que essa estratégia de treinar TODA a equipe no Scrum está dando certo para todos os nossos clientes corporativos. O convencimento deve ser geral. É comum quando estou ministrando que a equipe técnica tenha dúvidas das práticas de engenharia (que geralmente são do XP e não do Scrum). Os Product Owners querem ser desgraçados gananciosos. Essas respostas devem ser dadas e não vejo que um GP tradicional treinado para ser ScrumMaster possa dá-las de imediato. É comum que uma dúvida técnica básica da equipe possa comprometer a adoção do Scrum.

O pessoal do Venturus tiveram um treinamento diferenciado. Eu não precisei convencer eles a usar o Scrum, pois eles já estavam vivenciando as práticas. O treinamento foi mais focado em Concepção Ágil, utilização de Stories, Design Emergente e principalmente Estimativas e Métricas Ágeis. Ao final, 70% dos alunos avaliaram o treinamento como Excelente e 29% avaliaram como Bom. A Equipe Aspercom agradece!

Certo dia, em certa empresa, fui convidado para participar de um treinamento sobre SCM (Gerência de Configuração). SCM é uma das áreas de avaliação para obter a certificação CMM que a empresa estava buscando. Realmente achei que o treinamento era válido pois a empresa não tinha uma cultura muito forte em Gestão de Configuração, porém, o treinamento foi um desastre. A consultoria que “estava nos ajudando” a obter o selo não explicou o que é SCM no treinamento. Basicamente eles ensinaram quais documentos a gente precisaria preencher e quando tirar as baselines para conseguir passar no assessment. A empresa obteve o selo CMM 2 a um custo próximo de MEIO MILHÃO de reais, mas não tem internamente boas práticas de desenvolvimento.

Olhando o CMM/i não tenho muitas críticas ao modelo em sí, mas sim critico o que essa “certificação” se tornou, a motivação das empresas para obtê-la e essas consultorias “tarja-preta” que te “ajudam” a obter o selo. Isso seria assunto para um outro artigo (não postem comentários defendendo CMMi, deixe isso para o outro artigo, ok?).

O ponto que quero comentar aqui é que ter projetos ou equipes externas para obter melhoria de processos é um grande engodo. Nunca ví isso funcionar e coleciono casos onde esse tipo de prática provou ser ineficaz. Sabe aquelas pessoas “responsáveis por definir os processos”? É delas que estou falando.

Não vou mentir pra vocês. Eu já participei desses “projetos” internos e confesso que essas iniciativas de melhoria de processo falharam miseravelmente. Quando digo que falharam estou pensando no lado financeiro da coisa não importando a melhoria obtida. Pare para pensar: Numa conta rápida esses “responsáveis por definir processos” são profissionais caro$ e custam mais de R$ 15 mil por mês. Se você tiver 2 ou 3 deles o custo pode ultrapassar R$ 45 mil reais por mês. Será que as ineficiências do processo são mais caras que 500 mil reais no ano? Qual é o ROI disso?

Eu ministro treinamento de UML. O que eu ensino (e já escreví sobre isso) é que UML não é documentação e nem especificação firme. É comum empresários e alunos associarem UML com melhoria de processo não sei porque. Por conta disso, tenho muito contato com esses “responsáveis pelos processos”. Eu uso o treinamento para mudar a cabeça de muitos com relação a processos de desenvolvimento. Um depoimento de uma aluna no ano passado resume o que ocorre em geral:

“- Os caras que cuidam dos processos lá na minha empresa são muito fechados. Eles não aceitam a opinião das equipes. A visão que eles têm do processo é que qualquer pessoa poderia pegar qualquer papel, mesmo sem conhecimento, e as coisas funcionariam mecanicamente. Segundo eles, AS PESSOAS NEM PRECISARIAM CONVERSAR, as tarefas chegariam pela ferramenta de gestão, o artefato é preenchido e encaminhado para o próximo responsável…”

Essa aluna em especial ficou surpresa quando expliquei a natureza empírica de um processo de desenvolvimento de software. O processo nunca é ÚNICO para a empresa toda. Cada projeto pode necessitar de um processo diferenciado. O processo pode inclusive mudar de iteração para iteração.

Nenhuma literatura prega essa “intervenção externa” para melhoria de processos de desenvolvimento de software dentro das equipes. Isso pode funcionar para um cartório, uma linha de montagem, um supermercado e etc… Porém, o Manifesto Ágil é claro ao dizer que pessoas são mais importantes que processos. O que nos traz à solução da equação: Na minha experiência, todas as vezes que um empresário/gerente me procurou falando que o problema era falta de processos eu ví que o problema dele era falta de capacitação e não de processos. Ví que corpo técnico não sabia levantar requisitos, eleger uma arquitetura, gerenciar o projeto e ter uma cultura de teste. Se as pessoas não sabem ou fingem que sabem fazer as tarefas dificilmente o desenvolvimento do software terá qualidade e produtividade. Não adianta por arreio em cavalo chucro. Ao invés de pagar centenas de milhares de reais para melhorar o processo de “fora-para-dentro”, gastar 50 mil em bons treinamentos traz mais resultados palpáveis no curto prazo.

Bons processos surgem de boas práticas de desenvolvimento de software. Bons processos surgem de boas pessoas em constante colaboração. O processo é uma coisa que emerge da equipe e não algo que é imposto externamente. Geralmente o que esses empresários precisam é de treinamento e não de consultoria de processos. As pessoas precisam conhecer desenvolvimento de software. O primeiro valor ágil é muito sobre isso e empresas que estão tendo suce$$o (leia-se dinheiro) já aprenderam que investir em pessoas é mais vantajoso que investir em “projetos de melhoria” de processos. Exemplos:

Google
http://blog.aspercom.com.br/2008/04/10/culturaempresarialemalta/

Thoughtworks
http://www.thoughtworks.com/who-we-are/TW-history-MA.html

Ainda sobre a ThoughtWorks, o Phillip Calçado “Shoes” nos falou um pouco sobre os processos de um projeto no blog dele (aproveite os links do post e também veja a opinião do Dr. Ivar Jacobson sobre o assunto). Essa lista envolve muitas outras empresas, inclusive aqui no Brasil. Esses exemplos são mais caracterizados pois são empresas grandes com projetos grandes e lucratividade compatível (grande). Essas empresas não têm esses “departamentos” de melhoria de processos, mas sim, bons departamentos de RH e de empowerment.

É engraçado como está tendo um movimento muito grande da indústria nesse sentido. A própria nova linha de produtos da IBM Rational (veja http://jazz.net) declaradamente diz “People not Organizations build great Software”. Creio que essa segunda geração de produtos alinhe de vez a IBM com Agilidade e enterre o RUP Waterfall praticado no mercado. Por mais que alguns de nossos “gestores tupiniquins” queiram fechar os olhos, desenvolvimento de software é puramente dependente de pessoas e não de processos. A alta rotatividade que temos hoje é um problema gerencial e não um problema do desenvolvimento de software em sí. É uma ilusão enorme achar que melhorar o processo irá diminuir a dependência das pessoas.

Se você é “a pessoa responsável pelos processos” não desanime! Existe uma alternativa! O foco da melhoria dos processos deve ser treinamento e menthoring. Acredite, os resultados serão muito melhores. Ajuste o foco para as práticas e para a colaboração das pessoas. Deixe de lado as reuniões inúteis, a definição de papéis e os templates do modelo de artefatos. Todas as metodologias são fundamentadas em valores e não em modelos de artefatos.

Há algum tempo atrás eu e o Alexandre Magno discutimos sobre o papel do Product Owner dentro do Scrum. Essa discussão rolou na lista Scrum-Brasil, segue o link:

http://br.groups.yahoo.com/group/scrum-brasil/message/470

Se você não estiver a fim de ver este link, veja os pontos de vista abaixo:

Você (Magno) já havia defendido aqui que você não enxerga o PO como diretamente o cliente. Eu já acho ótimo quando o PO é alguém do lado sponsor. Eu vejo que é melhor que o custo do PO não seja custo direto do desenvolvimento. Eu vejo que o PO é mais próximo do cliente presente do XP. Na minha experiência, não achei bom as vezes que o PO era diretamente “da própria organização” do time. Um bom PO é formado a partir da experiência de pagar a conta. Rodrigo Yoshima

Eu realmente gosto do PO junto ao time…conhecendo muito do cliente (e negócio) sim, mas bem envolvido com Scrum e com o projeto. Algo similar ao papel de “Gerente de Produto” que existe hoje na maioria das empresas que produzem algo através de projetos. Alexandre Magno

Antes de mais nada nossas visões não são diametralmente opostas. O ponto é que “daonde sai o dinheiro” e quem está no controle disso pode fazer uma grande diferença para o projeto.

O Product Owner é um papel difícil de encontrar. Todos os projetos que participei salvo duas excessões tive problemas com os Product Owners. Alguns eram moscas mortas. Outros se sentiam como Gerentes de Projeto. Outros se metiam nas coisas técnicas. Além desses problemas, esses Product Owners não tinham um compromisso com sua maior responsabilidade: O ROI do projeto (return on investment ou retorno sobre o investimento). Esses Product Owners problemáticos eram da mesma organização da equipe técnica (Team Role), isto é, eles eram “colegas de trabalho”. Eu realmente acredito que a falta de compromisso com o ROI era por conta dessa proximidade com a equipe.

É muito impressionante ver a falta de compromisso que os projetos em geral tem com o ROI. Ora, ninguém investe dinheiro para perder dinheiro. É estranho ver que o empresariado não enxergou que fábricas de software e consultorias montam contratos que estão se lixando para o ROI e para o sucesso do cliente. Quando um empresário faz um investimento qualquer, como um dono de uma gráfica que compra uma impressora off-set ou um fazendeiro que compra uma ceifadeira, ele sabe que aquele investimento terá um retorno. Isso significa mais páginas impressas ou mais sacas colhidas. Infelizmente muitos empresários estão bem insatisfeitos com o retorno oferecido por soluções de software. Isso se deve a maneira que o software é contratado. Fábricas de Software e Consultorias em Geral não dão a mínima importância se o projeto vai ou não colocar dinheiro no bolso do cliente. O escopo de um projeto para esses fornecedores é implementar requisitos e não dar soluções para problemas de negócio. Geralmente um requisito levantado e implementado não necessariamente resolve um problema de negócio. Requisitos são abstrações. Essa é a maior razão de trabalharmos de maneira iterativa seguindo princípios ágeis. Quem desenvolve um projeto de maneira iterativa quer solucionar os reais problemas de negócio do cliente e não simplesmente implementar requisitos. O mercado em geral adota um processo cascata e não iterativo. Eles caem no conto que requisitos traduzem as necessidades de negócio.

Quando se fala em ROI sempre pensamos em risco e ganho. A melhor literatura nesse aspecto são Os Axiomas de Zurique. Considero “Os Axiomas” uma literatura imprescindível para os brasileiros. Apesar de toda a nossa criatividade não somos treinados em nossas famílias e nossas escolas a correr riscos para ganhar mais.

O Scrum é uma metodologia guiada pelo ROI. Todos os projetos têm risco. Mas se você se focar em ter ganhos rápidos esses riscos podem ser minimizados pois você obtém retorno. Se você pegar o “Agile Project Management with Scrum” você encontrará:

O Product Owner obtém o financiamento no início e durante o projeto, criando os principais requisitos iniciais, os objetivos de retorno sobre investimento (ROI) e o planejamento dos releases. Ken Schwaber

Essas colocação do Ken Schwaber nos dá boas dicas que financiamento e ROI são as tônicas do dia-a-dia do Product Owner. Minha pergunta é: Num projeto outsourcing ou fábrica será que um Product Owner do lado do fornecedor terá um sentimento de financiamento e ROI à flor da pele? Creio que não! Só o cliente tem (ou deveria ter) uma completa visão de investimento, risco e benefício. Outro questionamento: Será que o cliente permitirá que um Product Owner do lado fornecedor represente diante do projeto TODOS os outros stakeholders?

Pegando novamente a literatura do Ken Schwaber, a maioria das vezes que ele fala a respeito do Product Owner ele diz “maximize de value of the project”. Quando ele diz isso não creio que ele esteja falando de um software bonito, nem um software funcional, nem um software implementado na melhor tecnologia. Esse “value” é bufunfa, cascaio, grana, money. Lembre-se: ninguém em sã consciência investe para perder dinheiro. O Software tem que dar lucro.

Desculpe se isso pode ofender alguém, mas lembre-se que estamos inseridos em um contexto capitalista moderno: O Product Owner deve ser um desgraçado ganancioso. Se você não concorda e acha o lucro ruim mude-se para Cuba ou Coréia do Norte enquanto esses regimes ainda existem.

Waren Buffet, Bill Gates e George Soros seriam bons Product Owners. Veja outros aqui.

Infelizmente os exemplos de Product Owner que o Ken Schwaber lista em sua obra não são exemplos de outsourcing. São softwares feitos “em casa”. Porém, o Geoff da MegaFund, um gerente de produto, “queria que o XFlow se tornasse COMERCIALMENTE viável externamente” (página 59). Não creio que ele quisesse dar este software de graça. O Michel, da TechCore, usou o Scrum para “ver que o verdadeiro DINHEIRO seria ganho focando a atenção no desenvolvimento do produto” (páginas 60 e 61). Michel negou a oferta de mais de MEIO BILHÃO de dólares pela sua companhia porque achou que poderia ganhar mais (e ao fim, ganhou 1.43 bilhões com o software). Esses caras não me parecem ter sentimentos comunistas. Esses caras são direcionados pelo ROI.

Pode parecer que não, porém, ter um Product Owner que de fato está financiando o projeto e que só pensa em ROI é muito saudável para o projeto. Ele aceita a iteratividade porque quer ter retorno rápido. Ele quer agilidade pois tem um mercado a atender (e dinheiro a ganhar). Ele quer participar ativamente pois é o dinheiro dele que está sendo investido alí. Quando você foca no ROI besteiras e desperdícios caem por terra. Se este Product Owner representar um grupo de stakeholders, as briginhas comuns que ocorrem entre eles são facilmente resolvidas colocando o dinheiro em primeiro lugar: será que aquele relatório que o estoquista pediu é de fato importante?

O Product Owner não pode ter mais apego à equipe técnica (Team) do que ele tem pelo dinheiro (creio que esta é a maior razão para que o Product Owner não seja da mesma empresa que a equipe).

OK!!! Talvez chamá-lo de “desgraçado ganancioso” seja forte demais. Usei este termo com objetivos didáticos para que você não esqueça as motivações deste importante papel do Scrum. São elas que fazem o Scrum funcionar. Agora, o fato dele ter foco em ROI não pode atrapalhar o trabalho da equipe. Ele não deve pressionar a equipe e as regras do Scrum SEMPRE devem ser seguidas. O Product Owner não pode se meter no dia-a-dia técnico. A equipe dá o prazo e deve ter tranquilidade para trabalhar. Garantir que o processo funcione é papel do ScrumMaster.

Outro ponto é que nem sempre é possível ter um Product Owner no lado do cliente. Não são regras que estou definindo aqui. É possível ter bons Product Owners na visão do Alexandre Magno. Ele até pode cumprir seu papel com relação ao ROI, mas dificilmente será um desgraçado ganancioso de fato. Entre esses dois tipos, eu fico com o De$graçado.

Atualmente surgiram algumas discussões em fóruns sobre a entrada de itens técnicos no Product Backlog do Scrum. A apostila do nosso curso Scrum pode dar uma idéia sobre o que é um Product Backlog:

“Os itens que aparecem no Product Backlog são qualquer tipo de funcionalidade ou tarefa que possua um valor para o Product Owner ou ao grupo de Stakeholders que este Product Owner representa. Esses itens seguem um conceito do SCRUM chamado incremento de funcionalidade potencialmente implantável. Uma funcionalidade potencialmente implantável significa que quando esse item do Product Backlog for finalizado ele estará completamente funcional e resolvendo algum problema de negócio dos Stakeholders.”
Rodrigo Yoshima, Gerenciamento de Projetos com Scrum

As discussões estão listadas abaixo:

http://br.groups.yahoo.com/group/agile-brasil/message/1738
http://br.groups.yahoo.com/group/scrum-brasil/message/751

Eu particularmente sou contra enfiar coisas que não agregam valor para o PO no Product Backlog. Bem, pra falar a verdade, defendo uma outra visão. Pode ser que existam itens criados por recomendação da equipe, mas tudo lá agrega valor de negócio para o PO. Lembre-se: O Product Backlog é um importante registro de métricas como prazos, produtividade, pesos funcionais e etc… É preferível que essas métricas importantes para o negócio não sejam poluídas com problemas técnicos da equipe (apesar desses problemas interferir nas métricas, são ortogonais à visão que defendo aqui). Gerar um script do Ant não é algo que constaria nos meus product backlogs.

Débito Técnico é um problema da equipe técnica. Se existem Débitos Técnicos é culpa (responsabilidade) da equipe técnica. Agora, nenhuma aplicação que desenvolví ou qualquer outra que tive contato É 100% LIVRE DE DÉBITO TÉCNICO. Já olhei código de algumas dezenas de projetos Open Source. Todos tinham algum débito, porém, isso é natural. Como vocês todos sabem, débito técnico é comparado com inflação. Tem que ser gerenciado. Nenhum economista consegue gerenciar algo como os 100.000% de inflação do Zimbabue.

É capaz que existam itens do tipo:

- Efetuar um teste de usabilidade com os usuários finais
- Efetuar um teste de carga com 480 usuários simultâneos

Já passei por essas duas situações. Mas esses itens foram para afastar riscos do negócio e não “Débito Técnico”. Esses itens constaram no Backlog sugeridos pela Equipe pois eram “técnicos”, mas negociamos com o PO. Esses itens constaram no Backlog pois tomaram muito tempo. Como exemplo, o teste de carga tomou quase 1 Sprint para ser efetuado.

Débito Técnico, Débito Funcional, Débito do Projeto

Atualmente defendo uma tese que nossa preocupação são as 3 qualidades do software. A qualidade interna, qualidade externa e qualidade do projeto (ver artigo “Modelagem Ágil”, MundoJava #27). Só para revisar, listo as 3 qualidades do software:

1. A solução atende ao negócio (qualidade externa).
2. O software é fácil de manter e evoluir (qualidade interna).
3. Menor custo e prazo possível (qualidade do projeto).

Um ponto que não mencionei no artigo é que com essa visão das qualidades nós temos 3 “listas de débitos” para gerenciar: débitos técnicos, débitos funcionais e débitos do projeto. Exemplos:

1. Débitos Técnicos:
- Melhorar o Build
- Melhorar a Documentação Técnica
- Melhorar a cobertura de testes
- Fazer passar PMD, Checkstyle
- Código Macarrônico
- Baixa coesão, alto acoplamento
- POG

2. Débitos Funcionais:
- Bugs
- Algumas funcionalidades pequenas não implementadas
- Funcionalidades não implementadas por conta de bugs em bibliotecas de terceiros
- Melhorar usabilidade
- Melhorar a “beleza” da aplicação

3. Débitos do Projeto:
- Uma linha de burndown acima do planejado (cheiro de atraso)
- Custo acima do esperado
- Falta de comprometimento dos Stakeholders
- Falta de financiamento
- Baixo ROI
- Falta de comprometimento da Equipe

Bem, logicamente essa minha tese ainda carece de melhores fundamentos teóricos. De qualquer forma não é algo novo. Simplesmente juntei vários aspectos que já constam em outras literaturas. Essa visão fez e faz sentido nos projetos que participei. Seu processo de desenvolvimento deve focar nas 3 qualidades e os 3 débitos devem ser gerenciados.

Documentando os Débitos

Débitos Técnicos podem ser facilmente gerenciados dentro do próprio código e com suporte das IDEs atuais. A maioria deles constam como //TODO:. Nas IDEs atuais como o Eclipse temos uma boa visão dos To Dos através da View “Tasks”.

Relacionados com Débitos Técnicos temos restrições arquiteturais. Restrições arquiteturais não são débitos técnicos, mas podem se tornar um, principalmente em projetos ágeis e iterativos. Restrições arquiteturais importantes podem constar num documento de arquitetura.

Para documentar débitos funcionais podemos usar o proprio Product Backlog, porém, a granularidade desse tipo de item (débito funcional) costuma ser bem pequena (como os exemplos que citei). Eu relaciono débito funcional como uma funcionalidade pequena que não impede que os usuários dêem a história como pronta, mas não deixa de ser desejável. Vendo dessa maneira, talvez essas pequenas funcionalidades podem constar como issues do Bug Tracking.

Já o débito do projeto pode ser melhor compreendido como o sentimento dos envolvidos com relação ao projeto (vide exemplos citados). Débitos do projeto costumam surgir nos bate-papos das reuniões ou durante o cafezinho da equipe técnica. Para documentar isso de maneira iterativa uma lista de risco é uma boa opção. Essa lista pode ser revista e atualizada durante cada Retrospective ao fim das iterações.

Um alerta importante é: NÃO ADIANTA SÓ DOCUMENTAR! Débitos devem ser vencidos. Para exemplificar, é muito comum que um Gerente de Projetos tradicional encha uma lista de riscos e vire as costas para o problema que ela representa, assim como um programador que faz um código ruim e não tem preocupações com a qualidade interna.

Estude mais:

http://blog.fragmental.com.br/2008/02/17/gerenciando-debitos/

http://josepaulopapo.blogspot.com/2008/04/qualidade-cdigo-manutenibilidade.html