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:
- Definir objetivos;
- Especificar e/ou Planejar o que tem que ser feito;
- 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
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 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.
Mais posts da série Manual do CTO
- 6 de julho de 2020 Um exemplo prático da importância da lei de Conway
- 21 de maio de 2020 Hyrum’s Law (Lei das interfaces implícitas)
- 15 de janeiro de 2020 Lehman’s laws
- 2 de janeiro de 2020 A “execução” é, mesmo, sempre mais difícil que o “planejamento”?
- 20 de dezembro de 2019 Correlação não implica em causalidade
- 26 de novembro de 2019 As quatro origens da complexidade
- 17 de novembro de 2019 O custo da oportunidade
- 11 de novembro de 2019 A estranha, odiosa e íntima relação entre a burocracia e a forma como desenvolvemos software
- 21 de outubro de 2019 Management Debt (Dívidas da Gestão)
- 19 de outubro de 2019 As “quatro versões” de como as coisas acontecem na organização
- 14 de outubro de 2019 O problema do “espírito de startup”
- 26 de setembro de 2019 As diversas fórmulas da produtividade
- 13 de setembro de 2019 Aprender a dizer “NÃO”!
- 4 de setembro de 2019 Conhecendo e suportando a estratégia competitiva
- 28 de agosto de 2019 A importância de entender relatórios/análises financeiras
- 21 de agosto de 2019 Conway’s Law
- 27 de junho de 2019 Os diversos perfis de CTO
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”.