Retrabalho na AI
23 09 2008Ultimamente tenho pensado quantos arquitetos de informação são obrigados a ter um retrabalho daquilo que seria essencial ao projeto. Todos, com certeza, já devem ter passado por isso. Então fiquei imaginando uma forma de minimizar a ocorrência destes fatos (é… tenho estado constantemente nesta situação, mas não vamos nos prender a isso (risos)).
O grande diferencial de alguns AIs é que podem ter acesso ao cliente: passam horas juntos a ele para ter um briefing legal, acompanham desenvolvimento dos projetos e, o melhor, prezam pela qualidade e sucesso. Mas, pelo visto, esquecem que este “prezar pela qualidade e sucesso” talvez seja a tarefa mais importante sobre a responsabilidade deste profissional.
A esta altura você já deve estar se perguntando aonde quero chegar… Seguinte! Acho que todos gostariam muito que, após construído o wireframe apontando as funcionalidades do projeto, não tivessem que escutar: “Quero algo mais simples” ou “Não vou desenvolver isto porque não tenho recurso”.
Bem, o que queria mesmo era descrever/lembrar algumas propostas para minimizar todo retrabalho:
- Em primeiro lugar, saber as limitações de toda a equipe de desenvolvimento
- Não adianta, por mais simples que seja, fazer inovações sem conhecer sua equipe de trabalho. Isso é um ponto muito importante, pois são eles os responsáveis pelo desenvolvimento. Claro que toda equipe de trabalho deve se empenhar para ser a melhor, mas conhecê-la BEM fará com que haja um bom resultado final. É legal escutar a todos, até para ver o que eles estão querendo desenvolver. Um bom AI sempre fará questão de escutar as idéias e opiniões do outros.
- Saber filtrar, e muito bem, as necessidades e idéias dos clientes
- Já imaginou chegar em um cliente e este querer fazer um portal Globo.com para a sua empresa? Tudo bem… Vamos sentar e ver se vai dar certo. Analisar se existe condições de atualização, conteúdo dentro da empresa… Não é porque será um grande projeto que este será de sucesso. Por isso que ás vezes é melhor fazer o simples e bem feito
- Saber entender os limites: prazo, custo, recurso
- Que tal, antes de tudo, sentar com o gerente de projeto e apresentar as necessidades, um resumo das idéias do cliente e, também, as suas? Uma pequena reunião como esta, pode prevenir a ocorrência do “Não iremos desenvolver isto!”. Estamos mais do que acostumados com estas cenas e devemos esquecer a perfeição um pouco e trabalhar em cima do necessário (esta é a forma de pensamento de 99,9% dos gerentes). Concentrar-se nesta etapa deve fazer com que seu trabalho se encaixe perfeitamente dentro da sua análise da necessidade do projeto, limitações da equipe e entendimento/aceite dos responsáveis pelo gerenciamento.
- Pensar para a frente
- Utilizar soluções que ajudarão em projetos não só atuais, mas também futuros pode ser uma boa saída para aprovação de suas idéias.. Esta dica pode-se ser utilizada muito mais para desenvolvimento de áreas administrativas dos Portais. Saber ligar uma solução com outra e projetos entre si torna solução mais fácil para equipe de desenvolvimento, gasta menos recursos, pode ajudar a diminuir prazos e agrada (e se agrada) Gerentes.
Retrabalho na arquitetura de informação pode ser uma coisa inexistente para você, mas para outros é uma rotina. Talvez algumas das dicas acima possam servir para, pelo menos, lembrar do que deve ser feito. Mas a importância nos projetos são de extrema relevância. Trabalhar com funcionalidades que possam ser aplicadas em diversos projetos é bem interessante. Neste caso deve-se focar na melhoria destas funcionalidades; o “Pensar para a frente”.

Acho que o remédio para o retrabalho é a experiência, com o tempo você vai sabendo de quais respostas precisa para executar seu trabalho de forma excelente, não tem erro.
Bom post!
(=
Tudo depende da equipe com a qual você está trabalhando. Mas em alguns momentos não vejo como retrabalho, e sim como um processo de evolução.
A arquitetura sempre pode ser melhorada e deve-se limitar quando o trabalho será encerado.
Jonas, obrigado pelo complemento! Também concordo com você!
Abraço
Oi Rogério,
como falei, a equipe deve se esforçar para ser a melhor. Dependemos deles. Não são todas as vezes que são retrabalhos, realmente, em muitos casos existem melhorias no processo, mas creio que estas melhorias devem vir na etapa, ainda, de desenvolvimento da arquitetura (sentar do lado de todos e saber se vale a pena ou não utilizar isto).
Ah, acho que ainda devemos acompanhar resultados do projeto. Daí já entramos um pouco na web analítica… e que deve ajudar MUITO no caso de uma segunda etapa ou uma nova cara, futura, do projeto.
Mais uma coisa, vi a pouco o agradecimento no seu blog. Pode contar comigo! Abraço
Oi João!
É por isso que eu insisto taaaanto no alinhamento à estratégia de negócio… e pesquisa, pesquisa, pesquisa
beijo