Lendo o livro The Art of Project Management, do Scott Berkun, topei com uma parte completamente inusitada, mas que faz todo sentido: ele faz uma referência ao gerenciamento de cozinha de grandes restaurantes e seus desafios gerenciais, e cita o livro do Anthony Bourdain, Kitchen Confidential (já traduzido para o portugues, Cozinha Confidencial). Claro que bateu a curiosidade de ler esse livro algum dia e, enquanto isso não aconteceu, peguei a dica do livro do Berkun e passei a usar gerenciamento de cozinha (apesar de eu não ser cozinheiro e de não ter nenhuma relação com cozinhas) como exercícios de aquecimento na minha disciplina de Gerência de Projetos, na graduação.
Como? Os exercícios eram na seguinte sequência, sempre focados em processos gerenciais: Ex. 1 – como seria o fluxo de processo de gerenciamento de uma cozinha de restaurante pequeno, especializado em um tipo de comida, com menu fixo que sofre poucas alterações?; Ex. 2 – idem, complicando um pouco no tamanho do restaurante, colocando por exemplo mais de um salão de refeições e aumentando a quantidade de atendimentos, com um menu variado e multi-nacional; Ex. 3 – como seria o gerenciamento de um restaurante sem menu fixo, que deixaria o cliente chegar e solicitar o prato que lhe viesse à mente no momento? Percebam ai que vou aumentando o nivel de dificuldade do problema, o processo vai se complicando, e eu poderia estender muito mais os problemas intermediários. O último exercicio, naturalmente, tem desafios enormes, e ai de fato cada pedido de cliente pode ser considerado um projeto, dentro da concepção técnica de o que é um projeto no PMBOK. Nos dois primeiros casos, a confecção de cada pedido ou prato não seria um projeto, e sim uma operação corriqueira e repetivel. O resultado desses exercícios foi fantástico, levando a longas discussões sobre gerenciamento, análise dos processos e fluxos de trabalho propostos pelos alunos, etc. Muita criatividade, recomendo que tentem esse tipo de exercicio, fazendo os alunos pensarem em problemas fora da área de computação, levando-os a enxergarem as metáforas tão necessárias na vida.
Agora, nas minhas primeiras férias de aposentadoria, chegou a oportunidade e li o livro todo, no Kindle (software, não tenho o hardware do Kindle). O livro é fantástico, uma aventura, conta a vida e a ascenção do Anthony Bourdain no mundo da cozinha, suas experiências principalmente em New York onde ele se criou, seus erros e acertos, as furadas, os desastres, as perdas e ganhos, etc. Abre o jogo com relação a alguns pontos interessantes, como por exemplo: -dias bons para comer peixe em NY são terças, quartas, e quintas, que são dias em que o mercado de peixes de NY (Fulton Fish Market) funciona, e normalmente os peixes são frescos nos restaurantes. Nos demais dias, corre-se o risco de comer peixe que já entrou e saiu do freezer várias vezes, já foi manipulado, piorando seu sabor e qualidade; -fuja dos brunchs de domingo (tem prá todo lado aqui), essa é mais uma solução Lavoisier (nada se perde, nada se cria, tudo se transforma…); e mais várias outras dicas engraçadas.
As estórias de dentro das cozinhas, como os pratos são produzidos, como funcionam as estações de trabalho dentro das cozinhas, como os pedidos são agrupados para tirar proveito de carnes semelhantes, frigideiras já quentes, temperos já misturados, etc., aumentando a eficiência do fluxo de trabalho. Sem contar a imagem fiel que ele passa sobre o tamanho das cozinhas de grandes restaurantes, as câmaras frigoríficas, o estoque, a relação com fornecedores, o gerenciamento de conflitos entre os empregados (graves e complicados), o que fazer quando falta algum funcionário crítico como um cozinheiro por exemplo, a descrição das funções dentro do restaurante (cozinheiro, copeiro, garçom, maitre, gerente de cozinha, chef, gerente de estoque, lavador de louça e de panela, limpador de chão, responsável pelo lixo…), a coordenação dos espaços dentro da cozinha para não haver colisões. Enfim, um mundo de detalhes para gerenciar, e tudo com tempo determinado para ficar pronto, e tudo devidamente fiscalizado pelo chef. E nessa confusão toda, ele conta um monte de estórias engraçadas de conflitos, lições de vida, faltou o tomate no meio da noite em um dos restaurantes italianos onde ele trabalhou (já pensaram só numa situação dessas?), briga de porrada entre funcionários. E o gerenciamento dos roubos de todo tipo: talheres, pratos, estoque, etc., praticados pelos funcionários.
Enfim, uma leitura fantástica, li rápido porque gostei demais, e fui fazendo a ligação da metáfora entre o gerenciamento da cozinha e o gerenciamento de projetos, muitos problemas são idênticos, e as soluções gerenciais idem. Vi muito mais de agilidade no livro, do que processos organizados com passos determinados. Acho que seria impossível gerenciar uma cozinha grande com processos rigidos. Anthony Bourdain tem um programa no canal Travel and Living, vejam o link aqui, que eu assisto regularmente no Brasil, e me divirto muito. Recomendo o livro, é muito divertido e traz muito conhecimento, mesmo que você não tenha interesse nenhum em gerenciamento de projetos.
(este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com) (from Jersey City, NJ)
Topei com uma entrevista na Forbes recentemente, que li e reli, e acho que vale a pena comentar aqui no blog. O título é provocativo: Project Managers Will Kill Your Company: Advice From Palo Alto Networks Founder Nir Zuk. O entrevistado é Nir Zuk, jovem empreendedor, fundador da Palo Alto Networks, onde atualmente é CTO – Chief Technology Officer. É reconhecido na área, por ter reinventado a firewall e sua implementação: “In 2006, Palo Alto totally rebuilt the firewall, making it the first company to bring a completely new firewall to market since it was invented 11 years earlier. They called it the “next-generation firewall,” a term now adopted by analysts who cover the industry.”
Como inovador, tem ideias também inovadoras e desafia os padrões atuais de administração de empresas de alta tecnologia como a Palo Alto. Por exemplo, seu reconhecimento de que a empresa não é apenas dele, e que seus colaboradores merecem uma fatia de participação na empresa e seu crescimento, tão grande quanto a fatia dele próprio. Transformando-o em um parceiro e também colaborador, ao invés de ficar na posição de dono da empresa. Esta visão é talvez a mais apropriada para administrar bem empresas de alta tecnologia, em que todos os colaboradores contribuem com conhecimento para o negócio principal, sendo impossível apontar as contribuições individuais, o que achata a estrutura hierárquica das empresas maiores e tradicionais, com longas linhas de mando e de comando.
Na entrevista, ele revela sua maior preocupação: que a Palo Alto Networks se transforme em mais um mamute da alta tecnologia, crescendo a tal ponto que seja obrigada a adotar a estrutura pesada e os padrões de administração destas grandes empresas, deixando de lado a estrutura atual colaborativa, em que cada um se sente responsável pela empresa. E na linha desta preocupação dele, vem o que ele acha de contratar gerentes de modo geral, e de projetos em particular:
How do you grow at that rate without developing a bureaucracy to oversee it?
From the beginning, you create a culture where decisions get pushed to the bottom, to the lower level people. You don’t try to centralize anything. You let people make decisions. But you need to have the right people to do that. A lot of people can’t do that. People who are not ‘A’ players do not fit into that scheme. The advantage of pushing decisions down is you have a lot of decision-making happening in parallel. If you need to coordinate between different departments, it happens at the lower levels, it doesn’t have to go up to the VP over to the other VP and back down. In which case you would need someone to do all the coordination.
‘A’ players?
When you start hiring ‘B’ players or ‘C’ players, or ‘D’ players… ‘A’ players hire ‘A+’ players, but ‘B’ players hire ‘C’ players. When you start hiring ‘B’ players, they are very insecure about themselves, and rightfully so. Their biggest worry is people underneath them jumping over them when it’s time to be promoted. If you’re a ‘B’ player and you’re a manager or director and you want to be VP, if you aren’t sure of yourself and your abilities, then you will do everything you can to make sure someone below you doesn’t surpass you. Managers are making sure that the people underneath them are not successful. If [their employees] have a great idea, first they try to steal it, if they can’t, they shoot it down. Then all the decisions have to happen at the top.
Achei melhor não traduzir essas duas partes da entrevista dele, deixando no original da entrevista que apareceu na Forbes e que está citada no inicio. O admirável ai, é que se trata de um inovador e empreendedor jovem, com ideias também jovens e arejadas. Jovens têm o poder de mudar o mundo, acordem ai… Pergunta final: porque é que eu escolhi a foto acima para ilustrar a postagem? exatamente a foto de uma árvore, que é a abstração que usamos invertida para representar hierarquias?
(este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com) (from Jersey City, NJ)
- Em: Carreira | Inovação | Livros
- Deixe um comentário
Praticando um dos meus passatempos favoritos, que é entrar em livrarias e ficar rodando à procura de novidades, topei com este livro do Austin Kleon, que me chamou atenção pelo título completamente inusitado. Como assim, steal like an artist (roubar como um artista)? Bom, de curiosidade, peguei o livro para dar uma olhada, já de cara tem uma boa indicação: lista dos mais vendidos do New York Times. Pode não significar muita coisa, mas é uma indicação melhor do que comprar no escuro, sem saber. Com isso ai, o livro já estava mais da metade na cesta de compras, e ai olhei o preço, 11 dólares, e o livro foi definitivamente para a cesta de compras. O autor, Austin Kleon, é escritor e artista, de Austin-Texas.
Bom, quando li o sub-título do livro, melhorou a primeira impressão: 10 things nobody told you about being creative. Ai deu para perceber o contexto do título, e a leitura do livro foi pura diversão do começo ao fim. O que significa roubar, no contexto do livro? O reconhecimento de que nossa estrutura de conhecimento individual é composta por influências e mais influências que sofremos ao longo da vida. Algumas mais, outras menos, e o fato é que quando chegamos ao ponto de produzir algo próprio, com nossa própria visão, esse algo vai impregnado por essas influências que colecionamos ao longo da vida. Escritores, artistas, atores, pintores, designers, família, amigos, coveiro, motorista de ônibus, filosofia de botequim, enfim, as contribuições vão aparecendo sem que a gente se dê conta de onde elas vieram, impossivel desagregar uma influência depois de algum tempo.
Ai é que vem o contexto de roubar, no título do livro: observar os outros, as obras dos outros, adotar modelos, etc. Mas, nunca significa simplesmente copiar as ideias e insights de outra pessoa, isso é outra coisa, isso é plágio, é desonesto. A ideia aqui é você entender a obra de outro artista a ponto de conseguir enxergar o mundo pelo menos com parte da visão dele, que passa a ficar incorporada na sua própria visão e modelo de mundo. Plagiar é muito fácil (muito fácil descobrir também), mas adquirir essa visão do outro, exige muito estudo de técnicas, análise da produção, biografia, vida e experiências, etc. E essa é uma prática mais comum entre os artistas, que estudam a obra e o processo criativo de vários artistas na sua e em outras áreas. Com o tempo, a obra do artista passa a sofrer influência dos demais estudados. Por exemplo, no site MusicMap, é possivel visualizar as influências sofridas por um músico ou grupo musical, e as influências exercidas pelo grupo em outros grupos. Para ver o mapa referente aos Beatles, por exemplo, clique aqui, é muito interessante. Claro, o mapa mostrado é apenas a influência visivel cujos dados estão disponiveis e registrados de alguma forma processável. Será que em algum momento no futuro vai ser possível ter um desenho de um mapa desses para cada um de nós?
O livro é curto e grosso, e dá para perceber nele a influência de outros autores de livros que já li. Por exemplo, percebe-se influência do excelente livro Where good ideas come from (Steven Johnson) em algumas partes. Costumo falar isso nas minhas aulas de engenharia de software: estudar as obras de outros artistas, outros projetos, faz parte do processo criativo dos artistas. Por exemplo, o arquiteto, uma vez definidos os requisitos de um projeto, tenta achar soluções já prontas para mostrar alternativas aos clientes, como se fossem protótipos para ajudarem no entendimento e melhoria dos requisitos. Por isso, revistas como Arquitetura e Construção, Casa Cláudia e outras fazem parte obrigatória do processo de projeto dos arquitetos. O projeto pode seguir um caminho com menos riscos, com maiores chances de satisfazer às expectativas do cliente. E ai fica a pergunta: porque em engenharia de software ainda não fazemos isso? Parte da resposta está no fato de que ainda não temos um corpo de conhecimento registrado sobre projetos e sua descrição. Na verdade, ainda não temos nem um padrão a ser seguido sobre como descrever projetos e suas partes, cada empresa adota uma linguagem que acha melhor ou mais fácil usar. Mas, padrões estão aparecendo, e sua adoção e vantagens em adotá-los estão começando a ser disseminados.
Recomendo demais o livro, muitos benefícios na leitura, vocês vão gostar. Tem um pouco cara de livro de preceitos, daqueles que ficam classificados nas prateleiras de auto-ajuda das livrarias. Mas não é nada disso, podem apostar, é apenas primeira impressão. E é o tipo de leitura que realmente puxa nossa mente e nos faz crescer, completamente fora da área técnica. São minhas leituras preferidas.
(comprei esse livro na loja do MOMA – Museum of Modern Arts, em NYC, 18 de abril de 2013)
(este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com) (from Jersey City, NJ)
Zipcar: uma ótima ideia
Publicado em: domingo, 21 abril, 2013
- Em: Economia | Inovação | Social | Viagem
- 1 Comentário
Quando li pela primeira sobre o Zipcar e sobre o modelo de negócios que o acompanha, achei muito bem bolado. Mas, agora pude ver funcionar de verdade, e fiquei impressionado com a praticidade e facilidade do negócio. O ramo de negócio, à primeira vista, parece ser aluguel de carro, mas eu acho que é bem mais, trata-se de compartilhamento de carros: você marca o horário e o tempo que vai precisar do carro, vai lá no estacionamento onde eles ficam, pega o carro reservado, usa, e devolve no mesmo lugar para o próximo usar. Mas só pode usar quem estiver cadastrado no sistema deles, e tiver o cartão (tipo um cartão de banco) para poder destravar e abrir a porta do carro. Ou seja, a ideia do negócio é mais para compartilhamento do que para simples aluguel.
Os carros ficam disponíveis em vagas de estacionamentos fechados, geralmente prédios de vagas, e ficam sempre no primeiro andar de vagas. No que eu vi aqui, são três vagas por prédio (certamente isso deve variar dependendo de demanda). O funcionamento é simples: -você tem que estar cadastrado devidamente no sistema, e isso significa ter um cartão de crédito válido cadastrado; -para fazer uma reserva, login no site deles, e marca o horário de pegar o carro, escolhe um carro disponivel no estacionamento mais próximo de onde você está (tipo e modelo); -no horário marcado, você vai lá no estacionamento no primeiro andar, e o carro certamente vai estar lá esperando; -com seu cartão Zipcar, você abre o carro passando o cartão num leitor que fica por dentro do para-brisa, no lado do motorista; -o sistema destrava as portas do carro, e aí é só sair dirigindo, a chave de ignição fica dentro dele, presa num cabo com sensores. Dentro do carro, no protetor de sol que fica do lado do motorista, ficam dois cartões: um para sair e entrar no estacionamento, e outro para abastecimento, que só funciona em postos de gasolina autorizados e só podem ser usados para comprar gasolina. E ai, claro, no horário marcado, o carro tem que estar de volta no mesmo lugar, para o próximo usuário. E a despesa do aluguel é debitada diretamente no seu cartão de crédito cadastrado. Um detalhe: os carros têm seguro e tanto ele quanto a gasolina estão incluidos na tarifa, que pode ser por hora ou por periodo. Simples, não?
O software de controle disto tudo é que tem desafios do ponto de vista arquitetural e de engenharia de software. Pensem ai no funcionamento do esquema, tem muita função interessante implementada, principalmente na parte de controle. A parte de web, cadastro, etc., não tem grandes novidades, tem um monte de sistema que funciona do mesmo jeito. O que interessa mesmo, é o controle do aluguel, a partir do momento em que o usuário passar o cartão no para-brisas. Por exemplo, como é feito o controle de liberação do carro? A informação sobre o próximo usuário tem que estar armazenada no sistema do carro, para a autorização de uso acontecer, concordam? Se não for assim, o sistema vai ser uma bagunça total, pois qualquer um poderia pegar qualquer carro a qualquer instante. E ai já temos um desafio de arquitetura: a comunicação entre o sistema de controle central, e o software que roda no carro. O que também não tem grandes desafios tecnológicos, e que pode funcionar usando a rede de telefonia celular (claro, com um SLA-Service Level Agreement bem rigoroso).
Mas, deixando a imaginação rolar, é muito possível que esse sistema de controle mantenha um rastreamento do carro incluindo as rotas, onde passou, onde ficou estacionado, etc., acrescentando essa informação depois de devidamente processada, ao perfil daquele usuário. Com o tempo, o sistema já teria um histórico de preferências de cada usuário, conseguindo fazer previsão de horas de uso, disponibilidade, expansão da frota, descarte de carros mais velhos, etc.
Na minha opinião, o sistema funciona bem porque, antes de mais nada, não depende de operadores humanos para funcionar talvez em 90% do tempo. Certamente, em algum momento aparece algum ser humano, afinal o carro precisa trocar óleo, calibrar pneus, lanternagem, limpeza, etc., mas essa intervenção não precisa ter interação com o usuário. Outra coisa interessante, é que aqui fora tem muita demanda por carros de aluguel, tanto que é um enorme negócio desde há muitos anos, tanto nos EUA quanto em outros paises. Se você mora numa cidade como Nova Iorque ou Londres, por exemplo, certamente não vai ter carro próprio, primeiro porque não tem onde estacionar na rua (tudo carissimo) e se tiver vaga, vai custar caro e você tem que ser autorizado a estacionar naquele local. Você pode até arriscar e estacionar, mas se a polícia de trânsito pegar você, vai colocar um grampo na roda do seu carro, e você só vai conseguir sair nele se for lá na sede da policia, pagar multa e pagar para eles tirarem o grampo da roda. Segundo porque a cidade oferece um sistema de transporte por metrô e ônibus que desencoraja mais esse gasto com carro (jogando dinheiro no lixo). Alugar um carro é muito mais racional e mais barato do que ter o carro. Em cidades do interior do pais, acontece o contrário, você tem que ter o carro, mas ai o contexto é o contrário deste das grandes cidades.
Ai no Brasil também é assim, só que o aluguel do carro ainda é muito caro, e os carros baratos são somente os Uno, Gol e Palio, ou seja, somente os carros de entrada, sem ar-condicionado e outros confortos. Ou seja, mesmo sendo caro, ter o carro próprio acaba sendo a única opção viável. E tem também, na minha opinião, uma grande diferença na visão empresarial deste ramo de negócio, e na enorme fome por lucros rápidos e fáceis, deixando sempre o usuário em segundo plano sofrendo com os carrinhos porcaria e pagando caro pelo aluguel. Como se o usuário fosse apenas um detalhe do negócio, quando na verdade deveria ser “o detalhe”!
Atualização 4/5/2013 - terça desta semana, tivemos a oportunidade de testar a robustez do sistema da Zipcar. Fomos pegar um carro, e quando fomos sair do estacionamento, o cartão de estacionamento não estava onde deveria estar, alguém que alugou anteriormente perdeu ou sei lá o que, resultado: não tinha como sair do estacionamento com o carro. Um telefonema para a central de atendimento deles, e foi resolvido na hora: quem atendeu alocou outro carro que estava disponivel no mesmo estacionamento, fez a troca no sistema deles, e saimos no outro carro. Em seguida, mandaram um funcionário (desta vez físico) ao estacionamento resolver a falta do cartão de estacionamento. Fácil, não? O cliente em primeiro lugar, sempre, porque aqui fora, tem concorrência pesada, se sua empresa não me atende bem, eu passo para outra, e outra, e outra…
Nota: o logo da Zipcar foi tirado diretamente do site deles.
(este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com) (from Jersey City, NJ)
- Em: Arte | Emergência | Reflexões
- 1 Comentário
Ainda na leitura do livro This explains everything, comentado em postagem anterior, alguns textos chamam atenção pela beleza e generalidade do padrão unificador apresentado e discutido rapidamente. Um deles foi apresentado por John Naughton, colunista no jornal inglês The Guardian, sobre o comportamento sincronizado de pássaros voando em bando (Flocking behavior in birds).
Quais as regras que fazem com que os pássaros voem em bando exibindo um padrão de sincronia que resulta em um verdadeiro balé? Como por exemplo o mostrado neste vídeo? O estudo e o entendimento dessas regras de comportamento tem enorme interesse, porque podem ser usadas em modelos de simulação que reproduzam o movimento, e dai serem estendidos a outros domínios, como por exemplo o movimento de bactérias, de multidões, etc.
As regras são simples e poucas, daí a beleza do padrão: 1-Separação: não amontoe em cima de seus vizinhos; 2-Alinhamento: mantenha o rumo da média dos seus vizinhos; 3-Coesão: mantenha-se em uma posição média que não afaste você de seus vizinhos. Claro, isso está escrito ai em linguagem comum, e ficam dúvidas: como é que cada pássaro vai saber que está na distância média dos outros? e o rumo? como é feito o comando do bando, qual pássaro ou grupo de pássaros direciona? Talvez os pássaros usem medidas como por exemplo “uma asa tocando a do vizinho”, ou então a sensação de calor gerado pela proximidade com o vizinho, etc.
Como não sou Biólogo ou Ornitólogo, dificil saber todas as explicações, e nem acho que interessam muito para esta postagem. O que interessa mais aqui é falar sobre o padrão, para que percebam que estamos cercados por padrões que seguimos sem saber e sem sentir, já fazem parte do cotidiano. Como os pássaros, como os gafanhotos (o padrão de movimento deles é até engraçado), de gado, de animais selvagens, e do próprio universo onde estamos inseridos. E que vemos se repetir na Computação, na organização das linhas de código, nos padrões de projeto, nos padrões de repetição de erros em programas, etc.
Para saber mais, recomendo a leitura do verbete na Wikipedia, e um artigo mais técnico sobre o assunto aqui (não sei avaliar se o artigo é bom, pelo menos me pareceu interessante).
(este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com) (from Jersey City, NJ)
This explains everything
Publicado em: segunda-feira, 8 abril, 2013
- Em: Filosofia | Reflexões | Social
- 1 Comentário
Mais um livro da série lançada pelo site Edge, gerenciado pelo John Brockman, já comentado aqui em postagem anterior What have you changed your mind about? Repetindo do que se trata, a cada ano o Brockman lança no site uma pergunta desafiadora, e convida pensadores, filósofos, cientistas, artistas, tecnologistas, etc. para responderem à pergunta ou desafio em um texto de uma a duas páginas no máximo, que são posteriormente selecionados, ordenados e organizados na forma de livro, que é impresso em papel jornal, edição barata para melhorar a difusão. Tenho lido todos eles em formato de livro “de verdade”, para deixar anotações que posso acessar e complementar a qualquer momento.
This explains everything é o título do livro, resultado final do desafio lançado pelo Brockman em 2012, “What is your favorite deep, elegant or beautiful explanation?”. O livro é tão festejado a cada ano, que na livraria Barnes&Noble ele aparece na categoria mind food (alimento para a mente), dado o seu objetivo de cutucar a mente de quem ler, provocando mudança em pensamento e em rumos. Os textos são fantásticos, e eu não leio na ordem em que aparecem, vou lendo ao acaso, para provocar mais a mente. Textos que me chamaram mais atenção até agora: -Boltzmann’s explanation of the second law of thermodymics, Leonard Susskind; -Why some turtles migrate?, Daniel Dennett; -Flocking behavior in birds, John Naughton; -The Gaia hypothesis, Scott Sampson, e ainda vão aparecer outros, principalmente na releitura.
Particularmente, e dando minha contribuição modesta à discussão, gosto demais do principio unificador (que explica também o comportamento) das Três Leis da Robótica, enunciadas pelo Isaac Asimov em seu fantástico livro I, Robot (que deu origem ao filme de mesmo nome, com o Will Smith), que já foram objeto de postagem aqui no blog. Essas três leis, simples e curtas, refletem um conceito de comportamento para máquinas (e porque não dizer para nós humanos também?) fantásticos: 1-A robot may not injure a human being or, through inaction, allow a human being do come to harm; 2-A robot must obey the orders given to it by a human being, except where such orders should conflict with the first law; 3-A robot must protect its own existence as long as such protection does not conflict with the First or Second laws.
Tentem enxergar as três leis acima como um princípio unificador (que é o desafio do livro para 2012), curto e grosso, com um enorme efeito em comportamento. Mesmo a despeito do tanto de discussões que já tenham gerado e continuam gerando.
(este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com) (from Jersey City, NJ)
Padrões em projetos de software
Publicado em: sexta-feira, 5 abril, 2013
Recentemente, recebi uma mensagem de um ex-aluno sobre uma questão conceitual de uso de padrões de projeto de software. A questão era, mais ou menos: membros da equipe de desenvolvimento da empresa onde trabalho querem usar padrões de projeto no desenvolvimento, mas querem alterar os padrões para ajustá-los aos projetos. A pergunta me fez pensar em um zilhão de ideias que me brotaram na mente, parte delas eu trouxe para esta postagem, pois certamente podem beneficiar outros interessados no assunto.
Antes de mais nada, padrão é padrão. A definição de dicionário é:
sm (lat patronu) 1 Modelo oficial de pesos e medidas. 2 Modelo. 3 Desenho de estamparia. 4 Título autêntico. P. de cor, Telev: cada um dos três padrões internacionais usados para descrever como as cores da TV e imagens de vídeo são exibidas e transmitidas: NTSC, PAL e SECAM. P. de fato, Inform: um projeto, método ou sistema tão amplamente utilizado que se tornou padrão, apesar de não ter sido reconhecido oficialmente por qualquer comitê. P.-ouro: moeda-ouro. Pl: padrões-ouros e padrões-ouro. (extraido do Dicionário Michaelis-UOL Online da Lingua Portuguesa).
Será que você sairia satisfeito de uma loja, depois de comprar 50 metros de cabo para instalação de rede em sua casa, e o comerciante tivesse medido os 50 metros usando um metro que ele mesmo definiu por conta própria, para ficar mais fácil de medir na concepção dele? Como por exemplo faziam os antigos fenícios, tomando a medida da ponta do nariz até a ponta da mão direita (ou esquerda) com o braço estendido e o nariz “meio” apontando para o lado contrário ao da mão? Testem ai, até que funciona, dá mais ou menos um metro mesmo.
Então, padrões são originados por emergência a partir do uso, observados ao longo de muitas situações que se repetem com regularidade, e medida sua eficiência para aquela situação específica. Depois de propostos são testados exaustivamente, até que sejam aceitos pela comunidade que precisa utilizá-los, e então são adotados como universais e disseminados pelas comunidades. Foi assim com o metro, com o quilograma, com a libra, com o pé, a jarda, com a arquitetura de redes em camadas, padrões de instalação elétrica prediais e residenciais, etc. E é para isso que existem organizações como a ISO (International Organization for Standardization), a ABNT (Associação Brasileira de Normas Técnicas), a ANSI (American National Standards Institute), que cuidam do estudo, definição formal e disseminação de padrões para os mais diversos usos e em todas as áreas tecnológicas.
Os padrões aplicáveis a projeto de software disponiveis e disseminados principalmente via o livro Padrões de Projeto do Erich Gamma e colaboradores, aceitos e utilizados por desenvolvedores no mundo todo, não foram (ainda) objeto de uma formalização maior e publicados como uma norma ISO, ANSI ou ABN T. O melhor que se conseguiu fazer foi o catálogo de padrões disponível no livro e em várias outras fontes que surgiram posteriormente, incluidos outros livros. Mas então, já que os padrões de projeto não estão definidos tão formalmente e não estão normatizados, seria razoável adotar um padrão como o Façade por exemplo, e mudar a sua definição para “ajustá-lo” às necessidades que o desenvolvedor considera importantes?
Do ponto de vista de documentação do projeto e de sua manutenção posteriormente, isso seria um desastre, e aumentaria o impacto na documentação, pois estamos falando de um novo padrão que não é o original. Dificultaria muito a manutenção e, se isso for feito com outros padrões no mesmo projeto, com o tempo a rastreabilidade dos requisitos e a manutenibilidade do projeto estariam completamente comprometidos, talvez obrigando a um novo desenvolvimento para restaurar esses atributos importantes do software. E a rastreabilidade é tão importante em projetos, que está presente em todos os modelos de qualidade como um processo de GRE – Gerência de Requisitos (mpsBR, nível G e CMMI, nível 2). Do ponto de vista conceitual, de projeto de software, essa é a questão, e se a necessidade do seu projeto é “quase parecida” com o padrão Façade, o mais correto é não adotar o padrão e você desenvolver a implementação por conta própria, sem citar padrão nenhum.
Claro, se você usa os padrões de projeto corretamente em seus projetos, a discussão sobre como implementar é outra completamente diferente. Implementações podem variar, pois normalmente são atreladas a soluções tecnológicas, sujeitas a muitas escolhas e decisões de implementação.
(este artigo foi escrito por zeluisbraga, e postado no meu blog zeluisbraga . wordpress . com) (this post is authored by zeluisbraga, published on zeluisbraga . wordpress . com) (from Jersey City, NJ)
