Unter der Rubrik Klartext / Forum schreibt Dr. phil. Guido Wolf,  M.A., dass William Edwards Deming ursprünglich einen PDSA-Zyklus zur Entwicklung von Produkten und nicht zur Verbesserung von Prozessen erarbeitet hat:

• Plan a change or a test, aimed at improvement
• Do - Carry out the change or the test (preferably on a small scale)
• Study the results. What did we learn? What went wrong?
• Act – Adopt the change, or abandon it, or run through the cycle again

Diesen Zyklus benannte er nach seinem Lehrer Walter A. Shewhart Shewhart-Cycle.

In der Folge haben japanische Manager den PDCA-Zyklus daraus entwickelt. Wobei v.a. das Act nicht mehr so recht passt: positive Ergebnisse beim Check machen einen erneuten Durchlauf unnötig und v.a. fehlt durch das Check (statt dem ursprünglichen Study) das Lernen  wie es bei Deming noch Teil des Study war.

Der Autor schlägt daher den PDSL-Zyklus vor, der statt dem Act ein Learn vorsieht:

• Plan – die Veränderung an Produkt, Prozess, Struktur etc. sorgfältig planen
• Do - die Veränderung wie geplant durchführen
• Check – die Veränderung durch Messungen, Tests, Audits etc. prüfen
• Learn -die Prüfergebnisse auswerten die Erkenntnisse ableiten.

Soweit zu dem Artikel in Kurzform.

Im Quality Improvement Paradigm (kurz QIP), das von Victor Basili entwickelt wurde,  ist dieser Mangel schon lange behoben. Lernen ist hier Teil von Erfahrung aufbereiten, zudem ist hier vor allem das Lernen in der Organisation durch eine Experience Factory (Erfahrungsdatenbank) sytematisiert . Dieser Zyklus ist deutlich praxisnäher, weil er u.a.

• die Standortbestimmung als eigenen Schritt sieht,
• in der Planung die Bestimmung der Ziele betont – siehe dazu  Goal-Question-Metric (GQM) und
• einen zusätzlichen Mini-Zyklus in der Pilotierung enthält.

QIP bestimmt das Handeln in allen Projekten, die die Mitarbeiterinnen und Mitarbeiter von Maud Schlich IT-PROJECT-SERVICE durchführen.

Beispiel für QIP im Kleinen:

• Standort bestimmen – Auswertung einer Metrik, z.B. “Fehlerrate im Abnahmetest liegt aktuell bei 35 Fehlern der Kategorie A”
• Ziele definieren – “Absenkung der Fehlerrate im Abnahmetest auf maximal 5 Fehler der Kategorie A durch Verbesserung des Systemtests”
• Prozesse, Methoden, Techniken auswählen – Schulung der Sytemtester zum Certified Tester Foundation Level, Schulung der Testmanagerin zum Certified Tester Advanced Level Test Analyst und Testmanager, Einführung von systematischen Testfallentwurfstechniken mit Hife von Coaching der Testmanagerin durch einen fachlichen Coach
• Pilotieren – Anwendung der neuen Testfallentwurfstechniken im Pilotprojekt (in mehreren Iterationsschritten)
• Ergebnisse analysieren – Prüfung, welche Testfallentwurfstechnik welche Fehler aufdeckt mit welchen Raten und in welchen Teststufen
• Erfahrungen aufbereiten – Dokumentation der Lessons Learned aus dem Piloten und Überarbeitung der Testpolitik / Qualitätspolitik

Beispiel für QIP im Großen:

• Standort bestimmen – Durch eine vollständiges Assessment
• Ziele definieren – Planung des Verbesserungsprojektes
• Prozesse, Methoden, Techniken auswählen – entsprechend der Planung des Verbesserungsprojektes
• Pilotieren – Anwendung jeweils einzelner Prozessverbesserungen in Piloten
• Ergebnisse analysieren – Prüfung der Wirksamkeit der Verbesserungen und der Eignung für alle Projektarten
• Erfahrungen aufbereiten – Umsetzung der Lessons Learned in der Prozessmodellierung und Nutzbarmachen der Erfahrungen bzgl. Durchführung von Verbesserungsprojekten für die nächsten Schritte

QIP ist also für kleine und große Vorhaben gleichermaßen gut geeignet. Auch für sehr kleine Vorhaben lässt sich QIP bestens anwenden – dann können die ersten drei Schritte evtl. auch nur in wenigen Stichpunkten beschrieben sein oder auch nur im Kopf durchgeführt werden (bei Ein-Personen-Vorhaben).

Probieren Sie es doch einmal aus und schreiben Sie einen Kommentar zu Ihren Erfahrungen.

Have you ever heard the old saying, “Behind every great problem statement is a great goal statement?” Probably not…

Goal statements rarely get the attention that the problem statement or root causes receive. They just kind of hang out like some fleeting after thought. More often than not, they’re reduced to fragmented sentences scribbled on the PDCA form before we move on.

But the goal statement is, arguably, the MOST CRITICAL component of the PDCA. We just don’t realize it because we don’t understand what its job is. So, here’s a job description for the goal statement.

1. The goal statement is the whole point of the PDCA. Yes, you want to solve a problem. But unless you’re a detective — or possibly some kind of super hero — your job isn’t to just solve problems. You’re trying to accomplish something, be that to make more sales or to reduce cycle time or meet a deadline. But there’s an obstacle keeping you from achieving that goal. Thus the point of the PDCA and the importance of the goal statement.

2. The goal statement is the PDCA’s compass. It sets the direction for the problem statement and the following causes and counter measures.  Without a clear direction, the PDCA can mire down in  data collection or steer off course during the cause & effect analysis. Have you ever had a PDCA that just seemed to linger on for months without ever really getting anywhere? Or have you ever seen a PDCA with counter measures that have nothing to do with the original problem?

3. The goal statement tests the validity of the problem statement. A strong goal statement is practically a mirror image of the problem statement – they are twin sentences with a few minor word differences. If they aren’t, there’s a problem with the problem statement. And, the PDCA isn’t ready to move on to the point of cause yet.

4. The goal statement supports the reason for the counter measures. It must be clear that these actions will eliminate the root causes allowing you to achieve the goal. But if the counter measures aren’t moving you toward achieving the goal statement, you know the PDCA went off course.

5. The goal statement measures the success of the PDCA. When you follow-up on the counter measures to see what worked and what didn’t work, the first question you want to ask is, “Was the goal statement achieved?” That answer isn’t always a simple “yes” or “no.” The goal statement on a recent PDCA sought to increase Realtor® participation to 80%. The counter measures got participation up to 70%. Because they had a strong goal statement, the PDCA group could determine if new counter measures were needed, or if the current ones simply required more time to work.

It’s okay to start your PDCA by writing the goal statement first. In fact, it’s sometimes easier to write the problem statement once the goal statement is clearly stated. Remember, behind every great problem statement is a great goal statement. (There… Now you’ve heard it.)

© November 2009 Homebuilding Partners, Inc.   

Este trabalho técnico foi preparado como estudo de viabilidade de implantação de produção enxuta em uma empresa de embalagens em Novembro de 2009, em São Paulo, SP, como oportunidade de melhoria de produtividade, redução de custos, aumento da lucratividade, redução de desperdícios e aumento da competitividade no mercado nacional.

Resumo

O ciclo PDCA é uma proposta de abordagem organizada que tem como objetivo solucionar qualquer tipo de problema. Desta forma, pode-se orientar de maneira eficaz e eficiente a preparação e a execução de atividades planejadas para a solução de um problema. Foi introduzido no Japão no período pós-guerra por Willian Edward Deming, porém foi desenvolvido por Walter Shewhart na década de 20. O ciclo PDCA tem por princípio tornar mais claro e mais ágeis os processos envolvidos na execução da gestão, começando pelo planejamento, em seguida executa-se o conjunto de ações planejadas. Posteriormente, compara-se os resultados obtidos com a meta estipulada e, por fim, toma-se uma ação para eliminar ou ao menos reduzir os defeitos no produto ou processo.

Abstract

The PDCA cycle is a proposal for organized approach that aims to solve any problems. Thus, it can be oriented in an effective and efficient preparation and implementation of activities planned for the solution of a problem. It was introduced in Japan in the postwar period by William Edwards Deming, but was developed by Walter Shewhart in the 20s. The PDCA cycle is beginning to clarify and to speed up the processes involved in the implementation of management, beginning with planning, then execute the set of planned actions. Subsequently, we compare the results with the target set and, finally, becomes an action to eliminate or at least reduce the defects in the product or process.

1. Fundamentação teórica

                É importante, antes de estabelecer a proposta metodológica para o uso do PDCA para a solução de problemas, conhecermos as ferramentas básicas e gerenciais da qualidade, ou as sete velhas e as sete novas ferramentas da qualidade, que serão muito úteis durante o uso do ciclo PDCA.

1.1    Brainstorming

                O brainstorming é uma ferramenta associada à criatividade e é, por isso, preponderamente usada na fase de planejamento (na busca por soluções). Este método foi inventado por Alex F. Osborn em 1939, quando ele presidia uma importante agência de propaganda.

                Ele é usado para que um grupo de pessoas crie o maior número de idéias acerca de um tema previamente selecionado. Brainstorming significa “tempestade mental” ou “tempestade de idéias” e também pode ser utilizado para identificar problemas no questionamento de causas ou para se fazer a análise da relação causa-efeito.

                No braistorming estruturado, todos os integrantes devem dar uma idéia quando chegar a sua vez na rodada, ou passar a vez até a próxima rodada. Isso evita a preponderância dos integrantes mais falantes, proporciona a todos uma oportunidade igual para contribuir com idéias e promove o envolvimento maior de todos os integrantes, mesmo os mais tímidos. O brainstorming termina quando nenhum dos integrantes tem mais idéias e todos “passam a vez” em uma mesma rodada.

                No brainstorming não estruturado, qualquer integrante lança idéias à medida que vão surgindo na mente. Tende-se a criar uma atmosfera mais relaxada, mas também há o risco dos integrantes mais falantes dominarem o ambiente. Torna-se mais fácil para certos integrantes “pegar carona” nas idéias dos outros. Essa técnica termina quando nenhum integrante tem mais idéias e todos concordam em parar.

                O brainstorming é realizado em seis etapas básicas:

1)       Construir a equipe, onde geralmente participam os membros do setor que busca resolver o problema. Eventualmente, pessoas criativas de outros setores da empresa poderão ser convocadas. Os participantes devem estar reunidos em torno de uma mesa e indicar uma pessoa para secretariar a reunião, isto é, anotar as idéias que cada membro irá ditar.

2)       Definição do foco e enfoque, onde o foco é o tema principal (o assunto). Geralmente está associado a um resultado indispensável (problema) ou a um desafio que se quer vencer. Definido o foco, é necessário estabelecer o enfoque, que mostrará como o foco será abordado. Por exemplo, se o foco for “férias”, poderá ser abordado este foco de angulos distintos (enfoques), como por exemplo “onde gostaríamos de passar férias?” ou  “o que podemos fazer para diminuir nossas despesas nas férias?”.

3)       Geração de idéias, onde o que importa, nesta etapa, é a quantidade de idéias geradas, não importando a qualidade destas idéias.

a)       O exercício deverá centrar-se sobre um único foco já clara e previamente definido.

b)       As idéias emitidas, nesta etapa, devem ser anotadas pelo facilitador e devem ser isentas de críticas. Pode-se dizer que quanto mais potencialmente disparata for uma idéia, melhor, pois mais facilmente pode induzir a criatividade para a solução. O objetivo nesta etapa é emitir idéias que possam ser associadas às outras já emitidas.

c)       O participante deve emitir qualquer idéia, sem nenhum exercício de censura quanto às próprias e quanto as idéias dos demais. A idéia deverá ser formulada mesmo que num primeiro instante pareça ridícula.

d)       O secretário deverá anotar as idéias emitidas pelos participantes sem qualquer crítica. Quando emitir uma idéia, deve expressá-la em voz alta e anotá-la.

e)       Periodicamente, o secretário faz a leitura de todas as idéias até então anotadas. Ao término de um determinado período de tempo (entre 10 e 20 minutos), as idéias começam a rarear e o secretário poderá propor o encerramento, passando para a etapa seguinte.

f)        Uma vez selecionadas as idéias em consonância com o foco, estas serão agrupadas por “parentesco” ou semelhança de conteúdo, de forma a gerar subtítulos ou múltiplas respostas.

4)       Na conclusão, deverá ser feita uma análise dos tópicos, subtítulos ou respostas, deve-se selecionar aquelas que, combinadas ou isoladamente, respondem à questão exposta no foco.

1.2    Diagrama de Pareto

                O Diagrama de Pareto (ou 80-20 ou 70-30) é um gráfico de barras que ordena os problemas, identificando os mais importantes e medindo-os em diversas escalas, permitindo usar a teoria de Pareto (poucos essenciais, muito triviais), ou seja, há muitos problemas sem importância diante de outros mais importantes. Além disso, o Diagrama de Pareto permite agrupar os dados de diferentes formas, medem o impacto de mudanças no processo e quebra causas genéricas em causas específicas.

                No topo da barra mais alta, traça-se uma linha para poder verificar a medida cumulativa das categorias, podendo assim identificar o peso que os problemas têm em relação ao todo.

Figura 1 – Diagrama de Pareto

                Para montar o Diagrama de Pareto, as fontes podem ser:

a)       Brainstorming;

b)       Dados coletados através de planilhas;

É importante destacar algumas regras durante a análise do Diagrama de Pareto:

a)       Os problemas mais frequentes nem sempre são os mais caros;

b)       Construa o gráfico indicando corretamente as grandezas e a que elas se referem (unidades de medida);

c)       O gráfico deverá possuir títulos e nomenclatura para os eixos X-Y.

Passos para a construção do Diagrama de Pareto:

1)       Coletar os dados (brainstorming ou apontamentos);

2)       Organização dos dados;

3)       Contagem dos números, separados por categoria;

4)       Reescrever as categorias, por ordem de ocorrência;

5)       Juntar as categorias com menos frequência sob o nome de “outros”;

6)       Construir uma tabela;

7)       Elaborar o gráfico (barras ou linhas);

1.3    Diagrama de Causa e Efeito ou Diagrama de Ishikawa

                O Diagrama de Ishikawa leve este nome em homenagem ao seu criador, Kaoru Ishikawa, que desenvolveu esta ferramenta na década de 40. Ela se apresenta como uma ferramenta de qualidade muito eficiente na identificação das causas e efeitos relacionados com a maioria dos problemas detectados em uma organização. A exemplo do que ocorre na maioria das empresas, os pontos fracos acabam por gerar inúmeras dificuldades e problemas operacionais, com grandes e inevitáveis reflexos negativos sobre o meio organizacional.

                Alguns fatores são apresentados por sentar que concorrem para o efeito que será estudado. As causas ou fatores complexos podem ser decompostos em seus mínimos detalhes, sem com isso perder a visão de conjunto. Normalmente, os processos são analisados a partir de seis grandes grupos de fatores:

• Máquina = inclui todos os aspectos relativos às máquinas, equipamentos e instalações, que podem afetar o efeito do processo;
• Método = inclui todos os procedimentos, rotinas e técnicas utilizadas que podem inteferir no processo e, consequentemente, no seu resultado.
• Material = inclui todos os aspectos relativos à materiais como insumos, matérias-primas, sobressalentes, peças, etc, que podem interferir no processo e, consequentemente, no seu resultado.
• Mão de obra = inclui todos os aspectos relativos ao pessoal que, no processo, podem influenciar o efeito desejado.
• Medida = inclui a adequação e confiança nas medidas que afetam o processo como aferição e calibração dos instrumentos de medição.
• Meio ambiente = inclui as condições ou aspectos ambientais que podem afetar o processo, além disso, sob um aspecto mais amplo, inclui a preservação do meio ambiente.

                Em geral, as causas são levantadas em reuniões brainstorming. As causas mais prováveis podem estão ser discutidas e pequisadas com maior profundidade.

                Identificar todos os problemas existentes, para posterior análise e avaliação, estabelecendo as prioridades de acordo com o tamanho do estrago que cada um deles vêm causando à empresa.

                À frente (na “cabeça do peixe”) do diagrama, coloca-se o efeito e nos elementos da espinha colocam-se as causas, de modo a facilitar a visualização de todas as causas do efeito e permitir um ataque preciso ao âmago da questão com ferramentas e mecanismos adequados para eliminar de vez os gargalos e suas fragilidades.

                A última etapa consiste em analisar minuciosamente as inúmeras causas de cada efeito encontrado, agrupando-as por categorias, as comumente conhecidas “6M’s”.

                Para implentação do Diagrama de Ishikawa, não há limites. As organizações preferem ir além dos padrões convencionais, podem identificar e demonstrar em diagramas específicos a origem de cada uma das causas do efeito, isto é, as causas das causas do efeito. A riqueza de detalhes poderá ser determinante para uma melhor qualidade dos resultados do projeto. Quanto mais informações sobre os problemas forem disponibilizadas, maiores serão as chances de livrar-se deles.

Figura 2 – Diagrama de Causa e Efeito

                Dicas para montar o Diagrama de Causa e Efeito:

a)       Reuna os envolvidos e peça sugestões (brainstorming);

b)       Faça perguntas usando as grandes causas como catalisadores;

c)       Chegue a um consenso com os envolvidos;

d)       Defina a causa específica com poucas palavras.

                Para construção do Diagrama de Causa e Efeito, um caminho é o uso dos “5 por quês”.

1.3.1           5 Por quês

                Ao analisar um problema, é importante levá-lo até o maior nível possível para descobrir a causa primária. A técnica dos 5 por quês faz com que analisemos cada causa em vários níveis, sempre questionando “por quê” até chegarmos à raiz do problema. Porém, deve-se tomar o cuidado de efetuar os por quês enquanto as causas convergirem em soluções mais simples, que não envolva grandes custos e que esteja dentro da competência do grupo envolvido na solução do problema.

                A técnica dos 5 por quês foi desenvolvida por Sakichi Toyoda durante a evolução de suas metodologias de manufatura. O importante ao utilizar esta técnica é que ela não deve ser considerada substituta de uma análise mais profunda do problema. É uma técnica simples para problemas mais simples. Além destas perguntas, outras podem ser feitas (Bill Wilson):

• Que provas tenho de que esta causa existe? (É concreta? É mensurável?)
• Que provas tenho de que esta causa levará ao problema identificado? (Ou estou apenas fazendo suposições?)
• Que provas tenho de que esta é a principal causa que verdadeiramente leva ao problema? (Mesmo que seja um fator importante, a causa principal poderia ser outra).
• Algo mais deve ocorrer junto a esta causa para que o problema ocorra? (Serve para esclarecer se o problema não vem de uma combinação de fatores)

1.4    Estratificação

                Estratificar significa separar os dados que necessitam ser analisados em grupos (estratos).

                Por exemplo, ao comprar um aparelho eletrodoméstico, podemos fazer a seguinte questão “este aparelho tem defeito?”, ou “será que é bom mesmo?”.

                Verifique os defeitos, separando-os por “estratos”: por operador ou por máquina ou por partida. Separe e estratifique, observando dentro de cada estrato.

                Se os elementos são diferentes, devem ser separados em estratos e observados um estrato por vez.

Figura 3 – Estratificação

1.5    Folha de Verificação

                A Folha de Verificação começa pelo planejamento dos dados que devem ser observados, estabelecendo o período em que os dados devem ser coletados. A Folha de Verificação ajuda a analisar os dados coletados e a frequência com que ocorrem.

                Além disso, as Folhas de Verificação fornecem os subsídios para as outras ferramentas, e são construídas a partir de tabelas.

Figura 4 – Folha de Verificação

1.6    Histograma

                O Histograma mostra a variação dos dados coletados, onde os dados são agrupados e, através deste agrupamento, torna-se possível analisar sua dispersão e a variação do processo.

                Para construir um histograma, é necessário:

a)       Coletar os dados (em uma folha de verificação, por exemplo);

b)       Fazer uma tabela de distribuição de frequências

• Contar o número de dados coletados;
• Calcular a amplitude, isto é, a diferença entre o maior e o menor dado;
• Escolher o número de classes;
• Achar os intervalos de classe (arrendondando para o inteiro mais próximo);
• Determinar os extremos da primeira classe;
  • Tomar o menor número;
  • Arredondar para baixo; este é o extremo inferior;
  • Somar um intervalo de classe ao extremo inferior; este é o extremo superior;
  • Definir a primeira classe de extremo a extremo;
  • Definir as demais classes de maneira similar;
  • Contar o número de elementos em cada classe;
  • Construir uma tabela;
  • Construir o histograma
    • Marcar a classe no eixo das abscissas;
    • Marcar a frequência no eixo das ordenadas;
    • Fazer barras justapostas;
    • Inserir título

                O Histograma revela o grau de variação que todo processo traz dentro de si (pouca ou muita variação). O Histograma típico tem o formato de sino ou de uma curva normal.

                Dicas para interpretar o histograma:

a)       Veja o espalhamento: quanto mais espalhado é o histograma, mais variável é o processo;

b)       Se existe especificações, o histograma deve ficar dentro dos limites especificados;

c)       Veja se o histograma está centrado na média do processo; se não estiver, o processo precisa de ajuste;

d)       Não devem existir picos gêmeos; se isso acontecer, procure o problema;

Figura 5 – Histograma

1.7    Diagrama de Dispersão

                A função do Diagrama de Dispersão é verificar se existe correlação entre duas ou mais variáveis. Os tipos podem ser:

a)       Correlação positiva forte, ou seja, X e Y crescem (exemplo: pressão e temperatura);

b)       Correlação positiva fraca, ou seja, X cresce e Y cresce, porém pouco (exemplo: idade e experiência);

c)       Correlação nula, ou seja, X cresce e Y varia ao acaso;

d)       Correlação negativa fraca, ou seja, X cresce e Y descresce mas pouco (exemplo: qualidade e reclamações);

e)       Correlação negativa forte, ou seja, X cresce e Y descresce (exemplo: pressão e volume).

                Para desenhar o diagrama de dispersão, deve-se coletar de 50 a 100 pares de valores X e Y. Para julgar a correlação, observe a direção e a dispersão dos pontos, pois uma correlação negativa é tão importante quanto uma correlação positiva. É importante frisar que o Diagrama de Dispersão mostra correlação entre variáveis, mas não prova relação de causa e efeito.

Figura 6 – Diagrama de Dispersão.

Figura 7 – Diagrama de Dispersão com as correlações positivas.

Figura 8 – Diagrama de Dispersão com as correlações negativas.

1.8    Gráfico de Controle

                A função dos gráficos de controle é medir e verificar a variação de um processo ao longo do tempo e controlá-los de forma que o processo produtivo não apresente variações além dos limites superiores e inferiores previamente estabelecidos. As características do produto ou do processo deverão estar dentro destes limites e, caso apresente variações fora destes limites, os gráficos permitem enxergarmos esta variação e nos permite a correção em tempo hábil.

                Os gráficos de controle são utilizados no Controle Estatístico de Processo (CEP) e deverão estar em todos os processos que possuem características especiais conforme previamente estabelecido em desenhos do produto. Os gráficos de controle auxiliam para conhecermos se o processo é “capaz”, ou seja, quando possui um índice de capabilidade (Cp) maior ou igual a 1,33, o que significa dizer que, para cada 4 partes da especificação, poderemos ter apenas 3 partes de variação total do processo, considerando-se uma variação de 6s.

                As cartas são desenhadas com uma linha média central (média do processo), e duas linhas, sendo uma linha superior de controle e uma linha inferior de controle, traçadas a partir da linha média do processo (a distância é definida estatisticamente).

Figura 9 – Gráfico de Controle.

                O gráfico acima mostra um exemplo de gráfico de controle, onde:

a)       LSE = Limite Superior de Especificação;

b)       LSC = Limite Superior de Controle;

c)       LIC = Limite Inferior de Controle;

d)       LIE = Limite Inferior de Especificação.

                As variações que ocorrerem e forem anotadas no gráfico dentro dos limites LSC e LIC são variações decorrentes do processo e são chamadas de causas comuns. Os pontos que ficarem entre o LSC e LSE e entre o LIC e LIE são chamados de causas especiais, ou seja, indicam uma variação diferente da variação normalmente esperada.

Figura 10 – Gráfico de Controle, apresentando causa especial (gráfico superior).

                As 7 velhas ferramentas da qualidade (Pareto, Ishikawa, Estratificação, Folha de Verificação, Histograma, Dispersão e Gráficos de Controle) abordam uma metodologia estatística para levantar e atuar sobre problemas de forma corretiva. O objetivo das 7 novas ferramentas da qualidade, chamadas de ferramentas gerenciais da qualidade, permitem compreender melhor os fenômenos que ocorrem durante o processo, principalmente aqueles que são difíceis de quantificar.

1.9    Diagrama de Afinidade

                Utilizado para solucionar problemas através da coleta de dados verbais de forma desordenada, porém analisando-os por sua afinidade.

                Para se construir o Diagrama de Afinidade, devemos pensar no problema em questão, suas causas e, posteriormente separar estas causas em categorias, através de afinidades. É originado pelo Brainstorming e torna-se um complemento do Ishikawa, porém com aplicações mais amplas (por exemplo, o que pode ser importante na qualidade de um aparelho celular? Cada envolvido dirá o que considera importante, posteriormente estes itens serão separados por categorias e esta separação ocorre pela afinidade dos itens levantados).

Figura 11 – Diagrama de afinidade.

1.10Diagrama de Relações

                Analisa a inter-relação entre causa e efeito, ou seja, a inter-relação que existe entre as causas, simplificando a busca por soluções de problemas através da indicação das diversas causas envolvidas em um problema e suas relações.

a)       Deverá ser construído a partir de várias idéias sugeridas em um processo de Brainstorming, Ishikawa e 5 por quês;

b)       Poderá ser de Objetivo Simples ou Objetivos Múltiplos;

c)       Cada uma das idéias deverá ser colocada em um quadro e a partir daí, verificar se existe relação com as demais idéias apresentadas, fazendo sua ligação por meio de setas;

d)       Feitas as ligações, que deverão ter suas conexões exaustivamente discutidas, verifique a quantidade de setas que entram e que saem de cada quadro. Cada quadro deverá então conter um número E/S (Entrada/Saída), de maneira a identificar se aquela etapa é um agente gerador de ações (com muitas saídas) ou então um processador de ações (com muitas entradas);

e)       Dá-se então início ao processo de análise ao principal agente gerador de ações. O gerador de ações deverá conter somente saídas e nenhuma entrada;

f)        Os quadros com maiores quantidade de entradas e diversas saídas serão denominados processadores de ações; os quadros com muitas entradas e poucas saídas são denominados de gargalos.

Figura 12 – Diagrama de Relações.

1.11Diagrama de Árvore

                O Diagrama de Árvore serve como desdobramento de um problema para buscar sua causa raiz. Ele serve para desdobrar uma idéia, um conceito, uma tarefa, um processo em seus componentes mais básicos, permitindo que seja mais bem conhecido.

Figura 13 – Diagrama de Árvore.

1.12Diagrama de Matrizes

                Estuda e avalia, através de análise multidimensional, os pontos problemáticos, buscando entender a interação entre eles. A combinação pode ser de dois a quatro fatores, relacionados entre si, e que possuem pesos específicos conforme o público a quem se dirige. Um exemplo de aplicação é no QFD (Quality Function Deployment), onde através do desdobramento funcional da qualidade, é possível entender os desejos do cliente e do consumidor ao projeto e às especificações de um produto ou serviço.

Figura 14 – Diagrama de Matriz.

1.13Matriz de Priorização

                Uma das matrizes de priorização é a Matriz GUT. Esta ferramenta gerencial é uma forma de se tratar problemas com objetivo de priorizá-los. Leva em conta a gravidade, a urgência e a tendência de cada problema.

a)       Gravidade é o impacto do problema sobre coisas, pessoas, resultados, processos ou organizações e efeitos que surgirão a longo prazo, caso o problema não seja resolvido.

b)       Urgência é a relação com o tempo disponível ou necessário para resolver o problema.

c)       Tendência é o potencial de crescimento do problema, a avaliação da tendência de crescimento, redução ou desaparecimento do problema.

                A pontuação deverá ser de 1 a 5 para cada dimensão da matriz, permitindo classificar em ordem descrescente de pontos os problemas a serem atacados em melhorias de processo.Este tipo de análise deverá ser feito pelo grupo de melhoria com os colaboradores do processo, de forma a estabelecer a melhor priorização dos problemas. Após atribuída a pontuação, deve-se multiplicar G x U x T e achar o resultado, priorizando de acordo com os dados obtidos.

1.14Diagrama do Processo Decisório

                É uma ferramenta pouco explorada mas tem sua utilização voltada para analisar as etapas a serem consideradas para atingir o objetivo proposto, permitindo decidir pelas melhores alternativas à medida que as restrições forem surgindo.

Figura 15 – Diagrama de Processo Decisório

1.15Diagrama das Setas

                Eficiente no acompanhamento e monitoramento de um plano. É útil para auxiliar a montar cronogramas, indicando os caminhos críticos.

Figura 16 – Diagrama de Setas.

1.16Plano de Ação 5W2H

                Embora não seja uma ferramenta gerencial, o 5W2H é um plano de ação que engloba os envolvidos na solução de um problema, partindo das questões:

a)       What? O quê?

b)       Who? Quem?

c)       Where? Onde?

d)       When? Quando?

e)       Why? Por quê?

f)        How? Como?

g)       How Much? Quanto (custará)?

                Para cada uma das soluções priorizadas, a equipe estabelece metas de melhoria a serem alcançadas. O estabelecimento de metas é importante para constatar o nível de melhoria a ser incorporado ao processo, a partir da causa do problema que foi priorizada para ser eliminada. Esta etapa permite explicitar o nível de resultado esperado, como também, programar as atividades para a implementação da melhoria.

2. A solução de problemas usando o PDCA

                O objetivo principal na solução dos problemas é garantir o desempenho máximo da produção, operações e serviços pois estes afetam diretamente o cliente (externo e interno), e conduz tanto a receitas crescentes como a gastos reduzidos.

                Neste processo, as responsabilidades pela solução de problemas seriam:

a)       Qualidade

• Avaliação do desempenho real do processo, traduzido em forma de qualidade de produto em processo e produto acabado;
• Comparação do desempenho real com as metas pré-estabelecidas (níveis de refugo, de aceitação, etc);
• Atuação direta nas discrepâncias entre o real e o planejado, solicitando e conduzindo reuniões para soluções de problemas usando a metodologia proposta e procedimento documentado.

b)       Engenharia

• Determinar quais são os principais parâmetros do processo;
• Determinar como controlar estes parâmetros;
• Determinar os níveis desses parâmetros que levarão ao desempenho ótimo;
• Entender a variabilidade natural do processo;

                Não estudar o processo e não buscar as soluções possíveis faz com que o desempenho dos produtos fiquem cronicamente abaixo dos níveis desejados, bem como o rendimento do processo e as ações corretivas exigem muitas tentativas. É comum, ao final de várias tentativas (tentativa e erro), não conhecer a real causa do problema e o que de fato foi realizado para solucioná-lo de forma corretiva. Quando este problema ocorrer novamente, serão realizadas novas tentativas até estancar o problema, e assim sucessivamente. Esta é a principal finalidade do estudo de solução de problemas, propor ações baseadas em dados estatísticos e coleta de informações, usando as ferramentas de qualidade apropriadas, que eliminem definitivamente aquele problema ou o torne uma variável sob controle.

                Desta forma, a Qualidade levantará as evidências objetivas de problemas (medindo o estado atual dos processos) e analisando criticamente as evidências. A qualidade identificará os problemas e reunirá os times de trabalho (departamentos e pessoas envolvidas na solução dos problemas).

                Os times de trabalho estabelecerão diagnósticos, além de propor soluções e planejar a implementação. Além disso, irão implementar as soluções, monitorá-las e medir sua eficácia, empreendendo ações corretivas e padronizando as rotinas.

                Os times de trabalho serão compostos pela Qualidade, Engenharia de Produção, Produção e Manutenção (time fixo) e, diante da necessidade, outros departamentos irão compor o time (exemplo: suprimentos, comercial/vendas, etc). A necessidade do time de trabalho fixo se dá pelo fato da análise de Ishikawa e os 6M’s, onde os departamentos citados encontram-se envolvidos.

2.1    Método PDCA

Figura 17 – Roteiro para a solução de problemas usando o ciclo PDCA.

2.2    Identificar os problemas

                Os problemas deverão ser claramente identificados, seja por ocorrência em processo (não conformidade do desempenho real planejado com o especificado ou a meta pré-estabelecida), seja por processo de melhoria de processo. Esta identificação do problema poderá ser por meio de detecção de não conformidade em processo ou dados coletados durante o processo.

Figura 18 – Relatório de Não Conformidade.

2.3    Priorizar os problemas

                Quando houver mais de um problema em análise, os problemas deverão ser priorizados em sua análise e solução de problemas conforme a matriz de priorização, ou seja, qual o problema possui o maior resultado quando analisada a sua gravidade, urgência e tendência (resultado da multiplicação dos fatores).

Figura 19 – Matriz GUT para priorização dos problemas.

2.4    Analisar o problema

                A análise do problema consiste em conhecer as causas do problema, utilizando para isto o Diagrama de Ishikawa (Causa e Efeito) e os 5 por quês, a fim de conhecer as causas fundamentais (causa raiz) do problema em análise. Deve-se investigar como o problema ocorre e quais os fatores que o afetam, assim como as suas variações.

                Para conhecer o problema, é necessário estratificá-lo, visitando o local onde o problema ocorre e observando.

Figura 20 – Planilha para uso dos 5 por quês para buscar o último nível do problema (causa raiz).

                Detectadas as causas em todos os níveis, deve-se inserir as informações no Diagrama de Ishikawa a fim de separá-las em grupos (6M’s), facilitando assim a tomada de ações por parte do time de trabalho (definição das responsabilidades e dos grupos envolvidos nos planos de ação).

Figura 21 – Diagrama de Ishikawa para separação das causas nos grupos 6M’s.

Figura 22 – Diagrama de Relações.

2.5    Gerar alternativas

                Identificar as ações necessárias para bloquear as causas fundamentais; nesta fase, serão discutidas o maior número possível de soluções para cada problema listado no Diagrama de Ishikawa e Diagrama de Relações. Cada efeito deverá possuir, ao menos, três soluções viáveis do ponto de vista técnico (possíveis de serem executadas).

Figura 23 – Planilha para análise das soluções para o problema.

                Após a análise das possíveis soluções para o problema, o time de trabalho deverá analisar e refinar, optando pela solução mais viável e mais rápida de ser executada. Como auxílio nesta análise, utilizar o Diagrama de Processo Decisório.

2.6    Elaborar plano de ação

                Após descobrir as causas, elaborar alternativas e descrever as soluções mais relevantes, o próximo passo é implementá-las, usando a ferramenta 5W2H. Para cada uma das metas priorizadas, o time de trabalho estabelece metas de melhoria a serem alcançadas e planejam o desenvolvimento da ação proposta, estabelecendo prazos e ações através da planilha abaixo e, como auxílio, um cronograma.

Figura 24 – Planilha para Plano de Ações na solução das causas do problema.

                Além do plano de ação, o time de trabalho poderá realizar o benchmarking, comparando o processo com o processo de líderes reconhecidos para identificar as oportunidades para a melhoria do processo e da qualidade. O benchmarking compara os processos e desempenho dos produtos e serviços com os de líderes reconhecidos, permitindo identificar as metas e estabelecer prioridades para a preparação de planos que resultarão em vantagem competitiva no mercado, sendo realizado da seguinte forma:

a)       Determinar os itens para benchmark – os itens devem ser as características chaves de processos e suas saídas, e suas saídas devem estar diretamente relacionadas às necessidades do cliente;

b)       Determinar em relação a quem será estabelecido o benchmark – organizações típicas podem ser competidores diretos e/ou não competidores reconhecidamente líderes no item de interesse;

c)       Coletar os dados sobre o desempenho de processos e necessidades de clientes, que podem ser obtidos através de contatos diretos, vistorias, entrevistas, contatos pessoais e profissionais e periódicos técnicos;

d)       Organizar e analisar os dados – a análise é dirigida no sentido de estabelecer os melhores objetivos práticos para atingir todos os itens relevantes;

e)       Estabelecer os benchmarks – identificar as oportunidades para a melhoria da qualidade baseada em necessidades de clientes e no desempenho de competidores e não competidores.

2.7    Treinar e implementar

                Os envolvidos no processo e no plano de ação deverão ser treinados, capacitando-os para bloquear as causas fundamentais do problema. Este treinamento deverá ser registrado em lista de presença conforme modelo determinado no SGQ.

Figura 25 – Modelo de Lista de Presença para treinamento.

2.8    Controlar o processo

                Após o treinamento dos envolvidos, a solução deverá ser implementada, verificada e controlada através de folha de verificação, a fim de detectar se o bloqueio às causas fundamentais foi efetivo ou não (eficácia das ações). Caso o bloqueio não tenha sido efetivo, ou seja, através das folhas de verificação for detectado que a ação não eficaz, uma nova análise deverá ser realizada sobre o problema, a fim de discutir os motivos pelo quais o bloqueio não foi eficaz e definir uma nova estratégia de ação.

                Por outro lado, uma vez detectado estatisticamente que o problema foi resolvido (o tempo de verificação será determinado pela Qualidade, a fim de garantir que o desempenho esteja em conformidade com as necessidades do cliente), o processo deverá ser consolidado, alterando-se a documentação técnica necessária (instruções de processo, FMEA, especificações do produto e outras documentações pertinentes ao processo), buscando padronizá-lo à nova situação.

                Um bom sistema de medição impulsionará a empresa numa direção positiva. As medições serão o ponto de partida para as melhorias porque nos possibilitam entender onde a empresa se encontra e fixar metas que nos ajudem a chegar onde se deseja. As medições são realizadas através das folhas de verificação que, posteriormente, serão transformadas em gráficos de indicadores (formas de representações quantificáveis das características de processos e produtos/serviços; são utilizados para controlar e melhorar a qualidade e o desempenho dos produtos, processos e serviços ao longo do tempo).

2.9    Padronização do processo

                A padronização requer:

a)       Procedimento operacional – a instrução de processos deve estabelecer o novo procedimento operacional, incorporando quando possível um mecanismo “à prova de erros” (poka yoke). Deve ser esclarecido neste procedimento operacional o que, quem, quando, onde, como e por quê, para as atividades que devem ser incluídas ou alteradas nos padrões já existentes. Também deverá ser verificado se as instruções, determinações e procedimentos implantados deverão sofrer alterações antes de serem padronizados.

b)       Comunicação – as confusões deverão ser evitadas, estabelecendo-se a data de início da nova sistemática, quais as áreas serão afetadas para que a aplicação do padrão ocorra em todos os locais necessários ao mesmo tempo e por todos os envolvidos.

c)       Educação e treinamento – reuniões, palestras, manuais de treinamento, OJT. Deve-se garantir que os novos padrões ou operações sejam transmitidos a todos os envolvidos. A comunicação, além do documento, deverá ser verbal, onde será exposto o que mudou, a razão da mudança e apresentar com clareza os aspectos importantes daquilo que mudou.Deve-se certificar que os operadores estão aptos a executar o novo procedimento operacional, providenciando documentos no local de trabalho e na forma que forem necessários.

d)       Sistema de verificação ao cumprimento padrão – Deve-se evitar que um problema resolvido reapareça devido à degeneração do cumprimento dos padrões. Deve ser estabelecido um sistema de verificação periódica (auditoria escalonada), onde o supervisor da produção, juntamente com o time de trabalho, deverá acompanhar periodicamente para verificar o cumprimento dos procedimentos operacionais.

2.10Conclusão das ações

                Deve-se refletir sobre as atividades do time de trabalho durante o desenvolvimento do trabalho, compartilhando o aprendizado e definindo planos para o futuro:

a)       Análise dos resultados – buscar a perfeição, por um tempo muito longo, poderá ser improdutivo. A situação ideal quase nunca existe, portanto, delimite as atividades se o limite de tempo original for atingido. Deverá ser relacionado o que e quando não alguma ação não foi realizada. Deverá ser mostrado também os resultados acima do esperado, pois são indicadores importantes para aumentar a eficiência dos futuros trabalhos;

b)       Reavaliação dos itens pendentes – planejar e atacar os problemas remanescentes utilizando novamente o ciclo PDCA;

c)       Reflexão – Questões que deverão ser levantadas pelo time de trabalho ao término do trabalho:

• Ocorreram atrasos significativos ou prazos folgados demais? Quais os motivos?
• A elaboração dos diagramas foi superficial?
• Houve participação dos membros? As reuniões eram produtivas?
• O grupo ganhou conhecimentos?
• O grupo melhorou a técnica de solução de problemas? Utilizaram todas as técnicas?

Figura 26 – Filosofia do Ciclo PDCA.

Bibliografia

As Sete Velhas Ferramentas da Qualidade, Prof. Clovis Hegedus.

As Sete Novas Ferramentas da Qualidade, Prof. Clovis Hegedus.

As 7 ferramentas estatísticas para o Controle da Qualidade, Sonia Vieira e Ronaldo Wada, 1992, Ed QA&T.

Curso Nacional de Promotor de Polícia Comunitária – Gestão pela Qualidade na Segurança Pública;

As Ferramentas da Qualidade – Revista Falando de Qualidade – Editora Banas.

A visão de um holograma, ou de um fractal, é a visão que supera a holística do todo, pois enxerga o todo nas partes. Desta forma, o ciclo PDCA requer um ciclo PDCA para cada fase. Por exemplo: dentro do D (fazer), está prevista a capacitação. Mas esta capacitação requer uma análise de eficácia, através de um novo PDCA. Da mesma forma, o ishikawa pode se aplicar a cada um dos recursos.

Sometimes problems stick out like sore thumbs, and problem statements practically write themselves. But more often than not, the initial problem has so many layers and complications that it’s really hard to define. So what’s the problem?

A recent PDCA group was stuck asking this same question. There were five Construction Professionals in the group, and all five of them had issues with the same Building Partner. One Construction Professional said the problem was that the Building Partner couldn’t complete the work on schedule, while another said that the Building Partner was charging too much over the competition. Because each had a unique perspective on the problem, no one could agree on exactly what that problem was. So the PDCA just spun around in circles without ever defining an actual problem.

A lot of PDCA groups hit this early road block. It’s common when a process is creating multiple types of waste or a breakdown in the system affects several positions. The more complex the problem, the harder it is to define. In the situation with the five Construction Professionals, the only thing they could agree on was the Building Partner was making life difficult in each community.

The group had to hit the pause button. To get the PDCA moving forward again, the group leader initiated a brainstorming exercise that got all the problem ideas together then sorted out the causes from the actual problems.

Step 1:

The first step was brainstorming. (Read more about brainstorming by clicking here.) Each member of the group got an opportunity to describe the problem as he or she saw it, and the group leader wrote each description on a dry erase board. These problem description were very simple, 12 words or less. If a problem description got too complicated, he broke it into two shorter ideas. Each member of the group took turns until everyone had said “pass – I’m out of ideas.”

Step 2:

Once no one in the group had another idea to add to the board, the group leader read each idea. Then they evaluated and discussed each idea to determine if it was actually a problem, or if it was causing a problem. If the idea was a problem, he wrote “P” beside it. If it was causing a problem, he wrote “C” beside it. Ultimately, they had many more “C’s” than “P’s.” (Those “C” ideas were later used in the 5-Why Analysis.)

 Step 3:

Finally, the group re-evaluated each “P” idea. The goal was to have only one “P” standing. But since they started off with “Houses are over budget” and “Building Partner is more expensive than competition” as both “P’s”, the group leader asked if those ideas related to one another. When connecting the two thoughts, they found “Houses are over budget” because “Building Partner is more expensive than competition.” They then changed “Building Partner is more expensive” to a “C – Cause.”

Once “Houses are over budget” was defined as THE Problem, the group could move on to writing the problem statement. From what I hear, the group is now debating the Point of Cause, but that’s another story.

© October 2009 Homebuilding Partners, Inc.

We have an expression in our company — something originally told to us by our lean consultant Sammy Obara with the Honsha Associates.  He said, “You don’t need PDCA to kill a snake; just kill it.”

One of our recent PDCAs reminded me of this expression when we had some confusion with the title company. It seems a document used to communicate closing information had an outdated address for the title company, and a PDCA was initiated to correct this. The PDCA went something like this:

Problem: Closing notification form has incorrect address

Goal: Closing notification form has correct address

Point of Cause: Title company moved to a new location

Root Cause: No one updated the form used to schedule closings

Counter Measure: Update the closing notification form with the new address

This PDCA killed a snake. It completed an obvious task that needed to be accomplished. And, there is really no need to PDCA an obvious task such as updating someone’s address. Still, there was a PDCA to be done.

The outdated closing notification form actually created a series of problems: The Process Director had to correct several closing documents, and the Sales Professional had to make additional phone calls to the home buyer and the Realtor, who may have been confused by the misprint. And we don’t want that to ever happen again.

So, this was the deviation from standard (translation = “The Problem”). Normally, the document is printed and sent to the parties who use the info to schedule the closing, then everyone shows up at the appointed time and location, some paperwork is signed and the Home Buyer becomes a Home Owner. But in this instance, it didn’t happen that way.

That pesky outdated form created a lot of waste for a lot of people. It caused a problem. So the “closing notification form” is actually our Point of Cause. (Click here for more information about Problem vs. Point of Cause.) From there, we can mine down to the 5-Why Analysis, asking, “Why was the closing schedule form outdated?”

Which brings us back to our snake.

If we’re trying to bludgeon a snake with Plan-Do-Check-Adjust, hit the pause button. We may be confusing the problem with the Point of Cause. Ask, “How did the snake get inside in the first place? And are we taking measures to keep another snake from coming back?” At some point, information on that closing notification form will become outdated once again, and we’re going to get mighty tired of walloping snakes on the head.

© October 2009 Homebuilding Partners, Inc.

Point of Cause can be a difficult concept to grasp, and it’s often confused with the actual problem. The problem is waste. It’s a deviation from standard (or the norm). The point of cause is the physical time and/or location the deviation is occurring.

Here’s an exercise that illustrates this concept very clearly:

Let’s say that I snore very, very loudly. In fact, my snoring is so loud that it keeps my next door neighbor awake all night. He can’t sleep. Now, what’s the problem and what’s the point of cause?

The problem is my neighbor can’t sleep. His standard is sleeping at night, but he’s deviating from that norm. In fact, if this were a PDCA, he’d be the one to initiate it.

But wait — why isn’t my very loud snoring the problem?

The answer: Because I sleep just fine, thank you. If it wasn’t for my neighbor being kept awake, no one would care that I snore. If no one cares, where’s the problem?

If we apply the Because Equation to this (The problem occurs BECAUSE of the point of cause), we’d say, “My next door neighbor can’t sleep BECAUSE of my snoring.”

Once the snoring is identified as the point of cause, you can break it down into root causes. Why am I snoring? I need to lose 10 pounds. Or, I have a deviated septum. Or, who knows what the root cause would be. But at least now we can find it.

© October 2009 Homebuilding Partners, Inc.  

by Karyl Kowlessar, for Development Crossing, October 7, 2009.

Despite cost-cutting measures in this economic downturn, thousands of organizations still successfully use and implement management systems to save them time and money, to improve their internal processes and procedures, to prove their competency to their customers and to manage risk.

Corporate governance is the way in which corporations and other organizations are directed and controlled. The subject has been around for a while, ever since the problems arising from the separation of ownership and control of organizations has been recognized.

Organizations such as Enron and WorldCom acted as catalysts for corporate governance reforms. Industry in both the UK and the United States has since become more focused on managing corporate governance appropriately and safeguarding stakeholders’ interests. Compliance issues are at the very top of the corporate agenda.

Even with the introduction of new regulatory measures, it is clear that no firm is immune to the problems of poor risk management and corporate governance, and that initiatives introduced by the regulatory bodies should be viewed only as a base-line preventative measure…

To continue reading click here.

Por Rafael Ramos

Este post traz uma breve introdução ao SCRUM, abordando os principais conceitos, os papéis e as responsabilidades das pessoas envolvidas, o fluxo de trabalho e os seus processos. Confira!

*Este post está sendo publicado simultaneamente nos blogs Conhecimento e TI e Qualiblog como uma primeira ação de parceria entre os blogs.

Conceituação

SCRUM é um processo interativo e incremental para o desenvolvimento de projetos e utilizado desde 1990. O seu objetivo é entregar o máximo de valor de negócio no menor tempo.

O SCRUM tem como foco o PDCA (Plan, Do, Check, Act), resultando na melhoria contínua. Inicialmente, ele foi concebido para utilização em projetos de software, que possuem algumas características, tais como:

• São empíricos: complexos, caóticos, com detalhes pouco conhecidos.
• Difícil estimativa de tempo de duração das atividades.
• Os requisitos mudam constantemente

No SCRUM, existe uma lista com os requisitos identificados pelo cliente chamada de Product Backlog. Esta lista é alimentada continuamente pelo cliente em conjunto com o Product Owner (definição mais adiante) e reflete os trabalhos pendentes do time.

Papéis e Responsabilidades no SCRUM

No SCRUM, os papéis dos participantes em projetos são muito bem definidos. Existem basicamente três papéis no SCRUM: PO (Product Owner), SCRUM Master e o próprio time. A seguir serão detalhadas as características de cada participante:

x Product Owner:

x Criar e compartilhar uma visão projeto

x Tomar decisões sobre os itens do product backlog

x Indicar e priorizar itens de backlog

x Validar a entrega no final do sprint

x Time:

x Estimar os itens do backlog

x Desenvolver

x Auto-organizados para entregar o que o Product Owner quer

x Scrum Master:

x Contato direto com o product owner

x Cuidar do time

x Disseminar o SCRUM

x Garantir comunicação

x Evitar impedimentos

O Fluxo do SCRUM

O SCRUM possui um fluxo de trabalho muito bem definido. Muitos autores afirmam que esse simples fluxo é a essência desse framework e deve ser seguido o mais próximo possível da sua realidade.

x Sprint Planning 1

x Estimativas da próxima entrega

x O PO participa

x Sprint Planning 2

x Planejamento dentro da equipe

x O PO não precisa participar

x Daily SCRUM

x Reunião diária, que engloba:

x O que fiz desde a última daily SCRUM?

x O que espero fazer até a próxima daily SCRUM?

x O que está impedindo o progresso?

x Sprint Review

x Entrega dos artefatos planejados para este sprint. Importante: Presume-se que antes foi definido que este sprint teria algo “pronto” a ser apresentado

x Sprint Retrospective

x Aprendizado, lições aprendidas, discutir sucessos e erros do sprint

x TIMEBOX: Conceito do SCRUM que “obriga” que eventos sejam realizados periodicamente

Vantagens do SCRUM

x Processo bem definido e com time boxing

x Formação de profissionais auto-gerenciáveis

x Maior envolvimento do cliente

x Entregas freqüentes

x Desenvolvimento da equipe (liderança e auto-organização)

x Pessoas responsáveis pelos seus atos: na Daily SCRUM o time indica como está, seus impedimentos e, com o suporte do SCRUM Master, torna-se responsável pela sua entrega acordada

x Disseminação da prática de retrospectivas ou lições aprendidas: o que erramos no último sprint e o que podemos melhorar nos próximos sprints?

x Foco no cliente: O time entende que sua tarefa é uma parte em um Sprint e vêem valor agregado no que estão fazendo

x O cliente também torna-se responsável nas alterações de escopo

Conclusões

Há pessoas que caracterizam o SCRUM como uma metodologia; outros afirmam que é apenas um framework de apoio. Independente da caracterização que se queira dar, o fato é que ele se tornou uma realidade e já há esforços para que seja adaptado a outras áreas, como engenharia, indústria naval, dentre outras.

Como todo processo, lembre-se que ele deve ser adaptado a sua realidade. Afinal, a metodologia perfeita é aquela que se adequa ao seu negócio e, principalmente, ao seu cliente.

Sobre o autor

Rafael Ramos é analista de sistemas e mestrando em Gestão Empresarial. É mantenedor do Blog Conhecimento e TI e trabalha na área de TI há mais de oito anos, onde desempenhou os papéis de desenvolvedor, analista de sistemas, coordenador de fábrica de software e Scrum Master.

Se o SCRUM te chamou atenção, veja no Conhecimento e TI diversos outros artigos sobre o assunto!

Depois vou falar sobre os motivos que me levaram a trazer esse tema para cá. Aguardem!

Restrospectivas ágeis são sem dúvida, uma grande oportunidade para que equipes de desenvolvimento de software parem para pensar no trabalho que vem realizando e questionem o que pode se melhorado. É uma execente ferramenta para que o famoso ciclo PDCA (Plan / Do / Check/ Act) possa ser aplicado. O método ágil Scrum sugere que as reuniões de retrospectiva aconteçam no final da iteração (sprint) e que a equipe se faça duas perguntas básicas:

• O que está indo bem?
• O que pode ser melhorado?

Alguns preferem perguntar:

• O que devemos parar de fazer?
• O que devemos continuar fazendo?
• O que devemos começar a fazer?

No fim das contas o que realmente importa é que a reunião tenha como resultado ações a serem tomadas pela equipe para que a melhoria continua seja aplicada, e que na próxima restrospectiva, a equipe seja melhor do que era na última.

Alguns dias atrás o Vinicius Teles da Improveit twitou o link de uma palestra que foi apresentada no Google por by Esther Derby e Diana Larsen sobre restrospectivas ágeis. As duas são especialistas sobre assunto e já até escreveram um livro que pode ser comprado por $20 em PDF. Vale a pena assitir a palestra:

Creio que uma das coisas mais importantes que as duas destacaram na apresentação é a necessidade de dividir as responsabilidades de tomar as ações entre os membros da equipe para que as mudanças realmente aconteçam.  De nada adianta reuniões de retrospectivas que apontam problemas que nunca são resolvidos por ninguém. Para evitar que isso aconteça na Bluesoft, ultimante em toda reunião de restrospectiva nós lemos os itens que identicamos como coisas que poderiam ser melhoradas no sprint anterior e então rapidamente discutimos se realmente já estão resolvidos, e caso não estejam, voltamos a incluir o item e insistímos até que finalmente seja resolvido.

Um outro ponto interessante levantando por meu amigo Ricardo Almeida, é que devemos tomar cuidado para não transoformar a reunião de restrospectiva em uma mera busca de culpados. O foco deve estar sempre na solução.

No inicio desde ano Linda Rising apresentou na QCon Londres 2009 um tutorial sobre retrospectivas, uma de suas dicas, foi que as pessoas anotassem os acontecimentos bons e ruins ao longo do sprint em post-its para que não os esquecessem. Na Bluesoft, reservamos uma área do Kanban para que estes post-its sejam anexados.

Para maiores informações sobre retrospectivas, visite o Agile Restrospective Resource Wiki, um wiki (em inglês) com uma série de dicas, exercícios e ferramentas para realização de retrospectivas. O site cmcrossroads possui uma lista bem completa de sites onde você pode encontrar excelente material sobre o assunto.

Boa Restrospectiva!

“Mountain Jumping” is the term we use when someone encounters a problem and immediately determines the solution to fix it. We all do it. That’s why PDCA is a methodical series of steps that forces you to hit the pause button, examine what’s causing the problem, determine what measures should be taken to stop its recurrence, and then, finally, follow-up to ensure that those measures are working. PDCA forces us to go through every step.

Still – how many times do you encounter that one member of the PDCA group who just knows what we should do, and keeps bringing the conversation back to his solution? Even worse, once one member of the PDCA group takes that giant leap, it’s not long before every other member is jumping off that mountain right along with him.

As a leader on many PDCAs with chronic mountain jumpers, I’ve learned that taking a few pre-emptive measures during the PDCA process keeps me from having to say, “Will you just shut up? Stop! Don’t jump…”

Step 1

Begin every PDCA meeting with the Group Leader writing on a dry erase board (or simply a sheet of paper that everyone can see) the beginning steps of the PDCA process:

• Problem
• Goal
• Point of Cause
• Root Cause #1
• Root Cause #2
• Root Cause #3

Visually, this will help keep everyone focused during the PDCA process. Then remind the group that, “Right now, we’re only interested in exploring these areas of the problem. If you have an idea for a counter measure, great. Write it down so you don’t forget it, but don’t bring it up just yet.”

As the group works through each step of the PDCA process, write out the problem statement, goal statement and so forth on the board. This will keep people engaged and feeling like the group is moving forward.

Step 2

Often when the group begins the 5-Why Process, something will spark an idea and someone will say, “Well, you know what we ought to do…” Thus our mountain jumper is primed and ready to leap — and plans on taking the entire group with him.

As the leader, simply respond, “You know, that might work. Write that idea down so that we don’t forget it when we get to the counter measure section.” Then redirect the focus back to the 5-Why Process asking if anyone else has a suggestion.

Step 3

Occasionally, you’ll get that group member who simply won’t let his idea for a counter measure rest. He brings it up again and again. At this point, you may really want to push him off that mountain. Don’t do it.

Generally, this is an idea that he has a personal stake in. Possibly, he has  been working around the problem for some time and has given a lot of thought to his solution. Because it has some specific meaning to him, he won’t let it go until it’s been “officially” acknowledged.  

Ask the mountain jumper to write his idea on the board below the beginning steps of the PDCA process (see step 1) under “Possible Counter Measures.” Do not simply write “Counter Measures” at this point – this isn’t a counter measure yet. It’s a possible counter measure. Still seeing his idea on the board in writing will allow his mind to let go and focus on getting to the root of the problem.

People often mountain jump because they think they know the solution going into the PDCA process. However, when you work through the steps, you’ll find that an immediate solution is just one piece of a much larger puzzle – it often only addresses a single root cause, if it actually addresses any of them at all. Immediate solutions tend to be workarounds, creating new problems and additional waste.  Root causes call for real, specific counter measures that eliminate the problem for good.

Time and time again we find that working the PDCA process proves the original solution (or the mountain jumping) actually affects a symptom of the problem and not a root cause at all. In that case, you would’ve jumped for nothing at all.

© September 2009 Homebuilding Partners, Inc.

True story. Last Wednesday, I went to see a movie with four friends. Each of us put our two cents in about what movie to see and what night to go. And after some back and forth and a little planning, we all came to an agreement. At 7:15 on Wednesday night all four of us showed up at the same movie theater, bought a ticket for the same show and sat together on the same aisle in the same auditorium. 

But once the previews were over, one of my buddies got up and left. He wasn’t mad; he just didn’t care to watch any more.

So then there were three of us. The movie started and about 30 minutes into it, we lost another member of the group. He got up and for whatever reason, never came back. So for the next hour, there were just two of us watching this movie – until I looked over and noticed I was alone. All three of my friends had walked out. So I sat there watching the end of this film – by myself.

When I left the auditorium, I ran into one of those friends and asked, “What happened? Where’d you go?”

He said, “I got tired of watching that movie and decided to go see a different one.”

“But we had a plan. We organized. We all agreed…” I said, a little frustrated. “What was the point of all us putting so much planning and effort into organizing a movie night when no one bothered to watch the movie?”

Does any of this sound familiar? It should… Because we (as in you, me, and all our other Teammates) keep acting out the same scenario over and over again. Only, instead of planning a movie night, we put all that effort into PDCA. We go through the process of developing, agreeing upon and establishing uniform specs, criteria, methods, processes and practices, and then… one by one, like four friends walking out of an auditorium before the movie ends, we each drift back to an old way — or our own way. We’re not standardized.

You haven’t noticed? Let me give you some examples.

A few of the strongest and most-highly publicized and visible PDCAs of 2009 have been the “standardization” of the marketing flyer templates, the FTQ process, and the New Home Introduction. And over the last two weeks, a custom-created, non-templated flyer was turned-in, while many weekly FTQ sheets were not, and a very old, very outdated “Quality & Satisfactorily Complete Final Walk” check list turned-up. That doesn’t even begin to mention how many questions asked, phone calls made, and emails written to go over steps that are already accessible and clearly outlined in a SWIS in a manual. (You just got to blow the dust off the cover and open the book.)

Now take a minute to look at the PDCAs you’ve participated in this year. How many counter measures have you implemented? How many standard processes have you improved? How many Standardized Work Instruction Sheets have you created? How many people are consistently carrying-out and following them?

Now, be honest, are you consistently carrying-out and following them?

Are you wearing your hard hat on your head or on your hip every time you step on the homesite? How many Hot Spot sheets have you posted in your home-under-construction or even reviewed with a Building Partner? Are you referring to the SWIS to update the website? How many Construction Professionals and Sales Professionals are walking the community and model home together every Monday? Does every model home have a community info book next to the sales center printer?

In a nutshell, we’re failing to standardize, or the “Do, Check, and Adjust” part of PDCA. We’re not seeing it all the way through to the end. That’s like planning a movie night with four friends, but no one bothers to stay through the movie. We’re just dropping out and giving up too soon. And in many circumstances, we’re not even trying.

I believe there are several reasons this is happening and I have some ideas to improve, but that’s mountain jumping. So today, there’s a PDCA out there with my name on it that’s analyzing our lack of standardization in our standardization.

© September 2009 Homebuilding Partners, Inc.

Harry and the Hendersons

Have you ever seen the late ‘80’s movie, Harry and the Hendersons? In it, the Henderson Family had never seen a Bigfoot till their car smashes into one deep in the Washington forest. Then, at the end of the film when they return Harry – the elusive Bigfoot – to the wild, they find there were Bigfoots all around them in that forest. The Hendersons just had never been able to see them before.

Now, if you apply that analogy to problem awareness in our communities, you’ll find that we’re kind of like the Henderson Family. And the problems we’re conscious of might as well be as elusive as bigfoot. Sure, we can identify a big, hairy problem when we smash into one. But for the most part, we’re pretty unaware of our own environment.

Don’t believe me? Just take a random look at some of the PDCAs presented at this month’s Ganmi web conference. Ask yourself, how long have some of these workarounds been festering, and why did it take the problem coming to a head to make someone finally start a PDCA?

Today, we’re falling into several traps that are preventing us from mastering problem consciousness in our own environment. These traps are blinders really, keeping us from seeing the waste and damage created by allowing recurring problems time and time again, or worse, accepting workarounds to supersede the system. Arguably, the Number 1 trap is not knowing and truly understanding waste.

There’s seven types of waste. If you can’t name them off the top of your head – and more importantly give real world examples of each – then your problem solving skills will remain largely ineffective. You’re not seeking out and eliminating waste; you’re sitting back waiting for big, hairy problems to smash into you. And when they do, human tendency is react to it and jump to a solution. We don’t have time to PDCA – we’ve got a fire to put out!

Because we don’t have time, we generally accept recurring problems as part of the job — which is trap #2. Saying, “I’ll get to it later! I don’t have time to do this right now,” or, worse, “this workaround is getting the job done” does far more damage – though it might appear quiet and subtle – than hitting the pause button. Sometimes you have to stop production so that production never stops.  If an occurrence happens twice, it will happen again. If a problem can potentially arise, it will. If a problem occurs in your community or on your home site, it’s happening in others. Don’t accept recurring problems and don’t accept workarounds as a solution to a recurring problem.

Sometimes workarounds are tricky: they disguise themselves as “the way it’s always been done,” a.k.a trap #3. Sometimes, even if we know something isn’t right, we’ll accept it because that’s the way we did it last week, or that’s the way it’s always been done in this community, or that’s the way I was “trained” to do it. If a process doesn’t seem right to you or its creating waste, question it. It’s okay to question why you do something a particular way. But, again, to see it and then question it, you must first understand the waste and recognize it’s occurring.

The first step to true problem consciousness is becoming aware of your environment. Buy a note book dedicated to problem identification.  On the first page, list the seven types of waste and their definitions. Then begin looking for real world examples in your community – be it at the model home, home sites under construction, vacant lots, the building process, the route to local Realtor offices, etc. Keep a log of the waste you see. Pick a specific type of waste and keep your eyes open for it. Take a trip to another community to visit other model homes and jobsites. Sometimes it’s easier to spot waste in someone else’s environment, rather than your own. Then, take that list back to your own community and compare. Today you may only see one or two items to log. If you keep the log daily and write down everything you see, you’ll find your daily list growing exponentially. And, no, you may not realistically be able to PDCA every waste you identify. Simply concern yourself with opening your eyes and making yourself aware.

There’s waste all around us, like those elusive Bigfoots in the Washington forest. You’ve just got to know what you’re looking for.

© September 2009 Homebuilding Partners, Inc.

Pernah mendengar atau membaca kalimat dalam judul tersebut?

Ya, judul tersebut merupakan metode yang digunakan para praktisi bisnis untuk melakukan perbaikan dalam proses bisnisnya. Metode ini digunakan untuk melakukan perbaikan secara kontinu sehingga diperoleh proses bisnis yang ‘excellent‘.

Definisi:

Plan (Perencanaan)

Proses ini termasuk didalamnya sasaran dan proses yang akan dilakukan agar memberikan hasil yang sesuai dengan spesifikasi yang diinginkan.

Do (Lakukan)

Penerapan dari rencana yang telah dirumuskan

Check (Cek)

Proses pemantauan dan evaluasi terhadap proses dan hasil yang diperoleh. Apakah proses yang dilakukan sesuai dengan rumusan rencana yang dibuat? Atau, Apakah hasil yang diperoleh sesuai dengan spesikasi yang ditentukan?

Act (Tindak lanjuti)

Tahap ini merupakan proses tindak lanjut untuk melakukan perbaikan terhadap proses yang diperlukan  agar hasil dan proses menjadi ‘excellent’ . Modifikasi planning akan dilakukan terhadap proses yang dilakukan agar memperoleh hasil yang baik dan akan diterapkan pada proses berikutnya. Demikian seterusnya…

Ke-empat langkah ini akan dilakukan secara berulang agar memperoleh proses excellent dan hasil yang berkualitas dan sesuai spesifikasi yang ditentukan. Metode ini diterapkan pada perusahaan-perusahaan yang concern terhadap peningkatan kualitas produksi melalui proses bisnis yang excellent.

Notes:

Metode ini tidak jauh berbeda dengan prinsip management POAC (Planning, Organizing, Actuating, Controlling)

rural internet & telephony www.netkrom.com

Kalau dibedah teknologi komputer dapat dipilah menjadi 4 bagian besar: (1) motherboard multilayer, (2) komponen elektrik dan elektronika, (3) layar LCD, (4) plastik, yang kesemuanya berada di luar sana, Taiwan, Cina, Korea. Prakarsa Depdiknas melakukan perakitan komputer oleh SMK, patut mendapat acungan jempol. Sayang, kita belum mendengar departemen terkait seperti Perindustrian, Kominfo, Ristek, Perdagangan, Koperasi,  Tenaga Kerja, Industri, Perguruan Tinggi/Riset, juga Pemerintah Daerah, dilibatkan dan bersinergi untuk bersama-sama membangun kapabilitas nasional di bidang ini. Cantik sekali, kalau ada…

Ini belum memadai. Membangun kapabilitas nasional desain dan manufaktur komputer mencakup ruang lingkup yang amat luas. Tidak mudah karena teknologi komputer dan network bukan milik kita. Berikut diperlihatkan peta sinergi, hasil kajian ringkas sebuah pemikiran  memperlihatkan apa yang perlu dikerjakan untuk membangun kapabilitas nasional tersebut.

(1) desain motherboard, chip, komputer (2) manufaktur motherboard (3) mounting komponen di atas motherboard (4) marketing & sales (1)(2)(3)(4) support, customer care, training, maintenance, …dll.

Dengan menerapkan konsep PDCA (Plan-Do-Check-Action) secara bertahap, kegiatan dapat dirinci lebih lanjut melihat keterlibatan institusi dan departemen. Dapat dilihat juga, merakit hanya merupakan bagian kecil namun bukan proses sederhana yang sekedar menggabung-gabungkan komponen. Masih banyak hal lain yang perlu diperhatikan. Kesemua ini, tidak mungkin dikerjakan sendiri, terlebih hanya oleh satu departemen saja tanpa melibatkan pihak lain. Impossible. Ayolah serius, jangan main-main dengan uang titipan rakyat, para pembayar pajak .

Dalam skala kecil model kegiatan membangun kapabilitas di atas sudah dkerjakan, dan berhasil seperti yang dibahas di posting-posting sebelumnya. Tiba saatnya kita memasuki tahap desain dan manufaktur sesungguhnya dalam skala besar. Untuk meningkatkan kandungan lokal tidak semua harus dikerjakan sendiri di negeri ini; tidak perlu karena negara lain juga tidak melakukannya. Mari kita bersepakat kandungan lokal komputer ‘made in Indonesia’ selain proses perakitan di Indonesia, adalah komputer yang memiliki kekayaan intelektual anak bangsa sebanyak-banyaknya di dalamnya. Satu istilah, desain! Mulai dari desain kemasan, desain chip, desain motherboard, hingga ke desain komputer  untuk aplikasi khusus yang sangat diperlukan Indonesia.

Bagaimana?

Semogalah disetujui dan dilaksanakan. Kita serahkan dan percayakan ini semua kepada pemerintahan SBY yang baru…

A idéia deste bolg é, antes de tudo, socializar informações sobre a metodologia do mapeamento de processos e esclarecer dúvidas, enquanto registramos o passar do tempo e as experiências vividas pela equipe do GMGP da SM.

Pretendemos que funcione como um diário de campo: ao mesmo tempo em que registramos informações, curiosidades e peculiaridades da metodologia, possamos refletir sobre elas e realinhar nossas ações.

Seria como elaborar um PDCA (ferramenta que utilizamos do TPM): planejar, agir, checar e avaliar, associada, talvez com a técnica de diário de campo da antropologia: registrar e refletir, analisando os detalhes e dificuldades encont

Plan - Do - Check - Act

rados.

É isso.

Ciągłe ulepszanie – cykl podstawowy, znany też jako cykl Deminga. Także metodologia ciągłego uczenia się.

آزاد کاری در حوضه IT امر خیلی نو پایی در ایران هست و برای ما ایرانی ها شاید به تازگی در حال جا افتادن باشه. به همین دلیل بدون شک ما بی نیاز از تجارب و توصیه های با تجربه ها و پیشگامان این حوضه نیستیم و بهره گیری از تجارب و تعالیم اون ها به من که خیلی کمک کرد که این امر هم می تونه برای شما صادق باشه. در ادامه این نوشته من قصد دارم جسته و گریخته چند موضوع مهم رو که به آزادکاری من شکل بهتری رو داد برای شما بیان کنم. بدیهی ترین فایده به کار گیری این توصیه ها برای من افزایش قابل توجه در آمد بود. پس چرا برای شما اینطور نباشه؟ اگر مثل من شما هم بتونید خیلی راحت و ساده بر اساس تمایل خودتون از تنها بخشی از تجارب من بهره برداری کنید شاهد تغییر چشمگیری خواهید بود که شاید باعث بشه برگردید و از تجارب من و سایرین بیشتر بهره برداری کنید. پس خیلی سخت نگیرین به خودتون که حتما بخاین به همش عمل کنید و تحت فشار قرار بگیرید. این رو بدونید که شما هم توانایی های مثبت خوبی در این زمینه دارید.

یک دفترچه یادداشت و یه خودکار نا قابل

باورتون نمیشه اما گذاشتن یه دفترچه یادداشت و یه خودکار کنارش روی میز برای من که خیلی مشکل گشا بوده. میدونین چرا؟ الان میگم. بارها پیش میاد که برای ما در حین کاری ایده های جالبی به ذهن ما خطور میکنه که ازش خوشمون میاد و دوست داریم به نوعی حفظش کنیم. به تعبیری مشابه همون بوکمارک کردن آدرس سایت های مفید می مونه که بعدا یادمون نره. خب داشتن این دفترچه خیلی به ما کمک میکنه که ذهنیاتمون رو مکتوب کنیم.

در حین رفع اشکال، توسعه و تولید یه محصول نیازمند این میشیم تا یادداشت هایی رو انجام بدیم که داشتن این دفترچه مشابه حالت قبل خیلی سودمند خواهد بود. میشه شبیه یک چک لیست که شما در ادامه روند کاریتون ازش بهره میگیرید و موارد رو اصلاح و یا اعمال می کنید و توسعه کار رو به پیش می برید. حتی این مورد و مورد قبلی به شما کمک میکنه که به نوعی چرخه ای روالمند موسوم به چرخه دمینگ ( PDCA ) رو رعایت کنید و باهاش بیشتر آشنا بشید. خیلی سادس اصلا نترسید. به طور خلاصه و بر اساس تصویر این چرخه ( که عمدتا برای طراحی وب استفاده میشه) شامل چهار حالت هست:

- طرح ریزی یا برنامه ریزی (Plan)

- انجام کار(Do)

- بررسی و آزمودن(Check)

- اعمال اصلاحات(Act)

در نتیجه شما کم کم یاد میگیرد که با انجا دو مرحله قبلی که مشابه مراحل Plan و Check هستند با مهندسی بهتری کار رو به پیش ببرید. چقدر ساده بود، نه؟ حتی شاید خودتون هم به این دستاورد رسیده باشید. مهم اینه که به همین روال های ساده عمل کنید تا پول دار تر بشید مثل من. یه بار دیگه لطفا این بخش رو مرور کنید.

خب حالا چرا نگفتم این کار رو به صورت نرم افزاری انجام بدیم و مثلا از نرم افزار Onte Note مجموعه آفیس استفاده نکنیم یا نرم افزار های مشابه. پاسخ این سوال بر میگرده به ذائقه شما. من برای خودم بهتر دیدم که از روش سنتی و ساده شروع کنم تا حسابی روالمند بشه این رفتارم و بعد بتونم با هر نرم افزاری این عادتم رو ادامه بدم. شاید شما ترجیح بدین از همون اول این کار رو بکنید.

احتمالا شما کامپیوتر نیستید!

این رو برای اون دسته ای میگم که شبیه کامپیوتر نیستن. اگر شما شبیه کامپیوتر هستید که هیچ و این بخش رو رها کنید و برید بخش بعدی. خب فکر می کنید چرا بشر کامپیوتر رو اختراع کرد؟ به این دلایل که انجام کار ها رو ساده تر بشه و بازدهی و سرعت بالاتر بره. به همین جهت سیستم عامل ها تا جایی پیش رفتند که چند وظیفه ای ( Multi Tasking ) شدند و تونستند چندین کار رو همزمان و با سرعت مطلوب انجام بدند.

خب این داستان خیلی برای بشر صادق نیست و بشر نمیتونه مثل کامپیوتر به خوبی چند کار رو با بازدهی مطلوب و حفظ تمرکز همزمان به پیش ببره. همین نکته ساده به شما کمک میکنه که در طول عمر توسعه یک پروژه به سراغ کار دیگه ای نرید و تا انتها تمرکز رو بر روی یک پروژه حفظ کنید. اگر میخاین بد قول نشید، فحش نخورین، شب زنده داری نکنید، عصبی نشید و تمرین قناعت کنید حتما به این مورد توجه کنید. طمع دستمزد نباید شما رو وسوسه کنه. چون بر این اساس احتمال زیاد آسیب هایی رو به خودتون خواهید رسوند که بنده در ایامی که تازه سبیل بر لبان مبارکم نقش بسته بود به خوبی اون رو تجربه کردم. گذشته از آسیب ها این روند تمرکز باعث میشه که بهره بری و راندمان شما بسیار بالاتر بره. باور نداری؟ خیال میکنی اینم مثل سخنرانی های کسالت آور کارشناسان توی تلویزیون هست؟ خب برو این راه اینم چاه.

امان از این اینترنت پرسرعت!

آقا این عامل عین ذغال خوب میمونه برای معتاد! این اینترنت دائمی و کار در خونه و موج ابزارهای اجتماعی باعث میشه که جاذبه های سنتی اینترنت بیشتر بشه و شما به زودی در یابید که معتاد بدی شدید. خصوصا اگر این اعتیاد در کنار کار باشه. شاید الان اینی که میخام بگم جیغ خیلی ها رو در بیاره، اما من توی این چند وقته یه مطالعه سر انگشتی روی بر و بکس ایرانی فعال توی حوضه وب و حوضه های اجتماعی وب انجام دادم و به یه شواهدی رسیدم:

- خیلی از کسانی که به شدت شاخص شدن در وب و باعث تعجب ما میشن که  آیا این ها خواب و خوراک ندارن که این همه فعالن؟ ، بعد از یه فراز کاملا کمرنگ شدن و خبری ازشون نیست.

- عده ای که به شدت فعالیت می کنند و برای این کار دستمزد دریافت می کنند و یا سود مادی براشون از این کار متصور هستم.

- عمده کسانی که شاخص فعالیت اجتماعی  (به طور کلی ) در وب هستند کسب و کاری همچون ما آزادکارها ندارند و ماهیت سنی و شغلی آنها نشون میده که تعلقات این چنینی ندارند و مثلا هنوز دانشجو هستند، نوجوانند، جیره خوار خانواده هستند و یا تخصصی غیر از کامپیوتر دارند که این فعالیت چشمگیر باعث ضرر آنچنانی اونها نمیشه.

چون دیدگاه من در این باره منفعت گرا و تحث تاثیر فعالیت های سود زاست این طور نهایتا از موارد بالا جمع بندی می کنم که آنچنان نیازی نداریم که در فعالیت های اجتماعی تحت وب فعال باشیم و خوره وار هر جایی سرک بکشیم و یه پروفایل وب دویی متشکل از دویست تا سایت وب دویی داشته باشیم. از این عامل اعتیاد بیش از حد میشه تحت نام عامل حواس پرتی هم یاد کرد که باعث میشه یهویی نگای ساعت کنید و ببیند 4 ساعت رو الکی تلف کردید و وقت لالاست. من چند توصیه بر اساس تجارب خودم می تونم برای جلوگیری از این عارضه (!) داشته باشم:

- موقع کارهای جدی برنامه های پیام رسان همچون یاهو مسنجر، گوگل تاک و … رو ببنید.

- اگر چند تا اکانت ایمیل دارید سعی کنید همش رو متمرکز کنید و همه رو به یکی فروارد کنید.

- از برنامه های خبر خوان و خوراک خوان همچون Google Reader استفاده کنید تا صرف وقت به شکل قابل توجهی بهینه شود.

- شبکه های اجتماعی بی فایده برای خودتون ( تاکید می کنم بی فایده برای خودتون) رو کنار بذارید. مثلا فیس بوک برای من اصلا منفعتی نداشت و من مدت هاست که در فیس بوک نیستم. اما YouTube و Digg برای من بسیار سودمند هستن و به طور مفید و ورای جو زدگی ازشون استفاده خوبی می کنم. سعی کنید جو گیر نشوید و این احساس به شما دست نده که اگر توی توییتر فعالیت ندارید عقب مونده اینترنتی هستید!

چرا میترسی؟ خب بپرس جانم، بپرس دلبندم، د بپرس لا مذهب…

هنوزم که هنوز من عده زیادی رو می بینم که اینترنت رو به عنوان بزرگتریم و بهترین مرجع فراموش می کنند و بر میدارن زنگ میزنن به فلانی یا شال و کلاه می کنن راه میفتن برن تحقیق برای حل مشکل. عزیز من برادر من توی حوضه ای که شما داری درش آزاد کاری میکنی بیشتر از هر حوضه ی دیگه توی اینترنت آموزش و کتاب و خودآموز و هزار کوفت و زهر مار هست. چرا نمیری سوالت رو درست سرچ کنی؟ چرا سوالت رو توی تالارهای گفتگو و انجمن های تخصصی نمیپرسی؟ چرا کم  به صورت آنلاین مطلب مرتبط میخونی؟ چرا ترس برت میداره بخای به زبون انگلیسی بری جایی صحبت کنی؟ خیلی سادس، جوینده یابنده است…

اما در کنار این برای دوستان جوان خودم ( خودمم جوونم بابا) این توصیه های اکید دوستانه رو دارم:

- سرچ کردن رو خوب یاد بگیرد.

- ترسی از گفتگوی به زبان انگلیسی نداشته باشید.

- در محیط های بین المللی پرخاشگرانه و فرمایشی رفتار نکنید.

- در محیط های بین المللی تخصصی از بیانات سیاسی و احساسی پرهیز کنید. مگر اینکه تخصص شما همین باشد.

- در محیط های بین المللی از درخواست صریح کرک و آموزش هک پرهیز کنید.