Padronizar ou não padronizar, eis a questão
- De Henry Ford ao Devops
“O cliente pode ter o carro da cor que quiser, desde que seja preto”.
Se você já ouviu essa famosa frase do Henry Ford, pai da linha de produção, provavelmente foi em dois contextos:
- Para explicarem o valor da automatização e padronização na redução de custos de produção
- Como exemplo do que NÃO fazer para atender bem seu cliente.
Independentemente do contexto que ouviu, quem te explicou estava certo.
É claro que padrões de trabalho tem seu valor e devem ser estabelecidos para que a empresa que os adota tenha menor variabilidade de entrega, processos estáveis, clareza dos passos que estão sendo dados e facilidade de comunicação, já que todos falam a mesma língua. Mas a regra de ouro para a definição de processos organizacionais é padronizar somente o que é padronizável. “One size fits all” definitivamente não funciona. Além de não considerar o momento de cada time, restringe a liberdade criativa dos nossos profissionais. E, no fim, as empresas contratam as pessoas para pensar, não para seguir regras cegamente, certo?
Um exemplo disso acontece na Formula 1, em que são estabelecidos padrões de sistema de freios, dimensões do pneu e punições comuns para quem fizer uma ultrapassagem por fora da pista, mas a estratégia sobre quantas trocas de pneu vão fazer ou qual pneu irão utilizar em cada condição meteorológica fica a cargo de cada time decidir.
Para isso, você que já trabalha (ou tem interesse em trabalhar) em tecnologia, tem que ficar ligado. Frameworks, novos modelos de trabalho e conceitos da moda vão aparecer toda hora. Mas Upstream, Shift Left, Devops, Double Diamond e Dual Track não podem simplesmente ser termos e expressões bonitas jogadas aleatoriamente em qualquer discussão como se fosse a “bala de prata” que mata o vampiro da burocracia da empresa. É preciso entender o contexto, o histórico, os legados e os porquês de a arquitetura de sistemas estar como está!
2. E na ViaHub?
Na ViaHub, buscamos um equilíbrio entre as metodologias praticadas no mercado e o contexto em que empresa está colocado.
Muito bonito seu discurso, mas o que isso quer dizer?
Aqui (e em qualquer lugar), a utilização de processos, dinâmicas e práticas de mercado facilita a vida de qualquer pessoa que não tenha tanta experiência com determinadas metodologias. Com uma pesquisa rápida na internet, mesmo que o indivíduo nunca tenha participado de um Discovery ou uma Inception na vida, já é possível entender o conceito, os benefícios dessa prática e porque elas estão sendo utilizadas na empresa, por exemplo.
Em paralelo, o contexto da empresa e de cada área garante que não seja preciso determinar um padrão de trabalho único e obrigatório em que todos os times precisam usar Kanban, Scrum, SaFe, LeSS ou qualquer outra metodologia de trabalho porque a área X ou Y acredita ser a melhor para conseguir gerar e acompanhar indicadores.
2.1. Times multidisciplinares e colaborativos
Um bom exemplo disso é a padronização da estrutura organizacional da área de Tecnologia. Os times da ViaHub são multidisciplinares e matriciais, de forma que garantam que o produto criado e evoluído por um time não dependa sempre de outros para o lançamento de novas funcionalidades. Todos esses times são chamados de squads e um conjunto deles que estejam em um mesmo contexto são as tribos. Esse é o padrão!
Mas isso não significa que é obrigatório que todo time tenha a mesma quantidade de engenheiros, analistas de dados, UX designers ou qualquer outro papel. Cada time tem uma realidade e necessidades de papeis distintos para conseguir evoluir seus produtos.
2.2. Iniciativas alinhadas aos objetivos estratégicos
Da mesma forma, para começar a execução de uma iniciativa, é necessário que ela busque resolver um problema real, que esteja alinhada com os objetivos estratégicos da empresa e que tenha orçamento aprovado. Isso é o padrão! Mas se o(a) responsável pela iniciativa vai demonstrar que o problema existe através de uma pesquisa com um grupo de usuários, através da quantidade de chamados na URA ou através de dados de saída de clientes em uma determinada etapa do fluxo de compra, fica a cargo da pessoa.
2.3. Planejamento Sincronizado
Ainda podemos citar o padrão do planejamento de tribos da ViaHub com frequência trimestral com objetivo de gerar maior alinhamento de interdependências e por consequência, previsibilidade nas entregas de curto prazo, reduzindo a frequência de grandes mudanças de escopo daquilo que já estiver em desenvolvimento. Mas a forma como cada time planeja e executa tais entregas dentro do trimestre é de responsabilidade de cada um.
2.4. Frameworks de trabalho ágil
Para times com produto consolidado, por exemplo, é possível usar Kanban e lançar novas funcionalidades todo dia, enquanto que para times que trabalham com mudanças estruturais grandes, talvez seja melhor trabalhar com sprints bem definidas de duas ou três semanas. Cada time escolhe sua abordagem, sempre contando com o apoio dos Agilistas para a evolução da maturidade desses times, considerando o contexto que estão inseridos.
3. Processos de valor, por favor
Com esses exemplos fica mais fácil entender que, em uma empresa que está passando por uma transformação digital, saber entender quais processos valem a pena serem padronizados e até que nível é uma tarefa desafiadora e contínua. É de responsabilidade de todos que usam e participam desses processos, questionar sempre se o benefício da existência do processo A ou B em relação ao seu custo operacional é realmente algo positivo. Caso contrário, a aspiração e o objetivo desse padrão existir podem até ser nobres, mas a empresa vai acabar afundada em um mar de metodologias e práticas que pouco fazem sentido, gerando, na verdade, barreiras para o que realmente importa, a geração contínua de valor para o cliente!
