Pular para o conteúdo principal

Chefes, Cargos e outros detalhes

Hoje ficou um post um pouco longo, mas acho que vale a reflexão.

Chefes

Eu já falei a 1 ano atrás sobre por que não acredito na necessidade dos chefes. Recentemente o @faa85 mandou uma série de vídeos clássicos do Waldez Ludwig (video1, video2 e video3) falando sobre o novo mercado de trabalho (se você não viu, eu aconselho ver). Nem precisa falar que a fala dele é bem alinhada com o discurso do pessoal do manifesto 2.0. Resumidamente o que ele nos diz é que não existe mais espaço, na indústria da informação, para os antigos capatazes (atuais gerentes), nem antigos escravos (atuais funcionários), e que hoje as relações se moldam de uma forma mais horizontal e guiada pelo conhecimento.

Mas isto é chover no molhado. O que me traz a discutir novamente é o fato de que eu realmente acreditava que, nos trabalhos intelectuais, não existia espaço para chefes. Mas tenho visto que isto não é verdade para muitos, e acho que vale abrir espaço para algumas observações que fiz.

Primeiramente, entenda o que é um chefe. Este cara (também chamado de Gerente ou Coordenador) é uma pessoa encarregada de estabelecer cronogramas, fazer planos, distribuir tarefas e assegurar que tudo ande nos trilhos. Caso algo saia dos trilhos, ações corretivas devem ser tomadas para que tudo volte ao normal.

Na minha visão não precisamos mais desta figura. Na indústria do conhecimento a equipe é bem capaz de alcançar tudo isso quando lhe apresentam um objetivo. Mas vale então mostrar meus achados empíricos de impedimentos ao estabelecimento deste cenário.

1º Detalhe: "Praticidade"

É muito ruim para a maioria das pessoas sair da posição de ter que apenas acatar decisões para efetivamente tomá-las. Muitos acreditam que não estão preparados ou tem apenas preguiça desta nova atividade. Afinal, tomar decisões implica em discutir, argumentar e expor sua opinião aos demais. Neste caso seria melhor receber ordens do chefe. Afinal, ele sabe bem mais que você (será?).

2º Detalhe: "Responsabilidade"

A culpa quando algo sai errado é do chefe. Afinal, ele que tomou as decisões erradas. Mas quando estas são tomadas pela equipe fica complicado, pois agora a responsabilidade é de todos. Temos a vantagem das glórias serem compartilhadas, mas isso não supera o medo de muitos de se arriscar naquilo que se faz. Deixe que o chefe decida, afinal, se der errado, a culpa não é minha.

Estes dois detalhes levam toda a idéia de compartilhamento, transparência e auto-organização pro buraco. Pois impedem de maneira drástica qualquer medida em prol de uma estrutura menos hierárquica. Mas será que eles realmente impedem um ambiente 2.0? Será que não vale nos arriscarmos um pouco e obter novos resultados no lugar da segurança dos resultados que já conhecemos?

Cargos

Cargos são aqueles nomezinhos que você coloca no seu cartão de visita, assinatura de email (não vale certificações, sobre isso o @unclebobmartinfalou) ou conta pra suas tias. Eu por exemplo já usei uma penca:
  • Cientista da Computação
  • Analista de Sistemas
  • Analista Desenvolvedor
  • Diretor de TI e GQ
  • Empresário
  • Etc ..
Mas nada disso diz alguma coisa. Ou será que diz? Um dia desses uma colega de trabalho me perguntou o que colocar no campo "cargo" de um formulário, eu disse "coloca analista de sistemas" e se iniciou uma breve discussão se aquilo a enquadrava ou não no que ela desempenhava. No meio de TI existem diversos definições de cargos, algumas muito"estranhas" a mim. Afinal, o que diferencia um Testador de um Analista de Teste? É uma cabeça sem corpo? E se o cara que desenvolveu também testar ele é o que? E se ele conversar com o cliente? A combinatória disso leva a um caos total. Por isso que eu gosto do termo que o amigo @alegomes usou em sua última apresentação: "Engenheiro de Software". Algo que abrange tudo relativo a produção de software (algo que se espera de qualquer um neste meio).

Infelizmente, cargos carregam muito mais que isso. As pessoas não querem saber apenas do significado. Elas querem saber do que eles representam socialmente. Por isso a briga pelo cargo de Arquiteto, Líder de projeto e Gerente são grandes (apesar de ter muita dessa gente fazendo o serviço de ponta-a-ponta =P).

Conclusão

E aonde eu quero chegar neste meu post?
Assim como disse o Waldez Ludwig, cada vez mais vejo que o mundo da gestão do conhecimento é para poucos. Pois comportamentos como estes que eu observo só me levam a crer que muitas pessoas ainda preferem o viver no (não tão) seguro mundo 1.0. Preferem não se arriscar em um mundo sem fórmulas mas que pode levar a um trabalho muito mas feliz. Não cabe a mim criticar estas decisões, mas vale colocar aqui que existe um universo muito mais belo fora desta caixa, basta abri-la e sair.

Postagens mais visitadas deste blog

A experiência de software

Hoje em dia está muito em voga se falar sobre o desenvolvimento de produtos e serviços de software. Sendo assim as iniciativas e startups estão alta. Mas para quem está no mercado de Brasília (e de alguns outros centros do país) como eu, sabe que a prestação de serviços nas famigeradas "Software Houses" ( me recuso a chamar de Fábricas de Software ) é bem comum. Porém, este trabalho costuma ser renegado ou, como eu vejo, tratado sob um ponto de vista um pouco equivocado. Uma fábrica de software artesanal Onde se enganam tais pessoas é em que elas estão vendendo. Muitas empresas acreditam, de fato, que vendem software. Eu porém digo que isso é não de todo verdade. Se você é um prestador de serviços e constrói software sob demanda, você não vende apenas o software. Aqui não me refiro aos milhões de outros "artefatos" que são empurrados goela abaixo entregues aos nossos clientes. O que vejo é que vendemos algo que não está limitado ao software que vai pra mão (ou se

TDD como ferramenta de aprendizado

Na penúltima sessão do DojoBrasilia surgiu a seguinte questão: Será que o TDD não atrapalha no aprendizado de novas tecnologias?  A grande questão girava em torno de que o respeito estrito as regras ao TDD tornariam o aprendizado lento e enviesado. Isso por que você estaria focado em passar o teste o que estaria limitando sua velocidade no aprendizado na tecnologia, bem como a visão do objetivo final. Caso do dojoBrasília No caso da sessão que levantou a questão acho que o principal sentimento de "lentidão" se deve a grande carga de tecnologias novas que estavam envolvidas. Escolhemos iniciar um problema conhecido em não uma, mas várias tecnologias ( Backbone.js , Undescore , CoffeeScript , Jasmine , etc). Ao final da sessão a sensação de pouco avanço era justificada pelo tempo gasto compreendendo as tecnologias em questão. A sessão seguinte não obteve o avanço que muitos esperavam. Mas nela podemos ver como o uso de TDD compensou. Tínhamos apenas 4 cas

De Híbrido a 100% remoto - o caso da bxblue

A bx nasceu como uma empresa remota. Durante os primeiros 18 meses, os três fundadores --  eu, Guga e Roberto -- trabalhamos de nossas casas. Passado esse período inicial de maturação da idéia, nosso time começou a crescer, e acabamos optando por seguir um modelo híbrido. Nele tecnologia e marketing permaneceram remotos porém nosso time de atendimento e vendas ficou atrelado ao nosso escritório. Mas, como em muitas outras empresa, isso mudou nas últimas três semanas. Depois de tantos anos, nos tornamos uma empresa 100% remota. O O grande incentivo veio da situação que vivemos no mundo atualmente. Tendo o isolamento social como uma medida necessária a todos que tem o privilégio de poder fazê-lo, era nossa responsabilidade fazer tal mudança. Pois minha intenção aqui é contar um pouco tem sido essas 3 semanas que marcam o começo de um período que a ainda tem muito pela frente. Porque Híbrido? Antes, deixe-me explicar por que escolhemos o caminho de ser uma empresa híbrida, tendo na