A estranha, odiosa e íntima relação entre a burocracia e a forma como desenvolvemos software

Elemar Júnior

Desenvolver e implementar processos de trabalho para times de desenvolvimento de software não é tarefa trivial. É responsabilidade primária do CTO garantir que os processos mais ajustados sejam implementados e observados na organização.

A ideia de implementar uma “metodologia ágil” é extremamente tentadora. Entretanto, essas iniciativas falham com frequência porque se aplica a “mecânica” e se ignora os princípios.

Um universo de boas intenções

Muitos gestores, ao elaborar e tentar colocar em prática processos de desenvolvimento, buscam alternativas para que a operação ocorra da forma mais eficiente possível (sem desperdício de tempo ou de recursos), continuamente (sem interrupções, nem variabilidades), de forma veloz (quanto mais rápido, melhor) e, preferencialmente, minimizando conflitos entre as pessoas.

The chief merit of “good software development practices” is its technical efficiency, with a premium placed on precision, speed, continuity, discretion, and optimal returns on input. (Merlon)

Para isso, definem papéis e atividades independentes para:

  1. Definir objetivos;
  2. Especificar e/ou Planejar o que tem que ser feito;
  3. Executar o trabalho.

Em termos práticos, estabelecem times com “analistas”, que são os únicos autorizados a falar com os “clientes” , e “traduzem” o que precisa ser feito, em especificações funcionais, para os “programadores” (executam o trabalho).

NOTA: Muitas vezes, antes dos analistas, há também consultores/gerentes de conta. Esse papel, “mais comercial do que técnico”, entende “os porquês” dos clientes.

São os analistas que entendem o que tem que ser feito e que planejam as atividades. Eles são profissionais mais “nobres e caros”. Geralmente, eles já foram programadores, mas, muitas vezes, esqueceram como escrever código.

NOTA: Os “analistas” são, geralmente, considerados pelos seus superiores como potenciais “líderes técnicos”. Não raramente, entretanto, são considerados como ultrapassados e supervalorizados pelos “programadores”.

Os “programadores” não perdem tempo entendendo o que o cliente quer, todos os dias, eles apenas “pegam a próxima história” (que é um jeito “ágil” de falar “especificação”) e começam a “transformar café em código”.

Choque de realidade

O problema é que o que muitos consideram ideal é, na verdade, conceitualmente, pura e simples burocracia.

The chief merit of bureaucracy “good software development practices” is its technical efficiency, with a premium placed on precision, speed, continuity, discretion, and optimal returns on input. (Merlon)

Definições explicitamente delimitadas para quem estabelece os objetivos, planeja e executa o trabalho caracterizam processos burocráticos que, embora funcionem bem para “trabalho braçal” ou repetitivo, não se ajustam para trabalhos complexos e intensivos em conhecimento, como é o desenvolvimento de software.

Ter analistas que “entendem” o que precisa ser feito e “orientam” os desenvolvedores apenas funciona, ainda que raramente, em times que fazem, sempre, mais do mais do mesmo. É herança do taylorismo, incompatível com trabalho do conhecimento.

Quando taylorismo se disfarça como agilidade

O espírito da agilidade não está em entregar mais features, e sim em entregar mais valor, em forma de software funcionando, em menos tempo.

Se há uma distinção clara entre quem define objetivos, analisa/planeja e executa o trabalho, há burocracia, não agilidade. Não importa se o “analista” ganha nome de Project Owner ou de arquiteto. Nem mesmo se há ou não um quadro kanban na parede (ou em versão virtual).

Recomendações para dias melhores

Se o trabalho em sua empresa não é repetitivo, não trate seu time como uma “linha de montagem”.

A ânsia de entregar mais rápido, eliminando desperdícios de tempo e de recursos, faz com que as entregas fiquem cada vez mais lentas e, frequentemente, com menor qualidade percebida. Todo mundo perde!

A busca pela precisão técnica, tentando fazer o certo da primeira vez, ignora o fato de que, muitas vezes, o cliente precisa “sentir” o software que foi desenvolvido, experimentando e avaliando, para ter uma ideia mais clara do que realmente precisa e deseja.

Tentar fazer com que o programador opere de forma contínua o afasta das discussões sobre as motivações para cada feature, impedindo que ele participe da construção da soluções. Programadores são profissionais valiosos demais para serem apenas “braços”, eles precisam ser “cabeças”.

Tentar manter um “ritmo constante” de trabalho para os programadores, empurrado e não puxado, os sobrecarrega e não deixa margem para a criatividade.

A maior parte do tempo consumido entre uma feature ser solicitada e entregue está em atividades que não tem relação com seu desenvolvimento. Não é raro que uma feature implementada em horas fique parada dias (e até semanas) esperando por homologação e deploy. Por isso, é importante considerar se vale tanto a pena gastar tanta energia na formulação de estimativas que, na prática, servem para pouco ou nada.

O maior custo em desenvolvimento de software é sempre o “custo de não ter” e ele é sentido pelo negócio. Formulemos processos com isto em mente e estaremos fazendo o certo!

Em resumo

O problema
As organizações, incluindo muitas pretensamente ágeis, definem e implementam seus processos com princípios burocráticos, de forma incompatível com a prática de desenvolvimento de software complexo.
O insight
Orientar a implementação de práticas e processos buscando minimizar o “custo de não ter” que é sentido pelo negócio. Eficiência, continuidade e previsibilidade devem ficar em segundo plano ou, até mesmo, ignoradas.
Os benefícios
A entrega de “mais valor” em tempos menores gera um ciclo virtuoso motivando o time a maximizar resultados, de forma cada vez mais autônoma e com alinhamento natural.

Compartilhe este insight:

Comentários

Participe deixando seu comentário sobre este artigo a seguir:

Subscribe
Notify of
guest
1 Comentário
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Eduardo Spaki
Eduardo Spaki
3 anos atrás

Boa reflexão. A única ressalva que vejo, em casos reais do meu dia-a-dia é que, em alguns casos (principalmente em softwares negociados por escopo), quando o desenvolvedor está em contato mais próximo do cliente, acaba correndo o risco do cliente pedir coisas fora do escopo ou até mesmo desvirtuar prioridades da cia, tentando favorecer a si próprio. Geralmente, alguma espécie de analista tem que acompanhar esse processo para “manter o dev dentro da psita”.

AUTOR

Elemar Júnior
Fundador e CEO da EximiaCo atua como tech trusted advisor ajudando empresas e profissionais a gerar mais resultados através da tecnologia.

NOVOS HORIZONTES PARA O SEU NEGÓCIO

Nosso time está preparado para superar junto com você grandes desafios tecnológicos.

Entre em contato e vamos juntos utilizar a tecnologia do jeito certo para gerar mais resultados.

Insights EximiaCo

Confira os conteúdos de negócios e tecnologia desenvolvidos pelos nossos consultores:

Engenharia de Software

Três vantagens reais de utilizar orquestradores BPM para serviços

Arquiteto de software e solução com larga experiência corporativa
Desenvolvimento de Software

Os principais desafios ao adotar testes

Especialista em Testes e Arquitetura de Software
Arquitetura de Dados

Insights de um DBA na análise de um plano de execução

Especialista em performance de Bancos de Dados de larga escala

Acesse nossos canais

Simplificamos, potencializamos e aceleramos resultados usando a tecnologia do jeito certo

EximiaCo 2022 – Todos os direitos reservados

1
0
Queremos saber a sua opinião, deixe seu comentáriox
()
x

A estranha, odiosa e íntima relação entre a burocracia e a forma como desenvolvemos software

Para se candidatar nesta turma aberta, preencha o formulário a seguir:

Condição especial de pré-venda: R$ 14.000,00 - contratando a mentoria até até 31/01/2023 e R$ 15.000,00 - contratando a mentoria a partir de 01/02/2023, em até 12x com taxas.

Tenho interesse nessa capacitação

Para solicitar mais informações sobre essa capacitação para a sua empresa, preencha o formulário a seguir:

Tenho interesse em conversar

Se você está querendo gerar resultados através da tecnologia, preencha este formulário que um de nossos consultores entrará em contato com você:

O seu insight foi excluído com sucesso!

O seu insight foi excluído e não está mais disponível.

O seu insight foi salvo com sucesso!

Ele está na fila de espera, aguardando ser revisado para ter sua publicação programada.

Tenho interesse em conversar

Se você está querendo gerar resultados através da tecnologia, preencha este formulário que um de nossos consultores entrará em contato com você:

Tenho interesse nessa solução

Se você está procurando este tipo de solução para o seu negócio, preencha este formulário que um de nossos consultores entrará em contato com você:

Tenho interesse neste serviço

Se você está procurando este tipo de solução para o seu negócio, preencha este formulário que um de nossos consultores entrará em contato com você:

× Precisa de ajuda?