<\/HEAD>
No clássico romance de Mary Shelley, Frankenstein<\/EM>, quando Victor Frankenstein decide alcançar seu objetivo, ele busca criar o homem perfeito. Após perceber que um humano de tamanho médio exigiria uma montagem delicada, ele faz sua criatura (Adão) com 8 pés de altura, membros proporcionais, cabelos negros lustrosos e dentes brancos perolados. Tão absorvido nos detalhes de montar e animar a criatura ao longo de vários anos do projeto, ele nunca parou para olhar o todo.<\/P>Só depois do primeiro movimento de vida percorrer sua criação é que ele percebeu:<\/P>Eu havia trabalhado arduamente por quase dois anos, com o único propósito de infundir vida em um corpo inanimado. Por isso, privei-me de descanso e saúde. Desejei isso com um ardor que ultrapassava a moderação; mas agora que terminei, a beleza do sonho desapareceu, e horror sem fôlego e nojo preencheram meu coração. Incapaz de suportar o aspecto do ser que criei, saí correndo da sala e continuei por muito tempo atravessando meu quarto, incapaz de compor minha mente para dormir.<\/EM><\/P>Shelley pode ter publicado Frankenstein em 1818, mas esse momento no romance é uma analogia excepcional para o processo de desenvolvimento de projetos e aplicações. Como profissionais geoespaciais, gerentes de projeto e desenvolvedores, há uma tentação definitiva para trabalharmos incansavelmente em um desenvolvimento técnico sem pausar para olhar o quadro geral.<\/P>Sei que pessoalmente aprecio o desafio de conectar as veias, artérias e fibras musculares de uma aplicação e tenho certeza que muitos de vocês sentem o mesmo. No entanto, é importante garantir que a inovação técnica de uma aplicação não ofusque o propósito original. É improvável que uma aplicação ou projeto ganhe vida e mate meus entes queridos, como acontece em Frankenstein<\/EM>, mas as consequências de um produto final que não atende à necessidade original do negócio ainda podem ser severas.<\/P>Já vi os efeitos de projetos e aplicações mal executados em primeira mão. Depois de trabalhar em uma organização, se eu ouvia alguém mencionar um determinado conjunto de software, acabava revirando os olhos tão forte que podia ver o interior do meu crânio. Também tive que passar longos períodos restaurando a fé dos usuários no ArcGIS, ou até convencê-los de que ferramentas geoespaciais valiam a pena serem usadas, tudo por causa de uma experiência ruim.<\/P>Trabalhando com GIS, projetos ou desenvolvimento de aplicações, raramente estamos construindo um resultado para nosso próprio benefício. Como um executivo para quem trabalhei certa vez disse: "não somos um sorvete que se lambe sozinho". Os aplicativos e projetos que supervisionamos destinam-se a resolver uma necessidade comercial definida. Se essa necessidade não for atendida, sua aplicação pode não ser utilizada pelos clientes ou usuários para quem você a desenvolveu. Como consultor, seu cliente pode não estar tão ansioso pelos negócios futuros da sua empresa se você não conseguiu fornecer o que foi pago. Se você trabalha diretamente para uma organização, seu gerente ou executivo pode perder a fé na sua capacidade de entregar o que eles querem.<\/P>Uma vez que uma organização dedicou tempo e dinheiro desenvolvendo uma solução, ela naturalmente desejará retorno sobre esse investimento. Uma aplicação que não oferece benefício não será utilizada, mas ficará pairando no ambiente de trabalho como um cheiro ruim, potencialmente azedando a impressão das pessoas sobre você ou sobre o conjunto de software que você usa.<\/P>Quando focamos no quadro maior, garantimos que nossas aplicações atendam às necessidades do usuário, em vez de focar apenas no lado técnico. É compreensível ficar empolgado ou orgulhoso por um pedaço de código que você escreveu ou por uma manipulação inspirada dos dados, mas isso não pode acontecer às custas do requisito real que nos foi dado.<\/P>A última coisa que queremos ver é aquele primeiro movimento de vida percorrer algo ao qual dedicamos tempo e esforço, apenas para perceber que criamos um monstro.<\/P><\/BODY><\/HTML>
