02 Mar 2015
Hoje em dia parece haver consenso acerca dos danos que copyright pode causar à inovação. O que era para ser um estímulo a criatividade, agora é um entrave. A ideia de que uma interação com um software pode ser patenteada e se tornar diferenciador indica uma disfunção. Com o advento do Software Livre uma camada inteira do processo de desenvolvimento de produtos passou a ser patrimônio da sociedade, como a produção acadêmica. Muitos negócios extremamente bem sucedidos contribuem ativamente com a comunidade de software livre. E não por isso estão sendo prejudicados. Muito pelo contrário: estão na frente.
Criação de software é um processo extremamente democrático. Um desenvolvedor que utiliza uma tecnologia moderna pode obter resultados que anos atrás requereriam investimentos pesadíssimos. Se um modelo de negócio se diferencia só pelo software, é uma questão de tempo até que alguém descubra uma maneira melhor de fazer a mesma coisa. Por outro lado, com código livre a indústria como um todo se beneficia e - mais importante - a sociedade também. Empresas bem sucedidas usam software para implementar o seu modelo de negócio de uma forma mais eficiente. O software - apesar de ser ferramenta chave para viabilizar o negócio - não é o negócio. E o mais importante: se o modelo de negócio for único, copiar o software não fará diferença.
27 Feb 2015
A julgar pelo número de encontros de praticantes de análise de sistemas que acabaram com a atividade de "Definição do papel de analista de sistemas" como tarefa para ser executada a seguir, a falta de clareza acerca do papel é certamente a maior angústia da comunidade de analistas que trabalham com projetos ágeis.
Quem é esse cara?
Não é de se surpreender, pois a imagem o analista está intimamente ligada ao processo "cascata" de desenvolvimento de software, aonde havia uma longa fase inicial de análise, aonde estes profissionais acumulavam resmas de papel que já estariam desatualizadas antes de serem utilizadas e que - no melhor dos casos - seriam arquivadas no fim do projeto e nunca mais consultadas. Qualquer tentativa de aproveitar essa papelada para alguma outra coisa acabava por gerar mais confusão do que solução. Esse papel de intermediário era reservado, ainda por cima, para profissionais mais experientes, que abandonaram a atividade de desenvolvedor em favor do glamouroso "contato com o cliente". Eram, os barqueiros que ficavam carregando informações de um lado ao outro do rio, reduzindo o envolvimento do cliente com o projeto.
Com o advento dos métodos ágeis, a colaboração passou a ter precedência e o cliente teve que aceitar, relutantemente, o seu papel de protagonista na criação do software. Mas qual o papel do analista nessa configuração? Apesar de me considerar um Analista de Sistemas, costumo dizer que o analista é "o desperdício em um projeto ágil".
O "não papel" do analista de sistemas
Na verdade é mais fácil de chegar a um consenso a respeito do que o analista de sistemas não faz. O analista - via de regra - não escreve código. Essa, aliás, parece ser a única coisa que podemos afirmar que o analista normalmente não se envolve. Isso colabora com a pressão por explicar o que a gente faz, uma vez que nós mesmos somos os primeiros a admitir que escrever código é a única atividade em um projeto de software que realmente adiciona valor para o cliente e para os usuários. Além disso, analistas ágeis também rejeitam a definição de "barqueiro", e também os rótulos frequentes de "escrevedores de estórias" e "tomadores de pedido". Mas ainda não sabemos o que faz.
Creio que pra começar, precisamos aceitar que, em muitos projetos modernos, a figura do analista realmente não é necessária. Em muitas empresas, especialmente as que desenvolvem um produto de software, um profissional cujo a única função é ser o "analista de sistemas" realmente pode não ser necessário. Em times pequenos e maduros com profissionais capazes de falar constantemente com seus usuários essa função pode ser compartilhada por todos. Isso é ótimo! Eliminamos o "desperdício".
Mas isso certamente não é verdade em todos os casos. Em muitos times facilitar a comunicação, fazer o papel do cliente quando ele não está lá e advogar pelas necessidades do negócio - seja por que o time é muito grande, é distribuído ou simplesmente não é muito maduro - é trabalho de tempo integral. No caso de uma empresa de serviços de software, como a ThoughtWorks, o analista ainda tem o papel de ter as conversas mais difíceis ou demoradas com o cliente enquanto os desenvolvedores focam no que é mais importante: entregar código de qualidade e com valor em produção.
Na nossa cara o tempo todo
Algumas atitudes do analista já começam a ficar mais claras mas o conjunto de habilidades ainda não. Usamos o termo "Analista de Sistemas" a tanto tempo que nem paramos pra pensar no significado literal do nome em português. Talvez a resposta esteja na nossa cara o tempo todo! Vamos ver (fonte: dicionario Michaelis):
análise [a∙ná∙li∙se]
sf (gr análysis)
1 Decomposição ou separação de um todo, quer seja uma substância material, quer seja um produto do pensamento, em seus elementos constituintes.
sistema [sis∙te∙ma]
sm (gr systema)
3 Conjunto ou combinação de coisas ou partes de modo a formarem um todo complexo ou unitário.
Então, o analista de sistemas pode ser definido como o profissional que decompõe um todo complexo em seus elementos constituintes. Isso parece fazer sentido. Na minha experiência, a habilidade mais difícil de dominar na análise ágil é exatamente a "quebra de estórias" a divisão de uma funcionalidade maior nas menores estórias possíveis que realizam algum valor quando estiverem prontas e que são claramente testáveis.
Ainda mais: O termo "sistemas" remete a pensamento sistêmico, "o processo de entender como coisas, entendidas como sistemas, influenciam uma a outra dentro de um todo" (definição da Wikipedia). Pensamento sistêmico como paradigma foi popularizado no livro "A Quinta Disciplina" do Peter Senge e ajuda a entender como processos podem ser melhorados - ou seus fracassos compreendidos - se entendermos como os ciclos de feedback, premissas implícitas, incentivos e atrasos na transmissão de informação influenciam de formas inesperadas a sua execução. A habilidade de identificar as partes constituintes de um sistema, nesse caso pode ser relacionada com a habilidade de "quebrar estórias".
Assim, creio que a habilidade central de um Analista de Sistemas é a capacidade de buscar a combinação mais simples de partes constituintes que permite entender um processo. A escrita de estórias é uma aplicação específica disso. Ela implica conhecimentos de método científico, lógica, psicologia, economia entre outras e o uso generoso da Navalha de Occam para selecionar as opções pertinentes mais simples para cada momento.
Portanto, o analista de sistemas tem por papel em cada situação buscar entender o todo, e a partir deste encontrar a combinação mais simples de partes constituintes que vai permitir descrever o funcionamento atual, e eventualmente substituir as peças que impedem que o processo seja bem sucedido. Talvez até através de software de qualidade e com valor entregue em produção!
