Skip to Content.
Sympa Menu

aifia-pt - Re: [AI] Metodologias

aifia-pt AT lists.ibiblio.org

Subject: Arquitetura da Informação (em Português)

List archive

Chronological Thread  
  • From: Isabel Lofgren - Usability <isabel AT usability.com.br>
  • To: "Arquitetura da Informação (em Português)" <aifia-pt AT lists.ibiblio.org>
  • Subject: Re: [AI] Metodologias
  • Date: Mon, 14 Aug 2006 19:13:45 -0300

Title: Re: [AI] Metodologias

O assunto me interessa. Em parte porque já trabalhei muito com a questão de desenvolvimento de metodologias para a área de criação nas priscas eras da bolha...mas que ainda são atuais.

Primeiro, precisamos entender que qualquer projeto de web ou de software é um empreendimento multi-disciplinar. As metodologias de criação de software como RUP, por exemplo,acomodam, uma linha de atuação como AI, mesmo que não tenha sido concebida para isso, pois o modelo RUP tem como centro a questão das diversas iterações entre processos. A partir desse ponto, é preciso analisar as tarefas de Ai necessárias, com os deliverables todos muito bem delineados e padronizados para que possam ser ‘quantificáveis’.

Mas quando o AI trabalha sozinho, ele deve ter também um set de deliverables estabelecidos que são entregues/aprovados segundo etapas de definição do projeto...Não adianta fazer mapa do site depois dos wireframes, ou, não adianta definir elementos da interface de uma página individual sem ter antes definido minimamente a estrutura do conteúdo, e por aí vai.  Deve sempre existir uma ordem lógica das tarefas e deliverables para que tanto você quanto seu cliente e sua equipe saibam o que estão avaliando e/ou recebendo...É tudo uma questão de estabelecer uma linguagem também. Não acredito que exista um padrão de mercado, pois quando trabalhei com a Sapient, eles tinham uma metodologia muito bem delineada que era diferente dos seus competidores e muito bem adaptada a várias escalas de projeto. Havia uma divisão em fases do projeto e dentro de cada fase havia os key players, uma lista de deliverables padrão e as reuniões mais importantes em torno das quais giravam as aprovações e mudanças. A base dessa estratégia era desenvolimento e contenção de escopo, principalmente, como uma medida de controle de tempo/dinheiro/recursos. Os estratagemas diários eram amplamente discutidos até a equipe chegar a um consenso dependendo de prazo e do desafio do projeto e a responsabilidade de cada um e entender onde são os ‘overlaps’ do projeto assim como os riscos e como contê-los de antemão, na medida do possível. O importante dessa experiência era o fato dessa metodologia não ser uma abordagem teórica, mas sim extremamente pragmática, pois uma metodologia teórica mostra-se altamente não-recomendável por engessar os processos e mostrar pouca flexibilidade de ação – o que pode melar um projeto por inteiro.

Metodologia pode ser entendida como uma filosofia de trabalho aplicada. No entanto, em algumas empresas com as quais trabalhei,  metodologia tornou-se sinônimo de ineficiência. Os processos extremamente burocráticas em termos de deliverables e a metodologia deles era tão inflexível que ao invés da metodologia ser uma ferramenta, tornou-se um freio no processo além de gerar desentendimentos entre a equipe e fornecedores pois nada nunca estava ‘nos conformes’. O resultado é que perdia-se muito mais tempo fabricando os documentos do que discutindo as soluções propostas, além do fato da própria linguagem dos deliverables ser prolixa e na maior parte dos casos, e irrelevante dado a pressa e interesse do cliente em questões teóricas de AI, ou de qualquer outra coisa. Basicamente, o cliente não lê deliverables muito longos...o cliente pagou por informação e por um produto que ele quer vê-lo pronto. É simples.

O importante de uma metodologia é que ela ofereça uma espinha dorsal onde você possa se apoiar no melhor caso, mas deve ser flexível ao ponto de você poder mudar de estratégia dependendo do timing e do tipo de cliente. Se o projeto tem que ser rápido, o que adianta produzir documentos que custam tempo e dinheiro que só irão atrasar o prazo e causar ansiedade no cliente? Se o projeto é muito complexo, é fundamental que exista um gerente de projetos que irá aplicar a melhor metodologia para o projeto visando melhor aproveitamento de tempo/dinheiro/recursos, sempre baseado no modus operandi da empresa.

A chave do sucesso é sempre um bom planejamento e a utilização de ferramentas que comuniquem adequadamente a idéia. Em um projeto, ao invés de fazer um site map hierárquico mapeei o conteúdo em termos de uma molécula tentacular que ilustrou muito melhor a organizacão do conteúdo do q ue um mapa linear, e o cliente sacou na hora. Outra vez, fiz um prototipo em html com os wireframes para que o cliente entendesse de cara o esquema de navegação proposto, ao invés de bombardeá-lo com centenas de wireframes estáticos sabendo que ele iria ficar perdido. E por aí vai.

Moral da história: metodologia é qualquer modus operandi que você decidir visando a solução do seu projeto. A não ser que você tenha que trabalhar com RUP ou coisa parecida, você tem  toda a liberdade de desenvolver o projeto como quiser, contanto que tanto o cliente e a sua equipe estejam de acordo e que seja minimamente coerente com uma realidade.

Abração

Isabel





From: cristiane lindner <kri.ca AT kri.ca>
Reply-To: "Arquitetura da Informação   (em Português)" <aifia-pt AT lists.ibiblio.org>
Date: Mon, 14 Aug 2006 17:23:17 -0300
To: "Arquitetura da Informação   (em Português)" <aifia-pt AT lists.ibiblio.org>
Subject: Re: [AI] Metodologias

Oi Fabio, realmente a sua pergunta/problema é bem abrangente. Primeiro quando vc fala sobre metodologia A.I. e em segundo quando aplicada em diferentes estruturas como agências e empresas de tecnologia (fabricas de software). No primeiro caso acredito eu que muitos aqui possuem diferentes metodologias aplicadas caso a caso às necessidades dos seus clientes, porém todos temos as mesmas fontes conceituais, teóricas etc. No meu caso eu acabei desenvolvendo sim uma metodologia modular com várias abordagens que podem ser combinadas de acordo com a necessidade do cliente. Agora falando sobre a metodologia aplicada a diferentes estruturas, eu não vejo grandes dificuldades, na realidade foi trabalhando em uma empresa voltada a tecnologia e criação de softwares q me ajudou muito a melhorar e ampliar os módulos da minha metodologia A.I., principalmente quando falamos em levantamento de processos. 
O q comentei acima é apenas um início de discussão se eu realmente entendi as suas preocupações.

[]'s 


 

' Cristiane Lindner


kri.ca AT kri.ca
 

On Aug 14, 2006, at 5:01 PM, Gustavo Gawry wrote:

Eu como comecei a trabalhar com AI a pouco tempo queria saber se vocês
tem algum processo bem definido de trabalho... uma metodologia... eu
comecei a trabalhar nisso pra pensar momentos de avaliar o trabalho...
mas ainda é algo bem prematuro...
alguem ja tem algo mais bem definido?

On 8/14/06, Livia Labate <liv AT livlab.com> wrote:
 
Eu nao entendi sua pergunta nem o problema, mas estou curiosa para saber
o que eh uma "metodologia de AI"... talvez por nao ter entendido o que
isso significa.

Fabio Palamedi wrote:
 
Ola =)



Eu estava tentando explicar para meus gerentes, o porque que uma
metodologia de AI deveria ser aplicada aqui no office. No entanto, eu
não consegui explicar, mesmo porque, um dos meus gerentes (por falta de
um tenho três -_- ) que veio de uma agencia, diz que a AI, pode possuir
uma metodologia aplicada em um ambeinete de agencia.



E no contexto "Fabrica de software" ? Quero dizer, a empresas que
produzem soluções B2B, B2C, e mais uns B´s por ai. Após ler o artigo do
Guilhermo no webinsider sobre metodologia, e daí a duvida.



O maior problema que vejo em uma metodologia de AI dentro de uma fabrica
de software, é como implementar uma metodologia, em um ambiente cheio de
metodologias (como por exemplo, UML com o Enterprise Architecture) ?



Bom, acredio que a discução seja valida. O que acham?



[].s









Fabio Palamedi

Arquiteto de Informação \ Designer de UserInterface

RGM Informática Ltda.

(11) 3016-3555

 /Esta mensagem, incluindo seus anexos, tem caráter confidencial e seu
conteúdo é restrito ao destinatário da mensagem. Caso você tenha
recebido esta mensagem por engano, queira por favor retorna-lá ao
destinatário e apaga-lá de seus arquivos. Qualquer uso não autorizado,
replicação ou distribuição desta mensagem ou parte dela, sob qualquer
meio, é expressamente proibido. A RGM Informática Ltda. não é
responsável pelo conteúdo ou pela veracidade das informações nela contidas/




------------------------------------------------------------------------

. . . . . . . . . . . . . . . . . . . . . .
Ao responder, elimine o texto não essencial
de mensagens anteriores e evite formatação.

Lista de discussão AIfIA-pt
AIfIA-pt AT lists.ibiblio.org
Arquitetura de Informação em Português
http://lists.ibiblio.org/mailman/listinfo/aifia-pt
 
. . . . . . . . . . . . . . . . . . . . . .
Ao responder, elimine o texto não essencial
de mensagens anteriores e evite formatação.

Lista de discussão AIfIA-pt
AIfIA-pt AT lists.ibiblio.org
Arquitetura de Informação em Português
http://lists.ibiblio.org/mailman/listinfo/aifia-pt

 


-- 
Gustavo Gawry
Arquiteto da Informação
www.gawry.com
. . . . . . . . . . . . . . . . . . . . . .
Ao responder, elimine o texto não essencial 
de mensagens anteriores e evite formatação.

Lista de discussão AIfIA-pt 
AIfIA-pt AT lists.ibiblio.org
Arquitetura de Informação em Português
http://lists.ibiblio.org/mailman/listinfo/aifia-pt


 



. . . . . . . . . . . . . . . . . . . . . .
Ao responder, elimine o texto não essencial
de mensagens anteriores e evite formatação.

Lista de discussão AIfIA-pt
AIfIA-pt AT lists.ibiblio.org
Arquitetura de Informação em Português
http://lists.ibiblio.org/mailman/listinfo/aifia-pt



Archive powered by MHonArc 2.6.24.

Top of Page