Página 12 de 16
O quão ruim é pedir “confirmação de leitura” dos e-mails que eu envio?
Esta é uma dúvida comum de gerentes de projetos e outros profissionais que, de forma cotidiana, trabalham com comunicação dentro das empresas. Como centralizadores de informação, eles são responsáveis pela comunicação efetiva entre os interessados de um projeto. Por ser comum as empresas adotarem softwares de e-mail (Outlook, Live Mail, entre outros) que trazem a “incrível” funcionalidade de “confirmação de leitura”, nada melhor que usar tal recurso em todos os e-mails para garantir que os envolvidos estão recebendo as comunicações devidas, não é mesmo? Errado!
O que é a confirmação de leitura?
É basicamente um e-mail automático de resposta avisando que uma mensagem foi aberta. A pessoa que lhe enviou a mensagem pode ativar uma configuração global de “confirmação de leitura”, isto é, todas as mensagens dela pedem confirmação, como também ativar seletivamente por e-mail enviado. Quando você recebe o e-mail, a configuração padrão é perguntar se você quer confirmar o recebimento. Em caso afirmativo, uma mensagem será enviada de volta ao remetente.
Veja abaixo imagens da configuração de “confirmação de leitura” e da mensagem de confirmação que você vê ao receber um e-mail.
Muitas pessoas ativam a opção global de solicitar confirmação de leitura para todas as mensagens e não refletem sobre o as consequências disso.
Como as pessoas encaram a confirmação de leitura
Certo gerente estava cogitando pedir confirmação em todas as comunicações que iria realizar, mas antes iniciou um debate num fórum. Os participantes da discussão foram unânimes em responder que os profissionais em geral consideram essa atitude como algo, no mínimo, rude.
Há ainda uma sensação de invasão de privacidade, ao visualizar uma mensagem e ser interrompido por uma caixa de diálogo perguntando se você quer confirmar o recebimento.
Outro problema é que pessoas ocupadas olham rapidamente novos e-mails e os marcam como “não lidos” para depois tomarem uma ação adequada. Elas não querem ter sua atenção desviada naquele momento, principalmente se há documentos anexos que demandariam a interrupção do fluxo de trabalho. Nesse caso, a mensagem de confirmação de leitura gera uma contradição, pois o conteúdo do e-mail não foi devidamente analisado e não há uma opção de enviar a confirmação posteriormente.
Por esses e outros motivos, várias pessoas simplesmente desativam por completo qualquer resposta de confirmação de leitura. Eu sou uma delas.
Razões erradas para usar a confirmação de leitura
Um dos motivos ocultos que estão por detrás do uso da confirmação de leitura é que o emissor do comunicado (gerente do projeto, administração, gestor, etc.) quer delegar à ferramenta a sua responsabilidade de garantir a eficiência da comunicação. Ele pensa que, se a leitura for confirmada, então já “passou a bola pra frente” e a responsabilidade não recai mais sobre ele. Agora, de mãos lavadas, caso a execução do projeto não ande de acordo com o plano, ele poderá orgulhosamente abrir sua caixa de e-mails e apontar para o culpado pelo atraso do projeto dizendo: “olha aqui a confirmação de que você recebeu o comunicado X no dia Y”. Isso é um tiro no pé. O recebimento e leitura de uma mensagem não podem ser confundidos com comunicação efetiva de forma alguma, muito menos se pensarmos em conseguir a colaboração e o compromisso dos envolvidos, que são coisas bem diferentes.
Outra possível razão para alguém desejar receber confirmações de leitura é a curiosidade de saber quem lê seus e-mails e quando. Não é preciso ir a fundo para dizer que é uma péssima ideia, pois basta saber que a maioria dos seus colegas irá se aborrecer, ignorar o pedido de confirmação e a curiosidade não será satisfeita no final.
Conclusões
A “confirmação de leitura” não garante a eficiência da comunicação. Para todos os efeitos, ela não é confiável para nenhum fim.
O uso de tal recurso pode causar mais problemas do que ajudar e deve ser restrito a determinadas situações, quando houver prévio acordo entre as partes, onde emissor e receptor concordem que será útil para um objetivo específico.
Usa notebook/laptop? Atenção com a saúde!
Há alguns dias minha esposa começou a reclamar de dores nos pulsos. Contextualizando, ela trabalhava comigo em desenvolvimento de software e está bem acostumada a usar computadores cotidianamente há anos. Refletindo sobre o que pode ter ocorrido, ela chegou à conclusão de que a única mudança significativa que ocorreu recentemente foi que, há aproximadamente dois meses, troquei o desktop da minha casa por um notebook.
Através de uma rápida pesquisa percebi o quanto fomos ignorantes nesse sentido. Há anos a tendinite e outros males têm sido associados ao uso excessivo de teclados e outros periféricos. Entretanto, a “nova geração” de usuários de dispositivos móveis, por alguma razão, parece ignorar os riscos à saúde que podem advir do uso cotidiano desses aparelhos.
Problemas comuns durante o uso de notebooks
Notebooks são portáteis, relativamente fáceis de carregar e usar em qualquer lugar: sofá, cama, banquinho. Justamente aí começam os riscos, pois alguns princípios básicos que aprendemos com o uso de computadores desktop parecem ter sido esquecidos quando os trocamos pelos seus primos móveis, tais como: colocar o monitor na altura da vista, manter uma postura ereta e apoiar confortavelmente os pulsos.
Usar o notebook no colo pode gerar desconforto devido ao aquecimento. De qualquer forma, evite usá-lo em qualquer superfície “fofa” para evitar superaquecimento.
Recomendações saudáveis para o uso de notebooks
Sempre que possível conecte monitor, teclado e mouse ao notebook. Não fique com preguiça.
Além disso, todas as recomendações de saúde para PCs desktop aplicam-se também aos notebooks, tais como: evitar o uso prolongado, alongar-se e descansar a vista em intervalos regulares, manter uma distância de pelo menos 50 centímetros da tela e corrigir constantemente a postura.
Curiosidades
Embora os computadores portáteis sejam comumente chamados de notebooks, principalmente aqui no Brasil, o termo laptop parece ser mais comum nos países de fala inglesa.
A palavra lap é traduzida pelo termo colo, então laptop é literalmente algo que fica em “cima do colo”. Essa é a forma que muitas pessoas usam esse aparelho, mas com certeza os fabricantes não estavam pensando na saúde dos usuários quando conceberam o produto.
Seguem algumas referências internacionais, pois ao que parece ninguém por aqui está muito preocupado com isso:
What is a Legacy System?
If you work with IT, certainly you already heard about “legacy systems”. However, unless you have searched about it by yourself, I doubt someone took the time to explain what it really means. As in many lingoes, people often just use it without really knowing its meaning and are ashamed of telling they don’t know what it is. So legends emerge. After all, we all born knowing such an obvious thing, isn’t?
Defining a legacy system
What is a legacy system? One says it’s an old system, another a system “received” from others or even a system that cannot be modified. Indeed, there isn’t a unified definition of legacy systems, but there is a set of indicators we could loot at. Let’s see some of them:
Lifetime
An “old” system, built relatively a long time ago, isn’t necessary a legacy. The lifetime is certainly an indicator, but not a definition.
Usefulness
A system that isn’t used anymore is not a legacy system. A good indicator is a system that’s essential for the business and cannot be abandoned, even though sometimes people would want to.
Obsolete Technologies and Hardware
A third indicator of a legacy system is its obsolescence. Some systems work on ancient hardware, such as mainframes, which components are costly and rare. Deprecated programming languages, development tools, protocols, database systems and data formats are also important to be considered.
Maintenance
Another tip about a legacy can be detected when all the original developers are retired or left the company, being difficult to replace the workforce. Actually, if people prefer to die instead of working on a software, probably there is a legacy system involved.
Documentation
A few authors claim that a characteristic of a legacy system is lack of documentation. I completely disagree. In this way, the majority of modern systems would born as legacies. 😉
However, if no one knows the business rules behind it and it’s impossible extract them from the implementation, that certainly indicates a legacy system.
Creating a legacy system
Specific decisions and actions, or the lack of them, collaborate in making legacies.
Don’t design properly
The main act that produces legacy systems occur just in its conception. A critical system, from business point of view, without a good design inevitably will become a legacy quickly, as soon as it’s deployed and people realize new features are hard to be added.
Don’t refactor
The system’s complexity grows when it’s modified to meet new requirements. We can call it “entropy”. When code is changed or added without any control, it becomes more and more unorganized and difficult to understand. Without refactoring and internal improvements of the architecture, it would reach a point where will be almost impossible to make any modification without break something.
A friend of mine used to say: “this system is like a short blanket, you cover your feet and it uncovers your chest, you cover your chest and it uncovers your feet”. Did your hear of cases when for each bug fix, two new bugs arose? I heard about a company that chose don’t fix a system because they feared it would not work anymore, since the consequences of changes were unpredictable.
Conclusion
We looked at various indicators of a legacy system, then a few items about how we, as developers, contribute to their appearing.
A more generic and broad definition of legacy system, which I learned from an advisor and professor, goes like this: from a point in the lifetime of a system, its architecture becomes complex enough to make the cost of maintenance higher than the cost of building a new one. There are some issues in this definition, but I won’t go into details. The main idea is: if the cost to add new features is a great constraint to the business, we have a legacy.
There is not absolute rule to define what a legacy system is, but such knowledge about this type of system surely help in management decisions and also in the development of new systems, since we’re able to take actions against the growing complexity in order to make system’s lifetime longer.
O que é um sistema legado?
Se você é de TI, tenho certeza que já ouviu diversas vezes a expressão “sistema legado”. Porém, a não ser que você tenha realizado uma pesquisa por conta própria, duvido que alguém tenha se dado ao trabalho de lhe explicar o que isso significa. Como ocorre com diversos jargões, muitas pessoas os usam sem saber seu exato significado e quem ouve fica constrangido de dizer que não sabe exatamente o que aquilo significa. Assim surgem as lendas. Afinal, todos nascemos sabendo algo tão óbvio, não é mesmo?
Definindo um sistema legado
Mas o que é um sistema legado? Alguns dizem que é um sistema antigo, outros que é um sistema recebido de terceiros e há quem diga que é um sistema que não pode ser alterado. Na verdade, não existe uma definição única do que é um sistema legado, mas existe um conjunto de indicadores que devemos analisar. Vejamos alguns:
Tempo de Vida
Um sistema “velho”, desenvolvido há um tempo relativamente grande, não é necessariamente um legado. O tempo que um sistema tem pode ser um indicador inicial de alerta, mas não define um sistema como legado.
Utilidade
Um sistema velho que não é mais usado não é considerado um legado. Um bom indicador de um sistema legado é quando o mesmo ainda é essencial para o negócio, isto é, não se consegue abandoná-lo.
Tecnologias e Hardware Obsoletos
Um terceiro indicador de um sistema legado é a sua obsolescência. Alguns sistemas funcionam em hardware antigo, principalmente mainframes, cujos componentes são extremamente caros. Linguagem de programação, ferramentas de desenvolvimento, protocolos, bancos de dados e formatos de arquivos depreciados também são itens importantes.
Dificuldade de Manutenção
Um outro indicador é se os desenvolvedores originais do sistema já se aposentaram ou trocaram de emprego e é difícil encontrar mão-de-obra para manutenção. Na verdade, se “colocar a mão num vespeiro” é uma metáfora válida para mexer em um sistema, quase certamente você possui um legado em mãos.
Documentação
Alguns autores afirmam que uma característica de sistemas legados é a falta de documentação. Discordo completamente. Se fosse assim praticamente todos os sistemas modernos também seriam legados. 😉
Entretanto, se ninguém conhece as regras de negócio implementadas em um sistema e não é possível extraí-las da implementação de alguma forma, isso pode ser um indicador de um legado.
Criando um sistema legado
Além das características de um sistema, existem determinadas ações, ou a falta delas, que colaboram para ele tornar-se um legado.
Não projetar adequadamente
O principal ato produtor de sistemas legados ocorre logo em seu nascimento. Um sistema crítico do ponto de vista do negócio sem um projeto adequado inevitavelmente se tornará em um legado muito mais rapidamente, tão logo ele seja implantado e novas funcionalidades sejam difíceis de adicionar.
Não realização de melhorias
A complexidade de um sistema aumenta na medida em que ele é alterado para atender a novas necessidades do negócio. Código é acrescentado e modificado sem controle, tornando-se cada vez mais desorganizado e confuso. Sem refatoração e melhoria da qualidade interna, chega um momento em que é quase impossível alterar uma funcionalidade sem impactar em outra.
Como diz um colega: “esse sistema é igual cobertor curto, você cobre o pé e ele descobre a cabeça, cobre a cabeça e ele descobre o pé”. Já ouviu de casos onde, para cada bug corrigido, dois novos eram introduzidos? Eu já vi um caso onde decidiu-se não arrumar um sistema devido ao medo dele parar de funcionar, pois as consequências das alterações eram imprevisíveis.
Conclusões
Vimos diversos indicadores de sistemas legados, além de alguns itens sobre como nós, desenvolvedores, contribuímos para o surgimento deles.
Uma definição mais genérica e abrangente de “sistema legado”, que aprendi com meu orientar de monografia, é a seguinte: a partir de um momento do ciclo de vida do sistema, sua arquitetura torna-se tão complexa ao ponto do custo de manutenção ser maior do que o custo de desenvolver um novo sistema. Há várias questões nessa definição, nas quais não vou entrar em detalhes, mas a ideia geral é que, se o custo de acrescentar novas funcionalidades é um impeditivo para o negócio, temos um sistema legado.
Enfim, não há uma regra absoluta para definir o que é um legado, mas tais conhecimentos sobre esse tipo de sistema certamente ajudam em decisões gerenciais e também no desenvolvimento de novos sistemas, desde que tomemos ações contra a complexidade crescente do software que prolonguem sua vida útil.
Reflexões sobre o uso de frameworks
Em meu último artigo, Porque eu odeio frameworks, traduzi uma parábola fictícia que critica a crescente complexidade dos frameworks. Se você não tem muita experiência com Design Patterns (Padrões de Projeto) e com diversificados frameworks, provavelmente não tenha entendido ou mesmo achado o texto pouco interessante.
Agora, sendo mais direto, irei analisar nos tópicos a seguir alguns dos problemas e dificuldades que devemos nos precaver quando usamos frameworks e bibliotecas. Escolhas erradas impactam todas as fases do desenvolvimento de um sistema!
Complexidade excessiva
Quando aprendemos sobre Design Patterns e princípios como coesão e desacoplamento, temos a tendência de considerar tudo isso como soluções mágicas para os problemas de complexidade do software. Alguns começam a aplicá-los indiscriminadamente de forma que, mesmo operações que antes eram simples, exigem agora diversas classes para implementação e conhecimentos de vários conceitos para o entendimento.
Quando ainda estamos nessa fase de “descoberta”, onde acreditamos cegamente nas “vantagens”, sem compreender as consequências de nossas decisões ou mesmo a correta aplicação dos padrões, podemos acabar com dezenas de frameworks pendurados em nossos sistemas e inúmeras classes adicionais mesmo para tarefas simples. Já ouviu a expressão “matar uma mosca com um canhão?”
Soluções “genéricas”
Bons frameworks e bibliotecas possuem aplicações bem definidas. Nenhum framework é tão bom e completo a ponto de ser usado em todo e qualquer projeto. Nem mesmo uma determinada arquitetura como o MVC, por exemplo, mas infelizmente não é sempre assim que aprendemos na teoria.
Por outro lado, nós, desenvolvedores, somos culpados muitas vezes de usar um framework ou biblioteca indiscriminadamente, simplesmente porque já temos algum conhecimento.
Comprometimento da Arquitetura
Muitos frameworks são intrusivos no que diz respeito à arquitetura do software. Isso quer dizer que eles nos obrigam a tomar certas decisões arquiteturais simplesmente para que eles funcionem.
Infelizmente, a realidade hoje é que a grande maioria dos sistemas existentes possuem suas regras de negócios codificadas conjuntamente com classes específicas de terceiros. Não sabemos, e talvez nem pensemos sobre isso, o quanto somos orientados a tecnologias. Para falar a verdade, eu reconheço que também sou culpado disso. Quando codificamos, na maior parte das vezes, estamos mais preocupados com questões técnicas do que em realmente atender aos requisitos. Ou pior, quantas vezes não queremos simplesmente concluir o trabalho e não nos preocupamos com a qualidade interna do código? Infelizmente, a “preguiça” do programador em codificar corretamente é um dos grandes fatores que fazem crescer o número de defeitos e o número de horas extra.
Conclusão
Infelizmente, é preciso queimar muitos neurônios para criar frameworks e bibliotecas que, sendo flexíveis, não sejam demasiadamente complexos e intrusivos nos sistemas. E o mesmo se aplica ao uso deles. Bons programadores devem saber não apenas como configurar, instanciar e executar objetos de frameworks e bibliotecas, mas principalmente sua precisa escolha e aplicação.
Por fim, para divertimento dos nerds de plantão, selecionei um exemplo de um Hello World em Java que abusa um pouco da complexidade. Ele serve para ilustrar como é possível complicar algo tão trivial.
public interface MessageStrategy {
public void sendMessage();
}
public abstract class AbstractStrategyFactory {
public abstract MessageStrategy createStrategy(MessageBody mb);
}
public class MessageBody {
Object payload;
public Object getPayload() { return payload; }
public void configure(Object obj) { payload = obj; }
public void send(MessageStrategy ms) {
ms.sendMessage();
}
}
public class DefaultFactory extends AbstractStrategyFactory {
private DefaultFactory() {}
static DefaultFactory instance;
public static AbstractStrategyFactory getInstance() {
if (null==instance) instance = new DefaultFactory();
return instance;
}
public MessageStrategy createStrategy(final MessageBody mb) {
return new MessageStrategy() {
MessageBody body = mb;
public void sendMessage() {
Object obj = body.getPayload();
System.out.println(obj.toString());
}
};
}
}
public class HelloWorld {
public static void main(String[] args) {
MessageBody mb = new MessageBody();
mb.configure("Hello World!");
AbstractStrategyFactory asf = DefaultFactory.getInstance();
MessageStrategy strategy = asf.createStrategy(mb);
mb.send(strategy);
}
}
* Extraído de http://seenonslash.com/node/465
Porque eu odeio frameworks…
Decidi construir uma prateleira de temperos. Como já fiz pequenos projetos com madeira anteriormente, acredito ter uma boa ideia do que eu vou precisar: um pouco de madeira e algumas ferramentas básicas, como fita métrica, serra, nivelador e um martelo.
Vou até uma loja de ferramentas para comprar o que preciso e pergunto ao atendente onde encontro um martelo.
– Um martelo? – ele pergunta. Na verdade ninguém mais compra martelos. Eles estão meio fora de mora.
Surpreso com essa mudança, pergunto a ele o por quê.
– Bem, o problema com martelos é que existem muitos tipos diferentes: do tipo marreta, o tradicional (com as duas pontas para tirar pregos), o de cabeça arredondada, o de borracha e assim por diante. E se você comprar um tipo de martelo e depois perceber que precisava de outro tipo? Você teria de comprar outro martelo. Sendo assim, a maioria das pessoas queria apenas um único martelo que pudesse executar todos os tipos de marteladas que você possa conhecer em sua vida.
– Suponho que isso seja bom. Pode me mostrar onde encontro o “martelo universal”?
– Não, nós não vendemos ele mais. Estão obsoletos.
– Sério? Mas você acabou de me dizer que o “martelo universal” é a onda do futuro.
– Descobrimos que, se você faz um tipo de martelo capaz de fazer todos os tipos de tarefas de todos os tipos de martelos, ele na verdade não é tão bom em nenhuma tarefa. Pregar um prego com uma marreta não é muito eficiente. E, se você quer matar sua ex-namorada, não há melhor substituto do que o martelo com cabeça arredondada.
– Isso é verdade. Mas então, se ninguém compra mais “martelos universais” e você não vende mais os martelos tradicionais, que tipo de martelos você vende?
– Na verdade, nós não vendemos nenhum martelo.
– Então…
– Conforme nossas pesquisas, o que as pessoas realmente precisavam não era um “martelo universal”, no fim das contas. Sempre foi melhor ter o tipo de martelo adequado para o trabalho. Então nós começamos a vender fábricas de martelos capazes de produzir qualquer tipo de martelo que você possa se interessar em usar. Tudo o que você precisa fazer é preencher a fábrica de martelos com trabalhadores, ativar a maquinaria, comprar a matéria prima dos martelos, pagar as contas e, voilà, você terá exatamente o tipo de martelo que precisa na hora!
– Mas eu não queria comprar uma fábrica inteira de martelos.
– Isso é bom, porque nós também não as vendemos mais.
– Mas você acabou de dizer que…
– Nós descobrimos que a maioria das pessoas realmente não precisa de uma fábrica inteira de martelos. algumas pessoas, por exemplo, nunca precisarão de um martelo com cabeça arredondada (talvez porque não tenham uma ex-namorada ou já usaram um furador de gelo para matá-las). Então, não há razão para alguém comprar uma fábrica de martelos que pode produzir todo tipo de martelo existente debaixo do sol.
– Sim, isso faz muito sentido.
– Então, ao invés disso, nós começamos a vender esquemas para fábricas de martelos, permitindo a nossos clientes construir suas próprias fábricas de martelos, personalizadas para fabricar apenas os tipos de martelos que eles iriam precisar.
– Deixe-me adivinhar: vocês não vendem isso mais…
– Não! Certamente não! Descobrimos que as pessoas não queriam construir uma fábrica inteira apenas para fabricar um ou dois martelos. Deixe a construção da fábrica para os especialistas em construção de fábricas, foi o que eu sempre disse!
– E eu tenho que concordar com você.
– Isso. Então nós paramos de vender os esquemas e começamos a vender fábricas de construção de fábricas de martelos. Cada fábrica de fábricas de martelos é construída para você pelos principais especialistas no ramo de fábrica de fábricas de martelos, então você não precisa se preocupar com nenhum detalhe em construir uma fábrica. E ainda assim você tem todos os benefícios de ter sua própria fábrica personalizada, produzindo seus martelos personalizadas rapidamente, de acordo suas próprias especificações de martelo.
– Bem, na verdade, isso não parece…
– Eu sei o que você vai dizer! Nós não vendemos mais isso também. Por alguma razão, poucas pessoas estavam comprando as fábricas de fábricas de martelos, então nós criamos outra solução para resolver o problema.
– Hu-ho!
– Nós analisamos a situação com calma e olhamos para toda a infraestrutura de ferramentas. Então entendemos que as pessoas estavam frustradas em ter que gerenciar e operar uma fábrica de fábricas de martelos, tanto quanto a fábrica de martelos que era produzida. Esse tipo de trabalho adicional pode ficar muito confuso quando você lida com um cenário provável de também ter que operar uma fábrica de fábricas de fitas métricas, uma fábrica de fábricas de serras e uma fábrica de fábrica de niveladores, sem mencionar o conglomerado de fabricação de chapas de madeira. Quando nós olhamos a situação com a devida atenção, vimos que era tudo muito complexo para alguém que quer apenas construir uma prateleira de temperos.
– Nem me diga!
– Então, nesta semana, nós estamos introduzindo no mercado a fábrica de fábricas de fábricas de ferramentas de propósito geral, de forma que todas suas diferentes fábricas de fábricas de ferramentas podem ser produzidas por uma única fábrica unificada. A fábrica de fábricas de fábricas não irá apenas produzir as fábricas de fábricas de ferramentas que você precisa, mas cada uma das fábricas de fábricas irão produzir fábricas únicas baseadas nas suas especificações personalizadas de ferramentas. O conjunto final de ferramentas que irão emergir desse processo serão as ferramentas ideias para o seu projeto em particular. Você terá exatamente o martelo e a fita métrica que precisa para sua tarefa, tudo com o simples pressionar de um botão (embora você tenha ainda que implantar alguns “arquivos de configuração” para fazer tudo isso funcionar de acordo com suas expectativas).
– Então, você não tem nenhum martelo? Nenhum mesmo?
– Não. Se você quer mesmo uma prateleira de temperos de alto padrão e de acordo com as especificações da indústria, você precisa urgentemente de algo mais avançado do que um simples martelo de uma lojinha de ferramentas.
– Isso é o que todos estão fazendo agora? Todo mundo está usando uma fábrica de fábricas de fábricas de ferramentas de propósito geral, sempre que precisam de um martelo?
– Exato!
– Tudo bem, Acho que vou querer uma dessas também. Se é assim que todos estão fazendo, acho melhor aprender dessa forma.
– Vai ser bom pra você.
– Vem com manual, né?
Trecho extraído de http://discuss.joelonsoftware.com/?joel.3.219431.12
Seja um especialista
Neste artigo, simplesmente farei a tradução de um pequeno trecho do livro The Passionate Programmer, de Chad Fowler, que me chamou muito a atenção.
Infelizmente, a indústria de software tem produzido em massa esses especialistas superficiais, que usam o termo especialista como uma desculpa para saber apenas uma coisa. Na indústria médica, um especialista é alguém com um entendimento profundo de alguma área específica. Médicos encaminham seus pacientes a especialistas porque, em circunstâncias específicas, o especialista pode cuidar melhor deles do que um clínico geral.
Então, o que deve ser um especialista na área de desenvolvimento de software? Eu vou lhe dizer o que estava procurando em cada esquina e beco naquela viagem de recrutamento. Eu estava buscando pessoas que entendessem profundamente o ambiente de programação e produção Java. Queria gente que pudesse dizer “já passei por isso, resolvi de tal jeito” em 80 por cento das situações que poderíamos encontrar, cuja profundidade de conhecimento pudesse fazer os 20 por cento restantes suportáveis. Eu queria alguém que, enquanto lidasse com abstrações de alto nível, entendesse os detalhes de baixo nível da implementação daquelas abstrações. Eu queria alguém que pudesse resolver qualquer problema em produção que pudéssemos encontrar ou pelo menos soubesse para quem pedir ajuda.
Esse é o tipo de especialista que sobreviverá às mudanças na indústria da computação. Se você é um especialista em .NET, isso não é uma desculpa para não saber nada além de .NET. Isso significa que se algo tem a ver com .NET, você é a autoridade. O Servidor IIS travou e precisa ser reiniciado? “Sem problemas.” Integração de código fonte com Visual Studio .NET? “Vou mostrar como se faz.” Clientes ameaçando cancelar o projeto por questões obscuras de desempenho? “Me dá 30 minutos.”
Se não é isso que ser um especialista significa para você, então espero que você não diga que é um.
Texto original:
Unfortunately, the software industry has churned out a whole lot of these shallow specialists, who use the term specialist as an excuse for knowing only one thing. In the medical industry, a specialist is someone with a deep understanding of some specific area of the field. Doctors refer their patients to specialists, because in certain specific circumstances, the specialist can give them better care than a general practitioner.
So, what should a specialist be in the software field? I can tell you what I was searching for in every nook and cranny on that recruiting trip. I was searching for people who deeply understood the Java programming and deployment environment. I wanted folks who could say “been there, done that” in 80 percent of the situations we might encounter and whose depth of knowledge could make the remaining 20 percent more livable. I wanted someone who, when dealing with high-level abstractions, would understand the low-level details of what went into the implementation of those abstractions. I wanted someone who could solve any deployment issue we might encounter or would at least know who to call for help if they couldn’t.
This is the kind of specialist who will survive in the changing computer industry. If you’re a .NET specialist, it’s not just an excuse for not knowing anything except .NET. It means that if it has to do with .NET, you are the authority. IIS servers hanging and needing to be rebooted? “No problem.” Source control integration with Visual Studio .NET? “I’ll show you how.” Customers threatening to pull the plug because of obscure performance issues? “Give me thirty minutes.”
If this isn’t what specialist means to you, then I hope you don’t claim to be one.
Dependência Organizacional
Charles Chaplin, no filme Tempos Modernos, pinta um retrato cômico de um operário na era industrial. Seu trabalho é apertar um parafuso e provavelmente ele não tem ideia do que está ajudando a construir. Extrapolando toda a crítica social dessa obra, será que, como profissionais, podemos extrair uma lição prática para hoje? Acredito que sim!
Antes de falar sobre que tipo doença é essa tal de dependência organizacional ;-), deixarei o caro leitor com uma indagação: você é dependente da estrutura da sua empresa? Se trocar de emprego hoje, ainda que na mesma área, teria que praticamente recomeçar sua carreira?
O que é a Dependência Organizacional
Na área de TI, tenho notado que, em empresas de médio e grande porte, as quais contam com um ambiente complexo, o desenvolvedor tende a aprender uma forma muito específica de engenharia de sistemas. Ele simplesmente “pega o jeito” da empresa, isto é, aprende a usar ferramentas e processos específicos para criar um tipo específico de aplicação.
Também já vi currículos onde profissionais de desenvolvimento afirmam ter experiência com ferramentas ou frameworks criados dentro da empresa onde trabalham e usados exclusivamente por elas. Sinceramente, tal experiência é, no mínimo, irrelevante, exceto se conceitos de Engenharia de Software forem explícitos, o que dificilmente ocorre com ferramentas internas. Imagine alguém que passou anos criando software com o gerador de tabelas e formulários do Microsoft Access. Dificilmente isso agregará boas práticas sobre modelagem de banco de dados, programação e elaboração de interfaces que sirvam para outras plataformas.
Além disso, a área de TI está cada vez mais complexa. Novos processos, ferramentas, tecnologias e frameworks surgem com uma frequência alta. Se não nos esforçarmos constantemente em aprender, permanecendo numa zona de conforto, acabamos nos tornarndo “especialistas” limitados.
Enfim, a verdade é que muitos profissionais são completamente dependentes da estrutura de uma empresa. Eles ficam perdidos fora do ambiente de trabalho com o qual estão acostumados e dificilmente conseguem manter um diálogo com colegas de outras empresas. Infelizmente, a carreira deles se resume a fazer o que lhes é ordenado.
O ambiente de trabalho
O local de trabalho influencia, até certo ponto, no desenvolvimento do profissional. O trade-off que muitos encontram é algo dessa natureza:
- Trabalhar em uma empresa de grande porte, com estabilidade e boa estrutura, mas ser apenas um operário com uma tarefa específica que nunca enxerga o todo.
- Ou entrar numa empresa menor, talvez com um salário menor, um trabalho desafiador, mas que recompensará e impulsionará sua carreira.
Não é uma escolha fácil, quando há chance de escolha. Porém, independente da cultura da empresa na qual trabalhamos, devemos buscar nos desenvolver e amadurecer como profissionais.
Uma dica para desenvolvedores de software
Desenvolver-se como profissional de TI não se trata apenas de código e tecnologia, mas, falando especificamente aos desenvolvedores, gostaria que todos fossem full stack developers. O que é um full stack developer? Trata-se de alguém que domina diversos aspectos da arquitetura de sistemas.
Faça uma auto-avaliação sobre seu conhecimento. Todos querem ser o novo Zuckerberg, mas, sinceramente, ideias não valem nada. Você tem a capacidade de concretizá-las? Criar um sistema do zero, desde o banco de dados até a interface com o usuário?
Listarei abaixo alguns dos conhecimentos[1] que um desenvolvedor pode (e deve) ter:
Servidor, Rede e Hospedagem
- Entender o funcionamento, onde e porque podem ocorrer falhas.
- Usar apropriadamente sistemas de armazenamento, nuvem e recursos de rede.
- Entender de redundância e disponibilidade de dados.
- Compreender como a aplicação escala de acordo com o hardware.
- Entender problemas de concorrência e multi-threading.
- Prover mensagens de log coerentes, pois provavelmente outras pessoas irão analisá-las antes de você.
Modelagem de dados
- Criar modelos consistentes pois, se o modelo de dados é ruim, as regras de negócio ou outras camadas mais altas da arquitetura começarão a ter gambiarras para contornar os casos que o modelo não consegue tratar.
- Full stack developers devem saber como criar modelos de dados razoavelmente normalizados, usando adequadamente chaves estrangeiras, índices, visões e outros recursos disponíveis.
Regras de negócios
- Ter conhecimentos sólidos sobre orientação a objetos é essencial para a implementação do “coração do sistema”.
- Conhecer bibliotecas e frameworks específicos é importante para não se reinventar a roda.
Controle da aplicação e integrações
- Usar adequadamente frameworks é fundamental para a interação da aplicação com o “mundo externo”.
- Full stack developers devem ter a habilidade de criar interfaces de integração simples, claras e consistentes.
Interface com o usuário
- Entender como criar interfaces legíveis, além de reconhecer a importância da ajuda de designers. O visual é um fator chave de um sistema.
- Dominar HTML e CSS. JavaScript também é de extrema importância. Quem não está acompanhando, pelo menos em parte, os imensos avanços desta linguagens em suas variadas aplicações está perdendo um grande recurso.
Experiência com o usuário
- Full stack developers devem entender que os usuários querem um sistema que funcione.
- Um bom sistema não deve provocar tendinite ou cansar a vista. Bons desenvolvedores devem ser capazes de analisar a aplicação como um todo e reduzir um processo que exige uma dúzia de cliques e três passos para apenas um clique.
- Mensagens de erro devem ser claras. Se algo está errado, não saia colocando a culpa no usuário. Alguns programadores, mesmo sem querer, escrevem mensagens de erro que fazem as pessoas se sentirem estúpidas.
Entendimento das necessidades do cliente e do negócio
- Este item já vai um pouco além do papel de desenvolvedor, mas é importante ter um entendimento ainda que básico do que acontece na área do cliente onde o software é usado.
- Hoje, conhecer as regras de negócio é muito mais valioso do que saber 10 linguagens de programação.
E quem não é desenvolvedor?
Me perdoem os demais profissionais, mas o foco do artigo está nos desenvolvedores de software. Mesmo assim, estou certo de que os princípios apresentados são validos para as demais áreas.
Conheço muita gente que é razoável em desenvolvimento, mas simplesmente não está “no sangue”. Se você reconhece isso e aspira a gerente de projetos, analista de negócios ou qualquer outra área, esqueça o tópico anterior e busque um conhecimento estruturado em sua área. Não se assuste nem se iluda, galgar os degraus da carreira não é impossível, mas também não ocorre da noite para o dia.
Além disso, mesmo não sabendo programar uma linha de código, um bom profissional pode participar da próxima grande ideia bilionária se souber cumprir seu papel com excelência. Todos querem trabalhar com pessoas boas e com isso quero dizer pessoas que fazem as coisas acontecerem.
Dicas para vencer a Dependência Organizacional
Está parecendo um macaco apertando botões e preenchendo documentos que não entende? Converse com pessoas mais experientes e procure entender sobre o processo de desenvolvimento e sobre o negócio de sua empresa.
Você está acomodado em um mesmo projeto há muito tempo? Mude. Participe de projetos extra, com amigos ou open source. Em último caso, trocar de emprego pode ser necessário.
Faz tempo que não aprende nada novo? Estude. É importante estudar por conta. Ainda que você tenha alguém mais experiente para lhe dar direções gerais, não desgaste essa relação.
Diga-em com quem andas! Procure estar com pessoas que sabem mais do que você. Melhor, esteja perto de alguém que seja mais ou menos aquilo que você quer ser. O princípio de aprender por osmose pode não funcionar dormindo com a cabeça sobre um livro, mas garanto que funciona se acompanhar bons profissionais de perto.
Conclusões
Mesmo trabalhando num ambiente com poucas oportunidades de crescimento é possível agregar experiência e conhecimento que transcendam sua atual empresa se conseguir entender as razões da existência de ferramentas e processos, seu funcionamento e aplicar na prática esses conhecimentos de alguma forma. Entenda porque as coisas são como elas são!
Profissionais de outras áreas também podem aplicar os princípios apresentados aqui para quebrar a dependência organizacional. Gerentes de projeto devem refletir: eles são apenas “cobradores” e “preenchedores de planilhas” ou eles sabem realmente como fazer um projeto qualquer andar e obter a colaboração dos envolvidos? Arquitetos de sistemas sabem aplicar as boas práticas reconhecidas no mercado ou simplesmente perpetuam “o jeito que as coisas são feitas por aqui”? Administradores de bancos de dados conhecem mesmo sobre bancos de dados ou apenas seguem os padrões pré-estabelecidos pela organização?
Enfim, é normal haver, no início de qualquer carreira, um certo nível de dependência organizacional. Porém, devemos, dia após dia, nos esforçarmos para quebrar essa dependência e evoluirmos para sermos melhores do que o ambiente que nos cerca. Disciplina, estudo, auto-crítica, reflexão e auto-avaliação são fundamentais para esse processo de amadurecimento.
[1] A lista de conhecimentos e habilidades foi baseada no conteúdo deste artigo: http://www.laurencegellert.com/2012/08/what-is-a-full-stack-developer/
Quer aperfeiçoar seu Inglês de verdade?
Há algum tempo publiquei dicas sobre como comprar livros em Inglês por um preço bem razoável no The Book Depository e como estudar Inglês em casa de graça. Desde então vários colegas expressaram sua vontade e necessidade de se aperfeiçoarem nesse idioma.
Refleti bastante sobre o que poderia dizer a eles procurando entender o processo de minha próxima experiência. Não sou nenhum poliglota, mas desde que desisti do curso básico de Inglês numa escolinha de idiomas convencional, tenho estudado por conta própria até o nível onde leio com fluência, escrevo em fóruns, entendo palestras, vídeos e filmes e participo de conversas sem problemas.
Cheguei à conclusão que o período onde realmente ocorreu um salto em meu aprendizado foi quando comecei a ler. Livros não técnicos, com assuntos variados de seu interessante e escritos por bons autores. Esta é a melhor dica que posso dar para quem, como eu, não teve a oportunidade de passar um tempo num país de fala inglesa.
Estudo e entretenimento não combinam
Muitas pessoas recomendam (como eu já fiz) filmes sem legenda, músicas e outros tipos de entretenimento. Porém, em minha experiência, o progresso é relativamente bem menor, a não ser que se queira aprender expressões coloquiais e palavrões. O vocabulário da grande maioria dos filmes e músicas atuais são extremamente pobres. No caso das músicas, muitas vezes a poesia não tem sentido. Misturar estudo e entretenimento, em minha opinião, no mínimo não é eficiente. É possível aprender alguma coisa, mas é uma forma mais “preguiçosa”, pois a verdade é que ninguém pausa o filme para procurar uma palavra no dicionário.
Porque tanta gente faz curso e não aprende
Embora seja interessante ter um professor para questionar e treinar conversação, infelizmente muitas escolas não possuem professores capacitados para transmitir conhecimento. As lições padrão, principalmente para crianças e jovens, são infantis demais e sempre com os mesmos temas. Por outro lado, os alunos não estudam em casa e frequentemente fazem as lições apenas por fazer. Para eles, o importante é passar, como na escola regular.
Pessoalmente, eu não tenho interesse, nem recomendo, cursos convencionais de Inglês. São extremamente caros e o retorno é baixo.
Como ler e estudar
Baseado nas minhas reflexões, proponho a seguir um guia de estudo muito simples. São apenas direções e princípios gerais que possuem como requisito apenas um conhecimento básico da gramática inglesa, a qual se aprende no Ensino Fundamental ou Médio.
Compre um bom dicionário
Queime aquele dicionário de bolso que comprou para a escola. Invista num dicionário de verdade, um “tijolo”. Eu tenho e recomendo o Longman.
Selecione um bom livro
Não escolha o que está na moda. Procure um autor conceituado (Lewis, Tolkien, …). Também não selecione livros técnicos, pois não se aprende um idioma com eles, mas uma linguagem técnica.
Entenda o contexto
Ajuda se você tiver familiaridade ou mesmo dominar o assunto do livro. Eu garanto que, com sua intuição, você será capaz até de prever o significado de diversas palavras se for capaz de acompanhar o raciocínio do autor.
Comece devagar
Não tenha pressa em ler. Dependendo do seu nível, talvez leve alguns dias para ler a primeira página. É assim mesmo, não desista!
Anote todas as palavras novas
Circule ou anote todas as palavras que você não conhece. Dependendo da velocidade de leitura, leia um parágrafo ou página por vez, então pare, consulte e anote o significado das palavras. Finalmente, leia novamente o trecho, repetindo o processo até compreender o conteúdo.
Não pule
Não leia por ler. Leia até entender o que está ali. Peça ajuda se necessário. Então leia novamente até fazer sentido.
Não pare por aí
Procure outras fontes relacionadas: opiniões sobre o livro na Amazon, críticas, artigos sobre o assunto. A partir do momento em que você vai dominando uma área específica de conhecimento em outro idioma, fica mais fácil expandir seu conhecimento sobre outros temas relacionados e, à partir daí, construir um ponte até outras áreas.
Seja persistente
Não desanime se o ritmo for devagar no começo. Esta é a questão! Nós temos dificuldades em aprender qualquer coisa justamente porque estamos sempre pulando a parte difícil.
Colha os resultados
Quando comecei a ler meu primeiro livro usando esses princípios, lia uma página por dia, no máximo. O uso do dicionário era intenso. Quando cheguei na metade já eram 3 a 5, pois já estava acostumado com o vocabulário e consultava menos o dicionário. Até o final já me sentia bem à vontade.
No final, comece tudo novamente
Ao terminar o livro, você terá absorvido muito do outro idioma. Entretanto, existem inúmeros outros assuntos e autores a explorar, cada um com seu vocabulário. Procure outro livro e comece a expandir seu conhecimento em uma área diferente.
Seguindo essas dicas simples, variando os temas de leitura, estou certo de que em um ou dois anos estará perfeitamente habituado com o Inglês em diferentes contextos. A partir daí, sim, faz sentido assistir filmes e ouvir músicas para treinar a audição, mas sempre com critérios de qualidade.
Finalmente, espero que minha experiência lhe ajude e encoraje.
