O segredo sombrio do Agile? A TI tem pouca necessidade dele | IT Forum
08:04 am - 06 de abril de 2018
Você pode achar isso surpreendente – até que dê uma olhada mais de perto no que essas equipes precisam fazer: Há muito pouca sobreposição entre seus objetivos e o que as metodologias ágeis oferecem.
Faça as contas. O Agile é útil principalmente para 10% dos 30% – em outras palavras, ele lida com 3% do que as equipes de aplicativos de TI são obrigadas a fazer.
Assim, quando implementam um pacote COTS, precisam rastrear todos os bancos de dados existentes que armazenam os mesmos dados que o novo aplicativo também gerencia – não para aproveitá-los, mas para descobrir como manter os dados sobrepostos sincronizados.
Com os dados em mãos, as equipes de aplicativos precisam descrever o que a empresa deseja que o software faça. Variantes mais ágeis prescrevem o uso de "histórias de usuários" para este propósito – afirmações tomam a forma, "Como um <tipo de usuário> eu quero <a meta> para que <bom motivo>". Por exemplo, "Como um operador de telemarketing Quero armazenar informações sobre residências de clientes, por isso só chamo pessoas que possam querer comprar o próximo produto que estou vendendo".
Ok, o exemplo é obviamente ficção, mas não se preocupe com isso. Preocupe-se com o fato de que se você está implementando um sistema de CRM, você desperdiçará o tempo de todos e incomodará os gerentes de negócios se insistir nesse tipo de coisa. Se você estiver implementando um pacote de CRM que não armazene informações sobre todas as formas de "cliente", não estará implementando um pacote de CRM.
Aqueles que defendem a customização (porque a TI precisa deixar seus "clientes internos" felizes) estão fazendo lobby, gastando muito dinheiro implementando um software novo e brilhante para que você possa cuidar do seu negócio exatamente como está costumado.
Às vezes – na verdade, por definição – uma empresa é a melhor do ramo em uma coisa ou outra. Force o simples e a TI estará insistindo na deterioração dos negócios como estratégia.
Primeiro, a TI carrega os dados principais – dados do cliente, dados do produto e assim por diante – no banco de dados do novo pacote. Em seguida, o gerente de projeto reserva uma grande sala de conferência carregada com muitos quadros brancos, monitores grandes e outras coisas legais. Em seguida, vem uma grande pilha de transações comerciais que o novo pacote terá que lidar para ser competente no negócio.
O que acontece atrás da porta trancada? Um usuário de negócios pega uma transação, tenta fazê-la funcionar com o software como está e explica aos gurus: "Não consigo processar essa transação porque …" O desenvolvedor corrige o "porque" e passa para o próximo razão. Depois de um tempo, os porquês se tornam mais difíceis de encontrar. À medida que o fazem, o Estágio 1 desvanece e o Estágio 2 desaparece.
A transição é marcada por uma mudança na conversa. Enquanto no estágio 1 os usuários de negócios explicavam por que não conseguiam processar uma transação, as conversas do Estágio 2 soavam como: "Eu poderia processar essa transação mais facilmente se o software fizesse isso …"
Note que as conversas não são sobre tornar o software mais competente. Eles são sobre tornar os processos mais eficazes – sobre otimização de negócios.