Melhorando a relação dos times de negócio e tecnologia

Elemar Jr
tech_pagueveloz
Published in
2 min readSep 15, 2021

Tradicionalmente, são os times de "negócio" que apontam, por meio de "requisitos", o que deve ser feito. Para os times técnicos, fica a responsabilidade de determinar prazo e meios de entrega. Infelizmente, há inúmeras demonstrações de que essa fórmula não funciona. De um lado, profissionais do "negócio" reclamam que gente de "tecnologia" não consegue cumprir acordos. Do outro, "tecnologia" aponta o tempo todo que "negócio" muda de ideia toda hora.

O problema nasce com o conceito de "requisito". Na prática, o que o time de "negócio" tem é um problema para resolver. Os tais "requisitos", geralmente, não passam de um manifesto esperançoso de boas intenções. Não raro, os "requisitos" não resolvem, necessariamente, o problema e, por isso, será sucedido por outros "requisitos". Infelizmente, esses "requisitos novos" não costumam constar nos planos iniciais e, quando surgem, dão início aos conflitos.

Falar sobre prazos para "resolver problemas" é um problema porque toda solução identificada, até implementada, possui uma carga de incerteza, é apenas uma hipótese. Logo, a única (quase) certeza é que "requisitos" vão mudar ou outros novos vão emergir.

Na prática, o ideal seria que o "negócio" especificasse prioridade e que "tecnologia" potencializasse throughput para potencializar a experimentação e descobrir mais cedo o que dá e, principalmente, o que não dá certo. Ou seja, "negócio" deveria dizer o que deveria ser feito, ou seja as hipóteses (melhor que requisitos), e em que sequência (lembrando, quando tudo é prioridade, nada é prioridade). "Tecnologia", por outro lado, deveria se comprometer a fazer tudo da melhor forma e no melhor tempo.

Essa visão bidimensional, hipóteses e throughput, torna natural a formação de estruturas matriciais, como squads. Onde program managers respondem pela "estratégia do produto" e líderes técnicos correm atrás das melhores práticas.

Times de "negócio" e de "tecnologia" devem colaborar e não apenas cooperar. Mas, esse e tema para um outro post.

--

--

Elemar Jr
tech_pagueveloz

I help senior developers, architects and IT executives to develop software that meets the business needs.