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.
Parabéns pelo post. Deixa bem claro porque analisar o negócio e não o cliente é muito importante. Não devemos querer ‘automatizar tudo’, pois isso parece coisa do passado. Hoje os clientes buscam na TI algo que possa diferenciá-los no mercado, algo que possa dar valor competitivo a eles e isso só se consegue com uma profunda análise do negócio do cliente, procurando agregar valor ao mesmo. É impressionante a quantidade de pessoas que pensam entender seu próprio negócio, mas será que elas entendem mesmo? Acho que se realmente entendessem não iriam buscar ajuda de estranhos. Gostei muito do post e acho que as pessoas deveriam prestar mais atenção nisso, já que muitos projetos dão errado pelo fato dos clientes não conseguirem formalizar os processos do seu próprio negócio.
Em algum momento da Inception vcs tem designers elaborando as telas do sistema? Imagino que não…
Há um tempo li algumas pessoas falando contra Iteração ZERO, dizendo que esta trás ZERO de valor de negócio para o cliente. Não é o que eu penso, porque há projetos que precisam de um mínimo de trabalho de infra-estrutura antes de se começar a implementar histórias do cliente; e isso, ao meu ver, trás valor de negócio ao cliente sim, porque uma má infra-estrutura pode trazer sérios problemas ao software produzido, o que certamente trás projuizos ao negócio. (Deixar de perder, em muitos casos, é ganhar.)
Qual é o raio-x da Iteração ZERO que vocês praticam?
Sempre pensei no analista de negócios como a ponte entre o negócio e os desenvolvedores, mas isso se aplica estritamente a um mundo não ágil, bem compartimentalizado.
Aceito numa boa trocar o termo “ponte” por “facilitador”, gosto muito desse termo, mas apelo para que não negligenciemos o valor que um analista de negócios traz a um projeto.
Além dos analistas de negócios verticais, ou seja, focados em um determinado ramo do mercado, existem os analistas de negócios que possuem como foco, e eu me incluo neles, o de serem os melhores facilitadores possíveis dentro dos projetos, sejam eles ágeis ou não.
Muitos desses analistas vieram do desenvolvimento ou da análise de sistemas e eles não tem como não se preocuparem com esta parte da moeda, é por isso que é impossível falarmos de análise de negócios em um workshop sem abordarmos, por exemplo, metodologias de desenvolvimento.
É necessário conhecer o que queremos facilitar.
E ai Philip!
Otimo post. Em relacao aos Analistas de negocios serem facilitadores e nao pontes entre o cliente e o desenvolvedor, tem essa apresentacao da QCon, do Martin Fowler e do Dan North, que eh muito boa:
http://www.infoq.com/presentations/Fowler-North-Crevasse-of-Doom
Um abraco,
Frank
Respostas para o Kerber em:
http://groups.google.com/group/an-br/browse_thread/thread/8ea49a6c8fcaf781?hl=en#
Shoes, o link do google groups aponta para uma discussão num grupo restrito…
Fala Phillip,
Post bem interessante, obrigado por compartilhar conosco :-)
Concordamos praticamente tudo, para se ter uma equipe que seja ágil é preciso que todos estejam literamente mergulhados na visão. É a situação do “Elo mais Fraco”: se o seu cliente nao sabe o que quer, ele quebra a corrente, se o seu desenvolvedor nao entende o que esta fazendo e porque esta fazendo, tb quebra a corrente. Acho que este papel do Analista é interessante, mas fico preocupado com as responsabilidades de cada um. o cliente se sente responsável pelo produto? Ele faz parte do dia a dia, ou só esta presente nas Sessões de Demo semanais?
Mas temos que concordar que é super dificil fazer isso, este é um dos maiores desafios de implementar um projeto ágil, fazer todos entrarem em sintonia, e principalmente conseguir fazer com que as diferentes formas de pensar contribuam para a melhor solução no Produto.