“Basta ter certeza para estarmos errados”

(Este texto nasceu de um comentário que comecei a escrever a respeito do primeito texto publicado por um amigo pelo site http://www.desnewtoniando.blogspot.com/)

Hidas,  Gostei muito da sua estréia!!!! Parabéns!!! É uma excelente proposta e espero que eu consiga colaborar com propósito do seu blog!!!

Engraçado que alguns assuntos são “paradigmáticos” por natureza. A exemplo a própria conceituação de Newton. Existiam a mais de 5000 anos antes de cristo!!!! Isso mesmo!!! E eram tidas como ciência oculta!!! De conhecimento de poucos que sabiam ler o alfabeto DEVANAGARI (com o qual se escreve em sânscrito).

DEVA = Deus/divindade

NAGARI = escrita.

As pessoas com capacidade de ler estes ensinamentos e obter este conhecimento influenciavam mais o meio onde viviam do que aqueles que não as conheciam.

TAMAS, RAJAS e SATTWA respectivamente significam em sânscrito INÉRCIA, MOVIMENTO e ESTABILIDADE.

Mas não eram entendidos em si apenas. Existiam leis “explicativas” da própria dinâmica destas forças. Como por exemplo a lei do KARMA (Ação e reação), a lei da egrégora (ou “força holística” que diz que o valor/capacidade/força/conhecimento da soma das partes é menor que a valor/capacidade/força/conhecimento do todo).

Ou seja, em algum momento na história estes conceitos eram válidos e importantes. O mesmo podemos do próprio conceito de DEUS. DEUS inicialmente na cultura dos povos pagãos era visto e entendido como qualquer coisa, evento ou corpo da natureza. Deus era então o sol, a lua, as estrelas, o trovão, a chuva, o mar, a montanha, as nuvens, etc. em algum momento alguém estudou o movimento dos astros e, baseado neste conhecimento, previu os solstícios e equinócios, e com isto fez as vezes de “representante de Deus”. Eram Deuses na Terra os que detinham este tipo de conhecimento (o 1º nível de deturpação).

Não demorou muito até que alguém dissesse que Deus era uma entidade intensa, justa, onipotente, onisciente e onipresente. O pecado original fez com que o ser humano “nascesse devendo” a Deus. É claro, seu representante cobrava esta dívida.

Até que chegou um cara que disse que Deus não era nada daquilo. Disse que Deus era amor e bem aventurança. Acabou crucificado mas seu conceito de Deus permaneceu. Demorou para ser largamente aceito este conceito mas atualmente ele é aceito (apesar de não seguido na prática).

Hoje o conceito de Deus é variado. Para algumas religiões ainda prevalece a visão do Deus cobrador e Juiz do bem e do mal, para outras ele é amor, ou ainda consciência, luz, energia, força, e até mesmo o próprio universo absoluto.

Minha pergunta é: porque reduzimos nosso entendimento de deus a algo baseado em uma sensação de esperança e fé? Por que nossa mente não está apta a entender um novo conceito! Não que seja o novo conceito VERDADEIRO mas ele é um pouco mais refinado a cada geração que aplica a cognição para fazê-lo evoluir.

Não estamos prontos a aceitar a morte como um fim da nossa vida como a entendemos. Precisamos acreditar que somos eternos. O paradoxo é: “não faz sentido eu ser finito!! Minha consciência (esta que voz fala) permanecerá!” Será? Não sei! Mas também não acredito que alguém saiba. Resta mesmo é acreditar e esperar!

Fato é que nossos conceitos (justamente nesta era de conhecimento e produção exponencial) se tornam cada vez mais estáticos, fixos e imutáveis pois há muito conhecimento e praticas que se baseiam neles…e daria um trabalhão pensar em algo novo…mais completo…mais próximo da realidade atual….mais adequado ao futuro que pretendemos…

Podíamos pensar que a vida é sim finita, e por isso mesmo precisamos nos esforçar para fazermos o melhor, para sermos elos fortes nesta corrente humana em busca do conhecimento e da felicidade. Um nó forte na teia de vida.

Tenho minhas sugestões para transformar nossa realidade baseando-se em conceitos mais sustentáveis. Não garanto que o meu ponto de vista é o mais adequado, não tenho certeza de como uma empresa deve funcionar para crescer mas tenho propostas alternativa (até porque não acredito em fórmula mágica mas sim em adequação cognitiva). Quero tentar um mundo mais justo e integro. Não tenho certeza que conseguirei, mas afinal, basta ter certeza para estarmos errados.

 

Kleiton Kühn
kleitonkuhn@hotmail.com

http://kleitonkuhn.blogspot.com/
http://nrgconsultoria.com/

---

Antes de imprimir, pense em sua responsabilidade e compromisso com o meio ambiente.

O papel da qualidade no desenvolvimento de Software

 

Vejo que o mercado vem mudando sim, principalmente tomando-se, como base, cenários de uma década atrás, por exemplo. Porém, não creio que a diferença seja que antes pagava-se por qualidade e hoje não mais. Em verdade, o cliente antes pagava por qualquer coisa. a demanda era vertiginosamente crescente e a quantidade de pessoas que produziam Softwares de maneira minimamente séria era indiscutivelmente baixa.

Por consequência disso, os desenvolvedores tinham um tempo razoável para trabalhar, e o produto podia ter mais qualidade. Não por exigência do cliente, mas porque o mundo era diferente, a urgência era outra, a concorrência em muitos setores era praticamente nula, a cultura do desenvolvimento tinha outros princípios.

O que vejo é que, assim como em qualquer outro mercado, quanto mais produtos similares o cliente tiver a opção de adquirir, mais atenção aos detalhes ele dará, e é nesse ponto que aquele que tiver mais diferenciais reais e percebidos pelo cliente (o conhecimento no negócio, por exemplo) irá vencer a competição.

Questão importante: mas e a qualidade, não é um diferencial???

Resposta: ao meu ver, não! Pelo menos não de início. Com o tempo talvez o cliente se arrependa da aquisição e talvez ele pense:

“Puxa, se pelo menos eu tivesse ouvido aquele cara que não tinha carisma nenhum” - é um cara técnico tentando vender sistema – “Mas que foi sincero e me explicou que um sistema não poderia ser feito pelo preço que eu gostaria de pagar e muito menos no prazo que eu esperava receber...”

Mas neste ponto talvez já seja um pouco tarde. Softwares muito grandes são difíceis de trocar assim, de uma hora para outra. Muitas vezes envolvem a “cabeça” de pessoas demais dentro de uma empresa, ou às vezes cabeças muito “influentes”, o que sempre acontece em grandes corporações. O fato é: numa dessas, muitas vezes o desenvolvedor bem intencionado já ficou para trás, enquanto que o vendedor esperto já garantiu suas férias no caribe.

Bom, a moral da história é que, para o cliente, soam mais irresistíveis aquelas promessas mirabolantes de um vendedor “macaco velho” (se possível com aquele toquezinho de “desconto para clientes especiais”) do que a realidade nua e crua de que sem qualidade um sistema não passa de “jogada de marketing”.

Ao meu ver, a realidade é que o cliente não percebe, nunca percebeu e, talvez, nunca perceberá a importância da qualidade de um Software. Isto porque, para ele, é parte implícita na compra de um Software que o mesmo faça o que ele quer e da maneira que ele quer.

Costumo comparar isso ao comportamento de qualquer cliente (inclusive desenvolvedores de Software) ao comprar, por exemplo, um celular.

Mas deixe-me explicar melhor: quando você compra um celular, você costuma ler atentamente cada recurso que o celular deveria ter conforme a especificação? E mais do que isso, você TESTA cada um dos itens da especificação??? Mas é claro que não!

Deixe-me expor uma situação ainda mais absurda, mas que esclarecerá perfeitamente o que quero dizer: o que você sentiria se descobrisse, 1 ano depois da compra, que o seu celular não faz ligações para o Acre, às terças feiras, em noites de lua cheia em que o céu está nublado e, ao reclamar, o suporte lhe dissesse “Mas o senhor não testou esta situação quando recebeu o produto?”. Eu lhe digo o que você sentiria: Ódio! Ódio mortal!

Pois então, porque é que um cliente comprador de Software deveria se comportar diferente? Sim, eu sei que Softwares hoje em dia são produtos altamente personalizados, sei também que uma função que na tela parece simples provavelmente envolverá dezenas de linhas de código, mas o cliente não sabe! E nem é obrigado a saber.

Agora, uma coisa que é inegável. A longo prazo, a qualidade é realmente a alma do negócio. Um sistema bem estruturado, com o passar do tempo, vai gerar trabalhadores orgulhosos e clientes satisfeitos. Um mal estruturado irá gerar trabalhadores paranóicos e clientes com leves tendências homicidas. Fato!

Agrega-se a isso o fato de que um cliente satisfeito espalha as boas novas para 5 pessoas. O insatisfeito denigre sua imagem perante 15. Logicamente este número é um chute e variará de mercado para mercado, de situação para situação, mas é um cenário constante em qualquer tentativa de comercialização de produtos ou serviços.

Mas então, se a qualidade em si não é um diferencial na hora da venda (lembrando que estamos falando de um primeiro contato com o cliente que não tenha um “pré-conceito” formado sobre o produto ou a empresa), mas se é imprescindível a longo prazo, como eu faço para gerenciar estes dois momentos distintos porém indivisíveis?

Bom, é um assunto interessante, mas acho que isso já é um outro tópico...

 

(Texto de Hideki Kawauchi – amigo e colaborador)

Comentário de Kleiton:
Hideki, espero que continue se arriscando a escrever o que pensa. Sua opinião é sempre muito valiosa. Primeiro para você mesmo (pois escrevendo nos forçamos a aprender e definir nossos conceitos e significados) e segundo porque não estamos sós: muita gente busca conceitos de qualidade, conceitos de gerenciamento de projetos e uma nova visão sobre as práticas em empresas de TI. Invista tempo nisto! É o primeiro passo para transformar a realidade. abração!!!

∴Papo de Líder∴

Indo para o trabalho sempre escuto comentários sobre liderança de Eugenio Mussak no quadro “papo de líder” na rádio Eldorado.

Hoje ele falou sobre vontade e definiu “líder” como o gerador de vontade.

Gostei do conceito mas não concordo com ele. Ao meu ver ninguém gera vontade em ninguém. A vontade já existe latente dentro de qualquer ser humano. O papel do líder neste caso é tornar consciente esta vontade ao seus colegas e subordinados.

Não acredito que alguém possa gerar vontade em alguém, a não ser que a vontade já esteja lá dentro. Para mim , é mais como alguém “assoprando uma brasa até virar fogo, deixando-a viva e vibrante do que atear fogo em algo apagado”.

Um exemplo: ninguém conseguiria gerar em mim a vontade de comer carnes pelo simples fato de eu não considerar carne um alimento. Não há líder no mundo que me faça ter vontade de comer carnes. Pode até existir alguém que me obrigue a comer ou me engane, mas não terei comido por vontade de comer.

Para mim um líder é alguém que mostra para as pessoas uma verdade que foi esquecida ou que ainda não foi percebida. Inspira a fazerem seus trabalhos.

E quem melhor que você mesmo para ser seu líder???

Confúcio disse certa vez: “trabalhe com aquilo que gosta e não terá que trabalhar um dia sequer na vida”.

Algumas pessoas até podem se motivar por metas que não representam sua verdadeira vontade, mas esta motivação com certeza não será duradoura. Muitas vezes vinculam os objetivos pessoais de cada indivíduo aos objetivos da empresa através do compartilhamento de crenças e valores comuns. Esta vinculação não é manipulação falsa, pelo contrário: alguém que queira promover boa educação à seus filhos, ou constituir uma família (por exemplo) pode ser motivado a se esforçar ainda mais no trabalho. Ao atingirem coletivamente os resultados esperados que mantenham a remuneração dos integrantes, estes conseguem atingir seus objetivos pessoais.

O mal entendimento hoje é justamente este: as pessoas não sabem por que trabalham. Acham que trabalham por dinheiro. Quem pensa assim está enganado. Quem trabalha por dinheiro é mais uma foca fazendo o show por um peixe. Não nasceu para fazer aquilo. Mas vai viver a vida toda presa naquela atividade.

As pessoas querem ser felizes. Elas trabalham para serem felizes. Algumas ficam dois terços da vida em ambientes de trabalho medíocres só para conseguirem realizar (no terço restante) a sua felicidade. Parecem ter esquecido que esta vida é finita. Mas estou aqui para relembrá-los: eu e você vamos morrer um dia!!! Por isto realize a sua vontade e procure trabalhar em algo que lhe traga felicidade.

 

Kleiton Kühn
kleitonkuhn@hotmail.com

http://kleitonkuhn.blogspot.com/
http://nrgconsultoria.com/

---

Antes de imprimir, pense em sua responsabilidade e compromisso com o meio ambiente.

Metagerenciamento: Um Modelo de gestão baseado no modelo de Gerenciamento Agil de Projetos

Todos nós notamos que atualmente o mercado não está mais tão disposto a pagar por qualidade quanto a quinze anos atrás. Na verdade o cliente exige a qualidade a baixo custo, exige que o fornecedor conheça seu negócio e o negócio do seu cliente, exige que a solução, serviço ou produto a ser entregue seja aderente, flexível, robusto e estável. Os tempos são outros, a concorrência aumenta e os modelos de gestão por projetos em alguns mercados se consolida a cada dia como a solução para atingir os resultados pretendidos. Parece quem, enfim, a era industrial passa o bastão para a era do conhecimento.

Exemplos de empresas desta nova era são as muitas empresas de Softwares e soluções de TI. Elas são uma vanguarda no que diz respeito a produtos, serviços. Não apenas por trabalharem com tecnologia, mas por estarem mais aptas a adorem modelos de gestão onde o gerenciamento do conhecimento deve ser utilizado.

Mas por que este é um tipo de negócio tão diferente das empresas do passado? Uma frase que escutei a algum tempo atrás: “empresa de software não tem estoque”.

Sua matéria prima são idéias, conhecimentos tecnológicos e outros conhecimentos específicos relativos aos produtos da empresa além do conhecimento do negócio dos seus clientes: hoje em dia não conseguimos desenvolver nada realmente útil se não obtivermos a satisfação do usuário na prática do negócio.

Por este motivo muitas destas empresas estão buscando novos modelos de gestão dos seus processos e dos seus projetos. Modelos que dão ênfase para o foco aos clientes, mas sem submeter os membros da equipe a qualquer formato de controle autoritário ou de supervisão. Muitas empresas de software (pelo menos as que já perceberam que uma gestão mais sustentável e participativa é urgente para sua sobrevivência!) passam a delegar ao invés de centralizar, buscar a discussão produtiva para sanar os problemas ao invés de apontar alguém como responsável. Por qual motivo? Porque é a decisão mais assertiva a ser tomada! As burocratizações impostas por alguns modelos não tem força de influência na cultura destas empresas. Nelas a pesquisa por novas tecnologias e modelos não se prendem a obrigatoriedades: elas implementam o que é saudável e põem de lado o que não lhes serve para o momento. Estas são as famosas “learning organizations” profetizadas por Peter Senge e companhia. Elas buscam modelos para reter e desenvolver a capacidade de suas equipes em criar soluções cada dia mais avançadas, atrativas e baratas, que agreguem real valor aos seus clientes, fidelizando-os.

Este fato faz com que muitas destas empresas trabalhem dentro de um modelo projetizado de trabalho. Mas qual seria o modelo de gerenciamento de projetos mais viável e interessante?

Temos o PMI e toda a metodologia clássica de gestão de projetos que, por muitas vezes, dá ênfase ao processo e ao planejamento e ao controle em detrimento à execução e a pragmática e assertividade da interação com o cliente (característica do modelo de Gerenciamento Ágil de Projetos).

Prós e contras

O Gerenciamento Clássico de projetos (proposto pelo PMI) faz com que o planejamento seja obrigatoriamente realizado de forma detalhada logo no início. Basicamente tudo estará contido no escopo do projeto (o que será feito e o que não será feito muitas vezes).

Este formato funciona muito bem para a construção de um prédio ou de uma ponte, onde as necessidades de customização não são mandatórias (mesmo que desejáveis). Já para o gerenciamento de uma fábrica de software este modelo pode gerar muito retrabalho, negociações, controles de aceites e por conseqüência gerar alongamento de prazos e desconfiança (Imagine-se recebendo um documento com 180 páginas para ser lido e aceito em uma semana: o cliente não tem tempo de parar sua operação para analisar um bloco de informações tão grande e também não está disposto a correr o risco de aceitar um recurso que não lhe atenderá plenamente): precisaríamos de pessoas chaves do cliente (conhecedoras profundas das regras de negócios e posicionamento estratégico atual e futura da empresa) muito disponíveis e dispostas a participar do processo de criação da solução. Com este envolvimento e participação os próprios usuários se comprometem de forma mais profunda com o projeto e seus resultados do que quando não é valorizado e considerada sua participação ativa. Precisamos também de pessoas com profundo conhecimento dos produtos e da tecnologia envolvida para as customizações, além, é claro, de habilidades de relacionamento e negociação com os envolvidos. O modelo de gerenciamento ágil tem uma perspectiva mais dinâmica de pesquisa e, por envolver muito o cliente, pode apresentar atividades pouco objetivas no que diz respeito a conclusão de entregáveis. Neste não temos um escopo fechado e completamente detalhado mas uma visão (por muitas vezes subjetiva) sobre o que deve ser contemplado no projeto, a especulação sobre possíveis soluções alternativas, novas tecnologias e formas de se chegar aos resultados pretendidos (sempre envolvendo o cliente no aceite destas possibilidades) , a adaptação das soluções planejadas em conjunto, remetendo possivelmente a novos ciclos de especulação e a adaptação até que seja definido o encerramento do projeto após o recebimento e validação das soluções propostas em produção.

Teoricamente parecem ser incompatíveis os dois modelos, mas na prática ocorrem naturalmente muitas vezes. Quando a empresa de TI não é bem estruturada em gerenciamento de projetos (pelo menos nenhuma estruturação visível ou perceptível) ela sente através da sua demanda de trabalho a natural necessidade de organizar equipes e pacotes de trabalho que identifiquem as necessidades dos clientes (em menor grau de detalhamento inicialmente e depois gradativamente melhorando suas forma de solicitar desenvolvimentos, customizações, manutenção e suporte). Os serviços podem ser neste caso naturalmente planejados dentro de períodos curtos (dias ou semanas) para que o coordenador tente antever a necessidade de alocação e capacidade de produção de seus recursos (desenvolvedores, analistas e consultores) – quase como fosse um projeto semanal de tarefas e atividades. Neste caso não existe a possibilidade de determinação de encerramento destas atividades muitas vezes e por isso deixam de ser tratados como mini-projetos (de desenvolvimento) e passam a ser tratados como serviços (de manutenção/suporte).

Dificuldades nos dias de hoje

A demanda por customizações cresce a cada dia. O cliente não quer muitas vezes se adequar a processos pré-determinador, rígidos e pouco aderentes a realidade e maturidade da empresa cliente. Atualmente é entendido e aceito que um pequeno distribuidor (por exemplo) pode ter um processo muito distinto (e não apenas simplificado) em comparação a um grande distribuidor, pois a vertical de negócio já não é suficientemente flexível nos sistemas atualmente existentes para atender a todas as necessidades (e quando são flexíveis passam a ser por muitas vezes complexos, confusos, utilizando termos e conceitos que podem ser diferentes dos utilizados pela cultura no cliente).

Já está claro que o cliente precisa de aderência de suas das regras de negócios (implícitas e explícitas) ao sistema de gestão a ser adotado. A dificuldade que surge em primeiro lugar é o fato de que as pessoas chaves no cliente e outros envolvidos nem sempre conhecem de antemão a solução desejada. Elas tem uma idéia funcional genérica que não chega ao nível de tratamento das informações de entrada e saída de cada processo. Fora isso, a cultura da empresa pode adotar formatos e termos específicos diferentes dos academicamente aceitos e utilizados.

Ocorre também muitas dificuldades de compreensão ou incompatibilidade de significados entre termos como “tipo de pedido” e “operações fiscais” ou “Pedido de clientes” e “Ordens de Vendas”, ou “Orientação à compras”, “Planejamento Logístico” e “Demanda de Suprimentos”. Este alinhamento é necessário entre pessoas com perfil de gestão e negócios e algumas vezes com perfil técnico/especialista.

Além disto o gerenciamento de mudanças torna-se um complicador ao invés de ser uma forma de facilitar a definição sobre o que está e o que não está dentro do previsto ao escopo. Como o escopo é subjetivo  (uma visão orientadora sobre as funcionalidades a serem contempladas apenas) não se caracteriza facilmente uma mudança de escopo mas sim uma nova definição específica de customização. Neste caso SLAs podem ser perigosamente danosas.

Qual é a saída?

Depende! Uma forma entre a clássica e a ágil que, adequada pelo bom senso de cada empresa, solução e negócio seja mais aderente a cultura da empresa. Abaixo uma proposta de associação entre práticas clássicas e o modelo ágil de gerenciamento:

- Levantar e mapear de forma macro todos os processos buscando definir um escopo de funcionalidades;

-Definir os processos prioritários e mapeá-los, entender como funciona o cliente e como seus usuários trabalham;

-Sugerir baseando-se nestas informações as soluções que devem ser criadas (em consenso com os usuários chave, gestores e patrocinadores);

-Formalizar a proposta de solução (que pode ser chamada de solicitação, especificação ou customização) e colher o aceite dos envolvidos;

-Detalhar esta especificação funcional juntamente com a área de desenvolvimento (analisando a viabilidade dos requisitos solicitados). Caso seja necessária alguma alteração no escopo desta especificação, levar os pontos críticos aos usuários para nova rodada de criação, negociação e consenso;

-Desenvolver os recursos solicitados, inspecionando a programação e homologando o recurso (primeiro internamente, depois com apoio dos próprios usuários.

Assim a empresa ganha em produtividade de entregáveis, já que as soluções serão realizadas por processos. O entendimento do negócio do cliente é valorizado e os usuários chaves envolvidos se comprometem para a virada do sistema. As margens de lucro ficam mais controláveis e projetos de valor fechado não viram bichos de sete cabeças.

Conclusão: soluções flexíveis e dinâmicas (pela grande capacidade de produção de customizações como é o caso do Microsoft Dynamics AX com seu desenvolvimento orientado a objetos são uma excelente saída quando o assunto é agilidade, conectividade e aderência, se os projetos de implantação forem coordenados por empresas competentes em gerenciamento de projetos.

Espero ter auxiliado com um novo olhar sobre desenvolvimento e implantação de sistemas e seus vários modelos de gerenciamento de projetos. Quem sabe os novos modelos não criem empresas únicas preocupadas com os clientes e suas necessidades.

 

Kleiton Kühn

* kleitonkuhn@hotmail.com

Cel.: 55 11 9141-9545

http://kleitonkuhn.blogspot.com/

http://nrgconsultoria.com/

---

P Antes de imprimir, pense em sua responsabilidade e compromisso com o meio ambiente.