Jogo dos Pobres (ou dos Recicladores)

Se você quer brincar, hoje eu venho compartilhando o Jogo dos Pobres.

Ou Jogo dos Recicladores pra ficar mais politicamente correto… Haha

Então, vamos lá! Que comecem os jogos!

• Se você transforma a toalha velha em pano de chão, marque 3 pontos;
• Se você transforma a embalagem do extrato de tomate em copo, some 3 pontos à sua pontuação;
  • Atenção: se o copo for de time de futebol, você leva pontuação dobrada nesse quesito! :P
• Se você transforma a embalagem de margarina em “tapaué”, tome mais 3 pontos;
• Se você transforma a embalagem de refrigerante em jarra d’água, adicione mais 3 pontos;
• Se você transforma a embalagem de sorvete em pote de feijão, já vai ganhando mais 5 pontos;
• Se você transforma a embalagem do mercado (é, ela mesma, a sacola) em saco de lixo, são mais 5 pontos direto;
• Se você come frango e/ou ovo mais de 6 vezes por semana, ganhou mais 5 pontos;
• Se você faz compras à prestação, some 7 pontos de uma vez só;
• Se você cobra as “tapaué” emprestadas, lá se vão mais 7 pontos pra você;
  • Atenção: se a “tapaué” não for original, você leva pontuação dobrada nesse quesito! :P
• Se você fila Wi-Fi nos comércios, faça o download de mais 7 pontos; haha
• Se você trabalha por necessidade, na sua renda virão mais 10 pontos!

E aí, macho!? Somou tudo direitinho?

• Se você errou a soma, ganhou mais 30 pontos nesse momento!

Então bora lá pros resultados:

• Se você fez mais de 10 pontos: PARABÉNS! Você ganhou o jogo!
• Se você fez mais de 30 pontos, ser pobre, digo, reciclador, está impregnado no seu DNA;
• Se você fez mais de 60 pontos, os seus amigos vão fazer uma vaquinha pra te ajudar e, nesse momento, você dobra a sua pontuação.

Valeu!

Ei, psiu, se liga…

Dá para ficar sabendo das novidades do blog pelas redes sociais. Sigam-me os bons!

        

Conheça a minha obra completa em:

> paulodetarso.art.br

Projeto do celular que pega fogo

Em uma relação de amor e ódio, já reverenciamos os smartphones aqui no blog:

> Os smartphones vão acabar?

> Smartphones cada vez mais incríveis

Mas celular que pega fogo foi a funcionalidade mais incrível de todas!

Incrível e indesejada...

> "Galaxy-gate" arranha imagem da Samsung

> Samsung descontinua Galaxy Note 7 e pede que usuários desliguem o aparelho

> Samsung oferece incentivo em dinheiro a consumidores por devolução do Note 7

> Samsung revela quantos Galaxy Note 7 substituídos no recall superaqueceram

> Samsung luta para limitar danos causados por recall do Galaxy Note 7

> Samsung Galaxy Note 7: What went wrong?

Impossível não lembrar de uma lenda urbana que circulava quando os primeiros celulares foram lançados. Ela dizia que o sinal de telefonia celular era prejudicial à nossa saúde. Agora, com WiFi e 3G para todas as bandas, é como se estivéssemos dentro de uma Matrix.

Ele era um dos celulares top de linha da Samsung, projetado para peitar o temido IPhone. Era do verbo não é mais. Encerrou precocemente a sua era (substantivo). Se era que dava para chamar de era um negócio tão fugaz.

O danado do bichinho começou a pegar fogo! Combustão espontânea. Uma funcionalidade incrível e indesejada.

Mirando na bateria, a Samsung preparou um mega-recall para substituí-la onde ela estivesse. Pense num recall caro!

E não é que o danado do bichinho recallizado começou a pegar fogo também?!

Dezenas de casos. Inclusive com queimaduras nos usuários. E o caso mais bizarro demandou a evacuação emergencial de um avião!

Aí a Samsung foi obrigada a jogar a toalha. É o fim das vendas do Galaxy Note 7. A Samsung está recolhendo todos os aparelhos distribuídos e vendidos. Inclusive, está enviando “kits de remoção segura” para os usuários, devolvendo o dinheiro pago e dando uma indenização mixuruca de 100 dólares. (Indenização essa que não vai evitar uma chuva de processos judiciais.)

Mas a maior humilhação de todas foi a empresa implorar para os seus clientes pelo-amor-de-deus manterem todos os celulares DESLIGADOS pra sempre!

O que fazer então com 2 milhões de celulares-bomba? Mandar pro Congresso Nacional do Brasil? :P Não, né?

A Samsung agora está tocando um projeto grandioso e caro para recolher todo esse lixo tecnológico e dar uma destinação a ele. Até mesmo para reciclar as peças e reusá-las em outros aparelhos haverá custos envolvidos.

Um prejuízo gigantesco mesmo para a empresa que é 20% do PIB da Coreia do Sul.

Ainda assim, pequeno, se comparado ao imenso prejuízo da marca. Ações da Apple já subiram. E os concorrentes do mercado de entrada já se animaram.

Eu sou simpatizante do Chelsea muito por conta de sua bela camisa azul. Pois em 2010, eu criei coragem e comprei uma cami$a oficial. Lá, bem grande, no peito, um patrocínio da SAMSUNG MOBILE. Depois de vários anos de uso e de várias lavagens, partes das letras do patrocínio sumiram e a marca ficou bem avariada. É parecido com o que ocorreu agora.

Essa resenha toda nos leva ao nosso livro Fazendo um projeto dar certo. O último capítulo é sobre Testes e eu termino o post com a introdução deste capítulo:

CAPÍTULO IX

TESTES

Se não está testado, não está pronto. Vale atentar também para a eficiência e a eficácia dos testes. O simples fato de fazer um teste ainda não garante que o produto esteja satisfatoriamente testado e seja um produto de qualidade. Precisamos de testes bem planejados, bem projetados e bem construídos.

Os testes são um grande dilema para as indústrias. Até quando continuar testando? Investir quanto em testes? Fato é que entregar produtos de má qualidade é desastroso para a imagem de uma empresa. Por exemplo, nos recalls das montadoras de automóveis é possível calcular o prejuízo financeiro – com divulgação, peças e serviços das oficinas. Já o prejuízo à marca é maior e mais difícil de calcular.

Com software não é diferente. É muito caro garantir matematicamente que um software funcionará em 100% das vezes em que for utilizado e de todas as formas possíveis. Os softwares ditos de missão crítica carecem de mais investimento em testes, pois suas falhas são potencialmente mais desastrosas. Garantida mesmo é a frustração quando apertamos um botão e não obtemos o resultado esperado.

Hoje, temos diversos tipos de testes: funcionais, unitários, integrados, automáticos, homologação, piloto, regressão, desempenho, sanidade, acessibilidade, usabilidade... Igualmente, há diversas ferramentas gratuitas ou pagas. A equipe deve conhecer bem tudo o que existe para manter o arsenal adequado para todos os testes do projeto.

Que testar é essencial, penso que está claro. Os custos de bons testes também podem ser estimados. Já os custos da falta de testes são intangíveis: podem significar o fim de um contrato, uma rescisão judicial, o fim da empresa, bem como uma baixa autoestima da equipe do projeto.

Este capítulo aborda diversos aspectos sobre testes. Tudo começa com um processo adequado de testes. Saber que tipos de testes utilizar nas diversas partes do sistema. Buscar a eficácia dos testes no sistema sem que a equipe precise despender mais esforço que o necessário.

Falamos também sobre a disponibilidade de ambientes adequados à execução dos testes. A falta de ambientes pode inviabilizar tudo, inclusive desperdiçar todo o esforço da construção dos testes. Executar os testes em ambientes inapropriados compromete seriamente os resultados obtidos.

Intimamente relacionadas ao processo de testes definido, estão as ferramentas que viabilizarão os testes. Elas também indicam que ambientes serão necessários. Ferramentas e ambientes podem representar grande parte dos custos dos testes.

Os dados de entrada para os testes constituem outro fator crítico de sucesso da estratégia de testes adotada. Se os dados não forem reais e ricos em variedade, os resultados dos testes estarão comprometidos. Se os dados não são reusáveis, o processo todo pode ficar muito caro. O acesso indevido a dados de produção pode resolver o problema dos testes e gerar novos problemas de segurança.

A discussão termina falando sobre a importância da boa utilização de testes automáticos no projeto. Trata-se da melhor forma de buscar eficiência e eficácia nos testes do projeto, com resultados duradouros.

Devemos pensar sempre grande e não podemos desconsiderar a possibilidade de construir a própria ferramenta de testes para o projeto, desde que essa decisão seja economicamente viável.

Se quiser ler mais Fazendo um projeto dar certo:

> Site do e-book Fazendo um projeto dar certo

POST SCRIPTUM

Depois de 21 meses de trabalho, de 101 posts publicados, de muito esforço intelectual, físico e financeiro, chegamos a 15 mil visualizações no Blog Fazendo um projeto dar certo!

É com um sentimento de imensa gratidão que eu me dirijo a cada um de vocês que dedicou uma partezinha do seu precioso tempo para as discussões do blog.

Muito obrigado! Valeu! #tamujunto

Nos vemos por aí!

Ei, psiu, se liga…

Dá para ficar sabendo das novidades do blog pelas redes sociais. Sigam-me os bons!

        

Conheça a minha obra completa em:

> paulodetarso.art.br

Atualização de Software

Enquanto você lê este post, o software do blog está sendo atualizado no seu equipamento.

Brincadeirinha... :P

Há duas décadas, atualizar um software era uma coisa complicadíssima. Os fabricantes precisavam disponibilizar uma cópia de atualização do software em alguma mídia física (normalmente disquete ou CD) e os usuários tinham que encontrar essa tal cópia. Quem tinha determinado CD de instalação de alguns programas era o cara – o detentor do poder. Entregar a correção de um bug era caríssimo nesse sistema físico.

O avanço da banda larga pelo mundo fez com que as atualizações fossem viáveis pela Internet, dispensando a mídia física. Com Internet cada vez melhor, a indústria investiu pesado em facilidades para atualização remota de software.

E o que falar do Windows então? Algumas versões do Windows chegam a ser estressantes de tantas atualizações a fazer. Dia sim, dia não, está lá o computador baixando correções do software, normalmente de vulnerabilidades de segurança. Sem contar a instalação dessas correções que normalmente é obrigatória e penosa – dá uma canseira na gente.

No mundo do WiFi e da boa banda larga

Atualizar software hoje, no mundo do WiFi, é a coisa mais normal do mundo.

A primeira vez que o meu Moto G entrou em uma rede WiFi, ele quase teve um orgasmo. :P

Ele ficou ensandecido baixando atualizações de aplicativos. Foram atualizados mais de 20 aplicativos de uma vez. Alguns aplicativos que eu desconhecia totalmente: ué, isso existe? Serve pra quê? Depois, até acabei desinstalando alguns destes.

E, já na primeira semana de uso, ele me fez uma proposta ousada: bora atualizar a versão do Android? Sair do Android 4 (KitKat) para o Android 5 (Lollipop)?

Eu resgatei todos os meus traumas de atualizações do Windows e fiquei muito pé atrás. Depois pensei: é melhor eu mudar logo pro Android 5 agora, antes que eu me acostume com o Android 4. Dessa forma, sofrerei uma vez só para aprender. Bateria cheia, WiFi ligado e vamos que vamos!

> Os smartphones vão acabar?

Windows 10

E que tal atualizar a versão do Windows? Sair de Windows 8 direto para Windows 10? (Sendo que a 9 nunca existiu).

Relutei por semanas. Era arriscado demais. A Microsoft apelou para todas as estratégias de marketing possíveis:

• Você é muito especial – ganhou uma atualização de graça
• É só para você
• É grátis só até não sei que dia
• X mil pessoas já atualizaram. Só falta você!
• Vamos fazer só o download pra você ir se animando...

E isso até deu bode porque a Microsoft foi denunciada por fazer downloads fantasmas (não autorizados) de um software de 3 GB! Pode isso, Arnaldo?

> Microsoft está baixando o Windows 10 secretamente em PCs

Enfim, depois que alguns colegas me confirmaram que o procedimento era seguro, eu decidi partir para o Windows 10. Tive êxito na terceira tentativa. Realmente, achei até “fácil” (ainda mais sendo o Windows). E fiquei satisfeito porque a versão 10 recuperou alguma usabilidade perdida na versão 8. Quem diria, mudar de Windows assim.

E os usuários?

Do ponto de vista dos usuários, receber logo as novidades é bom demais. Você já tem um software novo com menos bugs e mais recursos. É o nirvana das equipes ágeis: entregar logo as novidades!

Agora alguns cuidados são necessários: e se você não está precisando atualizar o software agora? E quando você precisa do equipamento e ele está travado fazendo atualizações inúteis?

Sem contar o desespero quando a versão nova chega com uma interface totalmente diferente da que você já estava acostumado! Alguns softwares até mantêm interfaces duplas durante um período de transição.


Será que o excesso de versões não foi uma das causas da derrocada do Firefox?

Vou terminar com um causo... Em 2012, o nosso sistema estava travando (por regras definidas anteriormente) o envio de alguns dados. Só que o emissor em questão era muito importante politicamente e a gente precisava lançar logo uma nova versão capaz de receber aquelas informações. A gente trabalhou duro em mudar, testar e implantar rapidamente a nova versão da aplicação – um sistema pela Internet. Liguei para dar a boa nova à nossa cliente e a reação dela foi: mas já tá disponível para todo mundo? Na cabeça dela, o cliente precisaria ter um disquete para instalar a nova versão do software na sua máquina. A gente riu demais e rimos até hoje com essa história. São causos do desenvolvimento.

Bora dar uma lida no livro?

No livro Fazendo um projeto dar certo, discutimos alguns problemas acarretados quando são liberadas muitas versões do software. Tanto as angústias dos clientes – que estão sendo bombardeados com novas versões, quanto as angústias das equipes - que estão trabalhando insanamente.

"Em uma frequência insana, são liberadas novas versões do software. Quando os usuários estão começando a se acostumar com uma versão, já deparam com uma nova. Às vezes, até com mudanças drásticas e de usabilidade. É difícil acompanhar a evolução do software.

[...]

O cliente confunde as versões de desenvolvimento, homologação e produção. Ele não sabe que aquela novidade solicitada ainda está na versão de desenvolvimento.

[...]

Para controlar e lançar tantas versões, a equipe do projeto faz um esforço enorme de gerência de configuração. Tempo e energia preciosos são subutilizados.

[...]

De nada adianta a equipe ir ao seu limite para lançar uma versão nova a cada semana, se o cliente só consegue homologar (absorver) uma versão por mês. Não adianta ficar lançando muitas versões próximas e confundindo os usuários finais – que não têm tempo de se acostumar com as novidades.

Será que essa versão nova é realmente uma versão nova? Ou é só a versão anterior com pequenas melhorias? Não vale a pena juntar várias dessas versõezinhas e entregar uma nova versão de verdade?"

Tamujunto!

Ei, psiu, se liga…

Dá para ficar sabendo das novidades do blog pelas redes sociais. Sigam-me os bons!

        

Como dar o prazo final do projeto?

Nesses dias, estamos planejando um novo projeto. E eu tenho ouvido muito a pergunta que o gerente de projeto mais ouve na vida: quando fica pronto? O patrocinador do projeto também se preocupa bastante com quanto custará. Mas a pergunta que realmente mais interessa a todos os envolvidos no projeto é: quando fica pronto? É um momento de muita pressão e tensão para o gerente e sua equipe de projeto. E aí, como responder a esta pergunta? Como dar o prazo final do projeto?

O projeto tem um prazo fixo

Esse parece ser o caso mais fácil que o gerente de projeto encontra para dar o prazo final do projeto. Também conhecido como: tudo bem, você pode dizer o prazo, desde que não passe desta data que eu quero. Ora pois, se o cliente já deu o prazo, o prazo já está dado.

Geralmente, estes projetos estão relacionados a algum evento fixo no tempo. Exemplos: o show do réveillon deve acontecer na noite do dia 31/12. Nem um dia antes, nem um dia depois. Simples assim. Espera-se noite de lua cheia no luau. O Carnaval também tem suas datas preestabelecidas antecipadamente. Assim como a Copa do Mundo. E as Olimpíadas, sejam de inverno, sejam de verão. O baile de 15 anos não pode acontecer 6 meses depois do aniversário. Caso clássico também são os projetos que precisam impreterivelmente acabar antes das eleições, rendendo mais publicidade e votos aos políticos.

Nesse cenário, a missão da equipe de planejamento é garantir que todo o trabalho necessário para a conclusão do projeto pode ser realizado até a data estipulada pelo patrocinador. As aquisições devem ter uma contratação aprimorada. Uma entrega de um fornecedor que atrasa uma semana pode colocar tudo a perder. Horas extras, aumentar a equipe ou diminuir requisitos do projeto também podem ser opções para garantir a data. É o tripé do planejamento: escopo, tempo e custos. Se o tempo está fixado, apenas as outras duas variáveis podem ser alteradas.

Para projetos dessa natureza, é imprescindível um gerenciamento primoroso do tempo. Nas últimas semanas, é esperada uma pressão incrível sobre a equipe do projeto por conta do prazo que está chegando.

Em desenvolvimento de sistemas, é o caso do projeto ágil clássico. Ou seja, a equipe é contratada por determinado período, e deve produzir software durante este tempo. Tudo o que for entregue é válido, mas a equipe deve buscar ter sempre entregas verdadeiramente implantáveis.

Opinião Especializada

Essa técnica de estimativa consiste basicamente em terceirizar a pergunta para algum especialista: meu amigo, me ajude, considerando toda a sua vivência, se você fosse fazer este projeto, quando ficaria pronto?

Obviamente essa técnica implica em ter um especialista à disposição por um custo aceitável. Normalmente, ela é usada quando o tipo do projeto é totalmente inédito para a equipe. E, claro, é uma estimativa rápida e grosseira apenas para gerar uma noção inicial do prazo e dos custos relacionados ao projeto. Pode ser importante para determinar o avanço em um trabalho de planejamento mais detalhado. Afinal, planejar também custa tempo e dinheiro. E, às vezes, isso precisa ser feito antes do projeto (e seu orçamento) ser aprovado, como em uma típica pré-venda.

Estimativa Análoga

Essa técnica de estimativa consiste basicamente em fazer uma analogia do projeto atual com projetos semelhantes anteriormente desenvolvidos pela equipe. Olha, aquele prédio que construímos no Centro tinha 9 pavimentos e demoramos 3 anos para fazê-lo. Sabe, aquele sistema de envio de SMS para os clientes foi concluído em 10 semanas.

A vantagem desta técnica sobre a anterior é que os estimadores são “da casa” e podem se valer das lições aprendidas dos projetos anteriores.

Estimativa Paramétrica

Essa técnica de estimativa consiste basicamente em definir e utilizar alguma unidade de medida para comparar projetos diferentes. Essa unidade é utilizada como parâmetro para determinar o grau de multiplicidade entre os projetos comparados – quanto A é maior (ou menor) que B? Se um projeto do tamanho A é feito em X tempo, quanto tempo precisamos para fazer um projeto B, que tem o dobro do tamanho de A?

Em uma visão grosseira, poderíamos comparar a quantidade de apartamentos de um edifício residencial. Se gastamos 2 anos para fazer um prédio com 40 apartamentos, quanto tempo levaremos para fazer um novo prédio com 80 apartamentos? Pela estimativa paramétrica, teríamos 4 anos.

Em software, um parâmetro bem utilizado é o ponto de função, que visa medir o tamanho funcional de um sistema. A empresa pode ter a sua métrica de produtividade indicando quanto tempo ela precisa para produzir 1 ponto de função e isto pode ser utilizado para estimar o tamanho bem como o prazo de novos projetos.

A estimativa pode ser aprimorada incluindo-se tempos fixos para a iniciação e o encerramento de projetos de qualquer tamanho.

O grande problema desta técnica é encontrar parâmetros confiáveis para a comparação de projetos diferentes. O próprio ponto de função citado anteriormente tem consideráveis deficiências.

Estimativa Detalhada

Essa técnica de estimativa consiste basicamente em construir um cronograma completo de todo o desenvolvimento do projeto. E por completo entendam: obtenção de licenças e autorizações; disponibilidade de recursos materiais; aquisições; alocação de pessoas; testes, homologações e implantações.

A vantagem é ter uma estimativa bem mais realista e confiável. A desvantagem é que isso não sai de graça. Projetos enormes podem ter dezenas de profissionais trabalhando durante meses apenas no seu planejamento inicial.

A margem de erro vai pra lá e vem pra cá

Perceba que falamos o tempo todo em estimativas: avaliação ou cálculo aproximado de algo. E toda estimativa é falível. Portanto, toda estimativa deve ser agraciada com uma margem de erro. Uma variação aceitável dentro da data crua obtida diretamente pela estimativa.

Quanto mais detalhada a estimativa, melhor ela será e, portanto, aceitará uma margem de erro menor. Considere 30% de variação nas técnicas menos detalhistas. Isso pode ser aceitável em um projeto de 100 mil reais. Mas pode inviabilizar um projeto de 10 bilhões de reais caso não tenhamos à disposição os 3 bilhões de reais adicionais necessários à margem de erro do planejamento.

Quanto mais caro o projeto, mais cara a margem de erro e, talvez, tenhamos mais dinheiro para planejar melhor inicialmente, economizando, assim, na margem de erro.

E vai dar tempo?

Uma vez iniciada a execução do projeto, é necessária uma gestão cuidadosa do tempo, para garantir que o projeto acabe dentro do tempo planejado. A cada dia que se passa, a estimativa de ontem não vale mais. Ao mesmo tempo, já podemos ter uma estimativa nova e mais real do projeto. E assim seguimos até o último dia do projeto. Diariamente, respondendo: quando fica pronto?

O amadurecimento da equipe durante a execução do projeto e a ocorrência ou não dos riscos podem indicar se as estimativas serão cumpridas e se um eventual atraso pode ser recuperado com o esperado aumento da produtividade da equipe.

Para saber mais, estude Gerenciamento do Tempo.

Até!

Lição de vida, planejamento e jeitinho brasileiro

Mais uma grande lição que a vida me dá. Eu que tanto desejei um filho menino, consegui captar essa linda imagem da alegria da pequena menina Isabela: “Papai, tá muito bom aqui, a gente lavando o nosso carro”. E realmente não era pra ela ficar triste em um evento que juntava água e bagunça.

Conforme já discutimos em outro post, projeto é o planejamento para a criação de algo novo. No livro Fazendo um projeto dar certo, também conversamos bastante sobre a importância e a necessidade de um bom planejamento:

"É praticamente impossível fazer um projeto dar certo trabalhando no improviso.

A equipe de gerenciamento de projetos precisa estar treinada nas técnicas de gerenciamento de projetos e habilitada a utilizar as ferramentas necessárias aos ritos de planejamento do projeto. [...]

Planejar significa prever, calcular, acompanhar, checar e refazer tudo isso. O tempo todo. Até o último dia do projeto. […]

Um dia de planejamento pode significar um projeto dando certo e outros tantos dias a menos de trabalho.”

Mas o planejamento é apenas uma previsão do futuro. E somente Deus controla o futuro! A qualquer momento, as coisas vão acontecer de forma diferente do que planejamos. Nessa hora, é preciso replanejar e, se for o caso, improvisar, usar a favor do projeto o bom jeitinho brasileiro.

Por favor, perceba a diferença. Não é fazer o projeto todo no improviso. É improvisar em alguns momentos determinantes para que o projeto dê certo. Em projetos de software então, com muito ineditismo e imprevisibilidade, é necessário muito jeitinho brasileiro (criatividade).

Isabela é uma garotinha linda, saudável, inteligente, feliz e carinhosa. E o nosso projeto de formar uma família vai dando muito certo. Graças a Deus!

PS: E por que não planejar um irmãozinho (ou irmãzinha) para a Isabela?

Saudações.