É preciso disciplina para que as equipes de desenvolvimento se beneficiem da convenções modernas de engenharia de software. Se a sua equipe não tiver o tipo certo de disciplina de engenharia, as ferramentas e os processos que o senhor usa são quase irrelevantes. Defendi isso em A disciplina faz desenvolvedores fortes.
Mas alguns comentaristas ficaram compreensivelmente apreensivos com a ideia de ter um Instrutor de treinamento sênior Sargento de Artilharia Hartman em sua equipe, reforçando a disciplina de engenharia.
Seu canalha! Eu tenho seu nome! Tenho sua bunda! O senhor não vai rir. O senhor não vai chorar. O senhor aprenderá pelos números. Eu ensinarei o senhor.
Insultar e repreender seus colegas de trabalho para que cumpram as normas não é uma técnica motivacional eficaz para desenvolvedores de software, pelo menos não em minha experiência. Se quiser elevar sua equipe a um nível mais alto de engenharia, o senhor precisa de um líder, não de um executor. O objetivo não é fazer uma lavagem cerebral em todos com quem o senhor trabalha, mas negociar padrões comumente aceitáveis com seus colegas.
Achei que Dennis Forbes fez um excelente trabalho ao resumir as estratégias de liderança eficazes em seu post integração eficaz em equipes de desenvolvimento de software. Ele começa com um e-mail hipotético (e se eu conheço Dennis, provavelmente autobiográfico) que descreve as armadilhas de ser percebido como um executor:
Recentemente, fui contratado para ajudar uma equipe de software a lançar um produto, com a missão de ajudar com algum código de aplicativo da Web. Tenho feito o possível para me integrar à equipe, tentando ganhar alguma credibilidade e respeito ao me tornar útil.
Tenho encaminhado vários Joel sobre software envia a todos, recomendando que o escritório faça um estoque de Código Completo, Peoplewaree O Mês do Homem Míticoe faço um esforço para apontar tudo o que acredito que poderia ser feito melhor. Navego regularmente pelo repositório de código-fonte para encontrar maneiras pelas quais outros membros poderiam estar trabalhando melhor.
Quando outros desenvolvedores pedem minha ajuda, tento maximizar minha contribuição ampliando minha assistência para abranger a forma como estão desenvolvendo, como poderiam melhorar sua forma de digitação, que padrão de nomenclatura usam, para defender uma ferramenta de edição de código melhor e para dar minha palavra final educada em relação a todo o debate sobre stored procedure/dynamic SQL.
Apesar de tudo isso, continuo enfrentando resistência e acho que a equipe não gosta muito de mim. Muitas das minhas sugestões não são adotadas, e várias pessoas responderam com o que suspeito ser sarcasmo velado.
O que está acontecendo de errado?
Tenho certeza de que todos nós já trabalhamos com alguém assim. Talvez até nós mesmos tenhamos sido essa pessoa. Mesmo com a melhor das intenções e munidos de os principais livros da lista de leiturao senhor acabará como o Sargento de Artilharia Hartman: abatido por sua própria equipe.
No final de sua postagem, Dennis fornece um resumo bem pensado sobre como evitar ser atingido por sua própria equipe:
Seja humilde. Sempre presuma primeiro que o senhor está errado. Embora os desenvolvedores cometam erros e, como novo contratado, o senhor certamente deve ajudar os outros a detectar e corrigir erros, deve tentar garantir que tem certeza de sua observação antes de declarar orgulhosamente sua descoberta. É extremamente prejudicial à sua credibilidade quando o senhor grita “lobo”.
Seja discreto com as críticas construtivas. É muito mais provável que um desenvolvedor aceite sugestões casuais e perguntas discretas do que se o mesmo for enviado por e-mail para todo o grupo. Ampliar o público tem maior probabilidade de gerar reações defensivas e retaliações. A equipe está sempre considerando quais são os seus motivos, e o senhor será chamado a atenção e exilado se degradar o trabalho dos outros para se autopromover.
A melhor maneira de ganhar credibilidade e respeito é por meio de trabalho árduo e resultados reais. Substitutos baratos e superficiais, como e-mails de melhores práticas enviados a todos ou comentários passageiros sobre como seria ótimo implementar alguma solução milagrosa, não produzirão o mesmo efeito e serão mais facilmente neutralizados.
As ações falam mais alto do que as palavras. Simplesmente falar sobre a implementação de um blog de equipe, ou de um wiki, ou de um novo mecanismo de controle de origem, ou de uma nova tecnologia, é barato. Todo mundo sabe que o senhor está apenas tentando reivindicar a propriedade da ideia quando alguém acaba fazendo o trabalho duro de implementá-la, e o detestarão por isso. Se o senhor quiser propor algo, aplique um pouco de força de vontade. Por exemplo, demonstre os fundamentos de um blog de equipe, incluindo diretrizes preliminares de uso e uma demonstração de todas as tecnologias de suporte. Isso não garante que a iniciativa será bem-sucedida, e o esforço pode ser em vão, mas a equipe identificará que há motivação e esforço reais por trás dela, em vez de uma tentativa de conseguir alguns pontos fáceis.
Não existe um conselho único para todos os casos. Nem todo aplicativo é um site de comércio eletrônico de alto volume. Só porque esse é o assunto de práticas recomendadas mais comum não significa que seja, nem de longe, a melhor filosofia de design para o grupo do qual o senhor faz parte.
O que eu gosto no conselho de Dennis é que ele se concentra diretamente na ação e nos resultados. Ele se correlaciona muito bem com o que eu pessoalmente observei que funciona: o tipo mais eficaz de liderança técnica é liderar pelo exemplo. Com muita frequência, não há líderes de desenvolvimento com tempo e autoridade para impor o exemplo, mesmo que quisessem. as ações se tornam a única moeda.
Mas as ações por si só podem não ser suficientes. O senhor pode passar uma vida inteira aprendendo a liderar e ainda assim não acertar. O livro de Gerald Weinberg Becoming a Technical Leader: an Organic Problem-Solving Approach (Como se tornar um líder técnico: uma abordagem orgânica de solução de problemas) fornece uma análise muito mais profunda da liderança, específica para a profissão de engenharia de software.
Nos primeiros capítulos, Weinberg vai direto ao cerne do problema com as técnicas motivacionais hipotéticas do Sargento Hartman e de Dennis Forbes:
Como queremos ser ajudados? Não quero ser ajudado por pena. Não quero ser ajudado por egoísmo. Essas são situações em que o ajudante realmente não se importa comigo como ser humano. O que eu gostaria que os outros fizessem por mim é que me amassem – não um amor romântico, é claro, mas um verdadeiro carinho humano.
Portanto, se quiser motivar as pessoas, seja diretamente ou criando um ambiente de ajuda, o senhor deve primeiro convencê-las de que se importa com elas, e a única maneira segura de convencê-las é realmente se importando. As pessoas podem ser enganadas quanto a se importar, mas não por muito tempo. É por isso que a segunda versão da Regra de Ouro diz: “Ame o seu próximo”, e não “Finja que o senhor ama o seu próximo”. Não se engane. Se o senhor não se importar realmente com as pessoas que lidera, nunca terá sucesso como líder delas.
Weinberg’s Como se tornar um líder técnico é realmente um clássico. Ele é, simplesmente, o livro do nerd pensante Como conquistar amigos e influenciar pessoas. Grande parte da liderança é aprender a se importar com as outras pessoas, algo em que nós, programadores, somos notoriamente ruins. Talvez amar nossas máquinas e nosso código, mas nossos colegas de equipe são muito mais complicados.