Implantação de Sistemas

São 45 anos desenvolvendo e implantando sistemas. Uma vida. Dessa experiência posso afirmar que já vi excelentes soluções se tornarem um fracasso por causa da falta de um  processo de implantação ou mesmo a baixa aderência das partes a metodologias e soluções não tão boas com excelentes resultados por conta de um bom processo de implantação. Muitos não sabem, mas por exemplo a taxa de insucesso do SAP é bastante elevada....em geral a taxa de insucesso em implantações ainda é bem elevada. 

Muitas empresas contratam uma solução PRONTA como "salvação" , e depois tentam encaixar um sapato 40 em um pé 42...

Não querem mudar seus processos internos, esperam que a solução PRONTA funcione em total conformidade com o seu negócio. Este entendimento é a melhor forma de se iludir.  E aí muitas empresas desistem no meio do caminho..indo da euforia a decepção em um piscar de olhos.. estamos falando de cerca de 60% das empresas.

Quando analisamos os casos de insucesso e os de sucesso observamos que o segredo está nos detalhes e que estes não são contados, --- é interessante que o momento que iniciamos um Projeto novo ser o momento que pouco ou nada sabemos sobre o mesmo --- parece que são tesouros que necessitam ser muito bem guardados e que em algumas empresas são protegidos pela maldição do Tutancamon.

Penso que a taxa de insucesso pode ser reduzida se houver transparência e realismo  no relacionamento. O Fornecedor de tecnologia apresentar a sua solução em um nível de detalhamento bastante grande de forma que o cliente entenda o que a solução faz e o que não faz, e dependendo do acordo comercial contrate a customização daquilo que a solução não faz. 

Hoje nossa solução atende  85%  de todos os requisitos de uma operação de cobrança. na entrada na empresa, mas o que se faz com os 15%? Eles são os detalhes, que muitas vezes nem o contratante tem domínio... 

​

Luciano Basile

CEO de i-Coll Soluções Telemática | OMNI-COLL Soluções Integradas

+55 21 9-9337-4896

skype: luciano.basile
luciano.basile@i-coll.com.br

http://about.me/luciano.basile/#

O Quadrante do Débito Técnico

Débito técnico é um neologismo, cunhado por Martin Fowler, que se refere ao acúmulo de defeitos, baixa legibilidade de código, dados des-normalizados, arquitetura ineficiente, desenho pobre e coisas como essas. É como um “cheque especial técnico” onde o débito vai se acumulando e depois é cobrado da solução final com juros e correção monetária. Abaixo o quadrante nada “mágico” do Débito Técnico.

Geralmente os times técnicos focam muito no débito técnico relativo ao código, mas ele pode ocorrer em todos níveis da arquitetura, incluindo mas não se limitando a, interface com usuário, lógica de domínio, comunicação e aos dados.

Esse gráfico não é o original cunhado por Martin Fowler. Ele teve o quadrante Inconsistente/Imprudenteestendido por Scott Ambler para endereçar questões além do código.

Existem algumas razões Prudentes para  entrar no “cheque especial” do débito técnico como a redução do tempo de liberação da solução (time-to-market)  ou uma oportunidade de aprendizado, devido à pressão do negócio.

Outras razões são Imprudentes como não investir  em arquitetura e desenho de forma Intencional, ou mesmo de forma Inconciente, resultado de não ter o conhecimento suficiente para entregar a solução.

Entre diversas abordagens para fugir do débito técnico está a adoção de métodos de desenvolvimento centrados em arquitetura, aliados ao desenvolvimento de provas de conceito e refatorações. Essa é uma abordagem que tem se mostrado sustentável, para gerenciar melhor as decisões técnicas visando manter o débito técnico sob controle.

E você? As soluções usadas em sua empresa acumulam débito técnico?. Pense nisto. Uma hora você terá que pagar a conta. 

Como tornar um aplicativo amigável ao usuário

Um aplicativo bom não significa ser um "canivete suíço" complexo demais. Veja os mandamentos do "user-friendly".

Uma interface amigável ao usuário é a regra mais importante de todas se você quiser que colaboradores e usuários externos adotem uma aplicação corporativa. Mas, para falar a verdade, o que torna um aplicativo “user-friendly”? Essa é uma ciência complicada, com livros e pesquisas dedicados exclusivamente a esse assunto; no entanto, se seu app possui algum desses três elementos, isso não é um bom sinal. 

1. Muitos lugares para fazer escolhas, especialmente na mesma tela. 

“Se você estiver trabalhando com uma tela que possui 40 opções, menus drop-down e outras caixas, não é realmente porque precisa fazer 40 coisas diferentes”. 

“Se estiver desenvolvendo uma interaface simples e bem pensada, com apenas alguns controles discretos, fica mais fácil para utilizar e testar. E, com sorte, a aplicação se torna mais estável”. 

2. Muitas telas. “Existem princípios de desenvolvimento de aplicações que realmente transcendem a questão de empresa ou consumidor”. “Um deles é a ‘regra dos três cliques’. A cada vez que o público precisa clicar em um link ou ser transportado para outra tela, você perde metade dele em termos de atenção e para manter em mente o contexto do que estavam fazendo momentos antes. Depois de três cliques, já perdeu muita gente”. 

3. Funcionalidades demais. Considere a combinação dos primeiros itens. Se você não pode colocar muitas coisas em uma mesma tela e não é recomendável ter telas demais, tudo leva a uma conclusão inevitável: não dá para abraçar o mundo e oferecer conteúdo em excesso. 

 “Você não pode tornar essas coisas muito complexas, é preciso realmente pensar sobre a quantidade de informações e opções necessárias para que os usuários executem uma ação. Se as pessoas tiverem que passar por uma transação atrás da outra, fica muito chato. Sendo assim, preste atenção ao valor de cada info colocada na tela” conclui. 

A solução, é não tentar criar um aplicativo que resolva todos os problemas de todos os usuários. “Nossas aplicações tendem a ser feitas sobre a regra dos 80/20, ou seja: tente desenvolver algo que faça 80% ou 90% do que você precisa muito bem, e ignore o resto”.