Há 2 meses eu disse aqui na empresa que designer e analista de teste deveriam projetar sistemas ao invés dos analistas de projetos e requisitos. Quase apanhei de alguns, ainda mais trabalhando numa empresa de TI. Vamos lá...
Um projeto deve ser visto como um todo, desde o início (necessidades e solicitações do cliente) ao seu fim (satisfação do usuário). E se o fim nunca chega, se não funciona ou se usuário sequer consegue acessá-lo?
Testers fazem tarefas muito próximas com as do designer e idênticas em teste de usabilidade. Eles não se preocupam somente se o sistema funcionou, ou se os casos de usos estão corretos ou se trouxe os dados certos após uma alteração. Eles também se preocupam como os usuários acessam o sistema.
Testers pensam como usuário, assim como os designers. Testers têm uma visão macro do projeto e dos níveis de acesso, podendo entrar na visão micro em determinados casos de uso e voltar ao macro em seguida. E o designer? Será que não faz o mesmo?
E se um sistema fosse "brifado" por uma pessoa errada, sem essa visão do todo, o que seria do projeto e do repasse das informações para o restante da equipe? Já vi requisitos fora do contexto de negócio e na contramão do caso de uso e interface.
Respeito o PMI, já fiz curso de gerente de projeto, trabalho com muitos analistas em diversos projetos mas poucos conseguem ver além dos antolhos, até mesmo para pequenas coisas que estão a frente da margem da sua especializade. Até mesmo para soluções simples e banais. Isso não ocorre só em TI, mas eu vejo muito mais forte em áreas técnicas, pois parece que as pessoas têm medo de errar, de serem punidas, de sair da linha do certinho e do documentado. O grande problema é que isso limita o interesse no outro lado da fronteira e fecha o conhecimento. Voto na experimentação, na pesquisa, nos testes e nos estudos de caso... e por isso eu retorno ao título deste post.
Esse texto partiu de uma conversa com duas amigas que são Testers. Cogitamos a idéia de um dia gerenciar um projeto e elas me deram razão nos pontos que levantei. E você?
terça-feira, 12 de janeiro de 2010
quinta-feira, 30 de julho de 2009
Tok&Stok, LaMole, Claro, sistemas e demandas
Recentemente eu e minha esposa trocamos de cama... na verdade queríamos trocar apenas o colchão pois gostávamos da cama antiga por ser forte, bonita, simples de montar, ter design assinado, etc.
Fomos na Tok&Stok para pesquisar preços e acho legal quando eles usam o site para consulta e não aqueles sistemas em delphi na cor azul ou verde. Perguntamos se a atendente sabia qual era o modelo certo para a nossa cama e ela prontamente abriu um sistema (não web, argh) com todos os dados das compras da minha esposa:
- "Seu colchão é da cama Mirage, tem 148 por 198 cm, 16 cm de altura, densidade 26 e já está bastante antigo pois foi comprado em 99 "
Olhamos um para o outro e ficamos espantados com o tipo de informação que eles tinham! Várias compras delas estavam no sistema. Coisas velhas, coisas que nem mais existem, coisas que poderiam ser trocadas...
Voltando para a casa pensei: Por que a Tok&Stok não integra esse sistema com o site, usa o cookie de login, meus históricos de compras, meu histórico de navegação (com permissão é claro) e oferece um colchão novo? A Tok&Stok é uma das lojas que mais investe em tecnologia e seus produtos são monitorados e controlados via RFID nos galpões e por que não investir num sistema inteligente de CRM para fidelizar mais clientes e vender mais?
Outra situação é com o restaurante La Mole, bem tradicional aqui no Rio de Janeiro. Um tempo atrás nós pediamos quase todos os domingos o nosso almoço pelo site. Seguíamos a mesma linha de prato variando apenas os acompanhamentos. Disse uma vez para minha esposa: "E por que eles não enviam um cardápio antecipado para o fim de semana já que vamos pedir mesmo?" Sei que é mais complicado mas pedido online de comida é algo que nunca vi case de sucesso... e por que não começar um?
Há 6 meses trocamos de aparelho e de operadora de celular. Na época do dia dos namorados eu estava doido pelo Nokia E71 e sempre ligava para a Claro pedindo descontos, implorando para ter o aparelho e nada. Um dia fomos na TIM e vimos uma promoção de portabilidade para o Nokia 5800. A promo era: 99 reais cada aparelho, 3 meses de conta gratuita, 1 ano grátis para baixar música e "n" benefícios! Liguei para a Claro para contraproposta e ninguém faz nada para segurar um cliente de 10 anos de relacionamento... e pediram para ligar na segunda pois o sistema estava fora do arrrrrrrrrrrrrr!!!
Se a atendente tivesse um relatório das minhas ligações (deveria servir pra isso os tais protocolos) bastava ver que eu estava negociando há meses o E71 sem sucesso. Não seria hora da operadora ceder e oferecer o aparelho em melhores condições já que eu estava na porta da concorrente? E o pior, se ela fizesse isso eu ficava com a Claro! Como o relacionamento nunca foi tratado como CRM de fato e como eu já estava no limite cancelei tudo e fui para a outra operadora sem pestanejar.
Fico parado em pensar que vivemos em uma época de alta tecnologia, de banda larga, de sistema de controles avançados (e free) somados a falta de visão e a falta de treinamento para que as empresas façam um CRM direto e pessoal com o cliente. Quem sabe com a explosão da rede social e o boca-a-boca algo não mude para o bem de todos.
Ah, acabamos dando a cama para um amigo, compramos uma cama box de molas na ETNA (concorrente da Tok&Stok), nunca mais pedimos comida do LaMole e estamos felizes na TIM.
Fomos na Tok&Stok para pesquisar preços e acho legal quando eles usam o site para consulta e não aqueles sistemas em delphi na cor azul ou verde. Perguntamos se a atendente sabia qual era o modelo certo para a nossa cama e ela prontamente abriu um sistema (não web, argh) com todos os dados das compras da minha esposa:
- "Seu colchão é da cama Mirage, tem 148 por 198 cm, 16 cm de altura, densidade 26 e já está bastante antigo pois foi comprado em 99 "
Olhamos um para o outro e ficamos espantados com o tipo de informação que eles tinham! Várias compras delas estavam no sistema. Coisas velhas, coisas que nem mais existem, coisas que poderiam ser trocadas...
Voltando para a casa pensei: Por que a Tok&Stok não integra esse sistema com o site, usa o cookie de login, meus históricos de compras, meu histórico de navegação (com permissão é claro) e oferece um colchão novo? A Tok&Stok é uma das lojas que mais investe em tecnologia e seus produtos são monitorados e controlados via RFID nos galpões e por que não investir num sistema inteligente de CRM para fidelizar mais clientes e vender mais?
Outra situação é com o restaurante La Mole, bem tradicional aqui no Rio de Janeiro. Um tempo atrás nós pediamos quase todos os domingos o nosso almoço pelo site. Seguíamos a mesma linha de prato variando apenas os acompanhamentos. Disse uma vez para minha esposa: "E por que eles não enviam um cardápio antecipado para o fim de semana já que vamos pedir mesmo?" Sei que é mais complicado mas pedido online de comida é algo que nunca vi case de sucesso... e por que não começar um?
Há 6 meses trocamos de aparelho e de operadora de celular. Na época do dia dos namorados eu estava doido pelo Nokia E71 e sempre ligava para a Claro pedindo descontos, implorando para ter o aparelho e nada. Um dia fomos na TIM e vimos uma promoção de portabilidade para o Nokia 5800. A promo era: 99 reais cada aparelho, 3 meses de conta gratuita, 1 ano grátis para baixar música e "n" benefícios! Liguei para a Claro para contraproposta e ninguém faz nada para segurar um cliente de 10 anos de relacionamento... e pediram para ligar na segunda pois o sistema estava fora do arrrrrrrrrrrrrr!!!
Se a atendente tivesse um relatório das minhas ligações (deveria servir pra isso os tais protocolos) bastava ver que eu estava negociando há meses o E71 sem sucesso. Não seria hora da operadora ceder e oferecer o aparelho em melhores condições já que eu estava na porta da concorrente? E o pior, se ela fizesse isso eu ficava com a Claro! Como o relacionamento nunca foi tratado como CRM de fato e como eu já estava no limite cancelei tudo e fui para a outra operadora sem pestanejar.
Fico parado em pensar que vivemos em uma época de alta tecnologia, de banda larga, de sistema de controles avançados (e free) somados a falta de visão e a falta de treinamento para que as empresas façam um CRM direto e pessoal com o cliente. Quem sabe com a explosão da rede social e o boca-a-boca algo não mude para o bem de todos.
Ah, acabamos dando a cama para um amigo, compramos uma cama box de molas na ETNA (concorrente da Tok&Stok), nunca mais pedimos comida do LaMole e estamos felizes na TIM.
sexta-feira, 24 de julho de 2009
Pra que CAPTCHA?
"Designer... Como é o nome daquela sopa de letrinhas tortas que coloca num formulário? Aquela que a gente não consegue ler nada e que não é acessível... Aquela com nome difícil?"
CAPTCHA ou "Completely Automated Public Turing test to tell Computers and Humans Apart" foi criada para testes não automatizados onde o ser humano consegue intervir validando alguma informação antes de completar uma ação.
As CAPTCHAS foram muito difundidas para evitar o SPAM (lembra que saco o UOL?) e ainda utilizadas em vários provedores. De algum tempo para cá, foram aplicadas para validar consultas ou cadastro em formulários evitando ataque robôs como invasões e DoS (Denial of Service) derrubando o servidor. Escutei uma vez a melhor explicação sobre DoS de um analista de rede: "Seria como todos os carros da Avenida Presidente Vargas (RJ) querendo entrar numa rua muito estreita na hora do rush... colapso total!"
Assim como um javascript ou layout ou css pronto para copiar na internet, alguns CAPTCHAS podem ser baixados e instalados em diversos modelos e linguagens de programação. Realmente ele evita (eu disse evita) invasões e ataques, entrada de SQL Injection no seu bando de dados, burlamento de cadastros, reutilização de serviços web e etc. O problema maior do CAPTCHA é como usar, onde usar e principalmente para quem usar.
Um analista desenvolvedor explicou o funcionamento dos robôs de quebra de CAPTCHA. Uma ou mais máquinas robôs acessam o site a invadir e ficam tentando várias combinações de letras e números. Quanto maior a combinação (5 caracteres em diante), mais difícil e mais tempo para efetuar a quebra. Alguns outros robôs utilizam softwares de OCR (Optical Character Recognition) que fazem um scan na tela e no código, acham a imagem do CAPTCHA e tentam detectar os caracteres submetendo várias combinações até que se entre na aplicação.
Há dois anos participei de um projeto para o Ministério do Trabalho e Emprego onde um aplicativo importante precisava de um maior nível de segurança devido ao número de informações ali trafegadas. Para se ter uma idéia, em dias críticos, eram 2.500 usuário simultâneos em cada servidor.
A solução encontrada foi criar um aplicativo oriundo do .Net que sorteia uma sequência de 7 figuras aleatórias, dentre mais de 200 variações de letras e números e 10 fundos diferentes, compondo uma única imagem final. Desde sua implementação, o servidor nunca sofreu ataques e ninguém conseguiu burlar o código e, mesmo assim, estamos aprimorando uma nova versão para inibir ainda mais o acesso dos robôs.
Mas nem tudo são flores...
Ainda na mesma empresa, só que em outro projeto também para o Ministério do Trabalho e Emprego, usou-se uma outra solução CAPTCHA que deu o que falar na semana passada! Veja a matéria no O Globo.
Esse modelo de CAPTCHA utilizava um arquivo de dicionário que sorteava uma delas e montava uma grid igual a "palavra cruzada" onde apenas a palavra escolhida estava escrita corretamente. Visualmente é um pouco confuso e difícil de entender mas interessante pelo modo simples de usar. A falha do projeto foi não validar as mais de 3 mil palavras deste dicionário! Tudo bem que a probabilidade de "acertar" uma delas é pequena mas não nula! Isso sem contar que o arquivo deste dicionário ficava na raiz do site, sem proteção e pedindo para ser hackeado!
Três soluções temporárias e rápidas poderiam ter sido feitas, além do teste das palavras do dicionário é claro:
1) Escolher 30 palavras sem duplo sentido para cada letra do alfabeto (casa, vaso, cartaz, mesa, etc).
2) Barrar acessos múltiplos e simultâneos do mesmo endereço IP.
3) Validar um campo obrigatório que o sistema solicitava antes do CAPTCHA.
Como nós não participamos desta solução CAPTCHA e muito menos fomos envolvidos, só tomamos conhecimento quando estourou a bomba na mídia! A falta de comunicação e a pseudo autosuficiência (não precisamos de designer e nem de analista de testes) do tal projeto ajudou a piorar a situação.
Por essas e outras defendo com unhas e dentes a criação de Wikis e Melhores Práticas no intuito de disseminar o conhecimento entre os projetos e as áreas de uma empresa. A Gestão do Conhecimento foi criada não só para descentralizar a informação mas para que esta seja difundida e aplicada para o bem estar mental e financeiro de uma empresa. Pense, analise o impacto desta notícia e o quanto ela denegriu a imagem do Ministério do Trabalho e Emprego (10h após a publicação da matéria tinham 180 comentários no Globo Online) e da empresa prestadora de serviço.
E quanto a acessibilidade? O CAPTCHA é acessível a todos usuários? Nem todos, mesmo os que possuem recursos de audio onde um programa lê os caracteres que estão na tela. Isso é uma discussão enorme e precisaria chamar o Horácio Soares para debater o tema. Certo que de uma coisa concordamos: pense bem pra quem (cliente) e como (linguagem) usar um CAPTCHA. Analise e veja se realmente é necessário. Quem sabe não existe uma outra forma mais agradável e acessível para validar um acesso?
CAPTCHA ou "Completely Automated Public Turing test to tell Computers and Humans Apart" foi criada para testes não automatizados onde o ser humano consegue intervir validando alguma informação antes de completar uma ação.
As CAPTCHAS foram muito difundidas para evitar o SPAM (lembra que saco o UOL?) e ainda utilizadas em vários provedores. De algum tempo para cá, foram aplicadas para validar consultas ou cadastro em formulários evitando ataque robôs como invasões e DoS (Denial of Service) derrubando o servidor. Escutei uma vez a melhor explicação sobre DoS de um analista de rede: "Seria como todos os carros da Avenida Presidente Vargas (RJ) querendo entrar numa rua muito estreita na hora do rush... colapso total!"
Assim como um javascript ou layout ou css pronto para copiar na internet, alguns CAPTCHAS podem ser baixados e instalados em diversos modelos e linguagens de programação. Realmente ele evita (eu disse evita) invasões e ataques, entrada de SQL Injection no seu bando de dados, burlamento de cadastros, reutilização de serviços web e etc. O problema maior do CAPTCHA é como usar, onde usar e principalmente para quem usar.
Um analista desenvolvedor explicou o funcionamento dos robôs de quebra de CAPTCHA. Uma ou mais máquinas robôs acessam o site a invadir e ficam tentando várias combinações de letras e números. Quanto maior a combinação (5 caracteres em diante), mais difícil e mais tempo para efetuar a quebra. Alguns outros robôs utilizam softwares de OCR (Optical Character Recognition) que fazem um scan na tela e no código, acham a imagem do CAPTCHA e tentam detectar os caracteres submetendo várias combinações até que se entre na aplicação.
Há dois anos participei de um projeto para o Ministério do Trabalho e Emprego onde um aplicativo importante precisava de um maior nível de segurança devido ao número de informações ali trafegadas. Para se ter uma idéia, em dias críticos, eram 2.500 usuário simultâneos em cada servidor.
A solução encontrada foi criar um aplicativo oriundo do .Net que sorteia uma sequência de 7 figuras aleatórias, dentre mais de 200 variações de letras e números e 10 fundos diferentes, compondo uma única imagem final. Desde sua implementação, o servidor nunca sofreu ataques e ninguém conseguiu burlar o código e, mesmo assim, estamos aprimorando uma nova versão para inibir ainda mais o acesso dos robôs.
Mas nem tudo são flores...
Ainda na mesma empresa, só que em outro projeto também para o Ministério do Trabalho e Emprego, usou-se uma outra solução CAPTCHA que deu o que falar na semana passada! Veja a matéria no O Globo.
Esse modelo de CAPTCHA utilizava um arquivo de dicionário que sorteava uma delas e montava uma grid igual a "palavra cruzada" onde apenas a palavra escolhida estava escrita corretamente. Visualmente é um pouco confuso e difícil de entender mas interessante pelo modo simples de usar. A falha do projeto foi não validar as mais de 3 mil palavras deste dicionário! Tudo bem que a probabilidade de "acertar" uma delas é pequena mas não nula! Isso sem contar que o arquivo deste dicionário ficava na raiz do site, sem proteção e pedindo para ser hackeado!
Três soluções temporárias e rápidas poderiam ter sido feitas, além do teste das palavras do dicionário é claro:
1) Escolher 30 palavras sem duplo sentido para cada letra do alfabeto (casa, vaso, cartaz, mesa, etc).
2) Barrar acessos múltiplos e simultâneos do mesmo endereço IP.
3) Validar um campo obrigatório que o sistema solicitava antes do CAPTCHA.
Como nós não participamos desta solução CAPTCHA e muito menos fomos envolvidos, só tomamos conhecimento quando estourou a bomba na mídia! A falta de comunicação e a pseudo autosuficiência (não precisamos de designer e nem de analista de testes) do tal projeto ajudou a piorar a situação.
Por essas e outras defendo com unhas e dentes a criação de Wikis e Melhores Práticas no intuito de disseminar o conhecimento entre os projetos e as áreas de uma empresa. A Gestão do Conhecimento foi criada não só para descentralizar a informação mas para que esta seja difundida e aplicada para o bem estar mental e financeiro de uma empresa. Pense, analise o impacto desta notícia e o quanto ela denegriu a imagem do Ministério do Trabalho e Emprego (10h após a publicação da matéria tinham 180 comentários no Globo Online) e da empresa prestadora de serviço.
E quanto a acessibilidade? O CAPTCHA é acessível a todos usuários? Nem todos, mesmo os que possuem recursos de audio onde um programa lê os caracteres que estão na tela. Isso é uma discussão enorme e precisaria chamar o Horácio Soares para debater o tema. Certo que de uma coisa concordamos: pense bem pra quem (cliente) e como (linguagem) usar um CAPTCHA. Analise e veja se realmente é necessário. Quem sabe não existe uma outra forma mais agradável e acessível para validar um acesso?
sexta-feira, 17 de julho de 2009
Pra que agenda? Faça o jogo dos 7 erros.
Cliente chatos, jobs "brifados" errado, chefes que não te entendem, prazos absurdos... nada de novo não é? O problema é que isso não para por aí e sempre aparecem novas modalidade que cada vez mais impactam no bom andamento de um projeto e principalmente na motivação e satisfação da equipe.
Fiquei surpreso em saber que existem empresas que delegam "agenda diária" para seus colaboradores! Ok, nosso dia é uma agenda mesmo, mas limitá-la a janelas de tempo é algo inusitado. Vejam o exemplo abaixo onde o chefe comunica ao designer:
"Veja sua agenda de hoje, que EU programei, e está no Google Docs da empresa:
9:00 - 11:00 = Criar nova home do portal XPTO
11:00 - 13:00 = Criar 3 novos banners para o site XYZ
13:00 - 14:00 = Ajustar o CSS que está dando erro no hotsite ABC
14:00 - 15:30 = Animar flash que o cliente ainda vai mandar os psds
15:30 - 17:30 = Refazer a home do mobile site que o cliente ainda não viu mas vai reclamar
17:30 - 18:00 = Ponto de controle do dia"
Quem se habilita ao jogo dos 7 erros?
1) O colaborador não almoça.
Onde está a hora de almoço? Precisamos comer, assim como respirar, sair um pouco do ar da empresa e integrar com a equipe também fora do ambiente de trabalho.
2) O chefe cria a SUA agenda e estipula prazos sem lhe consultar.
Mensurar prazos sem ao menos perguntar ou negociar com o executor com certeza geram ruídos e desgates entre os membros da equipe, insatisfação, falta de confiança na gerência, autoritarismo e, por fim, métricas ineficientes de avaliação de esforço. Esta última é fundamental na análise do ROI (Return On Investment) e item importante nas avaliações do CMMI (Capability Maturity Model Integration)
3) É mais que comprovado que o dia de trabalho tem 5h.
Ninguém trabalha 8h por dia! Lemos emails, tratamos ocorrências, levantamos informações, almoçamos (sim nós somos mortais e comer é uma necessidade básica do ser humano), pesquisamos algo no google, analisamos erros, procuramos novas idéias na web, escovamos os dentes, tomamos um café... Leve em consideração essas informações e aloque 5h diárias de real esforço dos seus colaboradores ao montar um plano de projeto, seja no Google Docs, MS Project, BaseCamp ou outra ferramenta.
4) Refazer algo que o cliente sequer viu/aprovou.
Para que desgastar a equipe com retrabalho desnecessário? Tem gestor que odeia ver a equipe parada mesmo que esta tenha feito um ótimo job! Perca um bom tempo para um briefing claro, objetivo e que atenda a todos os steakholders. Envolva sua equipe com o projeto, troque idéias, analise diversos pontos de vistas e dê foco no usuário! Quanto maior a interação e alinhamento de idéias no início do projeto, menos problemas de definições terão no futuro.
5) Ignorar o estress gerado por vários jobs simultâneos.
Ok, fazemos tudo ao mesmo tempo. Somos multitarefas e corremos contra o tempo mas estressar a equipe com diversos jobs diferentes e cobrá-los por igual pode até funcionar durante um tempo mas não sempre. Pense e aplique escala de importância nos jobs. Um ajuste de uma vírgula no texto tem tanta importância como uma promoção a ser publicada e com início daqui a 1 hora? Faça rodízio dos jobs entre a equipe e divida as entregas de um projeto por fases. Estresse menos o colaborador e o rendimento será melhor.
6) Executar algo sem base
De que adianta montar o html/css de um site sem ter em mãos o PSD pronto? Podemos adiantar tarefas e uní-las em um determinado ponto do projeto mas algumas são atividades sequenciais e dependentes. Analise e veja o que pode ser realmente adiantado e participe a decisão com o executor. Nem sempre o gestor tem idéia do que está se executando já que muitos não são técnicos ou especialistas naquela ferramenta.
7) Reuniões (des)necessárias?
Ponto de controle diário é realmente necessário? Reuniões de idéias, acompanhamento ou esporro? O gerente apenas quer conferir se as ordens foram cumpridas? Adote ponto de controles rápido (stand up meeting é uma saída) e esqueça a formalidade da sala de reunião. Faça um reunião rápida na mesa de um dos componentes da equipe ao invés da sua (gerente) e deixe que todos falem. APRENDA a elogiar e incentivar valores e até mesmo os erros, pois é com eles que se aprende e abre novas idéias!
Segregar, limar e não saber escutar críticas não é uma linha de gerenciamento. Infelizmente você (chefe) só perceberá quando não te chamarem mais para o almoço ou fugirem de você no café.
Bem, eu já fiz minha análise e você?
Fiquei surpreso em saber que existem empresas que delegam "agenda diária" para seus colaboradores! Ok, nosso dia é uma agenda mesmo, mas limitá-la a janelas de tempo é algo inusitado. Vejam o exemplo abaixo onde o chefe comunica ao designer:
"Veja sua agenda de hoje, que EU programei, e está no Google Docs da empresa:
9:00 - 11:00 = Criar nova home do portal XPTO
11:00 - 13:00 = Criar 3 novos banners para o site XYZ
13:00 - 14:00 = Ajustar o CSS que está dando erro no hotsite ABC
14:00 - 15:30 = Animar flash que o cliente ainda vai mandar os psds
15:30 - 17:30 = Refazer a home do mobile site que o cliente ainda não viu mas vai reclamar
17:30 - 18:00 = Ponto de controle do dia"
Quem se habilita ao jogo dos 7 erros?
1) O colaborador não almoça.
Onde está a hora de almoço? Precisamos comer, assim como respirar, sair um pouco do ar da empresa e integrar com a equipe também fora do ambiente de trabalho.
2) O chefe cria a SUA agenda e estipula prazos sem lhe consultar.
Mensurar prazos sem ao menos perguntar ou negociar com o executor com certeza geram ruídos e desgates entre os membros da equipe, insatisfação, falta de confiança na gerência, autoritarismo e, por fim, métricas ineficientes de avaliação de esforço. Esta última é fundamental na análise do ROI (Return On Investment) e item importante nas avaliações do CMMI (Capability Maturity Model Integration)
3) É mais que comprovado que o dia de trabalho tem 5h.
Ninguém trabalha 8h por dia! Lemos emails, tratamos ocorrências, levantamos informações, almoçamos (sim nós somos mortais e comer é uma necessidade básica do ser humano), pesquisamos algo no google, analisamos erros, procuramos novas idéias na web, escovamos os dentes, tomamos um café... Leve em consideração essas informações e aloque 5h diárias de real esforço dos seus colaboradores ao montar um plano de projeto, seja no Google Docs, MS Project, BaseCamp ou outra ferramenta.
4) Refazer algo que o cliente sequer viu/aprovou.
Para que desgastar a equipe com retrabalho desnecessário? Tem gestor que odeia ver a equipe parada mesmo que esta tenha feito um ótimo job! Perca um bom tempo para um briefing claro, objetivo e que atenda a todos os steakholders. Envolva sua equipe com o projeto, troque idéias, analise diversos pontos de vistas e dê foco no usuário! Quanto maior a interação e alinhamento de idéias no início do projeto, menos problemas de definições terão no futuro.
5) Ignorar o estress gerado por vários jobs simultâneos.
Ok, fazemos tudo ao mesmo tempo. Somos multitarefas e corremos contra o tempo mas estressar a equipe com diversos jobs diferentes e cobrá-los por igual pode até funcionar durante um tempo mas não sempre. Pense e aplique escala de importância nos jobs. Um ajuste de uma vírgula no texto tem tanta importância como uma promoção a ser publicada e com início daqui a 1 hora? Faça rodízio dos jobs entre a equipe e divida as entregas de um projeto por fases. Estresse menos o colaborador e o rendimento será melhor.
6) Executar algo sem base
De que adianta montar o html/css de um site sem ter em mãos o PSD pronto? Podemos adiantar tarefas e uní-las em um determinado ponto do projeto mas algumas são atividades sequenciais e dependentes. Analise e veja o que pode ser realmente adiantado e participe a decisão com o executor. Nem sempre o gestor tem idéia do que está se executando já que muitos não são técnicos ou especialistas naquela ferramenta.
7) Reuniões (des)necessárias?
Ponto de controle diário é realmente necessário? Reuniões de idéias, acompanhamento ou esporro? O gerente apenas quer conferir se as ordens foram cumpridas? Adote ponto de controles rápido (stand up meeting é uma saída) e esqueça a formalidade da sala de reunião. Faça um reunião rápida na mesa de um dos componentes da equipe ao invés da sua (gerente) e deixe que todos falem. APRENDA a elogiar e incentivar valores e até mesmo os erros, pois é com eles que se aprende e abre novas idéias!
Segregar, limar e não saber escutar críticas não é uma linha de gerenciamento. Infelizmente você (chefe) só perceberá quando não te chamarem mais para o almoço ou fugirem de você no café.
Bem, eu já fiz minha análise e você?
terça-feira, 14 de julho de 2009
Pra que Design?
"Ora, se o novo sistema já tem template, já tem css pronto, já tem a tecnologia definida, então, pra que design?"
Aposto que não só eu como várias pessoas já escutaram isso um dia. E por mais que você justifique sua competência, alguns cases, artigos e as troca de informação com pessoas no twitter não vão convencer o seu gerente.
Vejo várias pessoas comentando a mesma coisa: os projetos resumem-se a atender prazos sem a preocupação com quem está na outra ponta, ou seja, o usuário. Por conta disso, cria-se briefing errado, existem processos ruins, caimos na falta de comunicação e não envolvemos as áreas determinantes de um projeto. Com certeza o resultado final será um usuário completamente insatisfeito e um projeto fadado ao desastre.
Estudo recentes da IEEE mostram que apenas 25% dos projetos tendem ao sucesso. Em 1o anos pretende-se chegar a 100% propondo interações mais dinâmicas e efetivas entre as áreas de um projeto. Eis aí a questão deste post.
Design significa projeto (vide dicionários da língua inglesa). Design tem visão macro e consegue sempre descer até a visão micro. Design tem foco no usuário (vide alguns ideais da Bauhaus), seja ele qual for, pois qualquer projeto possui interface, como um sistema web, um celular, um carro, um painel, um cartaz, uma embalagem... tudo interage com o usuário fisicamente, emocionalmente e visualmente.
Não questiono aqui o papel de um gerente de projetos, mas tenho certeza que muitos deles não entendem o papel de um designer numa equipe. Designer não é front-end. Designer pode e deve ser envolvido em todas as fases de um projeto por ter uma concepção do todo e uma preocupação com o que vai ser entregue e não apenas cumprir prazos furados que são justificados com pizza, vouchers de taxi e tecnologia da moda.
Projetos não devem ser feitos PARA os gerentes e sim PARA o usuário. Desenvolver interfaces sem a mínima noção de UX (User eXperience), sem saber qual o público alvo, sem avaliar o ambiente e as reais necessidades do usuário são erros clássicos que devem ser tratados no início e, claro, mantidos no decorrer de um projeto.
Brinco que colocar um designer no final de um projeto é igual a passar canos e fios após o pedreiro ter levantado as paredes de uma casa. Design é muito mais que isso...
Aposto que não só eu como várias pessoas já escutaram isso um dia. E por mais que você justifique sua competência, alguns cases, artigos e as troca de informação com pessoas no twitter não vão convencer o seu gerente.
Vejo várias pessoas comentando a mesma coisa: os projetos resumem-se a atender prazos sem a preocupação com quem está na outra ponta, ou seja, o usuário. Por conta disso, cria-se briefing errado, existem processos ruins, caimos na falta de comunicação e não envolvemos as áreas determinantes de um projeto. Com certeza o resultado final será um usuário completamente insatisfeito e um projeto fadado ao desastre.
Estudo recentes da IEEE mostram que apenas 25% dos projetos tendem ao sucesso. Em 1o anos pretende-se chegar a 100% propondo interações mais dinâmicas e efetivas entre as áreas de um projeto. Eis aí a questão deste post.
Design significa projeto (vide dicionários da língua inglesa). Design tem visão macro e consegue sempre descer até a visão micro. Design tem foco no usuário (vide alguns ideais da Bauhaus), seja ele qual for, pois qualquer projeto possui interface, como um sistema web, um celular, um carro, um painel, um cartaz, uma embalagem... tudo interage com o usuário fisicamente, emocionalmente e visualmente.
Não questiono aqui o papel de um gerente de projetos, mas tenho certeza que muitos deles não entendem o papel de um designer numa equipe. Designer não é front-end. Designer pode e deve ser envolvido em todas as fases de um projeto por ter uma concepção do todo e uma preocupação com o que vai ser entregue e não apenas cumprir prazos furados que são justificados com pizza, vouchers de taxi e tecnologia da moda.
Projetos não devem ser feitos PARA os gerentes e sim PARA o usuário. Desenvolver interfaces sem a mínima noção de UX (User eXperience), sem saber qual o público alvo, sem avaliar o ambiente e as reais necessidades do usuário são erros clássicos que devem ser tratados no início e, claro, mantidos no decorrer de um projeto.
Brinco que colocar um designer no final de um projeto é igual a passar canos e fios após o pedreiro ter levantado as paredes de uma casa. Design é muito mais que isso...
Assinar:
Postagens (Atom)