O modelo de organização funcional, por departamentos, é utilizado há séculos. Foi adotado por praticamente todas as companhias e tem um grande valor: levar suas respectivas áreas, como marketing, produção e finanças, à especialização e ao ganho de eficiência. Com isso, ganham mais e mais eficiência no tempo.
A ideia de departamentalização é boa, porém leva a uma consequência não desejada: a fragmentação da visão do todo. Poucos profissionais em uma grande organização têm a visão do todo. Normalmente, cada um trabalha para resolver suas demandas independentemente dos outros e de forma isolada. A má notícia é que a soma das partes não resulta no todo.
Assim, a vasta maioria das organizações de hoje sofre deste problema de visão fragmentada, tentando ganhar eficiência nas partes. E isso faz com que os processos organizacionais sejam sequenciais. Assim, um processo inicia em uma área ou seção da empresa e, quando as atividades específicas terminam, os resultados são passados para a próxima seção ou departamento, em um processo sequencial.
O desenvolvimento de sistemas, atividade em que a agilidade está bem avançada, passou pelo mesmo processo de especialização. Até um passado recente, o principal modelo de desenvolvimento de software era o Waterfall, ou modelo em cascata. Sequencial e “departamentalizado” por especialização de tarefas. O Waterfall foi utilizado na grande maioria dos sistemas de software construídos. Em benefício da especialização, este modelo impõe às atividades o mesmo isolamento que os processos organizacionais departamentalizados. Porém, com as necessidades de mercado mudando rapidamente, escopos de projetos não muito claros e a necessidade de reduzir o “time-to-market”, o modelo Waterfall mostra-se pouco flexível.
Hoje, falamos em termos como SCRUM, Kanban, Lean Development. São frameworks ágeis ou metodologias ágeis de desenvolvimento de sistemas e foram concebidas exatamente para permitir maior flexibilidade para a construção de sistemas. Os leitores deste artigo também já devem ter ouvido falar em CI/CD (Continuous Integration / Continuous Delivery), que representam modernas práticas de engenharia de software que endereçam a integração entre o desenvolvimento e a operação de sistemas.
No desenvolvimento de software, muitas empresas já utilizam com sucesso tanto os frameworks ágeis quanto a integração e implementação contínuas. Ou seja, o desenvolvimento de software é ágil ou, ao menos, está se aproximando disso. E faz com que seja possível antecipar a entrega de valor – software em funcionamento – para clientes e mercado.
E isso garante o tão desejado business agility? Não! Por quê? Porque a cultura organizacional na grande maioria das empresas ainda segue bastante departamentalizada. Ou seja, as outras áreas da empresa mantêm seus processos sequenciais.
Um exemplo: em um projeto de aperfeiçoamento do sistema comercial de uma grande empresa, fomos convidados a construir o software para suportar novos meios de pagamentos. A ideia era, além de desenvolver a integração dos novos meios de pagamento, aproveitar a nossa experiência em frameworks ágeis para também ajudar no aculturamento da empresa neste contexto. O sistema comercial legado desta companhia, um monólito construído e mantido no modelo Waterfall, sofria uma atualização a cada 8 meses, o que tornava o “time-to-market” sofrível.
Com um time de desenvolvimento pequeno, autossuficiente do ponto de vista de suas atividades, constituído de profissionais talentosos, utilizando técnicas modernas de desenvolvimento (SCRUM, CI/CD), foram entregues versões do sistema a cada três semanas. Ou seja, após três semanas de trabalho já seria possível oferecer aos clientes novos meios para pagamentos. Mas os clientes conseguiram utilizá-los? Não! Por quê?
Porque os responsáveis pela Homologação de Sistemas, separados dos times de desenvolvimento, colocaram a nova solução em uma fila, em um processo que levou algumas semanas. E, após a homologação, o Departamento Jurídico da empresa “segurou” a entrada em produção até verificar se todas as medidas de segurança e compliance haviam sido observadas e implantadas. Ou seja, a construção do sistema foi ágil. Mas os processos que fazem parte do ciclo de desenvolvimento continuaram no Waterfall. Conclusão: o sistema entrou em produção aproximadamente 4 meses após o início de seu desenvolvimento. Melhor que os 8 meses do sistema legado, mas ainda distante do sonhado business agility.
Para alcançar o business agility, as organizações devem:
Entender suas operações e novas ofertas sistemicamente e não de forma departamentalizada;
Garantir que todos na organização entenderam os conceitos e práticas da agilidade, especialmente no nível executivo;
Estimular a experimentação de novas ideias e tecnologias;
Criar pequenas equipes multidisciplinares e dar valor ao talento dos indivíduos;
Garantir que a responsabilidade seja compartilhada por todos;
Dar autonomia às equipes e garantir que sejam autogeridas;
Como se pode ver, além de técnicas e processos modernos, para alcançar o tão desejado business agility é necessária uma cultura de agilidade que deve estar disseminada por toda a organização.
Edison Kalaf é sócio-diretor da OPUS Software, empresa especializada em soluções digitais, incluindo o desenvolvimento de software personalizado, que atua há mais de 30 anos no mercado
