Diferença entre Plano de Negócios e Plano de Projeto

Gerealmente, percebo as pessoas confundindo os dois conceitos. Vamos as definições:

Segundo E. Bolson, plano de negócio "é uma obra de planejamento dinâmico que descreve um empreendimento, projeta estratégias operacionais e de inserção no mercado e prevê os resultados financeiros"

Segundo a Wikipédia, um plano de projeto "inclui as ações necessárias para definir, coordenar e integrar todos os planos auxiliares do projeto. O conteúdo do plano irá variar dependendo da área de aplicação e complexidade do projeto. A elaboração do plano antecede a etapa de planejamento de projeto. "

Em resumo, o plano de negócio suporta o fluxo de caixa resultante do produto do projeto, enquanto o plano de projeto descreve o trabalho que será feito para a entrega do produto do projeto.

Resumo sobre avaliação do processo de desenvolvimento de produtos

Categorias de Avaliação	Situação Atual	Meta para a situação futura
Modelo Organizacional	Forte enfoque funcional (departamental)  Pouca prática de Eng. Simultânea  Interfaces não definidas	Estrutura orientada por processo  Integração das Engenharias  Orientação para trabalho em times  Sobreposição de atividades  Mais autonomia e autoridade para o líder de projeto  "Pool" de recursos humanos
Pessoas	Especialistas  Formação restrita  Sobre/Subutilização da capacidade das pessoas  Baixa autonomia das pessoas  Poucos coordenadores de projeto	Criação das figuras:  generalistas  consultores  Maior autonomia/delegação  Empreendedor  Capacitar líderes de projeto
Foco	Prioridade departamental/ funcional  Maior enfoque no desenvolvimento do Projeto do produto separado do Projeto do processo  Planejamento dos portfólio de produtos fraco	Por processo e no cliente  Enfoque nos projetos: os objetivos dos projetos são prioritários  Engenharia Simultânea
Processo de desenvolvimento de produtos	Tempo de ciclo elevado e processo fora de controle;  Muitos projetos sendo conduzidos em paralelo  Processamento seriado das atividades  Planejamento e gerenciamento do portfólio de produtos fraco  Muitos projetos sendo conduzidos em paralelo  Poucos recursos dispersos em muitos projetos  Planejamento dos projetos é fraco  Elevado tempo p/ projetos pequenos e médios	Introdução do conceito de gerenciamento do processo de desenvolvimento de produtos  Internalizar melhores práticas no planejamento dos projetos  Buscar um melhor respeito ao prazo  Reduzir o número de interfaces  Capacidade de processamento simultâneo  Buscar uma priorização dos projetos,de forma a focar os recursos nos projetos mais  importantes através de um processo de seleção de projetos mais rigoroso e consistente com os objetivos da organização  Buscar um melhor planejamento e gerenciamento do portfólio de produtos  Buscar sempre que possível o conceito de equipes dedicadas para pequenos e médios projetos

Estrutura para Seleção de Projetos

Análise de viabilidade econômico-financeira de projeto

Introdução dessa página

Analisar a viabilidade econômica-financeira de um projeto significa estimar e analisar as perspectivas de desempenho financeiro do produto resultante do projeto. Essa análise é de certa forma iniciada na própria definição do portfólio, na fase de Planejamento Estratégico do Produto (PEP), pois, ao escolher um dos produtos para ser desenvolvido, acredita-se, que com os dados disponíveis até então, na viabilidade econômica-financeira de seu projeto. A estimativa de orçamentos para o projeto, resultante da atividade anterior, serve para trazer uma estimativa dos níveis de preço final do produto, que o tornaria viável e cobriria os custos envolvidos.

Fontes

Os conceitos e definições utilizados na criação desta análise, em grande parte, foram elaborados a partir do livro “Gestão de Desenvolvimento de Produtos: Uma referencia para a melhoria do processo.” do Prof. Henrique Rozenfeld. Outros conceitos e métodos de análise econômica-financeira utilizados foram retirados de artigos e livros relacionados à engenharia econômica.
[1]Gestão agroindustrial: GEPAI: Grupo de estudos e pesquisas agroindustriais/ coordenador Mário Otávio Batalha. - vol.2 - 3. ed. - São Paulo: Atlas, 2001
[2]MARTINOVICH, M. Como gerenciar o capital de giro. Agenda do Empresário. São Paulo, nO 11, p. 1-6, 1996.

Definições

Na presente atividade do Planejamento do Projeto, são definidos os principais indicadores financeiros do projeto relacionados com o produto final, tais como o custo-alvo do produto, as previsões de retorno do investimento e a análise de suas características, o Valor Presente Líquido – VPL, a Taxa Interna de Retorno – TIR, Método do payback e o Fluxo de Caixa esperado com o novo produto.

Essa análise da viabilidade econômica-financeira realizada durante o Planejamento do Projeto é a referencia inicial para as fases seguintes, no desenvolvimento do produto propriamente dito, torna-se um dos critérios mais importantes para se manter a decisão de executar o projeto.

Existe a necessidade de uma revisão periódica dessa analise ao longo do projeto, pois na atividade de Planejamento do Projeto, estão disponíveis apenas informações preliminares, e, portanto, passives de mudanças, sobre o ambiente em que o produto irá ser inserido. À medida que as fases do desenvolvimento vão ocorrendo, aproximam-se as condições reais do momento de lançamento do produto, e, portanto, vão aumentando as certezas quanto as características que o produto deve adotar, sua atividade e receptividade no mercado, as condições desse mercado (concorrência efetiva, surgimento de novas tendências, mudanças econômicas etc), e sua relação quanto a preço/volume. Sendo assim, a análise de viabilidade econômica-financeira pode ser refinada e confrontada com a inicialmente planejada, para efeitos de aprendizado quanto à capacidade de previsão no início de um projeto de DP.

Essa revisão da viabilidade econômica-financeira ocorre ao final de cada uma das fases do desenvolvimento do produto, juntamente ou não aos gates. Pode também ocorrer a qualquer momento, quando grandes modificações endógenas ou exógenas ao projeto assim demandarem, para se verificar se o produto continuará financeiramente viável ou não.

Mecanismos

O principal elemento que justifica a existência de uma empresa é a geração de lucro. Para os investidores, porém, não basta que o projeto tenha um resultado positivo. Para um projeto de desenvolvimento ser atrativo, é preciso que a quantidade de lucro gerado, o retorno do projeto, seja melhor do que aquele que a empresa poderia obter com outros investimentos, por exemplo, aplicando no mercado financeiro. Portanto, a essência da avaliação econômico-financeira é medir o retorno do projeto de maneira comparável com outros investimentos.

O primeiro passo para a realização da análise econômica é a montagem do fluxo de caixa, isto é, a definição do fluxo de entradas e saídas de dinheiro durante o ciclo de vida planejado para o produto.

 

Fluxo de Caixa

De acordo com Martinovich, fluxo de caixa é um instrumento gerencial fundamental na tomada de decisões empresariais. Seus objetivos são a coleta e a organização dos dados e a geração de subsídios, para a análise de desempenho financeiro e para a realização de previsões orçamentárias.

Os três componentes principais de um fluxo de caixa são:

Investimento no novo produto:

Corresponde aos gastos necessários para a geração de benefícios a longo prazo. É a quantidade de dinheiro gasta para o desenvolvimento das especificações e preparação para a produção do produto. Para determinar os gastos com o investimento devem-se levar em consideração alguns fatores:

• Tipo de Projeto: Dependendo do tipo de projeto o investimento pode ser maior ou menor. Ex.: Em projetos incrementais o investimento necessário deve ser menor que o necessário em projetos radicais, pois criam produtos e processos que são derivados, híbridos ou com pequenas modificações em relação aos projetos já existentes. Já os projetos radicais envolvem significativas modificações no produto ou processo já existente, podendo requisitar novas tecnologias e materiais.
• Disponibilidade de Recursos: São os gastos para adquirir recursos, como: pessoas, máquinas, equipamentos, veículos, utensílios, computadores etc;
• Necessidades de adquirir: patentes, tecnologias e licenças;
• Gastos com estudos, pesquisas de mercado, projetos e capacitação de profissionais;
• Necessidade de possuir um capital de giro, inclusive para eventuais imprevistos.

Uma forma de calcular o investimento é criar uma conta específica para cada projeto, da qual sairiam todos os pagamentos e gastos efetuados. O maior desafio é computar o custo de pessoa, principalmente para os membros do time que dividem seu tempo entre vários projetos. É preciso também definir claramente o momento em que os custos e receitas serão calculados. Geralmente, esse momento é o final da aprovação do lote piloto, pois, a partir desse momento, os produtos produzidos pela linha poderão ser comercializados dando início aos dois outros componentes do fluxo de caixa, as receitas e os custos e despesas de produção.

 

Receitas:

Corresponde a estimativa de venda de produtos e subprodutos gerados pela produção. Para o cálculo dessa estimativa deve-se levar em consideração fatores como: preço final e demanda dos produtos.

• Preço final do produto: Esse valor vai depender do mercado, no qual se deseja vender o produto, do produto produzido, e do lucro esperado pelo fabricante.
• Demanda dos produtos: Esse valor vai depender do produto (produtos com alto valor agregado geralmente possuem um volume de venda menor), do mercado e da fatia de mercado que esse produto almeja atingir, do preço de venda, da analise locacional e de mercado.

Para estimar a receita, é preciso estimar o valor da demanda dos produtos, em seguida, multiplicá-lo pelo preço final estimado.

Além da receita gerada com as vendas outros fatores podem entrar na receita, como: subsídios governamentais, financiamentos e valor residual do investimento.

Custos e despesas de produção:

São os valores gastos diretamente e indiretamente para a produção e comercialização do produto.

Os custos são os gastos com um bem ou serviços utilizados para a produção de outros bens. Os principais custos são os seguintes:

• Matérias primas, embalagens, materiais auxiliares;
• Mão-de-obra direta;
• Consumo de energia elétrica, de água e de combustível;
• Manutenção, seguros, aluguéis, diversos.

As despesas são os gastos como um bem ou serviços utilizados para obtenção de receita. As principais despesas são:

• Despesas com vendas, financeiras e administrativas;
• Salários do pessoal administrativos;
• Impostos e taxas municipais.

Convém diferenciar custos e despesas de produção bem dos investimentos, o que muitas vezes pode ser difícil. Por exemplo, os gastos de uma operação na produção que visa produzir uma peça do protótipo é investimento. O gasto da mesma operação em uma peça idêntica, após a liberação do lote piloto, que será comercializada deve ser já apropriada como custo direto, a ser contabilizado naquele produto específico.

O intervalo para o cálculo do Fluxo de Caixa depende da duração do ciclo de vida do produto. Um produto industrial em geral é planejado para ficar alguns anos no mercado e, por isso, o período utilizado é normalmente anual. Calculados esses valores, eles serão somados, obtendo-se um valor final do fluxo de dinheiro esperado na empresa, conforme apresentado no Gráfico 1, a seguir.

Gráfico 1 – Exemplo de Fluxo de Caixa.

Indicadores Financeiros

O Gráfico 1 representa uma previsão do montante de dinheiro que entrará ou sairá da empresa em cada um dos períodos (no caso anos) do ciclo de vida do produto. Para sabermos se esse projeto é viável ou não economicamente, precisamos avaliar e comparar esse fluxo com outros investimentos à disposição do dono da empresa. Nesse cálculo, deve-se levar em consideração que o dinheiro possui um valor dependente do tempo, isto é, receber R$500,00 hoje é diferente do que receber esse mesmo valor no próximo ano. Portanto, utilizam-se índices financeiros e parâmetros calculados com os dados do fluxo de caixa que permitem comparações e análises do desempenho financeiro do projeto. A seguir são apresentados três dos indicadores financeiros mais utilizados em projetos de desenvolvimento de produtos.

Valor Presente Líquido - VPL

Método para análise de investimentos que determina o valor presente de pagamentos futuros. Este método consiste em uma fórmula matemático-financeira em que o valor dos investimentos e do fluxo de caixa atual e futuro são convertidos para um valor equivalente na data atual por meio de uma taxa de conversão. Esta conversão é devido ao fato do poder aquisitivo do dinheiro sofrer alterações com o passar do tempo.

A taxa de conversão utilizada neste método é a Taxa Mínima de Atratividade (TMA). A figura 1 apresenta a fórmula para o cálculo do VPL.

Figura 1 – Fórmula do VPL.

O Valor Presente Líquido de um projeto de investimento possui as seguintes possibilidades de resultado:

• Maior do que zero: significa que o investimento é economicamente atrativo, pois o valor presente das entradas de caixa é maior do que o valor presente das saídas de caixa.
• Igual a zero: o investimento é indiferente, pois o valor presente das entradas de caixa é igual ao valor presente das saídas de caixa.
• Menor do que zero: indica que o investimento não é economicamente atrativo porque o valor presente das entradas de caixa é menor do que o valor presente das saídas de caixa.

Entre vários projetos, o mais atrativo é aquele que tem maior Valor Presente Líquido.

Taxa Interna de Retorno - TIR

Estabelece a taxa econômica necessária para igualar o valor de um investimento com seus retornos futuros. Significa a taxa de remuneração que deve ser fornecido pelo projeto de modo que este iguale o seu investimento, após um período. A TIR é calculada utilizando-se a mesma fórmula descrita anteriormente, porém igualando-se o VPL a zero e utilizando a TIR como incógnita de taxa de conversão.

Posteriormente a TIR é comparado com a TMA da empresa para verificar o desempenho do projeto, podendo ser:

• Maior do que a TMA: significa que o investimento é economicamente atrativo.
• Igual à TMA: o investimento está economicamente numa situação de indiferença.
• Menor do que a TMA: o investimento não é economicamente atrativo, pois seu retorno é superado pelo retorno de um investimento sem risco.

Entre vários investimentos, o melhor será aquele que tiver a maior TIR.

Método do Payback

O payback é um dos métodos mais simples e, talvez por isso, de utilização muito difundida. Consiste, essencialmente, em determinar o número de períodos necessários para recuperar o capital investido. Tendo essa avaliação, a administração da empresa, com base em seus padrões de tempo para recuperação do investimento, no tempo de vida esperado do ativo, nos riscos associados e em sua posição financeira, decide pela aceitação ou rejeição do projeto.

A forma mais fácil de calculá-lo é simplesmente acumulando as entradas e saídas e determinando o período em que houve a transição de um valor positivo para negativo.

Recomendações para análise de viabilidade econômica

Cada um dos indicadores financeiros resulta em informações diferentes, que podem ser utilizados de maneira complementar. O VPL é um método que fornece uma boa noção do montante que será obtido com o projeto, isto é, o valor que será captado, porém, ele não permite uma comparação fácil com outros investimentos. Esse aspecto é grande vantagem da informação obtida na TIR, que fornece um valor facilmente comparável. Mas existem projetos que retornam um bom montante (VPL altamente positivo) e rentáveis (TIR acima da taxa de atratividade) mas cujo período de retorno de investimento é longo, significando que a empresa terá de amargar um bom período de prejuízo até a obtenção do lucro. Portanto, sugerimos o cálculo desses três indicadores.

É importante destacar que todos os métodos anteriormente citados dependem de estimativas: da demanda do produto pelo mercado, sua expectativa de crescimento, do preço de venda do produto aceito pelo consumidor final, dos custos envolvidos na produção do produto, sendo essencial a participação e o comprometimento de diferentes partes da organização, principalmente do marketing, engenharias e vendas.

Lições aprendidas

Premissas para o cálculo da viabilidade
A definição das premissas é o ponto mais estratégico para se realizar a análise de viabilidade. As premissas englobam as previsões da demanda futura no tempo; o preço de se conseguirá praticar; o custo resultante da operação e basicamente as taxas que servirão de referência no futuro. Não é fácil prever todas essas informações e por isso são consideradas premissas para a análise.
Calcular o fluxo de caixa depois de todas essas definições “é mais fácil”.

Monitorar a viabilidade durante o desenvolvimento do produto
A análise da viabilidade econômica normalmente é realizada no início do desenvolvimento de produto e raramente é “revisitada”. Não tem sentido financeiro recalcular o investimento, pois o dinheiro gasto não volta mais. Porém, uma simulação de toda a análise, ajustando as premissas e verificando de novo os indicadores pode fornecer uma visão de quanto a empresa “acerta” nas suas previsões.

Monitorar a análise de viabilidade é importante para se tomar decisões (por exemplo, nos Gates) durante o desenvolvimento para saber se aquele produto / serviço ainda é viável ou não diante de possíveis mudanças das premissas (concorrente lançou algo similar primeiro e os volumes de venda não serão os mesmos; crises financeiras; mudanças nas taxas de referência; etc).

Ponderar a análise com possíveis riscos
Quando realizamos uma análise de viabilidade, partimos do pressuposto que todas as premissas adotadas estão corretas. Porém, existem riscos que vão além dessas premissas. Basicamente pode-se agrupar os riscos em duas categorias: riscos tecnológicos e riscos mercadológicos.
Os riscos da primeira categoria tratam de questões associadas à probabilidade de sucesso (ou fracasso) da tecnologia e soluções adotadas. Isso é mais importante de ser analisado no caso de inovação em tecnologia.
Os riscos mercadológicos consideram o sucesso (ou fracasso) que um produto / serviço pode ter no mercado.
Deve-se portanto ponderar esses riscos, assim como as premissas quando se realiza a análise de viabilidade dos projetos de desenvolvimento. Ou seja, aquele VPL calculado (por exemplo) só daria certo se existir riscos baixos.
Imagine a comparação de dois projetos de desenvolvimento. O primeiro com um VPL alto e o outro com VPL baixo. Qual deve ser priorizado? Depende do risco também. Se a probabilidade de sucesso do segundo for muito maior do que o primeiro, em uma análise de balanceamento do portfólio de projetos de desenvolvimento, pode ser que a segunda opção seja priorizada.

Go Horse (in memorian) - Atas de Reunião

Atas de reunião são instrumentos inúteis e estúpidos, artifícios dos quais os burocratas do PMI dependem para compensar a sua falta de pulso e a incapacidade da equipe.

Um dos argumentos utilizados por aqueles que defendem o uso de atas de reunião é a eliminação da ambiguidade, ou seja, a busca pelo comum entendimento. Tudo aquilo que fora discutido em reunião deve estar claro e acordado entre todas as partes.

Bullshit! Por que perder tempo editando documentos que apenas abrem brechas para que os horses fujam das suas responsabilidades? Atas de reunião são um erro em virtude das seguintes razões:

- Quem precisa de uma ata para que tudo fique claro é burro. Tem que entender tudo o que foi dito em reunião e fazer o maldito trabalho direito.

- Se algum peão quiser contestar algo, vale a palavra do chefe. Argumentos tais como “não foi isso que discutimos na reunião” podem ser facilmente rebatidos com frases de efeito como “cala a boca porque quem manda nessa porra sou eu”. Vale a palavra do chefe, e não uma ata idiota.

Atas são inúteis, o que vale é fazer o trabalho.

Go Horse (in memorian) - Gestão da Qualidade

“Porra, será que eu tenho que fazer tudo por aqui?”
Quantas vezes o seu gerente, ou mesmo você nesse papel, falou essa frase? Isso é necessário quando a equipe não faz as coisas direito. Os malas do PMI são cheios de frescura quanto à qualidade: planejam, planejam, planejam…

Para o Go Horse, qualidade é simples: tem que fazer direito a porra do trabalho!

Go Horse (in memorian) - Gestão de RH

O processo burocrático do PMI para gestão dos recursos humanos vai desde criar uma matriz de responsabilidades para o projeto, passando pelo recrutamento de profissionais que preencham as vagas requeridas, até o treinamento dos membros da equipe para que estejam aptos a exercer as suas tarefas.

Tudo isso é muito bonito, mas só funciona na teoria, em um mundo de fantasias. Em Neverland, talvez.

O Go Horse não perde tempo com esse monte de bobagens, pois, ao contrário do PMI, parte das premissas corretas:

- As pessoas são podres: em uma estrutura matricial, gerentes funcionais não liberam os seus recursos mais valiosos para projetos que não digam respeito a (apenas) suas respectivas áreas. Isso porque a preocupação de gerentes funcionais é mostrar resultado aos seus superiores a fim de serem promovidos um dia.

- Diretores executivos não liberam verba a rodo para treinamento: isso impactaria no bônus anual recebido por eles, e comprometeria o valor das diárias das suas viagens de negócios a Las Vegas.

Para o recrutamento de pessoal para um projeto, o Go Horse prega a utilização de apenas uma ferramenta: o sponsor poderoso. O gerente de projetos deve ter costas quentes para que seja apoiado no processo de recrutamento.

Além disso, as posições devem ser preenchidas apenas de acordo com a disponibilidade das pessoas. Fazer um estudo das competências de cada profissional, como sugere o PMI, é pura perda de tempo – um tempo precioso que poderia estar sendo dedicado ao trabalho de verdade.

O PMI diz que a equipe do projeto deve ser desenvolvida e treinada. O Go Horse diz: BULLSHIT! Treinamentos são caros e demandam tempo. Tem que tocar o barco e ir fazendo o trabalho! Se um membro da equipe não possui o conhecimento necessário para a execução das tarefas que lhe serão atribuídas, ele que se vire para estudar e aprender. Como o horário de trabalho deve ser usado para trabalho de verdade, esse aprendizado deve ser realizado FORA do horário. Horas extras que nunca serão pagas, ou seja, a empresa não será onerada. O estado de terror em que o funcionário se encontra não apenas faz com que ele não cobre as horas extras com o auto-estudo, como o faz sentir-se culpado pela sua ignorância.

Está provado: Go Horse é muito mais rápido, efetivo e barato!

Go Horse (in memorian) - Gestão do Escopo

Os burocratas do PMI inventaram um monte de baboseiras para gerir o escopo do projeto… WBS, declaração do escopo, blá, blá, blá…

O Go Horse não perde tempo com asneiras como essas, pois se preocupa com o fundamental: ganhar a conta do cliente.

Não adianta perder tempo com previsões e futurologia… tem que dizer para o cliente que tudo o que ele quer vai ser entregue no prazo que ele deseja – só assim se ganha a conta. Depois, se dá um jeito pra fazer tudo – basta jogar a bomba no colo da equipe do projeto.

O gerente de projetos Go Horse deve submeter a sua equipe a um estado permanente de terror, de modo que a mesma trabalhe horas extras para cumprir o escopo, não apenas sem reclamar, mas pensando que não faz nada além da obrigação.

Às vésperas da entrega do projeto, após várias madrugadas de trabalho (por parte da equipe, não do gerente, claro), entrega-se o escopo completo, mas nas coxas. Enquanto o cliente testa, o time segue corrigindo os erros que sabe que existem. Perda de tempo zero, sucesso total.

Go Horse (in memorian) - Gestão da Comunicação

A comunicação talvez seja a área de conhecimento que demandou dos burocratas do PMI a maior parcela de criatividade.

Comunicação deveria ser simples: vai lá e fala pro cara o que ele tem que fazer! Mas não: pessoas perderam seu tempo precioso produzindo páginas e páginas com instruções sobre como burocratizar aquilo que a humanidade faz desde os seus primórdios, que é comunicar-se.

Planejamento da comunicação, atas de reunião, relatórios de desempenho, blá, blá, blá… para quê tudo isso se basta passar a informação ao interessado?

O Go Horse acredita em duas ferramentas para comunicação:

- Capacidade de compreensão do ouvinte: para bom entendedor, meia palavra basta. O que dizer de uma palavra inteira? É só falar para o cara o que ele tem que fazer e pronto!

- Poder na estrutura hierárquica: se o ouvinte não faz a tarefa direito porque (diz que) não entendeu, ou que ninguém pediu nada daquilo para ele, basta usar a hierarquia. Palavra de chefe é a verdade, e ponto final. Isso acaba com qualquer ambigüidade.

Go Horse (in memorian) - Gestão dos Riscos

Tá com medinho?

Gerenciar riscos é para os covardes. Ou você acha que o Chuck Norris tem medo de assumir riscos? Winners assumem riscos, losers têm medinho deles.

Não precisa gerenciar os riscos, basta saber em quem pôr a culpa caso algo errado aconteça!

Go Horse (in memorian) - Gestão das Aquisições

Essa é uma área que os chatos do PMI se esforçaram para encher de inutilidades. Papéis, papéis, papéis, documentos inúteis…

O PMBOK propõe um processo burocratizado e custoso para realizar concorrência de fornecedores. Ora, para que tudo isso se um parente ou amigo seu pode fazer o trabalho terceirizado? Quem sabe, se você contratar a empresa de um parente, pode até levar um por fora!

É mais ou menos como fazem os políticos no Brasil: preenchem os cargos em seus gabinetes com suas esposas, filhos e afilhados, afinal de contas, quem pode ser mais confiável do que a família, não é mesmo?

Enquanto o PMI condiciona a decisão de fazer ou contratar um serviço à capacidade da empresa de executá-lo, o Go Horse vai pelo caminho inverso: condiciona a sua capacidade de realização à existência de um amigo que faça o serviço!

Go Horse (in memorian) - Gestão do Tempo

“Quando eu terminar”. Essa foi a resposta que Michelangelo deu ao Papa quando perguntado sobre quando ficaria pronta a pintura do teto da Capela Sistina. Sim, uma das maiores obras da humanidade foi realizada com a utilização do Go horse.

O PMI vem com esse papinho de estimar duração de tarefa. Mas como prever o futuro, não é mesmo? Ora, tem que ir fazendo a tarefa até que ela fique pronta.

No entanto, no papel de gerente, você deve impor um estado de terror em seus subordinados, perguntando constantemente quando a porra da tarefa será concluída. Como você sabe que futurologia não existe, e portanto o seu subordinado vai chutar uma data furada, é nele que você vai pôr a culpa pelo suposto “atraso”!

Go Horse (in memorian) - Ferramentas Inúteis da Administração – Diagrama de Ishikawa

Os burocratas do PMI e da Qualidade adoram desenhos, gráficos e várias outras inutilidades. Parece que eles sempre precisam de uma figura para entender um problema, e por isso perdem tempo fazendo gráficos ao invés de trabalhar de verdade.

Este post é o primeiro de uma série denominada “Ferramentas Inúteis da Administração”. Abordaremos as mais ridículas ferramentas de que os burocratas precisam para viver, começando pelo Diagrama de Ishikawa ou “Espinha de Peixe”, o qual é exibido na figura abaixo.

 

A ideia dessa ferramenta é auxiliar os burocratas na identificação das supostamente possíveis causas para um determinado problema. Primeiro, categorizam-se as mesmas para, em seguida, identificá-las. Uma vez que os fatores que podem vir a causar uma não-conformidade são encontrados, ações preventivas são tomadas.

Por que o Go Horse despreza tamanha bobagem?

Primeiro, pelo desperdício de tempo e dinheiro com reuniões inúteis para a identificação de causas que podem nem vir a ocorrer. Pior ainda: desperdício de tempo e dinheiro com ações preventivas. Para que gastar esforço com ações preventivas inúteis antes de o problema ocorrer? É muito mais prático ser reativo se o barco afundar.

Outro motivo pelo qual essa ferramenta não serve para nada é ilustrado abaixo. Para os burocratas do PMI entenderem, criamos um diagrama que ilustra a única possível causa de um problema.

Se o barco afundar, a culpa é do peão que fez o trabalho. É ele o responsável pela qualidade, é ele quem deve resolver o problema. Ao invés de propor que especialistas importantes para a empresa desperdicem tempo em reuniões inúteis de qualidade, o Go Horse prega uma maneira muito mais barata: jogar nas costas do horse a tarefa de resolver o problema após a sua ocorrência.

Certamente seu chefe já lhe disse algo como “quero que você resolva o problema, não importa como”, ou simplesmente “se fode, baixa a cabeça e faz essa merda”. Isso é o mais puro e eficiente Go Horse.

Viva o GHP, a única metodologia capaz de viabilizar o trabalho sem burocracia.

Go Horse (in memorian) - Gestão dos Custos

Os burocratas do PMI inventaram um monte de baboseiras para gerir o custo do projeto. O Go Horse, por outro lado,  não perde tempo com asneiras como essas, pois se preocupa com o fundamental: fazer com que o projeto seja aprovado e suportado pela gerência.

Todos sabemos que as empresas não têm capital suficiente para realizar todos os projetos que gostaria. Cabe à gerência, portanto, escolher o projeto em que a empresa irá investir.

Projeto escolhido é projeto de visibilidade, o que traz prestígio. Qualquer gerente de projetos Go Horse que se preze busca prestígio incondicionalmente, e para isso deve estimar como custo total do projeto um valor que convença a gerência a escolher o seu projeto.

Ao longo da execução do projeto, é provável que o seu custo real ultrapasse o estimado. O Go Horse prega a filosofia de seguir trabalhando e pedir dinheiro à gerência à medida que for necessário. Para isso, a ótima metodologia GHP propõe as seguintes ferramentas para obter as verbas extras necessárias:

- Culpar a equipe por um suposto mau desempenho
- Culpar o cliente por sucessivas mudanças
- Enfatizar como o projeto é vital e não pode prescindir de aporte de verbas
- Citar a ocorrência de eventos imprevistos

Ao final do projeto, é provável que o custo final seja superior ao estimado. Mas não se perdeu tempo planejando custos e estimando riscos. Sucesso total, perda de tempo zero, prestígio ao gerente de projetos.

Go Horse (in memorian) - eXtreme Go Horse (XGH)

1- Pensou, não é XGH.
XGH não pensa, faz a primeira coisa que vem à mente. Não existe segunda opção, a única opção é a mais rápida.

2- Existem 3 formas de se resolver um problema, a correta, a errada e a XGH, que é igual à errada, só que mais rápida.
XGH é mais rápido que qualquer metodologia de desenvolvimento de software que você conhece (Vide Axioma 14).

3- Quanto mais XGH você faz, mais precisará fazer.
Para cada problema resolvido usando XGH, mais uns 7 são criados. Mas todos eles serão resolvidos da forma XGH. XGH tende ao infinito.

4- XGH é totalmente reativo.
Os erros só existem quando aparecem.

5- XGH vale tudo, só não vale dar o toba.
Resolveu o problema? Compilou? Commit e era isso.

6- Commit sempre antes de update.
Se der merda, a sua parte estará sempre correta.. e seus colegas que se fodam.

7- XGH não tem prazo.
Os prazos passados pelo seu cliente são meros detalhes. Você SEMPRE conseguirá implementar TUDO no tempo necessário (nem que isso implique em acessar o BD por um script malaco).

8- Esteja preparado para pular fora quando o barco começar a afundar… ou coloque a culpa em alguém ou algo.
Pra quem usa XGH, um dia o barco afunda. Quanto mais o tempo passa, mais o sistema vira um monstro. O dia que a casa cair, é melhor seu curriculum estar cadastrado na APInfo, ou ter algo pra colocar a culpa.

9- Seja autêntico, XGH não respeita padrões.
Escreva o código como você bem entender, se resolver o problema, commit e era isso.

10- Não existe refactoring, apenas rework.
Se der merda, refaça um XGH rápido que solucione o problema. O dia que o rework implicar em reescrever a aplicação toda, pule fora, o barco irá afundar (Vide Axioma 8).

11- XGH é totalmente anárquico.
A figura de um gerente de projeto é totalmente descartável. Não tem dono, cada um faz o que quiser na hora que os problemas e requisitos vão surgindo (Vide Axioma 4).

12- Se iluda sempre com promessas de melhorias.
Colocar TODO no código como uma promessa de melhoria ajuda o desenvolvedor XGH a não sentir remorso ou culpa pela cagada que fez. É claro que o refactoring nunca será feito (Vide Axioma 10).

13- XGH é absoluto, não se prende à coisas relativas.
Prazo e custo são absolutos, qualidade é totalmente relativa. Jamais pense na qualidade e sim no menor tempo que a solução será implementada, aliás… não pense, faça!

14- XGH é atemporal.
Scrum, XP… tudo isso é modinha. O XGH não se prende às modinhas do momento, isso é coisa de viado. XGH sempre foi e sempre será usado por aqueles que desprezam a qualidade.

15- XGH nem sempre é POG.
Muitas POG’s exigem um raciocínio muito elevado, XGH não raciocina (Vide Axioma 1).

16- Não tente remar contra a maré.
Caso seus colegas de trabalho usam XGH para programar e você é um coxinha que gosta de fazer as coisas certinhas, esqueça! Pra cada Design Pattern que você usa corretamente, seus colegas gerarão 10 vezes mais código podre usando XGH.

17- O XGH não é perigoso até surgir um pouco de ordem.
Este axioma é muito complexo, mas sugere que o projeto utilizando XGH está em meio ao caos. Não tente por ordem no XGH (Vide Axioma 16), é inútil e você pode jogar um tempo precioso no lixo. Isto fará com que o projeto afunde mais rápido ainda (Vide Axioma 8). Não tente gerenciar o XGH, ele é auto suficiente (Vide Axioma 11), assim como o caos.

18- O XGH é seu brother, mas é vingativo.
Enquanto você quiser, o XGH sempre estará do seu lado. Mas cuidado, não o abandone. Se começar um sistema utilizando XGH e abandoná-lo para utilizar uma metodologia da moda, você estará fudido. O XGH não permite refactoring (vide axioma 10), e seu novo sistema cheio de frescurites entrará em colapso. E nessa hora, somente o XGH poderá salvá-lo.

19- Se tiver funcionando, não rela a mão.
Nunca altere, e muito menos questione um código funcionando. Isso é perda de tempo, mesmo porque refactoring não existe (Vide Axioma 10). Tempo é a engrenagem que move o XGH e qualidade é um detalhe desprezível.

20- Teste é para os fracos.
Se você meteu a mão num sistema XGH, é melhor saber o que está fazendo. E se você sabe o que está fazendo, vai testar pra que? Testes são desperdício de tempo, se o código compilar, é o suficiente.

21- Acostume-se ao sentimento de fracasso iminente.
O fracasso e o sucesso andam sempre de mãos dadas, e no XGH não é diferente. As pessoas costumam achar que as chances do projeto fracassar utilizando XGH são sempre maiores do que ele ser bem sucedido. Mas sucesso e fracasso são uma questão de ponto de vista. O projeto foi por água abaixo mas você aprendeu algo? Então pra você foi um sucesso!

22- O problema só é seu quando seu nome está no Doc da classe.
Nunca ponha a mão numa classe cujo autor não é você. Caso um membro da equipe morra ou fique doente por muito tempo, o barco irá afundar! Nesse caso, utilize o Axioma 8.

Go Horse (in memorian) - FAQ

P: Qual a duração ideal de um ciclo de desenvolvimento usando go horse?
R: O ciclo inicia no começo, e se encerra quando o trabalho termina.

P: Na metodologia que eu uso atualmente, devo escrever documentação. Porém, sempre que há um problema ou duvida, o usuário me liga e pergunta como se faz. O GHP resolve isso?
R: Sim. Há uma extensa bibliografia sobre o assunto, mas o Go Horse recomenda a metodologia RTFM.

P: Quais as principais KPIs para a medição da performance do GHP? Por exemplo, KRPM (Krash Report Per Minute)?
R: KPIs são perda de tempo. Tem é que ir fazendo o trabalho.

P: Já foi considerada a aplicação de LEAN na metodologia GHP? Por exemplo, poderíamos eliminar o Horse, uma vez que não adiciona valor ao cliente?
R: O LEAN é derivado do Go Horse. Na verdade, trata-se da adição de um monte de bullshit ao Go Horse original, resultando em uma metodologia inútil.
Por fim, eliminar aquele simpático cavalinho do logo não é uma opção.

P: Como é feita a atualização de software usando GHP?
R: Atualizando.

P: Sou um gerente de projetos certificado pelo PMI. Por que devo abandonar as práticas propostas pelo PMBOK e adotar o Go Horse?
R: Por um motivo muito simples: em um projeto gerenciado com as práticas do PMI, quem leva a culpa se o projeto dá errado? O gerente. E quem leva os louros se dá certo? A equipe.

O Go Horse prega o não-planejamento, e se não há planejamento não há motivos pelos quais culpar o gerente. Com o Go Horse, tem-se a situação oposta: o gerente leva sozinho os louros da vitória, ao passo que a equipe leva a culpa se o projeto falhar. Não é perfeito?

P: Existe a possibilidade de desenvolver uma carreira promissora como um gerente de projetos Go Horse?
R: Sim! A maioria das organizações usa o Go Horse. Mas cuidado: para ser bem sucedido na carreira, não tente adotar Go Horse em uma organização que aplica o blá blá blá do PMI.

Veja este exemplo REAL: Um certo gerente de uma certa empresa encontrou alguns problemas durante um projeto. Para resolvê-los, aplicou todas as técnicas do Go Horse: Pediu mais verbas ao chefe quando o dinheiro acabou (em torno de 50%), mais prazo (11 meses), enrolou os superiores quanto ao escopo, e entregou o projeto. O que aconteceria com esse gerente em uma empresa dominada pelos malas do PMI? Seria demitido. No entanto, como o Go Horse era a prática adotada pela organização, esse gerente virou diretor!

P: Qual a metodologia mais eficiente? Go Horse ou PMBOK?
R: Ora, essa é fácil: Go Horse, claro! Mais da metade dos projetos gerenciados com as técnicas propostas pelos burocratas do PMI falham – isto porque o PMBOK diz que um projeto só é bem sucedido quando entregue dentro do prazo, cumprindo o escopo e respeitando as restrições orçamentárias.

O Go Horse, por outro lado, é contrário a esse monte de regras. Como a idéia é ir fazendo o projeto – tocar o barco – pedir dinheiro à medida em que é preciso e fazer o escopo que der na telha ao longo do projeto, nunca vai haver falha, já que não se perde tempo com planejamento. Ou seja, para o Go Horse, projeto de sucesso é projeto entregue! Não é fantástico?

P: Existe prova de certificação Go Horse?
R: Hein?

P: O PMI tem o seu código de ética. E o Go Horse?
R: O Go Horse também. Leia “As 48 leis do Poder”, de Robert Greene e Jost Elffers.

P: Como faço para descobrir se minha empresa usa Go Horse?
R: Se você não sabe qual a metodologia utilizada pela sua empresa, então com certeza ela usa Go Horse.

Qualidade Segundo o Go Horse

Fatos Sobre Qualidade

No mundo corporativo, a palavra qualidade é abreviada utilizando-se tão-somente a letra “Q”, e isto vale para os principais idiomas ocidentais. Em inglês, tal letra chama-se “kiú”. No alemão, espanhol e italiano, lê-se “ku”. Seria este carinhoso apelido mera coincidência?

Qualidade é, resumidamente, um baixo número de eventos de não-conformidade. Produtos ou serviços que não seguem suas respectivas especificações têm baixa qualidade. Qualidade é diferente de “grau”: tanto um Gol quanto uma Ferrari podem possuir o mesmo nível de qualidade.

Garantia e Controle de Qualidade

Peço desculpas aos conhecedores do tema, mas devo expor aqui dois conceitos básicos fundamentais para que todos possam compreender este texto: garantia de qualidade e controle de qualidade.

• Garantia de qualidade: é o processo de “melhoria contínua”. Se é processo, nunca termina. Empresas mantêm equipes dedicadas à otimização de processos que visam reduzir o número de produtos que apresentam não-conformidade.
• Controle de qualidade: é a implementação dos processos definidos pela garantia da qualidade. O controle de qualidade é aplicado diretamente ao produto ou serviço desenvolvido.

Qualidade: Go Horse vs. Burocratas

Os burocratas do PMI e de outras metodologias furadas gastam fortunas com qualidade, pois empresas que utilizam tais metodologias adotam como valor o tal “foco no cliente”. Isto é o estado-da-arte do bullshit e da estupidez, uma grande imbecilidade: o correto é focar na grana, nos acionistas, nos diretores e seus respectivos compadres e afilhados. Para isso servem as empresas. Funcionários devem ser constantemente chicoteados a fim de manter o crescente enriquecimento da casta mais alta – o resto é conversa furada.

Comparemos as abordagens do Go Horse e do PMI para um mesmo projeto fictício. A estimativa PMI de custos é mais alta, e uma das razões disso é a necessidade de embutir, no custo do projeto, o dispendioso processo de controle de qualidade. No gráfico abaixo, vemos isso claramente:

Em amarelo, o custo do controle de qualidade

Podemos observar que o Go Horse também requer gasto com controle de qualidade, porém um gasto infinitamente menor. Como isso é possível? Mágica? Não: com Go Horse simplesmente não há equipe de controle de qualidade. Os próprios membros do time de projeto devem ser responsáveis pela qualidade. Além de ser uma abordagem muito mais barata, atribuir a responsabilidade pela qualidade sobre os ombros da equipe do projeto facilita a identificação de culpados caso algo dê errado.

Paralelamente aos custos do projeto, a turma do PMI arca com o custo da garantia de qualidade: um custo que tende ao infinito! O Go Horse não admite tal baboseira, o que torna a diferença de custos entre as duas escolas ainda mais discrepante, conforme podemos observar na figura abaixo:

Em laranja, o custo da garantia de qualidade

Ao analisar o gráfico acima, os burocratas do PMI se regozijam, atingem o êxtase. Eles bradam que, uma vez que Go Horse não possui um processo formal de controle de qualidade, o número de defeitos será infinitamente maior, fazendo com que a empresa sofra as consequências que isso implica. Mas eles estão totalmente enganados, pois com Go Horse existe sim controle de qualidade. A diferença é que ele é feito pelo próprio cliente!

Ao receber o produto ou serviço, o cliente inicia o processo de validação. Ele inevitavelmente encontra erros, defeitos, não-conformidades, e os reporta. O time de projeto Go Horse os resolve. Isso teria de ser feito de qualquer maneira, mas o ônus de testar a entrega é do cliente!

A conclusão disso tudo é que o sucesso só pode ser atingido com Go Horse: com uma cotação mais baixa, ganhamos a conta do cliente, que paga pelo controle de qualidade assim como o faria em um projeto PMI.

Lembre-se, burocrata do PMI: o importante é ganhar a conta!

• Email
• Facebook

Se qualidade fosse bom não começaria com “Qu”

Follow-up do Estudo de Caso

Estudo de Caso – Com Go Horse é Mais Barato

Em um dia desses encontrei um velho amigo e colega de Gerência de Projetos, cuja identidade não revelarei. Apesar de ser um grande amigo, tenho uma certa restrição quanto a este profissional: ele é um burocrata do PMI. Tomamos um café e trocamos algumas idéias sobre Gerenciamento de Projetos.
Ele me relatava a sua experiência com a utilização das tais “melhores práticas” – dizia como sua gestão era efetiva e como minimizava os custos do projeto através da aplicação do PMBOK. Obviamente eu não comprei aquele monte de baboseiras que ele dizia, e tentei argumentar – em vão – que o Go Horse é mais efetivo não apenas na redução dos custos do projeto, mas como um todo.
Ele me dizia: “Projetos Go Horse geram retrabalho, ou seja, custos imprevistos”. Dizia também: “só acredito se você me mostrar um estudo de caso”. É incrível a obsessão que esse pessoal do PMI tem por papéis, documentos e formalidades.
Tomemos um projeto qualquer como exemplo. Para a estimativa de custos, os burocratas do PMI planejam, planejam, planejam… o Go Horse, ao contrário, faz uma estimativa de custos imediata – leia o estudo Go Horse sobre Gestão de Custos.
A estimativa de custos Go Horse, via de regra, é 20% mais baixa do que uma estimativa PMI. Isso porque, no caso do PMBOK, todo o custo do overhead de planejamento está embutido no custo do projeto – incluindo a burocrática e penosa análise de riscos.

Estimativa Go Horse vs. estimativa PMI

Imagine se as duas estimativas acima competem por uma conta de cliente. Obviamente o fornecedor Go Horse vence, pois ele não perdeu tempo planejando e, consequentemente, não aumentou o custo do projeto por causa disso.
Quando o projeto chega próximo ao seu final, olhamos para trás e percebemos que as coisas não saíram conforme o planejado.
Elas nunca saem, e justamente por isso o Go Horse despreza o planejamento. No caso de um projeto gerenciado com as técnicas burocráticas do PMI, o estouro de orçamento tende a ser menor do que o Go Horse: de 5 a 10%.

Estouro de orçamento PMI

Com Go Horse, o estouro de orçamento é bem maior, como podemos observar na figura abaixo. Esse fato leva os malas do PMI ao êxtase. Eles dizem: “Viram como tínhamos razão? Estouraram o orçamento! Expliquem ao cliente agora!”

Estouro de orçamento Go Horse

A questão é que, como disse o meu nobre colega burocrata do PMI, Go Horse gera retrabalho. Em síntese, todo o custo extra que vemos na figura acima é retrabalho. Agora jogamos um balde de água fria nos chatos do PMI. Dizemos a eles: “Leiam o que o Go Horse diz sobre a Gestão do Escopo!”.
Não permitimos que a equipe estoure o prazo – ao contrário, a submetemos a um estado permanente de terror, forçando-a a realizar horas extras. Ou seja, todo o retrabalho que gerou o custo extra representado na figura acima foi realizado através de horas extras.
Agora eu pergunto:
- A sua empresa paga horas extras?
- Existe alguma empresa que pague horas extras de projeto?
- Algum funcionário aceita servir de mártir, sacrificar sua carreira e chances no mercado, apenas para processar a empresa?
Nenhuma empresa esperta paga horas extras. Em um projeto Go Horse, o custo do retrabalho some como mágica!

Horas extras nunca são pagas!

Está provado: com Go Horse é mais barato!

Mecanismos de Defesa

Sublimação:
Os impulsos originais são redirecionados para outros com o objetivo de reduzir a ansiedade e o conflito que a situação poderia causar. Ex: um casal não pode ter filhos então compra um cachorro.


Racionalização:
O indivíduo tenta inconscientemente justificar com explicações lógicas uma atitude questionável.


Repressão:
É a operação psíquica que tenta fazer desaparecer da consciência, impulsos ameaçadores, sentimentos, desejos, conteúdos desagradáveis, ou inoportunos.
Este conteúdo reprimido no entanto, não é eliminado e continua no inconsciente. O resultado seriam algumas doenças psicossomáticas que poderiam estar vinculadas à essa repressão (Ex. asma, artrite, frigidez, etc).


Projeção:
O indivíduo coloca no outro, sentimentos, desejos ou idéias que são dele próprio. Esse mecanismo ajudaria então a lidar de uma maneira mais fácil com esses sentimentos. A dificuldade em admitir determinadas "falhas" em nossa personalidade seria projetada no outro.


Identificação:
O indivíduo assimila alguma característica ou aspecto de outra pessoa, se transformando total ou parcialmente, adotando-a como modelo.


Deslocamento:
É um processo psíquico através do qual o todo é representado por uma parte ou vice-versa.Também pode ser uma idéia representada por uma outra, que, emocionalmente, esteja associada à ela. Ex.: Ao invés de agredir a uma determinada pessoa, a agressão é direcionada à outra, talvez mais fácil de se atingir.


Formação Reativa:
É um processo psíquico que se caracteriza pela adoção de uma atitude de sentido oposto a um desejo que tenha sido recalcado, constituindo-se então, numa reação contra ele. Uma definição: é o processo psíquico, por meio do qual um impulso indesejável é mantido inconsciente, por conta de uma forte adesão ao seu contrário. Ex.: Uma pessoa rígida em relação à moral ou sexualidade, pode estar ocultando seu lado permissivo e imoral.


Negação:
Quando ocorre algo que nos incomode profundamente, há a tendencia a não aceitar esse ocorrido, ou lembrá-lo de modo incorreto. Podemos fantasiar também o que houve na tentativa de distorcer e minimizar assim, o impacto do evento.


Regressão:
Quando a pessoa, vivendo uma fase difícil, retorna à atitudes anteriores. O indivíduo busca uma situação ou comportamento mais infantil. A criança pode voltar a esse estágio quando nasce um irmãozinho, voltando à chupeta ou à mamadeira.


Introjeção:
O indivíduo toma para si características de outra pessoa ou de seus ídolos.


Isolamento:
É um processo psíquico típico da neurose obsessiva, que consiste em isolar um comportamento ou um pensamento de tal maneira que as suas ligações com os outros pensamentos, ou com o autoconhecimento, ficam absolutamente interrompidas (completamente excluídos do consciente).


Substituição:
Processo pelo qual um objeto valorizado emocionalmente, mas que não pode ser possuído, é inconscientemente substituído por outro, que geralmente se assemelha ao proibido. É uma forma de deslocamento.


Fantasia:
É um processo psíquico em que o indivíduo concebe uma situação em sua mente, que satisfaz a uma necessidade ou desejo, que não pode ser, na vida real, satisfeito.


Compensação:
É o processo psíquico em que o indivíduo se compensa por alguma deficiência, pela imagem que tem de si próprio, por meio de um outro aspecto que o caracterize, que ele então passa a considerar como um trunfo.


Expiação:
É o processo psíquico em que o indivíduo quer pagar pelo seu erro imediatamente.


Quem se interessar no assunto e quiser saber mais detalhes ver o link abaixo:

http://fundamentosfreud.vilabol.uol.com.br/mecanismosdedefesa.html


BIBLIOGRAFIA
FENICHEL,O., Teoria Psicanalítica das Neuroses.Atheneu.2000
GREENSON,R.R., A Técnica e a Prática da Psicanálise. Imago.RJ. 1981
LAPLANCHE & PONTALIS. Vocabulário de Psicanálise (2000), Martins Fontes S.P.
CARVALHO, UYRATAN . Psicanálise I . Isbn.RJ.2000
HENRY EY. Manual de Psiquiatria.5º Edição. Masson/Atheneu

Segurança x Liberdade

Nascemos. Um bebê vem ao mundo com a sua mente pura e límpida. Sua sobrevivência depende exclusivamente da mãe e de seus instintos básicos. Desde os primeiros dias de vida observa-se que o bebê é puro amor, carinho e alegria, sua mente é totalmente livre e sem medo de demonstrar sentimentos.

Crescemos. Com o passar dos anos o bebê torna-se uma criança. Aprende a falar, e começa a compreender o mundo que o cerca.

Desde cedo, a criança é educada e preparada para sobreviver e subsistir no mundo que a espera. Na sociedade ocidental geralmente aprende-se que para vencer na vida é necessário ganhar dinheiro, ser um homem de poderes e de sucesso, para assim poder conquistar os bens que aspira.

Sem perceber, aquele amor e alegria que com ele nasce começam a apagar-se, substituídos pela insaciável e infindável ambição por conquistas materiais. A liberdade de viver e pensar inerente ao ser humano começa a desaparecer gradativamente à medida que o indivíduo vai entregando-se à missão a que foi incumbido, adaptando-se ao modelo de vida projetado pelos mentores da sociedade contemporânea para a garantia da sua continuidade.

Embora para nós hoje em dia pareça ser tudo muito óbvio, correto e natural, os conceitos associados ao modelo desta sociedade à que somos submetidos divergem dos instintos naturais e elementares do ser humano.

A natureza animal aliada à complexa mente humana nos fornece instintos de sobrevivência. Como os bens materiais são limitados, o homem passa a disputar os recursos existentes com os seus semelhantes. O processo de adaptação à este modelo e o tipo de vida ao qual muitas pessoas acabam submetidas podem levar a seqüelas, muitas vezes originadas através de mecanismos de defesa desenvolvidos em suas mentes. Podemos citar alguns exemplos tais como o tédio, a depressão, a violência, diversos transtornos psicanalíticos, entre outros.

Com os problemas acima sem solução, e como a sociedade precisa ser preservada, tornou-se necessária a criação de instituições com o objetivo de reprimir as ações de indivíduos que apresentem conduta em desacordo com o modelo, limitando cada vez mais a liberdade da população como um todo.

Aproveitando este contexto, os líderes passam a criar mecanismos de repressão e punição que ao invés de procurar simplesmente educar a população, estabelecem multas cuja finalidade principal é inflar os cofres públicos. Com mais recursos disponíveis, o líderes têm a possibilidade de desenvolver mais projetos, e por conseguinte criar mecanismos que direta ou indiretamente os tragam vantagens pessoais.

A conclusão deste tema não é simplória, mas cabe uma breve reflexão:

O homem vive em um contexto contrário à sua natureza, mas é forçado a adaptar-se a ele.
Este modelo priva-o de sua liberdade essencial a qual lhe foi concedida ao nascer.
A perda da liberdade leva o homem ao sofrimento, consciente ou inconsciente, ou mesmo a contrair problemas psíquicos.
A subsistência da sociedade depende da submissão de todos às suas regras.
Os governantes aproveitam-se do poder para definirem leis mascaradas por objetivos de dar maior segurança ao povo, mas cujos verdadeiros fins são gerar benefícios próprios, através de mecanismos de punição e multagem à população.

“Anyone who trades liberty for security deserves neither liberty nor security.”
~Benjamin Franklin

Fonte: http://jbjorge.blogspot.com/

A Matrix (parte 1 e 2)

These are some additional server configuration settings:

C2 Audit Mode: Configures the server to record both failed and successful attempts to access statements and objects.

Fill Factor: Specifies how full SQL Server 2008 should make each page when it creates a new index using existing data.

Min and Max Server Memory: Reconfigures the amount of memory (in megabytes) in the buffer pool used by an instance of SQL Server.

Nested triggers: Controls whether an AFTER trigger can cascade; that is, perform an action that initiates another trigger, which initiates another trigger, and so on.

Query Governor Cost Limit: Specifies an upper limit on the time period in which a query can run.

Query Wait: Specifies the time in seconds (from 0 through 2147483647) that a query waits for resources before timing out. If the default value of -1 is used, the time-out is calculated as 25 times the estimated query cost.

CLR Integration: Supplies managed code with services such as cross-language integration, code access security, object lifetime management, and debugging and profiling support.

O método DMAIC

Para Blauth (2003), Pande et al. (2001) e Werkema (2002), os cinco passos para a execução de trabalhos sob a filosofia six sigma são estabelecidos pelo ciclo DMAIC descrito a seguir.

D – Define (Definir): Nesta etapa é necessário definir com precisão as necessidades e desejos dos clientes. Transformar essas necessidades e desejos em especificações do processo, considerando a disponibilidade de fornecimento de insumos, a capacidade produtiva e o posicionamento do serviço ou produto no mercado, tendo em conta as ofertas dos concorrentes.

M – Measure (Medir): Nesta etapa é necessário medir com precisão o desempenho de cada etapa do processo, identificando os pontos críticos e passíveis de melhoria. Todas as vezes ocorrem defeitos no processo ocorrem gastos adicionais de recursos para repor o nível de produção, insumos, tempo, mão-de-obra para executar a atividade. Esses custos precisam ser mensurados.

A – Analyse (Analisar): Analisar os resultados das medições permite identificar as “lacunas”, ou seja, determinar o que falta nos processos para atender e encantar os clientes. A busca da
causa-raiz dos problemas leva ao desenvolvimento de hipóteses e à formulação de experimentos, visando à eficácia dos processos. Para realizar as melhorias nos processos são elaborados projetos ou planos de ação acompanhados de cronogramas, dimensionamento de recursos necessários, custos e retorno do investimento.

I – Improve (Implementar): O sucesso da implementação das melhorias está relacionado com a forma de venda do plano às pessoas, que deve contemplar a demonstração das vantagens que a mudança vai trazer e, sempre que possível, aproveitar suas contribuições na forma de operacionalizar a estratégia.

C – Control (Controlar): O estabelecimento de um sistema permanente de avaliação e controle é fundamental para garantia da qualidade alcançada e identificação de desvios ou novos problemas, os quais devem exigir ações corretivas e padronizações de procedimentos.

MASP – Método de Análise e Solução de Problemas

O MASP é uma ferramenta sistêmica de abordar situações que podem exigir tomada de decisão devido a uma situação insatisfatória, um desvio do padrão de desempenho esperado ou de um objetivo estabelecido, reconhecendo a necessidade de correção, seguindo alternativas de ação. Estas situações são tratadas utilizando ferramentas da qualidade de uma maneira seqüencial e padronizadas, com o ciclo de definição, analise, melhoria, padronização e controle do problema (ARIOLI, 1998). A finalidade do MASP é resolver problemas, obtendo resultados em curto prazo, onde o trabalho em equipe é fundamental para o sucesso do método, englobando:

Fases de implementação do MASP

1. Identificação do problema: Definir claramente o problema e reconhecer sua importância;

2. Observação: Investigar as características específicas do problema com uma visão ampla e sob vários pontos de vista;

3. Análise: Descobrir as causas fundamentais;

4. Plano de Ação: Conceber um plano para bloquear as causas fundamentais;

5. Execução: Bloquear as causas fundamentais;

6. Verificação: Verificar se o bloqueio foi efetivo;

7. Padronização: Evitar o reaparecimento do problema;

8. Conclusão: Recapitular todo o processo de solução do problema, registrando-o para aproveitamento em trabalhos futuros.

Bill Hicks - It's Just a Ride

Options for Installing Components

Comparing Licensing of SQL Server 2008

Editions of SQL Server 2008

Eu não era nem um espermatozoide quando isso foi escrito

Porque o mundo não produz mais arte desse jeito?

Pink Floyd - Vera & Bring the boys back home

Gilmour, Mason e Waters tocam juntos em Londres a

Money is Debt