Oito Regras para Produção de Software Eficaz

Ao longo da minha carreira, participei de vários projetos de software da vida real e observei como as coisas são feitas em todos os níveis: tomada de decisão, adoção de práticas, formação de equipes, recrutamento, distribuição de habilidades, etc. Obviamente, diferentes abordagens produziram resultados diferentes . Sendo um tipo de pessoa orientada para a melhoria, percebi e coletei as práticas mais eficazes e os melhores truques práticos para me ajudar no meu trabalho.

Aprender com a observação é uma maneira difícil e demorada de fazê-lo. Eu ficaria extremamente feliz em pegar esse conhecimento mais cedo nos livros. Infelizmente não encontrei nenhum sobre o tema. Então decidi compartilhar minha experiência com outros buscadores desse tipo de conhecimento. Espero que isso poupe alguns anos de pesquisa pessoal.

Neste artigo, você aprenderá como superar o desempenho médio do setor produzindo produtos de software robustos e confiáveis ​​que exigem de 5 a 10 vezes menos manutenção. Posso dizer sem falsa modéstia que nos últimos 10-15 anos, eu (pessoalmente, assim como minhas equipes) superei todas as expectativas, deixando um rastro de sucessos. Os gerentes não podem estar mais felizes.

Certa vez, minha equipe encerrou um projeto importante em um prazo incrivelmente curto, pelo qual recebemos um prêmio de “Equipe de Alta Performance” da alta administração. Tudo isso sem ficar noites e finais de semana nos cansando. Apenas trabalho normal.

Veja bem, o próprio conhecimento efetivo de produção de software é um poder. Na verdade, é uma espécie de magia negra que muitas pessoas não conseguem entender, mesmo quando explicada em palavras simples. Você vai obtê-lo gratuitamente. Continue lendo se quiser ser percebido como um mágico de produção de software.

Para quem é isso?

Deixe-me fazer um aviso importante, importante, importante aqui.

Dirijo-me àqueles que precisam de um aumento de produtividade. Nem tudo na vida é sobre produtividade. Nem todos os projetos de software também. Há casos em que você não é julgado pelo seu desempenho. Obviamente, essas práticas não ajudariam então.

Essas técnicas serão mais úteis para líderes de equipe, arquitetos e gerentes de projeto, embora os desenvolvedores de software sênior também possam se beneficiar delas.

Regra nº 1: entenda a mentalidade de TI

A indústria de TI é uma mistura de ciência, tecnologia, arte e negócios. É muito difícil navegar por lá sem entender esses aspectos em um nível suficientemente bom. O maior problema é que a própria indústria é bastante complexa; portanto, as melhores práticas também são complexas. Você precisa aprender muito e verificar seu conhecimento praticando muito para ter sucesso.

A incrível taxa de atualização de tecnologia o torna duplamente difícil. Nada que você aprendeu dez anos atrás é mais necessário. Então você precisa aprender em um ritmo acelerado.

Resumindo tudo isso, podemos dizer que o sucesso na área de TI não se baseia em habilidades ou sentimentos inatos, mas em exemplos práticos concretos. Nunca “siga o instinto” ou acredite apenas com base no sentimento, incluindo o seu.

Se sim, vale a pena considerar a ideia. Caso contrário, exija uma explicação muito boa e bem detalhada de como a escolha desse caminho melhora a vida da sua equipe. Se ele passar neste teste, agende um projeto leve de prova de conceitos que prove experimentalmente que ele se encaixa em seu ambiente.

O importante a entender aqui é que não existem soluções certas e erradas porque existem muitas maneiras de resolver problemas de software. No entanto, existem bons e maus entendimentos da solução.

Se uma pessoa puder articular claramente a ideia em detalhes ou estabelecer um vínculo entre a adoção dessa solução e o sucesso da equipe para persuadir outros membros da equipe, podemos confiar na visão dessa pessoa e esperar uma grande chance de sucesso.

Regra nº 2: Não misture metodologias de produção de software e desenvolvimento de software

A produção de software é baseada no desenvolvimento de software. No entanto, esses dois têm objetivos, mentalidades e práticas completamente diferentes. Tentar resolver um problema de um desses reinos com os métodos de outro produz resultados ridículos. É importante entender a distinção e usar métodos apropriados para cada um desses mundos.

O desenvolvimento de software é uma combinação de arte e artesanato. O componente de arte sempre estará lá, independentemente das ferramentas de automação e metodologias de desenvolvimento de software existentes. Portanto, resolver tarefas de desenvolvimento requer concentração máxima e proteção contra todos os outros sinais de distração.

A melhor maneira de motivar um desenvolvedor experiente é apresentar a ele uma tarefa em sua forma puramente técnica com todos os fatores humanos excluídos. Todos os requisitos também devem ser expressos em linguagem técnica. Eles devem ser facilmente verificáveis ​​para permitir que eles naveguem em direção ao objetivo durante sua fase de pesquisa individual.

A produção de software, por outro lado, está mais no domínio da administração de negócios. Você sabe o que seu cliente precisa de um lado e sabe quais recursos de equipe você tem à sua disposição de outro. Então agora você tenta direcionar os esforços de sua equipe para atingir a meta. Enquanto isso, você também pode estimar sua velocidade de progresso e apresentar um plano bem versado ao chefe. As habilidades importantes são entender os desejos de seu cliente, entender os pontos fortes de sua equipe e comunicar planos e cronogramas formais.

Dito isso, gostaria de destacar que muitas funções no desenvolvimento de software estão trabalhando nesses dois mundos – na construção de uma ponte entre negócios e tecnologia – como líderes de equipe, arquitetos, analistas e gerentes de projeto. As pessoas nesses papéis devem ser capazes de caminhar facilmente entre dois planos da realidade e entender quando é hora de falar de negócios e quando é hora de arte.

Regra nº 3: Use o armazenamento persistente como uma extensão da memória humana

A memória humana, embora incrível em capacidade, tem seus limites. Você se lembra de coisas com precisão e duração imprevisíveis e, quando esquece, não há como se lembrar à vontade.

É por isso que usamos armazenamento de memória persistente para avançar a uma velocidade previsível. Não se trata de documentação formal, como manuais do usuário, que você cria muito depois do fato e para outras pessoas usarem. Trata-se de usar documentos literalmente como extensão externa de sua memória durante o trabalho que o ajuda a passar pelo processo de desenvolvimento de software.

Eu recomendo que você documente seus pensamentos e planos ao longo do caminho sempre que estiver enfrentando tarefas não triviais ou tarefas que envolvam mais de uma pessoa. Tente torná-lo o mais barato possível. Não crie documentos formais com o logotipo da empresa. Uma boa ferramenta seria um wiki da empresa com o espaço do seu projeto nele. Crie páginas dedicadas para as tarefas ou problemas (30 segundos). Em seguida, atualize-o sempre que tiver uma ideia ou estiver prestes a discuti-la com outras pessoas.

Em uma reunião, diga “espere, deixe-me colocar isso para baixo” e gaste de 10 a 30 segundos para expressá-lo por escrito. A redação não deve ser extensa, mas deve ser completa e coerente, como se você estivesse transferindo a ideia inteira para o papel. Mais tarde, você ou qualquer outra pessoa lendo sua passagem deve entendê-la tão claramente quanto você a entende agora. Esse truque economiza muito tempo, mas permite documentar em tempo real.

Esta técnica serve a dois propósitos.

Primeiro, ele bloqueia seu progresso no caminho para o sucesso, pressionando-o com força na pedra. Não há mais riscos de alguém esquecer algo, reiterar a mesma coisa várias vezes, ou renegociar a mesma coisa que já foi negociada.

Em segundo lugar, você limpa sua mente, descartando o problema que estava incomodando você. Agora sua mente está faminta pelo próximo desafio. Que aumento de produtividade!

Isso se aplica a qualquer tamanho de projeto ou tarefa. Para maiores, você terá apenas espaços maiores com uma hierarquia de páginas que cresce gradualmente à medida que seu projeto evolui. O conceito importante aqui é preparar um espaço e estrutura de documentação antes de iniciar sua tarefa de estabelecer um protocolo de despejo de memória rápido!

Para as pessoas que preferem analogias tecnológicas, eu compararia nossa mente a um processador com imenso poder de processamento, mas memória operacional limitada. Você essencialmente pode pensar em uma coisa de cada vez. Nesta analogia, sua documentação serve como armazenamento persistente, enquanto sua mente resolve problemas complexos em uma abordagem iterativa. Em algum momento, você decide iniciar a próxima iteração, ler a documentação anterior e carregar o estado atual em sua memória operacional, pensando nisso por um tempo e atualizando o código e a documentação com suas novas descobertas. Passo a passo até terminar.

Tudo o que foi dito acima, eu não encorajo as pessoas a processar muitas tarefas ao mesmo tempo. Pelo contrário, quanto menos tarefas você tiver, melhor. No entanto, muitas situações de trabalho não são realmente otimizadas para humanos, e a multitarefa pode ser necessária e você precisa lidar com isso de alguma forma. O truque acima ajuda a lidar melhor com isso.

Regra nº 4: Pare de perder tempo com estimativa formal de tempo

Não há dois projetos iguais. Da próxima vez que você fizer um projeto semelhante, terá clientes diferentes, objetivos diferentes, uma equipe diferente; talvez até tecnologias diferentes. Mesmo usando ferramentas e componentes padrão, você ainda precisará personalizar sua configuração e arquitetura. Ao lidar com projetos de software, lembre-se de que eles envolvem algo entre 50% e 100% de trabalho personalizado. Eles exigem pesquisa, discussões, pensamento, testes e outras atividades altamente imprevisíveis. Na prática, você pode experimentar uma enorme diferença no que parece ser o mesmo tipo de projeto exato e o que você fez antes. Um novo tipo de projeto, por extensão, é quase impossível de estimar com exatidão.

Se é tão imprevisível, então como os gerentes de projeto devem apresentar um cronograma de projeto e cumpri-lo?

Existe um método formal de fazer isso descrito na literatura; ou seja, dividir o projeto inteiro em etapas menores, estimar quanto tempo cada etapa leva e, em seguida, calcular a duração total do projeto combinando a duração do trabalho de peças individuais. Há toneladas de teoria por trás deste método ensinado em cursos de MBA.

Infelizmente, porém, nenhuma quantidade de matemática pode salvá-lo. Este método é notoriamente impreciso, na medida em que é completamente inutilizável e impraticável, sem mencionar o quão incrivelmente demorado é. Nunca vi um gerente de projeto que usasse métodos formais de cálculo sem nenhum ajuste, nem mesmo entre fanáticos metodológicos. Nem mesmo quando a empresa impôs estritamente tal uso do método! Na verdade, os gestores com melhor desempenho usam métodos alternativos completamente diferentes, conforme descrito abaixo:

Um bom gerente de projeto toma conhecimento do tipo de projeto, ambiente, recursos envolvidos, tipo de organização e todos os outros aspectos do trabalho que influenciam a duração real do projeto. Claro, ninguém precisa aprender apenas com seus próprios erros. Tais observações podem ser feitas direta e indiretamente; por exemplo, através de livros ou estudando projetos feitos por outras pessoas ou mesmo simplesmente passando o conhecimento de pessoa para pessoa. Esse conhecimento estatístico de alto nível melhora a navegação do cronograma do projeto pessoal.

Gostaria de destacar duas consequências importantes do método descrito acima.

Primeiro, a precisão da estimativa melhora com a experiência. Não há como uma pessoa inexperiente, armada com qualquer metodologia forte que tenha, possa ser boa nisso. Em segundo lugar, mesmo a melhor estimativa ainda é boa apenas em termos estatísticos. Ou seja, pode-se dizer que um determinado projeto pode demorar entre quatro e doze meses. Supondo que isso esteja correto, deve-se entender que há 50% de chance de o projeto ser executado em seu tempo médio de oito meses.

Compreender a previsão estatística tem um efeito incrível. Um gerente sábio colocaria uma estimativa de doze meses em um projeto como esse e impressionaria a todos ao concluí-lo antes. Em outras palavras, ninguém esperaria que uma equipe seguisse o cronograma do projeto por um dia.

O conselho geral para os gerentes de projeto e seus chefes seria parar de perder tempo com metodologias formais de estimativa de tempo. Em vez disso, incentive a coleta de informações estatísticas sobre a duração do projeto e compartilhe essas informações em toda a empresa. Conheço empresas onde essa abordagem foi implementada em toda a empresa, resultando em uma precisão preditiva milagrosa.

Regra nº 5: Entenda o custo de alternar tarefas e conciliar prioridades

A mente humana é incrivelmente projetada pela natureza. Mesmo sendo incrível, tem suas limitações. Em outras palavras, foi projetado para se destacar em áreas específicas e em um tipo específico de tarefa.

A mente de um desenvolvedor é definitivamente um grande trunfo no desenvolvimento de software. Você, como gerente de projeto, estaria interessado em entendê-lo melhor e colocá-lo em uma posição em que tenha o melhor desempenho?

Vamos colocar em termos simples, evitando muita teoria. Lembre-se, a teoria só leva você até certo ponto antes que você precise aprender com a experiência, seja sua própria ou de outros.

A mente humana tem um forte potencial de resolução de problemas e geração de ideias. Infelizmente, nem sempre é possível explorar esse potencial, principalmente porque, para dar suporte à geração de ideias, você precisa manter todas as peças do problema juntas em sua memória ativa ao mesmo tempo. É por isso que a resolução de problemas complexos passa por uma fase de simplificação, quando uma tarefa é generalizada ou reformulada para recortar peças sem importância e diminuir o número de elementos guardados na memória simultaneamente. Em outras palavras, podemos resolver um problema complexo muito estreito ou vários problemas simples.

A proporção não é linear, no entanto. Aumentar o número de coisas que você faz simultaneamente prejudica drasticamente suas habilidades de resolução de problemas. É por isso que a humanidade sempre empregou e empregará a separação de papéis como uma otimização da vida. Duas pessoas trabalhando separadamente em duas tarefas farão um avanço mais rápido do que se ambas trabalharem em ambas as tarefas ao mesmo tempo.

Outra característica importante da mente humana é sua incapacidade de alternar entre tarefas imediatamente, como os computadores fazem. Na verdade, você não pode simplesmente parar de pensar em algo à vontade. Você também não pode começar a pensar em um novo conceito a toda velocidade imediatamente. Esse tipo de inércia mental é perfeitamente ilustrado pelos operadores de controle de tráfego aéreo. Mesmo que eles estejam olhando para o radar e vendo a imagem inteira, eles ainda precisam carregá-lo em sua memória para operar rapidamente. Leva dez minutos para um novo operador observar a tela antes de poder substituir o antigo em uma mudança de turno.

O pior é que não podemos esquecer as coisas à vontade. Tudo o que aprendemos fica conosco e gradualmente desaparece com o tempo, ocupando espaço que poderíamos usar para novos conhecimentos. E ainda pior, esse efeito é agravado por uma sensação de “negócios inacabados” às vezes. É muito mais fácil esquecer algo que está concluído e que você não vai precisar no futuro. Ao passo que, quando você deixa as coisas de lado para terminar mais tarde, seu cérebro naturalmente se agarra às informações marcadas como “para referência futura”, não querendo deixar que novos conhecimentos tomem seu lugar.

OK. Agora que delineamos a ideia de alternar tarefas, vamos ver como isso funciona em um experimento mental da vida real (por assim dizer).

Imagine que você tenha seus dez desenvolvedores regulares trabalhando em dez tarefas regulares – uma tarefa por pessoa. Supondo que possamos encerrá-los em um ambiente perfeito e livre de distrações, cada tarefa pode ser resolvida em um determinado período de tempo por uma única mente. A coisa toda levará o tempo necessário para concluir a tarefa mais longa.

Agora, vamos repetir o mesmo experimento mental. Desta vez, estaremos constantemente alternando atribuições de tarefas entre os desenvolvedores sem motivo (importante). Todos os dias, cada desenvolvedor recebe uma nova tarefa para trabalhar. Melhor ainda, vamos trocá-lo a cada hora. Em quanto tempo eles vão terminar, você acha? Talvez nunca.

O gerente de projeto no primeiro cenário foi capaz de executar o projeto de forma eficaz. O segundo conseguiu “executá-lo”, isso é certo... no sentido de que facilitaram sua morte. Parabéns. Essa técnica de matar projetos é extremamente eficaz porque, além da mera perda de tempo, também reduz o moral dos funcionários a zero.

A maioria das pessoas concordaria com o exemplo acima quando é apresentado a eles de uma forma puramente acadêmica como essa. No entanto, na vida real, de repente, eles esquecem tudo sob a menor pressão. O chefão exige um relatório de progresso ou o cliente está perguntando sobre uma determinada data de implementação de recursos - praticamente qualquer evento externo pode fazer um gerente de projeto correr para a equipe e expressar sua preocupação, seguido por uma enxurrada de reatribuições de tarefas e malabarismo de prioridades em um tentar ganhar um pouco de tempo aqui e ali, resultando em nada além de tirar o projeto dos trilhos ainda mais.

Esse é um cenário da vida real que ocorre com bastante frequência, infelizmente.

Um bom gerente se levanta e protege a equipe desses pequenos distúrbios, absorvendo a onda de choque emocional e convertendo-a em itens produtivos para discussões futuras. Isso é definitivamente difícil emocionalmente, mas é a única maneira de manter a equipe em um bom ritmo de trabalho e deixá-los entregar.

Regra nº 6: Use revisões de arquitetura como forma de melhorar o design do sistema

A indústria de TI opera com noções de super e subengenharia . Quando se trata de uma entrevista, todo mundo diz que o excesso de engenharia é ruim. Essa é fácil de responder porque a própria pergunta transmite uma conotação negativa de “over”, que significa “demais”. O verdadeiro saber prático seria reconhecer quando sua arquitetura se torna mais projetada e evitá-la nos estágios iniciais.

Deixe-me dar-lhe alguns dos meus ponteiros testados e comprovados sobre isso.

Em primeiro lugar, a solução pode ser considerada com engenharia excessiva se houver outra solução mais simples que forneça todas as funcionalidades necessárias. Isso significa que se você não conhece uma solução mais simples, então qualquer solução mais simples que você possa oferecer é a melhor aos seus olhos, a menos que alguém prove que você está errado.

Se nosso arquiteto imaginário se esforça genuinamente pela perfeição da solução, a revisão usual da arquitetura garante que ela seja ótima o suficiente. Infelizmente, a revisão de arquitetura requer pelo menos alguns outros arquitetos qualificados. Ele corre o risco de estar indisponível ou impraticável em muitos casos. Na ausência de revisão por pares, os arquitetos são propensos a erros comuns. Vamos analisá-los um por um e discutir possíveis soluções para cada um.

Um dos erros mais comuns é projetar sem um objetivo comercial em mente. Parece óbvio que qualquer atividade de trabalho deve estar vinculada à satisfação do consumidor final ou ao sucesso da empresa ou a uma necessidade comercial semelhante. No entanto, muitas vezes, você pode ver a arquitetura projetada no todo ou em parte sem esse propósito em mente. O raciocínio está ausente ou se resume a usar tantos sinos e assobios modernos quanto possível.

O arquiteto, neste caso, não faz o que o consumidor pagou. Em vez disso, eles brincam com brinquedos legais para sua própria diversão e prazer. Isso não é de forma alguma aceitável na indústria formal. E, no entanto, parece acontecer com bastante frequência de qualquer maneira.

Às vezes, o problema está na personalidade do arquiteto e sua obsessão por certas tecnologias ou ferramentas. Eles apenas gostam de usá-los e não conseguem explicar de forma coerente qual necessidade de negócios eles estão tentando resolver. Perto disso há outro caso em que as pessoas não sabem nada além de construir algo com pequenos pedaços. Certamente, qualquer evento externo desencadeia sua vontade de mergulhar no mundo do design e nunca mais voltar para um cliente real. Mesmo que o gatilho inicial possa ser uma entrada comercial válida, seu distanciamento prolongado da realidade diminui a utilidade de seu trabalho artístico.

A cura para isso é muito simples, mas requer autodisciplina. Um bom arquiteto nunca deve tocar caneta e papel até que possa responder de forma clara e honesta por si mesmo por que é necessário. Tal necessidade pode vir de diferentes formas. Pode ser um requisito formal, uma necessidade implícita de melhoria do produto ou o surgimento de novas tecnologias que tornam o projeto anterior menos eficaz. De qualquer forma, não deve ser um gatilho formal, desde que os próprios arquitetos entendam a força motriz. Então eles podem usar essa força como uma verificação final de sua qualidade de projeto.

Outro problema mais difícil de detectar está relacionado ao pensamento da arquitetura de blocos. Pessoas com essa mentalidade acreditam que há solução para tudo e essa solução é sempre implementada como um bloco de construção. Em outras palavras, eles traduzem a funcionalidade para os componentes diretamente sem avaliar a arquitetura como um todo. Eles podem simplesmente anexar um componente que forneça a funcionalidade desejada ao sistema quando surgir a necessidade de tal funcionalidade. Na maioria das vezes, isso satisfaz os requisitos formais, mas deixa o sistema em um estado incoerente. O novo bloco não foi selecionado com base na compatibilidade do sistema existente para desenvolvimento, suporte ou mesmo no modelo de licenciamento da empresa. Assim, a equipe tenta modificar a configuração existente ou implementar essa funcionalidade por meio da capacidade do sistema existente. Como resultado, o suporte e a manutenção do sistema gradualmente se transformam em um pesadelo complicado, seguido de perto pela degradação do desempenho.

Não existe uma solução simples para este problema, pois a engenharia do sistema é uma arte e nunca é possível prever se um novo componente deve ser adicionado ou pode ser evitado. A melhor prática provavelmente seria manter um acúmulo de problemas de manutenção e arquitetura ao longo do tempo, seguido por revisões periódicas da arquitetura geral do sistema. Essa revisão periódica também pode levar em consideração tecnologias emergentes. Portanto, o objetivo geral das revisões de arquitetura não deve ser corrigir problemas, mas avaliar a viabilidade potencial das melhorias desejadas e do sistema como um todo contra a iminente inevitabilidade da obsolescência.

Regra nº 7: Valorize os jogadores da equipe

A maioria dos profissionais da indústria de TI foi questionada em uma entrevista se eles são bons jogadores de equipe ou se trabalham bem em equipe. No entanto, provavelmente ninguém jamais viu uma definição clara para isso na literatura. Obviamente, tal pessoa contribuiria para o sucesso da equipe em geral, mas poucas pessoas podem realmente definir qualidades pessoais distintivas que assegurem tal sucesso.

Observei muitas pessoas trabalhando em diferentes níveis e vi como suas qualidades pessoais influenciaram o progresso do projeto. Eu gostaria de apresentar as seguintes dicas sobre as qualidades pessoais que são mais úteis no trabalho em equipe.

Comunicação

A primeira e principal qualidade, é claro, é a capacidade de se comunicar.

Imagine uma pessoa com zero habilidades de comunicação. Certamente não receber feedback dos membros da equipe os torna completamente inúteis. Isso é tão óbvio que ninguém está realmente medindo essa habilidade durante a entrevista, o que implica que a habilidade está em um nível bom o suficiente, desde que a pessoa possa falar bem.

A comunicação não é uma habilidade binária sim/não; é mais uma janela de transferência de informações. Quanto mais amplo, mais rápida e clara será a troca de informações.

Como o intervalo de abertura dessa janela varia muito entre a população, a medida da largura dessa janela é uma característica importante de um jogador de equipe. Tenha em mente que estamos falando de transmitir informações neste contexto, mas não de falar suavemente ou encorajar as pessoas ou motivá-las ou organizá-las por meio de conversas e comunicações.

O estilo de comunicação também é irrelevante. As informações podem ser transmitidas oralmente, textualmente, em imagens ou de forma mista. A pessoa pode falar rápido ou devagar. Eles podem ser amigáveis, como olhar nos seus olhos e sorrir o tempo todo, ou podem desviar o olhar e falar com uma voz monótona. O estilo pode afetar sua percepção pessoal de seu colega de trabalho, mas desde que você entenda claramente o que eles significam, qualquer estilo é suficiente.

Passemos a casos práticos de detecção e medição de habilidades de comunicação.

Existem dois aspectos principais para as habilidades de comunicação em geral. Primeiro é a vontade de compartilhar informações. Algumas pessoas estão ansiosas para compartilhar, mas outras tentam esconder informações. Essa inclinação é mais ou menos natural, mas pode ser mudada lentamente com auto motivação e treinamento. É seguro supor que a pessoa que exibe um tipo de disposição para compartilhar informações também o demonstraria no futuro. É por isso que essa característica é boa para prever o sucesso futuro de um candidato em uma equipe.

Na vida real, as pessoas que tentam esconder informações são facilmente perceptíveis. Eles geralmente tentam dar informações intencionalmente inúteis em vez de qualquer coisa que realmente seja necessária. Ou fazem perguntas preliminares para direcionar o fluxo de informações para dentro e minimizar suas respostas a uma ocorrência de “necessidade de saber”. Quaisquer que sejam suas táticas, você sentirá no final que não obteve a informação desejada deles, ou que obter a informação exigiu muito esforço extra.

É importante entender a intenção, pois alguns tipos de pessoa aberta podem fazer perguntas preliminares para entender melhor sua pergunta e, em seguida, fornecer a resposta da maneira mais conveniente. A pessoa que pretende ocultar a informação fará perguntas adicionais apenas para desviar a conversa e nunca responderá à sua pergunta inicial.

Outra parte da habilidade de comunicação é a capacidade de sintonizar o ouvinte.

Pessoas diferentes têm um nível diferente de compreensão do tópico, estilo de comunicação diferente e talvez até interesse diferente em detalhes específicos. Algumas pessoas inteligentes comunicativas variam seu fluxo de conversa dependendo da capacidade do ouvinte de entendê-lo e preparar sua resposta para fornecer informações específicas. Em tal preparação, algumas perguntas preliminares podem ser feitas para diminuir o interesse do ouvinte. A capacidade de “resolver” as diferenças de comunicação é realmente uma grande habilidade, pois nos permite alcançar o entendimento em quase todos os casos. Os falantes flexíveis, por outro lado, podem às vezes ficar presos em becos sem saída insolúveis de mal-entendidos.

Entendendo os pontos fortes e fracos

Vamos nos concentrar em outra qualidade pessoal essencial para um jogador de equipe.

A maioria das pessoas concordaria que um ambiente de equipe deve ser mais amigável do que o mundo ao redor médio para promover a colaboração e aumentar a produtividade. Portanto, é importante que uma equipe entenda os pontos fortes e fracos de cada membro para distribuir as tarefas adequadamente e cobrir os pontos fracos com os pontos fortes. O primeiro passo nesse caminho é que todos os membros avaliem honestamente suas habilidades uns contra os outros. Psicologicamente, isso pode ser difícil, pois naturalmente tendemos a esconder nossos pontos fracos dos outros, protegendo-nos.

É aqui que a atmosfera amigável da equipe vem para ajudar.

Portanto, espera-se que o novo membro jogue pelas regras do time. Infelizmente, algumas pessoas não podem baixar a guarda mesmo em um ambiente amigável. Eles se comportam como lobos solitários durante toda a vida. Isso é mais forte do que eles. Infelizmente, tal atitude não contribui para os esforços da equipe.

Existe uma técnica fácil de reconhecer esses lobos solitários na entrevista. Eles nunca admitem que não sabem de alguma coisa. Claro, as pessoas gostam de mostrar o seu melhor, mostrando todas as suas habilidades e tentando resolver todos os problemas difíceis. No entanto, há um limite de conhecimento para todos. Nossos limites moldam nossas habilidades. Não admitir limites significa que os candidatos se apresentam como um faz-tudo, igualmente bons em tudo e em nada.

Quando você contrata um especialista, provavelmente gostaria de evitar essas pessoas. Além disso, essa atitude arrogante geralmente vem com outro traço de bandeira vermelha: falta de vontade de pedir ajuda. A capacidade de pedir ajuda é absolutamente essencial para o trabalho em equipe. Sem ele, não podemos progredir e desenvolver tão rapidamente. Uma pessoa tão teimosa queimaria recursos e tempo da empresa, lutando indefinidamente em tarefas difíceis, mas nunca pedindo ajuda aos colegas de equipe. Existe um truque fácil para detectar esses candidatos na entrevista. Faça uma pergunta que não faça sentido ou mencione algum termo sem sentido. Uma pessoa normal, idealmente curiosa, simplesmente diria que não sabe e perguntaria o que é. Uma pessoa defensiva nunca faria isso, mesmo que você destaque que não existe resposta certa ou errada e que “não sei” não a desqualifica.

Regra nº 8: Foco na organização do trabalho em equipe

Há tão pouca informação sobre a organização do trabalho em equipe quanto em qualquer tópico anterior acima. Todo mundo sabe que o trabalho em equipe é melhor, mas como construir e manter uma equipe permanece um mistério. No entanto, mesmo que seja impossível cobrir todos os aspectos da formação de equipes, podemos pelo menos explorar algumas técnicas importantes de formação de equipes aqui.

Experiência em construção

Cada projeto de TI é único. Para ter sucesso nele, é preciso aprender e dominar as especificidades do projeto. Podem incluir conhecimentos técnicos e não técnicos. Um exemplo de conhecimento não técnico pode ser uma rede pessoal para gerenciamento, clientes, equipes de suporte técnico, etc. Conhecimento técnico especial são detalhes adicionais sobre habilidades gerais de TI.

Por exemplo, você pode precisar conhecer o Maven para construir um projeto. No entanto, a estrutura de construção exata, a localização das propriedades e a filtragem ainda variam de acordo com o projeto. Como em qualquer tipo de conhecimento, dominar esses detalhes leva tempo; quanto mais tempo se investe nele, melhor eles podem executar. O tempo é o recurso mais valioso que você tem. Você deseja manter o membro de sua equipe focado na mesma área funcional pelo maior tempo possível para capitalizar seus conhecimentos e desenvolvê-los ainda mais, melhorando constantemente o desempenho da equipe.

Infelizmente, não é possível fazê-lo indefinidamente. Por um lado, as pessoas podem ficar entediadas. Por outro lado, você corre o risco de perder a experiência deles, colocando inesperadamente em risco seu projeto.

Vamos ver se existem maneiras de lidar com as desvantagens sem prejudicar muito o desempenho da equipe.

Distribua áreas de foco entre os membros da equipe e deixe que eles desenvolvam seus conhecimentos nelas. Em algum momento, eles atingem um nível alto o suficiente para fazer sentido no escopo deste projeto. O esforço extra de aprendizado não melhorará significativamente neste momento. Sem motivação e desafio, as pessoas inteligentes ficam entediadas e começam a odiar seu trabalho.

Evite isso abrindo possibilidades de aprendizado em outros lugares para eles. Mantenha-os informados sobre os projetos e a pilha tecnológica da empresa e abra novos desafios. Se o interesse deles estiver dentro do escopo do projeto, você recebe a dupla recompensa de manter sua equipe desafiada e ampliar conjuntos de habilidades úteis da equipe ao mesmo tempo. However, any self development is good to avoid boredom, even if it doesn't intersect with immediate project needs. As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!