BOAS PRATICAS DE TI

Quando Abandonar Um Projeto ? - Parte 2

2010-02-12T11:54:00.000-08:00

Da ultima vez, escrevi sobre qual o melhor momento para considerarmos abandonar um projeto. Como recebi alguns comentários nos quais me pediram para ser mais específico, ai vai.

Desta vez, o que queremos é, na medida do possível, elencar alguns pontos que poderiam servir de indicativos caso estejamos considerando abandonar um projeto que fez água.

Vou apresentar minhas considerações na forma de perguntas. Desta forma, fica mais fácil discorrer sobre cada tema e, por outro lado, pode ser que você mesmo esteja fazendo ou já fez estas perguntas a si mesmo.

Quanto tempo estamos com o projeto em andamento?

O fator tempo, na maioria dos casos, é um dos maiores problemas para a equipe fixar. É o velho cronograma. Aqui, já vi isto algumas vezes, o responsável pelo projeto faz de tudo para não responder com assertividade a pergunta - Qual a estimativa de prazo?.

Agora, se você esta diante de um projeto que já estourou mais de 2 cronogramas fixados, acenda a luz amarelo escuro,pois é grande a probabilidade de que este projeto não irá sair tão cedo ou, caso seja finalizado, é bem provável que o projeto sofrerá um processo de currasqueamento ou seja, várias funcionalidades tidas como importantes no início, serão fatiadas para depois e deixarão de fazer parte da primeira versão. Em alguns casos nem mesmo na 10º.

Com que freqüência e quantos erros recorrentes o projeto tem apresentado?

É impossível colocar uma aplicação em produção e acreditar que a mesma não apresentará erros dos mais variados tipos. Isto é comum e faz parte da construção do software. Agora, vale a pena enumerar a quantidade e a natureza destes erros. Dependendo do tamanho da sua lista e da natureza dos itens desta relação ( freqüência e tipo de erro ) é bem provável que você esteja envolto no exaustivo movimento de vai e vem produção / desenvolvimento desenvolvimento / produção.

Já perguntou a si mesmo: " Eu mesmo usuária e confiaria neste sistema ?"

Parece brincadeira, mas não é eu mesmo já participei de projetos cujo resultado final era tão sofrível que eu mesmo não teria coragem de usar na minha empresa. Não adianta, se abandonarmos nossa honestidade profissional, dificilmente conseguiremos contornar situações para as quais a melhor solução é buscar outra alternativa.

O que os usuários dizem de tudo isso?

Goste ou não, o que esta turma tem a dizer deve fazer diferença se você esta considerando abandonar o projeto e seguir com outra alternativa. São eles que farão uso intensivo e rotineiro da solução. Não adianta empurrar software goela abaixo desta turma, pois eles farão o maior movimento contra.

Agora, feche os olhos e imagine um cenário em que , ao que tudo indica, as coisas já não estão indo muito bem e ,além disso, você tem esta turma jogando contra. Haja fé para insistir no mesmo caminho.

Quando Abandonar Um Projeto ?

2010-02-02T12:50:00.000-08:00

Qual o melhor momento para decidirmos que um projeto não deve ser levado mais adiante?

Inicio com esta pergunta, pois é espantoso ver a dificuldade que alguns profissionais enfrentam quando estão diante de projetos que simplesmente empacam e não dão nenhum sinal de que irão avançar para além da total frustração.

Normalmente esta dificuldade esta associada ao simples “Não sei mais o que fazer“.

Outras vezes, esta insistência em projetos furados esta associada a falta de capacidade mesmo.

Aqui me refiro a total ausência de capacidade e coragem profissional que deve subsidiar decisões de retorno ou desvio quando nos deparamos com obstáculos deste tipo.

Muitos acreditam que insistir em algo que já deu inúmeros indícios de que não vai avançar é o único caminho a ser seguido. Afinal, pensar de forma diferente, em alguns casos, pode ser considerado crime capital.

É meio parecido com a estória do rei que desfilou nu por acreditar que só os iluminados podiam ver a vestimenta. Como ele não queria passar por ignorante, não só achou a roupa maravilhosa, como também sai às ruas com ela.

Desta forma, parodiando a estória acima, temos aqueles que acreditam estar diante de algo inusitado e inovador e, de outro, aqueles que já se convenceram do fiasco, mas, por medo ou sensatez, decidem se calar ou a falar coisas nas quais não acreditam.

Um dos sinais mais evidentes de ambientes deste tipo é a facilidade com a qual se celebra de forma festiva resultados obviamente medíocres. Parece que, agindo desta forma, as pessoas conseguem renovar a fé numa causa perdida.

Dar meia volta é uma opção sim, mas exige competência e coragem profissional, duas qualidades meio raras no mundo da gestão de TI.

Como Comprar Serviços de TI

2009-12-12T18:42:00.000-08:00

O que queremos aqui éressaltar alguns pontos de consideração quando estamos diante da tarefa de comprar soluções de TI. Seja um sistema pronto, serviços de consultoria ou serviços de outsourcing, sempre nos deparamoscom a necessidade de fazer a escolha acertada e, o que é pior, contando com margens de erro bem estreitas.

Nestes casos, o maior desafio é evitar, após a contratação, as enormes dores de cabeça decorrentes de uma opção mal feita e o constrangimento resultante dos gastos pela ausência do resultado esperado. ( em alguns casos, resultado nenhum ).

O Produto TI, em termos genéricos, é um produto abstrato demais para o comprador avaliá-lo em termos mercantis. Muitas vezes, nem mesmo temos um produto, mas um conceito de produto.

Esta é a razão pela qual, em muitos casos, as negociações são fechadas tendo como base muito mais a percepçãodo que a convicção por parte de quem decide acerca da contratação ou compra.

Neste tipo de negociação, os envolvidos optam por valorizar elementos externos ao produto TI, ou seja, tamanho da empresa fornecedora, prestígio no mercado, importância da carteira de clientes, casos de sucesso em outros ambientes, etc. São a estes aspectos que tanto o vendedor, quanto o comprador ir^TMo se apegar nas etapas que antecederão o fechamento do contrato.

Não há nenhuma razão para acreditar que, considerando o produto TI, o tamanho de uma empresa ou o prestígio de uma marca será uma garantia infalível de sucesso na compra da solução oferecida. Atémesmo porque, em se tratando de mercado de TI, consideráveis investimentos em marketing conseguem transformar produtos muitos ruins em boas soluções.

O que os compradores raramente levam em conta é que o que esta sendo comprado ou vendido não é uma marca ou um lote de ações da empresa fornecedora, mas uma solução para um problema. Ésimples assim. Afinal, comprador e fornecedor estão frente a frente em razão de um problema sentido por parte de quem certamente irá pagar pela solução.

Do exposto, devemos ter em mente que uma solução de TI nada mais é do que a formalização em código de boas idéias. Como boas idéias é um privilégio do ser humano é fácil concluir que a qualidade e pertinência da solução dependem muito mais dos indivíduos envolvidos no projeto do que do discurso elegante da equipe de vendas ou do prestígio de mercado da empresa fornecedora.

Desta forma, grande, média ou pequena, a empresa que fornecerá a solução de TI terá que contar com gente de qualidade, pois é esta turma que dará concretude e qualidade a solução vendida. Esta sim, éa verdadeira fonte geradora de valor agregado que a empresa tem. O resto é puro marketing.

Assim, é aconselhável não subestimar pequenas empresas como potenciais candidatas ao papel de fornecedoras de solução. Em alguns casos, estas empresas contam com potencial e know how de alta qualidade que, não raro, superam em muito os quadros de grandes empresas.

Se você dúvida e é da área de TI deve conhecer pelo menos um episódio desastroso de projetos enormes levados a efeito por nomes consagrados de mercado.

É sempre bom ouvir e avaliar as soluções apresentadas com total isenção, sem preconceitos ou rompantes de deslumbramento. Muitas vezes, incorremos em erros de avaliação exatamente por ceder a sentimentos deste tipo.

Se a idéia é comprar um solução de boa qualidade, então , nada melhor do que avaliar com total racionalidade as pessoas que eventualmente serão os responsáveis por viabilizá-la.

Nestes casos, não opte por vincular tamanho ou prestígio com qualidade. Esta equação nem sempre se resolve da forma como queremos. Se puder, procure conversar com as pessoas que realmente irão meter a mão na massa. Normalmente, elas se atém mais aos aspectos do problema e, por conseguinte, aos meios técnicos de solução do mesmo.

Como Vender Serviços de TI

2009-11-26T13:29:00.000-08:00

Vender serviços de tecnologia é um processo mercantil distinto quando comparado com a venda de outros produtos. Isto por que, do ponto de vista do comprador, falta uma das principais características presentes em todo processo de avaliação que precede a compra de qualquer produto, ou seja, avaliar o produto usando dois sentidos: visão e tato.

Como serviços de TI são, num primeiro momento, essencialmente abstratos, temos que lançar mão de artifícios bem específicos que nos permita ganhar a atenção do comprador e, de forma subsidiária, dar concretude ao produto que estamos oferecendo.

Aqui vou me ater a serviços de desenvolvimento de sistemas por ser uma atividade muito pulverizada no mercado nacional de TI entre um numero expressivo de pequenas empresas.

Não dispute a atenção do comprador com o seu próprio material de propaganda

Nunca entregue folder ou qualquer material de propaganda logo no início da conversa. Afinal, temos poucos minutos para ganhar a atenção e despertar o interesse do comprador.

Como são minutos precisos para quem está vendendo, você não vai querer disputá-los com o seu próprio material de propaganda.

Deixe isto para depois. Se você foi bem sucedido nos primeiros minutos da conversa, o folder servirá, mais tarde, para reforçar detalhes que o comprador quer rever ou recordar.

Seja prudente no uso da palavra “Não”

Evite o uso da palavra não especialmente se ela preceder palavras que denotam viabilidade. “Não é possível”, “Não dá” etc. É senso comum que quando se trata de tecnologia, dificilmente não podemos encontrar uma solução.

Elas sempre existem, podem não ser fáceis de serem enxergadas ou viabilizadas num momento inicial, mas elas estão lá. Cedo ou tarde são encontradas e viabilizadas.

Não tenha medo, aceite ou faça desafios.

Quem compra quer ser convencido. A menos que eu esteja enganado, não existe nada mais convincente do que desafiar ou aceitar desafios.

Muitas vezes consegui fechar bons negócios por que desafiei o comprador a se comprometer comigo caso eu fizesse o que era necessário num prazo 3 vezes menor em relação aos meus concorrentes.

Outras vezes, tive que aceitar o desafio de resolver, ainda que de forma preliminar, o principal problema do comprador para, só depois, fecharmos o negócio.

Não é tão simples agir assim, você tem que ter muita segurança no seu potencial e saber enfrentar tais desafios de forma calculada. O diferencial aqui é que, normalmente, quem vende serviços de TI, não age assim.

Fique com as necessidades sentidas e problemas que estão incomodando

Não perca tempo com problemas ou necessidades que o comprador não priorizou ou nem mesmo sentiu.

Se o comprador quer um sistema para gerenciar sua produção não tem cabimento você falar sobre suas soluções na área contábil também.

Outras necessidades terão o seu lugar certo para serem discutidas, mas, primeiro fique atento a tudo aquilo que compõem o problema sentido ou percebido. Lembre-se, é por causa dele que você foi recebido e esta sendo ouvido por quem quer comprar.

Venda ao poucos

Uma grande venda, se você não é famoso ou dono de uma grande empresa, é um conjunto de pequenos negócios que você vai fechando ao longo do tempo com o comprador.

Já comecei em clientes com trabalhos pequenos e, com o passar do tempo e assegurando sempre um bom nível de satisfação, me vi em meio a projetos enormes e de grande retorno financeiro.

Se for possível, tenha o melhor dos dois mundos.

A melhor combinação que se pode ter neste segmento é uma pessoa com habilidades de vendedor, mas que também traga uma bagagem muito boa de conhecimento de programação.

Se puder contratar um profissional com este perfil, suas chances de sucesso aumentam muito. Nada melhor do que um programador para vender serviços desta natureza.

Não prometa o que não poderá cumprir

De tão obvio, nem vou comentar. Mas senti a necessidade de colocar isto aqui.

Não esgotamos a lista de dicas com o exposto acima. Até pode ser que algumas dicas mencionadas nem sejam tão relevantes ou já eram conhecidas da maioria. Mas fica ai algumas indicações de quem tem feito bons negócios nos últimos anos.

Como Avaliar Profissionais de TI

2009-11-24T12:59:00.000-08:00

Montar uma equipe para atuar num projeto de TI não é um das tarefas mais fáceis. Isto porque somos, na condição de coordenadores, forçados a adivinhar quais habilidades uma pessoa realmente tem antes de vê-la atuar na prática.

É claro que sempre tem aquele cara que construiu em torno de si a fama de ser “bom”. Isto pode ser em virtude de opiniões de amigos próximos ou de uma habilidade do sujeito de sempre conseguir aparecer bem na foto.

Seja lá como for, trata-se de uma tarefa espinhosa e, pior, se não for bem conduzida certamente iremos comprometer o resultado do projeto.

Não existe receita de bolo, mas, se o coordenador do projeto tiver grande experiência, certamente acumulou, ao longo dos anos, uma espécie de “sexto sentido” que pode ajudar a errar menos nestas escolhas.

Vejamos então alguns aspectos que podem ser de grande ajuda nesta avaliação.

Avaliar é diferente de julgar

Em primeiro lugar, lembre-se, você esta avaliando e não julgando. Isto significa que você deve evitar termos genéricos para qualificar potenciais candidatos.

Dizer ou dar ouvidos a frases do tipo “fulano é bom”, “fulano é ruim”, é julgamento e não avaliação.

Pessoas não são boas ou ruins em termos genéricos (bom, existem casos em que isto é possível). “Se dissermos, ‘fulano é bom para a execução desta tarefa” ou “cicrano é ruim para desempenhar este papel”, a coisa muda de figura.

Sempre temos que apontar para algo muito especifico logo após os adjetivos bom e ruim quando se trata de avaliar pessoas para nossa equipe.

O que a pessoa fez é diferente do que a pessoa fará

Um bom currículo já é um começo e tanto. Mas ele só diz o que o cara já “fez”. Não há nenhum elemento que nos permita concluir o que o cara “fará”.

Não é incomum portadores de currículos menos exuberantes atuarem de forma muito mais produtiva. Eu mesmo já me surpreendi inúmeras vezes. Também já tive amargas surpresas ao ver a atuação sofrível dos portadores de currículos mais “qualificados”.

Valorize o ambiente como fonte de informação

Projetos em TI são atividades de natureza essencialmente pragmática. Desta forma, nos interessa contar com pessoas que realizam coisas com qualidade. Neste caso, nada melhor do que o ambiente onde a pessoa tem atuado por algum tempo. Assim, considerando o ambiente, pergunte a si mesmo:

“O que esta pessoa fez de relevante nos últimos seis meses?” - Inventividade.

“O que aconteceria se esta pessoa tirasse um ano de férias?” - Essencialidade.

“De quem sentiriam mais falta, dele ou da mulher do cafezinho?” - Capilaridade.

Estas considerações, embora genéricas, nos levam a considerar o grau de essencialidade que a pessoa tem no ambiente onde atua. Além disso, nos permite também, avaliar em que medida a atuação desta pessoa serve de apoio ou precondição para o exercício de outras atividades a cargo dos pares desta pessoa.

Como Escolher Metodologias em TI

2009-11-17T09:39:00.001-08:00

Aqui, o que queremos destacar são os possíveis meios que iremos usar tendo em vista alcançar um objetivo. No artigo anterior, destacamos a importância da compreensão clara do problema (http://boaspraticasdeti.blogspot.com/2009/10/como-fazer-um-projeto-o-problema-parte.html)

De posse desta compreensão, nos defrontamos com a necessidade de selecionar o método a ser usado para nortear os passos em direção à solução que melhor servirá para, em fim, resolvermos o problema.

Se na fase inicial a preocupação se dirigia para entender “O QUE”, agora nos voltamos para escolher o “COMO”.

O QUE É UM MÉTODO

Sem filosofar muito, vamos nos ater a etimologia da palavra. Um método, seja ele qual for, nada mais é do que um meio, uma maneira sistematizada para fazer alguma coisa visando atingir um resultado qualquer. É exatamente a falta de compreensão desta simplicidade conceitual que resulta em erros primários na escolha da metodologia.

Me lembro de um caso em que, visando acelerar o desenvolvimento dos projetos, a direção elegeu o Scrum como a grande tacada. A metodologia foi elevada ao patamar de solução final e sua adoção foi encarada como uma questão de vida ou morte.

Centenas de reais gastos depois, os projetos mantinham o mesmo rítimo de antes enquanto o restante dos grupos estavam em treinamento. Tempos depois, tendo em vista os magros resultados obtidos, pasmem, concluíram que o método era ruim.

Me permitam um desabafo. Ruim foi o idiota que deu início a esta cruzada imbecil. O cara responsável defendia a metodologia como se fosse uma religião. Quando a vaca foi pro brejo, o cara teve a capacidade de culpar a metodologia. Felizmente, no tribunal do bom senso, a metodologia foi absolvida e o cara foi despedido. Menciono este caso, pois é um momento raro de ser visto. Vou deixar pormenores deste e de outros casos para outro artigo ‘A Era dos Imbecis na Tecnologia `.

Voltando ao assunto, um método em particular não pode ser avaliado como melhor ou pior em relação a outros. Um método, em si, não é bom ou ruim. A escolha, sim, pode ser considerada nestes termos.

Uma escolha bem sucedida se traduz por resultados de qualidade que foram obtidos pelo emprego de um método num determinado contexto para um determinado tipo de problema.

Uma escolha equivocada, normalmente, se traduzirá em resultados medíocres obtidos após um tempo excessivo de projeto. Veja, além da mediocridade dos resultados, temos um enorme desperdício de tempo.

COMO ESCOLHER E CONVIVER COM A METODOLOGIA

• Escolha a metodologia tendo em vista o tipo de problema que você tem nas mãos. Lembre-se, o determinante na escolha são as características do problema e não a popularidade da metodologia.

• Seja rápido na avaliação dos resultados que a metodologia escolhida está trazendo.

• Seja rápido na mudança. Não insista, caso tenha feito uma escolha equivocada. Pessoas irão julgar o resultado do projeto e não eventuais equívocos ocorridos no meio do caminho.

• Leve em conta a curva de aprendizado da metodologia. Normalmente, você não está sozinho no projeto. Sua equipe precisa absorver a metodologia com facilidade.

• Lembre-se que a metodologia em si não é garantia de sucesso, mas um possível caminho para chegar lá.

• Não abra mão do bom senso. Toda metodologia foi criada por alguém que, em algum momento gastou tempo pesando em qual seria o melhor caminho para resolver um problema em particular. Isto não significa que a metodologia não possa ser melhorada ou repensada por você.

• Confie no seu “feeling”. A pior coisa que pode acontecer é se deixar convencer de que só existe uma forma de resolver um problema. Afinal, é a forma que todo mundo usa, então, não posso pensar diferente.

• Pense. Temos muita pressa para entrar em ação e, por isso, gastamos pouco tempo pensando em possibilidades metodológicas diferentes ou inovadoras que poderiam ser testadas antes de optarmos por métodos consagrados de mercado.

É sempre bom lembrar que metodologias foram criadas por pessosas que gastaram algum tempo pensando na melhor forma de fazer alguma coisa. Posteriormente, alguém, não necessariamente o cara que inventou o método, formatou a idéia em padrões e regras e passou a ganhar dinheiro com isto.

Como Iniciar um Projeto de TI - Parte 1

2009-10-22T17:53:00.000-07:00

Este é o passo mais importante do processo, pois, um entendimento claro e inequívoco do problema já é mais da metade do caminho andando.

Veja que cada problema sempre traz um desafio novo. Mesmo que o problema se pareça com algo visto no passado, ainda assim, temos que estar atentos para os aspectos muito específicos de cada ambiente.

É preciso, portanto, abandonarmos, ainda que por algum tempo, idéias preconcebidas sobre como ou que deve ser feito. Vá atrás da principal matéria prima, ou seja, as pessoas que atuam interagem no cenário do problema que você quer entender. Acredite, no início do projeto, as impressões menos importante são as suas.

Entendendo o Problema

Com alguns cuidados básicos de comportamento e abordagem, podemos entender melhor o problema e criar um ambiente menos hostil durante os inevitáveis problemas de implantação do projeto.

Nesta etapa devemos:

• Gastar tempo com observação e perguntas.

• Não falar demais, mas ouvir bastante.

• Não discutir suas idéias, mas assimilar e catalogar idéias que apresentadas.

• Não ter pressa para apresentar os resultados, mas considerar alternativas para perceber novas de soluções.

• Não subestimar o usuário levando em conta seu lugar na hierarquia corporativa

• Não superestimar o usuário levando em conta seu lugar na hierarquia corporativa

• Ganhar a simpatia dos usuários ressaltando sempre sua importância para o projeto

• Promover, desde o início, um ambiente de colaboração e não de conflito.

• Ressaltar sempre que o seu papel é de coadjuvante e não de estrela.

É sempre bom ter em mente que todo grande problema é a soma de problemas menores. Grandes problemas não são entidades coesas e monolíticas com vida própria, mas fragmentos de equívocos gerenciais ou operacionais que ao longo do tempo foram se amontoando para dar origem ao Grande Problema.

São princípios básicos de abordagem que se levados a efeito nos poupará de inúmeras reuniões nas quais gastamos muito tempo “discutindo a relação” com o nosso cliente.

É sempre bom lembrar que o alvo é a satisfação do cliente como resultado do seu bom trabalho. Você dependerá de outras pessoas para garantir maior assertividade na detecção do problema.

Sem uma clara compreensão do problema, as soluções propostas acabam por colocarem mais lenha na fogueira, ou seja, elas mesmas se tornam ou agravam o problema.

O Problema está no 'I' DA TI

2009-10-10T19:03:00.000-07:00

Nos muitos anos de experiência na área, pode-se dizer que já vi de tudo e mais um pouco.

O que mais me chama a atenção, ainda hoje, é que, invariavelmente,

um grande número de empresas ainda enfrenta problemas primários com suas soluções de TI.

O primarismo a que me refiro diz respeito muito mais ao uso do que as ferramentas existentes.

Em termos de tecnologia, podemos dizer que somos bombardeados com uma avalanche de novos recursos de TI diariamente. Entretanto, boas práticas de uso destes recursos não evoluem na mesma proporção.

Prova disto é que o número de casos de insucesso nos projetos de implementação de soluções é enorme. Se você é da área, pense um pouco e , com certeza , se lembrará de meia dúzia de casos enrolados que estão em andamento neste exato momento.

Analisando alguns casos de insucesso, pude constatar que, invariavelmente, projetos equivocados de TI poderiam ser explicados muito mais a partir de uma avaliação do I do que do T.

Podemos perceber a importância do I, simplesmente considerando a interação dos interlocutores chaves no âmbito de um projeto.

A informação que se obtém depende dos usuários.

A informação que se recebe depende de uma tradução dos analistas.

A informação que se constrói depende de uma tradução em algoritmos por parte dos desenvolvedores.

A informação que se espera, ao final, fica a cargo de quem pagou ou esta pagando pelo projeto.

Imagine, agora, o enorme esforço que estes elementos precisam fazer para que estas informações trafeguem de uma mente à outra sem comprometer sua integridade.

Por mais espetacular que seja a Tecnologia adotada, fica fácil concluir que, basta haver um acumulo de equívocos cognitivos no trafego acima e teremos o Caos completo em alguns meses de projeto.

É preciso reorientar o foco e, o mais rápido possível, entendermos que o indivíduo é a chave do sucesso num projeto de TI.

Pessoas com excelente conhecimento técnico existem aos montes no mercado, mas são raríssimos os profissionais que conseguem garantir a fluidez e a qualidade da informação ( tão cara ) nos limites de um cenário com interlocutores tão díspares.