Tecla Windows: veja do que ela é capaz

Posted in |

Descrição: teclawindows

Tecla Windows. Ela nunca foi tão útil quanto nessa
nova versão do sistema operacional. Nas versões
anteriores, algumas combinações já eram possíveis,
mas agora, ela ganhou outras funções que facilitam
o manuseio e fazem com que o usuário ganhe tempo.
Quer ver?

Experimente a combinação Windows + seta para a
direita. A janela que estava em primeiro plano
vai, automaticamente, para a metade direita da
tela. Selecione outra janela e, dessa vez, aperte
Windows + seta para a esquerda. Veja só. A tela
ficou dividida ao meio, com cada janela para um
lado. Isso é ideal para quem gosta de utilizar
duas aplicações ao mesmo tempo. A combinação
Windows + seta pra cima maximiza a janela, e
Windows + seta pra baixo minimiza o que estava em
primeiro plano.

Se o botão Windows for apertado junto com a tecla
de espaço, todas as janelas somem da tela e a área
de trabalho é mostrada. Isso é muito útil caso
você queira ver algo que esteja no desktop, sem
precisar minimizar uma por uma. O mesmo efeito
pode ser conseguido ao repousar o mouse aqui, no
cantinho direito. Agora, experimente clicar em
alguma janela e chacoalhar o mouse. Olha só. Tudo
é minimizado, menos o programa selecionado. Legal,
né? Isso também pode ser feito via teclado,
apertando simultaneamente os botões Windows e
Home.

Agora, com o Windows 7, cada item na barra de
tarefas é associado a um número. O mais perto do
botão iniciar é o 1. O item logo em seguida é o 2,
e assim sucessivamente. Se você apertar a tecla
Windows + algum número, aquele programa vai para o
primeiro plano. Já a combinação Windows + Shift +
algum número vai executar uma nova janela daquela
aplicação. Windows + T e você percorre pelos itens
da barra de tarefas. E se você tem problemas com
letras pequenininhas, experimente Windows e a
tecla +. O zoom digital aproxima a região onde o
mouse estiver repousado. Para voltar ao zoom
original, é só apertar Windows e a tecla -.

Veja logo abaixo uma lista com outras dicas de
como utilizar a tecla Windows:

Win+Home: Deixa aberta apenas a janela ativa
Win+Space: Todas as janelas ficam transparentes, e
o usuário consegue enxergar o desktop
Win+Seta para cima: Maximiza a janela atual
Shift+Win+Seta para cima: Maximiza a janela atual
na posição vertical
Win+Seta para baixo: Minimiza a janela / volta ao
tamanho original se maximizada
Win+seta esquerda / direita: leva a janela para
cada metade da tela
Shift+Win+seta direita / esquerda: Leva a janela
para o monitor da direita ou da esquerda (em caso
de monitor duplo)
Arrastar a janela para o topo: maximiza
Arrastar a janela para a esquerda ou direita: faz
com que ela ocupe metade direita / esquerda da
tela
Chacoalhar a janela com o mouse: minimiza tudo,
menos a janela selecionada
No Windows 7, se você usar a tecla Windows com
algum número, é possível interagir com as
aplicações da taskbar. Por ex: Win + 4 vai abrir o
4. programa, contado da esquerda para a direita.
Windows + Alt + 4 mostra o jumplist do mesmo
aplicativo.
Shift+Win+número (1-9): Abre uma nova janela
daquele aplicativo
Ctrl+Win+número (1-9): Alterna entre as janelas já
abertas daquele aplicativo
Alt+Win+número (1-9): Abre a jumplist daquele
aplicativo
Win+T: Passeia pelos ítens da taskbar
Win+B: mostra os aplicativos da direita da taskbar
Ctrl+Shift+N: Cria uma nova pasta no Windows
Explorer
Alt+Up: Sobe um nível de pastas no Windows
Explorer
Win+(+/-): Zoom in/out
Win+G: Alterna entre os gadgets da sua tela

Read Users' Comments (0)

Estudo de Caso

Posted in |

Estudo de Caso
 Introdução
            A técnica de modelagem de estudo de caso é usada para descrever o que um sistema novo deveria fazer ou qual a função de um sistema já existente. O modelo de estudo de caso é construído através de um processo interativo de discussão entre os desenvolvedores do sistema, e os clientes (e/ou) usuários em busca de uma solução pela qual todos estejam satisfeitos.
            O estudo de caso foi criado por Ivar Jacobson, em 1994, baseado em suas experiências em desenvolvimento do sistema AXE na Ericsson, mais especificamente o OOSE e método Objectory (Veja Histórico). O estudo de casos têm recebido bastante atenção pela comunidade de orientação a objetos, e têm, da mesma forma,  afetado os métodos usados na orientação a objetos.
            Os componentes primários do modelo de estudo de caso  são: os casos, os atores, e os sistemas moldados. O limites do sistema são definidos pela funcionalidade proposta ao sistema. A funcionalidade é representada por um número de estudo de casos, e cada estudo de caso especifica uma funcionalidade completa.quando a funcionalidade está completa, o estudo de caso deve manobrar a função inteira, desde o início, feito por um ator externo, até que ele tenha alcançado a funcionalidade desejada no início. Um estudo de caso deve sempre retornar um valor para o ator, de acordo com o que este ator definiu para o sistema.
            O ator é qualquer entidade externa ao sistema que tenha interação com o sistema. Normalmente, é uma pessoa, um usuário do sistema, mas pode ser, também, outro sistema, ou algum tipo de artifício de um hardware na necessidade de interagir com o sistema.
            Na modelagem de estudo de caso, o sistema é visto como uma "caixa preta" que supre o estudo de caso. Como o sistema faz isso, como os estudo de caso são implementados, ou como eles trabalham internamente, não é o mais importante. Na verdade, quando uma modelagem de estudo de caso é feita no início do projeto, os desenvolvedores não tem idéia de como os casos de uso são implementados.
            Tópicos:    
            Objetivos
            Diagramas de estudo de caso
            Sistemas
            Atores
           Estudo de Caso
                               
   
Objetivos
            Portanto, o importante é saber quais são os propósitos iniciais para o estudo de caso:
  •         Decidir e descrever as funcionalidades exigidas pelo sistema, resultado de um acordo entre o cliente (e/ou usuários finais) e os desenvolvedores de software que estão trabalhando no projeto;
  •         Dar uma visão clara e consistente do que o sistema deve fazer, para tanto o caso de uso é utilizado durante todo o processo para comunicar todos os desenvolvedores os objetivos principais exigidos pelo sistema, e para suprir as bases de uma modelagem gráfica futura do sistema, de acordo com esses objetivos;
  •        Garantir uma base para que testes de verificação do sistema sejam feitos. Certificar que os objetivo iniciais ainda sejam o foco principal do desenvolvimento do sistema.
  •        Providenciar uma habilidade para traçar a funcionalidade requeridas dentro das classes e das operações do sistema. Simplificar mudanças, extensões para o sistema (manutenção), e então, traçar o estudo de caso alterado na interface gráfica e na implementação.
            Todo este trabalho de criação de modelos de estudo de casos envolve a especificação do sistema, conhecimento dos atores e dos usos de casos, descrevendo os usos de caso, e definido o relacionamento entre os casos, e por fim, a validação do modelo.
            O modelo de estudo de casos consiste de diagramas mostrando os atores, os casos e os relacionamentos. Esses diagramas dão uma visão geral do modelo. Mas as principais descrições são tipicamente textuais. Modelos visuais não podem suprir toda a informação necessária para um modelo de estudo de caso, dessa forma, ambos, diagramas e textos são usados.
            O cliente, e o usuário devem estar interessados porque o estudo de caso especifica a funcionalidade do sistema e descreve como o sistema poderá ser usado. É de grande utilidade quando o consumidor participa ativamente do processo de criação de estudo de caso, porque o modelo acaba por se adaptar em detalhes aos desejos, e necessidades do usuário. 
            O modelo de estudo de caso representa a visão do caso de uso do sistema. Esta visão é muito importante, pois influencia todas as outras visões do sistema. Tanto a arquitetura lógica quanto a física são afetadas pelo estudo de caso, pois as funções especificadas no estudo de caso são implementadas nessas arquiteturas.
            A modelagem de estudo de caso não apenas captura as necessidades de um novo sistema, mas também é usada para a geração de novos sistemas a serem desenvolvidos. Quando uma nova geração (versão) do sistema é desenvolvida, uma nova funcionalidade é acrescentada para a extensão do modelo do caso de uso basta adicionar novos atores ou casos, ou modificando as especificações de casos já existentes. No entando, deve se tomar cuidado quando se modifica um caso de uso para uma extensão para que a funcionalidade inicial não seja prejudicada.


Diagramas de estudo de casos
             Um modelo de estudo de caso é descrito em UMl como um diagrama de caso de uso, e este modelo pode ser dividido em vários diagramas de estudo de casos. Um diagrama desses deve conter elementos do modelo para o sistema, os atores, e os estudo de casos, e mostrar diferentes relacionamentos como generalização, associação e dependência entre os elementos.
            A descrição real de diagrama de estudo de caso normalmente contem m texto completo. Em UML, a descrição é tratada como um documentação própria dos elementos de estudo de caso. Essa descrição contém informações vitais para a definição nas necessidades reais da funcionalidade. Como uma alternativa para descrever o estudo de caso em forma de texto, pode-se desenhar o diagrama. Contudo, é importante lembrar que o estudo de caso deve ser facilmente compreendido pelo usuário final, e uma estrutura mais formal como um diagrama ativo, pode intimidar as pessoas a interpretá-lo.
        Veja a Figura


Sistemas
        Como parte da modelagem do estudo de caso, os limites do sistema desenvolvido são definidos. (É importante que se tenha em mente que um sistema não é necessariamente um sistema de software, pode ser uma máquina, ou um negócio). Definir os limites e a todas as responsabilidades do sistema não é sempre fácil, pois não é sempre óbvio quais questões são melhores automatizadas por um sistema que pode ser executado manualmente, ou  por outros sistemas.
        Um sistema em um diagrama de caso de uso é descrito em uma caixa, o nome deve aparecer acima, ou dentro da caixa.


Atores
        Um ator é alguém ou algo que interage com o sistema, é quem o que usa o sistema. Por "interagir com o sistema" queremos dizer que o ator manda e recebe mensagens para e do sistema, ou seja, troca informações. Em suma, atores executam os casos de uso.
        Um ator é um tipo (uma classe), e não uma instância. Ele representa um papel, não um usuário individual do sistema. Essa troca de mensagens com o sistema é bastante similar à programação orientação a objetos, apesar de não serem tão formalmente especificados em um caso de uso. Um caso de uso é sempre inicializado por uma mensagem enviada por um ator, o que chamamos de estímulo. Quando um caso de uso é executado, espera-se que ele envie mensagens para um ou mais atores.
        Atores também podem ser definidos como ativos ou passivos. Um ator ativo é aquele inicializa o estudo de caso, enquanto que o passivo nunca inicia um estudo de caso, mas apenas participa de outros usos de caso. Quando se identifica um ator, está se estabelecendo uma entidade interessada em usar e interagir com o sistema.
       Um ator deve possuir a mesma associação com um ou mais casos de uso. Apesar do ator não ter inicializado o caso de uso, o ator irá em algum momento se comunicar com um. O ator recebe um nome que reflita seu papel no sistema.
        Atores em UML
        Tendo em mente que em UML existem classes com tipos <>, e que o nome da classe é o nome do ator (como dito acima, refletindo seu papel), uma classe ator, como outra qualquer, possui atributos e métodos, bem como documentação própria descrevendo o ator. Uma classe ator possui padrão de  representação que é o "homem palitinho", como o nome do ator abaixo da figura.
           Veja a Figura
       Relacionamento entre Atores
       Como atores são classes, eles tem os mesmos relacionamentos de uma classe normal. No diagrama de caso de uso, apenas relacionamentos de generalização são usados para descrever o comportamento normal entre atores. (Veja Gereneralização)
            Veja a Figura



Estudo de Caso
            Introdução
       Um caso de uso representa uma funcionalidade completa, como percebida pelo ator. Um caso de uso em UML é definido como um série de ações em seqüência que um sistema executa que produzem um resultado de valor notável para o ator. As ações podem envolver comunicação com vários atores (usuários ou sistemas), bem como performar cálculos e trabalhos internos no sistema.
        As características de um estudo de caso são:
  •        Um estudo de caso é sempre iniciado por um ator: é sempre executado em parte por um ator. O ator deve direta ou indiretamente ordenar que o sistema utilize um estudo de caso.
  •        Um estudo de caso devolve um valor ao ator: Um estudo de caso deve enviar algum tipo de valor tangível ao usuário.
  •        Um estudo de caso é completo: um estudo de caso deve possuir uma descrição completa. Um erro comum seria dividir o caso em casos menores que acabam não completando um ao outro. Um caso de uso não está completo até que se acabe o processamento do valor, mesmo que várias comunicações (como o uso de diálogos) sejam necessários ao longo do processo.
        estudo de casos está ligados aos atores através de associações, que são as vezes chamadas de associações de comunicações. As associações mostram qual ator está se comunicando, incluindo o ator que iniciou a execução de caso de uso. A associação é normalmente de um-pra-um, e sem direção. Isso significa que uma instância de ator se comunica com outra instância de estudo de caso, e que isso ocorre nas duas direções. Um estudo de caso recebe o nome de que caso performa.
        Um caso de uso é uma classe, não uma instância. Ele descreve a funcionalidade como um todo, incluindo possibilidades alternativas, erros e exceções que podem ocorrer durante o processo do estudo de caso. Um instanciamento do estudo de caso é chamado de scenario (em português cenário), e ele representa o uso real do sistema (uma execução específica através do sistema)
           Veja a Figura
    
        Estudo de Casos em UML
       Um estudo de caso é representado em UML como ema elipse contendo o seu nome dentro ou abaixo dela. Um caso de uso é geralmente alocado dentro dos limites do sistema, e pode estar ligado a um ator com uma associação ou  uma associação de comunicação que mostra como usar o caso e como o ator interage com ele.
            Veja Figura
        
        Relacionamentos entre Casos de Usos
         Existem 3 tipos de relacionamentos entre casos.
  •         Relacionamento por extensão:  é um tipo de herança, onde um caso de use é uma extensão de outro através da adição de ações do caso geral. O usa da extensão pode incluir o comportamento da classe que está sendo herdada, dependendo das condições de extensão;
  •         Uso de Relacionamento: é outro relacionamento de generalização onde um caso de uso, porém outro estudo de caso indicando que como parte especializada do caso de uso, o comportamento do caso de uso geral (classe mãe), também será incluído;
  •         Agrupamento: quando um número de casos de uso apresentam funcionalidades semelhantes, ou de alguma forma relacionadas, eles podem ser colocados juntos num pacote UML. Um grupo de pacotes relaciona um modelo de elementos, e pode ser expandido ou quebrado, permitindo ao desenvolvedor visualizar um pacote de cada vez. O pacote não possui nenhum outro significado semântico.

        Descrevendo estudo de casos
        Como já foi mencionado  várias vezes, a descrição do estudo de casos é normalmente fetita através de uma descrição textual. Esta é uma forma simples e consistente de especificação de como os atores e os usos de casos (sistemas) interagem. Isso contrasta com o comportamento externo do sistema. A terminologia da linguagem usada na descrição é a mesma da usada por consumidores/usuários do sistema:
        O texto de descrição inclui:
  •             Objetivos para o caso de uso: Quais são os objetivos finais do caso de uso?! O que se quer alcançar?! O estudo de caso é orientado a objetivos, e os os objetivos de cada caso de uso devem aparecer.
  •             Como o estudo de caso é inicilaizado: Que ator inicializa a execução do estudo de caso. E em quais situações.
  •             A fluência das mensagens entre os atores e os casos de uso. Que mensagens ou acontecimentos, o ator do caso de uso troca: atualizada, ou não, e ajuda em outras decisões.
  •             A fluência alternativa no caso de uso: um caso de uso pode ter execuções alternativas dependendo das condições ou exceções. É importante mencionar isso, mas é preciso também ser cauteloso para não descrever em muitos detalhes, já que eles devem escondem a fluência principal da ação no caso geral.
  •             Como um caso de uso termina com um valor para um ator: descrever quando um caso de uso é considerado terminado e que tipo de valor ele retorna ao ator.
         Lembrar-se que a descrição identifica o que é feito de relevante pelo ator externo, e não como as coisas são feitas dentro do sistema. O texto precisa ser claro e consistente para que o consumidor possa entender e validá-lo. Evitar sentenças complicadas que dificultem a interpretação.
         Um caso de uso pode também ser descrito através de um diagrama mostrando a seqüência de atividades, suas ordens e as decisões opcionais que são feitas para indicar que atividade será executada em seguida. 
        Como complemento para o caso de uso descrito, que contém uma completa e geral descrição, um número real de cenários são usados para ilustrar o que acontece, com ambos, os atores e os casos em suas respectivas instâncias definidas. É importante não esquecer que o scenario é apenas um complemento e não um substituto para a descrição do caso.
        Depois que os casos de uso são descritos, uma atividade específica revela se os relacionamentos previamente estabelecidos descritos estão identificados. Os desenvolvedores não tem conhecimento completo para identificar os relacionamentos cabíveis, até que todas as classes estejam descritas, além de ser arriscado o fazer sem essas informações.

Read Users' Comments (0)

Saiba como agir após uma entrevista de emprego

Posted in |

Enviar uma nota de agradecimento, mostrando que entendeu a vaga e a empresa e que está pronto para assumir o desafio, pode fazer diferença.
Em um mercado competitivo, no qual as melhores vagas são muito disputadas, candidatos a emprego devem lançar mão de todos os recursos para causar boa impressão. Nesse contexto, uma das coisas que pode fazer bastante diferença é o envio de uma pequena nota de agradecimento, capaz de demonstrar cordialidade e reafirmar o interesse pela vaga.Esse pequeno gesto, no entanto, não é muito comum, principalmente entre os jovens postulantes às vagas de tecnologia.
De acordo com a gerente geral do grupo de recrutamento Winter, Wyman &Company, Tracy Cashman, esse é um erro que pode fazer a diferença: se o recrutador estiver dividido entre dois candidatos, o recebimento de um agradecimento sincero e bem escrito pesará a favor de quem o enviou. Como esse tipo de ação não é tão comum, pode se tornar uma vantagem competitiva para quem adotar a prática. “Mostra cortesia, interesse pela posição e iniciativa”, afirma Cashman.
Mas, para que a ação seja realmente bem sucedida, Cashman afirma que é necessário seguir algumas regras básicas.
1 – Envie o agradecimento prontamente – Logo após o a entrevista, rascunhe a nota de agradecimento enquanto a conversa ainda está fresca na cabeça e envie no máximo em 24 horas. A nota pode e deve ser enviada por e-mail, que é mais imediato, mas deve seguir regras formais de escrita, como se fosse uma carta em papel.
2 – Seja específico e sucinto – Se a nota de agradecimento passar de três parágrafos, é melhor reduzir. Cashman diz que uma nota muito longa pode não ser lida inteiramente e, de quebra, somar pontos negativos na avaliação de sua habilidade de comunicação.
Mesmo com pouco espaço, é necessário abordar os pontos-chave da conversa, indicando que você teve atenção ao recrutador e ouviu o que ele tem a dizer.
3 – Siga uma estrutura - Cashman recomenda um modelo para uma nota de agradecimento funcional e eficiente. No primeiro parágrafo, expresse sua gratidão pela oportunidade  de saber um pouco mais das estratégias da companhia, desafios e necessidade por equipe.
No segundo, reitere porque você é um bom candidato à vaga, ressaltando que tem as habilidades desejadas e que está pronto a atender aos desafios e oportunidades que lhe foram apresentados. Mostre também que está confiante que a sua experiência trará benefícios para a organização. A meta é mostrar que o candidato entende quais são as necessidades para a posição e que seria a escolha ideal dentro desses requisitos.
No terceiro parágrafo, reforce seu interesse pela posição e pela companhia e coloque-se à disposição para novas conversas.
4 – Não erre na gramática e na ortografia – Assim como no currículo, erros na carta de agradecimento podem causar péssima impressão e provocar efeito contrário ao desejado. Revise quantas vezes for necessário.
5 – Evite o tom de desespero – Outra coisa que pode minar as chances de obter a vaga é escrever expressões que denotem desespero por um emprego.
6 – Não esqueça informações de contato – Com a excitação da entrevista, não é difícil esquecer de pedir as informações de contato do recrutador para que seja possível mandar a nota de agradecimento. Peça o cartão de visita da pessoa que realizou a entrevista ao final da conversa.

Read Users' Comments (0)

10 segredos para solucionar problemas de TI

Posted in |

Atitudes são tão importantes quanto conhecimentos técnicos na hora de resolver indisponibilidades de sistemas e outras questões tecnológicas.

Não importa quão profundo sejam os conhecimentos técnicos de uma equipe. Sem metodologia adequada, a solução de problemas torna-se um processo muito mais complicado.

O CIO da Escola de Medicina da Harvard e de um dos maiores grupos de assistência médica dos EUA, John Halamka, baseou-se em sua experiência para elaborar uma lista com os 10 principais segredos para resolver problemas com rapidez e experiência.

1 – Uma vez que algum problema foi identificado, verifique seu real alcance – O software de monitoramento pode até dizer que tudo está bem, mas é bom não se conformar. O ideal é conversar com os usuários, testar a aplicação ou a infraestrutura sozinho e ter certeza sobre a origem de qualquer reclamação.

2 – Quando o alcance do problema é muito grande e a raiz ainda é desconhecida, acione um plano de emergência – É muito melhor mobilizar toda a equipe para um falso alarme ocasional do que intervir tarde demais e quando o problema alcançar proporções muito grandes com uma resposta lenta do departamento de TI.

3 – O processo de solução de um problema deve ser visível, atualizado constantemente para todos e participativo – Muitas vezes os profissionais técnicos ficam tão focados em suas tarefas diárias que perdem a noção do tempo, não se atualizam mutuamente e deixam de conversar com outras áreas. A companhia deve ter uma abordagem multidisciplinar, com relatórios de progressos pré-determinados para prevenir, isolar o problema e buscar soluções com maiores chances de acerto.

4 – Mesmo com a rotina de atualizações e relatórios, a equipe deve ficar livre para trabalhar – Alguns líderes de TI gostam de retornos constantes de sua equipe e isso não é necessariamente ruim. Mas se a equipe gastar 90% do seu tempo reportando o status do trabalho, fica muito mais difícil solucionar problemas em prazo razoável.

5 – A explicação mais simples geralmente é a correta – Halamka relata que, em um incidente recente em sua corporação, todas as evidências apontaram para o mal-funcionamento em um componente do firewall. Mas todos as ferramentas de testes e diagnósticos indicavam que o firewall funcionava perfeitamente. Alguns levantaram a hipótese de que a empresa sofria um tipo muito específico de ataque de negação de serviços. Outros aventaram a possibilidade de uma falha em componentes das redes Windows dos servidores. Surgiu ainda a possibilidade de um ataque incomum por vírus. A explicação mais simples, do firewall, foi comprovada correta após sua remoção da infraestrutura da rede. E, segundo Halamka, a regra da explicação mais simples ser a resposta, até mesmo para problemas mais complexos, é verdadeira na maioria das vezes.

6 – Os prazos devem ser definidos de maneira responsável – O que mais irrita os usuários não é exatamente a demora, mas a definição de prazos imprecisos e os consequentes pedidos de “só mais uma hora para resolver o problema”. Se uma indisponibilidade de sistema ocorrer por conta de uma mudança planejada de infraestrutura, a questão é ainda mais séria: o melhor a fazer é definir um prazo preciso e respeitá-lo.

7 – Comunique-se com os usuários o máximo possível – A maioria dos stakeholders da empresa estão dispostos a tolerar indisponibilidade se você explicar exatamente as ações que estão sendo tomadas para restaurar o serviço. Os principais executivos de TI são os maiores alvos dessa dica, pois devem mostrar compromisso, presença e liderança.

8 – Orgulho não deve atrapalhar a solução – É difícil assumir erros e desafiador reconhecer o que não se sabe. Mas em vez de gastar tempo procurando culpados por problemas, o foco deve ser em examinar a raiz da indisponibilidade e depois definir processos para prevenir a repetição dos problemas.

9 – Não cante vitória antes do tempo – É tentador presumir que os problemas foram resolvidos e dizer a todos os usuários sobre a suposta vitória. Mas o melhor é esperar 24 horas seguidas de serviços ininterruptos antes de declarar o problema resolvido.

10 – Líderes de TI devem focar na sua trajetória, não em sua posição cotidiana – Indisponibilidades podem causar diversas emoções, como ansiedade, medo de perder o emprego ou a reputação e tristeza pelo impacto causado nos usuários. Nessas horas, a melhor coisa é ter em mente que o tempo é capaz de curar qualquer coisa e que incidentes eventuais serão esquecidos. Com o passar da trajetória profissional, a comunidade de usuários tende a observar mais a consistência e o processo contínuo de melhoria de qualidade do que episódios isolados.

De uma forma geral, problemas são dolorosos, mas capazes de unir pessoas. Nos piores momentos é que se constrói relações de confiança, criação de novos canais de comunicação e melhoria de processos.

Read Users' Comments (0)

Assinar: Postagens (Atom)