Hoje continuamos nossa familiaridade com o livro " Team Geek: The Ideal IT Company " de Brian Fitzpatrick e Ben Collins-Sussman, dedicado à comunicação "no trabalho" em todas as suas formas. Da última vez, começamos com as comunicações dentro da equipe e conversamos principalmente sobre como a mentalidade de cada funcionário individualmente os afeta. Desta vez, temos que olhar para a equipe de forma mais ampla - como um grupo unido com sua própria cultura interna, que de alguma forma é formada e necessária para algo.
A cultura da equipe é um conjunto de conhecimentos, valores e objetivos específicos para um determinado grupo de programadores. Isso inclui os métodos de criação de código de programa e o estilo de comunicação entre as pessoas e as formas de organizar o fluxo de trabalho - há muitos componentes. Alguns deles não são muito críticos, eles vêm e vão facilmente (por exemplo, o costume de pedir pizza e jogar jogos de tabuleiro às sextas-feiras), outros formam a "espinha dorsal" da cultura e podem sobreviver a gerações inteiras de programadores (por exemplo, procedimentos para os processos de inspeção de código, teste, documentação, etc. Mais).
Em sua forma original, a cultura geralmente é definida pelos fundadores e pela equipe técnica original. Posteriormente, ele inevitavelmente se desenvolve e passa por mudanças, mas para equipes fortes e comprovadas (Google, Apple, Microsoft, Oracle podem ser citados como exemplo) na maioria das vezes mantém sua face original até certo ponto - a conexão com as raízes não é completamente perdida.
Ao contrário do equívoco popular, a cultura da equipe não está inteiramente nas mãos e na consciência do líder. Se realmente existe (sobre o que acontece se realmente não houver cultura, falaremos um pouco mais tarde), é veiculado por quase todos os funcionários. Isso se torna aparente quando você olha como uma equipe de novatos geralmente se integra. O novo desenvolvedor tem uma ideia de como isso é aceito aqui, o que é importante e o que não é importante por meio da interação com os colegas: o que é prestado atenção em seu código, como e em que tom eles explicam a necessidade de correções, como são os conflitos resolvido.
Cultura de equipe autossustentável: uma metáfora de padaria
Por que trabalhar na cultura da equipe?
Portanto, a cultura da equipe é uma espécie de mistura difusa de diferentes atitudes e acordos que permite que as pessoas que trabalham juntas fiquem na mesma sintonia. Surge uma pergunta natural: vale a pena se preocupar com isso? A influência mútua dos funcionários no processo de trabalho ocorre naturalmente, de modo que qualquer cultura pode se formar por si mesma.
O problema aqui é que, como acontece com todos os processos espontâneos, uma cultura em evolução espontânea irá gerar mais entropia e pode produzir resultados imprevisíveis. Em outras palavras, mais cedo ou mais tarde haverá pessoas que decidirão por suas próprias mãos determinar "como é de costume aqui". Se eles se revelarem sãos e agirem na mesma direção, o final será feliz. Porém, na maioria das vezes, isso se transforma nas mesmas velhas guerras de escritório ou, pior ainda, em bolsões de decadência dentro da equipe.
Portanto, deixar as coisas irem não é a melhor escolha. Acima, falamos sobre o fato de que a cultura não pode ser instilada à força, mas você pode abordar sua formação com consciência. Se cada participante não só se comporta de acordo com os princípios do capítulo anterior, mas também tenta trazê-los para o nível da equipe, suprime ações que são perigosas para a cooperação e não tem medo de negociar regras comuns para todos, o risco de diminuições de surpresas desagradáveis.
Qual deve ser a cultura da equipe?
É claro que é impossível responder a essa pergunta de forma inequívoca e exaustiva. As safras são extremamente diversificadas e a gama de variações produtivas saudáveis é ampla. O trabalho bem organizado e confortável pode ser tanto em uma start-up caótica, onde todos estão no conselho, quanto em uma grande empresa com processos claros e mantendo distância. Tentar estabelecer uma referência para cada um dos muitos elementos é inútil.
Em termos mais gerais, a cultura deve ser:
- . . , , . , : .
- . , , , , . . , , – .
- . , , , : , , . , – , .
- . , , . , . , .
Os canais de comunicação são o componente da cultura mais fácil de controlar e os autores prestam mais atenção a eles. No entanto, antes de entrar em detalhes, eles dão algumas dicas sobre outros elementos mais sutis.
Quando se trata de formas de tomar decisões, então, em sua maioria, os programadores preferem modelos democráticos. Talvez isso se deva ao seu notório desejo de independência, ou talvez o fato seja que a profissão é inerentemente criativa, mas o fato permanece: é importante que os desenvolvedores tenham voz e a capacidade de compartilhar seus próprios pensamentos. Os líderes devem levar isso em consideração ao organizar os processos de tomada de decisão. Não é necessário resolver todas as questões por votação geral, basta que os funcionários sejam realmente ouvidos e o sistema pressupõe consenso suficiente para que eles se sintam donos.
Quanto à forma de comunicação, ela deve gravitar em direção a polidez enfatizada ao invés de agressividade. O problema com as equipes que gritam ou usam um tom assertivo para se afirmar é que pressionam e oprimem as pessoas com uma mente mais calma. Uma pessoa propensa a conflitos se sentirá bastante confortável tanto em um ambiente agressivo quanto entre pessoas educadas. Uma pessoa calma e reservada (que há muitos entre os programadores), ao contrário, não conseguirá se abrir bem em uma equipe agressiva. Conseqüentemente, ao encorajar ou simplesmente adotar uma forma ofensiva de comunicação, eliminamos automaticamente alguns dos funcionários fortes em potencial. Isso é impraticável.
Ao mesmo tempo, deve ser entendido que a cultura de correção e respeito mútuo é mais frágil e vulnerável a influências externas. Um iniciante assertivo é o suficiente para abalar a harmonia. Portanto, é muito importante acabar com qualquer tentativa de ir contra a forma de comunicação aceita e evitar que as pessoas obtenham vitórias por meio de comportamentos destrutivos. A melhor maneira de fazer isso é simplesmente se recusar a se comunicar em um tom agressivo.
Canais de comunicação
Descobrimos que a fixação e a transmissão de informações desempenham um papel decisivo na cultura da equipe. Nas condições modernas, muitas ferramentas estão à nossa disposição para esse fim; esta seção fornece uma visão geral apenas dos mais comuns.
Uma característica comum de equipes de sucesso é que elas usam ativamente vários canais de comunicação para garantir que todos permaneçam cientes da direção geral do movimento e do andamento atual do trabalho. Ao mesmo tempo, destaca-se os canais que, em primeiro lugar, disponibilizam publicamente a informação e, em segundo lugar, aproveitam ao máximo as possibilidades da comunicação assíncrona.
Além disso, os autores consideram uma série de ferramentas específicas por meio das quais a comunicação ocorre nas equipes técnicas; esclarecer sua finalidade e regras de uso.
Definição de missão
A partir de tal título, o leitor-programador provavelmente se benzeria, mas na verdade, nem tudo é tão assustador. No trabalho técnico, a missão é formulada no nível dos projetos individuais e visa não elogiar a empresa com expressões vagamente ornamentadas, mas indicar claramente o que está sendo feito e o que não está sendo feito. Em outras palavras, uma declaração de missão é uma definição lacônica da direção do desenvolvimento do produto e que limita seu escopo.
Digamos assim:
A missão do GWT é melhorar radicalmente a experiência do usuário na World Wide Web, permitindo que os desenvolvedores aproveitem as ferramentas Java existentes para criar aplicativos AJAX para qualquer navegador moderno.
Como pessoas ativamente envolvidas em projetos de código aberto, Fitzpatrick e Sussman puderam ver por experiência própria quanto tempo, energia e nervos tal medida pode economizar para a equipe a longo prazo. Quando novos membros estão constantemente aderindo ao trabalho, cada um com suas próprias ambições, comentários e ideias brilhantes, o “núcleo” do grupo deve ter uma compreensão clara e uniforme da essência do projeto. Caso contrário, o trabalho seguirá o cenário da fábula sobre o cisne, o câncer e o lúcio, ou sofrerá trombos constantes devido às tentativas de esclarecimento dessas questões ao longo do caminho.
Conseqüentemente, uma declaração de missão é útil de duas maneiras. Em primeiro lugar, se houver desacordo entre as principais partes interessadas sobre os objetivos e o escopo do projeto, isso surgirá imediatamente e será resolvido sem demora. Em segundo lugar, o resultado da discussão será um documento com as teses principais, às quais será possível referir recém-chegados estúpidos ou excessivamente zelosos.
A declaração de missão dá à equipe uma posição segura em quaisquer decisões relativas ao projeto, mas não deve ser considerada absolutamente inviolável. Às vezes acontece (principalmente em startups) que os objetivos ou circunstâncias de trabalho mudam radicalmente. Em situações de emergência, faz sentido avaliar honestamente se a missão original ainda é relevante e alterá-la de acordo.
Documentação do projeto
Se a missão for projetada para desenvolver uma única resposta para todos os participantes do projeto à pergunta "o quê", então a documentação do projeto implica um trabalho semelhante na pergunta "como".
O documento do projeto apresenta um esboço mais detalhado do futuro projeto e seu recheio técnico. Normalmente, ele tem um proprietário, dois ou três autores e uma boa quantidade de revisores contribuindo com seus comentários. Escrever documentação, não importa o quão difícil seja suportá-la, deve preceder o trabalho no código - o momento em que nenhuma linha foi escrita é mais adequado para ouvir críticas e ajustar planos de implementação. O documento de projeto finalizado é muito conveniente para usar ao traçar um roteiro, destacar estágios de trabalho e assim por diante.
A documentação do design, por sua natureza, é muito mais flexível do que a declaração de missão; não é um dogma, mas uma substância viva. Durante o processo de desenvolvimento, é necessário revisar alguns detalhes e, idealmente, a documentação deve refletir todas essas mudanças em tempo real para que a equipe se mantenha a par. Na realidade, infelizmente, muitas vezes é editado após o lançamento do produto.
Reuniões
Muitas pessoas pensarão que seria bom fazer o sinal da cruz aqui também - as reuniões têm uma péssima reputação entre os desenvolvedores. Segundo os autores, a razão é que são mal organizados e costumam ser usados onde seria mais razoável recorrer a um canal de comunicação assíncrono.
Um bom exemplo de seleção malsucedida do formato é o “encontro”, que se realiza com certa regularidade (geralmente uma vez por semana) e com muita gente. Normalmente, anúncios importantes são lidos ali, os resultados gerais são resumidos e assim por diante. Na verdade, todo o conteúdo dos panfletos é muito fácil e produtivo de traduzir em uma mala direta eletrônica, exceto nos casos em que é precisamente uma ampla discussão coletiva que é necessária.
Quanto às reuniões, das quais você realmente não pode prescindir, as seguintes regras devem ser mantidas em mente ao conduzi-las:
- . – , , , . « » — . , - .
- , , . , . , , .
- . – .
- (, ). , – Google .
Mailing
Lists Email é uma ferramenta muito útil para documentar o histórico do projeto em segundo plano. É muito mais fácil extrair informações dele do que de mensageiros instantâneos, onde há muito mais tráfego e muito menos regulamentação. Portanto, é aconselhável enviar todas as informações importantes em listas de mala direta, independentemente de onde soou antes: cópias de planos e notas de reuniões, resultados de discussões sobre determinados problemas, documentos de projeto, análise de erros. Forma-se assim um data warehouse centralizado, onde em qualquer etapa será possível retornar para não só encontrar determinadas informações, mas também rastrear as origens das decisões e o curso da discussão. Claro, o arquivo deve estar equipado com uma pesquisa indexada.
A importância da documentação e, portanto, das correspondências é determinada pela forma como a equipe é colocada no espaço. Se alguns funcionários trabalham remotamente ou aparecem no escritório de forma irregular, a prática sustentável de duplicar notícias de grandes projetos pelo correio torna-se uma necessidade urgente. Caso contrário, grande parte das informações que "estão no ar" (discussões em corredores e mesas próximas, transmissão oral de novas informações para quem não esteve na reunião) vai passar por eles.
Se a equipe for grande e os processos turbulentos, os participantes logo começarão a se afogar em uma torrente de anúncios heterogêneos. Nessa situação, a documentação é dividida em diferentes correspondências temáticas (desenvolvimento, análise do código do programa, suporte ao usuário, teste e assim por diante), que incluem funcionários interessados. No entanto, é melhor começar com um fluxo - se houver necessidade de separação, eles vão transmitir isso rapidamente para você.
Mensageiros online Os mensageiros
ficam em algum ponto intermediário entre a comunicação síncrona e assíncrona. Eles não são ideais para documentação, mas são indispensáveis para resolver problemas rapidamente, especialmente em equipes distribuídas. Do ponto de vista da cultura de comando, dois aspectos são importantes aqui.
Primeiro, a linha divisória entre discussões públicas e privadas. A grande maioria dos mensageiros internos e comerciais dá ao usuário a oportunidade de escolher entre se comunicar com uma pessoa específica ou um grupo de pessoas, e isso é muito conveniente. No entanto, de acordo com Fitzpatrick e Sussman, tem havido uma tendência ao isolamento ultimamente - as discussões estão ocorrendo cada vez mais em privado.
Em alguns aspectos, isso não é ruim - questões privadas definitivamente não "obstruirão o ar" para todos os funcionários. Mas, por outro lado, as pessoas ficam privadas da oportunidade de acompanhar o curso da discussão, inserir seus comentários e saber imediatamente sobre as mudanças. Os novatos também perdem muito, pois podem ganhar muitas informações valiosas simplesmente lendo silenciosamente as discussões ativas no chat geral. Freqüentemente, as discussões são privadas, não porque sejam muito nichos, mas tudo por causa do mesmo medo da vulnerabilidade: você não quer fazer perguntas ou fazer sugestões na frente de todos - e se eles se revelarem estúpidos? Os desenvolvedores devem se agarrar a essa motivação e tentar não esconder o que é mais sensato permanecer no domínio público.
Em segundo lugar, você precisa se lembrar que os mensageiros instantâneos, apesar de todas as reações instantâneas, não são um substituto completo para a comunicação ao vivo. Não possuem entonações e expressões faciais que possam suavizar ou esclarecer algumas frases. Isso aumenta o risco de mal-entendidos que ameacem os princípios da modéstia, respeito e confiança, e isso deve ser levado em consideração.
Sistema de rastreamento de bugs
Esta ferramenta não é tão comum quanto as mencionadas acima. Pode ser de grande benefício sob certas condições:
- Disponibilização de procedimento de processamento e triagem de erros, que garanta seu registro e correção em tempo hábil. Se a depuração do sistema não receber atenção suficiente, as pessoas não o usarão ou abusarão dele em pequenas coisas.
- . « » , .
- . – .
- . , , .
A comunicação como parte do desenvolvimento A
comunicação na equipe técnica ocorre não apenas ao redor, mas também diretamente dentro do código. O canal principal aqui é, obviamente, os comentários do desenvolvedor .
Os autores tocam brevemente nas regras básicas de comentários de código, que provavelmente são familiares a todos: explique não o que está sendo feito, mas por que está sendo feito, tente comentar no nível de funções e métodos, seja lacônico e não se deixe levar. afastado com detalhes. O resto do estilo de comentários é algo subjetivo, cada equipe desenvolve o seu próprio, dependendo das necessidades e da atmosfera geral. O principal é que esse estilo geral deve existir em princípio; o próprio fato da uniformidade, neste caso, é mais importante do que as características específicas.
Outra forma de comunicação dentro do código é a atribuição , ou seja, a assinatura do desenvolvedor no arquivo. O costume de deixar seu nome em um documento remonta aos tempos antigos; em programas antigos, você costuma ver esses autógrafos:
Fitzpatrick e Sussman insistem que hoje essas assinaturas devem ser consideradas anacrônicas. Do ponto de vista psicológico, o desejo de indicar a autoria, é claro, permanece natural e compreensível: trata-se de uma manifestação de orgulho e senso de responsabilidade pelo trabalho realizado. No lado prático, entretanto, isso representa mais problemas do que benefícios. Agora, o desenvolvimento, como já estabelecemos na primeira parte do artigo, tornou-se uma atividade de equipe. Na verdade, várias pessoas podem estar envolvidas em um código ao mesmo tempo, o que significa que resolver a questão da autoria pode causar polêmica, ressentimento e, em última análise, perda de tempo.
No ambiente atual, é mais conveniente manter o controle da autoria no nível do projeto, em vez de diretamente no código. Quando você precisar descobrir exatamente quem entrar em contato com perguntas sobre uma parte específica do código, o sistema de controle de versão virá em seu socorro.
Agora que examinamos o âmago da "dimensão humana" em uma empresa de TI de todos os lados, podemos passar para as camadas periféricas: elementos estranhos que cercam equipes e usuários.