Manual do CTO

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

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.

Elemar Júnior

Microsoft Regional Director e Microsoft MVP. Atua, há mais de duas décadas, desenvolvendo software e negócios digitais de classe mundial. Teve o privilégio de ajudar a mudar a forma como o Brasil vende, projeta e produz móveis através de software. Hoje, seus interesses técnicos são arquiteturas escaláveis. bancos de dados e ferramentas de integração. Além disso, é fascinado por estratégia e organizações exponenciais.

Talvez você goste também

Carregando posts…

Mais posts da série Manual do CTO

1 comentário
  1. Eduardo Spaki

    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”.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *