Postagem em destaque

Procurando Profissional em Análise de Processos de Negócios, BPM, BPMS e Melhoria de Processos, para atuar na Região Metropolitana de Belo Horizonte?

Marco Gandra Brasileiro – Casado 41 anos - CNH B Nascido em Belo Horizonte e-mail gandraribeiro@gmail.com ...

Pesquisar neste blog

24 de set de 2012

Comentários Críticos sobre Tecnologia da Informação

Por: Marco Mendes
Em: http://marcomendes.com/blog/2012/04/e-se-benjamim-franklin-fosse-um-arquiteto-de-software/


E se Benjamin Franklin fosse um arquiteto de software?


Benjamim Franklin foi um dos gênios da era moderna. Além de ser um cientista, ele também foi  jornalista, editor, autor, filantropo, abolicionista, funcionário público, diplomata, inventor e enxadrista. E se com todo este gênio, ele tivesse sido arquiteto de software?
Ele também teria nos ensinado diversas lições. A partir de um conjunto de pensamentos que resumem um pouco da filosofia de vida dele, coloco aqui lições dele projetadas no ramo da arquitetura de software.
01. Faça mais e fale menos.
“Well done is better than well said.”
Arquitetos devem fazer mais e falar menos. Isto é, arquitetos devem sair das famosas torres de marfim e dos documentos frios para a interação com as pessoas e a produção de protótipos, provas de conceitos e liberações frequentes de alfas e betas. Fazer em software significa: entregar valor. Entregar valor é código executável estável na mesa dos seus usuários.
02. Não adie riscos.
“Don’t Procrastinate.”
Arquitetos não devem adiar decisões. Isto é, eles devem identificar os fatores críticos que podem evitar o sucesso do projeto e atuar na mitigação destes riscos. Gerir riscos é uma habilidade fundamental a qualquer arquiteto.
03.  Esteja preparado.  
“By failing to prepare, you are preparing to fail.”
Arquitetos devem estar prontos para a ação. Conhecer métodos formais de arquitetura (tradicionais ou ágeis) e conhecer verdadeiramente os fundamentos da disciplina é fundamental para fazer um bom trabalho de arquitetura nos seus softwares. Acreditar que conhecer APIs Java EE ou .NET apenas é estar preparado é a primeira receita para fracassar como arquiteto.
04. Somente termina quando acaba.
“When you’re finished changing, you’re finished.”
Em média, um projeto tem 30% de seu escopo funcional mudado. Naturalmente, a arquitetura também irá mudar. Lutar contra o fato de existirem mudanças é perder tempo. Bons arquitetos entendem que  mudanças são naturais, replanejam o seu trabalho, atacam os novos riscos e renegociam os impactos desta mudança na arquitetura, seja no tempo, escopo ou financeiramente falando. Como já dizia Kent Beck: “Embrace Change”.
05. Seja um líder e movimente o seu time em direção às metas
“All mankind is divided into three classes: those that are immovable, those that are movable, and those that move.”
Arquitetos devem liderar times pragmaticamente em relação a objetivos bem estabelecidos. Bons arquitetos fogem da paralisia de análise e entregam resultados, custe o que custar. Arquitetos são seres pragmáticos.
06. Manter-se ocupado é fácil. Ser produtivo é diferente.
“Never confuse motion with action.”
Manter-se ocupado é fácil. Fazer da ocupação um trabalho produtivo é diferente. Bons arquitetos terminam o seu dia com pequenos produtos entregues. Eles se movimentam em relação aos seus alvos e não ficam ocupados em intermináveis reuniões infrutíferas ou documentos que não agregam valor tangível.
07. Errar é humano.
“Give Yourself Permission to Make Mistakes” 
Ficar na zona de conforto raramente levará um arquiteto a buscar soluções melhores para os seus software. Um excelente exemplo são as provas de conceito, que experimentam novas soluções em um projeto. Uma prova de conceito tem três resultados possíveis: sucesso, fracasso ou inconclusivo. Bons arquitetos não tem medo de fazer provas de conceito e experimentar novas soluções.
08. Seja persistente.
“Energy and persistence conquer all things.”
Arquitetar bons softwares não é trivial. Requer energia alta, trabalho duro e muita persistência. Significa negociar com gerentes e usuários. Significa liderar desenvolvedores. Significar enfrentar problemas complexos a cada dia. Significar aprender todo dia. Significa aprender a ouvir nãos e lidar (com frequência) com os seres mais arrogantes ou intransigentes que a genética do DNA humano permitiu conceber. Significa seguir em frente e não desistir.
09. Auto-conhecimento.
“There are three things extremely hard: steel, a diamond, and to know one’s self.”
Conhecer a si mesmo é fundamental para ser um arquiteto melhor e para compor o seu time. Arquitetos que reconhecem as suas forças e suas fraquezas tem a capacidade de saber o que podem fazer sozinhos, o que podem fazer em grupo e o que devem delegar.
10. Melhore sempre
“Be at war with your vices, at peace with your neighbors, and let every new year find you a better man.”
Arquitetos que acreditam que já sabem tudo estão se enganando. Como diria Benjamim Franklin, esteja em guerra com os seu vícios. Se você não consegue ouvir um estagiário, pratique a técnica de Escuta Ativa. Se o seu documento de arquitetura tem mais erros de regência verbal e uso de orações coordenadas e subordinadas do que o filho de 14 anos do seu vizinho, seja humilde para se matricular em um curso de português.  Se você não conhece a linguagem XPTO, faça um curso e frequente DOJOs aos sábados com seus amigos nerds. Se você não conhece sobre segurança ou acessibilidade Web e precisa disto em seu projeto, vá estudar sobre o assunto. Sempre haverá algo que você possa aprender na profissão de arquitetura de software.
Adaptado livremente a partir do blog de Thea Easterby – 14 Lessons From Benjamin Franklin About Getting What You Want In Life.

Nenhum comentário:

Postar um comentário