Category: Metodologia (page 1 of 7)

Metodologias

Futuro com Home Office

Caso não saibam, sou fã da Automattic, criadora da plataforma WordPress. Tanto as ferramentas quanto a metodologia de trabalho são fantásticas, futurísticas e muito e frente.

No Brasil a nova Legislação trabalhista pode ter aberto uma brecha que permite a modalidade Home Office, mas o quanto estamos maduros pessoal e profissionalmente para esta metodologia. Pensando em refletir sobre o tema, tenho estudado um pouco mais e identificado os casos mais conhecidos para analisar.

A exemplo de empresas 100% remotas, você sempre vai encontrar o case da Elastic, uma empresa de software, não possui escritórios, mas contava ou conta com 500 funcionários em cerca de 35 países. Para construir uma cultura comum, a empresa os reúne periodicamente, reunindo seus engenheiros nos EUA ou na Europa para se encontrar duas vezes por ano, disse o CEO Shay Banon . Quando os funcionários não se conhecem e suas únicas interações são via email, texto ou serviços de mensagens como o Slack,

Para evitar conflitos de escalada, Elastic mantém um canal de vídeo constante. “Uma das regras que temos é quando algo chega a um ponto de ebulição, vá ao vídeo e conversa”, disse Banon .

Mas veja a Automattic, a empresa de tecnologia criadora da plataforma WordPress.com, que tem um belo escritório em um armazém convertido em São Francisco, com tetos altos, uma biblioteca euma porta de celeiro customizada . Lindo demais o lugar, amistoso pelas fotos para se ir trabalhar.

Mas depois que sua CEO Matt Mullenweg chegou a conclusão que os empregados não estavam tão presentes assim, resolveu colocar o endereço 140 Hawthorne a venda.

A Automattic sempre deu aos seus 550 funcionários a opção de trabalhar remotamente; O espaço de San Francisco era um espaço de co-trabalho opcional, disse o porta-voz Mark Armstrong. A empresa mantém escritórios similares na Cidade do Cabo, África do Sul e fora de Portland, Maine, e dá aos funcionários um salário de US$ 250 por mês, se eles quiserem usar escritórios comerciais em outros lugares.

 

Mas se eles quiserem trabalhar na Starbucks, a Automattic pagará seu café. Imagina isso!?

Na contra partida da Automattic, em 2013, Marissa Mayer, então CEO do Yahoo, terminou a política de Home Office da empresa, informando aos funcionários em um memorando que para melhorar os resultados seria ” precisamos trabalhar lado a lado”.

Outra gigante, a IBM, considerada por muitos pioneira no trabalho remoto, comunicou seus funcionários nos EUA para começar a trabalhar em escritórios. O objetivo é tornar a força de trabalho da empresa mais ágil e, de forma semelhante ao objetivo do Yahoo, promover a criatividade através do trabalho ” lado a lado”.

Cerca de um quarto dos funcionários dos EUA trabalham remotamente total ou parcialmente do seu tempo, de acordo com Gallup. Há evidências de que esses funcionários trabalham mais horas do que seus colegas vinculados ao escritório.

 

Os cases citadas servem para analisar e tentar começar uma discussão mais elaborada nos próximos posts.

Pai do Pedro, Marido e Workaholic com vida social. Mais em https://www.edersonmelo.com/quem-sou/

Análise MoSCoW na Priorização de Requisitos

Há alguns dias conhecia Análise MoSCoW , um técnica para ajudar na priorização de itens, escopo, requisitos, classificação de mudanças…

Atualmente o Dynamic Systems Development Method (DSDM) Consortium possui os direitos de propriedade intelectual da MoSCoW, doados pelo seu criador Dai Clegg e significa:

Must Have (Deve Ter) – Tudo o que é imprescindível para o escopo do projeto. Aquelas funcionalidades CORE da sua aplicação, que sem elas a aplicação perderia totalmente o sentido.

Should Have (Deveria Ter) – Tudo o que é importante ter no escopo do projeto, mas que não são imprescindíveis. Funcionalidades que se por ventura não forem desenvolvidas, não farão com que o produto perca o seu valor de negócio.

Could Have (Poderia Ter) – Tudo o que seria bom ter, mas não são importantes. É aquele item que faz brilhar os olhos do cliente.

Won’t Have for Now (Não Terá por Enquanto) – Tudo o que não será desenvolvido por enquanto, pois o won’t have for now, não geram valor de negócio no momento.

Vantagens em utilizar a Técnica MoSCoW

  • Num planejamento da release, um PO poderia decidir que todas as estórias que estão classificadas e priorizadas com Must Have e Should Have deverão ser implementadas até a data da release.
  • O PO poderia, analisando o avanço do projeto, incluir uma estória no Backlog, classificá-la como sendo Could Have e definir todas as estórias classificadas com este valor de negócio, devendo ser discutidas previamente com o cliente.
  • OPO não terá maiores dificuldades em demonstrar redução nos custos do projeto, caso ele tenha classificado algumas estórias como Won’t Have for Now, e tais estórias, posteriormente, se fizeram de fato desnecessárias.

MoSCoW e as 3 ações (Dividir, Priorizar e Descartar)

Todas as estórias que têm valor de negócio Must Have, deverão ser refinadas. Elas precisam ser entendidas pelo time,  quebradas em estórias menores.

Todas as estórias que estiverem com Must Have e Should Have são prioritárias, precisam ser desenvolvidas na Sprint atual ou na próxima. (PRIORIZAR)

Todas as estórias que estiverem com Won’t Have for Now devem ser descartadas, pelo menos por enquanto. (DESCARTAR)

Eu vejo muitas oportunidades com a técnica, que se bem empregada, pode auxiliar muito a criação do backlog do projeto.

Apesar de ser Formado e Pós Graduado em Gestão de Projetos, estou muito aprofundado em Metodologias Ágeis, e estes estudos tem proporcionado uma gama maior de conhecimentos em novas técnicas como a MoSCoW . Sei que para muitos e que fica comprovado pela sua história, ela não é propriamente nova, mas hoje que eu a conheço melhor a vejo com outros olhos.

Aproveitem a leitura e pesquisem mais, colaborem e distribuam o conhecimento para evoluirmos juntos.

 

Pai do Pedro, Marido e Workaholic com vida social. Mais em https://www.edersonmelo.com/quem-sou/

Faça Mais e Se Divirta com Gestão do Tempo Usando Pomodoro

A Técnica Pomodoro não é como qualquer outro método de gerenciamento de tempo no mercado hoje. O que o torna tão único? Simplicidade!

Começamos que Pomodoro é um sistema cíclico. Você trabalha em sprints curtos , o que torna a certeza de que estamos constantemente produzindo. Você também terá de fazer pausas regulares que reforçam a sua motivação e o mantêm criativo.

 

Técnica Pomodoro é provavelmente, um dos métodos de produtividade mais simples de implementar. Tudo que você precisa é de um timer. Além disso, não existem aplicações especiais, livros ou ferramentas necessárias.  Relembrando como a Técnica  funciona:

  1. Escolha uma tarefa a ser cumprida;
  2. Defina o Pomodoro a 25 minutos (o Pomodoro é o temporizador);
  3. Trabalhe sua tarefa até que o Pomodoro determinado seja cumprido e coloque um cheque em sua lista;
  4. Faça uma pausa curta (5 minutos);
  5. A cada 4 Pomodoros dar uma pausa maior(sugestão de 15 min);
  6. Essa “pausa maior” é geralmente da ordem de 15-30 minutos, ou o que for preciso para fazer você se sentir recarregado e pronto para começar outra sessão de trabalho de 25 minutos. Repita esse processo algumas vezes ao longo de um dia de trabalho, e você se sentirá muito realizado e levei, tendo essas pausas para tomar uma xícara de café ou encher sua garrafa de água.

É importante notar que um pomodoro é uma unidade indivisível de-obra, que significa que se você estiver distraído part-way por um colega de trabalho, reunião, ou em alguma emergência, você tem que terminar o pomodoro (salvar o seu trabalho e começar um novo mais tarde), ou você tem que adiar a distração até o pomodoro ser completo. Neste caso, a sugestão é:

  1. Informe que você está trabalhando em alguma coisa agora;
  2. Negociar um momento em que você possa retornar;

pomodoro-edersonmelo

É claro que nem todas as distrações são tão simples, e algumas exigem atenção imediata.

Como o Pomodoro pode ajudar

A Técnica Pomodoro não é apenas ajudar você a fazer as coisas hoje; Trata-se de aprender como você trabalha para que você possa economizar tempo no futuro.

1. TRABALHAR COM TEMPO – NÃO CONTRA-O-TEMPO

Para muitas pessoas, o tempo é um inimigo. Nós corremos contra o relógio para terminar as atribuições e cumprir os prazos. A Técnica Pomodoro ensina você a trabalhar com o tempo, em vez de se esforçar contra isso.

2. GERENCIAR SUAS DISTRAÇÕES

Uma distração pode ser uma chamada no Facebook, ou, de repente, percebendo que você precisa mudar o óleo em seu carro, muitos pensamentos e eventos, distrações surgiram quando você está no trabalho. A Técnica Pomodoro irá ajudá-lo a registrar suas distrações e ordená-las de acordo com os níveis de prioridade. Você vai se surpreender como muitas coisas podem esperar o tempo apropriado.

3. TRABALHO/VIDA PESSOAL

A maioria de nós está intimamente familiarizado com a culpa que vem de procrastinar. Se não tivermos um dia produtivo, é muito fácil acabar sentindo que não podemos aproveitar o nosso tempo livre. A Técnica Pomodoro pode ajudar na organização, seja criando um cronograma ou em simples listas, permitindo que você realmente aproveitar seu tempo livre.

4. ENCONTRAR QUANTO DE ESFORÇO UMA ATIVIDADE EXIGE

Já se perguntou onde está todo o seu tempo? Não me pergunto mais: está tudo na página. A sua Folha do Pomodoro To-Do é uma visão geral do tempo gasto em várias tarefas.

5. APRENDENDO A LIDAR COM INTERRUPÇÕES

Normalmente, você pode demorar 25 minutos antes de ligar para um amigo ou responder a um e-mail. Você aprenderá a lidar com a interrupção inevitável, mantendo-se focado na tarefa em questão.

6. ESTIMATIVA DE ESFORÇO PARA SUAS ATIVIDADES

Uma vez que você tenha obtido o tempo necessário para tarefas comumente necessárias, você poderá prever com precisão quantos Pomodoros serão necessários para realizar as tarefas futuras.

 Com toda essa simplicidade e possibilidades que a Técnica Pomodoro promove, ou possibilita é o que me motiva a escrever tanto sobre algo simples.  É o que me motiva a utilizar diariamente no meu trabalho, mesmo que nem sempre está possa ser aplicada.
By Ederson Melo
Pai do Pedro, Marido e Workaholic com vida social. Mais em https://www.edersonmelo.com/quem-sou/

Papéis no Scrum: Product Owner, o Dono da Bola, Scrum Master, o Coach Proativo e Scrum Team

Scrum assim como muitas metodologias são formadas por papeis que fundamentam sua aplicação. Os papéis dentro do Scrum são compostos por: O Product Owner, Scrum Master e Team Scrum, que são suficientes para entregar software de alto valor agregado, de acordo com a metodologia Scrum.

Unindo e agregando conhecimento a meus posts anteriormente, temos uma descrição segundo o SBOK.

Product Owner, o Dono da Bola

O Product Owner é o dono do produto, é quem define os itens que compõem o Product Backlog e os prioriza nas Sprint Planning Meetings, pois fornece o conhecimento do negócio em forma de requisitos para a equipe assim como sua ordem de aplicação. Na prática, o Product Owner é a interface entre a empresa e os clientes.

O Product Owner Trabalha em conjunto com a equipe definindo as necessidades dos usuários, os requisitos técnicos, documentando-os conforme a necessidade, e determinando a ordem de sua execução. Ele gerencia o Product Backlog (que é o repositório de todas essas informações), mantendo-o ao nível de detalhe e qualidade que a equipe necessita.

O Product Owner também define o cronograma para liberação das releases, e faz a validação final para saber se as implementações têm as características e qualidade necessárias para a liberação.

O Scrum Team olha para o Product Backlog priorizado, seleciona os itens mais prioritários e se compromete a entregá-los ao final de um Sprint. Estes itens transformam-se no Sprint Backlog.

Daily-Scrum-edersonmelo

A equipe se compromete a executar um conjunto de atividades no Sprint e o Product Owner se compromete a não trazer novos requisitos para a equipe durante o Sprint. Requisitos podem mudar (e mudanças são encorajadas), mas apenas fora do Sprint. Uma vez que a equipe comece a trabalhar em um Sprint, ela permanece concentrada no objetivo traçado para o Sprint e novos requisitos não são aceitos.

Scrum Master, o Coach Proativo

O Scrum Master tem a responsabilidade de assegurar que a equipe respeite e siga os valores e as práticas do Scrum. Ele também protege a equipe assegurando que ela não se comprometa excessivamente com relação àquilo que é capaz de realizar durante um Sprint.

As responsabilidades do Scrum Master incluem:

  •  Remover as barreiras entre a equipe e o Product Owner.
  • O Scrum Master atua como facilitador do Daily Scrum e torna-se responsável por remover quaisquer obstáculos que sejam levantados pela equipe durante essas reuniões.
  • Melhorar a produtividade da equipe da forma que for possível.
  • Melhorar as práticas de engenharia e ferramentas para que cada incremento de funcionalidades seja potencialmente entregável.
  •  Manter as informações sobre o progresso da equipe visível a todos de uma forma clara e organizada.

Em termos práticos, o Scrum Master precisa ter em mente a vivência do Scrum para treinar e orientar os outros papéis, e educar e ajudar as outras partes interessadas que estão envolvidas no processo.

chickens-standup-edersonmelo

Ele deve manter atenção constante ao status do projeto em relação ao progresso esperado. Investigar e facilitar a resolução de quaisquer obstáculos que imobilizam o progresso e, geralmente, ser flexível o suficiente para identificar e lidar com quaisquer problemas que surjam. Ele deve proteger a equipe de perturbações externas.

O Scrum Master não atribui tarefas aos membros da equipe, isso é uma responsabilidade da equipe. Sua abordagem geral para a equipe é incentivá-la e facilitá-la na capacidade de tomada de decisões e resolução de problemas relacionados ao desenvolvimento, de modo que eles possam trabalhar com maior eficiência sem a necessidade de supervisão. Seu objetivo é ter uma equipe auto-organizável.

 E finalmente, Scrum Team

O Scrum Team é a equipe de desenvolvimento sem a necessidade de uma divisão funcional através de papéis tradicionais, tais como programador, designer, analista de testes ou arquiteto. Todos no projeto trabalham juntos para completar o conjunto de trabalho com o qual se comprometeram conjuntamente para um Sprint.

O Scrum Team é auto organizável, ou seja, quem decide quem faz o que, quais as funções de cada membro e o que cabe ou não na Sprint é o time.

Um Scrum Team típico tem de 6 a 10 pessoas, embora haja relatos de projetos Scrum com equipes maiores. A principal abordagem para trabalhar com equipes grandes no Scrum é usando o conceito de “Scrum of Scrums“.

edersonmelo-all-blacks-scrum

Cada Scrum Team trabalha normalmente, mas cada equipe também contribui com uma pessoa que deverá frequentar o Scrum of Scrums Meeting para coordenar o trabalho de múltiplas equipes Scrum. Esses encontros são análogos aos Daily Scrums, mas não acontecem necessariamente todos os dias. Fazer essa reunião duas ou três vezes por semana tende a ser suficiente na maioria das organizações.

Veja a importância efetiva de cada grupo definido no SBOK. Oportunizando a todos o mesmo grau de importância e compreensão do todo.

 

Pai do Pedro, Marido e Workaholic com vida social. Mais em https://www.edersonmelo.com/quem-sou/

Scrum of Scrums

Iniciado os estudos para Certificação Scrum, me deparo com boa parte que acabei aprendendo mas não utilizando, como o Scrum of Scrums (SoS) , que nada mais é que uma importante técnica para escalar Scrum em grande times e projetos.  Trabalhada em reuniões que permitem agrupar os times para discutir seus trabalhos, focando especialmente em área de sobreposição e integração.”

Definição

Uma técnica para escalar Scrum em grupos grandes (mais de 6 pessoas), consistindo em dividir os grupos em equipes Agile de 5-10. Cada Daily dentro de uma sub-equipe termina designando um membro como “embaixador” para participar de uma reunião diária com embaixadores de outras equipes, chamado Scrum of Scrums.

Dependendo do contexto, os embaixadores podem ser contribuidores técnicos, ou Scrum Master de cada equipe, ou gerentes de cada equipe.

O Scrum of Scrums transcorre como uma reunião diária normal, com os embaixadores que informam as conclusões, as próximas etapas e impedimentos em nome das equipes que representam. Espera-se que a resolução de impedimentos se centre nos desafios da coordenação entre as equipes; As soluções podem implicar concordar com interfaces entre equipes, negociar limites de responsabilidade, …

O Scrum of Scrum realiza seu acompanhamento dos itens através de um backlog próprio, onde cada item contribui para melhorar a coordenação entre equipes. Neste ponto consigo ver várias oportunidades de implementações em equipes de Sustentação de Sistemas, como a que eu trabalho hoje.

Lendo diversos artigos para buscar entender limitações e pontos onde a aplicação venha a aparesentar baixa performance ou qualquer entrave, cheguei a Allan Shalloway, que preve alguns problemas em praticar Scrum com grupos grandes (350 pessoas ou mais). Neste caso há vários diferentes produtos sendo construídos com componentes compartilhados. Ele cita 3 exemplos de problemas que ocorreram:

  • Nível Técnico. Dado que estávamos fazendo desenvolvimento iterativo, os times esperam seguir princípios de design emergente. Isso significa que estamos escrevendo código de qualidade, mas não adicionamos funcionalidade ou design até que eles sejam necessários.
  • Nível Inter Times. A forma como os times trabalham juntos quando há diferentes Product Owners e Scrum Masters para cada time, nem sempre é tão óbvia. Mais uma vez, uma visão mais abrangente ajuda. Isso é especialmente verdade quando há um time de componentes fazendo trabalho de suporte para vários outros times. Orientar-se através de business value requer olhar através dos product owners. Eles podem cooperar, porém, mais uma vez, eles podem não cooperar.
  • Nível de Estrutura do Time. Muitos times scrum trabalhando juntos tem problemas sérios para entregar uma funcionalidade final quando muitos times estão envolvidos.

Já Mike Dwyer diz preferir o SoS e Meta Scrums: “para coordenar a decomposição de estórias, de forma que assim você não termina com a mesma coisa construída por vários times. Aquelas coisas devem ser trabalhadas através de conversas diárias e frequentes que ocorrem em todos os níveis.” Em sua experiência, times bem conduzidos focam na infraestrutura, dados e arquitetura para fazer um bom trabalho de reunir código compartilhado.

O que mais acabaremos encontrando como receita para o sucesso da reunião Scrum of Scrums será o que todos já devemos ter em mente: “Manter a reunião curta. 15 minutos no máximo. Mantenha-a focada. O que os outros querem/precisam ouvir? Discussões devem ser reservadas para uma reunião separada para manter a reunião curta e focada. Traga os problemas que bloqueiam para cada reunião SoS até que sejam resolvidos.

Espero que tenham costado e que curtam. Conforme meu aprofundamento na metodologia e a leitura e entendimento do SBOK irei compartilhar mais conhecimento.

Pai do Pedro, Marido e Workaholic com vida social. Mais em https://www.edersonmelo.com/quem-sou/

Como você pode aprender a programar!?

Lendo algumas matérias e assistindo alguns vídeos sobre Como aprender a Programar, cheguei até a imagem postada no fim do texto. Originária da freecodecamp ela exemplifica bem alguns níveis que o desenvolvedor terá de passar.  Não pense que hoje e futuramente se aplicará a ideia de que: Eu só sei fazer a linguagem x back-end e fim. Além de ridículo acho extremamente anti profissional.

Recentemente , várias visualizações incríveis das várias tecnologias utilizadas pelos desenvolvedores web em 2017 surgiram no web.

Estes são ótimos recursos para principiantes e especialistas. Eles definem claramente quais tecnologias você deve estar ciente de se você deseja obter um emprego como desenvolvedor web frontend, desenvolvedor web backend ou administrador do sistema.

Mas acho que eles são especialmente úteis para iniciantes absolutos aprendendo suas primeiras linhas de código.

Então, ao invés de gastar seu tempo tentando aprender cada linguagem e tecnologia de programação, você deve aprender o que todo desenvolvedor já deve saber:

Saiba como ler a documentação
Saiba como ler código-fonte
Saiba como depurar o código
Saiba como pedir ajuda

Dá uma olhada e se gostou, curte aí. Obrigado.

Pai do Pedro, Marido e Workaholic com vida social. Mais em https://www.edersonmelo.com/quem-sou/

A eficiência de um Post-it em um quadro de tarefas

Voltando a colar Post-it em um Quadro de Tarefas chega a renovar os ânimos. Não que eu queira ficar colando bloquinhos coloridos, mas pelas possibilidades de renovação em um cenário caótico.

Mesmo usando ferramentas como ALM e Trello, nada substitui um bom Quadro de Tarefas na parede.  Mas não pense em um super Quadro de Tarefas com desenhos de personagens representando cada colaborador, multi colorido, com frases engraçadas. Pense num Quadro de Tarefas padrão com post-it’s simples.

Quando se chega a um ponto do desenvolvimento e você chegar a precisar muito disso e consegue uma brecha para criar você vai entender.  Você vai colocar sua energia, faz o seu melhor, busca técnicas e pode não agradar a todos, mas vale cada segundo.

Um bom Quadro de Tarefas gera motivação sim, todos se reúnem na frente, discutem, novos itens surgem enquanto outros são consumidos e outros priorizados.

Um Quadro de Tarefas é muito fácil, todos entendem, mas não serve de forma alguma como documentação, não vejo esse desejo ou pretensão de que um post-it seja uma forma de matar documentação, bem pelo contrário, é um incentivo a documentar cada etapa. Nada impede que você crie uma tarefa para documentar e ela seja colocada no quadro em um post-it.

Um bom Quadro de Tarefas organiza o trabalho da equipe, você enxerga quem esta fazendo o que, você sabe que talvez um esteja com 3 tarefas e que outro esta com 1 que vale por quatro(neste caso, vale quebrar a tarefa), neste momento você entende a frase 1 post-it + 1 post-it = 3 post-its. Isso porque você enxerga o quanto você produziu em equipe.

Bom, só para ficar o registro de como é legal criar um Quadro de Tarefas e usar post-its. Eu tenho um em casa, tenho ele replicado na minha tela do note através do windows notes. Posso me considerar um fã desta técnica e um eterno aprendiz.

Pai do Pedro, Marido e Workaholic com vida social. Mais em https://www.edersonmelo.com/quem-sou/

Pivotar em uma Startup

Tenho assistido o programa da History: Futuros Milionários, onde jovens millenials se inscrevem na multimilionária e excêntrica Universidade de Tim Draper para empreendedores.

Então ouvi novamente sobre o termo: Pivotar. De forma muito simples, é você rever seu negócio e se for o caso, redirecionar sua ideia de forma a retomar a vida da sua startup.

O termo pivot surgiu com Eric Ries, um norteamericano, famoso por desenvolver seu trabalho junto a startups em empreendimentos de alta tecnologia. Eric desenvolveu um método de gestão conhecido como Lean Starturp, que é baseado na eliminação constante de desperdícios e se baseia na tríade Construir, Medir e Aprender.

Na segunda e terceira etapa é onde fica o Pivot, já que se trata de saber mensurar se o seu negócio está atingindo o potencial desejado e, caso contrário, aprender como fazer com que seu modelo de negócio seja mais eficiente.

 

Pai do Pedro, Marido e Workaholic com vida social. Mais em https://www.edersonmelo.com/quem-sou/

Vou tentar acordar às 5 da manhã

Já ouviram falar do 5am club? É o poderoso é o intervalo das 5 às 8 da manhã. Mas nem todos estamos dispostos a acordar às 5 da manhã por escolha própria, mas é exatamente isso que fazem as pessoas mais bem sucedidas do mundo, a turma do 5am club ou “high achievers”.

Dentre eles estão Richard Branson (da Virgin), Tim Cook (CEO da Apple),  Robert Iger (da Disney), Howard Schultz (do Starbucks), Benjamin Franklin, etc.

 

Tenho tentando melhorias mais minha performance e produtividade, e isso é impossível durante a noite, então porque não estender minhas manhãs?

A ideia é começar agora na volta das férias e no início do próximo ano já estar totalmente habituado.

 

Tem uma expressão muito comum no inglês que define bem isso, “head start”. A ideia é simples: quando você acorda e 99% das pessoas ainda estão dormindo você começa o dia com vantagem e sua força de vontade no máximo. A preguiça deveria deixa de existir.

 

Começando o dia antes, é começar do jeito certo. E para isso precisarei criar novos hábitos e métodos, então, vamos as pesquisas.

Uh, pensei em registrar isso no snap. Vamos evoluir a ideia.

 

Pai do Pedro, Marido e Workaholic com vida social. Mais em https://www.edersonmelo.com/quem-sou/

Um Pouco de UX Design

Li sempre bons livros sobre Design e os dois últimos, um do Fabrício Teixeira, Introdução e boas práticas em UX Design, que fala muito bem de forma básica e que recomendo para quem estiver começando ou querendo aprender. Outro  livro, do Rafael Cardoso intitulado: Design para um mundo complexo, que ainda estou lendo.

Basicamente o design nasceu com o propósito de pôr ordem no mundo industrial. Entre meados do século XVIII e fins do século XIX , que temos como o surgimento do sistema de fábricas em boa parte da Europa e dos Estados Unidos – houve um aumento da oferta de bens de consumo, combinado com queda concomitante do seu custo, ambos provocados por mudanças de organização e tecnologia produtivas, sistemas de transporte e distribuição.

Nunca antes na história da humanidade, tantas pessoas haviam tido a oportunidade de comprar tantas coisas. Era a infância da sociedade de consumo. Para muitos observadores, à época, o processo teria gerado um declínio preocupante da qualidade e da beleza dos produtos. Certa ou errada (o que é bem mais provável), essa percepção serviu de estímulo para a ação. Entraram em campo artistas e arquitetos, reformadores e burocratas, governos, industriais, associações comerciais e profissionais, museus e instituições de ensino, com o intuito de melhorar o gosto da população e a configuração das mercadorias que lhes eram oferecidas. As atividades de projetar e fabricar artefatos, exercidas há muito em relativo silêncio, migraram para o centro dos debates políticos, econômicos e sociais.

(Livro Design para um mundo complexo)

User Experience Design

Existe muito trabalho intelectual de pesquisa de um verdadeiro UX Designer que é um questionador constante. Desde que trabalho na TI como um todo, conheci muitos profissionais de Design e principalmente de Webdesign, acompanhei o surgimento do termo UX Designer e vi profissionais que sempre fizeram este trabalho se encaixar de forma autônoma ao termo.

Continue reading

Pai do Pedro, Marido e Workaholic com vida social. Mais em https://www.edersonmelo.com/quem-sou/
Older posts

© 2017 EM2

Theme by Anders NorenUp ↑

%d blogueiros gostam disto: