Eu irritei bastante gente da última vez que falei sobre analistas de sistemas. Até hoje, 10 meses depois, ainda tem gente que me manda e-mail malcriado.
Muitos destes comentários falavam que eu estou desmerecendo o valor da análise. Minha resposta é que pelo contrario, o que eu estou dizendo é que análise é tão importante que não dá para misturar as coisas:
É certo que muitos clientes precisam entender seus próprios negócios antes de criar um sistema mas isso não é papel de analista de sistemas, é papel de analista de negócios. Um analista deste tipo possui capacitação em campos bem diferentes, é completamente possível que um analista de negócios seja um desenvolvedor (vamos abolir o “analista de sistemas” a partir daqui) mas neste caso ele está assumindo duas especialidades. Um analista de negócios possui um perfil não-técnico e mais especializado em um mercado como bancos, marketing, telecomunicações e etc.
Como eu falo no post citado, o problema é que pensamos que análise faz parte da profissão de desenvolvedor ou que é sua evolução. Isto não é verdade, o trabalho de analista de negócios pode resultar em algo que nem é um programa de computador. Em um caso recente o cliente queria um novo website para “automatizar processo” mas após a análise verificou-se que o que ele precisava era simplesmente melhorar seu formulário -de papel.
Eu realmente não entendo como pessoas conseguem misturar Test-Driven Development, Domain-Driven Design, metodologias ágeis e técnicas de análise de negócios em workshops de um dia.
Estou tendo a felicidade de ver um processo de ponta a ponta na pratica neste instante, participando de uma Inception, uma fase bem curta onde tentamos entender o que estamos fazendo. O projeto em si não começou, estamos apenas estabelecendo uma visão e pensando sobre a viabilidade do sistema.
O processo, segundo a metodologia que desenvolvemos na ThoughtWorks, é composto por diferentes workshops com quase todos os envolvidos do lado do cliente.
A atual equipe é composta por:
- Facilitador: Alguém que conduz as atividades e mantêm o time nos objetivos. Não possui uma habilidade específica alem de “facilitação de colaboração”. No meu projeto atual o papel é executado por uma analista de negócios mas eu já vi testadores, desenvolvedores e gerentes de projeto executando esta tarefa.
- Stakeholders + Analistas de negócios: Funcionários do cliente de diversas áreas envolidas e os nossos analistas que trabalham com eles.
- Líder Técnico: Um profissional técnico com senioridade suficiente para responder às dúvidas que surgirem.
Note que existe algo engraçado aí: parece um time ágil ao contrário. Ao invés de cliente presente nós temos o técnico presente. Eles realizam o trabalho de definir o que o sistema vai ser, eu só estou lá para dizer o que faz ou não sentido tecnicamente. Em um mundo ideal teríamos todo o time técnico presente (considerando que um time ágil não é nunca grande), mas como somos uma consultoria e cobramos por tempo o cliente quer, obviamente, minimizar custos em um projeto que ele ainda nem sabe se vai construir.
A Inception é muito curta. Ela precisa ser curta porque, já que não pretende entregar nada alem de uma visão geral do projeto, o desperdício precisa ser minimizado. As pessoas mais experientes dizem que nenhum projeto ágil pode ter mais de duas semanas de Inception.
As entregas são freqüentes, temos um showcase por semana (i.e. 2 no total) onde são apresentados aos stakeholders que não participam dos workshops (geralmente a alta gerencia) o que desenvolvemos naquele período: definições sobre o que o projeto é e o que ele não é. Como a maioria dos processos ágeis nós usamos ferramentas de baixa tecnologia como post-its e cartões, estes são fotografados e/ou convertidos em slides.
A entrega final depende do cliente. Em geral nós sempre temos uma lista com as histórias identificadas nestas duas semanas e suas estimativas de alto nível, formando um backlog inicial para o projeto começar. Também temos o que alguns poderiam chamar de project charter, mas ao invés de páginas e páginas de documentos temos um deck de slides com basicamente a consolidação dos dois showcases.
E qual o papel do tal analista de negócios nisso tudo? Eles trabalham junto com os stakeholders para gerar uma visão única do projeto (já que possivelmente cada stakeholder que uma coisa diferente) e transformar isso em algo que possa ser executado (histórias). No meio do caminho eles ajudam a eliminar desperdício, introduzir idéias novas, validar os pedidos, conferir viabilidade e tudo mais que não faz parte do papel de um desenvolvedor e sim de alguém que, de fato, entenda do negócio do cliente.
Desde quando trabalhávamos juntos que eu converso bastante com o Antônio Carlos sobre este tipo de coisa. No nosso ambiente nós tínhamos clientes que não sabiam o que queriam e desenvolvedores que não entendem do negócio. O resultado final era que nada que ia pro ar era exatamente o que o cliente queria, seja por falha de comunicação ou porque ele mudou de idéia e “esqueceu” de avisar aos desenvolvedores.
Note que o papel do analista de negócios não elimina a necessidade de termos um cliente presente. Não existe mapeamento de requisitos ou coisas do tipo, além de usar seu expertise naquele domínio em específico, o analista de negócios age como facilitador e não como ponte entre cliente e desenvolvedores. Ele também não é um tradutor, os termos de negocio e os processos devem ser entendidos por todos os envolvidos. Após a Inception o cliente não fica de fora do projeto, só voltando para colher os frutos. Ele faz parte da equipe o tempo todo, um analista de negócios, por melhor que seja, nunca substitui seu valor.
Esta fase do processo também responde a uma eterna discussão o fato de que XP (que é a metodologia-base usada na ThoughtWorks) não tem “foco em negócios”. Nem é para ter! XP ou qualquer metodologia ágil que se preze vai focar em pontos específicos. XP não atende a todo o ciclo de vida do projeto, ele faz parte do ciclo de vida. Quando a Inception acaba começa a Iteração 0 e daí o XP entra em ação.
Update: O Guardian, que passou pelo processo descrito aqui, tem um post bem legal sobre o assunto.
