E Agora, O Que Eu Faço? Planejando Mudanças de Design

Com bastante frequência, me vejo conversando com pessoas sobre seus designs, planos e arquiteturas de sistemas. E muitas vezes essa conversa acontece tarde demais, e os designs já estão implementados ou parcialmente implementados. Isso pode ser muito frustrante quando o design em andamento foi considerado não ideal para a situação.

Eu compreendo o sentimento de frustração que surge de uma situação como essa, mas é algo que nós, da área de TI, precisamos enfrentar com muita regularidade, e gerenciar essa reação de forma construtiva é uma habilidade fundamental em TI. Precisamos nos tornar mestres dessa situação, tanto técnica quanto emocionalmente. Não devemos ficar paralisados por ela; trata-se de uma situação natural que todo profissional de TI vivenciará regularmente. Ela não deveria ser desanimadora ou paralisante, mas é perfeitamente compreensível que possa parecer assim.

Uma razão fundamental pela qual vivenciamos isso com tanta frequência é que a TI é um campo imenso, com um grande número de variáveis a serem consideradas em cada situação. É também um campo altamente criativo, no qual pode haver inúmeras abordagens viáveis para qualquer problema. A existência de uma única opção “melhor” raramente é verdadeira. Normalmente, há muitas opções concorrentes. Às vezes elas são muito semelhantes entre si; às vezes essas opções são drasticamente diferentes, o que torna muito difícil compará-las de forma significativa.

Outra razão fundamental é que os fatores mudam. Isso pode acontecer porque surgem novas técnicas ou informações, novos produtos são lançados, produtos são atualizados, preços mudam ou as necessidades do negócio mudam pouco antes, ou até durante, os processos de tomada de decisão e de design. Esse ritmo de mudança não é algo que nós, como profissionais de TI, possamos esperar controlar. É algo que precisamos aceitar e administrar da melhor forma possível.

Outra coisa que vejo ser frequentemente esquecida é que uma solução que era ideal quando foi criada pode não ser ideal se a mesma decisão fosse tomada hoje. Isso não constitui, de forma alguma, uma deficiência no design original; ainda assim, já vi muitas pessoas reagirem como se constituísse. O cenário mais comum em que vejo pessoas exibirem esse comportamento é na aversão ao uso de RAID 5 no design de armazenamento moderno, sendo RAID 6 e RAID 10 as alternativas populares, com boas razões. Mas essa aversão ao RAID 5, comum desde cerca de 2009, nem sempre existiu, e de meados da década de 1990 até quase o fim da década de 2000, o RAID 5 não era apenas viável; muito comumente era a melhor solução para as necessidades técnicas e de negócio em questão (o aumento da aversão a ele foi, em sua maior parte, gradual, e não repentino.) No entanto, muitas pessoas veem o RAID 5 como compreensivelmente ruim como opção hoje, mas aplicam essa nova aversão a sistemas projetados e implementados há muito tempo, às vezes há quase duas décadas. Isso não faz sentido algum e é puramente uma reação emocional. O RAID 5 ter sido a melhor escolha para um cenário em 2002 não implica, de forma alguma, que ainda será a melhor escolha em 2015. Mas, da mesma forma, o RAID 5 ser uma escolha ruim em 2015 para um cenário não diminui nem anula, de forma alguma, o fato de que muito frequentemente foi uma ótima escolha vários anos atrás.

Já me perguntaram muitas vezes o que fazer depois que decisões de design menos do que ideais foram tomadas. “E agora, o que eu faço?”

Aprender o que fazer quando a perfeição já não é uma opção (como se algum dia realmente tivesse sido; toda a TI gira em torno de concessões) é uma habilidade muito importante. As primeiras coisas que precisamos enfrentar são os problemas emocionais, pois eles vão minar todo o resto. Precisamos fazer o nosso melhor para dar um passo atrás, aceitar a situação e agir de forma racional. A última coisa que queremos fazer é pegar uma situação não ideal e piorar as coisas tentando justificar retroativamente decisões ruins ou entrando em pânico.

Aceitar que nenhum design é perfeito, que não há como acertar sempre tudo completamente e que lidar com isso é apenas parte de trabalhar com TI é o primeiro passo. Dê um passo atrás, respire fundo. Não é tão ruim assim. Esta não é uma situação única. Todo profissional de TI que faz design passa por isso o tempo todo. Você deve tentar o seu melhor para tomar as melhores decisões possíveis, mas também precisa aceitar que isso raramente pode ser feito – ninguém tem acesso a recursos suficientes para realmente conseguir fazer isso. Trabalhamos com o que temos. Então, aqui estamos. E o que vem a seguir?

O próximo passo é avaliar a situação. Onde estamos agora? Em muitos casos, a implementação está concluída e não há mais nada a fazer. A situação não é ideal, mas é ruim? Muito frequentemente, o maior erro que vejo as pessoas enfrentarem em um design já implementado é que ele é caro demais – tipicamente, as soluções “melhores” não são melhores por serem mais rápidas ou mais confiáveis, mas por serem mais baratas, mais fáceis ou mais rápidas de implementar. Essa é uma situação infeliz, mas dificilmente é uma situação incapacitante. Qualquer tempo ou dinheiro gasto deve ter sido um valor aceitável na época e deve ter sido aprovado. O melhor que podemos fazer, neste momento, é aprender com o processo de decisão e tentar evitar o gasto excessivo no futuro. Isso não significa que a solução existente não vá funcionar ou que não vá funcionar até mesmo extraordinariamente bem. Significa apenas que ela pode não ter sido uma escolha perfeita diante das necessidades do negócio, principalmente financeiras, envolvidas.

Existem situações em que um design que foi implementado não atende adequadamente aos requisitos de negócio estabelecidos. Felizmente isso é menos comum, na minha experiência, pois é uma situação muito mais difícil. Nesse caso, precisamos fazer algumas modificações a fim de atender às nossas necessidades de negócio. Isso pode se revelar caro ou complexo. Mas as coisas podem não ser tão ruins quanto parecem. Muitas vezes, as reações a isso são enganosas, e a situação muitas vezes pode ser salva.

O primeiro passo, uma vez que estamos em uma posição em que implementamos uma solução que não atende às necessidades de negócio, é reavaliar as necessidades de negócio. Isso não quer dizer que devamos distorcer as necessidades para moldá-las àquilo que nosso sistema é capaz de atender, de forma alguma. Mas é um bom momento para voltar e verificar se as necessidades originalmente estabelecidas são realmente válidas ou se simplesmente não foram suficientemente examinadas, ou, ainda mais provável, para ir verificar se as necessidades de negócio mudaram durante o tempo em que a implementação ocorreu. Pode ser que a solução implementada, de fato, atenda às necessidades reais de negócio, mesmo que elas tenham sido originalmente declaradas de forma incorreta ou porque as necessidades mudaram ao longo do tempo. Ou pode ser que as necessidades de negócio tenham mudado de forma tão drástica que mesmo um planejamento perfeito originalmente teria ficado aquém das necessidades existentes, e o fato de a solução implementada não ter o desempenho esperado seja de menor importância. Fiquei muito surpreso com a frequência com que essa verificação das necessidades de negócio transformou uma solução considerada inadequada em uma solução “exagerada” que, na verdade, custou mais do que o necessário, simplesmente porque ninguém contestou as superestimativas das necessidades de negócio ou ninguém questionou o valor financeiro de certos investimentos em tecnologia.

O segundo passo é criar uma nova linha de base tecnológica. Esse é um passo muito importante para ajudar a evitar que a TI caia na armadilha da falácia do custo irrecuperável. É extremamente comum que qualquer pessoa, e isso não é de forma alguma exclusivo da TI, olhe para o tempo e o dinheiro gastos em um projeto e presuma que continuar pelo caminho original, por mais tolo que seja, é o que deve ser feito, porque tantos recursos já foram despendidos nesse caminho. Mas isso não faz sentido, é claro, pois como você chegou ao seu estado atual é irrelevante. O que é relevante é avaliar as necessidades atuais do departamento e da empresa e fazer um levantamento das soluções, tecnologias e recursos atualmente disponíveis. Dado o estado atual, o melhor caminho a seguir pode ser determinado. Qualquer consideração dada ao esforço despendido para chegar ao estado atual é apenas enganosa.

Um bom exemplo da falácia do custo irrecuperável está no jogo de xadrez. A cada lance, é importante avaliar novamente todos os lances, riscos e estratégias disponíveis, porque os lances usados para chegar ao estado atual não têm influência alguma sobre quais lances fazem sentido daqui em diante. Se o maior jogador de xadrez do mundo ou um incrível algoritmo de xadrez de computador fosse trazido no meio de uma partida, eles não precisariam de nenhum conhecimento sobre como o estado atual havia se formado – simplesmente avaliariam o estado atual e criariam uma estratégia baseada nele.

É assim que deveríamos nos comportar na TI. Nosso estado atual é o nosso estado atual. Para o planejamento estratégico, não importa o que se desenrolou para nos colocar nesse estado. Só nos importamos com essas decisões e custos ao realizar um processo de retrospectiva, a fim de determinar onde a tomada de decisão pode ter falhado, para aprender com isso. Aprender sobre nós mesmos e sobre nossos processos é muito importante. Mas essa é uma tarefa muito diferente de fazer o planejamento estratégico para a iniciativa atual.

O lado infeliz aqui é que precisamos começar nossos processos de planejamento novamente, mas desta vez com, presumimos, mais recursos para trabalhar. Mas isso não pode ser evitado. Nos piores casos, os orçamentos já não estão disponíveis e não há recursos para corrigir o design falho e atingir as metas de negócio necessárias. Concessões às vezes são necessárias. Fazer o possível com o que temos às vezes é o melhor que podemos fazer. Mas, na grande maioria dos casos ao que parece, alguma combinação de orçamento adicional ou reutilização criativa de produtos existentes pode ser adequada para remediar a situação.

Uma vez que tenhamos atingido um estado em que abordamos nossas deficiências, seja simplesmente aceitando que gastamos demais, entregamos de menos ou nos ajustamos para atender às necessidades, temos a oportunidade de voltar e investigar nossos processos de tomada de decisão. É ao fazer isso que esperamos crescer como indivíduos e, se possível, em nível organizacional, aprender com nossos erros, ou determinar se houve realmente erros. Toda empresa e todo indivíduo cometem erros. O que nos diferencia é a capacidade de aprender com eles e evitar esses mesmos erros no futuro. O crescimento vem principalmente de vivenciar a dor dessa maneira e, embora muitas vezes seja desagradável de enfrentar, é aqui que temos a melhor oportunidade de criar valor real e duradouro. Não adie nem ignore essa oportunidade de revisão, seja ela uma revisão dura e pessoal que você faz sozinho, uma revisão formal e organizacional conduzida por pessoas treinadas para isso, ou algo intermediário. Quanto mais cedo os processos de decisão forem avaliados, mais fresca estará a memória e mais cedo a correção de rumo poderá surtir efeito.

O passo final que podemos dar é iniciar o processo de decisão para projetar um substituto para a implementação atual o mais cedo possível, assim que a revisão do processo de decisão estiver concluída. Isso não significa necessariamente que devamos pretender gastar dinheiro ou alterar nossos designs em um futuro próximo. De forma alguma. Mas, ao sermos extremamente proativos na tomada de decisões de design, podemos tentar evitar os problemas do passado, concedendo a nós mesmos tempo adicional para planejamento, mais tempo para levantamento de requisitos e documentação, melhor percepção das mudanças nos requisitos ao longo do tempo ao revisitar regularmente esses requisitos para ver se permanecem estáveis ou se estão mudando, mais oportunidade de obter adesão e investimento da gestão e dos colegas na decisão e melhor entendimento do domínio do problema, de modo que estejamos mais bem preparados para alterar o design pretendido ou saber quando descartá-lo e começar do zero antes de implementá-lo da próxima vez. Isso também poderia, potencialmente, nos dar uma melhor chance de codificar o conhecimento organizacional que poderia ser repassado a um sucessor, caso você mesmo não esteja na posição de tomada de decisão ou implementação quando o próximo ciclo chegar.

Com processos bons e racionais e um bom entendimento dos passos que precisam ser tomados em um caso de design ou implementação de sistemas menos do que ideal, podemos nos recuperar de passos em falso e não apenas, na maioria dos casos, nos recuperar deles no curto prazo, mas também podemos proteger a organização contra os mesmos erros no futuro.